scispace - formally typeset
Search or ask a question

Showing papers in "Requirements Engineering in 2005"


Journal ArticleDOI
TL;DR: Members of the steering committee of the IEEE Requirements Engineering (RE) Conference have discussed paper classification and evaluation criteria for RE papers, and are far from a consensus about what classes of paper they should distinguish, and what the criteria are for each of these classes.
Abstract: In recent years, members of the steering committee of the IEEE Requirements Engineering (RE) Conference have discussed paper classification and evaluation criteria for RE papers. The immediate trigger for this discussion was our concern about differences in opinion that sometimes arise in program committees about the criteria to be used in evaluating papers. If program committee members do not all use the same criteria, or if they use criteria different from those used by authors, then papers might be rejected or accepted for the wrong reasons. Surely not all papers should be evaluated according to the same criteria. Some papers describe new techniques but do not report on empirical research; others describe new conceptual frameworks for investigating certain RE problems; others report on industrial experience with existing RE techniques. Other kinds of papers can also be easily recognized. All of these types of papers should be evaluated according to different criteria. But we are far from a consensus about what classes of paper we should distinguish, and what the criteria are for each of these classes.

843 citations


Journal ArticleDOI
TL;DR: In this article, a systematic approach to eliciting security requirements based on use cases, with emphasis on description and method guidelines, is presented, which extends traditional use cases to also cover misuse, and is potentially useful for several other types of extra-functional requirements beyond security.
Abstract: Use cases have become increasingly common during requirements engineering, but they offer limited support for eliciting security threats and requirements. At the same time, the importance of security is growing with the rise of phenomena such as e-commerce and nomadic and geographically distributed work. This paper presents a systematic approach to eliciting security requirements based on use cases, with emphasis on description and method guidelines. The approach extends traditional use cases to also cover misuse, and is potentially useful for several other types of extra-functional requirements beyond security.

662 citations


Journal ArticleDOI
TL;DR: In this paper, the authors focus on the potential use of process mining for measuring business alignment, i.e., comparing the real behavior of an information system or its users with the intended or expected behavior.
Abstract: Increasingly, business processes are being controlled and/or monitored by information systems As a result, many business processes leave their “footprints” in transactional information systems, ie, business events are recorded in so-called event logs Process mining aims at improving this by providing techniques and tools for discovering process, control, data, organizational, and social structures from event logs, ie, the basic idea of process mining is to diagnose business processes by mining event logs for knowledge In this paper we focus on the potential use of process mining for measuring business alignment, ie, comparing the real behavior of an information system or its users with the intended or expected behavior We identify two ways to create and/or maintain the fit between business processes and supporting information systems: Delta analysis and conformance testing Delta analysis compares the discovered model (ie, an abstraction derived from the actual process) with some predefined processes model (eg, the workflow model or reference model used to configure the system) Conformance testing attempts to quantify the “fit” between the event log and some predefined processes model In this paper, we show that Delta analysis and conformance testing can be used to analyze business alignment as long as the actual events are logged and users have some control over the process

228 citations


Journal ArticleDOI
TL;DR: A model, with four abstraction levels, was developed as a response to the industrial need, that will allow companies to ensure comparability between requirements, and hence it generates important input to activities such as prioritization and packaging of requirements before launching a development project.
Abstract: Software requirements arrive in different shapes and forms to development organizations. This is particularly the case in market-driven requirements engineering, where the requirements are on products rather than directed towards projects. This results in challenges related to making different requirements comparable. In particular, this situation was identified in a collaborative effort between academia and industry. A model, with four abstraction levels, was developed as a response to the industrial need. The model allows for placement of requirements on different levels and supports abstraction or break down of requirements to make them comparable to each other. The model was successfully validated in several steps at a company. The results from the industrial validation point to the usefulness of the model. The model will allow companies to ensure comparability between requirements, and hence it generates important input to activities such as prioritization and packaging of requirements before launching a development project.

227 citations


