(Re-)Engineering Quality requirements (Activity)

From Foss2Serve
Jump to: navigation, search

Contents

Overview

Title

(Re-)Engineering Quality Requirements

Overview

In this activity, students learn a simple method to specify non-functional requirements.

Prerequisites

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.

Learning Objectives After successfully completing this activity, the learner should be able to:

Able to specify precise quality requirements, process requirements, and system constraints.

Process Skills Practiced

Information Processing


Background

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

Additional Information

ACM Body of Knowledge
Area & Unit(s)

SE Requirements Engineering

ACM Topic(s)

Non-functional requirements and their relationship to software quality,
Properties of requirements including consistency, validity, completeness, and feasibility

Level of Difficulty

medium

Estimated Completion Time

twice 75 minutes (or start in lab and finish as homework)

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



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