Task: Elicite Requirements |  |

Purpose

Elicite Requirements

Relationships

Roles

Primary Performer:

- Analyst
- Product Owner

Additional Performers:

Inputs

Mandatory:

- Business Domain Model
- Vision

Optional:

- None

Outputs

- Requirements

Process Usage

- Epilogue > Identify Requirements > Elicite Requirements
- Identify Requirements > Elicite Requirements

Main Description

It would be nice if requirements gathering was as simple as asking your customers and stakeholders what they want your system to do. Unfortunately, it’s never that straightforward.

In most cases, stakeholders are not aware of all the alternatives that exist when it comes to developing a specific product. Immersed in the current status quo, their vision tends to be limited. It’s hard for users to detach from the way they’re currently doing things—to imagine possibilities that are a significant departure from what they have now.

Furthermore, there’s no silver bullet. No single requirement gathering technique will help you elicit a complete set of requirements that will fill every gap and stand up to scrutiny during validation.

That’s why it’s a good idea to take a multi-faceted approach to requirements gathering. Requirements engineering best practices recommend using a variety of methods aimed at different phases of the process.

This article looks at eleven effective requirements gathering techniques. They will be presented roughly in the order in which they normally appear in the requirements gathering process. It is not necessary to use all of them for every project, but a healthy mix of these techniques, chosen based on the needs of your specific project, will likely improve your requirements coverage and help you reduce requirements-related problems during software development and afterward.

- Interviews
- Questionnaires or Surveys
- User Observation
- Document Analysis
- Interface Analysis
- Workshops
- Brainstorming
- Role-Play
- Use Cases and Scenarios
- Focus Groups
- Prototyping