Journal ArticleDOI
TL;DR: A framework for SME combining an assembly-based approach for project-specific method construction and a roadmap-driven approach for engineer- Specific method configuration is proposed, which aims at choosing the most adapted path (roadmap) to satisfy the requirements of a particular project engineer within the project- specific method.
Abstract: Because the engineering situation of each information system development (ISD) project is different, engineering methods need to be adapted, transformed or enhanced to satisfy the specific project situation. Contributions, in the field of situational method engineering (SME), aim at providing techniques and tools allowing to construct project-specific methods instead of looking for universally applicable ones. In addition to the engineering method tailoring, necessary to fit the project situation, a customization of the engineering method for each engineer participating in the project is also required. Such a configuration allows a better understanding of the method by focusing on guidelines related to the project engineer’s daily tasks. It also increases his/her involvement in the ISD method realization. To achieve this twofold objective (ISD method tailoring and customization), we propose a framework for SME combining an assembly-based approach for project-specific method construction and a roadmap-driven approach for engineer-specific method configuration. The first step of our process provides support to build a new method that is most suitable for the current ISD project situation, whereas the second step aims at choosing the most adapted path (roadmap) to satisfy the requirements of a particular project engineer within the project-specific method. The two core elements of our SME framework are the method chunks repository and the reuse frame. The former concerns reusable method components definition and storage whereas the latter deals with the characterization of the project situation and the project engineer’s profile. In this paper we start first by presenting our SME framework and its core elements: the method chunk repository and the reuse frame. Then we show how to take advantage of them through our two-step process combining assembly-based method construction and roadmap-driven method configuration.

184 citations


Journal ArticleDOI
TL;DR: The approach implemented in the framework, called ReqMon, provides real-time feedback on requirements satisfaction, and thereby provides visibility into requirements compliance of enterprise information systems.
Abstract: Requirements compliant software is becoming a necessity. Fewer and fewer organizations will run their critical transactions on software that has no visible relationship to its requirements. Businesses wish to see their software being consistent with their policies. Moreover, partnership agreements are pressuring less mature organizations to improve their systems. Businesses that rely on web services, for example, are vulnerable to the problems of their web service providers. While electronic commerce has increased the speed of on-line transactions, the technology for monitoring requirements compliance—especially for transactions—has lagged behind. To address the requirements monitoring problem for enterprise information systems, we integrate techniques for requirements analysis and software execution monitoring. Our framework assists analysts in the development of requirements monitors for enterprise services. The deployed system raises alerts when services succeed or fail to satisfy their specified requirements, thereby making software requirements visible. The framework usage is demonstrated with an analysis of ebXML marketplace specifications. An analyst applies goal analysis to discover potential service obstacles, and then derives requirements monitors and a distributed monitoring system. Once deployed, the monitoring system provides alerts when obstacles occur. A summary of the framework implementation is presented, along with analysis of two monitor component implementations. We conclude that the approach implemented in the framework, called ReqMon, provides real-time feedback on requirements satisfaction, and thereby provides visibility into requirements compliance of enterprise information systems.

163 citations


Journal ArticleDOI
TL;DR: This paper suggests specific semantics for object- oriented constructs based on a mapping between ontologically derived concepts and object-oriented language constructs and proposes modelling rules to guide the construction ofobject-oriented conceptual models and to assure that such models describe only ontologically feasible application domain situations.
Abstract: Understanding the business is an important step in information system (IS) development. Conceptual models are descriptions of the organizational context for which a system is developed, and are used to help understanding this context. However, conceptual modelling methods do not provide well-formalized ways to create domain descriptions. On the other hand, in the area of IS design and software modelling, languages exist (such as UML) that possess a high level of formality. Extending the use of these IS design languages to conceptual modelling, even though they have not been specifically intended for this, can lead to several advantages. In particular, it can enable the use of similar notation in several stages of system development. However, while object-oriented constructs such as “object” and “operation” have clear meaning in the context of software design, it is not clear what they might mean in terms of the application domain, and no rules or guidelines exist for using them to create useful descriptions of such domains. This paper suggests specific semantics for object-oriented constructs based on a mapping between ontologically derived concepts and object-oriented language constructs. The paper also proposes modelling rules to guide the construction of object-oriented conceptual models and to assure that such models describe only ontologically feasible application domain situations. While the results are applicable to object-oriented constructs in general, UML is used as an example. A case study to test the use of the proposed semantics and modelling rules is described.

140 citations


