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.
Latest Articles
Comments on all Articles
