Stakeholder Goals Identification

Definition

Stakeholder Goals Identification

the requirements engineering task during which stakeholders goals (e.g., desires, needs, and expectations) are identified

Classification

As illustrated in the preceding figure, Stakeholder Goals Identification is part of the following inheritance hierarchy:

• Type: Abstract
• Superclass: Business Analysis
• Subclasses:
  • None

Responsibilities

The typical responsibilities of Stakeholder Goals Identification are to:

• Identify the stakeholder goals (e.g., desires, needs, and expectations).
• Organize these goals.
• Capture these goals in the language of (and from the perspective of) the stakeholders.

Preconditions

Stakeholder goals identification can typically begin when the following preconditions hold:

• The business strategy phase has started.
• The business strategy team or requirements team is adequately staffed and trained in stakeholder goals identification.
• Stakeholders are available for workshops and interviews.

Completion Criteria

Stakeholder goals identification is typically complete when the following postconditions hold:

• All goals of the stakeholders have been identified, collected, and informally documented.

Steps

Stakeholder goals identification typically involves the business strategy team or requirements team performing the following steps in an iterative, incremental, parallel, and time-boxed manner:

• Elicit stakeholder goals (i.e., desires, potential needs, and expectations):
  • Hold joint stakeholder goals identification workshops with stakeholders.
  • Interview stakeholders.
  • Observe representative users at work.
• Identify other possible sources of stakeholder goals:
  • Subject matter experts (e.g., domain experts, industry analysts, consultants).
  • Reusable desires, potential needs, and expectations (see Requirements Reuse)
  • Documentation (e.g., business strategy documents, business vision statement, documentation of relevant legacy systems, workflow procedures, vendor documentation, marketing studies, change/enhancement requests from the users and technical service representatives, industry analyst reports, etc.).
  • Human Interface Prototypes.
• Obtain and read documents that are sources of potential stakeholder goals.
• Identify and document the stakeholder goals.
• Understand associated constraints (e.g., potential market size and segmentation, cost constraints, feasibility, risks, and training needs).
• Analyze the stakeholder goals (e.g., prioritize the goals, remove conflicts).
• Informally verify and validate the stakeholder goals (e.g., validate potential needs as actual needs).
• Iterate the stakeholder goals as necessary.

Techniques

Stakeholder needs identification can typically be performed using the following techniques:

• Apprenticing.
  A requirements engineer becomes an apprentist to a user representative, learns the user’s tasks, and thereby learns the user’s needs.
• Documentation Studies.
  Study all documentation that may provide stakeholder goals.
• Cross Functional Teams.
  Stakeholder goals identification should be performed by a cross-functional business strategy team or requirements team including multiple roles.
• Incremental Development.
  Incrementally develop the lists of stakeholders goals.
• Iteration.
  Iterate the lists of stakeholders goals.
• Joint Application Development (JAD).
  Hold joint requirements engineering workshops with stakeholders:
  • Brainstorming.
    Brainstorm informal lists of potential stakeholders and other sources of stakeholder goals.
  • Informal joint modeling (e.g., domain modeling, use case modeling, object modeling, and state modeling) using actor cards, use case cards, diagrams, printing whiteboards, etc.
• Interviews.
  Interview the stakeholders and subject-matter experts.
  • Active listening.
  • Active questioning.
• Questionnaires.
  Have the stakeholders and subject-matter experts fill out questionnaires regarding stakeholder goals.
• Observation.
  Observe the users while they are using the current or related applications:
  • Note taking, audiotape, and/or videotape (in either public or surveilance mode).
  • Active questioning.
  • Verbal descriptions of duties.
  • Keystroke monitoring.
• Parallel Development.
  Elicit the stakholder goals in parallel with:
  • Other requirements engineering tasks (e.g., requirements reuse, stakeholder profiling).
  • Other activities (e.g., architecting, design, testing, management, configuration management, training).
• Timeboxing.
  Timebox stakeholder goals identification so that goals are identified in time for business case development.

Work Products

Stakeholder needs identification typically results in the production of the following work products:

• Textual lists of sources of stakeholder goals.
• Textual lists of stakeholder goals including issues and conflicts.
• Informal diagrams (e.g., context diagrams, use case diagrams, sequence diagrams, activity diagrams, etc.).
• Audio and videotapes of stakeholder goals identification sessions with stakeholders and subject-matter experts.

Guidelines

• Stakeholder needs are often referred to as user requirements or stakeholder requirements.
• Stakeholder goals identification should be performed iteratively, incrementally, and in parallel with other tasks (e.g., stakeholder identification and profiling).
• Hold multiple JAD stakeholder needs workshops and individual interviews rather than one big mass meeting.
• JAD stakeholder needs workshops tend to be more effective than interviews and questionnaires.
• Use interview checklists to help ensure that no issue falls through the cracks.
• This task is called stakeholder goals identification rather than stakeholder needs identification to emphasize the active aspects of drawing requirements from people who know them but may not be able to effectively elucidate them.
• The requirements team must understand the user’s work and operational environment(s) in order to properly identify and understand their goals.
• Stakeholder goals identification can be difficult for numerous reasons:
  • Stakeholders often have difficulty expressing their desires, needs, and expectations although they are often convinced that they have expressed themselves clearly.
  • Stakeholders often have difficulties imagining new ways of doing their tasks (and new applications should enable new ways of doing things or enable new things to be done).
  • Stakeholders may not realize that stated goals may not be real goals.
  • Stakeholders may identify goals that are not real:
    • Their goals may not be feasible given business and technical constraints.
    • Their goals may not be cost-effective (gold-plating).
    • Their goals may not be validatable (e.g., testable).
    • Stakeholders often request solutions (implementations and constraints) rather than goals.
  • The identified goals may rely on factors outside of the business and thus be beyond the control of the business.
  • The identified goals, even when properly implemented, may not adequately enable the users to perform their tasks.
  • Stakeholders can have conflicting goals.
  • Some goals are much more difficult to identify than others:
    • Stakeholders often fail to identify goals that deal with exceptional situations.
    • Stakeholders often find it difficult to identify data and quality goals.
    • Missing goals are a major cause of endeavor failure as measured by endeavor cancellation, cost overruns, budget overruns, inadequate functionality, etc.
  • Stakeholders often do not know all of the important consequences of their requests (e.g., cost, schedule, maintenance, technology).
  • Stakeholders (and requirements engineers) often have difficulty determining the scope of the goals.
  • Stakeholders often find it far easier to identify their problems than their goals.
  • Goals change during the course of the endeavor as conditions change (e.g., market pressures change, mistakes are found, lessons are learned, laws change, technology changes making new requirements feasible, etc.).
  • Requirements engineers may not be properly trained in the stakeholder goals identification task and its associated techniques.
  • Requirements engineers may not be provided adequate access to all stakeholders. In fact, with certain kinds of projects and application procurement, the development organization may not be legally allowed to collaborate with stakeholders to properly elicit the requirements.
• Avoid the use of technical jargon in the goals, unless it is the well-known (within the business domain) jargon of the users or customer representatives. Avoid the use of application (e.g., systems or software) development terminology.