According to the Oxford Dictionary, the word "elicit" has its origin in the Latin term "elicio," which means "to draw out," "to call forth," or "to evoke" by magic or trickery.
In the context of business analysis, elicit/elicitation first appeared in the 2nd edition of the Business Analysis Body of Knowledge (BABOK) Guide, published in 2009. The BABOK Guide is widely considered the standard manual for business analysis practices.
In business analysis, elicitation, however, does not involve magic or trickery. It refers to a structured approach aimed to "draw out" information and forge a consensus among Subject Matter Experts (SMEs) regarding the requirements of application/software development.
The elicitation process actively engages stakeholders and promotes collaboration, encouraging conflicting opinions to reach a consensus. For instance, SMEs are asked to complete specific tasks independently, answer questionnaires, and submit detailed explanations for their respective answers. The justifications furnished by each SME reveal individual assumptions, which are explored and debated to analyze contradictory ideas. This helps unearth tacit knowledge, identify discrepancies, understand inconsistencies, and reduce over-reliance on a particular expert or stakeholder.
The following article dives into the concept of requirements elicitation and provides you with a comprehensive overview of what is elicitation, its role in business analysis, and popular requirements elicitation techniques.
What Is Elicitation?
Many of the technical or business requirements are not formally documented anywhere. Typically, the requirements exist only in the minds of Subject Matter Experts and stakeholders.
Business analysts, therefore, have to draw out or elicit the requirements to gain access to relevant data. The methodology of elicitation must also be meticulous and logical.
Elicitation is the cornerstone of any project, as it plays a critical role in bringing the requirements for a project to the table. Scientists and engineers agree that elicitation errors are one of the most common causes of project failures and abandonment that negatively impact the bottom line.
To avoid the possibility of fatal mistakes hampering a project, adequate research and preparation are hence necessary for the elicitation process.
Simply put, the goal of a requirements elicitation is to exhaustively identify the assumptions, risks, and needs involved in any project.
What Is Requirement Elicitation in Business Analysis?
Requirements elicitation is one of the most complex, error-prone, communication-intensive, and challenging stages of the software development process, as it is pivotal in determining the budget, time estimate, and scope of a project. The clarity of requirements elicitation should be exceptional in order to deliver solutions that end-users find useful and satisfying.
The Business Analysis Body of Knowledge (BABOK) Guide states that the primary responsibility of a Business Analyst is to make the requirements elicitation process complete and clear. Incorporating requirements elicitation into business analysis practices enables Business Analysts to act as a bridge between developers, stakeholders, and end-users, thereby facilitating the seamless development of applications that are responsive to customer requirements.
Requirements Elicitation Techniques
Factors, such as the customer's profile and organizational structure, as well as the project type, should be considered by the business analysis team before adopting a requirements elicitation technique or a combination of techniques. There are many requirements elicitation techniques for obtaining critical information from Subject Matter Experts and stakeholders. The most popular ones are listed below.
Brainstorming
The requirements elicitation process begins with brainstorming. To facilitate focused and fruitful brainstorming sessions, business analysts should set up a team with representatives of all stakeholders for capturing new ideas. Suggestions coming out of brainstorming sessions should be properly documented in order to draft the plan of action.
Document Analysis
During this step of the requirements elicitation process, business analysts review existing documentation at hand, with the intent of identifying requirements for changes or improvements. Examples of document analysis sources include pre-existing project plans, system specifications, process documentation, market research dossiers, customer feedback, meeting minutes, and user manuals. Document analysis is performed before scheduling more in-depth requirements elicitation sessions or interviews with stakeholders.
Focus Group
In a focus group, relevant stakeholders provide feedback to refine processes, ideas, or solutions that emerged as an outcome of earlier elicitation activities, such as brainstorming and document analysis. The feedback and comments are recorded for use in later phases of requirements elicitation.
Interface Analysis
At the core of interface, analysis is the idea of deconstructing how external and internal systems interact with each other and with end-users. This enables business analysts to identify potential requirements, uncover limitations, and determine interoperability issues between hardware and systems, which simplifies integration and testing workloads.
Interviews
A great way to extract critical data is via interviews. Business analysts engage in group or one-to-one interviews in an informal or formal setting to elicit project requirements through questions directed at Subject Matter Experts, stakeholders, and end-users. By exploring diverse opinions, business analysts gain in-depth knowledge of the requirements.
Observation
Also referred to as job shadowing, observation is an excellent elicitation technique that helps understand requirements based on observations related to process flows and work environments of stakeholders. Practical insights into actual workflows serve as the basis for modifications and enhancements. The observation approach allows business analysts to elicit real-world data that other requirements elicitation methods cannot capture.
Prototyping
One of the most important phases of the requirements elicitation process, prototyping enables business owners and end-users to visualize realistic models of applications before they are finally developed. Prototyping helps generate early feedback, and it boosts stakeholder participation in requirements elicitation.
Workshops
For multi-stakeholder, complex projects, workshops are one of the most resource-efficient methods to elicit requirements. Intense, focused, and highly productive workshops have a key role to play in getting all parties onto the same page. Workshop events help Subject Matter Experts and Stakeholders to collaborate, resolve conflicts, and come to an agreement.
Survey
When multiple Subject Matter Experts and stakeholders are involved in a project, business analysts conduct a survey for the elicitation of requirements. Everyone involved is given a questionnaire to fill out. Subsequently, the responses are analyzed to refine the requirements. Surveys are less expensive than other requirements elicitation techniques, easy to administer, and can produce both qualitative and quantitative results.
Master the Art of Requirements Elicitation
Simplilearn's Professional Certificate Program In Business Analysis, in partnership with IBM and America's #5 most innovative university, Purdue, covers every aspect of business analysis through 170+ hours of live online classes, top-notch e-learning content, Harvard Business case studies, 11+ projects with industry data sets, and capstones from 3 domains.
The market-leading course, facilitated by the world's #1 online bootcamp and certification provider, Simplilearn, offers students masterclasses from Purdue faculty, and industry-recognized post-graduate certification, Purdue alumni membership, and a unique JobAssist program. Enroll now to get certified.
