Karl Wiegers wrote the book on structured requirements – Software Requirements, 2nd Edition, Karl E. Wiegers.
If you are involved in managing requirements, you should own this book. Even if you don’t follow his approach to managing requirements, or don’t like how he deals with use cases, you should still read this book – at a minimum, you’ll know more about it than your pointy-haired boss who reads this blog, sees this post, and tells you that you must follow the Wiegers way.
He details his framework, tells you how to use it, and how to manage requirements in it. Karl also has a website, processimpact.com, chock full of resources.
Karl proposes that there are three distinct levels of requirements
- Business requirements - Goals of the business like “increase profits”, “improve branding”, “become dominant in a market”
- User requirements – Goals or tasks of the users of software like “create purchase order”, “find a book my wife would like”
- Functional requirements – Functionality that the software must include like “calculate profit-maximizing price” or “generate Sarbanes-Oxley compliance report”
He also classifies these requirements as either being functional or non-functional.
Functional requirements describe what the system must do.
- Provide a history of transactions for auditing purposes
- Enable users to listen to samples of the music on the CD
Non-functional requirements constrain how the system must do it.
- Most relevant search results will be returned in under 5 seconds
- System will be available 99% of the time between 9 AM and 7 PM Eastern time
Karl then presents these types of requirements with a structured classification. His structure shows different types of requirements driving other types of requirements. In the picture below, we would see that a business requirement (increase profits) drives a user requirement (define product prices) which drives a functional requirement (calculate profit-maximizing price).
I believe a simplified version of this diagram (which is a simplified version of a diagram from page 9 of his book) makes it easier to introduce the concepts.
In a presentation to a class at St. Edwards University last fall, I presented the following single slide.
Summing it all up
Goals are achieved through use cases.
Use cases are enabled by functional requirements.
Functional requirements lead to design and implementation.
Non-functional requirements characterize how functional requirements must work.
Constraints restrict how functional requirements may be implemented.
[Update 2007/02/26]
I’ve refined my thinking about how structured requirements should be represented. In short, I feel that non-functional requirements are under-emphasized in the real world. I proposed a modified view of structured requirements, designed to increase the level of attention given to non-functional requirements. I go into more detail in the article, Non-Functional Requirements Equal Rights Amendment. Here’s the diagram of the structure that I proposed in that article:
- – -
Check out the index of the Foundation Series posts for other introductory articles.
Latest Articles
Comments on all Articles
