Clear justification of modeling decisions for goal-oriented requirements engineering

Representation and reasoning about goals of an information system unavoidably involve the transformation of unclear stakeholder requirements into an instance of a goal model. If the requirements engineer does not justify why one clear form of requirements is chosen over others, the subsequent modeling decisions cannot be justified either. If arguments for clarification and modeling decisions are instead explicit, justifiably appropriate instances of goal models can be constructed and additional analyses applied to discover richer sets of requirements. The paper proposes the “Goal Argumentation Method (GAM)” to fulfil three roles: (i) GAM guides argumentation and justification of modeling choices during the construction or critique of goal model instances; (ii) it enables the detection of deficient argumentation within goal model instances; and (iii) it provides practical techniques for the engineer to ensure that requirements appearing both in arguments and in model instance elements are clear.

Automated analysis of the SCR-style requirements specifications

The SCR(Software Cost Reduction)requirements method is an effective method for specifying software system requirements.This paper presents a formal model analyzing SCR-style requirements.The analysis model mainly applies state translation rules,semantic computing rules and attributes to define formal semantics of a tabular notation in the SCR requirements method,and may be used to analyze requirements specifications to be specified by the SCR requirements method.Using a simple example,this paper introduces how to analyze consistency and completeness of requirements specifications.     

Automated structural analysis of SCR‐style software requirements specifications using PVS

The importance of effective requirements analysis techniques cannot be overemphasized when developing software requiring high levels of assurance. Requirements analysis can be largely classified as either structural or functional. The former investigates whether definitions and uses of variables and functions are consistent, while the latter addresses whether requirements accurately reflect users' needs. Verification of structural properties for large and complex software requirements is often repetitive, especially if requirements are subject to frequent changes. While inspection has been successfully applied to many industrial applications, the authors found inspection to be ineffective when reviewing requirements to find errors violating structural properties. Moreover, current tools used in requirements engineering provide only limited support in automatically enforcing structural correctness of the requirements. Such experience has motivated research to automate straightforward but tedious activities. This paper demonstrates that a theorem prover, PVS (Prototype Verification System), is useful in automatically verifying structural correctness of software requirements specifications written in SCR (Software Cost Reduction)‐style. Requirements are automatically translated into a semantically equivalent PVS specification. Users need not be experts in formal methods or power users of PVS. Structural properties to be proved are expressed in PVS theorems, and the PVS proof commands are used to carry out the proof automatically. Since these properties are application independent, the same verification procedure can be applied to requirements of various software systems. Copyright © 2001 John Wiley & Sons, Ltd.     

Contributions from cognitive engineering to requirements specifications for complex sociotechnical systems: A case study in the context of healthcare in Brazil

This paper aims at presenting a case study on the use of human factors and ergonomics to enhance requirement specifications for complex sociotechnical system support tools through enhancing the understanding of human performance within the business domain and the indication of high‐value requirements candidates to information technology support. This work uses methods based on cognitive engineering to build representations of the business domain, highlighting workers’ needs, and contributing to the improvement of software requirements specifications, used in the healthcare domain. As the human factors discipline fits between human sciences and technology design, we believe that its concepts can be combined with software engineering to improve understanding of how people work, enabling the design of better information technology.     

Deriving problem frames from business process and object analysis models

While Problem Frames have become a useful approach for requirements analysis, little research has been made to explore how to derive them from a complex problem context. The purpose of this paper is to propose such an approach. The proposed approach consists of three steps to drive the development of Problem Frames. In the first step, business process models are developed to capture the behavioural view of the problem context. In the second step, object analysis models are used to capture the structural view of the problem context. Together, these two views collectively and adequately capture the early context knowledge. These two types of model will then be used in the third step to construct context diagrams and derive Problem Frames. A complex real‐world problem – equity trading problem – is used to illustrate this approach.     

Goal-Oriented Requirements Engineering: A Unifying Framework

The study of contemporary requirements engineering (RE) methodologies indicates that modelling of organisational goals constitutes a central activity of the RE process. In particular, goals provide the rationale and drive the elaboration of the requirements that operationalise them. They also provide the criteria against which the completeness and correctness of the requirements specification is validated. In other words, requirements implement goals in the same way that programs implement design specifications. Despite the significance of goals in RE, research in the field is fragmented. No research has so far taken place in order to define the overall role that goals play in RE. This paper puts forward a unifying view of goal analysis in the context of RE. This allows the identification of similarities and differences between the different conceptions of goal used by different approaches and promotes the understanding of the overall role of goal analysis in RE. Based on this understanding the various approaches can be put together, thus leading to a stronger goal-driven RE framework that takes advantage of the contributions from the many streams of goal-oriented research.     

Program Synthesis from Formal Requirements Specifications Using APTS

Formal specifications of software systems are extremely useful because they can be rigorously analyzed, verified, and validated, giving high confidence that the specification captures the desired behavior. To transfer this confidence to the actual source code implementation, a formal link is needed between the specification and the implementation. Generating the implementation directly from the specification provides one such link. A program transformation system such as Paige's APTS can be useful in developing a source code generator. This paper describes a case study in which APTS was used to produce code generators that construct C source code from a requirements specification in the SCR (Software Cost Reduction) tabular notation. In the study, two different code generation strategies were explored. The first strategy uses rewrite rules to transform the parse tree of an SCR specification into a parse tree for the corresponding C code. The second strategy associates a relation with each node of the specification parse tree. Each member of this relation acts as an attribute, holding the C code corresponding to the tree at the associated node; the root of the tree has the entire C program as its member of the relation. This paper describes the two code generators supported by APTS, how each was used to synthesize code for two example SCR requirements specifications, and what was learned about APTS from these implementations.