Automating Scenario-Driven Structured ... - Semantic Scholar

Automating Scenario-Driven RE

2/7/2000

Automating Scenario-Driven Structured Requirements Engineering Hong Zhu School of Computing and Mathematical Sciences, Oxford Brookes University, Gipsy Lane Campus, Gipsy Lane, Headington, Oxford, OX3 0BP, Email: [email protected] Lingzi Jin Cherwell Scientific, Oxford Science Park, Oxford OX4 4GA, UK, Email: [email protected] Abstract Scenario analysis has been widely perceived to be able to play two important roles in requirement engineering. Firstly, it is a vehicle of separating concerns in the elicitation of users' requirements. Secondly, it is a means of validating specified requirements. However, there are a number of key activities in scenario analysis that demand automated tool support to make the method practically applicable. Such activities include: (a) the analysis of consistency and completeness among various scenarios, (b) the analysis of the consistency and completeness of a set of scenarios with respect to requirements models, (c) the synthesis of requirements models from a set of scenarios, and (d) the generation of scenarios from requirements models for requirements validation. In this paper, we present an automatic toolkit that supports these activities. We discuss how the idea of scenario analysis can be adapted to a structured analysis method, how to describe scenarios and how to support scenario analysis activities through automated tools. We also report some case studies with the toolkit. Keywords: Requirements engineering, automated tool, scenario analysis, consistency, completeness, requirements model synthesis, formal specification, Z language.

1. Introduction Requirements analysis and specification are concerned with eliciting, clarifying, documenting and validating users' requirements of computation systems [1]. Many studies have shown that errors made at this stage are very costly, even impossible, to rectify. Neglected or only partially completed requirements analysis tends to lead to problems later in development. It is perceived as an area of growing importance. In the analysis and specification of users' requirements, software engineers are often confronted with difficulties due to the complexity of the problem, the communication barriers between people of diverse backgrounds, the inconsistency and incompleteness of information and frequent changes of users' requirements. A number of proposals have been advanced in the literature to overcome these difficulties. These include the deployment of various vehicles for separation of concerns, the design and use of various kinds of representations and notations for the description of users' requirements, and the development of software tools to support requirements engineering process. In this paper, we report our researches on automated tool support for requirements engineering and present an automated toolkit -- RASS system*. The paper is organised as follows. Section 2 gives an overall picture of the research by presenting the process model underlying the automated toolkit, the requirements definition language, and the overall structure of the toolkit. Section 3 focuses on the toolkit's support to scenario driven requirements elicitation and analysis. Section 4 presents the facilities provided by RASS to support the integration of multiple views at model construction and analysis stage. Section 5 is devoted to the tool support of requirements validation and testing. Section 6 studies the automatic generation of formal specifications. Section 7 reports case studies with the toolkit. Section 8 is the conclusion of the paper.

2. Process Model, Language and Automated Toolkit This section gives an overview of the researches by presenting the process model, the requirements definition *

An earlier version of the system was called NDRASS.

H. Zhu and L. Jin

-- 1 --


2/7/2000

language, and the structure of the toolkit, and discusses their interrelationships.

2.1 The process model We regard requirements engineering as the process that starts with informal statements of users' requirements and targets at producing a requirements specification in a formal notation. In this course, software engineers not only need to formalise the information, but more importantly to elicit the necessary information from the users and domain experts. To bridge the vast gap between the two ends, we proposed the POT (Progressive and Orderly Transition of representation) process model of requirement engineering [2, 3, 4]. It divides the process into a number of iterating phases. Each phase aims at increasing the formality of representation by a small step with the help of users' interactions and supported by automated tools. The process includes the following typical phases. z Initial statement: an initial statement of user's requirements is produced, which is usually in a natural language; z Requirements elicitation: users' requirements are elicited and described, say, in the form of scenarios+. Conflicts and inconsistency between the requirements are detected and resolved; z Model construction: models of users' requirements are constructed, analysed and validated, where a model should be in the form of diagrams and other formally defined notations, but may contain terminology informally defined, even undefined. Such models are considered as semi-formal due to the coexistence of formally defined notations and informally defined and undefined contents; z Knowledge formalisation: the informally defined and undefined terminology used in the models are formally defined and specified in the first order logic or other mathematical notations in this phase. These formal definitions constitute the knowledge base of system specific knowledge and domain knowledge; z Formal specification: formal requirements specifications are produced according to the models of users' requirements and formally defined system specific knowledge and domain knowledge. As the formality of representation increases, more and more formal checking of consistency and completeness can be performed, which may result in backtracking to earlier phases and iteration. The POT process model is generic and independent of the analysis method. In fact, two experiments have been successfully conducted. One to apply the process model to object-oriented analysis and another to structured analysis. Consequently, two software toolkits have been developed, see [3] for more details. In this paper, we only discuss the researches on tool support of structured analysis.

2.2 Requirements Definition Language RDL-2 The RDL-2 language and its earlier version NDRDL [2] attribute entity are based on the classic methods of structured analysis, multiple relation see e.g. [5]. In addition to an informal statement of users' relationship requirements, a requirements definition in RDL-2 contains unique relation three diagrams and three dictionaries. The diagrams Figure 1. Notations of entity-relationship diagrams include an entity-relationship diagram (ERD), a data flow diagram (DFD) and a state transition diagram (STD), see data source or sink process Figure 1 and Figure 2 for the notations. The set of dictionaries includes a data dictionary, a relationship data storage data flow dictionary and a process dictionary. The data dictionary defines the structure and usage of data in a required Figure 2. Notations of data flow diagram system. An entry in a data dictionary consists of four fields. The first is the name of the data to be defined. The second is the informal description of the data in natural language. The third is a formal description of the data. It gives the type, hence the structure, of the data. The type of the data is represented similar to a data type in programming languages. The fourth is the constraint on its value. It is in the form of a first order predicate. The relationship dictionary defines the relationship between entities. An entry in a relationship dictionary contains four fields. The first field is the name of the relationship. The second field gives the entities of the relationship. The third field is an informal description of the relationship in natural language. The fourth field is a formal definition of the relationship written as a predicate. +

In this paper, we use the word 'scenario' as a synonym of 'use case'. More discussions are given in section 3.

H. Zhu and L. Jin

-- 2 --


2/7/2000

The process dictionary provides definitions of processes. An entry in a process dictionary consists of five fields. The first is the name of the process to be defined. The second and the third are the input and output of the process, respectively. It should be noted that the data flows into or from a data store are not considered as input or output of processes because data stores are considered as globally accessible. The fourth field is an informal description of the function of the process. The fifth is the formal definition of the process in the form of a predicate that relates the output to the input with references to data stores and defines the update to data stores.

2.3 The structure of RASS system In addition to the facilities that are provided by existing CASE tools, we are more concerned with the following activities in requirement engineering: z the automatic transformation of information from one representation form into another, for example, from scenarios into requirements models, from requirements models into a well organised documentation of software requirements - the requirements definition, and from requirements definitions into formal specifications; z the automatic analysis of the properties of the information and its representations, such as the consistency and completeness of information at each phase; z the validation and verification of the consistency between different views and across different representations in different phases. As shown in Figure 3, the RASS system consists of a set of editors, a set of information management subsystems, a set of automatic consistence and completeness checkers, and a set of automatic synthesisers and generators. These tools are invoked through menu items in a tool bar in graphic user interface. They can be grouped into a number of subsystems to provide support to various phases and activities in requirements analysis and specification. The following briefly describe the functions of these subsystems. The scenario analysis support subsystem supports scenario driven requirements elicitation and analysis. It consists of (a) the diagram editors of various views of scenarios; (b) automatic checkers of the consistency and completeness between various scenarios, (c) the automatic generator of requirements models from a set of scenarios, and (d) the automatic checkers of consistency and completeness between requirements models and a set of scenarios.

