Requirements engineering process (Activity)

Title	Understanding and analyzing requirements engineering processes
Overview	This activity lets students practice the new terminology and concepts on requirements engineering processes they were introduced to in the lecture. This is the second activity used in the Requirements Engineering course. It is based on the 'process' 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: Understand requirements engineering process terminology. Identify and reflect on the adequateness of a specific project's chosen process.
Process Skills Practiced	Information Processing, Critical Thinking

Background

• Background reading material: 'process' lecture slides
• Rationale for this activity: Students need to be able to analyze project documentation to understand the development process of the project and compare it with an ideal or standard requirements engineering process. This allows them to understand common practice as well as reflect on how existing practice could be improved.

Directions

In this lab session, we will identify what the RE process looks like in an open source project and compare that to what we learned in the lecture. In OpenMRS, http://openmrs.org/ how is Requirements Engineering performed?

1. The RE process:
   1. How are the four phases of requirements engineering performed in OpenMRS – Elicitation, Analysis, Specification, and Verification & Validation?
      Which indicators can you find on their website and/or their documentation (chat, issue tracker, etc.) to support this finding?
   2. How is requirements management performed in OpenMRS?
      Select 2 requirements management activities and describe how they are handled in OpenMRS.
2. What are the equivalents for the general process model elements in OpenMRS and where can they be found (descriptions of how to do things in OpenMRS)?
   What do they use for each of the following elements?
   1. Methods and Activities
   2. Roles
   3. Artifacts
   4. Tools
   5. Milestones
3. Is the development of OpenMRS more activity-oriented or more artifact-oriented?
   State your understanding and explain why in 2-3 sentences.
4. Which of the main challenges identified in http://www.requirementsengineering.org/ are relevant for open source projects and why?
   Select 3 major challenges and explain in 1-2 sentences per challenge.
5. Which of the main challenges identified in http://www.requirementsengineering.org/ are not relevant for open source projects and why?
   Select 2 challenges and explain in 1-2 sentences per challenge.

Assignment sheet with these directions.

Deliverables

• The student (team) will hand in a PDF with about two pages of written answers to the questions posed 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.
  • As this was during the second week of classes, the assignment was not graded yet 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 engineering process terminology.	Most answers are accurate in their description of how the requirements engineering process of OpenSMRS (or the chose project) is conducted.	All answers accurately paraphrase how the requirements engineering process is conducted 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 processes.	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 process is documented for the project. This may be helpful to improve documentation and facilitate an improved change management process.