U.S. Department of Transportation
Federal Highway Administration
1200 New Jersey Avenue, SE
Washington, DC 20590
202-366-4000


Skip to content U.S. Department of Transportation/Federal Highway AdministrationU.S. Department of Transportation/Federal Highway Administration

California Division

Home / About / Field Offices / California Division / Systems Engineering Guidebook for ITS

Home What's New Systems Engineering Guidebook Views Search Glossary Resources Feedback Site Map

3.9.2 Elicitation

 

OBJECTIVE:

Elicitation is a set of techniques for drawing out stakeholder needs, goals, requirements, constraints, priorities, normal operations, and preferences. It is done early in system development to support the initial needs assessment leading to the development of requirements. As the project progresses, the process is revisited as necessary to provide further clarification.

DESCRIPTION:

Elicitation is a collection of techniques to draw out and clarify stakeholder needs and requirements. Multiple techniques are provided to address the needs from various directions. Needs are usually vague, implicit [unstated], or described in terms of technical solutions. Elicitation techniques help the stakeholders clarify their needs. The techniques present a logical sequence, starting with available material and build on what is learned through additional feedback. The actual steps taken depend upon the size and complexity of the project. Other factors include the number and diversity of the stakeholders.

CONTEXT OF PROCESS:

Shows the flow for cross-cutting activity Elicitation Process. Summaries are described for inputs, constraints, and enablers into the task; activities of the task; and outputs from the task. The flow is described in detail in the accompanying text.

ELICITATION PROCESS

Inputs:

Project Goals and Objectives are the major drivers for defining needs.

Control:

Project Plan, SEMP will describe the elicitation approach that will be developed before elicitation begins.

Enablers:

Stakeholder involvement is essential to defining valid and meaningful needs.

Technical reviews are an effective means to get stakeholder feedback on the needs being collected.

Trade studies support prioritization of the needs.

Outputs:

Key needs are the documented list of prioritized stakeholder needs, their sources, and rationale for the selection.  The highest prioritized needs are called the key needs.

Constraints as well as needs are collected during the elicitation process. They are anything expressed by the stakeholders that may limit solutions to the needs.

Process Activities:

Identify stakeholders

Identify the stakeholders who will operate, maintain, use, benefit from, or otherwise be affected by the system. See 3.9.1 for details.

Do literature search

Take advantage of any existing documents, such as previous studies, reports, standards, specifications, scopes of work, or concepts of operations. Homework will be needed before meeting with stakeholders. Build on what was learned to make the other activities much more effective and focused.

Carry out day-in-the-life studies

The purpose is to understand current operations from the view of the key stakeholders. This is especially useful with system operators. Spend time with the stakeholders and document what they do and how they do it. Identify and document workflow threads; these will be the basis for scenarios in the Concept of Operations. Ask them what they like and do not like about how they currently do their job.

Administer surveys

Surveys are especially useful in setting priorities among multiple stakeholders or when there is insufficient funding to meet all of the important needs. First decide exactly what is needed from the survey. Get expert assistance to design the survey carefully, asking questions in multiple ways and from both positive and negative views to prevent biasing the results and to clarify the answers.

Perform one-on-one interviews

This is an opportunity to probe deeper into the perspective and needs of the individual stakeholders. Focus on the expertise of domain experts, but be especially aware of hot buttons and conflicting goals.

Conduct workshops

Workshops are an opportunity to de-conflict needs and requirements. Present the stakeholders with a summary of what was heard so far and a description of the issues. Create a positive environment [a professional facilitator may help] in which the various groups can listen to each other's concerns. Facilitate discussion and consensus.

Document needs

Document what has been learned in the elicitation process. Review it with the stakeholders and revise, as necessary.

Illustrates where Elicitation occurs in the Vee Development Model. Elicitation for regional needs occurs in the Regional Architecture section. Elicitation for project needs occurs in the Concept Exploration section. Elicitation for requirements and clarifications of needs occur in the Concept of Operations, System Requirements, and High-Level Design (Project Architecture) Subsystem Requirements sections. Elicitation changes and upgrades occur in the Changes and Upgrades section.

Where does elicitation take place in the project timeline?

Is there a policy or standard which includes Elicitation?

FHWA Final Rule does not specifically mention general elicitation practices to be followed. CMMI provides some useful material in this area.

Which activities are critical for the system's owner to do?

  • Identify stakeholders and encourage their participation
  • Participate as stakeholders in elicitation activities
  • Review the summaries and conclusions of the elicitation process

How do I fit these activities to my project? [Tailoring]

All projects require an identification of the stakeholders and documentation and acceptance of the findings. Beyond that, the combination of techniques used depends on the complexity of the system under development. A small, straight-forward system may only require a literature search. This is especially true if the needs have been well thought out and described in a document. Even in that case, an informal one-on-one interview is helpful to clarify the document.

