Ask A Good Product Manager

Your product management questions answered

Should my requirements documents include all requirements or just new ones?

Posted on February 7, 2011 · 6 Comments

Question: How should I handle requests that my requirements documents include all features, not just new ones?

I recently joined an organization that develops software for life sciences, a highly regulated industry. As a vendor in this vertical, we are constantly audited by clients for our quality practices in software development. We are about to launch a new product line and the question of Product Requirement Documents have come into play. Our Quality Management team has asked my team to continue carrying requirements from older product releases into the PRD for the next product release version. My software product management career has typically involved writing “delta” PRDs – the net-new features that are going into the product, rather than one large document that covers 100% of the new product’s functionality. This is the case where the PRD serves as an internal communication tool with Engineering and Marketing but also an outward facing document that may get audited by multiple clients. Has anyone worked with writing requirements that carry 100% of the functionality forward with each new software release PRD?

Answer from Tom Leung of Always Be Shipping: Yikes, that’s not the most sexy assignment I’ve ever heard so accept my condolences. That said, it’s clearly an important requirement given your industry and low tolerance for product error. Here are some suggestions as you embark on this old-school, document heavy approach.

  1. If you’re new to the life science software world, make sure you grock why they need so much detail. Ask “why?” a few times to really nail the underlying need. Talk directly to some of those outside clients who might audit this doc. This may result in you doing a delta PRD and just referencing the previous PRD or you may learn that the PRD is used in a way that really does require a new tome on the product as if the audience knows nothing. Alternatively, maybe you can come up with a more clever approach based on the real needs of the PRD’s audience. In a lot of ways, the PRD is a product in and of itself and not immune from the need for customer empathy.
  2. At the risk of stating the obvious, you’ll probably want to look at previous PRDs to see how others at your company have approached it. Often times, new PMs to a company are fearful of asking basic questions and appearing incompetent, but that’s just pride messing with them. If the current format meets the needs from tip #1, then you may not need to re-invent the wheel.
  3. One thing that people often overlook when launching highly complex projects is the power of pictures, especially if you need to educate external audiences. While you’ll need to satisfy whatever expectations there are, make sure you go heavy on visuals, mock-ups, diagrams, etc. It’s much easier to “click through” a series of wired mock-ups or screen shots than reading a bunch of words, lists, or tables describing those images.
  4. Since you mentioned quality a few times, make sure you have a thoughtful description of QA practices, minimum quality requirements, etc. You will at least want to get input from your QA team or ask them to write it themselves. It may very well be that this is the section everyone really wants covered versus the complete feature audit. I’d probably also include some discussion of top quality risks and mitigation methods and owners.
  5. If you have to document every feature anyway, take this as an opportunity to do some pruning. Chances are, some features are rarely used, don’t work, or no longer relevant. If you are carrying over ever single feature in your new release (unless backwards compatibility is a requirement), lifetime feature support is probably a recipe for some serious bloatware after a few versions. Given the sensitivities of your audience, probably worth calling out killed features very clearly and up front in the doc.

Hope this helps and best of luck!

6 other answers so far ↓

  • Mark Field // Feb 9, 2011 at 7:04 am

    While designing a requirements management capability for our commercial product, I spent a lot of time talking to customers in different industries about their ‘requirements management’ needs, including customers in Med Device and other regulated industries.

    My guess is that the real need is to show auditors that the product is being validated properly by being verified against new requirements and past requirements to ensure no regressions.

    So, in this case, I think there needs to be two types of requirements documents. The PRD you mentioned that describes the required changes to the product and can be used for customer validation and review. And, a Test Requirements document (frankly, a document isn’t the best way to manage these kinds of requirements) that lives from release to release and captures requirements that state how the product requirements – old and new – are being verified.

  • Dmitry Dragilev // Feb 9, 2011 at 6:15 pm

    Why not challenge all the idea of having a requirements document at all by turning to a sketches and visuals to explain requirement? Check these examples:

    http://www.zurb.com/article/574/avoiding-the-pain-of-requirements

  • Amit Chandra // Feb 22, 2011 at 12:31 pm

    Delta-based documents with a change log containing summary of the previous changes makes good sense in such situations.

  • Howard // Mar 16, 2011 at 2:09 pm

    2 words: Regression Testing.

    Sounds like QA is trying to get you to do their job for them. Good luck doing that, I don’t think it is an appropriate task. What would be better would be to keep a running list of features that are supported and which are deprecated. They should retain their tests from version to version so they can test and retest without needing a new PRD every time to recreate the wheel. Hopefully the political landscape will support you, but this seems like extra work that has zero value from a product management perspective.

  • Travis Mills // Apr 25, 2011 at 10:44 pm

    thanks for sharing this wonderful post

  • Sean Sullivan // Aug 2, 2011 at 8:53 pm

    Although I have experiences not too different, I must question the wisdom of sharing PRDs with clients. In my experience the PRD itself does not give a clear reflection of the product design nor whether specific reqs are met in a given product release. Very frequently, resource reality stikes back and we can’t do everything in a PRD without missing dates or reduced quality. So we tend to reduce scope and defer 2nd priority reqs.

    How can someone external work with such a document?

What do you think?