Both the PASSI, and ASPECS, software processes are driven by requirements. Thus the starting activity deals with the analysis of system functional requirements and non functional requirements. Functional requirements describe the functions the software has to exhibit [1] or the behavior of the system in terms of interactions perceived by the user. Non functional requirements are sometimes known as constraints or quality requirements [1]. The global objective of the Domain Requirements Description (DRD) activity is gathering needs and expectations of application stakeholders and at providing a complete description of the behavior of the application to be developed. In the proposed approach, these requirements (both functional and non functional) should be described by using the specific language of the application domain and a user perspective. This is usually done by adopting use case diagrams for the description of functional requirements besides, conventional text annotations are applied to use cases documentation for describing non functional requirements. The resulting document is labeled as the current activity: Domain Requirements Description (or briefly DRD).
Contents |
Goal
The global objective of Domain Requirements Description activity is to provide an overview of the system’s context and capabilities. This activity aims thus at gathering needs and expectations of the application’s stakeholders and provide a complete description of the behavior of the application to be developed. These requirements should be described using the specific language of the application domain and perspectives of users. This activity specify the application’s system-level functional and non functional requirements. It has to establish a first estimation of the scope, the size, the complexity of the application and the amount of associated costs.
Input
Use cases are deduced from a set of text descriptions of the system usage scenarios, quality and method documents and are gradually refined with the passing stakeholder interviews and workshops.
Output
Requirements are described in terms of use case diagram. The Domain Requirements Description activity, as a result, is a functional description of the system composed of a hierarchical series of use case diagram. Functional and non functional requirements are described using a specific use case template inspired by (R)UP. Each requirement is expressed in natural language or an appropriate formalism. Structured natural language is a way of writing system requirements where the freedom of the requirements writer is limited and all requirements are written in a standard way. The advantage of this approach is that it maintains expressiveness and understandability of natural language but ensures that some degree of uniformity is imposed on the specification. This description in natural language can be completed and associated to description using formal language like Z or Object-Z. Actors involved in the system are described using the template described in Table 2, their associated requirements using the template depicted in Table 1. Non functional requirements are listed in the form: <keyword>:<requirement>. Non-functional keywords include, but are not limited to Performance, Reliability, Fault Tolerance, Frequency, and Priority.
| Use Case Description Template |
|---|
| Identifier: Unique identifier of the use case, may depend on reference number
and modification history. |
| Name: Name of the use case. |
| 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 for use case to start successfully. |
| Flow: The ordered list of interactions between actors and system that are
necessary to achieve goal. Example of general flow of interaction:
|
| Variations/Alternative Flow: Any variations, alternative in the flow of a use
case. |
| Non-functional: List of non-functional requirements that the use case must
meet. |
| Actor Description Template |
|---|
| Stereotype : Actor Classification, e.g.: human-being, device, database, data warehouse,
etc. |
| Types: Abstract or Concrete. Primary or Secondary. |
| Identifier : Unique identifier of the actor, may depend on reference number and
modification history. |
| 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. |
| Responsibilities : 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. |
MAS Meta-Model Elements
Define(Functional Requirements), Define(Non-Functional Requirements).
Work to be done
In ASPECS the requirement engineering process starts with requirements elicitation. This task aims at firstly 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 determine a classification, hierarchy and priority of these requirements. Giving this partition, the objective is to distinguish functionality that will be directly implemented from future extensions and enhancements to the application. Each requirement is then described and documented, the associated description are completely fulfilled. Requirement engineering is also an iterative process where a first sets of requirements is identified and described. Afterward these requirements are detailed and progressively extended with the various stakeholders’ interviews. The identified requirements will so drive the complete development process: from the design to implementation and testing activities.
Guidelines
Functional requirements, related to action and interaction, are often characterized by verbs, whereas non functional requirements are often characterized by adjectives. Actors are often represented by subjects of sentences.
References
- [1] Software Engineering Body of Knowledge
- IEEE Computer Society.
2004.
