
The discussion about requirements and the naming of things continues. Can we stick a fork in it already? Maybe, but probably not. Catch up on the cross-blog discussion with Roger and Adam. Long time readers may also remember the discussions that included Michael and Tony several months ago.
Recent Discussion
The latest round of discussion started with the following articles (and comments/questions from Roger):
Market Requirement Valuation Example
This is our market requirement.
Sole-proprietor restaurants will reduce the amount of food spoilage by 50%, by making better food purchasing decisions.
From Market Requirement to Product Requirement
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.
Requirements Context
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.
Valuable and Functional Requirements
Market requirements and product requirements can be characterized based on value, but are undefined along the functional/non-functional axis. The requirements that make up a specification can be classified as functional or non-functional. And these are the requirements that drive design. Design boundaries are defined by constraints.
Which inspired Adam to write a pretty strong critique of “big upfront requirements” (BUFR) from the startup perspective.
While I don’t discount the usefulness of this type of information, I’d drown if I had to write something like this. MRD, PRD, SRS, FRS — acronyms galore. […] This is just an observational post about how the start-up environment I’m in is so much different.
To which I responded with a long and rambling response.
And trust me when I say I share your concerns about the complexity and acronymity of the big company software development process. I think the situation has evolved as a result of mixing the bureaucracy of big companies with the need to delegate responsibility.
[…]
Requirements documents are all about communication. There’s a vision that someone sets for a product or project. When that person has direct, regular communication with the team that makes this product a reality, then the documentation approach will be very different than when a distributed team of fifty people are all three steps removed from the person with the vision.
Another factor is specialization. When a person has the opportunity to play multiple roles, she don’t need an artifact for communicating with herself. And the distinction between a product requirement, a software specification, and a high level design is academic. Her thought process should be focused on “is this a good idea?” not “am I putting design details into the specification?”
Which prompted Roger to respond.
I have been struggling to understand Scott’s requirements framework. My suspicion has always been that the MRD/PRD/FRS/SRS onslaught of documents:
1. Is harmful to organizations (startup or not) that produce them all.
2. Employs terminology (”requirement”, “functional”) in a logically inconsistent or highly inelegant fashion.
3. Reflects a substantive misunderstanding of requirements.
In short, I do not believe, as Scott states, that the distinctions are “academic”, even for a “vertical operator”.
[… more good stuff and a concrete example from Roger…]
But Scott isn’t your typical requirements analyst, which is why I look forward to his continuing the discussion I’ve started on his blog.
And Roger also posted an article including a conceptual model on his blog.
Summary To Date
Whew. Fun stuff, and a lot going on. There is a lot more going on in each of the posts and in the comments – I tried to tease two ideas.
- There are a bunch of requirements document formats. They all talk about requirements in different levels of detail. Roger says this is harmful, is logically inconsistent, and demonstrates a substantive misunderstanding of requirements.
- The distinctions reflected in the above are / are-not academic.
Document Formats and Abstraction
Yes, there are a bunch of different types of requirements documents in use today. Using all of them on one project is bad. We should use either the MRD or the PRD, combined with either an SRS or an FRS, to create a design. From that design, a solution is implemented. Roger is right – all of these documents should never be used on the same project.
Can any of these document types be completely eliminated? Is my “framework” suffering from the same problem as the vista shutdown featuritis? The different documents are designed to do different things, for different people. Each of those people can reasonably interpret the intent of the document to mean either what, why, or how, depending on their perspective. For the record, I am not proposing a “framework” that uses four levels of requirements documents plus a design. I use the word “or” quite a bit.
Requirements documents are intended to communicate. When a team is structured with horizontal contributors (read the comments on Adam’s article if you haven’t already), a horizontal decomposition is both justified and constructive. But two layers is sufficient – MRD/SRS or PRD/FRS. When team members have vertical skills, then a vision-statement combined with some prototypes may be more efficient.
The Naming Of Things
Naming is an outgrowth of context. A “requirement” is synonymous with “a reason why” we do something – because it is required. When people operate at different levels, the problem is being decomposed into different notions of why and what (and how). For any given person to describe their “why” as a requirement is not unreasonable.
“Reflects a substantive misunderstanding of requirements?” How about “Summarizes perspectives that are not my own?”
The usage of the word “requirement” is permanently entrenched in the vernacular and is overloaded with multiple meanings beyond the single meaning identified in Roger’s conceptual model. We’ll never escape or change this. Perhaps Roger and I disagree because he wants the word to only be used one way, and I want people to be aware of (and tolerant of) all the ways that people use the word.
Academic Distinction
The distinctions between product requirements, software specifications, and design are highly relevant to “horizontal” players. Roger is right about that.
Imagine a start-up team where the CEO creates the vision for a product and the lead engineer decides how it will actually be built. The distinction between the vision/requirements and the specification/design is also not academic (another point for Roger). The distinction, to that engineer between the specification and the design is academic (half a point deducted).
If the distinction between a spec and a design, when the same person is responsible for both, is not academic, then what is the benefit of putting them into separate documents? The documents are intended to communicate. Who would be communicating with whom? For a large (horizontal) team, it makes sense to have a document that allows a product manager to communicate with a lead engineer. Especially if the team is geographically distributed or outsourcing.
Conclusion
Small companies and large organizations operate differently. They staff projects with people who have different skill sets, and expect those people to deliver different things.
Requirements documents are intended to communicate. Different teams need different communication, and therefore different documentation approaches. One size does not fit all.