How clear are your requirements

I think we all can sympathize with the wife in the old IT joke in which a programmer husband, on his way to the grocery store asks his wife if she needs something. “Get a loaf of bread, and if they have eggs get six”, she replies.

He came back with six loaves of bread :).

Next day the wife asks the husband - “While you are at the store, get some eggs”. The husband never returns. He goes to store, buys eggs, he finds himself still at the store, buy more eggs. Finds himself still at the store, buy more eggs and so on. An external trigger is needed to stop the endless loop.

·      Husband runs out of ways to carry the boxes of eggs (stack overflow)

·      Husband runs out of money or store runs out of eggs (null pointer exception)

·      Store closes and kicks him out (timeout)

·      Gets a call from home - “what is taking you so long, come back home immediately” (exit) 

While hilarity ensues, the point here is if a requirement can be misinterpreted in such a simple scenario then how can we expect the requirements to be captured and interpreted correctly for big projects?

Every Project starts with an intent and a vision of the product. Is it not important for the requirements to convey the intent rather than just the needs and how do we capture the requirement to guarantee clarity? 

In our work we come across the notion "requirements" every day. The importance of this word is amplified due to the growing popularity of agile software development methodologies. One of the Agile Manifesto states to choose ‘Responding to change over following a plan’.

How much change in the agreed requirement is acceptable? How should we measure deviation and what must be done if there is shift in vision or intent? Let’s look at this subject more closely.

Requirements are not only functional; this is the key mantra that should change the way you think and will bring you closer to your goal. While managing the requirement we should pay equal importance to other Non-functional Requirements-Audit, Security, Integration, Reporting, Information integrity (validation/edit), System and then comes Business, User and Functional requirements. Writing, managing and ensuring that all these requirements are mapped to the final product is not an easy task. It is particularly difficult when multiple interacting systems are involved.

Start formulating an umbrella of Non-Functional requirements that must span the whole system, followed by individual system requirements which then map further down the product life cycle to individual components. Now begin with high-level definition of the Project Scope, which sets the boundaries for areas within the project that will respond to respective change. Next, the team expands on the scope statement by collaboratively uncovering the need statements to be solved for (business requirements). Finally, the team can drill down to a technical approach, finding appropriate solutions that satisfy the project needs

Requirements are captured in user stories, but do not take the term ’stories’ literally and start jotting down the fantasies. Requirements like objectives must be SMART ie they should be S-pecific , M-easurable, A-ttainable, R-ealistic,T-ime based. If there are interlinked requirements, give them in the correct order. Elaborate key requirements. It is easier to maintain the quality of the product if you state the key requirement out loud

Always remember, if you don't understand the requirements, it's highly likely that other people don't understand as well so keep refining.

During the project lifecycle Non-functional requirements should not change, any change in non-functional requirements means there is a new dimension added to the projects. It is quite essential for an project to ponder on non-functional requirement at the very beginning of the project to adhere with company compliance policies, best practises and standards, these requirements if neglected in the beginning will incur a huge debt, they are story points intensive and gives no visible business value. All the non-functional requirements must be either added as an acceptance criterion in the backlog items or in definition of done.

Although stories and sprints orchestrate changes, any change in business requirements qualifies as a new story but if there are deviation, they should be measured. A standard deviation in terms of story points should be established at the very beginning of the project. If this threshold is reached Product owner should be aligned with the higher management and stakeholders as the chances are the product vision is changing. It must be analysed if this change in vision intentional and desired and not a detour.

As much as changes are welcomed, they should be scrutinized and there should always be a constant effort from the team to keep the requirement as stable as possible. Requirements play a major role not only delivering the product as desired but also understanding the goal, estimating development costs, creating comprehensive schedule and setting priorities. If you take this easy, your path ahead would be difficult.

“Walking on water and developing software from requirements are easy if both are frozen”