Project Database

Proj. Manager Graphic User Interface Modelling subsystem

Scenario analysis subsystem Diagram Editor

Scenario Data Manager

Knowledge acquisition subsystem

Diagram Editor

Requirement specification subsystem

Dict. Manager

Text Editor

Dictionaries

Informal Description

Model/Dict. Checker Scenario Descriptions

Scenario Database

Requirements Models Dict. Generator

Scenario Checker

Requirement validation subsystem

Synthesiser Spec. Generator Scenario/Model Checker

Test Adequacy Checker

Doc. Generator Test Set Generator

Formal Specification

Sets of Test Cases

Requirements Definition

Figure 3. Structure of the RASS system H. Zhu and L. Jin

-- 3 --


2/7/2000

The requirements modelling support subsystem supports the multiple view approach to requirements model construction. It includes the diagram editors for interactive editing of various views of requirement models, the automatic checkers of consistency between the views. The automatic generator of requirements models from a set of scenarios, and the automatic checkers of consistency and completeness between requirements models and a set of scenarios can also be considered as a part of this subsystem. The knowledge acquisition support system supports the acquisition of domain knowledge and system specific knowledge. It consists of the automatic generator of dictionaries, the dictionary management and editing subsystem, and the automatic checker of consistency and completeness between requirements models and the domain and system specific knowledge represented in the form of dictionaries. The requirements validation support subsystem supports the validation of software requirements. It consists of the automatic generator of test cases, the automatic checker of test adequacy, and the automatic checker of consistency and completeness between requirements models and scenarios. The requirements specification support subsystem consists of the text editor and the automatic generator of formal specifications in Z and the document generator for generating requirements definition in RDL. Figure 4 illustrates how the tools support the POT process model. Initial user's requirements statement

User's requirements

Text Editor

Scenario analysis

Diagram Editor

Scenario Description

requirements modelling

Model Synthesiser

Diagram Editor

ERD

Requirements validation

Scenario Consistency / Completeness Checker

Model Consistency Checker

Requirements specification

Dictionary Generator

Dictionary Frameworks

Test set Generator Specification Generator

DFD STD

Informal Description

Knowledge acquisition and formalisation

Dictionary Manager/Editor

Test Scenarios

Formal Specification

Dictionaries Test Adequacy Checker Model/Dict. Consistency Checker

Figure 4. Relationship between tools and the POT process model

3. Scenario Analysis Scenarios and use cases are vehicles for separation of concerns, e.g. [6, 7, 8]. They are concerned with situations that might reasonably occur in the operations of a system. One of the fundamental characteristics of scenarios is that they are mainly concerned with the use of the system. Though situations of uses are normally only related to a part of the system's functions, not every arbitrary subset of functions constitutes a meaningful scenario. A scenario should have the following characteristics. Agents: Agents refer to the users, equipment or software systems that involved in the operation of a system. A scenario must have a specific type of users, or a set of types of users, that participate in the use of the system in the scenario, and/or a subset of the equipment in the environment system that are involved in the operation of the system; Purpose: a scenario is the set of situations when the user or users use the system with a specific goal or purpose; Condition: a scenario must occur under certain operational conditions and at certain states of the environment system. H. Zhu and L. Jin

-- 4 --


2/7/2000

For example, consider a personal bank account management system. An example of scenario is that a customer wants to withdraw some money from his account. Here, a customer of the bank is an agent. Other types of users of the system can be managers of bank branches, and clerks of the bank. In this scenario, the goal or purpose of using the system is to withdraw money from an account. Other purposes can be to deposit, to make an enquiry about the balance of the account, or even to try to get money from another customer's account illegally. The condition that a customer uses the system also varies. For example, a customer may try to withdraw an amount of money in excess of the balance in the account, or want to withdraw less than the balance, etc. By identifying a set of scenarios, i.e. a set of such situations of common characteristics, and working on each scenario separately to elicit information, a complicated problem can be decomposed systematically and naturally. Information from different sources can be elicited independently. A requirements definition can be synthesised from the descriptions of the scenarios. Secondly, by analysing the consistency between requirements of different scenarios, conflicts between different types of users, different use purposes and different operation conditions can be discovered. Moreover, scenario analysis also provides a basis for requirements validation. By analysing the consistence and completeness of requirements definition with respect to a set of well defined scenarios, the requirements definition can be validated and verified. In recent years, the role of scenarios in requirements elicitation, modelling and analysis has been more and more widely recognised [9]. However, scenario driven requirements analysis has been studied mainly in the context of object-oriented analysis methods. The use of scenarios in requirement analysis originates from Objectory# [6,8], and was used in OBJ [6] and UML []. The first process model of use case driven object oriented analysis was proposed in [8]. This model was further developed in [11] with emphasis on the importance of synthesis of requirements models from scenarios. In [12], the effectiveness of scenario analysis in fault detecting and correction was investigated. An early case study of application of scenario analysis in industrial environment was reported in [13]. A formal approach to scenario generation and analysis was proposed and investigated in [14]. In recent years, the use of scenarios in requirements engineering has been investigated more systematically, for example, by the CREWS projects [15, 16]. A framework of scenario classification guidelines was proposed for the systematic identification of scenarios. A tool for semi-automatically generating scenarios has been implemented [17]. A scenario driven requirements engineering methodology is emerging, which is user centred with emphasis on the role of scenarios in requirements process and systematic deployment of scenario analysis techniques. For large software systems, there might be a large number of scenarios. Dealing with a large number of scenarios demands tool support. Among various activities in scenario analysis, we believe that the most crucial activities that demand tool support include: the analysis of consistency among a set of scenarios, the analysis of consistency and completeness of a scenario with respect to requirements models, the synthesis of requirements models from scenarios, and generation of a set of scenarios from requirements models for validation. Unfortunately, existing software tools such as DOOR and ROSE have not provided such supports to these activities. Supporting these activities is the main feature of RASS that distinguished the tool kit from existing software tools. This section further discusses the fundamental concepts underlying RASS tools for scenario driven requirements analysis. Details about the implementation and algorithms can be found in [23].

3.1 Description of scenarios in RDL-2 An appropriate representation of scenarios should satisfy at least two basic requirements. Firstly, it should be simple and easy for software engineers and users to understand. Secondly, it should facilitate automatic analysis of scenarios as well as the construction of requirements models. Although various representation forms have been proposed in the literature, unfortunately, few satisfy both of the requirements. For example, in the HCI area, scenarios often appear in the form of activity lists, which are lists of sentences in natural languages [18]. In [6] and [19], a tabular notation is used. In [20], the use of structured natural language is proposed. These informal and tabular representations are simple and easy to use, but do not facilitate formal analysis. In [14] scenarios are described in a formal language so that verification techniques can be applied to check the consistency between scenarios. In [21], use cases were first described in a tabular form, called partial use case table, and organised into a tree to form a complete use case. Use cases were further linked together by temporal #

