By Scott Sehlhorst | January 24th, 2006
brought to you courtesy of Tyler Blain 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 askinghow. 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.
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.
0 Comments
Leave a Reply. |
AuthorThis is a forum of tips and links to best information to help to optimize your business - covering everything from SEO management to social networking & writing a press release to igniting a movement. Archives
January 2014
Categories |