Practice EARS (Activity)

From Foss2Serve
(Difference between revisions)
Jump to: navigation, search
 
(7 intermediate revisions by 2 users not shown)
Line 1: Line 1:
=== Overview ===
+
__NOTOC__
 +
 
 
{{Learning Activity Overview
 
{{Learning Activity Overview
|title=Practicing natural language requirements specification
+
|title=
|overview=This activity lets students practice the [https://www.slideshare.net/secret/NOcw2ahpblic2g "Easy approach to requirements syntax"], a simple pattern-based approach to specify natural language requirements that don't allow for ambiguity.
+
Practicing natural language requirements specification
|prerequisites=This is the first activity used in the [http://foss2serve.org/index.php/Requirements_Engineering,_CSU_Long_Beach,_Penzenstadler Requirements Engineering] course. It is based on the [https://www.slideshare.net/secret/NOcw2ahpblic2g lecture slides] that explain EARS and can be conducted individually or in small teams.
+
|overview=
|objectives=To practice a pattern-based approach to natural language requirements in order to develop a good, unambiguous writing style for natural language requirements.
+
This activity lets students practice the [https://www.slideshare.net/secret/NOcw2ahpblic2g "Easy approach to requirements syntax"], a simple pattern-based approach to specify natural language requirements that don't allow for ambiguity.
|process skills=[[Category:Information_Processing]]  
+
 
 +
This is the first activity used in the [[Requirements Engineering, CSU Long Beach, Penzenstadler|Requirements Engineering]] course.  
 +
It is based on the [https://www.slideshare.net/secret/NOcw2ahpblic2g lecture slides] that explain EARS and can be conducted individually or in small teams.
 +
|prerequisites=
 +
|objectives=  
 +
Practice a pattern-based approach to natural language requirements in order to develop a good, unambiguous writing style for natural language requirements.
 +
|process skills=  
 +
[[:Category:Information Processing|Information Processing]]
 
}}
 
}}
  
 
=== Background ===
 
=== Background ===
  
* [https://www.slideshare.net/secret/NOcw2ahpblic2g "Easy approach to requirements syntax" lecture slides]  
+
* Background reading material: [https://www.slideshare.net/secret/NOcw2ahpblic2g "Easy approach to requirements syntax" lecture slides]  
* Rationale: Natural language requirements are often written in an ambiguous way. EARS provides templates that help students develop a systematic way to write down functional requirements.  
+
* Rationale for this activity: Natural language requirements are often written in an ambiguous way. EARS provides templates that help students develop a systematic way to write down functional requirements.  
  
 
=== Directions ===
 
=== Directions ===
Line 28: Line 36:
 
=== Deliverables ===
 
=== Deliverables ===
  
* PDF file with three examples per [https://www.slideshare.net/secret/NOcw2ahpblic2g EARS] pattern
+
* The student (team) will hand in PDF file with three examples per [https://www.slideshare.net/secret/NOcw2ahpblic2g EARS] pattern
  
 
= 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 38: Line 48:
 
** The reading part is not assessed, but the usage of the natural language requirements patterns.
 
** The reading part is not assessed, but the usage of the natural language requirements patterns.
 
** Points are given according to correct application of the patterns.
 
** Points are given according to correct application of the patterns.
* How will learning will be measured? Ideally, there should be a way to measure each of the objectives described above.
+
* How will learning will be measured?
 
** If the students are able to correctly apply the patterns to given examples, they have mastered this skill.
 
** If the students are able to correctly apply the patterns to given examples, they have mastered this skill.
 
* How will feedback to the student be determined?  
 
* How will feedback to the student be determined?  
 
** The student receives written feedback on their submission of written requirements w.r.t. correctness and unambiguity.
 
** The student receives written feedback on their submission of written requirements w.r.t. correctness and unambiguity.
 
** Submitted solutions can be discussed in class (probably anonymizing them, according to classroom code of conduct)
 
** 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.
 
  
 
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 81: Line 89:
 
=== Additional Information ===
 
=== Additional Information ===
 
{{Learning Activity Info
 
{{Learning Activity Info
|acm unit=SE Requirements Engineering
+
|acm unit=
|acm topic=Describing functional requirements using, for example, use cases or users stories
+
[[:Category:SE Requirements Engineering|SE Requirements Engineering]]
|difficulty=easy
+
|acm topic=
|time=75 minutes (may be done in less time, depending on how much time is spent reading about FOSS)
+
Describing functional requirements using, for example, use cases or users stories
|environment=computer lab with internet
+
|difficulty=
|author=[http://foss2serve.org/index.php/User:BPenzenstadler Birgit Penzenstadler]
+
easy
|source=n.a.
+
|time=
|license={{License CC BY SA}}
+
75 minutes (may be done in less time, depending on how much time is spent reading about FOSS)
 +
|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]]
 +
[[Category:Ready to Use]]

Latest revision as of 13:55, 15 October 2018


Title

Practicing natural language requirements specification

Overview

This activity lets students practice the "Easy approach to requirements syntax", a simple pattern-based approach to specify natural language requirements that don't allow for ambiguity.

This is the first activity used in the Requirements Engineering course. It is based on the lecture slides that explain EARS and can be conducted individually or in small teams.

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

Practice a pattern-based approach to natural language requirements in order to develop a good, unambiguous writing style for natural language requirements.

Process Skills
Practiced

Information Processing


Background

  • Background reading material: "Easy approach to requirements syntax" lecture slides
  • Rationale for this activity: Natural language requirements are often written in an ambiguous way. EARS provides templates that help students develop a systematic way to write down functional requirements.

Directions

In our first lab session, we will get an overview of free open source software development and an example project, and then practice the EARS approach from today’s lecture.

Assignment sheet

Deliverables

  • The student (team) will hand in PDF file with three examples per EARS pattern

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 reading part is not assessed, but the usage of the natural language requirements patterns.
    • Points are given according to correct application of the patterns.
  • How will learning will be measured?
    • If the students are able to correctly apply the patterns to given examples, they have mastered this skill.
  • How will feedback to the student be determined?
    • The student receives written feedback on their submission of written requirements w.r.t. correctness and unambiguity.
    • 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 Nothing submitted. Correct pattern used in at least 50% of requirements. Correct pattern used in at least 80% of requirements. Correct pattern used in 100% of requirements.
Unambiguity All requirements can be misinterpreted. At least 50% of requirements are unambiguous. At least 80% of requirements are unambiguous. 100% of requirements are unambiguous.

Comments

  • Having students write natural language requirements using a straight-forward technique in the very first lab of the course gives them a stronger sense of agency and gets them more activated than reviewing higher-level concepts.
  • This task can be a bit monotonous if the students are not interested in the system, so make sure to use a system they find exciting. Or have different teams work on requirements for different systems.

Suggestions for Open Source Community

This can significantly increase the quality of natural language requirements of a project with regard to ambiguity of requirements. The output of the exercise can often be integrated beneficially into existing requirements specifications.

Additional Information

ACM BoK
Area & Unit(s)

SE Requirements Engineering

ACM BoK
Topic(s)

Describing functional requirements using, for example, use cases or users stories

Difficulty

easy

Estimated Time
to Complete

75 minutes (may be done in less time, depending on how much time is spent reading about FOSS)

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