(Re-)Engineering Quality requirements (Activity)

Overview

Title	(Re-)Engineering Quality Requirements
Overview	In this activity, students learn a simple method to specify non-functional requirements. This is an activity used in the Requirements Engineering course. It is based on the "Classification of non-functional requirements" 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: Specify precise quality requirements, process requirements, and system constraints.
Process Skills Practiced	Information Processing

Background

• Background reading material:
  • "Classification of non-functional requirements" lecture slides
  • Rethinking the notion of non-functional requirements by Martin Glinz, Proc. Third World Congress for Software Quality, 2005
  • Non-functional requirements in architectural decision making by D Ameller, C Ayala, J Cabot, X Franch - IEEE software, 2013
  • Software quality: the elusive target by B Kitchenham, SL Pfleeger - IEEE software, 1996
• Rationale for this activity: Non-functional requirements and quality requirements are often still neglected in requirements engineering practice, and even if specified, then they are often still the first ones that do not get implemented because of time or budget constraints. This leads to big problems in the software industry, and by teaching students this important aspect early on, they will hopefully be able to change that status quo.

Directions

• In class, we discuss how to develop and document “non-functional” requirements. In this assignment, you have to develop the non-functional requirements for OpenMRS.
• For this assignment, you will use your input from the earlier content items (goal model, usage model) including the feedback you received on those.
• On that basis, your team develops a small set of non-functional requirements, as described and discussed in the lecture (use the template below). This shall be provided in the form of
  • Three process requirements
  • Three deployment requirements
  • Three system constraints, and
  • Six quality requirements (for different quality characteristics).
• These requirements shall be linked refinements of your earlier elicited goals, so please name the goals as rationale. Also, they need to be implemented in OpenMRS, not inferred in the sense of “made up” from your own ideas.
• Please also provide your description of the rationale for your results, at least two paragraphs of how you did it and what you found difficult or the most challenging aspect of it.

Type of NFR and quality characteristic	<Quality characteristic / system constraint / development process / deployment requirement>
NFR description	<Description of what the actual requirement is>
Rationale	<Goal the requirement is derived from>
Satisfaction criterion	<Metric that needs to be achieved. When will the stakeholder be satisfied?>
Measurement	<How the metric will be measured/determined. Describe how the test will be conducted on whether this requirement is met by the system. >
Risk	<In case this is requirement was not met - what could happen?>
Compliance in OpenMRS	<Description of why you think this requirement is being fulfilled and reference to artifact that proves this compliance.>

Assignment sheet with these directions.

Deliverables

• Students will hand in a PDF with non-functional requirements specified according to the template 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 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:

• The measurement actually tests the quality attribute they are naming.
• The description gives an actual answer to how well the system is doing w.r.t. the specified quality attribute.
• The steps described in the measurement are enough for a tester who wasn’t involved in the development to follow along and perform the tests for you. (Remember that in the real world the author of the test specification might not be the one performing the tests.)
• Process requirements: template filled out completely and correctly (as in the criteria above)
• Deployment requirements: template filled out completely and correctly (as in the criteria above)
• System constraints: template filled out completely and correctly (as in the criteria above)
• Quality requirements: template filled out completely and correctly (as in the criteria above)
• 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	Requirements are missing, description is minimalistic and incomplete.	Requirements are present with a basic description of all fields in template.	Requirements are all present with a good description of all fields in template.	Requirements are all present with a very detailed description of all fields in template.
Correctness	Requirements are not identified and described or mainly incorrectly so.	Requirements are identified and described correctly to at least 50%.	Requirements are identified and described mostly correct and the majority of their details is accurate.	Requirements are identified and described completely correct and all their details are accurate.
Understandability	Requirements are missing, illegible, confusing or plain wrong.	Requirements specifications are rudimentary but the descriptions are understandable.	Requirements specifications are well-structured and easy to understand in their phrasing, test measures are easy to follow.	Requirements specifications are well-structured and easy to understand in their phrasing, test measures are easy to follow by a test engineer who knows nothing else about the system.

Comments

• What should the instructor know before using this activity?
  • Specifying good quality requirements can be tedious but it makes for good classroom discussions.
• What are some likely difficulties that an instructor may encounter using this activity?
  • Some requirements can be classified one way or the other. It depends on the chosen phrasing. A safety requirement can be phrased as system constraint or as quality requirement, and both can be correct. The classification is supposed to help pick the right phrasing for a given project situation, not a once-and-for-all label for a requirement.

Suggestions for Open Source Community

None so far.