By N2H

Requirements analysis

October 30, 2007

If you're new here, you may want to subscribe to my RSS feed. Thanks for visiting and have a nice day!

Requirements Analysis (Elicitation)

After initial feasibility study, the first major stage of requirements engineering process is requirements analysis or elicitation. The technical software development staff works with users to find out

what functions the system should provide
required performance of the system
hardware constraints etc

This stage is depended on for user acceptance i.e. how well the system meets the users needs and supports the work to be automated.

Requirements Analysis is a difficult process because

Users often don’t really know what they want from the computer system.
Different users have different requirements and they express this in different ways.
Since analysis takes place in an organizational context, political factors in organizations may influence requirements of the system.
The economic and business environment in which analysis takes place is dynamic e.g. new requirements may emerge from users who were not originally consulted.

The process of gaining these requirements is iterative with continual feedback from each activity to other activities. The process activities are:

Domain understanding: Analysts must develop their understanding of the application domain e.g. If a system is for a supermarket, the Analyst finds out all he/she can about supermarkets.
Requirement collection: this is the process of interacting with users in the system to discover their requirements
Classification: This activity takes the unstructured collection of requirements and organizes them into coherent clusters.
Conflict Resolution: This involves finding and resolving conflicting requirements.
Privatization: This stage involves interaction with stakeholders to discover the most important requirements.
Requirements validation: The identified requirements are checked to discover if they are complete, consistent and in accordance with what you really want from the system.

Requirements Definition:

A system requirements definition is an abstract description of functions/services which the system should provide and the constraints under which the system must operate. It should only specify the external behaviour of the system it should not be concerned with system design characteristics.

The requirements should not be defined using an implementation model i.e. the definition should be written in such a way it’s understandable to users.

The requirements may either be functional or non functional

The functional requirements should be

Consistent: The requirements should not have contradictory definitions.
Complete: i.e. all functions required by the user should be defined.

Requirements specification:

This adds further information to the requirement definition. The requirements specification is usually presented with the system models developed during requirement Analysis.

The specification and the model should describe the system to be designed and implemented.

It should include all the necessary information about what the system must do and all the constraints on its operations.

Since the use of natural language on this document might bring problems e.g. misunderstanding because of ambiguity of natural language words, one can use alternatives such as

Structured natural language

This is a form of structured definition. It depends on using standard forms or templates to express the requirements specification

Design Description Language

This approach uses programming language but with more abstract features by defining an operational model of the system.

Requirements Specification Languages

These are special purpose languages that can be used to express software requirements such as PSL/PSA, RSL.

Graphical notations

This notations can be used for analysis and requirements specification eg SADT.

Mathematical specification:

These are mathematical formulas that are formal mathematical concepts such as finite state machines.

A requirement specification should have traceability i.e. the case of finding related requirement to achieve traceability one can:

have all requirements assigned unique number
Requirements should explicitly identify related requirements by referring to their number.
Each requirement document should contain a cross reference matrix showing related requirements.

Recommended Text