The authors of Objectory and UML use the term 'use case' in the sense of 'scenario' of this paper, and use the word 'scenario' as a special case of use cases and only allow a linear sequence of activities occur in a scenario. In this paper, instead of taking such a syntactic discrimination between 'scenario' and 'use case', we regard them as synonymous.

H. Zhu and L. Jin

-- 5 --


relations. Then, such descriptions were transformed into Petri nets manually to facilitate formal analysis. Although such formal representations facilitate formal analysis, they are difficult for software engineers and users to use.

2/7/2000

Terminator Data store

State

Process

State transition

Data flow

Virtual state transition

Virtual data flow Another very important requirement for scenario representation is that it (b) Extended state transition diagram should facilitate the integration of (a) Entended data flow diagram scenario-driven requirements analysis Figure 5. Notations of extended DFD and STD into other well established requirements engineering methodologies such as multiple views and structured analysis. The notion of scenario has been incorporated in the study of multiple views either explicitly or implicitly. In [21], a use case is described in the form of trees of tables as domain expert-centred viewpoint and equivalently in Petri net as analyst-centred viewpoint, while in [17, 22], a view also has the characteristic of specific user agents, use purpose and operation condition. An open problem in the research on scenario-driven requirements engineering is how to integrate the notion of scenario and multiple views into the practically widely used method of requirements analysis, such as structured analysis, so that practical tools can be developed.

In RDL-2 [], a scenario description consists of a name and a number of the scenario, an introduction in natural language and three views of the scenario. These views are extensions of ERD, DFD, and STD. In the design of RDL-2, we recognised some special requirements for scenario description that are not satisfied by the existing models. Among the most important facilities that existing requirements models lack are the facilities to describe information that is vague or unknown in a scenario and the facilities to describe the relationships between scenarios. Due to the restriction of a scenario on a particular use purpose of the system and the limitation of the users involved in the scenario, the description of a scenario may need to describe vague information about the system's functional, behavioural and other requirements. Such information could be unknown for its detail to the people involved in the elicitation of the requirements, or even not directly relevant to the scenario, hence should be excluded. However, that information should be elicited and described in other parts of the system through another scenario. For instance, consider a banking system and the scenario that a customer deposits into an account by presenting a cheque. From a customer's point of view, such a scenario consists of the process of filling a pay-in slip, presenting the cheque and pay-in slip to the cashier, and then somehow the correct amount of money will be added to his account within a certain period of time. However, how the Customer Cheque received money comes to his account is unknown to Cheque the customer. In fact, the customer is Fill pay-in slip (cheque information) probably not interested in the detailed process Fill pay-in after the paying in activity as long as the slit correct amount of money is added into the account within an acceptable period of time. Pay-in slip Hand in at cashier desk Without a facility to describe that some (cheque, pay-in slip) Hand in at process is going inside the system that finally cashier desk leads to the adding of money to the account, one either has to describe the detailed process Account No., not directly related to the scenario, or results Amount in a collection of unrelated pieces of Deposit information that may not make sense and could hardly be considered as a partial model. Deposit Account No., Account No., The description of a scenario should therefore (Account No., Amount) balance balance not just simply delete irrelevant information Account Cheque processed from a requirements model. In RDL-2, we database introduced the notion of virtual data flow into the data flow description of scenarios and the Figure 6. Example of descriptions of scenario using virtual notion of virtual state transition into the state data flow and virtual state transition transition description of scenarios as such a H. Zhu and L. Jin

-- 6 --


2/7/2000

facility. Virtual data flows and virtual state transition are depicted as dashed arrows in diagrams, see Figure 5. Figure 6 gives the data flow and state transition descriptions of the scenario of paying-in-by-cheque. In an extended data flow diagram, a dashed arrow means that the need of a data flow path in the whole system is recognised but its details are not clear or not relevant in this scenario. Therefore, it represents a path in the data flow model of the whole system. Similarly, a dashed arrow in an extended state transition diagram means that the need of a state transition or a sequence of state transitions in the whole system is recognised and represents a path in the state transition model of the whole system. The introduction of virtual data flow and virtual state transition, thus, also provides a facility of describing the relationships between scenarios. For example, a scenario describing how a cheque is processed would relate to the scenario of paying-in-by-cheque through the virtual state transition and virtual data flow in Figure 6. Such relationships cannot be described in other existing scenario representations, although UML's use case diagram can specify the 'include' and 'extend' relationships between use cases.

3.2 The process model of scenario analysis As discussed in section 3.1, scenario analysis is a user centred process that can play an important role in requirements engineering. A process model of scenario analysis is depicted in Figure 7. It consists of the following interactive and iterating activities. Identification of scenarios: a set of scenarios is identified by analysing the agents, use purposes and operational conditions in the uses of the system. A number of approaches to the identification of use scenarios have been proposed in the literature, such as [8,17].

Identify scenarios

Scenario log

Elicitation of information and description of scenarios: for each scenario, the requirements in the scenario are elicited and described so that further analysis of scenarios can be conducted on the basis of the description. Analysis of the consistency and completeness: once use scenarios are described, the consistency and completeness of the information contained in the scenarios are analysed. If the scenarios are inconsistent, it will backtrack to the information elicitation and scenario description to resolve the conflicts. If incompleteness is discovered, it will backtrack to the scenario identification to identify new use scenarios that cover the missing situation. Synthesis of requirements models: once a complete and consistent set of scenarios are well defined and formally described, requirements models can be synthesised from the set of use scenarios. Such models are required to be consistent with the scenarios and contain all the information from the scenarios, but they must not contain any information that can not be inferred from the information contained in the scenarios.

Elicit information & describe scenarios Incomplete

Inconsistent Analyse scenario consistency

Analyse scenario completeness

Scenario descriptions

Synthesise requirements models from scenarios

Modify requirements models

Inconsistent

Requirements models

Validate models against scenarios

Analyse validation adequacy

Incomplete

Figure 7. A process model of scenario driven requirements engineering

Validation of requirements models: requirements models are subject to modifications and can also be constructed manually rather than automatically synthesised from a set of scenarios. In such cases, the requirements models should be validated against the scenarios by analysing if the requirements models are consistent with respect to scenarios. Additional scenarios can also be identified and described for the purpose of validating requirements models. The adequacy of such validation should also be analysed, for example, by checking the completeness of the scenario with respect to the requirements models. H. Zhu and L. Jin

-- 7 --


To support these activities, RASS provides scenario editing tools, scenario consistency and completeness checking tools, and requirements model synthesis tools, see Figure 8.

3.3 The notions of consistency and completeness There are two notions of consistency related to scenarios. One is the consistency of a scenario with respect to a requirements model. The other is the consistency among a set of scenarios. These notions of consistency have their own uses in requirements analysis. Both of them can be automatically analysed by RASS tools.

2/7/2000

Scenario analysis tools Scenario editing tools Scenario management tool

