Understanding Requirements Engineering in Software Development

Posted on Jan 17, 2025 in Software Engineering

Requirements Engineering in Software Development

Requirements engineering is the process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed.
The requirements themselves are the descriptions of the system services and constraints that are generated during the requirements engineering process.

It may range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specification.
This is inevitable as requirements may serve a dual function:
- May be the basis for a bid for a contract – therefore, it must be open to interpretation;
- May be the basis for the contract itself – therefore, it must be defined in detail;
- Both these statements may be called requirements.

User Requirements
- Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers.
System Requirements
- A structured document setting out detailed descriptions of the system’s functions, services, and operational constraints. Defines what should be implemented, so it may be part of a contract between the client and contractor.

Functional Requirements
- Statements of services the system should provide, how the system should react to particular inputs, and how the system should behave in particular situations.
- May state what the system should not do.
Non-Functional Requirements
- Constraints on the services or functions offered by the system, such as timing constraints, constraints on the development process, standards, etc.
- Often apply to the system as a whole rather than individual features or services.
Domain Requirements
- Constraints on the system from the domain of operation.

These define system properties and constraints, e.g., reliability, response time, and storage requirements. Constraints are I/O device capability, system representations, etc.
Process requirements may also be specified, mandating a particular IDE, programming language, or development method.
Non-functional requirements may be more critical than functional requirements. If these are not met, the system may be useless.

The software requirements document is the official statement of what is required of the system developers.
It should include both a definition of user requirements and a specification of system requirements.
It is not a design document. As far as possible, it should set out what the system should do rather than how it should do it.

Many agile methods argue that producing a requirements document is a waste of time as requirements change so quickly.
The document is, therefore, always out of date.
Methods such as XP use incremental requirements engineering and express requirements as ‘user stories’ (discussed in Chapter 3).
This is practical for business systems but problematic for systems that require a lot of pre-delivery analysis (e.g., critical systems) or systems developed by several teams.

Information in the requirements document depends on the type of system and the approach to development used.
Systems developed incrementally will typically have less detail in the requirements document.
Requirements document standards have been designed, e.g., the IEEE standard. These are mostly applicable to the requirements for large systems engineering projects.