Exploring artifact models (Activity)

From Foss2Serve
(Difference between revisions)
Jump to: navigation, search
 
Line 8: Line 8:
 
|overview=
 
|overview=
 
In this activity, students will work with the concepts of artifact models and develop a simple one themselves.
 
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, CSU Long Beach, Penzenstadler|Requirements Engineering]] course.
 +
 +
It is based on the [https://www.slideshare.net/kamikitty/requirements-engineering-artifactoriented-requirements-engineering "AMDiRE" lecture slides] and can be conducted individually or in small teams.
 
|prerequisites=
 
|prerequisites=
This is an activity used in the [http://foss2serve.org/index.php/Requirements_Engineering,_CSU_Long_Beach,_Penzenstadler Requirements Engineering] course. <br/> It is based on the [https://www.slideshare.net/kamikitty/requirements-engineering-artifactoriented-requirements-engineering "AMDiRE" lecture slides] and can be conducted individually or in small teams.
 
 
|objectives=
 
|objectives=
Apply and develop simple requirements engineering artifact models, compare them to a reference model and perform a gap analysis.
+
Apply and develop simple requirements engineering artifact models, compare them to a reference model, and perform a gap analysis.
 
|process skills=
 
|process skills=
[[:Category:Information Processing|Information Processing]],  
+
[[:Category:Information Processing|Information Processing]], [[:Category:Critical Thinking|Critical Thinking]]
[[:Category:Critical Thinking|Critical Thinking]]
+
 
}}
 
}}
  
Line 42: Line 44:
  
 
= Notes for Instructors =
 
= 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.
+
 
 +
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 ===
 
=== Assessment ===
Line 99: Line 103:
 
{{Learning Activity Info
 
{{Learning Activity Info
 
|acm unit=
 
|acm unit=
SE Requirements Engineering
+
[[:Category:SE Requirements Engineering|SE Requirements Engineering]]
 
|acm topic=
 
|acm topic=
 
Evaluation and use of requirements specifications
 
Evaluation and use of requirements specifications
Line 109: Line 113:
 
computer lab with internet
 
computer lab with internet
 
|author=
 
|author=
[http://foss2serve.org/index.php/User:BPenzenstadler Birgit Penzenstadler]
+
[[User:BPenzenstadler|Birgit Penzenstadler]]
 
|source=
 
|source=
 
n.a.
 
n.a.
Line 116: Line 120:
 
}}
 
}}
  
[[Category:Learning_Activity]]
+
[[Category:Learning Activity]]
[[Category:Specification_and_Design]]
+
[[Category:Specification and Design]]
[[Category:Requirements_Engineering]]
+
[[Category:Requirements Engineering]]
 
[[Category:Documentation]]
 
[[Category:Documentation]]
[[Category:Ready_to_Use]]
+
[[Category:SE Requirements Engineering]]
 +
[[Category:Ready to Use]]

Latest revision as of 13:50, 15 October 2018


Overview

Title

Exploring artifact models

Overview

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.

Prerequisites
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

Information Processing, Critical Thinking


Background

  • 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.

Directions

In this lab session, we will work on artifact models and getting a good overview of the development environment and information sources of OpenMRS.

  1. Getting familiar with the developer environment of OpenMRS
    1. Read through http://write.flossmanuals.net/openmrs-developers-guide/collaboration-tools/
    2. Where would be the appropriate starting points to ask for RE?

(Please provide the URLs as well so I can follow your thoughts better.)

  1. 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.
  2. 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?
  3. 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.

Deliverables

  • 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.

Assessment

  • 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.

Comments

  • 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.

Additional Information

ACM BoK
Area & Unit(s)

SE Requirements Engineering

ACM BoK
Topic(s)

Evaluation and use of requirements specifications

Difficulty

medium

Estimated Time
to Complete

75 minutes

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

Personal tools
Namespaces
Variants
Actions
Events
Learning Resources
HFOSS Projects
Evaluation
Navigation
Toolbox