The consistency between a scenario and a requirements model is a Figure 8. Scenario analysis tools in RASS property that the information contained in the scenario does not conflict with the requirements model. Since a scenario is essentially a special case of the requirements model, consistency means the information contained in a scenario is a subset of the information contained in the model. This property is can be formally defined and automatically analysed, see [23] for detail. For example, the entity-relationship diagram (a) in Figure 9 is not consistent with the entityrelationship diagram (b) because the edges between entity A and relationship R are different. This notion of consistency enables us to automatically validate a requirements model against a set of well defined scenarios. If a requirements model is consistent with respect to a set of scenario descriptions, then the requirements model is valid with respect to the scenarios. Otherwise, errors a b are found in the requirements models or the scenarios. Such validation is proved effective in our case studies of the RASS tool kit. It is particularly A A useful when the user changes the requirements by modifying a description of a scenario. Automatic analysis of consistency between the modified R R scenario and the existing requirements models enables software engineers to identify the required modifications on the models. Hence the impact of B B the modification can be identified. c

d

e

d A set of scenarios is consistent if the scenarios do not contain conflict information among themselves. This notion of consistency can be formally (a) (b) Figure 9. Example of defined by using the notion of consistency between a scenario and a inconsistency between ERDs requirements model, because a set of scenarios is consistent if and only if there is a requirements model that all scenarios in the set are consistent with respect to the model. However, this property can be automatically analysed with out to construct the requirements model first. Checking the consistency among a set of scenarios is particular useful during requirements elicitation stage when users express their requirements through scenarios. Conflict requirements can be identified and resolved at very early stage without any effort of constructing a requirements model.

When a requirements model is validated against a set of well defined scenarios, the question arises of how adequate such a validation is. This leads to the notion of completeness of a set of scenarios with respect to a requirements model. It means that all the information contained in the model is covered by at least one scenario. Therefore, checking the consistency against the set of scenarios covers all the information contained in the model. In this sense, checking the completeness of a requirements model against a set of scenarios is checking the adequacy of validation. On the other hand, checking such completeness also means checking if a requirements model contains information not contained in the scenarios. Assuming a set of scenarios is complete in the sense that it already contained all the information of the required system (this second notion of completeness is discussed in next subsection), incompleteness then means that the model must contain H. Zhu and L. Jin

-- 8 --


2/7/2000

unnecessary or incorrect information. Therefore, checking completeness is also an important part of the validation of requirements models. This notion of completeness is formally defined in [23].

3.4 Synthesis of requirements models Given a set of descriptions of scenarios, to synthesise a requirements model we require that the result should include all the information contained in the scenarios, but contain no information that cannot be inferred from the scenarios. The result model should also be consistent with respect to all of the scenarios. It was proved that from any consistent set of entity-relationship diagrams, we can always synthesise an entity-relationship model. However, due to the existence of virtual flows, consistency is not sufficient for synthesising a data flow model, nor a state transition model, from a set of scenario descriptions. This is caused by the incompleteness of the information contained in the scenario descriptions. For example, a data flow scenario description contains a virtual flow, but there no scenario in the whole set contains further information about the data flow. This leads to the second notion of completeness, i.e. the self-completeness of a set of scenarios. This notion of completeness was also formally defined. It was proved that a data flow model M can be uniquely synthesised from a set of scenarios that is consistent and complete with respect to M, if and only if the set of scenarios is consistent and self-complete. A similar theorem holds for state transition diagrams. An example of the synthesis of a state transition diagram from scenarios is given in Figure 10. The scenarios A, B and C constitute a consistent and self-complete set of scenarios. But, any proper subset of the scenarios is not self-complete though consistent. The set of scenarios is consistent and complete with respect to the synthesised model. begin

begin

begin

F1

begin F1

F1 F4

a

a

a P2

P1

b

P1

b

b

b F2

P3 P4

c P4

P3 c

(a) Scenario A

F2

F3

F3

F3 exit

P2

P1

F4

F3

(b) Scenario B

F5 exit

exit (c) Scenario C

F3

P3 c

exit F5

(d) Synthesized model

Figure 10. Example of the synthesis of a state transition diagram from scenarios

4. Integrating multiple views The method of multiple views was proposed as a vehicle for separation of concerns to ease the communications between people and to handle the complexity of problem [24, 25]. The fundamental concept is the use of a number of models and notations to specify a system from different perspectives [26,27]. Each perspective is the perception of the problem domain from the viewpoint of a particular stakeholder group involved in requirements engineering. Such a stakeholder group can be managers, different system development professionals, and various end-users. Each view is a simplified model represented in the stakeholder's knowledge and language, hence comprehensible by the stakeholder. It is in this way that the approach of multiple views separates concerns. Therefore, a characteristic of multiple views is perhaps the use of a number of different notations to specify a system from different perspectives [25, 27, 28]. Inevitably, the different perspectives of these stakeholders intersect, hence giving rise to the possibility of inconsistency between views. Due to the differences in the language and knowledge used in various views, it is difficult to detect and manage inconsistency and conflicts between the models. In [25, 29], a framework called ViewPoint was proposed for expressing the relationships between multiple views and to handle inconsistency. This work was further developed in [30] by proposing a weakened form of classical logic, called quasi-logic, for reasoning and analysing inconsistent formal specifications. Readers are referred to [31] for a review and comparison of various multiple view approaches. In addition to the model generators described in the previous section, RASS also provide tools for manually constructing and modifying requirements models. In the development of RASS system, we identified three types H. Zhu and L. Jin

-- 9 --


2/7/2000

of possible tool supports to the integration of multiple views: (a) checking consistency between views, (b) tracking the same piece of information between different views, (c) transforming information contained in one view into another. No matter whatever the type of support a tool provides, the foundation of such a tool is the consistency constraints imposed on the views. Therefore, the RDL-2 language not only provides three different views of requirements, but also explicitly specified a set of consistency and completeness constraints on the diagrams and dictionaries, see Table 1. These constraints form the foundation of automatic tools in RASS for supporting the integration of multiple views, which include tools for checking the consistence between the views and dictionaries, and tools that automatically generate dictionaries from diagrams. Table 1. Consistency and completeness constraints Views

Constraint

DFD/ ERD

The collection of data in a DFD must be the same as the collection of data represented as the entities and their attributes in the corresponding ERD. The set of processes associated with the arcs in a CFD must be the same as the set of processes in the corresponding DFD.

CFD/ DFD Any sequence of events in a CFD must satisfy the permissible condition, i.e. an event can happen only if its data are all available. CFD/ ERD

Any data used in a CFD must be contained in the collection of data in the corresponding ERD.

ERD/ DD

Every entity in an ERD must be defined in the data dictionary. If an entity has a set of attributes, the definition of the entity in the data dictionary must also specify the attributes accordingly.

ERD/ RD

Every relationship in an ERD must be defined in the relationship dictionary with the same participant entities.

DFD/ PD

Every process in a DFD must be defined in the process dictionary that the signature of the process must be consistent with the data flowing inwards and outwards the process node.

