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.
Framework
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.
Symbolism
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.
Structure
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:
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.
Conclusion
User cases live between product requirements (GOALs, above) and a functional requirements spec with enough detail to allow people to follow it.
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?
Hey Roger, thanks for the comments and loyal reading!
Sorry it took so long, but I put together an answer in today’s article, Valuable and Functional Requirements