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.
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:
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.
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."
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.
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.
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.
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.
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.
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.
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.
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."
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.
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.