Levels and Types of Requirements
In short Requirements come in layers: why the organization wants a product, what users must be able to do with it, and how the system must behave. Keeping the layers apart tells you where each statement belongs, who approves it, and what is missing.
Based on: K. Wiegers, J. Beatty, Software Requirements, 3rd ed., ch. 1; the problem-domain / solution-domain model of E. Hull, K. Jackson and J. Dick as presented in I. Kornipaev’s Requirements Management course (in Russian).
On this page
Key ideas#
What counts as a requirement#
Wiegers and Beatty start from a definition by Sommerville and Sawyer: a requirement specifies a behavior, property or attribute the system must have, and may also constrain how it is built. A statement stays a requirement even if it has low priority or is deferred. Do not argue whether something is “really” a requirement; record it and prioritize it.
Three levels of product requirements#
| Level | Question it answers | Typical form | Where Wiegers and Beatty keep it |
|---|---|---|---|
| Business requirements | Why does the organization need this? | Business objectives, success measures | Vision and scope document |
| User requirements | What must users be able to do? | Use cases, user stories, event-response tables | User requirements document |
| Functional requirements | How must the system behave in given conditions? | “The system shall…” statements | Software requirements specification (SRS) |
Three more kinds of information sit alongside the levels:
- Non-functional requirements — quality attributes (availability, usability and so on), design constraints and external interface requirements. They appear at every level.
- Business rules — policies, regulations and calculations. Strictly, they are not software requirements, but they are a major source of them.
- System requirements — top-level requirements for a product made of several subsystems, often hardware plus software. The book’s example is a supermarket checkout workstation with several attached devices.
A feature is a group of related functional requirements that gives users something of value, such as autosave. A feature tree breaks a feature into sub-features, each linked to specific user and functional requirements.
Product requirements vs. project requirements#
The SRS holds product requirements only. What the project needs — team resources, staff training, user documentation, data migration, certification, licensing, service-level agreements — goes into the project management plan, a shared responsibility of the business analyst and the project manager. If a statement describes what the project must do rather than what the product must do, move it out of the SRS.
Development vs. management#
Wiegers and Beatty divide requirements development into elicitation, analysis, specification and validation, repeated with more detail each pass rather than done once in sequence. Requirements management starts once a baseline is agreed: versions, change impact, status and links. Waterfall projects front-load this work, iterative projects do some in every iteration, and agile projects refine each story just before it is built.
Usage first, features second#
The authors recommend a usage-centric approach: understand business objectives and user tasks first, then derive features. A product-centric approach that starts with an attractive feature list risks building functions nobody ends up using.
A second view: problem domain vs. solution domain#
Hull, Jackson and Dick, as presented in Kornipaev’s course, describe three similar layers: stakeholder requirements state the problem and avoid naming solutions; system requirements say abstractly how the system will meet those needs; system specifications describe the architecture. The lesson matches Wiegers and Beatty: do not mix goals with solutions. The BABOK® Guide has a comparable split into business, stakeholder, solution and transition requirements.
How to apply it#
- Tag every statement you collect with its level: business, user, functional, non-functional, business rule, or project.
- Trace each functional requirement up to a user requirement, and each user requirement up to a business objective. Anything that traces to nothing is either unnecessary or a sign of a missing objective.
- Move project requirements into the project plan.
- Keep business rules in their own list and reference them instead of copying them.
Example#
For The Workshop, a fictional chain of 12 bike-repair workshops:
| Kind | Statement |
|---|---|
| Business requirement | Reduce phone calls to front desks about bookings and repair status by 30% within a year of launch. |
| User requirement | A customer can book a repair slot online at a chosen workshop. |
| Functional requirement | The system shall show the available repair slots at the selected workshop for the next 14 days. |
| Non-functional requirement | The booking page shall be available during all published opening hours. |
| Business rule | A booking can be cancelled free of charge up to 24 hours before the slot. |
| Project requirement (not in the SRS) | Train front-desk staff at all 12 workshops before go-live. |
Pitfalls#
Wiegers and Beatty list six warning signs of trouble with requirements:
- Too little user involvement. The analyst documents an ideal process, not the real one. The book describes a tax department the team did not know existed for months.
- Careless planning. A rough guess is heard as a commitment.
- Creeping requirements. Filter every new request through the business objectives, scope and success criteria, and keep planning buffers. In agile work, the backlog does this job.
- Ambiguity. Each reader finds their own reading sensible, so a friendly read-through misses it. Use formal reviews, test cases or prototypes.
- Gold plating. Developers add features nobody asked for. Trace every function to a source.
- Overlooked user classes. Include indirect users and hidden stakeholders such as regulators, support staff and data-migration specialists.
The authors cite research attributing roughly 40–50% of software defects to requirements errors (Davis), and argue that requirements work is an investment rather than a delay.
Sources and further reading#
- K. Wiegers, J. Beatty. Software Requirements, 3rd ed. Microsoft Press, 2013, ch. 1.
- I. Kornipaev. Requirements Management, course slides (in Russian) — presentation of the Hull, Jackson and Dick model.
- E. Hull, K. Jackson, J. Dick. Requirements Engineering.
- IIBA. A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), version 3. International Institute of Business Analysis, 2015.