From MRD to PRD: The key to defining a spec
They key to writing a great spec is knowing how to specify software that mets our customers’ needs.
It can be a daunting task. First, we have to define what our customer needs. High level requirements are just requirements that are too vague or high-level to be directly actionable. “We must reduce our cost of fullfilling orders by 20%” is a high level requirement. We can’t start writing code with only that information. In an early post, we talked about functional requirements being written at the right level - don’t confuse the level of clarity required for writing a functional spec with that required to define goals.
A market requirements document (MRD), as we discussed earlier, discusses the problems (to be solved) or the needs of the market. When working with a customer, that customer will identify one or more strategic objectives.
As an aside - this case study demonstrates use of the OST (objectives, strategy and tactics) approach to initiating and managing projects. Check it out for context. You can just skim the bold parts in the OST sections if you want to stay on topic with this post.
The question is - How do we get from an MRD to a great PRD?
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.
We’re not talking about specifying implementation details - just articulating capabilities. Here is a list of “market need : product capability” that demonstrate the transition from MRD to PRD.
- Customers are cancelling 5% of their orders because of shipping delays : Software will enable shipping within 24 hours of order
- Our competitor is gaining market share by offering free plugins : Software will support a plug-in architecture
- 80% of potential customers (visitors) leave our website without ordering : Navigation must be simple on the website
- Our software keeps crashing and we don’t know why : Software will send error information from client to server
One of the things that makes this requirements design activity so difficult is that we have to have good ideas about how to solve the problems we are tasked with solving. Look at example number three - there are many different ways to attempt to solve the problem - the challenge is in picking the right one. Requirements elicitation will unearth the required capabilities.
Organizing, validating, and prioritizing these capabilities is the hard part. The output of this effort is a PRD. A product roadmap (a vision of what a product will be capable of doing, over time) is another potential output.
(Be The First to Rate This Article)
Loading ...
Add Tyner Blain to Google Toolbar
January 24th, 2006 at 10:46 pm
A lot of this terminology - MRD, PRD, market needs, product capabilities, requirements, design - is subject to debates about semantics. I personally don’t see much need to have two separate requirements documents, but I do accept the distinctions between strategic objectives and product requirements.
Just to try to bring some clarity to some of the terms: I would not portray things in terms of market need and product capability. Instead, I would go from:
problem -> requirement -> design
Example:
problem - 20% of customers quit using the product after trying it the first time, expressing frustration about how difficult it is to use.
requirement - 95% of customers with skills a, b, and c should be able to accomplish goal x in y amount of time using the product the first time.
design - present an optional wizard-based user interface for first-time users.
Ideally, the requirement does nothing more than state a pass-fail measurement expressing whether the product has solved the problem to a sufficient degree. Any specification of “product capability” beyond this measurement is, as you state, design. I don’t see any reason to call such a further specification a “requirement”.
Furthermore, I don’t see design (whether high or low level) or “product capability” as the purview of the product manager. Architects and user interface designers are by definition the experts on such matters. A single person can be well qualified to play all these roles, but the roles are distinct.
January 25th, 2006 at 7:54 am
I completely agree that the flow is from problem -> requirement -> design.
There is ideation at each stage.
Prioritizing the right problems to solve, selecting the articulation of the requirement (sometimes the solution isn’t even in the software), and designing the software are ALL ideation activities.
To focus on “requirements design” - there are several different ways to address any particular problem. Using your example of first time users failing to use the software effectively, there are multiple ways to address the problem:
Each of these “requirement designs” would drive different software design decisions.
On another point - I would be careful of using “95% of users”, as that either introduces a burdensome cost or a sense of false precision. There is significant effort in actually assuring that X% of users can do anything - and you would actually have to state “with Y% degree of confidence” for the requirement to be unambiguous. This is an expensive process, and misleading to anyone who hasn’t studied statistics. It would be better as a general rule, IMHO, to simply say “customers with skills a,b,c…” - and then evaluate subjectively based on anecdotal data. For critical usability concerns (can the guy in the silo enter the launch codes) - spend the money, but clarify the requirement first.
Thanks again for your comments - they are frequent, provoking and helpful, and very appreciated!
January 27th, 2006 at 4:37 am
I would be hesitant to put these all in the same bucket:
> 1. Specify that goal X is achievable in Y time.
> 2. Eliminate goal X and replace it with goal Y.
> 3. Market the product to a different user group.
> 4. Users must be trained to use the application.
(1) is most likely a requirement, (3) is a strategic decision that impacts requirements, and (4) is almost certainly a design choice. (2) depends a lot on the context.
January 27th, 2006 at 7:45 am
You’re right - my examples don’t work well as a group. The point I was striving to make is that there isn’t a thought-free conversion from a market requirement to a product requirement.
The best way to articulate what part of the problem the software needs to address is not self-evident. I think keeping seperate notions of “this is what is wrong” and “this is what we’re going to solve with the software” is valuable.
February 1st, 2006 at 11:22 pm
[...] A functional spec is a single artifact, generated from a living repository of information about what needs to happen for a software project to succeed. It is not a static document. A solution can be described differently for different audiences and to achieve different objectives. The source code is a description of the functionality - a quite explicit one, describing exactly how it works (if you know how to read it). A design document, or a UML diagram, or an E-R diagram is another description of functionality - and it describes how a system is supposed to work. Most technical people can read a design document, but stakeholders may still be in trouble. A functional spec describes what a system is supposed to do without describing how the system does it. Larger audience, different objective. “Above” the functional spec lives a set of use cases, which describe how someone uses the system - again, different objective. “Above” the use cases lives a product strategy, or the objectives and benefits inherent in the system - what the system should enable, and why the system should do it. [...]
February 8th, 2006 at 7:47 am
[...] We start with identification of the problems or opportunities, before defining what the requirements will be. This is the same process we discussed in From MRD to PRD, applied to the test-automation space. The following are the top five problem areas we can identify about test automation suites. [...]
February 9th, 2006 at 12:24 am
[...] In an earlier post, From MRD to PRD, we talked about the fact that there is design involved in converting from a defined opportunity into a goal for software. In this post we will look at a real world example of doing just that. [...]
February 13th, 2006 at 6:25 pm
[...] We propose that when discussing the software development process, the term design should not be applied to the act of creating a PRD from an MRD. [...]