…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:
- Decide what to do
- Determine how to do it
- Do it
We can think of it as three questions:
- Why are we doing this?
- What do we want to do?
- 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 software development process in this flow is broken down into five categories
- Market. Definitions of the problems and opportunities that are worth solving. Think of them as market needs.
- Requirements. MRD or PRD. Expression of an implementation-agnostic description of what must happen to address these market needs.
- Specification. SRS or FRS Structured and constrained description of a technological solution that would implement the requirements.
- Design. A strategy for implementing the specification.
- 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.
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,
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
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?
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.
Scott, Thanks for the quick response. For the role of systems engineer, From the “International Council of Systems Engineers (INCOSE)” page:
http://www.incose.org/ProductsPubs/pdf/SEPrimerAIAA-INCOSE_1997-08.pdf
Part of my job is systems engineering, and job is requirements development(RD) and requirements management(REQM).
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.