These are the Five Key Aspects of an Effective Requirements Elicitation Process

Eliciting requirements is an essential part of any project. Without understanding what we want and how we can achieve it, planning for the project becomes difficult. Many organizations and project teams don't give this important functionality the importance it deserves and fail to do enough research to understand all of their needs.

1) Create a clear Requirements Elicitation Process: It is extremely helpful to have a clearly-described requirements elicitation procedure that clearly demonstrates how clients will be approached, what other functions or groups will be involved and in what capacity, as well as how the entire process will be carried out. It is important to indicate how much involvement each group would expect and what steps they will be involved in.

2) Have a Requirements Elicitation process that is geared towards the main categories of work conducted in your organization: We all know that the requirements for a sustainment request are very different from those for a full-fledged project. Projects are different from one another. IT professionals know that Infrastructure projects require a different approach than application selection and implementation projects. It is important to have a process in place for each main category.

3) Have a comprehensive and yet easy to read Requirements Gathering document: Organizations often create complicated requirements elicitation documents. It is not only difficult for the person who fills it out, but it also makes it very difficult for them to engage with the client or project sponsor. The analyst who conducts the requirement gathering workshop might try to skip or avoid capturing important information that would have been helpful in Solution Design.

To avoid this, create a Requirement Gathering Document that includes sections to capture key information. Always remember that meaningful sections along with document style, font, line spacing all play a very vital role in making a document more readable as against of a dull & drab complicated (think tax) document!

4) Describe the requirements in simple sentences, from the point of view of the requestor: Because there is a demand, we capture requirements. The requester wants something to happen. Instead of saying the need "as if" in vain, capture the requestor's perspective of the need and it will give you much more information than just technical words.

For e.g. let’s say a Payroll Manager would like to have a report that indicates the time spent by her staff to correct timesheet errors. One, you could capture the requirement as; Provide report that indicates time spent by the payroll staff to correct timesheet errors and the second would be as I wrote it above- Payroll Manager would like to have a report that indicates the time spent by her staff to correct timesheet error. The first way of writing is cold and non-personal where are the second style makes it a requirement-user-story. Someone wants something, so they can in turn do something else.

Stating requirements in this style of user-story soon creates a “Requirements Ambience” which the subsequent Solution Design needs to meet in addition to the actual delivered artifacts (in our example above, the actual report).

Capturing requirements in this way, also makes validation that much easier- since the user’s requirement have been captured from their perspective, it is easier for them to identify with that stated need, validate it and approve it in the Requirements Gathering document.

5) Map Gathered requirements to Delivered Functionalities: Not many projects go the extra mile to make sure that what they deliver as deliverables actually maps to the original requirements. Clients and sponsors must agree to the deliverables in order to sign off on the project. However, by mapping the delivered functionality to the requirements it allows for greater traceability and supportability as future modifications and changes are made to the original deliverables.

By mapping gathered requirements to delivered functionalities, projects can provide a more comprehensive and robust Operations document.

These are five crucial ways in which you can modify your Requirements Elicitation Process to ensure more effective Requirements gathering that help in formulating better solutions to satisfy clients and provide detailed information that can be easily utilized by the Operations group. A win-win way of working… happy clients, happy operations and engaged & satisfied project team members!

About the author: Sandhya Bhat MSc, CSSMBB, CSSE has developed several new and enhanced existing strategic methodologies to improve technology and human capital utilization, produce greater ROI on investments and streamline service delivery. She is an acclaimed author, speaker, a sought after thought leader and an avid world traveler.