Examples of use:


These fields are included in the template to describe a stakeholder to a project, an initiative or an information actant (service solution, product):

Field name Description
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.

In an enterprise architecture described in accordance with the ArchiMate framework:


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.