Requirements Context

Dubai Hotel Tennis Court / Helipad

Understanding someone’s perspective on requirements requires that you appreciate the context in which they’ve formed that perspective. Not everyone is playing the same game on the same field.

Words and Symbols

When someone says “write a test case”, we may wonder if they mean system test, or unit test, or user acceptance test, or regression test. Without more information, we don’t really know what they mean. But we do know that they aren’t talking about implementation or design or requirements gathering – they are talking about testing.

When someone asks “document the requirements”, we don’t know what they are talking about. They might mean market requirements, or product requirements. They may mean functional, or business, or user requirements. As product managers and analysts, we have to understand the perspective of the listener before we can determine which type of requirements document is required.
The very word, requirements, has become a touchstone for debate – almost the third rail of software development. There are two factors that create the semantic debates about what requirements are and are not.


Every person on a software development team works within a given framework. From that perspective, there is a notion of why something needs to be done. An individual has an idea about what he needs to do. And while he may delegate getting stuff done, he will still talk about how it needs to be done.

The variations in framework have spawned many different requirements documents.

Even when we recognize that there are different ways of perceiving why, what, and how, we still run into a problem when debates involve the use of the word requirement. The word has developed a symbolic representation for many people. The problem is that the symbol is ambiguous, because it doesn’t mean the same thing to everyone.


Roger commented on our recent article about defining product requirements to support market requirements. In that article we showed a transition from market requirements (clarity of vision, too vague or high level to be actionable) to product requirements (a given approach to solving a market problem). Roger wanted to know if use cases fall in the space between market and product requirements.

No. :)

In a structured requirements approach to documentation, we have a diagram that looks like the following:

structured requirements

We also wrote about combining interaction design with a structured requirements approach.

In both of these situations, use cases live between goals and the functional spec.

Market and product requirements are both at the “Goal” level. [More detail in this article]. Use cases are used to convert a vision of how a product will exploit a market opportunity. Use cases describe how the product will be used. And functional requiremens enable communication between the business and the implementation team.

User cases live between product requirements (GOALs, above) and a functional requirements spec with enough detail to allow people to follow it.

2 thoughts on “Requirements Context

  1. Okay, so if I understand your semantic framework correctly, we have:

    market requirements – goals to achieve to solve market problems
    product requirements – goals for the software or product to achieve
    functional requirements – what developers should build

    But then:

    1. Can a market requirement be functional?
    2. Can a market requirement be nonfunctional?
    3. Can a product requirement be functional?
    4. Can a product requirement be nonfunctional?
    5. Is it the case that every requirement is either functional or nonfunctional?
    6. Are the functional requirements what the developers should build, or do they need both the functional and nonfunctional requirements to know what to build?

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.