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.
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.
Scott, I very much appreciate your patient, respectful, and insightful approach to continuing this dialog. Unfortunately, I don’t think we can stick a fork in it yet.
A few things:
1. I should not have implied that you favor producing every document (MRD, PRD, FRS, SRS). My real point is that I don’t think it’s possible to reconcile all of the terminology (“market requirement”, “product requirement”, “functional requirement”, “nonfunctional requirement”, “software requirement”) associated with these documents. I’m even struggling to understand how you reconcile PRD terminology with SRS terminology (see #2).
2. As I see it, one of your examples of a product requirement, “The system shall reccommend ingredient purchase amounts and timing that would reduce spoilage by at least 50% against the baseline,” is a combination of a functional requirement (“The system shall recommend purchase amounts and timing.”) and a nonfunctional requirement (“Spoilage stemming from the system’s purchase recommendations shall not exceed 50% of the baseline amount.”). How do you reconcile this example with your contention that product requirements “are neither functional nor non-functional”? (I posed this question in a comment on your “Valuable and Functional Requirements” entry.)
3. I certainly do not deny that people use the word “requirement” and related terms in many different ways. Indeed – the diverse usages of the terms are central to my point. I contend that these diverse usages are irreconcilable, and further that their incoherence and inconsistency is destructive.
4. When linguists face this sort of problem, they explicate the terms. I.e., they account for all the usages, point out the inconsistencies and inefficiencies, and extract the essence of the terms to clarify their meanings.
5. It’s a bit like math students who say that two angles are “equal”. We know what they mean, but we also know that this terminology is in some sense “wrong”. The measures of the angles are equal; the angles themselves are congruent. In the case of geometry, this terminological confusion is rather innocuous. Unfortunately, in the case of requirements terminology, the usage is so skewed and inconsistent that it reflects, and contributes to, a requirements crisis.
6. I have no issue with two levels of documents, at least in theory. I just don’t see how you can reconcile the terminology. The PRD/SRS distinction is much more linguistically coherent if you call the SRS an FDS (functional design specification) or an IDS (interaction design specification). Such a naming scheme would, in my opinion, lead to greater awareness of the goals that should drive the product and more attention to the nonfunctional requirements that never seem to get their due.
Thanks Roger!
We’ll keep the conversation going on this one – maybe some other folks will chime in as well.
Scott
Scott, I totally agree, and wanted to provide some insight on things from my side — I’m in a *really* small start-up now (14 people — 3 developers and 1 product mgr…myself) and was in a pretty small start-up prior (80 people…15-20 developers around the World and 1 product mgr…myself).
There is a key factor that we may not be hitting on here too — the number of products involved and the tech stakeholder involvement. Really quick point here is, if you have 1 product (typical start-up), EVERYONE in the company wants to own it and feel like they are helping it get better. That means, and this is something I push, everyone must wear the Product Mgmt hat at some point. If you have multiple products, it’s easier because folks are more spread out in terms of where their interests lie. It’s much easier when there is more than 1 to foster a product-centric environment. But, I digress.
You are right in that, typically, product vision is driven from the top – especially in a startup. CEO / CTO / VC (let’s not forget them) comes up with an idea, and delegates responsibility for creating the thing and the PM must point out flaws along the way. Also, she must take initiative for actually getting the thing built. If you are not pointing out ways the idea can be made better, or if that’s not fostered, there are bigger issues. A person’s title must be forgotten to unabashedly create excellent products. You should all be on the same team – the customers.
That being said, I’ve created 1 template in the past that I’ve found to work well — an FRD (Feature Requirements Document) template. I define a feature as being a container for requirements, whether functional and non-functional. They can all be wrapped into one doc, and can be clearly pointed defined. Here’s the structure I have in the template:
– Introduction / Overview
– Feature vision
– Requirement Themes
– Actors
– Functional Requirements
– Non-Functional Requirements
Prior to this, I would generate a simple vision doc that would outline at a 50,000 foot view what the hell my FRD doc was talking about. This would get the point across to everyone that it needed to, then the content would be rolled into the FRD, and the Vision doc would be effectively destroyed. We are now just down to 1 doc defining everything about a feature / module / whatever. It’s not a matter of the # of docs, because in theory, you would have more than a single FRD (and it works more effectively if you do) if you were defining an entire product from scratch. This allows you to divvy up FRD’s between developers more easily and not suck out time by having valuable tech resources reading about the “vision” for something they aren’t working on. So long as they get the bigger picture of the product as a whole (and that’s much important), dev should be golden working this way.
Now, that was for the company with 85 people, in which product development was dominated with feature requests made by clients VIA Services, and the product roadmap had to fit what clients were paying for. It was a high-quality revenue stream. Right or wrong — that’s how it worked.
In the company of 14, we don’t support queue jumping / roadmap hogging as a revenue stream, so it is all proactive. It’s bliss, let me tell you. More time to spend on the market as a whole instead of those that yell the loudest. My comment about me drowning if I had to write out all those docs revolves around two absolute truths:
1 – They would take me at least 3-4+ weeks to generate
2 – I can get the point / req’s across in a bulleted list in 1-2 days for a complete product with over 100 features of all sizes (tiny to full-scale / platform entwined beasts)
My logic is, each feature I recommend, I better make damn sure I have a justification for doing so, because my VC, CEO, and CTO are going to have my hide if I don’t. They all understand I work for the customer at the end of the day, and for me, that’s just not a fed line; I really do operate & feel that way. As an aside, I’m always of the mind that opinion matters for absolute 0 in making product decisions. Unless it’s a) good for the customer and b) you can prove it’s good for the customer, it’s useless and should be shelved.
Now, if I were to take 3-4 weeks to generate documents that I could completely NULL and void if I were to call up the CEO and say, “hey — here’s my bulleted requirements list, let me tell you why I want to do features 5-10, all the others should be obvious,” that saves everyone in the company time, and thus saves overhead, and thus saves money. And that’s the name of the game for me…I just don’t see how it’s not the name of the game in all companies. There’s nothing touch feely here — just get ‘er done (JGET).
I think more often than not, and I’ve gotten this from talking to some of my best friends that work in large Org’s, must of this “communication” stems from everyone trying to cover their ass and not want to make mistakes. While massive companies can claim all they want that they foster “teamwork” and environments where their folks are allowed to falter, I just don’t think it’s true. It’s built into the culture that if you make a major mistake, your kicked to the curb and the guy waiting in line for your job takes over.
So, my thinking is, this stuff is much broader than a PM generating *RD/*RS documents. I lean towards thinking they exist because if they didn’t, it would mean people really have to trust their team and peers and directs. From what I understand, it’s not your manager doing your performance review each year deciding how much food you’ll be able to put on the table. If you work for Scary Monolithic Corp, Inc. it’s some HR associate that you’ve never met before and their MO is “save the bottom line.” Yikes.
Make mistakes. Big companies have money — fight for it to actually go and talk to the product team face to face. Buy Webcams and use Skype to talk regularly. I feel that people are generally smart and *want* to get it; they want to buy in to the vision and do a good job. Work to foster the environment with dev where questions are the norm and no one is called out for asking one that’s stupid — Jack Welch taught me that there is no such thing. That’s the msg I give to my team.
I think at the end of the day, relationships would be better, a team would be stronger, and a PM’s time wouldn’t be sucked up generating paperwork. There’s no reason why all of the *key* elements of these things can’t be combined into 1 document and then discussed. The truth of the matter is, a developer is only reading & caring about 1 thing – how can they make the requirement work elegantly, and be creative at the same time. Requirements aren’t about solutions — that’s spec, and that should be coming from a tech lead anyway, not a product manager. And yes, I could see how a spec doc would be 1,000 pages, especially when you are dealing with a system responsible for billions of dollars for example.
Anyway, talk about rambling! I’m sure I’m overlooking the need to communicate high amounts of detail. Maybe I’m just spoiled in that my CTO and I are really on the same page and we get what the other is trying to accomplish.
I’m really enjoying this discussion and hope that we can agree on some points — at least between the three of us. Hey, maybe Steve Johnson is reading and will work it into Pragmatic… =)
Adam,
Sounds like you have a sweet gig! Great points about how to stay focused in a startup environment too.
I agree that the CYA mindset does happen a lot at large companies. I think we’re really on the same page, and that the product manager should focus on, well, all the strategic stuff Pragmatic outlines.
Different team sizes will split up the work differently (vision vs spec vs design vs implementation).
“Hey, maybe Steve Johnson is reading and will work it into Pragmatic…”
As far as I can tell, Steve Johnson is on record largely agreeing with my view. See his article, Reqs and Specs, for details.
He distinguishes between requirements and specifications, and then enumerates the following roles:
– the product manager finds and quantifies market problems, articulating them in the form of requirements
– the product architect (or designer) writes a functional specification describing the approach to solving the problem
– the product developer creates a technical specification that fully describes how the functional specification will be implemented
As you can see, Johnson mentions three types of documents, but he considers only one of them a requirements document.