Requirements Documents – One Man’s Trash

crumpled paper

…Is another man’s treasure. There are many different ways to document requirements when developing software. And there is a proliferation of requirements documents – MRD, PRD, SRS, FRS and design documents. Everyone has a perspective on what each document represents, and each person on the team has a unique perspective on what questions the document answers.

The flow of software development.

Software development has three phases:

  1. Decide what to do
  2. Determine how to do it
  3. Do it

We can think of it as three questions:

  1. Why are we doing this?
  2. What do we want to do?
  3. How will it be done?

Depending on our role on the team, we have a different perspective on the answers to those three questions. The following diagram shows a flow that covers the full development process.
The flow of software development

The software development process in this flow is broken down into five categories

  1. Market. Definitions of the problems and opportunities that are worth solving. Think of them as market needs.
  2. Requirements. MRD or PRD. Expression of an implementation-agnostic description of what must happen to address these market needs.
  3. Specification. SRS or FRS Structured and constrained description of a technological solution that would implement the requirements.
  4. Design. A strategy for implementing the specification.
  5. Product. Code and Tests. The implementation, solution, or product.

Team Perspectives

There are four different ways to look at the flow above to answer the three questions. The questions are “Why?”, “What”, and “How”. We can identify a champion to carry the banner for each point of view.

  • Product Manager. The thinker, in search of opportunities to create great software.
  • Lead Developer. The inventor, in search of the best technical solution to the targeted problems.
  • Developer. The executor, striving to create the most elegant implementation of each design.
  • QA. The enforcer, who’s mission is to assure that we build the right thing, and build it right.

Each of our champions approaches a portion of the process above, and looks for answers to the three questions, “Why” “What” and “How.” And each champion selects different steps in the process to find the answers. The following diagram shows the 5 categories from the previous diagram, and maps them to the four champions.
Different views on the process

Product Manager

  • Why? The market tells us why we should do something. We find opportunities and assess them.
  • What? Our requirements articulate those problems we choose to solve, and what’s required to solve them.
  • How ? The specification is an actionable description of precisely what needs to be done.

Lead Developer

  • Why? We have requirements that define the scope of our endeavor.
  • What? The specification tells us what needs to be done.
  • How? Our design demonstrates the approach we will use to get it done.

Developer

  • Why? The specification articulates our responsibilities.
  • What? The design guides us to meet those responsibilities in the best possible way.
  • How? We are accountable for the product we deliver.

QA

  • Why? The requirements must be met.
  • What? The design may be robust. Trust, but verify.
  • How? With these tests, we are confident in the quality of what we deliver

Conclusion

Different people on the team have different responsibilities. And they look to different steps in the process as their source of inspiration. They are also responsible for delivering different results. It all flows together.

  • Scott Sehlhorst

    Scott Sehlhorst is a product management and strategy consultant with over 30 years of experience in engineering, software development, and business. Scott founded Tyner Blain in 2005 to focus on helping companies, teams, and product managers build better products. Follow him on LinkedIn, and connect to see how Scott can help your organization.

8 thoughts on “Requirements Documents – One Man’s Trash

  1. Scott,

    Long time reader, first time poster here. Just curious as to your opinion on who should own each of the documents in your process above. For example, who owns the Spec? Is it the PM or the Lead Dev?

    Thanks,
    Hill

  2. An extremely good presentation and full of information! And I got the meaning of “One man’s trash is one man’s treasure” after reading through linked posts.

    One query, what role do “Systems engineers” play in the whole process?

  3. Hill and Bikram, thanks so much for the great questions and for reading!

    Bikram, when you say ‘Systems Engineer’, what do you mean? I haven’t worked on any projects that had that specific title. Can you describe some of the responsibilities this person would normally have?

    Hill, the ownership is going to be a function of the skills of the people on the project.

    The MRD captures the results of strategic analysis of the market. The primary focus of the (inbound) product manager is synthesis and prioritization of market requirements.

    The SRS captures the user-perspective of how the software will work. Use Cases, for example, show how people are intended to achieve the requirements spelled out in the MRD. Designing the use case requires us to apply business analysis skills – essentially a process design step. Interaction designers will apply insight into how people would ideally interact with the user interface. Ideally, this document would be created by the interaction designer and (product manager | program manager | business analyst). On smaller teams, I’ve seen this role work with a program manager working in conjunction with inputs from interface designers.

    The design document focuses on what Alan Cooper would call ‘program design’. The senior implementation people will design the architecture for the implementation.

    When faced with the tough “who own’s it?” question (because there isn’t a person on the team who is an obvious choice), I would always defer to the person “upstream” in the process. The upstream person (product manager, for the spec) will have the strongest handle on the driving “why” of the particular “what”. Mistakes in direction can mess up a project more than mistakes in execution – so I would use that approach when there isn’t a clear owner.

  4. Bikram,

    Thanks for the link. Based on the definition of systems engineering from the linked pdf, I would say that the system engineering role looks like a combination of the “lead dev” role and project management.

  5. Pingback: Kevin Brennan
  6. Pingback: Frank Gartland

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.