001 - Requirements Clarifications

In the Agile scenario, “Active stakeholder participation” throughout the project's lifecycle is described as one of the key success factor.
Though there are now doubts in above said point, the issue comes when you have stakeholders coming from a complete not IT background and it’s difficult for them to perceive the functional software. Sounds wacky? It’s common in South Asian countries, especially in the government departments. Such stakeholders are defined as: “End users who tells you what they really want on the day you give them what they've asked for”. Oops, I can know what I really want is only after seeing it.

Another thing I’ve faced is the “tale of never ending open requirements”. The project is kicked-off, teams have been finalized and stakeholders are identified for requirements clarifications. Users keeps on explaining about the functional requirements and issues they face with the existing system. In the middle of a requirement clarification (asked from software analyst) the user realizes that they’ve missed something…and here comes the brand new feature that turns out to be one of the key requirement of the software. Poor analyst, curse himself why the hell he asked for the damn clarification. Now by end of requirement phase, you’ll actually see little projects, trying to pop out of the additional (key) requirements.

These are the most common scenarios that are bound to happen during the requirement analysis phase (in this part of the word). The waterfall method by no means can address such challenges. Agile may be helpful is some situations, or al-least minimizes the risks.

Successful (Agile) Requirements Analysis Rules (for Nerds):

The #1 rule reminds me a quote I’ve seen on internet; called - Hoggarth's Law Reworded by MHR from Chris Hoggarth's email October 2006. It says “Attempts to get answers early in a project fail as there are many more wrong questions than right ones. Activity during the early stages should be dedicated to finding the correct questions. Once the correct questions have been identified correct answers will naturally fall out of subsequent work without grief or excitement and there will be understanding of what the project is meant to achieve.”

That’s the Rule #1: Prepare yourself first, do the homework before you start collecting requirements. Be sure of what you need to know from user (and what not).

Few months back, I was looking for a Air-conditioner and saw an advertisement of a electrical retail chain in the newspaper. They were selling the 1.5 ton A.C. for Rs. 13,000. It was the best deal I would get anywhere in summers so I went to this shop to place an order (Also took the newspaper for reference). I asked the sales guy that I am willing to buy the A.C. that costs 13,000 bucks. He replied that it’s the exchange offer and also the cost depends on the condition of the old A.C. I was surprised and showed him the newspaper where the exchange condition was nowhere mentioned. Now, this guy show me a small (microscopic) * in the advertisement that says “conditions apply”. I was shocked.

Rule #2: Be transparent and set the expectation right from day one. Don’t make too much assumptions in requirements.

The extension of Rule #2 is the rule of communication (language). Even if I had seen the “condition apply” (using magnifier), It was still difficult for me to understand what exactly does it means. The description of “conditions apply” must be given somewhere in the advertisement so that customer like me are not fooled around.

Develop a method to communicate with customers. Generally end users understand the user interface they are going to work with. Developing a UI prototype during the analysis would be of great help to end users and requirement analysts.

Rule #3: If it's is not on a paper it's never been said. Document each requirement clearly and maintain it’s relationship (traceability) in each phase.