Requirements Documentation

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.

Data Perspective

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

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.

Behavioural Perspective

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.

More from my site

  • Tracking of Relationship Between Requirements An important aspect of requirements management is the ability to trace the relationships between requirements and other artifacts (including other requirements). The ability to track […]
  • Categorization of Requirements According to the Kano Model Defining the requirements that will increase the satisfaction of stakeholders from the system being created is crucial for the process of acquiring requirements. Implementation of too many […]
  • The Requirements Are the Most Important During my work, I noticed that the requirements are a big problem. The difficulty is not to write them down. It is difficult to articulate them. I omit the turbulence associated with the […]
  • User Stories vs Requirements When writing any specification of requirements and the product register and sprint register, non-functional requirements should be included in this specification. While the user's […]
  • Requirements Management – Best Practices Ian Sommerville and Pete Sawyer in "Requirements Engineering: A Good Practice Guide" described, over 15 years ago, the method of assessing and improving requirements engineering […]

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top