Journal ArticleDOI
TL;DR: The feasibility and effectiveness of the technique in requirements elicitation was demonstrated by experiments on two projects with very different characteristics, and the results of both experiments highlights the higher effectiveness of EPMcreate.
Abstract: This paper proposes the application to requirements elicitation of an innovative creativity fostering technique based on a model of the pragmatics of communication, the Elementary Pragmatic Model (EPM). The EPM has been used to define a creative process, called EPMcreate (EPM Creative Requirements Engineering TEchnique) that consists of sixteen steps. In each step, the problem is analyzed according to one elementary behavior identified by the EPM. Each behavior suggests that the analyst look at the problem from a different combination of users’ viewpoints. The feasibility and effectiveness of the technique in requirements elicitation was demonstrated by experiments on two projects with very different characteristics. Each experiment compared the performances of two analysis teams, one of which used EPMcreate and the other of which used brainstorming. The results of both experiments highlights the higher effectiveness of EPMcreate. Additional data from the experiments are examined for other insights into how and why EPMcreate is effective.

83 citations


Journal ArticleDOI
TL;DR: This viewpoint argues that the introduction of most computer-based system to an organization transforms the organization and changes the work patterns of the system’s users in the organization.
Abstract: This viewpoint argues that the introduction of most computer-based system to an organization transforms the organization and changes the work patterns of the system’s users in the organization. These changes interact with the users’ values and beliefs and trigger emotional responses which are sometimes directed against the software system and its proponents. A requirements engineer must be aware of these emotions.

67 citations


Journal ArticleDOI
TL;DR: In this paper, the deep structure that lies behind the surface structure of business processes and business process support systems (BPSs) is understood and a theoretical basis for concurrent design and engineering of BPs and BPSs is provided.
Abstract: In order to achieve and maintain an optimal fit between business processes (BPs) and business process support systems (BPSs), both need to be understood thoroughly and coherently Moreover, to benefit fully from the potentials of modern information and communication technology (ICT), the deep structure that lies behind the surface structure of BPs should be understood The Ψ-theory, which is only summarized in this paper, provides the basis for such an understanding of BPs and BPSs as well as for some other basic notions In particular, the notions of design and engineering and of architecture and ontology will be addressed The conclusion is that these notions can consistently and coherently be related to each other, on the said theoretical basis, such that the concurrent (re)design and (re)engineering of BPs and BPSs can be performed more effectively

62 citations


Journal ArticleDOI
TL;DR: This article will try to go about demonstrating why it is sincerely believed that good requirements practices are indeed neither necessary nor sufficient, even though the authors are devoted to the field of requirements as active researchers and practitioners.
Abstract: The title of this essay was selected to create controversy among the readers and perhaps cause some of you to become defensive. However, we will try to go about demonstrating why we sincerely believe that good requirements practices are indeed neither necessary nor sufficient, even though we are devoted to the field of requirements as active researchers and practitioners. In fact, after you read this article, we trust that you too will say, ‘‘Well, of course, I agree with you.’’ To argue about the necessity or sufficiency of good requirements practices, we must first agree to (1) what is a requirements practice, (2) what is a good requirements practice, (3) what is the purpose of a requirements practice, and (4) what is it necessary and sufficient for? Only then can we argue why ‘‘good’’ requirements practices are neither necessary nor sufficient to achieve the intended purpose for requirements. There is little uniformity in terminology concerning the classes of activities that make up requirements. However, we all seem to agree that the following activities are included:

Journal ArticleDOI
TL;DR: The paper proposes criteria and associated generic metrics to quantify to which extent there is a fit between the business and the system which supports it and bases this proposal on the use of ontologies.
Abstract: It is widely acknowledged that the system functionality captured in a system model has to match organisational requirements available in the business model. However, such a matching is rarely used to support design strategies. We believe that appropriate measures of what we refer to as the fitness relationship can facilitate design decisions. The paper proposes criteria and associated generic metrics to quantify to which extent there is a fit between the business and the system which supports it. In order to formulate metrics independent of specific formalisms to express the system and the business models, we base our proposal on the use of ontologies. This also contributes to provide a theoretical foundation to our proposal. In order to illustrate the use of the proposed generic metrics we show in the paper, how to derive a set of specific metrics from the generic ones and we illustrate the use of the specific metrics in a case study.

