Domain Requirements Description
Both the PASSI, and ASPECS, software processes are driven by requirements. Thus the starting activity is the functional requirements and non functional requirements analysis. Functional requirements describe the behaviour of the system in terms of interactions perceived by the user. Non functional requirements are requirements which specify constraints on the system and some of its quality aspects. In the following the description of this activity according to the proposed template will be presented.
The global objective of the Domain Requirements Description (DRD) activity is to provide an overview of the system’s functionalities. This activity thus
aims at gathering needs and expectations of application stakeholders and at providing a complete description of the behaviour of the application to be developed. In the proposed approach, these requirements (both functional and non functional) should be described using the specific language of the application domain and a user perspective.
Use cases are deduced from a set of text descriptions of the system usage scenarios (that are supposed to be an input of this design process), quality and procedure documents and are gradually refined with stakeholder interviews and meetings.
- Identifier: Unique identifier of the use case, may depend on reference number and modification history.
- Name: Name of the use case.
- Iteration: informs the reader of the stage the use case has reached.
- Type: Abstract or Concrete
- Description: Goal to be achieved by use case and sources of requirements.
- Actors: List of actors involved in use case.
- Pre-conditions: Conditions that must be true for use case to start successfully.
- Post-conditions: Conditions that must be true at the end of the scenario. It summarizes the state of affairs after the scenario is complete.
- Flow: The ordered list of interactions between actors and system that are necessary to achieve goal. Example of general flow of interaction:
- 1. Interaction x
- 2. Interaction y
- 3.a If condition then
- 3.b else If condition then
- 3.c else
- Variations/Alternative Flow: Any variations,
- Non-functional: List of non-functional requirements meet.
- Authors and dates: Modifications history.
|Figure 3: Use Case Description Template |
- Stereotype: Actor Classification, e.g.: human-being, device, database, data warehouse, etc.
- Type: Abstract or Concrete.
- Identifier: Unique identifier of the actor, may depend on reference number and modification history.
- Iteration: inform the reader of the stage the use case has reached.
- Actor type: Primary or Secondary.
- Actor form: Initiator, Server or Receiver.
- Contact: Actor Name.
- Definition/Description: Who or what the actor represents, why the actor is needed, what interests the actor has in the system. if actor is an external system: specification, interface description, manufacturer documentation, reference materials, etc.
- Responsabilities: ID of use cases in which the actor is involved.
- Relationships: (e.g., client, server, peer) to the application, application domain, or component.
- Required Expertise: Only if actor is a human actor.
- Authors and dates: Modifications history.
|Figure 4: Actor Description Template |
MAS Metamodel Elements
Define(Functional Requirements), Define(Non-Functional Requirements), Relate (Functional Requirements, Non-Functional Requirements).
Work to be done
In ASPECS the requirement engineering process starts with requirements elicitation. This task firstly aims at identifying the available sources of
requirements: stakeholders (system-end users, customers, domain experts), documentation, existing systems, databases, etc. Then the objective is to determine with them what functionalities the system should provide, and the set of constraints to satisfy for each of them (performance, accessibility, hardware specificity, etc). When requirements have been identified, the second task consists in determining a classification, hierarchization or a prioritization of these requirements. Giving this partition, the objective is to distinguish functionalities that will be implemented by the current release of the system from future extensions and enhancements to the application. Each requirement is then described and documented. Requirement engineering is also an iterative process where a first set of requirements is identified and described. Afterward these requirements are detailed and progressively extended with the various stakeholders’ interviews.
Starting from a text description of the system behaviour, it is possible to identify some initial requirements. In this text, functional requirements, related to actions and interactions, are often characterized by verbs, whereas non functional requirements are often characterized by adjectives. Actors are often represented by subjects of sentences.
Figure 5 details the use cases associated to the development of a simulator for the FIRA Robot Soccer cup. Eight use cases and one actor have been
identified, each use case has been numbered in order to facilitate the explanations in the following activities. The actor represents the user of the simulator who can simulate matches and tune the strategy of each team. Simulating a match implies the simulation of two autonomous teams which can choose their own strategy and are responsible for simulating the individual robots behaviour.
|Figure 5: FIRA Robot Soccer Simulator use cases |