Examples of use:
- #lib0201 - Global society and #lib0202 - National governments in the #2030library case.
- Moderator in ParliamentWatch debategraph.
These fields are included in the template to describe a stakeholder to a project, an initiative or an information actant (service solution, product):
|Stakeholder Name||The name(s) of the stakeholder(s) or their representative(s)|
|Stakeholder Class||One of the options in Stakeholder Class|
|Stakeholder Role||A term (job title, department, system class, organisation) that indicates a role for the class of stakeholder|
|Stakeholder Rationale||What involvement does the stakeholder have in the requirements debate (for a business product) ?|
|Involvement||Estimate when and how much time the stakeholder should be involved in the requirements debate|
|Classes of knowledge||Indicate for (some of) these classes the specific knowledge expected for/from this stakeholder: Goals, Business constraints, Technical constraints, Functionality, Non-Functional requirements, Project Issues|
|Hands-On Users: If the stakeholder is a hands-on user of the product, then consider below additional fields|
|User name/category||The name of the user group|
|User role||A summary of the users' responsibilities|
|Subject matter experience||One or more of these ratings: novice/journeyman/master|
|Technological experience||The users' experience with relevant technology|
|Other user characteristics||E.g. physical or intellectual abilities/disabilities, attitude towards the work area of the product, age group, education, …|
|Priority||Rate each user category as: key/secondary/unimportant|
|User participation||Ref. Involvement. Provide additional detail: Which kind of functional or non-functional requirements? How much time needed to determine complete requirements?|
|Non-functional requirements||List non-functional requirements that are specific and important for the user category, tag them as one or more of the listed types of non-functional requirements|
|Project Issues||List project issues that are specific and important for the user category, tag them as one or more of the listed types of project issues|
The availability of an enterprise architecture - preferably as part of an enterprise repository - will impact the amount of work that must be invested in describing the stakeholders as a service solution must be created or modified.
- stakeholders (for the enterprise architecture with respect to which the service solution will be positioned) are included in the motivation extension. The rationale for their involvement will often be related to their role in the Business collaboration that must be supported by the service solution;
- hands-on users (of the product for which requirements are collected) are addressed as part of the active structure aspect:
- the Business actor would include the "stakeholder" descriptive elements and Business role would include the "user role".
- stakeholders of Stakeholder class "Interfacing technology" are named application components and are described as part of the framework's Application layer; The rationale for their involvement will often be related to their role in a Application collaborations among "services".
Acknowledgement: Volère Stakeholder Analysis Template: fields and definitions adapted and modified for usage in the design of web-based service solutions and for use in DebateGraph. Inclusion of Non-functional requirements and Project Issues fields in the template is one of the suggested options in Volère1 and a recommended practice in EMPRESS2.