Requirement Types & Quality Requirements
Not all requirements are the same. The IREB syllabus distinguishes three fundamental types and places special emphasis on quality requirements, which are often neglected in practice.
The Three Requirement Types
Every requirement falls into one of three categories:
1. Functional Requirements
A functional requirement describes what the system should do, a result or behavior provided by a function of the system.
"The system shall allow a user to search for flights by departure city, destination city, and date."
Functional requirements are typically subdivided into:
- Functional requirements (input/output behavior)
- Behavioral requirements (how the system reacts to events)
- Data requirements (what data the system stores and manages)
2. Quality Requirements
A quality requirement describes how well the system should perform. These are often called "non-functional requirements" and they frequently influence the system architecture more than functional requirements do.
"The system shall respond to any search query within 2 seconds under normal load."
Quality requirements address concerns like performance, security, reliability, usability, maintainability, and portability.
3. Constraints
A constraint is a requirement that limits the solution space without describing functionality or quality. Constraints cannot be influenced by the project team, they must be adhered to.
"The system shall be implemented using Java." "The system shall be available on the market by Q2 2025."
Constraints can restrict the system itself (technology choices) or the development process (deadlines, regulations).
Functional Requirement
Click to flipA requirement concerning a result of behavior that shall be provided by a function of the system. Describes WHAT the system does.
Click to flip backWhy Quality Requirements Deserve Special Attention
In daily practice, quality requirements are often:
- Not documented at all
- Inadequately documented (vague statements like "the system should be fast")
- Improperly negotiated between stakeholders
This is dangerous because quality requirements heavily influence the system architecture. A system designed for 100 concurrent users has a fundamentally different architecture than one designed for 10 million. If these requirements are discovered late, the rework is massive.
ISO/IEC 25010 Quality Categories
The ISO/IEC 25010 standard provides a structured way to think about quality requirements. Use it as both a documentation template and an elicitation checklist:
A client tells you: "The system must be built with React and deployed on AWS." What type of requirement is this?
Which of the following is a quality requirement?
Beyond the Three Types
Requirements can also be classified by other attributes:
- Level of detail, high-level stakeholder need vs. detailed system specification
- Priority, must-have vs. nice-to-have (covered in Chapter 8)
- Legal obligation, shall (mandatory) vs. should (recommended) vs. will (future intent)
Standards like CMMI, SPICE, and ISO/IEC/IEEE 29148 offer additional classification schemes used in practice.
- Three requirement types: Functional (what), Quality (how well), Constraints (limits)
- Quality requirements are frequently neglected but heavily influence system architecture
- Constraints are not implemented, they are adhered to
- ISO/IEC 25010 provides 6 key quality categories: performance, security, reliability, usability, maintainability, portability
- Use quality categories as both a documentation template and an elicitation checklist