(Re-)Engineering a system vision (Activity)

From Foss2Serve
Revision as of 13:13, 15 October 2018 by Clif.kussmaul (Talk | contribs)
Jump to: navigation, search

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.
It is based on the "System Vision" 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:

Able to 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
Practiced

Information Processing, Problem Solving


Background

Directions

  1. 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.
  2. 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/
  3. 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.
  4. 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.
  5. 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.
  6. 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?
  • 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)

SE Requirements Engineering

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)

Birgit Penzenstadler

Source

n.a.

License

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

CC license.png



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