(Re-)Engineering stakeholders (Activity)

From Foss2Serve
(Difference between revisions)
Jump to: navigation, search
m
 
Line 1: Line 1:
 
=== Overview ===
 
=== Overview ===
 +
 
{{Learning Activity Overview
 
{{Learning Activity Overview
|title=(Re-)Engineering Stakeholders
+
|title=
|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.
+
(Re-)Engineering Stakeholders
|prerequisites=This is an activity used in the [http://foss2serve.org/index.php/Requirements_Engineering,_CSU_Long_Beach,_Penzenstadler Requirements Engineering] course. <br/> It is based on the [https://www.slideshare.net/kamikitty/requirements-engineering-stakeholders "Stakeholders" lecture slides] and can be conducted individually or in small teams.
+
|overview=
|objectives=Identify stakeholders and relate them in a network or hierarchy as well as characterize additional information that helps to manage them well.
+
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.
|process skills=[http://foss2serve.org/index.php/Category:Information_Processing Information Processing]
+
 
 +
This is an activity used in the [[Requirements_Engineering, CSU_Long_Beach, Penzenstadler|Requirements Engineering]] course.  
 +
 
 +
It is based on the [https://www.slideshare.net/kamikitty/requirements-engineering-stakeholders "Stakeholders" lecture slides] and can be conducted individually or in small teams.
 +
|prerequisites=
 +
|objectives=
 +
* Identify stakeholders and relate them in a network or hierarchy as well as characterize additional information that helps to manage them well.
 +
|process skills=
 +
[[:Category:Information Processing|Information Processing]]
 
}}
 
}}
  
Line 34: Line 43:
  
 
= Notes for Instructors =
 
= 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.
 
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.
  
Line 104: Line 114:
 
=== Additional Information ===
 
=== Additional Information ===
 
{{Learning Activity Info
 
{{Learning Activity Info
|acm unit=SE Requirements Engineering
+
|acm unit=
|acm topic=Describing functional requirements using, for example, use cases or users stories, Requirements analysis modeling techniques
+
[[:Category:SE Requirements Engineering|SE Requirements Engineering]]
|difficulty=medium
+
|acm topic=
|time=twice 75 minutes (or start in lab and finish as homework)
+
Describing functional requirements using, for example, use cases or users stories, Requirements analysis modeling techniques
|environment=computer lab with internet
+
|difficulty=
|author=[http://foss2serve.org/index.php/User:BPenzenstadler Birgit Penzenstadler]
+
medium
|source=n.a.
+
|time=
|license={{License CC BY SA}}
+
twice 75 minutes (or start in lab and finish as homework)
 +
|environment=
 +
computer lab with internet
 +
|author=
 +
[[User:BPenzenstadler|Birgit Penzenstadler]]
 +
|source=
 +
n.a.
 +
|license=
 +
{{License CC BY SA}}
 
}}
 
}}
  
--------------------
+
[[Category:Learning Activity]]
{{License CC BY SA}}
+
[[Category:Specification and Design]]
 
+
[[Category:Requirements Engineering]]
[[Category:Learning_Activity]]
+
[[Category:Specification_and_Design]]
+
[[Category:Requirements_Engineering]]
+
 
[[Category:Documentation]]
 
[[Category:Documentation]]
[[Category:Ready_to_Use]]
+
[[Category:SE Requirements Engineering]]
 +
[[Category:Ready to Use]]

Latest revision as of 13:27, 15 October 2018

Contents

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?
  • 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.

Additional Information

ACM BoK
Area & Unit(s)

SE Requirements Engineering

ACM BoK
Topic(s)

Describing functional requirements using, for example, use cases or users stories, Requirements analysis modeling techniques

Difficulty

medium

Estimated Time
to Complete

twice 75 minutes (or start in lab and finish as homework)

Environment /
Materials

computer lab with internet

Author(s)

Birgit Penzenstadler

Source

n.a.

License

This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License

CC license.png

Personal tools
Namespaces
Variants
Actions
Events
Learning Resources
HFOSS Projects
Evaluation
Navigation
Toolbox