An Awesome Guide To Requirements Elicitation: What To Do Before The Event
/ Stephanie FamuyideTo Elicit Is To…
Listen, not dictate
Probe, not interrogate
Discuss, not assume
Observe, not accept, and
Evoke, not suppress,
in order to find out what the business truly needs.
Organising or facilitating a requirements elicitation event is one of the most critical phases of any software implementation project, no matter how big or small. Where requirements are not comprehensive, complete or accurate, the project will most certainly not deliver on anticipated benefits and will fail to meet the expectations of business stakeholders from day one. To avoid project failure, it is extremely important to plan for elicitation events effectively so that any anticipated difficulties can be nipped in the bud.
What makes requirements elicitation so difficult?
A snapshot representing the difficulties of requirements elicitation from the perspectives of stakeholders and analysts is shown in the diagram below:
One key aspect of effective planning is visualization - the exercise of seeing the success in your mind including the fine details of how to get there.
For quick tips on how to increase the chances of your requirements elicitation event (Brainstorming sessions, workshop sessions, etc) through effective planning and visualisation, download BAL’s first ebook:
Business Analysts play a pertinent role in determining what functionality a system should or should not have. If you can ask these questions of every requirement, the implemented solution will have a higher possibility of acceptance:
One of the main goals of business analysis is to uncover unknown risks and requirements during the requirements discovery phase. But as many business analysts will surely attest to, sooner or later, the problem of scope creep inevitably arises, unless concrete steps are taken to prevent it.
We make hundreds if not thousands of decisions every day. Some more important, others less so. With each decision we make, we shape our future and possibly, come closer to the attainment of our goals. One of the most effective ways to increase productivity and make better choices during requirements elicitation is by organizing facilitated sessions among stakeholders.
Documentation of software requirements should not be seen as optional, but a necessity. While the level of detail may vary depending on the approach adopted, be it Agile or Waterfall, it’s important to keep in mind why documentation is needed in the first place, before one goes too far in the wrong direction.
Needs Analysis is similar to business analysis especially in the sense that it is used to determine the needs of the business, and is centred on understanding the issues and opportunities faced by the business with the objective of finding resolutions, defining approaches to resolving issues and exploiting opportunities. In summary, it’s about:
From analysing data and preparing deliverables to supporting stakeholders through other stages of the solution development lifecycle, the role of the BA is certainly key to successful projects. The end of the elicitation event does not signify the end of business analysis activities, but the beginning of the BA’s involvement in other aspects of the project.
This piece is a continuation of Why Do Business Analysts Miss Software Requirements? and provides more reasons why Business Analysts may miss out on key requirements necessary for system development.
A project that ends with a deluge of change requests once operations have started can only signify one thing—missed requirements or unmet expectations. Requirements may be missed for many reasons on business projects. This article explores the reasons why requirements can end up as missed and some best practices to keep in mind for successful software implementation.
While a cruise ship captain is responsible for the vessel, its crew and the passengers, a facilitator is responsible for the outcome of the requirements elicitation event. Still, there are many similarities between a ship captain and an event facilitator:
The relentless pace of technological progress drives businesses to work on increasingly more complex projects. With this increased complexity comes new challenges and roadblocks that business analysts must learn to overcome.