Revenir à la page d'accueil
Plan du site   |   Plan d’accès   |   UTBM
Projets Européens
Réseaux d'Excellence
Projets Nationaux
Contrats Industriels
Projets thématiques
    ASPECS Methodology
       A quick overview of ASPECS
       System Requirements Analysis
          Domain Requirements Description
          Problem Ontology Description
          Organisation Identification
          Interactions and Role Identification
          Scenario Description
          Role Plan
          Capacity Identification
       Agent Society Design
       Comparisons with existing Agent-Oriented Methodologies
Accueil > Activités et projets > Projets thématiques > ASPECS Methodology > System Requirements Analysis > Domain Requirements Description
Domain Requirements Description

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.


UML use case diagram is the notation suggested for adoption in this activity. Requirements are described in terms of use case diagrams, following an approach inspired by [41]. The result of the Domain Requirements Description activity is a functional description of the system composed of a hierarchical series of use case diagrams. Functional and non functional requirements are described using a specific use case template inspired by [46, 50, 51, 52] and depicted in figure 3. 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 writer is limited and all requirements are written in a standard way. The advantage of this approach is that it maintains expressivenessand understandability of natural language but ensures that some degree of uniformity is imposed on the specification [71]. This description in natural language can be completed and associated to a description made by using a formal language like Z or Object-Z (see [14, 53, 71]). Actors involved in the system are described using the template described in figure 4, their associated requirements using the template depicted in figure 3. Non functional requirements are listed in the form: :. Non-functional keywords include, but are not limited to Availability, Certification, Documentation, Maintainability, Compatibility, Price, Fault Tolerance, Reliability, Resource constraints, Robustness, Safety, Scalability, Security, Performance, Frequency, Priority, etc.

  • 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.a.1 Interaction
      • 3.a.2 Interaction
    • 3.b else If condition then
      • 3.b.1 Interaction
      • 3.b.2 Interaction
    • 3.c else
      • 3.c.1 Interaction
  • 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

  90010 Belfort cedex - Tél : +33 (0)3 84 58 33 19 - Fax : +33 (0)3 84 58 33 42 - Mentions légales