Requirements engineering

Process · Chapter 3

The idea in brief

Requirements engineering establishes the functionality stakeholders need plus the constraints under which the software must be built and operated.
It encompasses all tasks around requirements: eliciting, analyzing, documenting, validating, and maintaining them.
Architects participate in these tasks, so familiarity is essential — you cannot design an appropriate architecture without knowing the requirements.

Types of software requirements

Type	What it captures
Business requirements	High-level business goals: the problems the software solves or opportunities it addresses. Often market-driven (match or differentiate from competitors), so they frequently influence quality attributes.
Functional requirements	What the software must do — its behavior, capabilities, inputs, outputs, services, and external interfaces; how it interacts with its environment.
Non-functional requirements	Conditions/constraints for the solution to be effective. Includes quality attributes (the “ilities”). Critical to architecture yet often under-captured.
Constraints	Restrictions (technical or non-technical) that are already-decided and must be honored.

Sources of requirements

Requirements arrive from many sources: organizational (policies/procedures), legislative (laws/regulations), ethical (privacy, safety), delivery (deployment), standards, and external (systems that must integrate).

On non-functional requirements

Stakeholders capture functional requirements well but neglect non-functional ones.
Project success depends on meeting non-functional requirements, and they can profoundly shape the architecture — so the architect must actively elicit them and ensure they are captured.
Quality attributes are a subset of non-functional requirements — maintainability, usability, testability, interoperability, and more (see Quality attributes).

On constraints

A constraint is a decision already made that typically cannot be changed and is outside the architect’s control (though you may sometimes provide input to change one).
Examples: an existing vendor agreement or purchased tool, a mandatory law/regulation, an immovable deadline, a dictated resource/outsourcing arrangement, or a required programming language matching the team’s existing skills.

Why requirements engineering matters

Proper requirements analysis is crucial because it affects every subsequent phase. Done poorly, it causes rework, time, and cost overruns.
The later a defect is found, the costlier it is to fix — deliverables from design and development phases may need refactoring. Steve McConnell (Code Complete, 2nd ed.): find an error as close as possible to when it was introduced.
Benefits of proper analysis: reduced rework, fewer unnecessary features, lower enhancement costs, faster development, reduced development costs, better communication, more accurate test estimates, higher customer satisfaction.
Management must understand this importance so adequate time is scheduled; if they don’t, make the case to them.

Requirements must be measurable and testable

Requirements should be complete (all defined) and consistent (clear, non-contradictory).
Each requirement should be unambiguous, measurable, and testable — consider testing when writing them.
Measurable = provides specific values or limits. Testable = there’s a practical, cost-effective way (a test case) to verify it’s met.
Example: “the web page must load in a timely manner” is untestable; “the web page must load within two seconds” is measurable and testable.
If an architect sees a requirement that fails these conditions, point it out so it can be fixed. Set mutually agreed, common expectations with stakeholders to avoid surprises at delivery.

Requirements that affect architecture

Complete, validated requirements are crucial to the architect. Requirements vary in architectural impact — some have none, others profound.
The requirements that most affect design are usually quality attributes, so pay them particular attention.
Quality attributes are commonly under-defined or defined in a non-measurable way, so architects must make extra effort to understand which quality attributes matter to stakeholders and pin down the expected values that make them testable and documented.

Citations

Software Architect’s Handbook (Packt, 2018), Ch.3 “Requirements engineering”, pp. 154-162.