Requirements Elicitation is about discovering the real business requirements and the system requirements of any software endeavour.
It is first about discovering what is needed and then about articulating the distilled discoveries into a artefacts that can be used as the basis for describing what needs to be done. It is unusual that the real business requirements (and subsequent system requirements) can be rapidly found. Although requirements elicitation is sometimes referred to as requirements gathering, this is a misleading phrase. The real requirements are more like buried treasure in a field as apposed to crops that can be reaped. Sometimes an indication of the requirements are documented, sometimes not and sometimes what the user thinks they want, is not in fact what they actually want or need.
Documenting requirements is challenging, but eliciting the right requirements can be even more so. Doing poor elicitation will lead to the wrong software being built, can be a partial or complete waste of the entire activity.
Requirements elicitation is usually performed by a trained and qualified Business Analyst. Their responsibility is not only to identify the business needs and value but also the risks, and assumptions associated with the endeavour.
Discover the Real Requirements.
Requirements Structure
We recommend a 3-tiered approach to requirements hierarchy:
- Objectives – quantifiable business benefits.
- Capabilities – principle general software capabilities
- Functional Requirements or Functional User Stories
The upper levels are not burdensome but they do ensure focus on outcome and traceability of requirements to outcome.
Requirements elicitation is about asking the right questions of the right people.
Elicitation Techniques
The purpose of any elicitation technique is to help draw out from existing software, documentation and stakeholders, the real requirements faster and more completely. Some common techniques are shown below, these are described repeatedly on the internet and we wont go into the details of each one here.
- Interviews
- Observations
- Brainstorming
- Requirements Workshops
- Documentation examination
- Prototyping
- Surveys
- Existing system inspections
Cost of Poor Requirements Elicitation is closely aligned with the idea of technical debt. Technical debt is the need to rework software in the light of becoming aware of new requirements. If one fails to elicit the correct requirements in the first place, one is creating technical debt. Therefore:
elicitation failures = technical debt
Recommended Reading
Requirements Elicitation with AI
Did you ever wonder how artificial intelligence could help with software requirements elicitation? You need to find out what is really needed, so that involves discovering, capturing and then playing back what you have discovered to stakeholders and then refining the understanding. ScopeMaster’s analysis engine, interprets and then provides visualisations and contextual questions to help accelerate effective elicitation.
ScopeMaster Generated Models
ScopeMaster's models stimulate effective elicitation
Contextual Questions - auto-generated
ScopeMaster auto-generates suggested elicitation questions that are in the context of each user story to stimulate critical thinking
