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.
This format is very reminiscent of Nam Suh’s Axiomatic Design. Functional Requirements (FRs) define the set of goals that the design must satisfy. Design Parameters (DPs) are the means that solve these goals. By mapping these parameters and establishing their relationships, the proposed system can be classified as coupled, uncoupled, or decoupled. There are two central axioms in Axiomatic Design: 1) Independence of FRs and 2) Information (minimize design complexity).
I attended Suh’s class at MIT and relied on these techniques heavily in my thesis. One great aspect of this work is that it is applicable for all industry. For more details, read his book “Axiomatic Design.” Understanding the underlying theory of this methodology can enhance your problem solving skills.
Thanks Kristina for the comments. In really liked the sample pages for Suh’s book at amazon (added to Tyner Blain’s bookshelf).
He used a simple description of the design process:
A. Know the customer’s needs
B. Identify the problem to be solved
C. Create a solution idea
D. Analyze the idea
E. Test that the design (C) meets the needs (A)
This is consistent with the high level view of software processes identified in the foundation post on software processes:
1. Decide what to do (combines A & B)
2. Do it (combines C & D & E)
3. Deliver it
I’m excited to see how he treats the transitions from A to C. And I wonder if the design-complexity issues he raises are consistent with trying to avoid entanglement in OO design. Thanks for pointing out his book to us, and keep on commenting.
We’ve just updated this article to reflect our refined perspective on structured requirements. A lot of search-engine traffic makes it to this page, and we reference it a lot to provide context to many other discussions.
When we spent some time focusing on non-functional requirements, we realized that they are under-utilized, under-appreciated, and under-represented.
Generally, they are under-valued. We believe this is because they lack obvious champions.
We’ve refined our diagram to reflect the sources that drive non-functional requirements, in order to give them those champions. We covered this in more detail in our article, Non-Functional Requirements Equal Rights Amendment.
Since this article is over a year old, our feed subscribers and regular readers won’t know that it has been updated. At least those of you who subscribe to our comments-feed will know.
Thanks to all who read this, and welcome to Tyner Blain if you’re new here. Let us know what you think of this and other articles. Comment and join in the discussions, or at least rate the articles.
Hi Scott,
Just found your blog. This article is an excellent introduction into how to think about requirements. I agree that Karl Wiegers’ book is a must-read for anyone involved in requirements management.
I look forward to reading the rest of your blog during this holiday break!
Happy holidays,
Raj
Accompa – Affordable Requirements Management Software
Hey Raj, thanks for the comment and welcome to Tyner Blain!
Good luck reading all 600+ articles over the holiday. That’s too much for me – let us know if you make it!
Hi Scott,
You are correct, 600+ is too much to read over a long weekend! :)
I made some good progress though – excellent blog you have here, keep up the great writing…
Hi Scott,
I am using your approach in our project to analyse requirements since it fits well with our prespective. I wanted to ask you if this approach can be can be considered as an agile developpement process ? because you didn’t mention user story in your explanation which i believe they are the core of the agile devloppement process.
Thanks Raed for your question and welcome to Tyner Blain! You can use use cases or user stories in an agile process, either one can be appropriate.