(Re-)Engineering goals (Activity)

Overview

Title	(Re-)Engineering Goal Models
Overview	This activity lets students explore the concept of goals and lets them practice a goal modeling technique based on a simple UML-based notation. This is an activity used in the Requirements Engineering course. It is based on the slides "Goals and Constraints" and can be conducted individually or in small teams.
Prerequisites
Learning Objectives	After successfully completing this activity, the learner should be able to: Use goal modeling in requirements engineering to elicit and document stakeholders' needs, wishes, and constraints.
Process Skills Practiced	Information Processing

Background

• Background reading material: slides "Goals and Constraints"
• A generic model for sustainability by Penzenstadler and Femmer, GIBSE 2013
• Rationale for this activity: Goals are the most important stakeholder concerns. Many problems in requirements engineering arise from hidden requirements conflicts and therefore a technique to detect such conflicts is important.

Directions

In this lab session, we will reengineer a goal model for the OpenMRS system. In class, we discussed how to develop and document goal models.

The intent for a goal model is to consolidate all the different goals that the earlier identified stakeholders have into one overview. That way they can be discussed and conflicts become visible. Furthermore, trade-offs and cross-relations can be identified, some of which might be useful, while others might impose problems for the system’s development, so it’s better to know about them early.

We will use the classification of business goals (context of the system, what are you building it for, why will people want to use it), usage goals (what the functionality will be), and system goals (quality or technical aspects). Find a way to connect from the business goals down to the usage goals (derive usage goals from business goals) and then from usage goals to system goals (derive system goals from usage goals).

Make sure your goal model contains at least 7 goals each of business goals, usage goals and system goals and at least 25 goals in total. Put them into a hierarchy with sub-goal relationships. Overall I want to see at least 3-4 levels of subgoals for more than half of the goals and that appropriate notations are used (goal categories, labeled relations for decomposition, supports and conflicts). Also make sure you identify at least one (potential) goal conflict.

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 submit a PDF with a goal model diagram, detailed goal descriptions, and 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)

Assessment questions / evaluation criteria:

• Is the goal model well structured?
• Does it contain at least 7 business goals, 7 usage goals and 7 system goals, at least 25 in

total?

• Are they broken down and refined into sub-goals where possible?
• Is each of these elements related sufficiently to the other goals and are all notations used?
• Are all stakeholders’ main concerns represented by goals?
• Is a good accompanying explanation provided for the diagram?
• Is the source for the goal denoted? (meaning, the stakeholder for the goal)
• 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	Less than 10 goals identified, incomplete description	More than 10 goals identified; complete description	All 21 goals identified and arranged in diagram; complete descriptions	21+ goals identified and arranged in diagram; all described well in detail.
Correctness	Goals are not identified and classified or mainly incorrectly so.	Goals are identified and classified correctly to at least 50%.	Goals are identified and classified mostly correct and the majority of their details is accurate.	Goals 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 goals 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?
  • Goal 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 goals 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 goals as specific as possible (instead of generic goals like 'high quality').

Suggestions for Open Source Community

Goal models could enrich the documentation of the system and make (sometimes conflicting) concerns of main stakeholders more clear.