Exploring artifact models (Activity)
Exploring artifact models
In this activity, students will work with the concepts of artifact models and develop a simple one themselves.
This is an activity used in the Requirements Engineering course.
It is based on the "AMDiRE" lecture slides and can be conducted individually or in small teams.
|Learning Objectives||After successfully completing this activity, the learner should be able to:
Apply and develop simple requirements engineering artifact models, compare them to a reference model, and perform a gap analysis.
|Process Skills Practiced|
- Background reading material: "AMDiRE" lecture slides
- AMDiRE article by Mendez and Penzenstadler, Requirements Engineering, Springer
- Rationale for this activity: Artifact models are semantic and syntactic structuring mechanisms for documentation and make it easier to keep an overview of all information related to requirements engineering. Therefore, developing simple artifact models provides students with more agency to orchestrate requirements engineering activities later on. In the Requirements Engineering course, the artifact reference model AMDiRE is used as a framework for the remainder of the course.
In this lab session, we will work on artifact models and getting a good overview of the development environment and information sources of OpenMRS.
- Getting familiar with the developer environment of OpenMRS
- Read through http://write.flossmanuals.net/openmrs-developers-guide/collaboration-tools/
- Where would be the appropriate starting points to ask for RE?
(Please provide the URLs as well so I can follow your thoughts better.)
- Sketch an artifact model for OpenMRS.
We know by now that this platform and its documentation use a variety of tools and techniques for development and documentation. You are now a quality assurance person trying to establish an artifact model for them.
To be able to do so, a first step is to make an inventory of what is already present. Therefore you make a documentation of their current artifact model that we can then subsequently analyze. Break down the artifacts into their content items, a high-level structure, and note the representation.
You can start drawing it by hand, but for submission please provide a computer-based drawing, e.g. from draw.io or cacoo.com or any other drawing tool you have access to.
- Where does OpenMRS need (better) documentation?
Looking at the AMDiRE content model, can you find content items that are missing in OpenMRS, which you cannot find documentation on?
- Looking at AMDiRE, where would you get the information for the artifacts when trying to reengineer a requirements specification for OpenMRS?
List the main artifacts of AMDiRE and write down where you would find the related contents in the OpenMRS project.
Please provide the URLs as well so I can follow your thoughts better.
Assignment sheet with these directions.
- The student (team) will hand in a PDF with about one page of text documenting their answers to the questions in the directions above.
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.
- How will the activity be graded?
- The written answers can be assessed for their correctness (not necessarily absolute correctness, but whether the answers make sense given the descriptions) and thoroughness and conclusiveness of argumentation.
- The assignment was not graded but only intended to deepen the understanding of the lecture material.
- How will learning will be measured?
- Learning will be measured by the quality of the answers given. The arguments should be conclusive and evidenced with links to the documentation they found for the project.
- 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).
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)|
|Correctness||Several answers are missing or completely off.||The majority of answers makes sense and reflects a basic understanding of requirements artifact models.||Most answers are accurate in their description of how the requirements engineering artifact models of OpenSMRS (or the chose project) is composed.||All answers accurately paraphrase how the requirements engineering artifact models is composed in OpenMRS (or the chosen project) and reflect the students' understanding of the new terminology.|
|Conclusiveness||Several answers are missing or completely off.||The majority of arguments makes sense and shows a basic reflection on requirements engineering artifact models.||Most arguments are conclusive and easy to follow in their reasoning.||All arguments are conclusive, well-phrased, and easy to follow.|
|Thoroughness||Several answers are missing or completely off.||The majority of answers is complete in the sense of giving a solid description instead of just bullet points or minimalistic sentences.||Most answers are described completely in the sense of providing the whole argument instead of just a core 'punch line'.||All answers provide a well-rounded description and complete argumentation with regard to the questions.|
- What should the instructor know before using this activity?
The evaluation criteria of conclusiveness and thoroughness depend on the level of the students taking the course and are somewhat subjective. For the author, they are mainly used to make sure that the students really understood the content of the lecture and were able to apply that knowledge and assess a given documented project with regard to this aspect.
- What are some likely difficulties that an instructor may encounter using this activity?
Their level of written communication may not accurately reflect their level of actual understanding. This can be facilitated by class discussion and providing sample solutions after the initial feedback.
Suggestions for Open Source Community
A member of the open source community may make use of the results of this assignment to get feedback on how well their requirements engineering artifact model is documented for the project. This may be helpful to improve documentation and facilitate an improved change management process.
| ACM Body of Knowledge
Area & Unit(s)
Evaluation and use of requirements specifications
|Environment / Materials||
computer lab with internet
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License