…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.
Latest Articles
Comments on all Articles
