Q
Problem solve Get help with specific problems with your technologies, process and projects.

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.

This was last published in November 2010

Dig Deeper on Software Requirements Gathering Techniques

PRO+

Content

Find more PRO+ content and other member only offers, here.

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

-ADS BY GOOGLE

SearchMicroservices

TheServerSide.com

SearchCloudApplications

SearchAWS

SearchBusinessAnalytics

SearchFinancialApplications

SearchHealthIT

DevOpsAgenda

Close