(Re-)Engineering Quality requirements (Activity)

From Foss2Serve
(Difference between revisions)
Jump to: navigation, search
 
(One intermediate revision by one user not shown)
Line 1: Line 1:
 
=== Overview ===
 
=== Overview ===
 +
 
{{Learning Activity Overview
 
{{Learning Activity Overview
−
|title=(Re-)Engineering Quality Requirements  
+
|title=
−
|overview= In this activity, students learn a simple method to specify non-functional requirements.
+
(Re-)Engineering Quality Requirements  
−
|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-nonfunctional-requirements  "Classification of non-functional requirements"]  lecture slides and can be conducted individually or in small teams.
+
|overview=
−
|objectives=Able to specify precise quality requirements, process requirements, and system constraints.
+
In this activity, students learn a simple method to specify non-functional requirements.
−
|process skills=[http://foss2serve.org/index.php/Category:Information_Processing Information Processing]
+
 
 +
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-nonfunctional-requirements  "Classification of non-functional requirements"]  lecture slides and can be conducted individually or in small teams.
 +
|prerequisites=
 +
|objectives=
 +
Specify precise quality requirements, process requirements, and system constraints.
 +
|process skills=
 +
[[:Category:Information Processing|Information Processing]]
 
}}
 
}}
  
 
=== Background ===
 
=== Background ===
  
−
* Is there background reading material?
+
* Background reading material:
−
* What is the rationale for this activity?
+
** [https://www.slideshare.net/kamikitty/requirements-engineering-nonfunctional-requirements  "Classification of non-functional requirements"]  lecture slides
 +
** [http://www.ptidej.net/courses/log3410/fall11/Lectures/Article_5.pdf Rethinking the notion of non-functional requirements] by Martin Glinz, Proc. Third World Congress for Software Quality, 2005
 +
** [http://ieeexplore.ieee.org/abstract/document/6381398/ Non-functional requirements in architectural decision making] by D Ameller, C Ayala, J Cabot, X Franch - IEEE software, 2013
 +
** [http://ieeexplore.ieee.org/abstract/document/476281/ 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 ===
 
=== Directions ===
Line 54: Line 67:
  
 
|}
 
|}
 +
 +
[http://foss2serve.org/index.php/File:2017_542_Lab_NonFunctionalRequirements.pdf Assignment sheet] with these directions.
 +
 +
 +
 
=== Deliverables ===
 
=== Deliverables ===
  
−
* What will the student hand in?
+
* Students will hand in a PDF with non-functional requirements specified according to the template above.
  
 
= 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.
  
Line 64: Line 83:
  
 
* How will the activity be graded?
 
* How will the activity be graded?
 +
** The deliverable will be graded as one part of the [http://foss2serve.org/index.php/(Re-)Engineering_a_Software_Requirements_Specification requirements specification].
 
* How will learning will be measured?  
 
* 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?  
 
* 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)
  
−
Include sample assessment questions/rubrics. Feel free to indicate that the activity itself is not graded, however it would be helpful to include any questions that might be used at a later date to interpret learning, for example on a quiz or exam.  
+
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:
 
The form of the assessment is expected to vary by assignment. One possible format is the table:
Line 77: Line 108:
 
! Level 4 (exceptional)
 
! Level 4 (exceptional)
 
|-
 
|-
−
| '''Criterion 1...'''
+
| '''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.
  
 
|-
 
|-
−
| '''Criterion 2...'''
+
| '''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.
  
 
|}
 
|}
Line 95: Line 133:
  
 
* What should the instructor know before using this activity?
 
* 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?
 
* 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 ===
 
=== Suggestions for Open Source Community ===
  
−
Suggestions for an open source community member who is working in conjunction with the instructor.
+
None so far.
  
 
=== Additional Information ===
 
=== Additional Information ===
 
{{Learning Activity Info
 
{{Learning Activity Info
−
|acm unit=SE Requirements Engineering
+
|acm unit=
−
|acm topic=Non-functional requirements and their relationship to software quality,<br/> Properties of requirements including consistency, validity, completeness, and feasibility
+
[[:Category:SE Requirements Engineering|SE Requirements Engineering]]
−
|difficulty=medium
+
|acm topic=
−
|time=twice 75 minutes (or start in lab and finish as homework)
+
Non-functional requirements and their relationship to software quality,<br/> Properties of requirements including consistency, validity, completeness, and feasibility
−
|environment=computer lab with internet
+
|difficulty=
−
|author=[http://foss2serve.org/index.php/User:BPenzenstadler Birgit Penzenstadler]
+
medium
−
|source=n.a.
+
|time=
−
|license={{License CC BY SA}}
+
twice 75 minutes (or start in lab and finish as homework)
 +
|environment=
 +
computer lab with internet
 +
|author=
 +
[[User:BPenzenstadler|Birgit Penzenstadler]]
 +
|source=
 +
n.a.
 +
|license=
 +
{{License CC BY SA}}
 
}}
 
}}
  
−
--------------------
+
[[Category:Learning Activity]]
−
{{License CC BY SA}}
+
[[Category:Specification and Design]]
−
 
+
[[Category:Requirements Engineering]]
−
[[Category:Learning_Activity]]
+
−
[[Category:Specification_and_Design]]
+
−
[[Category:Requirements_Engineering]]
+
 
[[Category:Documentation]]
 
[[Category:Documentation]]
 +
[[Category:SE Requirements Engineering]]

Latest revision as of 13:44, 15 October 2018

Contents

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

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 BoK
Area & Unit(s)

SE Requirements Engineering

ACM BoK
Topic(s)

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

Difficulty

medium

Estimated Time
to Complete

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

Retrieved from "http://foss2serve.org/index.php?title=(Re-)Engineering_Quality_requirements_(Activity)&oldid=12795"
Personal tools
Namespaces
Variants
Actions
Events
Learning Resources
HFOSS Projects
Evaluation
Navigation
Toolbox