Stakeholders


Stakeholders are the source of requirements


The next part of the trinity is the stakeholders. Stakeholders include anyone with an interest in, or an effect on, the outcome of the product. For example, you are a stakeholder because you have an interest in the requirements. The users of the product are stakeholders because they have an interest in having a product that does their work correctly. A security expert is a stakeholder who is interested in ensuring a secure product is built. In the same way, potentially dozens of stakeholders exist for any project. The importance attached to stakeholders comes from the fact that they are the source of all your requirements.

For more on stakeholder analysis, refer to Alexander, Ian, Neil Maiden et al. Scenarios, Stories, Use Cases Through the Systems Development Life-Cycle. John Wiley & Sons 2004.


The stakeholder map (christened an onion diagram by Ian Alexander) in Figure 3.6 identifies common classes of stakeholders that might be represented by one or more roles in your project. Here is how you interpret the map.

Figure 3.6.

This stakeholder map shows the organizational rings surrounding the eventual product, and the classes of stakeholders who inhabit these areas. Use this map to help you determine which classes of stakeholders are relevant to your project and which roles you need to represent them.


At the center of the stakeholder map is the intended product. Notice that it has a cloud-like shape, which is appropriate: It indicates that at the start of the requirements activities you should not be sure of the exact boundaries of the product. Surrounding the intended product is a ring indicating the operational work area. Stakeholders who will have some direct contact with the product inhabit this space. In the next ring, the containing business, you find stakeholders who benefit from the product in some wayeven though they are not in the operational area. Finally, the outer ring, the wider environment, contains other stakeholders who have an influence on or an interest in the product. Note that the detailed and multiple involvement of the core team membersanalysts, designers, project manager, and so onis emphasized by the fact they span all the rings.

Because there are so many classes of stakeholders, it is helpful if we discuss some of the major categories and then formalize all of them with a detailed stakeholder analysis template.




Mastering the Requirements Process
Mastering the Requirements Process (2nd Edition)
ISBN: 0321419499
EAN: 2147483647
Year: 2006
Pages: 371

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net