Stakeholders - how to model them

UML is all about visual modelling, and though Unified Process has made UML the default modelling technique, it does not visually define stakeholders or their relation to the stakeholder requests.

Personally I find this a shortcoming, and I have been thinking about ways to model stakeholders, their types, their relations and their interests in stakeholders requests.

Stakeholder analysis is a rapidly growing area wth its main applications in politics and management. For RUP purposes, we usually don't need to model all properties and relations between stakeholders. Moreover, as circulstances, and thus stakeholders, can change frequently, it is often not very wise too spend too much time and effort on stakeholder analysis, as many projects should and will be short.

But for Requirements Management it is wise to link Use Cases to stakeholder requests, and Stakeholder requests to Stakeholders. By linking Use Cases to Stakeholder Requests, we can check that no Use Cases creep in that are not supported by Stakeholder requests. By linking Stakeholder requests to Stakeholders, we can make sure that these Use cases are requested by at least one Stakeholder.

"Traditionally" (for what is tradition in this young branch?) stakeholders and feature requests are related in a matrix. But tables are not very intuitive. It will have benefits if we can model the relations visually.

The simplest representation of a link between stakeholder and feature request or stakeholder request is a line. Like the Use Case Model, a Stakeholder Request Model could consist of persons (stakeholders) linked to ovals (feature requests) by lines.

As the lines should depict support of a stakeholder for a request, lines should be uni-directional and thus have an arrow.

The power of stakeholders is often described as an important feature, and something we could visually depict by the size of the person representing a stakeholder. To keep things manageble, 3 levels (powerful, normal, weak) should suffice.

The support of a stakeholder for a request can be depicted by the widt of a line, the thicker the line, the stronger the support. Again, 3 levels should be sufficient: Must, Should, Could, they correspond with the first three levels of MosCow:

• M - MUST have this.


• S - SHOULD have this if at all possible.


• C - COULD have this if it does not affect anything else.


• W - WON'T have this time but WOULD like in the future.

In a good project, the Wonts wont be present.

Let me conclude this with a simple example of what i have in mind:


This example shows part of an online registration system for courses / lectures. Professors may register a lecture they intend to give, students may sign up for them. The manager provides the funds for the system, holds the most power (hence drawn larger) and has the largest influence.
The analyst, knowing this, might do well to have a 5 minute chat with the manager before starting the work on a use case to ask him what the priorities of the manager are, before going into the details with the student or the professor. If the managers respons is: "the students will have to use the system anyway, so dont spend to much money on their facilities", he has another frame of mind than if the manager would reply: "At present, too many students find it hard to sign up in time for the start of courses and that holds the results of our university back".

Sources:

1. Stakeholder analysis: a review, 2000, Oxford University press, Ruairí Brugha1 and Zsuzsa Varvasovszky2


2. Cultivating Peace: Conflict and Collaboration in Natural Resource, 1999, World
   Bank Institute,Ricardo Ramirez


3. http://en.wikipedia.org/wiki/MoSCoW_Method