Requirements Elicitation

I extracted these notes from several sources on the Web, as well as some course notes by IBM/Rational. They are provided as a supplement to the materials in the textbook, only for students in this course. Credit for the content goes to the original authors. Do not post them on personal websites or otherwise distribute them outside of this context, as that would be a violation of copyright law.

Requirements Elicitation Steps

  1. Gather stakeholder requests/needs
  2. Clarify and organize the ideas
  3. Condense ideas
  4. Prioritize remaining ideas

Requirements Workflow in RUP


Requirements Artifacts in RUP

In the Rational Unified Process, from which some of these notes are taken, the objective for this work is to collect and elicit information from stakeholders in the project. This information can be regarded as a "wish list" that is used as primary input in defining use cases and supplementary requirements.
This workflow detail is performed mainly during iterations in the Inception and Elaboration phases. However, stakeholder requests should be gathered throughout the project by reviewing change requests following your Change Request Management process. You should be aware of incoming stakeholder requests throughout the product lifecycle, to make sure you continue to address your stakeholders' real needs.
The key activity is to elicit stakeholder requests and determine the requested features of the system. The primary outputs are a collection of prioritized Stakeholder Needs and Features, as well as the attributes associated with them. These outputs are recorded in the Vision document. Also, during this workflow, you discuss the system in terms of its use cases and actors. Another important output is an updated Glossary of Terms to facilitate a common vocabulary among team members.

Requirements Sources

You need to capture requests from all stakeholders and specify how these requests are addressed. Although the system analyst is responsible for gathering this information, many people contribute to it: marketing people, users, customers-anyone who is considered to be a stakeholder in the project.
Other examples of external sources for requirements are:
Any results from requirements elicitation sessions and workshops

Requirements Gathering Process


How to Shorten Number of Iterations

Problems Often Encountered

  • Stakeholders
    • Have pre-conceived ideas of the solution
    • Do not know what they really want
    • Are unable to articulate what they want
    • Think they know what they want, but don't recognize it when it is delivered
  • Analysts
    • Think they understand user problems better than users
  • Everybody
    • Sees things from their own point of view
    • Believes everyone else is politically motivated

How to Express Stakeholder Requests

"I need to assess the status of my project."
"I want a trend report that shows the rate issues are being opened and resolved."
Jumping to solution mode is a common problem we humans have. It is because of this that, when you elicit needs from your stakeholders, you often get them expressed as features instead of a statement of what the stakeholder needs from any solution in order to solve the business problem. What do you do with these needs expressed as features? Do you tell the customer to "hold off - we'll get to those later"? No. At this stage, it is a stakeholder request and should be recorded as one. At the appropriate time you should assess whether it is valid and then create a feature requirement for it. The text of the new feature may be identical to the text of the stakeholder request. (In the USA DoD standards, the process of copying the text of a requirement to the next level is called allocation. If you reword the requirement when you create it at the next level, it is called derivation.)
To understand the need behind a request expressed as a feature, you can perform some problem analysis. For example: "The defect tracking system shall provide a project status trending report." This is a stakeholder request expressed as a feature. To understand the need that drives this feature, ask "why?" The answer could be something like: "I need to be able to understand if defects being raised faster than they are being resolved." This is the real need behind the feature, a sub-problem if you like.
Either way, you should record every request and then send it through a standard approval process before it is included in the system. Stakeholder requests expressed as features require a little more analysis to test whether they are valid and that they support the business goals of the system.

Stakeholder Request Artifact in RUP

  • Is owned by the stakeholders
  • Contains all the requests from the stakeholders
  • Consolidated from many sources
  • Used by project team to derive features and software requirements
  • May contain references to any type of external source

Techniques for Eliciting Stakeholder Requests

These elicitation techniques are useful for gathering information about stakeholder needs. The techniques can also be used very effectively for gathering information about feature requirements or detailed software requirements.
Many of these techniques can be used together. For example, a requirements workshop brings stakeholders together. At the requirements workshop, the participants may brainstorm for new ideas, or they may sketch out the use cases for the system to be built.
There are many excellent resources available to learn more about each of these elicitation techniques. The following list provides just a few resources that you can use:

Review Customer Requirement Specifications

Project teams sometimes receive their requirements in a document directly from their customer, especially when contracting to do a job.
In this case, it is important to review the customer's specification to determine what you believe to be the stated requirements. The identified requirements then need to be taken back to the customer to be verified; any issues noted must be addressed and resolved.
Keep in mind who wrote the specification. The specification is inevitably written from the author's perspective.
Introductory and overview sections of the specification are important for general understanding of the specifications. Those sections are less likely to contain requirements, but keep in mind there might be misplaced requirements.

Requirement Gathering Techniques

  1. Brainstorming (more on Brainstorming)
  2. Brain Writing (more on Brain Writing)
  3. Mind Map

Clarification Techniques

  1. CRC Cards: Card Swap; CRC Cards (more)

Idea Condensation Techniques

  1. Affinity Group Diagram
  2. Fishbone diagram

Idea Prioritization Techniques

  1. Multi Voting (another reference on Multi-Voting)
  2. Pareto Chart
  3. Nominal Group Technique
  4. Dot Voting



Brainstorming Rules


Brainstorming: Brain Writing

* *

Brainstorming: Mind Map


Idea Reduction: Affinity Group Diagram


Idea Reduction:Fishbone Diagram


Prioritizing: Pareto Chart


Prioritizing: Multi Voting


Prioritizing: Nominal Group Technique


Prioritizing: Dot Voting



  1. Gather stakeholder requests/needs
  2. Clarify and organize the ideas
  3. Condense ideas
  4. Prioritize remaining ideas