Journal ArticleDOI
TL;DR: This paper develops a unifying framework for requirements quality control, which reorganizes the existing knowledge around the issue of communicating requirements to all the different stakeholders, instead of just focusing on some techniques and processes.
Abstract: Literature tends to discuss software (and system) requirements quality control, which includes validation and verification, as a heterogeneous process using a great variety of relatively independent techniques. Also, process-oriented thinking prevails. In this paper, we attempt to promote the point that this important activity must be studied as a coherent entity. It cannot be seen as a rather mechanical process of checking documents either. Validation, especially, is more an issue of communicating requirements, as constructed by the analysts, back to the stakeholders whose goals those requirements are supposed to meet, and to all those other stakeholders, with whose goals those requirements may conflict. The main problem, therefore, is that of achieving a sufficient level of understanding of the stated requirements by a particular stakeholder, which may be hindered by, for example, lack of technical expertise. In this paper, we develop a unifying framework for requirements quality control. We reorganize the existing knowledge around the issue of communicating requirements to all the different stakeholders, instead of just focusing on some techniques and processes. We hope that this framework could clarify thinking in the area, and make future research a little more focused.

Journal ArticleDOI
TL;DR: This work proposes a requirements engineering framework that incorporates a business strategy dimension that incorporates Jackson’s Problem Frames approach, goal modeling, and business process modeling to achieve this.
Abstract: As a means of contributing to the achievement of business advantage for companies engaging in e-business, we propose a requirements engineering framework that incorporates a business strategy dimension. We employ Jackson’s Problem Frames approach, goal modeling, and business process modeling (BPM) to achieve this. Jackson’s context diagrams, used to represent business model context, are integrated with goal models to describe the requirements of the business strategy. We leverage the paradigm of projection in both approaches as a means of simultaneously decomposing both the requirement and context parts, from an abstract business level to concrete system requirements. Our approach maintains traceability to high-level business objectives via contribution relationship links in the goal model. We integrate use of role activity diagrams to describe business processes in detail where needed. The feasibility of our approach is shown by a well-known case study taken from the literature.

Journal ArticleDOI
TL;DR: An extension to the RESCUE process in which patterns for generating requirements statements from i* system models were manually applied to i* models developed for a complex air traffic control system is reported.
Abstract: Academic research has produced many model-based specification and analysis techniques, however, most organisations continue to document requirements as textual statements. To help bridge this gap between academic research and requirements practice, this paper reports an extension to the RESCUE process in which patterns for generating requirements statements from i* system models were manually applied to i* models developed for a complex air traffic control system. The paper reports the results of this application and describes them with examples, the benefits of the approach to the project, and ongoing research to implement these patterns in the REDEPEND modelling tool to make requirements engineers more productive. We review similar work on requirements modelling and expression, and compare our work to it to demonstrate the proposed advance in the state of the art. Finally the paper discusses future uses of requirements generation from model patterns in RESCUE.

Journal ArticleDOI
D. Arthur1, K. Gröner1
TL;DR: A requirements generation model (RGM) that decomposes the conventional “requirements analysis” phase into sub-phases which focus and refine requirement generation activities, bounds and structures those activities to promote a more effective generation process, and implements a monitoring methodology to assist in detecting deviations from well-defined procedures.
Abstract: Product quality is directly related to how well that product meets the customer’s needs and intents. Therefore, the ability to capture customer requirements correctly and succinctly is paramount. Unfortunately, within most software development frameworks requirements elicitation, recording and evaluation are some of the more ill-defined and least structured activities. To help address such inadequacies, we propose a requirements generation model (RGM) that (a) decomposes the conventional “requirements analysis” phase into sub-phases which focus and refine requirement generation activities, (b) bounds and structures those activities to promote a more effective generation process, and (c) implements a monitoring methodology to assist in detecting deviations from well-defined procedures intended to support the generation of requirements that meet the customer’s intent. The RGM incorporates “lessons learned” from a preliminary study that concentrated on identifying where and how miscommunication and requirements omission occur. An industry study (also reported in this paper) attests to the effectiveness of the RGM. The results of that study indicate that the RGM helps (a) reduce the late discovery of requirements, (b) reduce the slippage in milestone completion dates, and (c) increase customer and management satisfaction levels.

Journal ArticleDOI
TL;DR: The remedy that is proposed is that requirements engineering researchers should learn to distinguish design from research, and start doing research.
Abstract: A few years ago, Davis and Hickey (2002) suggested that a reason why the results of requirements engineering research are not used in practice is that requirements engineering researchers do not practice what they preach: they do not analyze the problems of requirements engineering practice, and therefore their solutions do not address these problems. Although I agree with this diagnosis, I think it must be taken one step further in order to achieve a vision of a solution. The additional step that I propose here is to realize that currently, most requirements engineering researchers do not do research. Many of us create unvalidated designs, and move on from one unvalidated design to the other. The remedy that I propose is that we should learn to distinguish design from research, and start doing research. What we should do research about is the engineering process, so let me first explain what I mean by ‘‘engineering’’.

