(Re-)Engineering stakeholders (Activity)

Overview

Title	(Re-)Engineering Stakeholders
Overview	This activity lets students explore the concept of stakeholders. They make a list of stakeholders of a project and develop a visual representation as well as a characterization. This is an activity used in the Requirements Engineering course. It is based on the "Stakeholders" lecture slides and can be conducted individually or in small teams.
Prerequisites
Learning Objectives	After successfully completing this activity, the learner should be able to: Identify stakeholders and relate them in a network or hierarchy as well as characterize additional information that helps to manage them well.
Process Skills Practiced	Information Processing

Background

• Background reading material: "Stakeholders" lecture slides
• Understanding project sociology by modeling stakeholders by Alexander and Robertson, IEEE Software
• Rationale for this activity: Stakeholders are the people who have an interest in a system under development. They need to be identified, characterized, interviewed, and managed. For that, stakeholder models provide a well-suited documentation template that can be customized according to project settings.

Directions

In class, we discuss how to identify and analyse stakeholders. They are documented in a stakeholder model comprised of a stakeholder diagram and a stakeholder matrix.

For this assignment, you will need to analyse the stakeholders for the OpenMRS system. Please follow the guidance from the slides and literature to elaborate a model with all relevant stakeholders. It should be easy to identify at least 30 stakeholders and develop a hierarchy of at least three levels (as an hierarchical diagram).

Finally make a stakeholder matrix (or individual tabular representations per stakeholder) where you denote their role, functions, motivation, main concern, availability, and relations to other stakeholders. The matrix may be split up into various tables, depending on what works best to represent the information you have collected.

Consider the various domains stakeholders could be included from and what types of information you would need to make as good and as complete a requirements specification as you can. Everybody who can provide you with knowledge beneficial for the system, and therefore your requirements specification, should be represented in your model.

Please also provide your description of the rationale for your results, at least two paragraphs of how you did it and what you found difficult or the most challenging aspect of it.

Assignment sheet with these directions.

Deliverables

• The student (team) will hand in a PDF with a stakeholder diagram and a stakeholder matrix as well as two paragraphs of reflection on their results.

Notes for Instructors

The remaining sections of this document are intended for the instructor. They are not part of the learning activity that would be given to students.

Assessment

• How will the activity be graded?
  • The deliverable will be graded as one part of the requirements specification.
• How will learning will be measured?
  • The quality of the application of the learned technique gives an indicator of how well the student has understood the technique and depending on the instructor, there can be a resubmission of the deliverable after initial feedback, so that the learning and the grade can be improved.
• How will feedback to the student be determined?
  • The student receives written feedback on their submission.
  • Submitted solutions can be discussed in class (probably anonymizing them, according to classroom code of conduct)

Evaluation criteria:

• Have all major stakeholder groups been considered?
• Is the diagram easy to understand?
• Are there well-organized hierarchies?
• Have they been analyzed and described to an adequate degree of detail?
• Are the relationships between the stakeholders clear?
• Is clear which stakeholder has which role, functions, motivation, main concern,

availability, and relations to other stakeholders?

• Is an elicitation technique and sample requirement provided per stakeholder?
• Is an adequate description provided about the rationale and challenges?

The form of the assessment is expected to vary by assignment. One possible format is the table:

Criteria	Level 1 (fail)	Level 2 (pass)	Level 3 (good)	Level 4 (exceptional)
Completeness	Less than 10 stakeholders identified, incomplete description	More than 10 stakeholders identified; role, functions, motivation, main concern, availability, and relations to other stakeholders are described.	More than 20 stakeholders identified and arranged in diagram; role, functions, motivation, main concern, availability, and relations to other stakeholders are described.	30+ stakeholders identified and arranged in diagram; role, functions, motivation, main concern, availability, and relations to other stakeholders are described well in detail.
Correctness	Stakeholders are not identified and classified or mainly incorrectly so.	Stakeholders are identified and classified correctly to at least 50%.	Stakeholders are identified and classified mostly correct and the majority of their characteristics is accurate.	Stakeholders are identified and classified correctly in all their characteristics as well as their relationships to each other.
Understandability	Diagram is missing, illegible, confusing or plain wrong.	Diagram is rudimentary but shows a clear structure of stakeholders and their relations.	Diagram is well-structured and easy to understand in its relations between the elements.	Diagram is easy to understand, very well structured and nicely visualized.

Comments

• What should the instructor know before using this activity?
  • Stakeholder models allow for some variation in correct solutions.
  • Students find it helpful to see several good examples before attempting this activity.
  • Students will try to copy closely what they see in the example so the notation of the examples should be chosen as close to what the instructor prefers as possible.
• What are some likely difficulties that an instructor may encounter using this activity?
  • Students may try to copy all the standard stakeholders and not think any further than that. It is helpful to let them think about the specific application domain of a system or ask them to name the stakeholders as specific as possible.

Suggestions for Open Source Community

Stakeholder models could enrich the documentation of the system.