In my experience with software development thus far, I find that requirements analysis is often overlooked or completely ignored. I believe that by not spending some time understanding the need for the software that's about to built, the developers may really be building an inferior product, which in the end is costly for the stakeholders of the project.

From my experience, there is often the misconception that the requirements process, in which requirements are discovered, is a slow process and is seen as the waterfall approach of software development. The perception is that the team needs to completely understand the requirements first before development. However, the requirements specifications can be built iteratively in parallel with software projects that are built iteratively when requirements are discovered as the project evolves and additional details are discovered.

Fundamental Truths

Mastering the Requirements Process: Getting Requirements Right by S... is a great book outlining their industry-proven experiences with the requirements process.

In the 3rd edition, they outline some fundamental truths and I shall share my experiences with them:

Requirements are not really about requirements.

Too often have I seen teams come up with a requirements document that focused primarily on what they believe the software needs to do. In essence, they are describing a solution to a problem that is not yet discovered and it is often the case that the software that is ultimately built is actually not needed.

Robertson explains that the requirements process is to understand the problem that the owner wants to solve and to describe a solution to address that problem directly.

If we must build software, then it must be optimally valuable for its owner.

This truth is often encountered after the team builds the software specified in the requirements document above. When the needs are not yet discovered but software development continues without this discovery, then the software built may not ultimately be needed by its owner and it will be seen as a failure.

Finding the optimal value for the owner is a matter of "understanding the owner's problem well enough to deliver a solution that provides the best payback at the best price."

If your software does not have to satisfy a need, then you can build anything. However, if it is meant to satisfy a need, then you have to know what that need is to build the right software.

This truth also follows from the above truth. From my experience, software developers enjoy building software and they can definitely do it well. However, it is often the case that what they build is ultimately not needed by the owner so the team ends up exceeding their budget.

Robertson mentions the danger of "[eliminating] the requirements discovery and [rushing] headlong into constructing the (inevitably) wrong product." Unfortunately, that observation is very true as the software development team are eager to build software while management often overlook the importance of requirements discovery.

I think the takeaway from this truth is that software developers can build anything but as a team, we need to know what need we are attempting to address by building the software and constrain our solution accordingly so that we don't end up exceeding our budget.

There is an important difference between building a piece of software and solving a business problem. The former does not necessarily accomplish the latter.

Software owners need to understand the cost of developing and deploying software. If they want their software to solve a problem, then "any development effort must start with the problem, and not with a perceived solution."

We need to be careful not to jump straight to the solution without understanding what the problem is. As mentioned above, I typically see software development teams eager to start building and they can come up with many solutions but if they are not constrained to the problem that the owner wants to solve, then they may end up wasting resources.

The requirements do not have to be written, but they have to become known to the builders.

Robertson claims that "the developers are almost always underwhelmed by [the requirements specifications] and either ignore it or willfully comply with it" but I find that developers often appreciate requirements specifications at least as a reference.

I believe the following statement from Robertson can't be stressed enough:

In many cases the act of writing a requirement helps both the business analyst and the stakeholder to completely understand it. As well as improving the understanding, a correctly written requirement provides trace documentation. The rationale of a requirement, or the justification on a story card, documents the team’s decisions. It also provides the testers and the developers with a clear indication of the importance of the requirement, which in turn suggests how much effort to expend on it. Additionally, the cost of future maintenance is reduced when the maintainers know why a requirement exists.

In general, complete requirements reduces pain points and errors in the development process. Maintenance is especially a pain when requirements are not complete because then you are forced to revisit the requirements with the likelihood of introducing additional errors.

Overall, by skipping requirements analysis in the beginning, you will definitely pay for it during maintenance.

Your customer won’t always give you the right answer. Sometimes it is impossible for the customer to know what is right, and sometimes he just doesn’t know what he needs.

This truth is tough because you want to make the customer happy but at the same time, you have to realize that you need to take the customers' stories as a factor in coming up with a solution to the problem they are trying to address rather than being a definitive answer to their problem.

It is often frustrating when the solution needs to change because not all aspects of the problem were explored. So when a customer states a solution, one has to prod some more to ensure that the customer's needs are going to be met.

Requirements do not come about by chance. There needs to be some kind of orderly process for developing them.

I think this truth is a given. There needs to be some process in place to extract requirements.

Of course, the process needs to be in-tune with the culture of the team. Otherwise, team members will likely resist or not put effort into the process.

You can be as iterative as you want, but you still need to understand what the business needs.

I have often seen software developers ignore requirements simply because they are working in an agile environment. However, the way I see it,iterative development requires you to make advances to the project and if you're working on something that's not needed, then you're essentially blocking forward progress!

What I've seen that I think works well in an agile environment is to allocate time to do some requirements discovery work that blocks the implementation tasks. For example, in a SCRUM-like environment, you could have a discovery story that blocks an implementation story and schedule accordingly.

There is no silver bullet. All our methods and tools will not compensate for poor thought and poor workmanship.

Requirements analysis is hard work and I believe it is mastered through regular practice.

Therefore, I think it's beneficial if teams started working on their requirements analysis skills because as Robertson states, there is no one-size-fits-all method on getting requirements right -- it's whatever works best with the culture of the company.

Requirements, if they are to be implemented successfully, must be measurable and testable.

When requirements are done correctly, you can easily draw up a test plan that accompanies your requirements specifications because the requirements already state their success criterion.

It is often much more painful to come up with a test plan later in the project.

All requirements need to be testable so that you can verify that the requirement is indeed met so "if you cannot find a measurement for a requirement, then it is not a requirement, but merely an idle thought."

You, the business analyst, will change the way the user thinks about his problem, either now or later.

Requirements analysis is a group effort. A single analyst can't possibly think of all aspects of a problem and so requires help from other stakeholders of project to write up complete requirements.

After several interactions and guidance with stakeholders, they will eventually understand what you're looking for in terms of requirements and begin to start thinking their problem in that manner.

Next Posts

Consider this blog post as an introduction to the requirements process and my experience with it in software development teams. I think I will share specific areas mentioned in the truths above from past experiences in greater details in future posts.