Journal ArticleDOI
TL;DR: There does not seem to be much interest in the scientific treatment of open issues in this regard, but this article argues for taking such issues up (again).
Abstract: Different communities deal with the use of object-oriented (O-O) ideas for requirements engineering. Their views are different and many misunderstandings are around. Although O-O approaches are the most widely used in practice apart from pure natural language, there does not seem to be much interest in the scientific treatment of open issues in this regard. This article argues for taking such issues up (again).

Journal ArticleDOI
TL;DR: This study investigates the usefulness of a scenario advisor tool built to help requirements engineers to generate sufficient sets of scenarios in the domain of socio-technical systems and found that the tool helped users to write more sound scenarios without any domain knowledge and to generate more variations on existing scenarios.
Abstract: This study investigates the usefulness of a scenario advisor tool which was built to help requirements engineers to generate sufficient sets of scenarios in the domain of socio-technical systems. The tool provides traceability between scenario models and requirements and helps to generate new scenarios and scenario variations. Through two series of evaluation sessions, we found that the scenario advisor tool helped users to write more sound scenarios without any domain knowledge, and to generate more variations on existing scenarios by providing specific scenario-generation hints for each scenario component. The tool should improve the reliability of requirements elicitation and validation.

Journal ArticleDOI
TL;DR: A simple specification method is introduced and the results of its application to a series of projects in Philips are reported, producing a model of system behaviour as a finite state machine.
Abstract: A simple specification method is introduced and the results of its application to a series of projects in Philips are reported. The method is principally designed to ensure that that every unusual scenario is considered in a systematic way. In practice, this has led to high-quality specifications and accelerated product development. While the straightforward tabular notation used has proved readily understandable to non-technical personnel, it is also a formal method, producing a model of system behaviour as a finite state machine. In this respect, the notation is unusual in being designed to preserve as far as possible a view of the overall system state and how this changes. The notation also features a constraint table which may be described as a kind of spreadsheet for invariants to help define the states of the system.

Journal ArticleDOI
TL;DR: The main findings are that the parties didn’t understand each other, although the suppliers sometimes pretended that they did so, and one consequence was that the business goals pursued by the customer were not properly achieved.
Abstract: Large IT systems are often acquired in a tender process where the customer states the system requirements, a number of suppliers submit their proposals, and the customer selects one of them. Usually the supplier uses an existing system as the basis for his proposal. He adapts it more or less to the customer’s requirements. This paper is a study of a specific tender process. The customer was a Danish municipality that supplied electrical power, water, gas, garbage collection, etc. for around 100,000 households. The customer wanted a new system for meter inspection, invoicing, planning the meter inspector’s routes, etc. We have studied the requirements, how they were perceived by the suppliers, and how they were intended by the customer. The main findings are that the parties didn’t understand each other, although the suppliers sometimes pretended that they did so. One consequence was that the business goals pursued by the customer were not properly achieved. Among the causes of this were an excessively democratic elicitation process and an inadequate use of requirement techniques, particularly use cases. There were also issues that the existing requirement techniques couldn’t deal with, for instance integration with future systems.

Journal ArticleDOI
TL;DR: This work has prototyped automated support for full-lifecycle scenario management and has applied it to some non-trivial systems.
Abstract: Scenarios have been shown to be very helpful in identifying and communicating requirements for computer-based systems (CBSs). However, they appear not to be applicable to the rest of the CBS development process. Making scenarios more useful for the entire software development lifecycle requires integrating scenarios to other representations used during CBS development. This integration is achieved with tracing technology. Having integrated scenarios into the entire software development lifecycle creates the necessity to maintain scenarios through the inevitable changes that they and other documents undergo and to subject them to configuration management. We have prototyped automated support for full-lifecycle scenario management and have applied it to some non-trivial systems.

