Software Requirements – Process and Roles

Requirements vs design – who does what and why

Our previous post, Requirements vs design – which is which and why, describes our position on which parts of the software development process are requirements-activities, and which parts are design activities. The debate among professionals about these distinctions is ongoing, and continues in the comments on that post. The length of the debate, combined with the skills of those debating demonstrates that it isn’t a black and white issue.

In this post, we will try and explore the reasons why this debate is ongoing. We will do that by exploring the symbolism of the terms involved, as well as the roles of different members of the software development team.

Symbolism
One of the challenges in successful communication comes from the way people use symbols as part of the organization of their thoughts. The word design, to many people, encompasses any task that involves ideation, or the creation of ideas. In software, this label is commonly applied to the task of determining how to achieve a goal in software. The previous debate asks a different question.

Does this symbol apply to the act of determining which problems to solve with software?

When we take the symbolic association traits of people into account, this is not an unreasonable question. Without an over-arching context in which to answer the question, the term design can be applied to almost any activity.

We propose that when discussing the software development process, the term design should not be applied to the act of creating a PRD from an MRD.

Process
The software development process can be described as a series of steps outlined below.

Steps in a software development process

1. Someone identifies market opportunities and captures the results of that analysis in a document like an MRD.
2. Someone determines which of those opportunities should be addressed in software and creates a PRD (or FRS or SRS) capturing the results of that analysis.
3. Someone designs a software solution based upon those software requirements, and captures that design in a design document.
4. Someone implements a software solution (writes code) that conforms to the documented design.

Note that there are also steps involved in assuring the quality of the solution, and feedback loops in a good software development process. We covered this in our earlier post, Where bugs come from. We’ve also talked in more detail about the software development process in our post, Describing the software development process. In order to keep this discussion on task, we’ve simplified our presentation of that material in this post.

Roles
We talked a bit in our previous posts about the nature of the activities in the four steps identified above. Each activity is distinctly different, as shown in the next diagram.

The software development process as shown has four distinct types of work that are involved.

The four types of work

1. Opportunity identification – identification and sizing of problems or opportunities that exist.
2. Opportunity classification – determining which and how problems should be solved in software.
3. Solution architecture development – determining, broadly, how software implementations should be created
4. Software implementation – determining, narrowly, how software solutions should be created and then creating those solutions.

Steps one and two are synergistic. Step three is a natural evolution of step four. The first two steps require distinct thought processes and frameworks from the last two steps. It is reasonable to combine either pair of steps (1 & 2, or 3 & 4) but not to intermix them (1 & 3 would be bad, for example).
The missing link

The crux of the ongoing debate is the following: Should step 2 be treated as two separate steps:

2A. Triage opportunities and select the ones best addressed with software solutions.
2B. Determine how software solutions should address the triaged opportunities.

And if so, should step 2B be considered “design”?

Our answer

The process of determining how software should address opportunities is tightly intertwined with the process of determining which opportunities to address in software. Having a vision of how the software solution might work is required to understand if software is the right mechanism for addressing a particular opportunity. There is a massive overlap in the skillsets required for these two tasks.

Since these two “half steps” are so intertwined, there is no benefit to separating them. In the overall flow of the process, there are clear distinctions between each of the “whole steps”, and it makes sense to separate them when possible.