Software Requirements – Process and Roles

black and white face

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.

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.

The software development process can be described as a series of steps outlined below.
software development process diagram
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.

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.
software development process roles 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.

3 thoughts on “Software Requirements – Process and Roles

  1. I like the following two points:

    1. Part of what matters in the requirements/design debate are the implications for the different roles and skill sets that participate in requirements and design activities. Effective requirements elicitation and formulation necessitates asking “why?” and being able to sift through customer requests that are often worded as solutions rather than problems to be solved. UI and software design require very different skill sets. To dismiss the debate as purely semantic, with no practical consequences, would be naive.

    2. Despite the importance of the distinct concepts and roles, feedback occurs. You can’t realistically determine which problems you can solve without having some idea of what solutions are feasible. For this reason, it helps when a skilled requirements analyst has some knowledge of design. I give an example of this sort of overlap and coordination here.

    1. Thanks for commenting Abdallah, and welcome to Tyner Blain! Can you tell me more about what it is you don’t understand / what part of the article is not clear?

      Thanks again!

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.