Capturing Requirements Right

Capturing

Recently, some prospects provided us Figma prototypes when asked for requirements. I guess this is becoming a trend. While those prototypes looked beautiful, they still did not communicate the requirements unambiguously. After looking at the protytypes, we invariably had many requirements-related questions for the clients. One has to wonder: If so many questions were left out, was their requirement capture attempt of any use at all?

In all these cases, the clients had hired someone to create those mockups, which means that some money and time were already spent. What if we told you that there is a better way to capture the requirements, which will be easy and quick and costs nothing?

Continue reading the following Q&A.

What is the purpose of capturing the requirements?

Requirement capture is the first step in SDLC (Software Development Life Cycle) chain. The requirements that are captured here then guide further activities in the chain (design, development, testing). There is a thumb rule that the cost to fix a mistake becomes 10 times in each subsequent phase, rolling over. Wrongly / incorrectly captured requirements waste the most amount of time and money in a project. It is thus crucial to have the requirement capture correctly.

In most cases, the requirements also have a more immediate purpose to serve. It is in estimating. The requirements are first estimated to create an effort estimate, which is then converted to calendar estimate (how much time is the development going to take?) and budget estimate (how much will it cost?). Many times, these estimates determine the viability of the project (go, no-go decision).

Capturing the requirements to utmost details seems to be the solution. Right?

As covered above, the more detailed is the requirement, better are the inputs to the downstream phases, and better are the inputs for estimation. Following this reasoning, it was decided that requirements must be captured in utmost detailed level. People started creating elaborate “Software Requirement Specifications (SRS)”. (Google “SRS template” to check out the elaborate templates that were made for capturing requirements to their minutest details, without ambiguity.)

However, the amount of time that goes in creating and processing the SRS itself was so high that a re-thinking was mandated. Detailing something to the minutest level when no reference is available is very difficult. Senior level stakeholders used to be needed for requirement capture meetings, and a lot of time used to be spent on trivial issues such as whether a button should be placed to the left or to the right. The elaborate SRS that resulted could be easily a 200-300 pages document, which would take long to read, understand and estimate.

Therefore, people were forced to find a more workable alternative. The rigor of the requirement capture had to be reduced. In other words, requirements are now captured at a little higher level without getting into elaborate details. There is no mandate to strain your mind to think through every detail upfront. This ensures that trivial issues do not take up your time and requirements capture is quick and brief.

The detailed capture in SRS is the hallmark of the well-known Waterfall methodology, whereas the high level requirement capture is a hallmark of Agile methodologies.

What are the advantages of capturing requirements only at a high level?

There is more to gain and less to lose, but this works well only when there is 2 way trust and understanding. Let me explain…

Firstly, understand that just because the size of the requirements document comes down, they become quicker and easier to understand and process.

Estimates are never accurate, even with the most detailed requirements. So, carrying out the estimate based on the high level requirements does not seem to deteriorate the quality of the estimates much.

Especially while evaluating the viability of a project, one is interested only in an order-of-magnitude estimate. High level requirements can be processed quickly, so that the estimate can be made quickly. Getting the inputs for go / no go decision with low effort seems to be a bargain.

Are there any disadvantages?

Yes, here are the disadvantages / things to keep in mind, when you save time by capturing requirements only at a high level.

When the minute details are not captured then it leaves the doors open for different interpretations. This creates a risk to mislead the downstream phases (as covered above). To mitigate this risk, Agile processes prescribe small iterations of product development and incremental product be released at the end of each iterations. Customer looks at the incremental changes in each release and provides feedback. This feedback is used for course correction in case there are any discrepancies.

It also means that there is going to be extra rework resulting out of different interpretations. This extra rework can be kept low through better communication among the stakeholders, but cannot be nullified. It is a good idea to add some margin for this to the estimate.

There is also a higher risk of the estimates going wrong. Some items that go unstated in the requirements may warrant unaccounted effort. Such situations need to be brought to the table and discussed.

Therefore, such effort saving works best when there is mutual trust between the stakeholders and the actual implementation team. Otherwise, it can lead to unproductive arguments and burnouts. Especially in software development scenario, it can be quite disastrous if the trust and understanding is not there.

So, what is the easy way to capture the requirements then?

The most important part of specifying a requirement is “who does what”, or to elaborate, “who will be interacting with your application, and what will they be doing with it”. This essence is very easily captured in user stories.

A user story is a plain English sentence which goes as:

As a ___________, I want to __________________ .

That’s it! You just need to fill in the role and the function. Let’s look at an example, where we are capturing the requirements of an ATM machine. One of the user stories would be:

As a bank account holder, I want to check my account balance.

The user story tool makes it super-easy for anyone to capture their software requirements in terms of user stories. Of course, you may add further documentation, pictures etc to a user story to clarify it, as needed. This works when you initially want to capture requirements only at a high level (say, for arriving at an order-of-magnitude estimate), and later add more details to refine the estimate / start with the downstream steps.

If you have already invested in creating mockups, then they may be referenced as additional information to user stories. However, writing the user stories is a must. On the other hand, if you haven’t invested in mockups yet, don’t bother. Just focus on creating user stories. You may have an opportunity to have a go/no-go check on your project quickly. Mockup creation may come after that, only when you get past it.