A day-in-the-life study is important when the system will change operations. Or, if it is being developed to enhance operations. Surveys are needed to set priorities in systems with vague or contentious needs or an insufficient budget. One-on-one interviews are always recommended. Elicitation is more important for more complex projects. For example, if new detector technology is to be installed, it is useful to talk to experts in that technology. Speak with people at other agencies who have used the technology. Workshops may be as simple as a presentation with feedback. They are essential when there are multiple agencies involved, especially if they have not worked together previously.

What should I track in this process step to reduce project risks and get what is expected? [Metrics]

On the Project management side:

  • Percentage of relevant documents which have been utilized
  • Percentage of stakeholder groups/individuals who have been queried using at least one of the techniques
  • Number of stakeholders who have agreed to the conclusions of the elicitation process

Checklist: Are all the bases covered?

check Have all relevant stakeholders been identified?
check Has the stakeholder equity into the system been defined?
check Have all appropriate techniques been used to draw out needs and requirements?
check Have all assumed needs been uncovered?
check Have all stakeholders agreed with the conclusions?

Recommendation.Are there any other recommendations that can help?

A professional facilitator will help to elicit needs, especially if there are conflicting needs. Also, there are techniques for collecting, analyzing, and prioritizing needs. For example, a workshop techniques like the ten dollar technique where stakeholders are given ten (1 dollar tokens) and asked to spread the tokens over a set of twenty needs. This forces the stakeholders to make priority choices among the twenty needs.

Any collected needs must be tempered by reality. As needs are collected, be aware of potential cost overruns, risks, conflicts, or scope creep. Here are some metrics to keep in mind and in front of the stakeholders.

  • Estimated cost of meeting the expressed needs or requirements
  • Estimated risk level of the expressed needs or requirements
  • Number of expressed needs that conflict with those expressed by other stakeholders
  • Number of new requirements that are beyond the initial needs statement, since they signal a risk of scope creep

Caution.Do not accept stated needs at face value without some exploration. Initial needs are often expressed in terms of solutions. For example, a need for more loops is really a need for better traffic information. Focus on the underlying need. Often, a key need is not expressed because it seems obvious. Explore some alternative solutions to uncover unstated assumptions.

There is an art to eliciting needs. It involves repeated digging and probing. Ask what they need. Then, ask why they need it. Whatever their answer, ask them, Why?” Continue until a complete understanding is obtained as to what it is they really need and why.

A closer look at a useful tool what if?” Ask them to consider alternative system approaches. Ask them about alternative technologies, such as cameras rather than loops, or alternative operations, such as local rather than centralized monitoring. This gets at underlying unspoken assumptions, requirements, or constraints. Sometimes the stated need is expressed in terms of a familiar solution. For example, the use of the Windows operating system may be cited. Does that mean an otherwise good Unix-based traffic management system is unacceptable? These types of questions ferret out the real requirements and bring previously unstated constraints to light. When developing requirements for the system, it is helpful to get someone who is not closely associated with the system that can think outside the box and probe in ways that can help clarify the needs and requirements.

What are sources for a literature search?

This varies greatly from project to project and depends on where in the development process the search is being done. If there is a contract that includes a scope of work, that will be a prime source. If the Concept of Operations has been completed, it will cover needs. Any applicable standards/specifications should be consulted. There may be previous studies for this or neighboring agencies. Other reports, such as strategic plans, will contain information on needs. If multiple agencies are involved, it is essential to understand all such documents.

Suggestions for day-in-the-life studies

If possible, watch them as they perform their jobs. Make note of the sequence of actions [as the basis for scenarios in the Concept of Operations]. Then, ask them about unusual situations such as failure events and how they handle them.

Suggestions for administering surveys

The Agency may regularly perform surveys. Take advantage of their experience. In fact, they are a good source of inputs from the traveling public, the ultimate stakeholder.

Suggestions for one-on-one interviews

At this point, a description of the needs should have been documented. This is an excellent starting point for discussions. Do they disagree with any of them? Are there any constraints that they know of which would make it difficult to meet the stated needs? Was anything important left out?

Suggestions for workshops

So far, needs have been gathered from individuals. Especially when working with multiple agencies, there may be very different priorities and even conflicting needs. For example, a transit agency wants signal priority for its buses. The agency that operates the roads thinks that it would be too disruptive of traffic flow. The workshop can be used to get the stakeholders together to listen to each other and to come to an agreement. Maintain an atmosphere that encourages this kind of dialog.

Checklist  
Return to top
Federal Highway Administration | 1200 New Jersey Avenue, SE | Washington, DC 20590 | 202-366-4000