Wednesday 29 January 2014

Efficient Requirement Gathering

“Requirements Gathering” is more than just finding out what the client needs today. It means understanding the functional requirements i.e. understanding how the system works “As-Is” and how the “To-be” system should work; clearly understand the requirements to segregate them into smaller, moderate and significant changes. Understanding the non - functional requirements like information the system should contain, expected performance from the system as well as security concerns is equally important to develop a good system. It basically means learning all you can about your customer’s business and daily routine of the business and then suggest ways for improvement.


On the face of it requirements gathering seem to be an easy task which involves talking to the client and noting down the requirements but in reality it requires a lot more than that. The analyst needs to establish a proper communication channel and a foundation of trust and rapport with the stakeholders for getting open and honest inputs because as the popular quotes goes “Half Knowledge is a dangerous thing”. When a new system is created, it must adhere to the needs of several groups of stakeholders, such as end users and senior management hence an ear should be given to the opinions and suggestions from all the stakeholders but what is beneficial and feasible as per the scope of the project is the job of the business analyst to evaluate.

The Skills required for effective requirement gathering are listed below:
  1. Effective listening and communication skills are needed for successful business requirements gathering.
  2. Appear Professional and Unbiased. The stakeholders should take the analyst seriously from business perspective and being unbiased will help the stakeholders to open up to you and be honest as far as requirements and expectations from the new system are considered.
  3. Cross-cultural understanding and open to suggestions
  4. Be analytical, investigative and should be able to separate facts from opinions.
  5. Good convincing and negotiation skills and at times be authoritative.
  6. Good understanding of technical jargons and business terms.

How to effectively gather requirements?

  • Identify and understand high level scope of the project, the different stakeholders involved and the business domain.
  • Involve all the stakeholders from the beginning. If possible conduct one-on-one meetings and then group meetings with the stakeholders to identify if individual requirements and the group requirements are in sync. While conducting meetings plan a clear agenda with adequate comfort breaks - not everyone is used to concentrating hard for long periods. Take notes of key points.
  • Ask stakeholders to identify the key problem areas, the scope for improvement in the current processes and the expectations of the stakeholders from ‘To – Be’ developed system.
  • Analyze the problems and the expectations of the different stakeholders. Build questionnaires / ask questions to specific stakeholders for points which are not clear. Do not presume anything. Take notes of key points.
  • Conduct a Joint Application Development (JAD) session which should typically include a facilitator, end users, developers, observers, mediators and experts. JAD sessions accelerates the requirement gathering process, considers view points of all the users and thus ensures a mutually agreed requirement is noted in the requirement specification document. JAD sessions are also useful during the development to faster the development times and reducing the likelihood of errors that are expensive to correct later on.
  • Ensure requirements are specific, realistic and measurable in terms of technology, time and budget. Showing what all is possible while pointing out which options offer the best return becomes a fine line in the requirements gathering process.
  • A common mistake is basing a solution on complex or cutting edge technology and then discovering that it cannot easily be rolled out to the 'real world' hence clearly identify deliverables and their formats.
  • Write down the requirements in a word file or an excel file or using a requirement gathering tool for capturing requirements doesn’t matter much as long it is readable, available and modifiable as and when needed. While writing down the requirements it has to be ensured it is written keeping in mind the different stakeholders and the development team. Everyone involved in the project should clearly understand the detailed requirements. 
  • Once the requirements document is clearly documented it should be distributed to all the stakeholders and consensus from the stakeholders is very important. At this stage if any of the stakeholders has queries try to resolve them at personal level but if it needed conduct another JAD session so that everyone understand the issue and try to come to a logical conclusion.
  • The requirements can change at any stage of the project. Some requirements will be minor changes and some might be significant but what is really important is to discuss the change in requirement with all the stakeholders. Analyze the impact of the change with respect to time, efforts and overall expected business outcome and once all the stakeholders approve the changes then incorporating the changes in to the requirements document. We humans have a tendency to forget hence it is better to document the changes and publish the updated requirements document to the concerned stakeholders. This will be helpful in future to avoid any blame game.
A requirement analyst has to ensure that while building up the requirements document view points of all the involved stakeholders is taken into consideration, discussion and question - answer round is conducted for analysis and evaluation of the various points but only the mutually agreed requirements are documented and should be in scope of the project. A well established communication channel for meetings and publishing requirements is truly important to keep everyone informed about the changes in the requirements.

About Author:
Nikhil Vaishnav 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 nikhil.v@spluspl.com

No comments:

Post a Comment