Gathering project requirement is the first step for developing any software project. In traditional software development approach, all the requirements are gathered, assessed and estimated at the very beginning of the project. If finalized and approved, it is signed off by stakeholders, which means that it cannot be changed any further. This approach does not involve any participation from developers, testers and team and the assumption is that all the requirements can be forecasted, analyzed and gathered at the very beginning. Any change in the requirements is considered to be an exception, and is dealt as it occurs without any prior consideration in terms of time, complexity and cost.

The above approach might have worked well in past when there is a clear vision of requirements and no possibility for changing them. But in today’s fast changing world, it is not possible to predict all requirements at the beginning.

But with the switch to the Agile model, the structure of requirements has changed as well. Requirements have become smaller, less precise and there is less time to elaborate them. Also with Agile, requirements are easy to change or extend and encourage discussions instead of describing the final state.

Some of challenges that are faced in requirement gathering in Agile model are:

• Limited access to stakeholders – stakeholders are too busy or there are conflicting priorities of tasks
• Ambiguity – most customers don’t know what they want and are not able to express correctly what’s on their mind
• Frequent changes – customers change their mind frequently
• Lack of Subject Matter Experts – getting associated with the suitable subject matter experts and domain professionals is difficult
• Wrong approach – the wrong approach of gathering requirements i.e. getting into great details of requirements without understanding the complete picture
• Unclear focus – not defining clear definition of done and sometimes focusing too much on one requirement

It is always best to streamline and define certain best practices and techniques that caters to business needs and current challenges faced in the requirement gathering phase.

The requirement gathering process can be divided into 4 key components:

• Developing a vision for the high-level details – The objective of developing a vision is to identify the main theme, high-level vision and scope, target users, main goals and create high-level backlog. Stakeholder interviews workshop, role playing along with out-of-the-box methods like Vision Statement in a product box, user roles (personas), use case modeling, process diagrams and UI flow and context diagrams are some of the most popular visioning technique.

• Brainstorming for features of requirement – Requirement brainstorming focuses on breadth rather than depth and identifies large number of features/epics/user stories. Some of the most popular requirement brainstorming techniques are story writing workshops, post it note brainstorming and teams breakout converge.

• Breakdown of features into user story – Requirement breakdown divides existing epics into smaller user stories. Some of the most popular requirement breakdown techniques are CRUD, acceptance test slicing and process steps.

• Defining detailed requirements – Defining detailed requirements for each user story along with acceptance tests and UI prototypes. Some of the most popular techniques are acceptance tests, test scenarios, UI prototyping, wireframing, example tables and activity diagrams.

Designing an upfront process for requirement gathering that focuses on the right level, at the right time from the right SME using the right modeling/elicitation techniques will be a game changer and critical to the success of all IT Projects.