Enhancing validation with Prototypes out of Requirements Model

Size: px

Start display at page:

Download "Enhancing validation with Prototypes out of Requirements Model"

Dale Phelps
5 years ago
Views:

1 Enhancing validation with Prototypes out of Requirements Model Michael Deynet, Sabine Niebuhr, Björn Schindler Software Systems Engineering, Clausthal University of Technology, Clausthal-Zellerfeld, Germany {michael.deynet, sabine.niebuhr, ABSTRACT In large IT projects it is important that the supplier understands the needs (requirements) of the user on the acquirer s side correctly. The presented Requirements Engineering methodology picks up this problem and improves the communication between acquirer (including the user) and supplier. Our approach uses a requirements model based on UML to communicate the acquirers requirements to the supplier. We use this Requirements Model to generate an early prototype of the developed IT-system. This can be used to illustrate the main functionality of the IT system to get early feedback from the user. Keywords Requirements Engineering, Screen-Mockup Prototype, UML, Validation 1. Introduction In industry large IT projects are subdivided into two parts: the acquirers part and the suppliers part. At the beginning, the overall IT lifecycle process contains two processes: The Acquisition Process and the Supply Process (e.g. ISO 12207). The Acquisition Process contains the activities of the acquirer who acquires an IT product. The acquirer captures the users needs (requirements) of the IT system and represents them. On the other side the Supply Process contains the activities of the vendor who has closed a contract with the acquirer to develop an IT product. The following development process on the supplier s side defines the system requirements among other things on the basis of the requirements of the acquirer. The acquirer s requirements should meet the following properties: The requirements should be understandable, clearly described, minimal, verifiable, and realizable (all this for the user and for the supplier). Through this, the IT product will be more verifiable regarding costs, quality, time, maintainability and functionality. Currently there are existing two language types for specifying IT systems: Natural language and specialized (formal or semi-formal) languages like UML-based languages or domain specific languages. The natural language is often used in early steps in IT

2 projects mainly on acquires side to describe the System Requirements. Specialized languages are often used in later steps of IT projects (e.g. for code generation). The use of natural language causes some problems: Natural language is unclear and interpretable. Furthermore, it is not possible to provide tool support for natural language (e.g. for testing). By the use of specialized languages a lot of these problems can be eliminated. Generally the acquirer uses natural language to specify the requirements of a system. He handovers these requirements to the supplier who refines them and uses them for designing and implementing the system. Through this, the problems concerning natural language get worse because the requirements in natural language are going over organization boundaries. Thereby it is crucial that the supplier understands the requirements of the acquirer early in the right way because the success of the IT project depends on this. Thus, we improved the interface between acquirer and supplier. The acquirer collects the requirements in a more formal language (than natural language), so that the supplier understands it in a better way. To define the requirements on the acquirers side we mostly use UML. Hereby, the supplier understands the requirements early in the right way. Furthermore, we use the formally described requirements to generate an early prototype of the IT system. This has got a basic benefit: The later user of the IT system (who is not an IT professional) can understand the prototype (which represents the requirement) and validate the requirements of the IT system. 2. The New Requirements Engineering Approach To improve communication our focus was to change the crucial situation between acquirer and supplier. What we had to do was to change the partially existing process for Requirements Engineering and to change the syntax for the requirements specification. In most cases the requirements specification documents are written in plain text with some illustrating figures. Plain text holds the risk of misinterpretation (on the suppliers and acquirers side) and inconsistency. Our approach is supplementing the typical textual specification with an extended Requirements Model. We use this Requirements Model to generate an early prototype of the developed IT system. This can be used to illustrate the core functionality of the IT-system to get early feedback from the user. We handover the Requirements Model (including the prototype) to the supplier, so that he can use this to understand the requirements. By using a more precise language, like UML and the same understandable semantics we can reduce the communication gap between the supplier and the acquirer.

3 2.1. Requirements Engineering Model The aim of the Requirements Engineering methodology is an extended object oriented Requirements Model described in UML notation (Object Management Group, 2009). Our Requirements Model consists of 4 partial models: 1. Use Case Model: It describes the external view of the future system, using UML Use Case Diagrams and Use Case Tables. 2. Domain Model: It describes the domain entities using UML Class Diagrams. 3. Activity Model: It describes the sequences of the functions described in the Use Case Model. 4. Screen Mock-up Model: It sketches the future actor interface. Use Case Model, Domain Model and Activity Model are described in UML and therefore have a defined language as syntax, namely the UML profile. This means a well defined semantics for especially the UML activity diagrams, which are the core of the requirements model. Due to the execution semantics, the model can be interpreted by a machine and the modeling can be supported by a tool. 2.2 Requirements Engineering Methodology Our approach combines Requirements Engineering and Software Architecture Design in modeling the Requirements Engineering Model. The central activity of the Requirements Engineering methodology is designing this model. To fulfill the demands of Requirements Engineering regarding Architecture Design aspects we combine the Requirements Analysis with Object Oriented Analysis (e.g. Booch, 2007) and Model Based Design (e.g. Kleppe, 2003). Since we changed the language of the specification from natural language to the more formal language UML, we moved further communication and media gap between supplier and acquirer to a new communication gap between the supplier s requirements analyst and the user. For involving the users for requirements validation, the UML Requirements Model is enhanced with Screen-Mockups. Executing the Requirements Engineering methodology, this enhanced Requirements Model is used to generate a prototype out of the model to communicate with users. In the further processing of Requirements Engineering the user and the requirements analysts communicate through the prototype. As a benefit of prototyping the modeled requirements, we bridge this new gap, and the user is able to understand the specification again. The risk of an incomplete or false validation is minimized and the specification is closer to the users needs. The semantics of the Requirements Model, as well as the methodology to design the model are described in well defined syntax and semantics. Well defined syntax and semantics enable machines to interpret the methodology s description.

4 3. Requirements Model Our Requirements Model consists of 4 parts: The Use Case Model, the Domain Model, the Activity Model, and the Screen-Mockup Model. The Use Case Model describes the external view of the system. The Domain Model describes the Domain Entities of the system. Each Use Case (in the Use Case Model) is detailed with an Activity in the Activity Model. In these Activities the Domain Entities (of the Domain Model) are used to describe the information flow among themselves. The interfaces between the Activities and external Actors (e.g. other systems) are described with Screen-Mockups. These model parts and their relationships are pictured in Figure 1 (left). Please have a closer look on the model parts in the following. 3.1 Use Case Model The Use Cases in the Use Case Model are describing the system requirements on the highest level. For each Use Case a Use Case Table is used to describe the requirement. In Figure 1 (right) a Use Case Table for a Use Case is pictured. Activity Model Domain Model Screen-Mockup Model Use Case Model Name Brief description ID Description Actors Category Trigger Precondition Incoming Data Outgoing Data Postcondition Standard sequence Alternative sequence Miscellaneous Figure 1: Left: Overview Requirements Model; Right: Use Cases and Use Case Table 3.2 Activity Model For each Use Case an Activity is created to decompose the high level requirement into a sequence of (more detailed) requirements (called Actions). To permit a later prototype

5 generation we had to define extensions to the UML Activities in terms of UML profiles. These extensions are described below Interface Action To describe the interface between the system and external actors we defined a special type of Action, the Interface Action. The Interface Action refers to a Screen-Mockup which defines the data (elements from the domain model) exchanged through the described interface. The Interface Action can have Input or Output Pins (both with the stereotype «InterfacePin»). With these Pins it is possible to get or set objects which are transported over the interface from/to the Actors. For example in Figure 2 (left) the system gets the called party from the inter-phone system. This party (variable cp ) can be used for further processing in the Activity. ActivityModel Use Case Model ActivityModel Figure 2: Left: Interface action to describe the interaction between Actors and the system; Right: Service Actions to describe functions the system processes on its own Service Action Service Actions are used to describe functions that the system executes on its own. They can also have Input and Output Pins (stereotype «VariablePin»). Input Pins are parameters on which the service action executes its output. This output is described as Output Pins of the Service Action. The output of a Service Action can for example be used for further decisions of the control flow, shown in Figure 2 (right). Here route is the variable which has a reference to the object which is the output of the Service Action Calculate route Variables To enable an automatic prototype generation we elaborated a variable concept for UML Activities: We distinguish between variable declaration and variable use in UML

6 Activities. We use the Object Nodes with the stereotype «Variable» for variable declaration. In Figure 2 (left) for example the variable with the name cp and from the type party is declared. Variables can be used as input or output of Actions. This is provided by Input and Output Pins with the stereotype «VariablePin» Call Behavior Action The presented methodology was elaborated to specify an embedded communication system. There was a need to handle the creation of multiple instances of Activities. This instantiation is provided by the Call Behavior Action (see Figure 3 (left)). Multiple instances can be created by executing the Call Behavior Action several times (seefigure 3 (right)). ActivityProviding LAN communication Figure 3: Left: Call Behavior Action to create an instance of an Activity; Right: Multiple instances of one Activity Signals The communication between Activities is provided by signals. A signal has a name ( Send Voice Message, Figure 4 (left)), a reference to the object which is transferred (InputPin voice message with stereotype «VariablePin») and a target (InputPin wi with stereotype «MessageTargetPin»). wi is a variable of the type Providing wireless communication (this is an Activity). So, the voice message is sent to the Activity which is referenced by the variable wi. The variable wi is previously set by the Service Action Get Wireless Instance. 3.3 Domain Model We use UML class diagrams to describe the domain entities of the system. In the Activity Model these Entities can be used to declare variables (see Figure 4 (right)) and to use these variables with Input and OutputPins. In the Activity Model in Figure 2 (left) the variable cp is declared. This variable has the type party which is defined in the

Domain Model. cp is used in the Activity Model as OutputPin of the Interface Action Get called party.

4 Screen-Mockup Model The interface between external actors and the system is described with Screen- Mockups.

This Mockup contains a Label (element Name with stereotype «MockupLabel»), a button (element Create with stereotype «MockupButton») and a textfield (element NameTextfield with stereotype

The Interface Action Create NPC refers to the Mockup Create NPC.

7 Domain Model. cp is used in the Activity Model as OutputPin of the Interface Action Get called party. ActivityModel ActivityModel Domain Model Figure 4: Left: Signals for inter-activity communication; Right: Use of Domain Entities in the Activity Model 3.4 Screen-Mockup Model The interface between external actors and the system is described with Screen- Mockups. This can be a User Interface (if the actor is a user) or any other interface where data is transmitted (if the actor is another system). Figure 5 (left) shows the Screen-Mockup Create NPC. This Mockup contains a Label (element Name with stereotype «MockupLabel»), a button (element Create with stereotype «MockupButton») and a textfield (element NameTextfield with stereotype «MockupTextfield») where the user can enter a text. An Interface Action in the Activity Model refers to a Screen-Mockup in the Screen- Mockup Model (see Figure 5 (right)). The Interface Action Create NPC refers to the Mockup Create NPC. The Textfield NameTextfield of the Mockup is mapped to the OutputPin of the Interface Action ( mockupelement=nametextfield in the specification of the OutputPin). If the Interface Action is active the user can enter the input in the Textfield NameTextfield of the Screen-Mockup. In the further processing of the Activity this input is copied to the variable newpc.name over the OutputPin. 4. Prototype Generation Through the previous sketched extensions to the UML Activities in terms of UML profiles the requirements model has a precise semantics with a well defined syntax. With this well defined execution semantics, the model is interpretable by a tool. In the following we present how the requirements model is used to generate a prototype of the system.

If the generated prototype is started the execution begins with an overview of the system functionality (see Figure 6 (left)). Thereby, for each Use Case in the Use Case Model a button is created.

8 If the generated prototype is started the execution begins with an overview of the system functionality (see Figure 6 (left)). Thereby, for each Use Case in the Use Case Model a button is created. Screen-Mockup Model Activity Model Figure 5: Left: Screen-Mockup Model; Right: Mapping InterfaceAction with Screen-Mockup and InterfacePin with a Mockup-Element There exists an underlying Activity (in the Activity Model) for each Use Case in the Use Case Model. This underlying Activity is executed by clicking on the corresponding button on the overview page in the prototype. 4.1 Activity execution We enrich elements (e.g. actions, pins, object nodes) used in the UML activities with stereotypes. This allows us to classify these elements into several groups, depending on their functionality. In the following, the most important stereotypes are explained: An «Interface Action» describes actions which deal with user interactions. If an Interface Action is executed, the prototype will show the associated Screen-Mockup and the user of the prototype can simulate the Actor who communicates with the system in this Action. Figure 7 shows the Interface Action Create NPC which references to the analogous Screen-Mockup. A «Service Action» describes an action the system executes on its own. If a Service Action is active the user of the prototype has to simulate the processing of the Service

If a decision node is executed, a dialogue with a list of all possible decisions appears in the prototype. The possible decisions result from the outgoing edges and their guards. 5.

9 Action on the basis of the data which are copied to the Input Pins the Service Action owns. Use Case Model Prototype Figure 6: Left: Each Use Case is represented by a button in the prototype; Right: Decision nodes In the prototype, decision nodes have to be simulated by the user (e.g. if the user is logged in, see Figure 6 (right)). If a decision node is executed, a dialogue with a list of all possible decisions appears in the prototype. The possible decisions result from the outgoing edges and their guards. 5. Preliminary lessons learned The presented RE Methodology is applied in a real project in the field of public administration on the acquirer s side. We are currently finalizing the requirements model and are validating this with the user using generated prototypes. Activity Model Active Screen-Mockup Model B A C A D E Prototype B D E C Figure 7: Screen-Mockup and corresponding windows of the Prototype

10 Using the generated prototypes enhances the communication with the user, especially in early steps of IT projects. The user gets able to understand the specified core functionality of the IT system and can validate this with his needs. We defined a very clear syntax and execution semantics for the requirements model to generate these prototypes. The maintenance of the requirements model is very complex and the requirements engineer has to fulfill a high level of expertise to maintain the requirements model. To pickup this disadvantage we are elaborating a finder-grained tool support for specifying the requirements in the requirements model. 6. Conclusions In this paper a Requirements Engineering methodology is presented which improves the communication between user, acquirer and supplier. This methodology uses a requirements model based on UML. It consists of 4 parts: Use Case Model, Activity Model, Domain Model and Screen-Mockup Model. The Use Cases are used to describe the external view of the system. Each Use Case is refined with an Activity. This Activity describes the sequences of the functions described in the Use Case Model. The Domain Model describes the domain entities using UML Class Diagrams. The Screen-Mockup Model sketches the interface between external Actors and the system. The paper details the modeling approach and the syntax of the requirements model and shows the relations between the particular model elements. Furthermore, the execution semantics of the requirements model which is used to generate early prototypes of the system is shown. 7. References Booch, G. et.al (2007). Object-Oriented Analysis and Design with Applications. 3rd ed. Boston ISO (1995). Systems and software engineering -- Software life cycle processes Object Management Group (2009, 1th July). Kleppe, A. (2003). MDA Explained: The Model Driven Architecture. Boston. Acknowledgements Thanks to Andreas Rausch who takes a leading part in elaborating the presented Requirements Engineering Methodology. Copyright Copyright 2010 Michael Deynet, Sabine Niebuhr, Björn Schindler. The author(s) assign to NACCQ and educational non-profit institutions a non-exclusive licence to use this document for personal use and in courses of instruction provided that the article is used in full and this copyright statement is reproduced. The author(s) also grant a non-exclusive licence to NACCQ to publish this document in full on the World Wide Web (prime sites and mirrors) and in printed form within the Bulletin of Applied Computing and Information Technology. Any other usage is prohibited without the express permission of the author(s).

Refinement and Formalization of Semi-Formal Use Case Descriptions

Refinement and Formalization of Semi-Formal Use Case Descriptions Matthias Riebisch, Michael Hübner Ilmenau Technical University Max-Planck-Ring 14; 98684 Ilmenau; Germany {matthias.riebisch michael.huebner}@tu-ilmenau.de