Requirements Engineering acts as the foundation of any successful software system. The primary goal of this discipline is to bridge the cognitive gap between what stakeholders need and what developers build. The ultimate output of this process is the Software Requirements Specification (SRS), which serves as the official contract between the development team and the client, a blueprint for system design, and the validation baseline for testing.

The requirements engineering lifecycle is not a single linear phase but rather a highly iterative process of continuous refinement, validation, and change management.

The Requirements Engineering Process

The requirements engineering discipline operates as a continuous lifecycle loop, transforming high-level business goals into precise, testable software components.

This lifecycle comprises several interrelated activities:

• Elicitation: Actively discovering stakeholder requirements through interviews, workshops, and observation.
• Analysis & Negotiation: Organizing the gathered requirements, identifying conflicts, and negotiating trade-offs with stakeholders.
• Specification: Creating the formal SRS document using standardized templates.
• Validation & Verification: Reviewing the document to ensure it is complete, consistent, and testable.
• Requirements Management: Managing changes to the baseline using a change control process and tracking requirements using a traceability matrix.

Footnotes

1. ISO/IEC/IEEE 29148:2018 - Systems and software engineering - Modern standard regulating requirements engineering processes and document templates. ↩

2. Karl Wiegers - Software Requirements (Microsoft Press) - Textbook defining requirements engineering phases, SRS design, and V&V checklist techniques. ↩

Real-Time Case Study: Automotive Anti-Lock Braking System (ABS)

In safety-critical systems, requirements engineering demands extreme precision. Let us examine the Software Requirements Specification for an Automotive Anti-lock Braking System (ABS), which is a classic hard Real-Time System.

In an ABS, a failure to meet timing constraints can lead to catastrophic hardware failure and loss of life. Its requirements are organized into three primary categories:

1. Functional Requirements (FR):
   • Wheel Speed Monitoring: The system shall read telemetry from the wheel speed sensors via the CAN bus.
   • Brake Pressure Modulation: The system shall modulate hydraulic valve pressure when wheel slip is detected.
2. Non-Functional Requirements (NFR):
   • Performance/Timing: The main control loop shall execute every $T_{\text{loop}} = 10\text{ ms}$ and calculate the slip ratio $S$ where: $S = \frac{V - \omega \cdot R}{V}$ where $V$ is the vehicle speed, $\omega$ is the wheel angular velocity, and $R$ is the wheel radius.
   • Safety: The software shall comply with the ISO 26262 standard for road vehicles, meeting Automotive Safety Integrity Level D ($\text{ASIL-D}$) compliance.
3. System Constraints:
   • The ABS software must execute within a microcontroller containing less than $512\text{ KB}$ of RAM.

SRS Excerpt Quality Assessment & Refactoring

In many industrial projects, initial requirements drafts contain critical flaws in clarity, traceability, and testability. The table below presents three flawed excerpts from an initial ABS requirements document, assesses their issues, and provides standard-compliant, fully testable refactored requirements.