(Re-)Engineering goals (Activity)
(→Overview) |
m (→Overview) |
||
| (One intermediate revision by one user not shown) | |||
| Line 14: | Line 14: | ||
* Use goal modeling in requirements engineering to elicit and document stakeholders' needs, wishes, and constraints. | * Use goal modeling in requirements engineering to elicit and document stakeholders' needs, wishes, and constraints. | ||
|process skills= | |process skills= | ||
| − | [[:Category:Information Processing]] | + | [[:Category:Information Processing|Information Processing]] |
}} | }} | ||
| Line 131: | Line 131: | ||
{{License CC BY SA}} | {{License CC BY SA}} | ||
}} | }} | ||
| − | |||
| − | |||
| − | |||
[[Category:Learning_Activity]] | [[Category:Learning_Activity]] | ||
Latest revision as of 13:27, 15 October 2018
Contents |
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:
|
| Process Skills Practiced |
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.
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 |
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
|
