(Re-)Engineering a system vision (Activity)
From Foss2Serve
(Difference between revisions)
(Created page with "=== Overview === {{Learning Activity Overview |title=(Re-)Engineering a System Vision |overview= This activity lets students create a system vision, a vision commonly agreed u...") |
m (→Additional Information) |
||
| (9 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
=== Overview === | === Overview === | ||
{{Learning Activity Overview | {{Learning Activity Overview | ||
| − | |title=(Re-)Engineering a System Vision | + | |title= |
| − | |overview= This activity lets students create a system vision, a vision commonly agreed upon by all stakeholders, mainly used for communication throughout the project. | + | (Re-)Engineering a System Vision |
| − | + | |overview= | |
| − | |objectives= | + | This activity lets students create a system vision, a vision commonly agreed upon by all stakeholders, mainly used for communication throughout the project. |
| − | |process skills=[ | + | This is an activity used in the [[Requirements_Engineering, CSU Long Beach, Penzenstadler|Requirements Engineering]] course. <br/> It is based on the [https://www.slideshare.net/kamikitty/requirements-engineering-system-vision "System Vision"] lecture slides and can be conducted individually or in small teams. |
| + | |prerequisites= | ||
| + | |objectives= | ||
| + | * Develop a system vision according to the rich pictures technique that enables developers and stakeholders to take about the vision for a system under development. | ||
| + | |process skills= | ||
| + | [[:Category:Information Processing|Information Processing]], [[:Category:Problem Solving|Problem Solving]] | ||
}} | }} | ||
| Line 12: | Line 17: | ||
* Background reading material: | * Background reading material: | ||
** [https://www.slideshare.net/kamikitty/requirements-engineering-system-vision "System Vision"] lectures slides | ** [https://www.slideshare.net/kamikitty/requirements-engineering-system-vision "System Vision"] lectures slides | ||
| − | ** [http://www.moodle2.tfe.umu.se/pluginfile.php/32063/mod_resource/content/1/Rich%20pictures%20-monk.pdf Monk & Howard: Methods & tools: the rich picture: a tool for reasoning about work context | + | ** [http://www.moodle2.tfe.umu.se/pluginfile.php/32063/mod_resource/content/1/Rich%20pictures%20-monk.pdf Monk & Howard: Methods & tools: the rich picture: a tool for reasoning about work context] |
* Rationale for this activity: Without a clearly delineated common system vision for a project, miscommunication and development that doesn't exactly fit the stakeholders' needs can easily happen. Therefore it is crucial to equip students with a technique to sketch precise but little technical system visions. | * Rationale for this activity: Without a clearly delineated common system vision for a project, miscommunication and development that doesn't exactly fit the stakeholders' needs can easily happen. Therefore it is crucial to equip students with a technique to sketch precise but little technical system visions. | ||
=== Directions === | === Directions === | ||
| − | In class, we discussed how to develop and document system visions. In this assignment, you have to develop a system vision for the OpenMRS system. | + | # In class, we discussed how to develop and document system visions. In this assignment, you have to develop a system vision for the OpenMRS system. |
| − | + | # As additional support for the discussion in the lecture, please read the [http://www.moodle2.tfe.umu.se/pluginfile.php/32063/mod_resource/content/1/Rich%20pictures%20-monk.pdf Monk & Howard article] and do the little tutorial from the Open University on Rich Pictures. http://systems.open.ac.uk/materials/T552/ | |
| − | As additional support for the discussion in the lecture, please read the Monk & Howard article | + | # For the system vision, the scoping (system boundary) is important, as well as other systems in the (operational and business) context and the (most important) involved stakeholders. |
| − | + | # Keep the intention of a system vision in mind: It shall communicate the idea of the project to all stakeholders in a way they can agree on and that is easily understandable without much technical knowledge. | |
| − | For the system vision, the scoping (system boundary) is important, as well as other systems in the (operational and business) context and the (most important) involved stakeholders. | + | # Diagrams have to be accompanied by explanatory text. It will not be possible to transport all the information you want in a diagram with only little “bubbles” and arrows, so please write a few paragraphs that help understand how to read and understand your diagram and the goals in there. In that description, also make clear which stakeholder is the issuer of that goal. |
| − | + | # Please also provide your description of the rationale for your process, at least two paragraphs of how you did it and what you found difficult or the most challenging aspect of it. | |
| − | Keep the intention of a system vision in mind: It shall communicate the idea of the project to all stakeholders in a way they can agree on and that is easily understandable without much technical knowledge. | + | |
| − | + | ||
| − | Diagrams have to be accompanied by explanatory text. It will not be possible to transport all the information you want in a diagram with only little “bubbles” and arrows, so please write a few paragraphs that help understand how to read and understand your diagram and the goals in there. In that description, also make clear which stakeholder is the issuer of that goal. | + | |
| − | + | ||
| − | Please also provide your description of the rationale for your process, at least two paragraphs of how you did it and what you found difficult or the most challenging aspect of it. | + | |
[http://foss2serve.org/index.php/File:2017_542_Lab_SystemVision.pdf Assignment sheet] with these directions. | [http://foss2serve.org/index.php/File:2017_542_Lab_SystemVision.pdf Assignment sheet] with these directions. | ||
| Line 37: | Line 37: | ||
= Notes for Instructors = | = Notes for Instructors = | ||
| − | The remaining sections of this document are intended for the instructor. | + | |
| + | 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 === | === Assessment === | ||
| − | ** The deliverable will be graded as one part of the [ | + | * How will the activity be graded? |
| + | ** The deliverable will be graded as one part of the [[(Re-)Engineering a Software Requirements Specification|requirements specification]]. | ||
* How will learning will be measured? | * 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. | ** 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. | ||
| Line 49: | Line 52: | ||
Assessment questions / evaluation criteria: | Assessment questions / evaluation criteria: | ||
| − | |||
* Can I (picturing myself as a stakeholder) easily understand what the system is about? | * Can I (picturing myself as a stakeholder) easily understand what the system is about? | ||
* Is a clear system boundary / scope visible? | * Is a clear system boundary / scope visible? | ||
| Line 83: | Line 85: | ||
| '''Understandability''' | | '''Understandability''' | ||
| Diagram is missing, illegible, confusing or plain wrong. | | Diagram is missing, illegible, confusing or plain wrong. | ||
| − | | Diagram is rudimentary but shows a clear structure of | + | | Diagram is rudimentary but shows a clear structure of elements and their relations. |
| Diagram is well-structured and easy to understand in its relations between the elements. | | 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. | | Diagram is easy to understand, very well structured and nicely visualized. | ||
| − | |||
| − | |||
|} | |} | ||
| Line 106: | Line 106: | ||
=== 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=easy to 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=[ | + | easy to 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]] | |
| − | + | [[Category:Specification and Design]] | |
| − | + | [[Category:Requirements Engineering]] | |
| − | [[Category: | + | |
| − | [[Category: | + | |
| − | [[Category: | + | |
[[Category:Documentation]] | [[Category:Documentation]] | ||
| − | [[Category: | + | [[Category:SE Requirements Engineering]] |
| + | [[Category:Ready to Use]] | ||
Latest revision as of 13:26, 15 October 2018
Contents |
Overview
| Title |
(Re-)Engineering a System Vision |
|---|---|
| Overview |
This activity lets students create a system vision, a vision commonly agreed upon by all stakeholders, mainly used for communication throughout the project.
This is an activity used in the Requirements Engineering course. |
| Prerequisites | |
| Learning Objectives |
After successfully completing this activity, the learner should be able to:
|
| Process Skills Practiced |
Background
- Background reading material:
- Rationale for this activity: Without a clearly delineated common system vision for a project, miscommunication and development that doesn't exactly fit the stakeholders' needs can easily happen. Therefore it is crucial to equip students with a technique to sketch precise but little technical system visions.
Directions
- In class, we discussed how to develop and document system visions. In this assignment, you have to develop a system vision for the OpenMRS system.
- As additional support for the discussion in the lecture, please read the Monk & Howard article and do the little tutorial from the Open University on Rich Pictures. http://systems.open.ac.uk/materials/T552/
- For the system vision, the scoping (system boundary) is important, as well as other systems in the (operational and business) context and the (most important) involved stakeholders.
- Keep the intention of a system vision in mind: It shall communicate the idea of the project to all stakeholders in a way they can agree on and that is easily understandable without much technical knowledge.
- Diagrams have to be accompanied by explanatory text. It will not be possible to transport all the information you want in a diagram with only little “bubbles” and arrows, so please write a few paragraphs that help understand how to read and understand your diagram and the goals in there. In that description, also make clear which stakeholder is the issuer of that goal.
- Please also provide your description of the rationale for your process, 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
- Students will hand in a system vision illustrated diagram accompanied by explanatory text.
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)
Assessment questions / evaluation criteria:
- Can I (picturing myself as a stakeholder) easily understand what the system is about?
- Is a clear system boundary / scope visible?
- Do I see what the most important structure, process and concerns are?
- Is the vision described and illustrated to an adequate degree of detail?
- Is it clear which elements belong to the operational and business context?
- Is it clear which most important stakeholders are involved?
- Is a 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 | Structure, process or concerns are missing, description is minimalistic and incomplete. | Structure, process and concerns are present with a basic description of everything in the diagram. | Structure, process or concerns are arranged in diagram with differentiated operational and business context; complete description of all elements. | Structure, process or concerns all identified and arranged in diagram with differentiated operational and business context; all described well in detail. |
| Correctness | Elements are not identified and classified or mainly incorrectly so. | Elements are identified and classified correctly to at least 50%. | Elements are identified and classified mostly correct and the majority of their details is accurate. | Elements are identified and classified correctly in all their details 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 elements 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?
- Make sure to give them some creative elements to play with and take inspiration from.
- Give them ideas for where to take pictorial elements from.
- What are some likely difficulties that an instructor may encounter using this activity?
- Students seem to be less used to creative space these days but are trying to conform and do everything correctly. Therefore system visions often turn out as aggregation of standard elements but fail to bring across the main purpose of the system.
- "Make sure the main purpose of the system becomes clear the first moment someone looks at the system vision" is the sentence I use most often for initial feedback, because students get caught up in identifying all the additional elements that are also part of the system.
Suggestions for Open Source Community
A system vision is a nice catchy visual for a home page - especially when the user interface of the system is not that interesting an eye catcher.
Additional Information
| ACM BoK Area & Unit(s) |
|
|---|---|
| ACM BoK Topic(s) |
Describing functional requirements using, for example, use cases or users stories, Requirements analysis modeling techniques |
| Difficulty |
easy to medium |
| Estimated Time to Complete |
twice 75 minutes (or start in lab and finish as homework) |
| Environment / Materials |
computer lab with internet |
| Author(s) | |
| Source |
n.a. |
| License |
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License
|