5. Requirements validation The validation of requirements definitions is widely perceived as an area of great importance. Existing requirements validation methods fall into two classes, static testing and prototyping. Static testing is concerned with the review of requirements documents. Typical static testing methods include checklists guided inspection [] and structured walk-throughs in formal review []. They have been widely used in practice and claimed to be effective to detect errors. Prototyping involves developing and demonstrating prototype software to show if the software satisfies user's requirements. It is effective for validating user interface and certain specific features of the system, such as timing and scheduling aspects in real-time applications []. In comparison with the methods for testing other software artefacts such as executable code [], the methods for testing requirements are less systematic, less cost effective and less easy to apply. For example, it is a common problem that requirements documents are difficult to grasp, especially when without tool support, e.g. []. During the process of testing, the testers have to translate, in their mind, the static description of the requirements so as to visualise the dynamic behaviour of the described system. Such translations often have to co-ordinate information scattered over the requirements documents, especially when the system is described by multiple views [33, 25]. This process is further complicated due to the difficulty of casting two-dimensional diagrammatic descriptions into one-dimensional, temporal sequences of events. Not only is this process time consuming and expensive, but also its effectiveness is dependent on the experience and training of the human tester. There is no well-established method to specify, measure or control the strictness of such tests. Prototyping provides the tester with visualised demonstrations of a system's behaviour, which enables the examination of software's functions and behaviour to some extend. Prototyping is thus an effective testing method. It is costly, however, to develop prototypes that contain sufficiently accurate details of the requirements. The amount of detail that a prototype can demonstrate is usually very limited, hence it bounds the maximum level of testing strictness. There is no well-established method for determining, specifying and measuring the strictness of testing by prototyping. The potential application of scenario analysis in requirements validation has been recognised by a number of researchers [12, 23, ]. The basic idea is to check requirements in various scenarios or use cases that may occur in the operation of the software. As discussed in section 3, RASS provides automatic checks for the consistency H. Zhu and L. Jin

-- 10 --


2/7/2000

between a scenario description and requirements models. However, such consistency checks have some weakness. For example, to apply the method, there must be a set of scenarios that thoroughly covers the requirements models. The problem is how to chose scenarios and where the descriptions of scenarios come from. Obviously, use of the scenarios obtained during requirements acquisition is not an ideal solution especially when the requirements models are automatically generated from the scenarios, because validation should be independent of the production of requirements models. As a complementary to the above approach, a second approach to software requirements validation using scenarios was proposed and implemented [, ]. The basic idea was to select a set of test scenarios automatically and systematically according to the requirements models, and then, to generate readable descriptions of system's behaviour in each scenario for validation review. The following discusses two key issues related to this approach of requirements validation, i.e. how to select test scenarios, and how to generate detailed descriptions of system's behaviour for a given scenario.

5.1 Description of software behaviour The method is inspired by Human-Computer Interaction (HCI) task analysis techniques [18]. Tasks are about behaviour and it is the behaviour of the putative system described by the software requirements definition that, by being independently tested, provides one method of software validation at the requirements stage. The key idea of the proposed approach is to test the correctness of a requirements definition by analysing the behaviour of the specified system on a set of task scenarios. As all scenarios, a task scenario represents a set of situations that may occur in the use of the software system. However, as a test case, such task scenarios should be simple and can be clearly described so that system's behaviour can be effectively analysis and validated. The result of such behaviour analysis is an activity list, which is a notion borrowed from HCI task analysis techniques but extended to describe system's behaviour. An activity list is a linear sequence of the events that happen inside the system in temporal order. In the design of the requirements validation tools, we identified the following aspects of software behaviour as the most important to be analysed during requirements validation: (a) how information is exchanged between components of the software and between such components and the agents in the system’s environment; (b) what sequence of computations are performed by each component; (c) how the software reacts to stimuli from its environment; and (d) how internal states of the software are updated and effect the behaviour of the system. Consequently, there are four types of actions used in the description of system's behaviour: (a) receiving or sending information from one agent to another; (b) obtaining information from internal state of the software; (c) updating the internal state of the software; (d) performing computation by a software component. An activity list is presented in the form of a sequence of simple sentences in structured natural language. An item in an activity list has the following structure: ::= [] [] where an agent or object can be a process, a data store, the user, or any agents in the environment. For example, the following sentence describes an activity. Process P sends data x of type real to the terminator display where x>0. agent

action

object

receiver

constraint

One of the most important advantages of activity lists is that a sentence in activity list combines relevant information originally scattered over the requirements definition documents in various diagrams and dictionaries. Information irrelevant to the scenario is filtered out. Therefore, when validating the behaviour of a specified system by reviewing the activity lists, the tester need not to search for all the information scattered over various diagrams and dictionaries, and to translate two-dimensional diagrams into temporal sequences of events. It is this characteristic of activity lists that differs from existing representations of scenarios such as diagrams e.g. [10, 8] and formal notations [14]. It thus offers a more testable description of system's behaviour so that formal review can be performed more effectively and efficiently. Figure 11 gives one of the rules of generating different types of activities and illustrates how information scattered over various parts of a requirements definition are put together to form an item in an activity list. Details of the generation process and a complete set H. Zhu and L. Jin

-- 11 --


2/7/2000

of rules can be found in [38].

5.2 Selection of test scenarios As argued in [38,39], a path from the start node to an exit node in a state transition diagram corresponds to a task scenario. The sequence of events associated to the arcs on the path is the sequence of the sub-tasks performed by the software in the scenario. Each sub-task corresponds to a process in the data flow diagram. It is further decomposed into a sequence of actions of obtaining information for processing, the performance of computation in the process and finally followed by a sequence of actions delivering the computation results and/or updating

Data Dictionary a P

A

Name

Description

Form

Constraint

a

……

Ta

Pred_a

Process P update data a of type Ta in data store A where a satisfies the condition pred_a

Figure 11. Generating activity of updating data in data store

system state. The state transition conditions, which are the predicates associated with the arcs on the path, are the characteristic conditions of the scenario. Conversely, since the system is only allowed to perform activities as specified by the state transition diagram, any task is an instance of a path from the start node to an exit node. As all other testing methods, the effectiveness of testing depends on the selection of test scenarios. Three types of selection criteria have been investigated. Data flow testing methods select test scenario according to the data flow model of requirements definition. State transition testing methods are based on the state transition model. Entity testing methods are concerned with the entity relationship model. Table 2 gives the definitions of the adequacy criteria.

Data flow testing

Criterion

Table 2. Test adequacy criteria for testing software requirements Definition (A set t of test scenarios is adequate, if it satisfies the following condition)

Process coverage

For each process P in DFD, there is at least one path p in t such that p contains an arc to which an invocation of the process P is associated.

Terminator coverage

For each terminator M in DFD, there is at least one path p in t such that the activity list of p contains an activity that receives data from, or sends data to, the terminator M.

Data store coverage

For each data store R, there is at least one path p in t such that the activity list of p contains at least one activity that obtains data from R or updates data in R.

Data node coverage

For each node R in DFD, there is at least one path p in t such that the activity list of p contains at least one activity that obtains data from R or updates data in R.

Definition coverage

For all data flow d into a data store, there is at least one path p in t such that p covers d.

Use coverage

For all data flows d that flow out from a data store, there is at least one path p in t such that p covers d.

Input coverage

For all data flows d from a terminator, there is at least one path p in t such that p covers d.

Output coverage

For all data flows d into a terminator, there is at least one test case p in t such that p covers d.

Parameter coverage

For all data flows d into a process, there is at least one path p in t such that p covers d.

Data flow coverage

For all data flows d in DFD, there is at least one path p in t such that p covers d.

Elementary DF paths

For all elementary data flow paths q in DFD, there is at least one path p in t such that p covers q.

Simple DF paths

For all simple data flow paths q in DFD, there is at least one path p in t such that p covers q.

Cycle once DF paths

For all data flow paths q with no cycle occurs more than once, there is at least one path p in t such that p covers q.

H. Zhu and L. Jin

-- 12 --

Entity testing

State transition testing


2/7/2000

All DF paths

For all data flow paths q in DFD, there is at least one path p in t such that p covers q.

