Requirements specification is a systematic representation of a set of requirements for a system or component that meets specific criteria.
Requirements are like contract. All information collected and agreed during the requirements engineering activities must be documented. Each type of requirement affects, directly or indirectly, all phases of software life cycle. The quality of the requirements document and the requirements as such is of key importance to the course of the project being implemented and determines its success.
Requirements are the basis for the system being created. For this reason, the document of requirements represents the contract by and between the customer and the contractor. The customer has the right to require that the agreed requirements be implemented. In the event of disagreement during the acceptance of the final system, the document of requirements constitutes the basis for resolving disputes.
Requirements documentation is complex. Systems that have thousands of requirements, which in turn have many interconnections, are often found in practice. Managing requirements would be very difficult without proper documentation.
The requirements must be available to all stakeholders. If the requirements are available at all times, stakeholders can explain their uncertainties related to the requirements on an ongoing basis, and new employees who joined the project can get acquainted with them quickly.
Requirements documentation can be considered from three different perspectives:
- Data Perspective
- Functional Perspective
- Behavioural Perspective
To describe each of the above perspectives, the requirements engineer can use a natural language and conceptual models.
In the case of a data perspective, the requirements are presented from a structural point of view. In this perspective, for example, the structure of input and output data for the system being created, and the relations between these data are presented.
Functional perspective documents what information is received, processed and retrieved by the system or its functions and the order of the functions that process this information.
The behavioural perspective focuses on documenting the system’s response to events occurring in its context, conditions that change the system or its components and the results that the system should provide to its environment.
Certain aspects of the models of a particular perspective can also be found in other perspectives. The three perspectives are therefore not disjoint. For example, the data, whose static structure is defined in a UML class diagram can potentially also be found from the functional perspective because it depicts the inputs and outputs of actions in a UML activity diagram. As the three perspectives are not disjoint, the models can be reciprocally checked for completeness and consistency with regard to the information that is modelled at the intersections.