Smart Requirement Gathering for Efficient Development

With IT Projects becoming bigger and the need to execute them faster becoming more and more crucial every day, the initial task of Requirement Gathering needs to be optimized to fit this need. The Requirement gathering process is the nucleus of the development activity and thus the results of the requirement gathering process reflects on the all the tasks of the project throughout the course of the project. 

Requirement Gathering based on Project styles?

The ways to approach a requirement gathering process for a Business Analyst differs from Project to Project, for instance in a Waterfall style project the requirement specification document will need to have a consolidated content to enable efficient development throughout the lifecycle of the project, whereas an incremental or an Agile style of project needs the requirements to act as a trigger for Development and further improvisations. So clearly there is no well-defined success formula to collect requirements efficiently, however by identifying the high level need of the project, the development process to be followed these requirement gathering techniques should be defined accordingly.

A few essentials to be followed:

• Ask the right and wrong questions
• Team contribution while creating a Requirement Specification
• Create a supporting cast for the requirements
• Revisit and update Requirements on a timely basis

Ask the right and wrong questions:

A requirement gathering is not just about gathering a passive set of requirements, it about understanding all the aspects including the need for the improvisations. The brainstorming session with the stakeholders needs to be a session where questions are asked regardless of the complexity of the system. It’s important to have a smooth flowing understanding with the stakeholders and it is important that even if there are questions which come up after a meeting, a requirement gathering should have majority of the questions answered. For questions which are not answered, a possible solution and understanding should be provided by the Business Analyst to clarify the requirements.

Team contribution while creating a Requirement Specification:

It is important to discuss the requirements/questions as a team. It’s a misconception that the Business analyst is the owner of the entire process however it is vital to have a development perspective through discussions/brainstorming sessions with the different members of the project. Right from the testing team to the development team, their concerns/questions on understanding a system can be vital in the questions set asked to the business owners/stakeholders.

Create a supporting cast for the requirements:

The Requirement specification document is the representation of the Requirement gathering process, but it’s a great utility to support the document with some additional tools. Sharing the understanding of the requirements with the business owners using tools like dynamic or static wireframes, dynamic mockups of the system (to allow users to navigate) can be vital in making the requirements concrete. These tools can also be used as a playback before sending out a finalized document for approval of the gathered requirements. It is also vital to keep these primary and secondary set of documents updated throughout the course of the development activity.

Conclusion: 

The Requirement gathering is a crucial initiation phase that sets the tone for the development activity to be followed. Hence understating the implications of the conclusions drawn at the end of this phase is vital. As specified earlier, there is not a defined set of questions or a defined process to carry this process out, but understanding the complexity and then adapting the requirement gathering process accordingly helps to make the process smoother. The success of a requirement gathering can be properly quantified during the development phase when the Requirement Specification document which is the result of the Requirement Gathering process acts as the primary reference for the development as well as testing teams.

About Author:
Chandan Amonkar is a consultant in Systems Plus Pvt. Ltd. Within Systems Plus, he actively contributes to the areas of Technology and Information Security. He can be contacted at: chandan.amonkar@spluspl.com