State coverage

For all states in STD, there is at least one path p in t such that p contains the state node.

Transition coverage

For all state transitions there is at least one path p in t such that p contains the state transition.

Elementary CF paths

For all elementary paths q of control flow in STD, there is at least one path p in t such that p covers q.

Simple CF paths

For all simple paths q of control flow, there is at least one path p in t such that p covers q.

All CF paths

For all paths q of a control flow that starts with the begin node and ends with an exit node, there is at least one path p in t such that p covers q.

Cycle once CF paths

For each path q in STD that starts with the begin node, ends with an exit node and contains no cycle more than once, there is at least one path p in t such that covers q.

Independent paths

For a state transition diagram of n nodes, a arcs and e exit nodes, t covers a complete set of a−n+e+1 linear independent paths of the STD.

Attribute coverage

For all attributes b in the ERD, there is at least one p in t such that p covers b.

Entity coverage

For all entities e in the ERD, there is at least one path p in t such that p covers e.

As shown in Figure 12, these adequacy criteria fall into a hierarchical structure of subsume relations, see [39] for proofs of the relations. All CF path coverage

Cycle once CF path coverage

All DF path coverage

Complete set of independent paths

Cycle once DF path coverage

Transition coverage

Simple CF path coverage

Simple DF path coverage

State coverage

Elementary CF path coverage

Elementary DF path coverage

Data flow coverage

Parameter coverage

Input coverage

Data node coverage

Input & output coverage

Output coverage

Terminator coverage

Process coverage

Attribute coverage

Definition & use coverage

Data store coverage

Definition coverage

Use coverage

Entity coverage

Figure 12. The hierarchy of test criteria

The current version of the RASS has implemented a test scenarios generation tool that automatically generates various sets of test scenarios according to the state transition testing criteria, see Figure 13. It also implemented a test adequacy measurement tool that measures test adequacy according to a subset of data flow test criteria, see Figure 14. As shown in Figure 15, the description of system's behaviour in each test scenario in the form of activity list can be display on screen for the tester to validate the requirements.

H. Zhu and L. Jin

-- 13 --


2/7/2000

Testing tools RASS tool bar Adequacy criteria for generating test scenarios Figure 13. Requirement validation and testing tools in RASS.

State transition test criteria

ata flow est criteria

Adequacy Figure 14. Measurement of adequacy according to data flow test criteria.

Test scenario number

Press buttons to browse test scenarios

Test set

Adequacy information Test scenario

Activity list

Figure 15. The display of activity list on screen.

A number of empirical studies of the tool shown that number of task scenarios and the lengths of activity lists are acceptable for the practical use of the testing method. Details of the empirical studies can be found in [39].

6. Generation of formal specifications Although existing formal methods suffer from scalability problems, the formal specification of small scale H. Zhu and L. Jin

-- 14 --


2/7/2000

computation problems has approached to a relatively mature state. A novel idea underlying the RASS project is to decompose the problem of specifying a large scale complicated software into a number of much simpler and smaller scale problems so that existing formal techniques can be applied to these localised and modularised formal specification problems. Finally, these pieces of formal specifications are put together by an automated tool to generate complete formal specifications of complicated and large scale software. There are two key problems that must be solved to achieve practical usability of the proposed approach. The first is how to decompose the problem. The second is how to compose the pieces together into a complete solution. This section discusses the RASS' solution to these problems.

6.1 Knowledge acquisition and formalisation RASS supports the decomposition of the formal specification through the knowledge acquisition tools, which consists of a set of dictionary generation tools and dictionary editing and maintenance tools. When successfully produced requirements models in the form of diagrams, software engineers can use dictionary generators in RASS system to automatically generate entries in the various dictionaries for each data, relationship and process occurred in the diagrams. These objects constitute the domain and system specific knowledge need to be further elicited. The dictionary generators also automatically fill certain fields in the dictionary with information already available from the diagrams, such as the parameters of processes, the attributes of entities, involved entities of an relationship, etc. The dictionary frameworks guide the knowledge acquisition process by promoting the software engineer to elicit information necessary to fill the fields that cannot be automatically filled from existing information contained in diagrams. Such information include: ¾The usage of the data, relationships and processes; ¾The constraints on the values of an entity; ¾The semantics of a relationship; ¾The semantics of a process; The knowledge acquisition process may start with informal expression of such information in the dictionary. The only information that needs to be formalised by software engineer is the constraints on the values of entities and the semantics of relationships and processes. First order predicates are used by RDL-2 language as the formal expressions of such information. They can be edited and input into the dictionary by RASS' dictionary management tools. Our case studies shown that the formalisation of such knowledge is usually localised and at a scale and complexity very easy to manage. For example, the formalisation of a process only involves the parameters of the process and the data stores that the processes access and updates. The meaning of such a process is the relationship between input parameter(s) and the output parameter(s). The use of first order predicates for such formal specifications has been well studied by formal methods.

6.2 Generating formal specifications The one of the main goals of formal specification in requirements engineering is to produce a highly readable specification in a mathematical notation that facilitates further development of the software. RASS selects the Z language [] as the notation of formal specification because it provides the schema facility to support modular descriptions of the state space and the operations and functions of a software system. The automatic specification generation tool in RASS generates five types of schemas according to the information contained in diagrams and dictionaries [41]. For each entity in the ERD, RASS generates an entity schema, which is used as a type definition to define (a) the types of state variables, the parameters, input and output of functions and operators, and the types of attributes in the definition of other entity schemas. Readers are referred to [41] for more details about the generation procedural. The system’s state space is determined by the data stores contained in the data flow diagram. For each data store in the DFD, a data store schema in the form given in is generated, where Type_of_Store is the schema name which defines the data type of the data store. It can be an entity name if the schema has been generated as described above. Otherwise, it will be a schema name that is generated according to the type specified in the data dictionary. When structured data types are used, intermediate schemas are generated. A relationship schema defines a relationship among entities. For each relationship R in the entity-relationship diagram, RASS generates a relationship schema.

H. Zhu and L. Jin

-- 15 --


2/7/2000 Operation dictionary

The functions and operations are also defined by schemas, which are called operation schema. They are generated according to the information contained in the DFD and operation dictionary. For each process in DFD, an operation schema is generated according to the rules illustrated in Figure 16.

Name Op

Input x1: Tx1

Output y1:Ty1

x1

x2

Description …

Op

DS1

DS1, ∆DS2 x1?:Tx1 y1!:Ty1

Op

In Z language, a software system is described as a function on the state space. This function is described by a control schema and generated according to the STD. The generation of system control schema is based on Fenton et al.’s theory of structured programming [] to improve the readability of generated Z code. According to the theory, every flow graph can be uniquely decomposed into a set of prime graphs so that it is the composition of the prime graphs by the nest and composition operations. The generation process consists of the following steps.

y2

y1

Definition P(x1,x2,y1,y2)

P'(x1?,x2,y1!,y2') DS2

Figure 16. Generation of operation schemas.

f1

p1

f2

f1

p2

A. A flow graph is normalised so that it contains only one start node and one exit node and every node has at most two outward arcs;

p1

B. The flow graph is decomposed into prime graphs such that the flow graph is represented as a decomposition tree. Given a flow graph, the decomposition starts with finding prime flow graphs. A prime flow graph is then reduced to an arc from the start node to the exit node of the prime sub-graph. Such a reduction process is recorded and a decomposition tree is constructed;

