Role: Stakeholder

Description

Effectively solving any complex problem involves satisfying the needs of a diverse group of stakeholders. Typically, different interest groups (and even stakeholders) will have different perspectives on the problem and different needs that must be addressed by the solution. Many stakeholders are users of the system. Other stakeholders are only indirect users of the system or are affected only by the business outcomes that the system influences. Many are economic buyers or champions of the system. An understanding of who the stakeholders are and their particular needs are key elements in developing an effective solution.

Related Information

This section provides links to additional information related to this role.

• Concept: Acceptance Testing
• Whitepaper: Applying Requirements Management with Use Cases
• Whitepaper: The Ten Essentials of RUP
• Concept: User-Centered Design

Staffing

Examples of interest groups you might need to consider as Stakeholder:

• Customer or customer representative,
• User or user representative,
• Investor,
• Shareholder,
• Owner or Board member,
• Production manager,
• Buyer,
• Designer,
• Tester,
• Documentation writer,
• and so on

Skills

The Stakeholder role requires subject-matter expertise in the domain or the interest area.

In some project cultures, a person playing the Stakeholder role must act as the representative for a number of other disenfranchised people: people who will be materially affected by the outcome of the project, but cannot for some reason represent their needs directly. As such, the assigned Stakeholder representative must be able to elicit sufficient information from other members of the interest group to fairly represent their needs.

Role assignment approaches

The Stakeholder role can be assigned in the following ways:

• Assign one or more staff members to perform the Stakeholder role only. This works well in large teams, where there are a sufficient number of subject-matter experts available who have significant domain knowledge that is critical to the success of the project.
• Assign one or more staff members to perform both the Stakeholder and Requirements Specifier roles. This strategy is a good option for small to mid-sized test teams, and is often used where domain experts are available to play both roles. You need to be careful that appropriate effort is devoted to satisfying both of these roles, and that the domain expert is suitable skilled in requirements elicitation and communication.
• Assign one or more staff members to perform both the Stakeholder and Test Analyst or Tester roles. This strategy is another option for small to mid-sized test teams, and is often used where domain experts are available to play both roles. Again, you need to be careful that appropriate effort is devoted to satisfying both of these roles, and that enough training is provided in testing practices to make this approach viable.

If either of the latter approaches are taken, it is recommended that you make sure that at least some staff with specialized skills and experience are assigned primarily to the roles indicated as secondary here.

Further Reading

See the references page for further information.

Rational Unified Process