Journal ArticleDOI
TL;DR: The suitability of certain scenario-based models in a real-time software environment is discussed and an approach is proposed, called timed automata, that constructs a formalised view of scenarios that generate timed specifications that represents the operational view of scenario with the support of a formal representation that is needed for real- time systems.
Abstract: One of the most critical phases of software engineering is requirements elicitation and analysis. Success in a software project is influenced by the quality of requirements and their associated analysis since their outputs contribute to higher level design and verification decisions. Real-time software systems are event driven and contain temporal and resource limitation constraints. Natural-language-based specification and analysis of such systems are then limited to identifying functional and non-functional elements only. In order to design an architecture, or to be able to test and verify these systems, a comprehensive understanding of dependencies, concurrency, response times, and resource usage are necessary. Scenario-based analysis techniques provide a way to decompose requirements to understand the said attributes of real-time systems. However they are in themselves inadequate for providing support for all real-time attributes. This paper discusses and evaluates the suitability of certain scenario-based models in a real-time software environment and then proposes an approach, called timed automata, that constructs a formalised view of scenarios that generate timed specifications. This approach represents the operational view of scenarios with the support of a formal representation that is needed for real-time systems. Our results indicate that models with notations and semantic support for representing temporal and resource usage of scenario provide a better analysis domain.

Journal ArticleDOI
Nikolaus Kleiner1
TL;DR: Delta analysis with workflow logs employs workflow logs recorded during system use to compare process enactment with its prescription and shows how process participants work with the new system and where and why they deviate from the intended process.
Abstract: To support and drive a business process with a software system means influencing the way process participants conduct their daily work. An analysis of the relationships between organizational processes, support systems, and process participants calls for a continuous alignment and parallel evolution of the intended business process and the supporting software system. Here, the primary information needed is how process participants work with the new system and where and why they deviate from the intended process. Delta analysis with workflow logs employs workflow logs recorded during system use to compare process enactment with its prescription: log entries are related with instances of business process activities of an explicit process definition, and the timely ordering of these entries is compared with the ordering of the activities implied by the process model. If the orderings comply, the log fits the model. Log entries and activities can be on arbitrary levels of abstraction and arbitrary granularity. The results of such an analysis can be utilized as an unbiased data basis for further discussions. Moreover, compared with traditional approaches such as interviews and observations, time and costs can be saved. The paper presents the concept, a feasibility study, some aspects of the related theoretical challenges, a prototypical implementation, and initial case study results.

Journal ArticleDOI
TL;DR: The immersive scenario-based requirements engineering (ISRE) method guides the analysis of problems encountered during the testing of virtual prototypes and helps assign causes to either genuine requirements defects or to usability issues with VR technology.
Abstract: Virtual prototyping is a useful approach for refining requirements for complex designs. However, the use of virtual reality (VR) technology can cause usability problems that can be interpreted as “false positive” requirements errors. The immersive scenario-based requirements engineering (ISRE) method guides the analysis of problems encountered during the testing of virtual prototypes and helps assign causes to either genuine requirements defects or to usability issues with VR technology. The method consists of techniques for walkthrough testing, testing with users, causal analysis of observed problems and the design of scenario-based analysis sessions. The method is described and its use illustrated with a case study of validating requirements for an aircraft maintenance application.

Journal ArticleDOI
TL;DR: KOPeR is enhanced, a knowledge-based system for business process improvement, with an explanation facility that can acquire and maintain knowledge about the context behind process definitions and design choices.
Abstract: Businesses need to continuously focus on change and innovation in order to survive in dynamic environments. The ability of an organization to deploy appropriate business processes requires that the fit between business processes and systems that support the management of these processes is continuously maintained and evolved. Acquisition and use of the knowledge about the context in which business processes are defined, modified, and implemented can help maintain this fit. We identify requirements for a business process management system (BPMS) capable of managing contextual knowledge. Based on these requirements, we have enhanced KOPeR, a knowledge-based system for business process improvement, with an explanation facility that can acquire and maintain knowledge about the context behind process definitions and design choices. A case study that illustrates the functionalities of this system which is designed to improve the fit between business processes and BPMS is presented.

Journal ArticleDOI
TL;DR: In this article, the authors presented some plausible estimates on the potential growth rate of the Brazilian economy based on two traditional models: the Harrod-Domar model and the neoclassical model with human capital and exogenous technical progress.
Abstract: The paper presents some plausible estimates on the potential growth rate of the Brazilian economy based on two traditional models: the Harrod-Domar model and the neoclassical model with human capital and exogenous technical progress. The estimates are obtained through adjusting the parameters of the models based on the observed values of those parameters. The comparison of the two models suggests significant uncertainty about the value of the potential growth rate. The exercise with the Harrod-Domar model suggests a 2.5% rate, whilst the neoclassical model points to 4.6%. The Brazilian experience over the 1980s and 1990s seems to be much closer to the forecast provided by the Harrod-Domar model than to the one provided by the neoclassical model.