p2

p2

f

p2

f1

f2

(p1;f1)∨(p2;f2)

(p1; f1) ∨ (p2)

f1; f2

p1

f1

f 5

f2

p2

p1

F == ( f; p1) F == (f1;p1;f2;F) F == p1 ∨ (p2;f ;F) ∨(f;p2;F) ∨(f1;p2) Figure 17. Examples of prime flow graphs.

C. The Z description of the flow graph is generated according to the decomposition tree. We selected a set of prime flow graphs as well structured STD. Their readable Z descriptions are shown in Figure 17. Prime flow graphs not in the set are not considered as well-structured. Once such a prime flow graph is detected, the user is warned and asked if any modification will be made. If no any, a recursive Z description of the prime flow graph will be generated. The distinction of well structured from not well-structured sub-graphs enables us to control software complexity at requirements engineering stage and helps quality control. Figure 18 gives an example of the process of normalisation and decomposition of a state transition diagram. Figure 19 shows the window that contains a fragment of formal specification in Z generated by the tool.

a

b

b

c

c

c

d

d

d

f

e g

c

c

d f

e

g h

i (a) normalised

a a

f

e

a

a

a

h

i (b-1) finding prime sub-graph

i

i (b-2) reduction

i

i (b-3)

(b-4)

(b-5)

Figure 18. Example of Normalisation and decomposition of STD

H. Zhu and L. Jin

-- 16 --


2/7/2000

7. Case studies We conducted a number of other case studies with RASS system. The example systems used in the case studies cover a variety of application areas including management and information systems, realtime process control systems, signal processing and computer simulation. A brief discussion of them follows. (A) Wind Tunnel is an example of real-time signal processing software system. It is to be used to set a number of strain gauges in a wind tunnel, to monitor the pressure readings from the gauges over a period of time during a wind tunnel experiment and to calculate average pressures to produce a report. This example took a real problem statement from industry. Two scenarios were identified and used in the requirements analysis. One is the set up of the strain gauges. The other is the operation of the system and production of experiment report. (B) Banking is a simplified information management system of personal bank accounts. It provides the basic facilities of banking including deposit, withdrawal and enquiry operations on an account. Four scenarios were identified according to the bank customer's purposes of using the system. They are: (a) to deposit into an account, (b) to withdraw from an account, Figure 19. Formal specification in Z generated by RASS (c) to make an enquiry about an account. These three scenarios were described under the condition that the user inputs valid account number and PIN number. Another scenario is also identified to catch the situation that the user's input about account number and PIN number is not consistent with the information stored in the bank's database. (C) Elevator is real-time control software that controls the door of an elevator to ensure the safety in the operation of the elevator. Four scenarios were identified during requirements analysis. They are (a) to open the door when it is blocked, (b) to open an unblocked door, (c) to close a door when close button is pressed, (d) timed close of door. (D) Book Store Management is a management information system which automates the process of book ordering and distribution process. Four scenarios were identified and used in the requirements analysis process. Each scenario corresponding to one task of the system. They were: (a) to receive and verify customers' orders, (b) to assemble a number of customers' orders to make block purchase requests to the publishers of the book, (c) to produce invoices to customers and make payments to the publishers after receive the books from the publisher, (d) to receive payment from a customer and to ship the book(s) from the customer. (E) Gas Burner is a software system that monitors and controls the real-time operation of a gas burner to ensure its safety. Three scenarios were identified and used in the requirements analysis. They were: (a) the control of the start process of the gas burner, (b) the dynamic real-time monitoring of the operation of the gas burner, (3) the restart and emergent shut-down of the gas burner when a failure occurs. (F) Travel Agent is an information management system that deals with air ticket booking and flight line availability information. Three scenarios were identified for two types of users. One was for an airline carrier provider to update airline information. The other two were for a travel agent to make reservations and H. Zhu and L. Jin

-- 17 --


2/7/2000

cancellations of seats. (G) Mobile Phone is a real-time simulation systems which simulates the cellar network of mobile phones. It is the most complicated example in our case study. Four scenarios were identified. They are the scenarios for setting up the phone, receiving a call, making a call and handing over from one site to another during communications. More details about the case study can be found in []. Table 3 summarises the complexities of the requirements models generated in case studies. Table 3. Data about the requirements models generated in the case studies DFD complexity STD complexity ERD complexity Type Scenarios Nodes Flows States Transitions Attributes Entities Relationships

System Wind tunnel

Real-time signal proc.

2

9

9

8

7

5

2

0

Bank account

MIS

4

7

17

6

8

5

3

2

Elevator controller

Real-time control

4

4

4

12

16

2

3

2

Travel agents

MIS

3

12

20

16

16

13

4

3

Book store

MIS

4

8

8

10

12

28

8

6

Gas burner controller

Real-time control

3

7

9

24

29

8

1

0

Mobile phone

Real-time simulation

4

27

41

38

47

6

3

3

Postgraduate students of software engineering participated in the case studies. For each example system (except the mobile phone simulation system), the requirements models was first developed without scenario analysis by a group of students. Then, a separate group of students of similar background developed the requirements models with the assistance of scenario analysis tools. In all cases it was very clear that the scenario analysis approach was a much easier way to produce a good requirements model than to draw the diagrams directly from scratch. With the exception of the mobile phone simulation system, all the requirements models generated by the scenario analysis tools were compared with the models produced by hand without scenario analysis. In almost all cases, the models are consistent with each other. Only one model generated from scenarios was different from the model produced without scenario analysis, and we found errors in the model produced without scenario analysis. The extreme case was the mobile phone simulation system. After a number of attempts, the group of students failed to draw the models directly for the mobile phone simulation system and eventually gave up. However, the same group of students was successful in developing the requirements models by using the scenario analysis method and tools. For each case study, we generated a requirements definition in RDL and a formal specification in Z by applying the RASS tools.

8. Conclusion Our experiments with automated toolkit for requirements engineering indicates that a significant degree of automation can be achieved at requirements stage. Automatic tools can provide software engineers power to cope with difficulties in requirements elicitation, analysis and specification. We are planning further case studies of the toolkit in industry environment.

Acknowledgement The work reported in this paper was supported by the programmes of 8'th and 9'th 5-year plans of China and China National Science Foundation. The authors would like to thank those who participated in the implementation of the tool and the case studies, especially Mr. Q. Huo, Mr. C. Zhang, Mr. G. Bai, Dr. Z. Fei, Dr. L. Dong, Mr. D. Yang, Mr. J. Ding, Mr. Y. Bao, Mr. S. Sun, and Mr. S. Lin. The authors would like to thank Prof. Jiafu Xu of Nanjing University, Dr. Bob Champion of Oxford Brookes University, Prof. Dan Diaper and Prof. Martin Shepperd of Bournemouth University for their valuable comments on an earlier version of the paper and discussions on many related issues. H. Zhu and L. Jin

-- 18 --


2/7/2000

