Line 1: Line 1:
Both the PASSI, and ASPECS, software processes are driven by requirements. Thus
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 behaviour 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 behaviour 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 labelled as the current activity: Domain Requirements Description (or briefly DRD).
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 behaviour 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 behaviour 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 labelled as the current activity: Domain Requirements Description (or briefly DRD).
 +
 +
 +
== 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 hierarchial series
 +
of use case diagram. Functional and non functional requirements are described
 +
using a specific use case template inspired by find a good citations of RUP,UP
 +
and depicted in figure 5. 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 naturak language can be completed and associated to description using formal
 +
langage like Z or Object-Z. Actors involved in the system are
 +
described using the template described in figure 2, their associated requirements using the template deicted in figure 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.
 +
 +
 +
{| class="frametable"
 +
|+ Figure 2: 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.
 +
|-
 +
|'''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.
 +
|}
 +
 +
 +
== MAS Meta-Model Elements ==
 +
 +
Define(Functional Requirements), Define(Non-Functional Requirements).
 +
 +
 +
 +
 +
 +
== Work to be done ==
 +
 +
 +
In ASPECS the requirement engineering process starts with requirements
 +
elication. 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 functionnalities the system should provide, and the set of constraints to satisfy for each of them (performance, accesibility, hardware specificity, etc).
 +
When requirements have been identified, the second task consists in determine a
 +
classification, hierarchisation or a prioritization of these requirements. Giving this
 +
partition, the objective is to distinguish functionnalities 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 fonctional requirements are often characterized
 +
by adjectives. Actors are often represented by subjects of sentences.
 +
 +
 +

Revision as of 14:58, 29 July 2010

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 behaviour 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 behaviour 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 labelled 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 hierarchial series of use case diagram. Functional and non functional requirements are described using a specific use case template inspired by find a good citations of RUP,UP and depicted in figure 5. 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 naturak language can be completed and associated to description using formal langage like Z or Object-Z. Actors involved in the system are described using the template described in figure 2, their associated requirements using the template deicted in figure 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.


Figure 2: 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.

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.


MAS Meta-Model Elements

Define(Functional Requirements), Define(Non-Functional Requirements).



Work to be done

In ASPECS the requirement engineering process starts with requirements elication. 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 functionnalities the system should provide, and the set of constraints to satisfy for each of them (performance, accesibility, hardware specificity, etc). When requirements have been identified, the second task consists in determine a classification, hierarchisation or a prioritization of these requirements. Giving this partition, the objective is to distinguish functionnalities 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 fonctional 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. document.

Copyright 2010-2019 © IRTES Institute - UPR EA 7274 - Université de Technologie de Belfort-Montbéliard - Privacy policy