(Re-)Engineering use cases (Activity)

Overview

Title	(Re-)Engineering Use Cases
Overview	This activity lets students (re-)create use cases and a UML use case overview diagram. This is an activity used in the Requirements Engineering course. It is based on the "Usage Models" 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: Develop a set of use cases for a system under development.
Process Skills Practiced	Information Processing

Background

• Background reading material:
  • "Usage Models" lecture slides
  • Cockburn's Use Case Template
  • Sindre & Opdahl: Eliciting security requirements with misuse cases, REJ 2005
• Rationale for this activity: Use cases are a standard elements in requirements specifications and therefore students need to know how to specify them.

Directions

• In class, we discuss how to develop and document usage models. In this assignment, you have to develop a usage model for your project system. The usage model describes the interaction between the system and the actor (user), the steps the user performs and how the system responds to those steps.
• For the usage model, please provide an overview diagram of all existing and two future use cases, plus a detailed version of at least three central use cases of the existing OpenMRS system and two use cases that are not implemented yet but would be desirable extensions, each of them including the full information from the template in the lecture slides. The detailed version per use case includes one scenario - first you describe it in the template (as main success scenario with extensions and/or variations), and then you use a message sequence chart to illustrate it.
• Please also provide your description of the rationale for your process and 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 the use case overview diagram, at least 3 detailed use cases in the form of templates and message sequence charts.

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:

• Is a use case overview diagram provided that is well structured and includes all important use cases?
• Does it have a system boundary, an actor outside that boundary, and relations from the actor to all use cases (and labelled extensions where appropriate)?
• Are all use cases that are important for the system depicted in that diagram?
• Are they structured in a hierarchy (<<extend>>, <<include>>) where appropriate?
• Is a complete and correct description provided for the (three or five or however many the instructor chooses) central use cases in a table (according to the Cockburn template)?
• Is a complete and correct description of the scenarios provided for the (three or five or however many) central use cases in one message sequence chart per use case?
• 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	Use cases or sequences are missing, description is minimalistic and incomplete.	Use cases or sequences are present with a basic description of everything in the diagrams and templates.	Use cases or sequences are not missing any steps; complete description of all steps in diagrams and templates.	Use cases or sequences are not missing any steps; complete description of all steps accurate and detailed in diagrams and templates.
Correctness	Interaction steps are not identified and modeled or mainly incorrectly so.	Interaction steps are identified and modeled correctly to at least 50%.	Interaction steps are identified and modeled mostly correct and the majority of their details and dependencies is accurate.	Interaction steps are identified and modeled correctly in all their details as well as the dependencies between use cases.
Understandability	Diagrams are missing, illegible, confusing or plain wrong.	Diagrams are rudimentary but shows a clear structure of elements and their relations, notations are used properly.	Diagrams are well-structured and easy to understand in their relations between the elements, notation used properly in both types of diagrams.	Diagram is easy to understand, very well structured and error-free UML notations in both message sequence charts and use case overview diagram.

Comments

• What should the instructor know before using this activity?
  • This is a common-practice specification technique in industry that students should definitely familiarize themselves with.
• What are some likely difficulties that an instructor may encounter using this activity?
  • In their first drafts, students often miss depicting all user interaction and instead only model what the system does. It is important that they know they have to model both sides, the user input and the resulting system output.
  • When this is hard to get for the students, I often explain using a ping-pong analogy. A player can only continue the game if the call comes back to them.

Suggestions for Open Source Community

None so far.