Requirements analysis includes a preliminary acquisition step where a global model for the specification of the system and its environment is elaborated. This model, called requirements model, involves concepts that are currently not supported by existing formal specification languages, such as goals to be achieved, agents to be assigned, alternatives to be negotiated, etc. The paper presents an approach to requirements acquisition which is driven by such higher-level concepts. Requirements models are acquired as instances of a conceptual meta-model. The latter can be represented as a graph where each node captures an abstraction such as, e.g., goal, action, agent, entity, or event, and where the edges capture semantic links between such abstractions. Well-formedness properties on nodes and links constrain their instances - that is, elements of requirements models. Requirements acquisition processes then correspond to particular ways of traversing the meta-model graph to acquire approp...

Specification exemplars are familiar to most software engineering researchers. For instance, many will have encountered the well known library and lift "problems", and will have seen one or more published solutions. Exemplars may serve several purposes: as drivers of and communication vehicles for individual research advances; to establish research agendas and to compare and contrast alternative approaches; and, ultimately, to lead to advances in software development practices. Because of their prevalence in the literature, exemplars are worth critical study. In this paper we consider the purposes that exemplars may serve, and explore the incompatibilities inherent in trying to simultaneously serve several of them at once. Researchers should therefore be clear about what successfully handling an exemplar demonstrates. We go on to examine the use of exemplars for not only specifications (an end product of requirements engineering), but also for the requirements engineering process itsel...

This handbook is about writing software requirements specifications and legal contracts, two kinds of documents with similar needs for completeness, consistency, and precision. Particularly when these are written, as they usually are, in natural language, ambiguity---by any definition---is a major cause of their not specifying what they should. Simple misuse of the language in which the document is written is one source of these ambiguities.

Formal specification techniques provide precise and analyzable software specifications. However, formal notations provided by most formal specification techniques are not easy to use and understand for most people. Our approach counters this difficulty by visualizing formal specifications. In this paper, we use various diagrams to visualize a Z specification. In our work both static and dynamic aspects of formal specifications including complex constraints are included in the visualization scope. This is in contrast to other work that develops visual representations of formal specifications, without visualizing the complex constraints in the mathematical notation. Our work also supports a mechanical translation process from Z specifications to diagrams by providing transformation rules between the two representations. Representing a Z specification using various diagrams should enhance the readability and the understandability of the Z specification, and should make Z specifications mo...

ion. Requirements may be distinguished based on the abstraction level of their description. A requirement may be further defined by add new details defined in more specialized subrequirements. Through specialization of abstract requirements, or generalization of detailed requirement, a requirement abstraction hierarchy can be defined. . Development p roperties . Requirements may be distinguished based on their development properties. For example, a requirement may have just been proposed. Late r, it may be accepted or rejected. . Representational properties. Requirements may be distinguished based on their representation. A requirement may begin as an informal sketch, then become a natural language sentence (e.g., "The system shall ..."). Finall y, more formal representations, such as UML, Z, or predicate cal- Requirements Interaction Management - Definition and scope 6 1999 William N. Robinson Requirements Interaction Management GSU CIS 99-7 culus, may be used to express a requir...

Abstract. The goal of our study is to evaluate the effect on program comprehension of three factors that have not previously been studied in a single experiment. These factors are programmer expertise (expert versus novice), programming task (documentation versus reuse), and the development of understanding over time (phase 1 versus phase 2). This study is carried out in the context of the mental model approach to comprehension based on van Dijk and Kintsch’s model [(1983) Strategies of Discourse Comprehension. New York: Academic]. One key aspect of this model is the distinction between two kinds of representation the reader might construct from a text: (1) the textbase, which refers to what is said in the text and how it is said, and (2) the situation model, which represents the situation referred to by the text. We have evaluated the effect of the three factors mentioned above on the development of both the textbase (or program model) and the situation model in object-oriented program comprehension. We found a four-way interaction of expertise, phase, task and type of model. For the documentation group we found that experts and novices differ in the elaboration of their situation model but not their program model. There was no interaction of expertise with phase and type of model in the documentation group. For the reuse group, there was a three-way interaction between phase, expertise and type of model. For the novice reuse group, the effect of the phase was to increase the construction of the situation model but not the program model.

This article summarizes the state of the art in software specification & design methods, which assist developers in constructing the models of the problem domain and of the system and in writing requirements and design specifications. The typical methods such as structured methods and object-oriented methods are summarized. The new discipline called "Method Engineering", engineering for constructing methods, is briefly presented

this paper, we describe REBUS and aspects of its development and use. Section 2 discusses current approaches to software requirements specification and explains our choice of requirements specification for the prototype process. The next three sections discuss the development of REBUS: Section 3 presents goals for the prototyping experiment and sets out requirements for the process program, Section 4 presents product and process models for REBUS, and Section 5 describes the design and implementation of REBUS in APPL/A. Section 6 then describes our experience in using REBUS. Finally, Section 7 provides a discussion of our experience and the issues raised, and Section 8 summarizes our conclusions and indicates future work.

Abstract not found

It is a frequently reported effect of applying requirements specification languages that the formalization of informal requirements leads to the detection of defects such as omissions, conflicts, and ambiguities. However, there is little quantitative data available on this effect. This paper presents an empirical study with requirements specification languages, which addresses two research questions. First, which types of defects are detected by a requirements engineer during the development of a requirements model, and second, what happen to those defects that are not detected? The results indicate that ambiguities require special care during formalization, because they are less frequently reported than other types of defects. Instead, ambiguities tend to become often disambiguated unconsciously, which is a serious problem, because implicit assumptions are more likely than in our study to be wrong when the system is more complex. Moreover, ambiguities are misinterpreted more often than other types of defects. Finally, ambiguities, if noticed, require immediate clarification. 1.