Journal ArticleDOI
TL;DR: In this paper, the authors assess the academic use of business simulators and suggest their main advantages to be the stimulus to systemic thinking and the development of decision-making capabilities, while the time length and resources demanded for its use are the main disadvantages.
Abstract: The article assesses the academic use of business simulators. Business simulators or games can be used in academic activities, business training, organizational and human resources development, psychology research, supporting decision processes and as a tool for economic research. Its application to academic purposes include solving complex problems, developing team work and technical capabilities. A study in Germany suggests their main advantages to be the stimulus to systemic thinking and the development of decisionmaking capabilities. The time length and resources demanded for its use are the main disadvantages. It is suggested here that cheaper IT technology, especially cheaper internet, will allow more intensive use of tools like business simulators in the applied social sciences.

Journal ArticleDOI
TL;DR: This special issue includes four extended, revised and rigorously re-reviewed papers selected among those presented at REFSQ’04 ( original versions are available in the workshop proceedings), and a summary of the best papers included in this special issue are provided.
Abstract: For the tenth time, the international workshop Requirements Engineering: Foundation for Software Quality (REFSQ) gathered researchers from around the world. The tenth anniversary was celebrated in the beautiful city of Riga, Latvia on the 6th and 7th of June, 2004, in connection with the International Conference on Advanced Information Systems Engineering (CAiSE’2004). The anniversary workshop had 27 participants from both academia and industry representing 15 countries from four continents. The REFSQ workshop series provides an annual, highly interactive forum for ground-breaking research in RE. The original aim of REFSQ was to foster research in requirements engineering with special focus on its links to the overall quality of the resulting systems. Over the years, the scope of the workshop has grown, both encompassing different and more diverse type of ‘‘systems’’ (from the initial software systems to business processes and socio-technical systems), and extending to other issues not necessarily focused on quality. The format of the workshop, with its strong emphasis on multifaceted, in depth discussions among participants over papers presented, has been highly successful in promoting active involvement and encouraging the emergence of innovative ideas. REFSQ invites publication and dialog regarding new solutions to known RE issues, ideas that are likely to initiate new threads inRE research, industrial problem statements, and generalisations from industrial experiences. The workshop also aims at intensive interaction between its participants and provokes discussion by guiding presentations, individual paper discussions, as well as topic discussions at the end of each session. This year, in addition to standard presentations, two special sessions devoted to a set of invited ‘‘anniversary papers’’ were included in the program: the first one on quality issues in RE and their relevance in industry; the second one on retrospective studies on the research output of REFSQ since its inception—as well as an outlook on future research. The REFSQ’2004 Call for Papers invited submissions on a wide range of RE issues, such as: understanding and improving RE-processes; new methods and method engineering approaches for RE; evaluations of RE methods, techniques and tools; empirical studies of industrial RE practice; as well as transdisciplinary theories of and paradigms for RE. This special issue includes four extended, revised and rigorously re-reviewed papers selected among those presented at REFSQ’04 (original versions are available in the workshop proceedings [1]). The selected best papers cover topics including the role of requirements in negotiation processes and the generation of requirements through novel elicitation techniques. A wide range of interesting results and important directions of further research are provided. Finally a summary of the anniversary events at REFSQ’04 (the anniversary papers can be downloaded from http://www.refsq.org) with focus on retrospectives and outlooks on RE research, and a summary of the best papers included in this special issue are provided.

Journal ArticleDOI
TL;DR: A case study in the commercial procurement of an IT system to support learners on short educational courses is looked at to discover how accurately the original model represented the final application to provide a measure of the potential usefulness of the pattern language during procurement.
Abstract: This paper looks at a case study in the commercial procurement of an IT system to support learners on short educational courses. It compares the use case model created before the system was built with the use case model after the system was delivered. The original use case model was created through the application of a requirements pattern language designed to be employed during the procurement phase of an IT system. The final use case model was reverse engineered from the working application. The objective was to discover how accurately the original model represented the final application to provide a measure of the potential usefulness of the pattern language during procurement.