Foundation Series: Structured Requirements


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,, chock full of resources.

Karl proposes that there are three distinct levels of requirements

  1. Business requirements - Goals of the business like “increase profits”, “improve branding”, “become dominant in a market”
  2. User requirements – Goals or tasks of the users of software like “create purchase order”, “find a book my wife would like”
  3. 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).

Wiegers taxonomy of requirements

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.

Simplified structural requirements taxonomy

In a presentation to a class at St. Edwards University last fall, I presented the following single slide.

Types of requirements 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:

Better Structured Requirements Framework

- – -

Check out the index of the Foundation Series posts for other introductory articles.

Post to Twitter Post to Facebook

This article was published on Wednesday, January 4th, 2006 at 11:19 pm and is filed under Foundation series, Process Improvement, Requirements, Software development.
You can leave a comment on this post


  1. Kristina Kuest Mistry

    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.

  2. 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.

  3. 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.

  4. 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,
    Accompa – Affordable Requirements Management Software

  5. 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!

  6. 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…

  7. I’ve been browsing online more than 2 hours today, yet I never found any interesting article like yours.
    It is pretty worth enough for me. Personally, if all website owners and
    bloggers made good content as you did, the net will be much more useful than ever before.

11 Trackbacks

  1. By Tyner Blain » Where bugs come from on January 22, 2006 at 3:15 pm

    [...] The process starts with stakeholders (all beneficiaries of the software system to be deployed, including users) identifying their objectives. [...]

  2. [...] When functional requirements are described too abstractly, they don’t provide enough information for implementation teams to properly scope the project. They also introduce too much risk – risk that the delivered product will not meet the needs of the stakeholders. Some examples: [...]

  3. [...] [C1] Additional user interaction will not be required to display the city forecasts. {This constraint affects requirement [R1]} [...]

  4. [...] Requirements. Different processes will use different names for these. In a process that uses structured requirements, this is the functional requirements, user requirements and business requirements. These can be captured in an FRS, SRS, or PRD (but please no, not all three!). [...]

  5. [...] Prioritize requirements based upon their explicit impact on profitability. With requirements traceability, we can break down the impact of supporting requirements as a percentage of the impact of those requirements that they support. This represents implicit value for a particular requirement. This is one of the benefits of using a structured requirements framework. Also, when using composition in requirements, we will distribute the impact assessment to the sub-requirements. [...]

  6. [...] Background: In our previous post, Sample use case examples, we created two informal use cases. The use cases were written to support product requirements defined as part of a project to reduce test suite maintenace costs. In this post, we will define functional requirements that support these use cases. This process is an example of using structured requirements, applied to a small real world project. [...]

  7. [...] Product requirements. In a process that uses structured requirements, these are the functional requirements, user requirements and business requirements. Design constraints are also requirements (non-functional requirements). Product requirements can be captured in an FRS, SRS, or PRD. [...]

  8. [...] Scott Sehlhorst at Tyner Blain has a great article about structured requirements. He simplifies Karl Wiegers’ ideas into a great little chart: [...]

  9. [...] Use cases are derived from user goals and use cases drive requirements.  In the context of a web application, a user goal might be to search for a CD to purchase.  That would give us a use case that would be called ‘Search for CD’, or maybe something more broadly titled in the case of an Amazon like site ‘Search for Product’.  Of course, it isn’t long before someone suggests an advanced search feature, so we have to decide whether that constitutes a new use case or an alternative path to the existing use case.  Then someone suggests tools tips would be helpful and another suggests a breadcrumb trail.  So, are these things that are included in an existing use case or do they constitute their own use case? [...]

  10. [...] variações em torno desta visão são curiosas. Tyner Blain, por exemplo, parte de uma uma sugestão de Karl Wiegers para gerar a visão representad…. Mas, caramba, não vejo ninguém afirmar com todas as letras que “passos em um caso de uso [...]

  11. By Youngkuk Kim on July 25, 2010 at 5:01 pm

    RT @sehlhorst: Foundation Series: Structured Requirements

Post a Comment

Your email is never published nor shared. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>