Types of software requirements: Business, functional, stakeholder, and 'real'

Expert Robin Goldsmith explains the different ways that requirements are categorized, explaining the difference between 'whats' and 'hows.' Goldmith recommends what he refers to as 'real' business requirements driven down to detail and are always business deliverable 'whats' that provide value when met.

What are the requirement types and how do they fit into requirement levels? I've read that there are a variety of types.

The concepts of requirements types and levels can be both helpful and misleading, so it's important to understand them accurately. I'm aware of four different ways that people commonly categorize requirements types:

1. A very widely-used classification says business requirements are high-level vague statements of goals, objectives and needs which decompose into detailed product, system, software or solution requirements (which often are just called the "requirements"). I refer to this as the "levels model," because it says the difference between the two types is merely a level of detail or abstraction.

2. Probably the most widely-used classification distinguishes functional requirements (behaviors or features the product must performs) from non-functional requirements, which describe quality characteristics and operational constraints (and thus often are called "quality factors," "quality requirements," "supplemental requirements," "environmental requirements," "attributes," or "ilities"--because so many sub-types end in "ility" such as reliability, usability, and testability). Both are subsets of product requirements.

3. Many authorities, such as the IIBA BABOK®, distinguish stakeholder [or user] requirements that frequently are documented in use cases describing a given stakeholder's needs and how that stakeholder will interact with a solution.

4. I use (I believe) a more accurate classification that overcomes flaws in each of the above common categorizations. Real business requirements are deliverable whats that provide value when satisfied by a product, system, or software how whose requirements describe presumed ways to satisfy the whats.

Real business requirements are not goals and objectives but rather achieve them when satisfied. Real business requirements need to be driven down to detail and are always business deliverable whats that provide value when met. Whats do not decompose into hows.

Product requirements hows are responses to whats. Creep occurs when people go directly from high-level business requirements whats to detailed product requirements hows without first detailing the whats. For an example of hierarchical decomposition that doesn't change a what into a how, see my tip, What Is a Test Case? What Is a Requirement?

Stakeholders are the source of all real business requirements. Stakeholders include but are not limited to users. What are commonly called "user requirements" actually are usage requirements of an expected product design. Real business requirements refer to (business) functionality and categories considered non-functional. The distinction prompts making sure attributes don't get overlooked; but quality factors are requirements only with regard to required business functionality. You don't just need a bunch of usability. Instead, you need certain, and often different, usability characteristics for each functional real business requirement.

Dig Deeper on Topics Archive