References [1] Stokes, D. A., Requirements analysis, in Software Engineer's Reference Book, Chapter 16, ButterworthHeinemann, 1991. [2] Xu, J., Zhu, H., et al., From requirements definition to formal functional specification -- A transformational approach, Science in China, Vol. 38 (Supp.) Sept., 1995, pp28~43. [3] Xu, J. and Zhu, H., Requirements analysis and specification as a problem of software automation -- some researches on requirements analysis, Proc. SEKE'96, Nevada, USA, June 1996, pp457~464. [4] Xu, J., Jin, L., and Zhu, H., Tool support of orderly transition from informal to formal descriptions in requirements engineering, Proc. of IFIP'96 : Advanced IT Tools, Australia, Eds. N. Terashima and E. Altman, Chapman & Hall, Sept. 1996, pp199~206. [5] Yourdon, E. Modern Structured Analysis, Prentice-Hall, New Jersey, 1989. [6] Rubin, K.S., Goldberg, A., Object behaviour analysis, Communications of ACM, Vol. 35, No. 9, 1992. [7] Jacobson, I., Object oriented development in an industrial environment, Proc. of OOPSLA, Oct. 1987. [8] Jacobson, I., et al., Object-Oriented Software Engineering, A Use Case Driven Approach, Addison-Wesley, 1992. [9] Weidenhaupt, K., Pohl, K., Jarke, M., Haumer, P., Scenario Usage in System Development: A Report on Current Practice, Proc. Of International Requirements Engineering Conference (ICREÿ98), Colorado Springs, Colorado, USA, April 6-10, 1998. [] Rumbaugh, J., Jacobson, I., and Booch, G., The Unified Modelling Language Reference Manual, AddisonWesley, 1999. [11] Regnell, B., Kimbler, K., Wesslen, A., Improving the use case driven approach to requirements engineering, Proc. REÿ95, 1995, pp40~47. [12] Anderson, J. S. and Durley, B., Using scenarios in deficiency-driven requirements engineering, Proc. REÿ93, 1993, pp134~141. [13] Gough, P.A., Fodemski, F.T., Higgins, S. A. and Ray, S. J., Scenarios - an industrial case study and hypermedia enhancements, Proc. REÿ95, 1995, pp10~17. [14] Hsia, P., Samuel, J., Gao, J., Kung, D., Toyoshima, Y., and Chen, C., Formal approach to scenario analysis, IEEE Software, 1994, pp33-41. [15] Jarke, M. and Pohl, K., Requirements engineering in 2001: (Virtually) managing a changing reality, Software Engineering Journal, Nov. 1994, pp257~266. [16] Jarke, M., et al. , Theories underlying requirements engineering: An overview of NATURE at Genesis, Proc. RE'93, 1993, pp19~31. [17] Maiden, N., Minocha, S., Manning, K. and Ryan, M., A Software Tool and Method for Scenario Generation and Use, Proceedings of Third International Workshop on Requirements Engineering: Foundation for Software Quality RESFQ', Barcelona, Spain, June, 1997. [18] Diaper, D., (ed.) , Task Analysis for Human-Computer Interaction, Ellis Horwood, 1989. [19] Potts, C., Takahashi, K., Anton, A. I., Inquiry-based requirements analysis, IEEE Software, Vol. 11, No. 2, March 1994. [20] Leite, J.C., Rossi, G., Balaguer, F., Maiorana, V., Kaplan, G., Hadad, G, Oliveros, A., Enhancing a requirements baseline with scenarios, Proc. of RE'97, Annapolis, USA, Jan. 1997. [21] Dano, B., Briand, H., Barbier, F., A use case driven requirements engineering process, Journal of Requirements Engineering, Vol. 2, No. 2, pp79~91, 1997. [22] Easterbrook, S., Domain modelling with hierarchies of alternative viewpoints, Proc. REÿ93, 1993, pp65~72. [] Jin, L. and Zhu, H., Description and analysis of use scenarios in requirements engineering, Proc. of SEKE'98, San Fransisco, USA, June 18-20, 1998. pp18~25. [24] System Designers, CORE -- The method, Systems Designers Scientific, Issue 1.0, 1985 [25] Nuseibeh, B., Kramer, J. and Finkelstein, A., A framework for expressing the relationships between multiple views in requirements specification, IEEE Transactions on Software Engineering, Vol. 20, No. 10, Oct. 1994, pp760~773. [26] Motschnig-Pitric, R. Nissen, H. W. and Jarke, M., View-directed requirements engineering -- a framework and metamodel, Proc. SEKEÿ97, Madrid, Spain, June 1997, pp366~373. [27] Leonhardt, U., Kramer, J., Nuseibeh, B. and Finkelstein, A. Decentralised process modelling in a multiperspective development environment, Proc. of 17'th ICSE, 1995, pp255-264. [28] Robinson, W. N., and Fickas, S., Supporting multi-perspective requirements engineering, Proc. ICREÿ94, 1994, pp206~215.

H. Zhu and L. Jin

-- 19 --


2/7/2000

[29] Finklestein, A., Gabbay, D., Hunter, A., Kramer, J., Nuseibeh, B., Inconsistency handling in multiperspective specifications, IEEE Transactions on Software Engineering, Vol. 20, No. 8, pp569~578, August, 1994. [30] Hunter, A. and Nuseibeh, B., Managing inconsistent specifications: reasoning, analysis and action, ACM Transactions on Software Engineering and Methodology, to appear. [31] Darke, P. and Shanks, G., Stakeholder viewpoints in requirements definition: a framework for understanding viewpoint development approaches, Journal of Requirements Engineering, Vol. 1, No. 2, pp88~105, 1996. [32] Wheele, D. A. (ed.), Software Inspection: An Industry Best Practice, IEEE Computer Society Press, Los Alamitos, 1996. [33]Yourdon, E., Structured Walkthroughs, 4th ed., Englewood Cliffs, London, Prentice-Hall International, 1989. [34] Luqi, Chang, C.K., and Zhu, H., Specifications in software prototyping, Journal of Systems and Software, Vol.42, No. 2, pp125~140, Aug. 1998. [35] Zhu, H., Hall, P. and May, J., Software unit test coverage and adequacy, ACM Computing Survey, Dec. 1997. [36] Kamsties, E., Hormann, K. and Schlich, M., Requirements engineering in small and medium enterprises, Requirements Engineering Journal, Vol. 3, No. 2, pp84~90, 1998. [37] Haumer, P., Pohl, K. and Weidenhaupt, K., Requirements elicitation and validation with real world scenes, IEEE TSE, Vol. 24, No. 12, Dec. 1998. [] Zhu, H., Jin, L. and Diaper, D., Activity List as A Description of Software Behaviour for Requirements Validation, Technical Report CMS-TR-99-01, School of Computing and Mathematical Sciences, Oxford Brookes University, March 1999. [] Zhu, H., Jin, L., and Diaper, D., Testing Software Requirements via Task Analysis, Technical Reports, CMS-TR-99-02, School of Computing and Mathematical Sciences, Oxford Brookes University, March 1999. [] Spivey, J. M. (1992) The Z notation -- A Reference Manual, Second Edition, Prentice Hall. [41] Jin, L., Zhu, H, Automatic generation of formal specification from requirements definition, Proc. IEEE first International Conference on Formal Engineering Method, Hiroshima, Japan, Nov. 1997, pp243-251. [] Fenton, N. E., Whitty, R. W. and Kaposi, A. A.(1985) A generalised mathematical theory of structured programming, Theoretical Computer Science, Vol. 36, 145-171. [] Zhu, H. and Jin, L., Scenario Analysis in An Automated Tool for Requirements Engineering, submitted to Requirements Engineering Journal.

H. Zhu and L. Jin

-- 20 --