Robin Goldsmith wrote an interesting article for RQNG about business requirements – what he calls “REAL” requirements. Gathering the right requirements demands more than just effective listening skills, you have to focus on the right problem. Robin brings up a theme we’ve discussed here in the past, and again in today’s article.
Business Requirements
Robin defines business requirements first by what they aren’t. Business requirements are not system requirements, product requirements, or software requirements. He contends that those terms are synonymous. The terms definitely share the same level of abstraction. Product requirements embody an element of design. To define product requirements, you have to choose to address the business requirements with a particular solution approach.
Yes, business requirements are real requirements. And you’ll find yourself nodding your head as you read how most business analysts struggle to define business requirements. They do a good job of defining product requirements, or functional specifications (the system shall…).
The article reads as a very single-customer-centric viewpoint. This is perfect for business analysts. Product managers need to abstract this into market requirements – those things that are valuable to all businesses in the target market. In either case, the points are valid – business value is the goal.
Product Requirements
Here’s a quote from Robin that we completely agree with:
The difference between REAL business requirements and system requirements is not the level of detail. The difference is qualitative. Business requirements are whats. System requirements are design hows. Design doesn’t have to be technical. A product or system is a presumed solution how to accomplish the presumed whats. Whats do not decompose
into hows. Hows are a response to whats.
A little over a year ago, we put it like this:
A product requirements document (PRD) captures the capabilities of the software in order to address the market needs. From these key capabilities comes the design of the software. How do we get from needs to ideas?
This is an ideation task. A product manager must apply high level design skills when writing the specification. Haven’t we said repeatedly that requirements should not describe the implementation or design? Yes. Previously, we talked about the importance of asking why, this is the same issue, approached in the other direction – starting with the why and asking how.
With that in perspective, we turn to project scope creep.
Project Scope Creep
Everyone experiences scope creep on projects. Scope creep can be an opportunity. Even with a good approach for managing project scope changes, it still benefits us to prevent them.
We’ve written about the impact of requirements changes before, as part of our series on the reasons we write use cases. In that article, we mentioned that all requirements change. What Robin points out, that we didn’t talk about, is that market requirements (business requirements) don’t change very often.
He’s exactly right.
Consider the need from our previous market requirements example:
Sole-proprietor restaurants are losing over 5% of their top line sales in food spoilage.
That dynamic isn’t going to change in the near term. The product requirements, once a decision has been made to solve the problem with software are liable to change.
The market requirement:
Sole-proprietor restaurants will reduce the amount of food spoilage by 50%, by making better food purchasing decisions.
Is addressed through two product requirements:
- The system shall reccommend ingredient purchase amounts and timing that would reduce spoilage by at least 50% against the baseline.
- The system shall allow users to ignore its reccommendations.
Additional decomposition of the problem would represent design or could be considered elements of an SRS (which, being a specification, is either design or requirements – depending upon your perspective).
Coupling Business Requirements To Product Requirements
This is the interesting part – the more tightly (effectively, rationally) the product requirements are coupled to the business requirements, the less change we will have in project scope over time. However – the key is to define the scope in terms of the business requirements (reduce spoilage), not product requirements (reccommend purchase amounts).
Conclusion
If you struggle to define business requirements, and find yourself focusing too much on product requirements, take Robin’s advice (and ours) to heart. Focus on business requirements.
I agree completely with the point you’re trying to make, and I know you worded things carefully to avoid a debate over semantics that might distract from the underlying point.
But I do have to note that Goldsmith implies that “system requirement” is a misnomer:
“System requirements represent a human-defined product or system which presumably is one of the possible ways presumably how to accomplish the presumed REAL business requirements. As such, system requirements actually are a form of high-level design.”
And he also implies that nomenclatures that categorize so-called “system requirements” as requirements are partially to blame for substantive, practical problems:
“[T]he primary reason the REAL business requirements are not defined adequately is because conventional requirements models mislead people into believing that system requirements are the requirements and thus warrant all the attention.”
Again, I agree with your point and believe that your underlying thrust is the same as Goldsmith’s. But I do think it’s important to recognize that semantics are very relevant (in a substantive way) to the issue, in my view, and apparently in Goldsmith’s view.
Thanks Roger. I was definitely staying “on message” with the value-drives-requirements point. And Robin’s presentation of this idea does lend support to your argument (which I’m not trying to cover here :).
Thanks,
Scott