Requirements Validation

Requirements Elicitation and System Refactoring in an Agile Environment

Overview

Students will prototype a system that manifests as a house. The stakeholder (instructor) has a small set of requirements for the system that are needed, and some that are desired but not critical. Students are instructed to devise effective questions for the stakeholder (instructor), whereby the responses are used to prototype the system based on the derived features. At the end of each sprint, each team presents their system to the class and the stakeholder offers feedback on requirements coverage. At the beginning of the new sprint, the stakeholder makes a change of a requirement that would require refactoring of the prototype.

Learning outcomes

Upon a successful completion of this project the students will be able to:

  • Devise a set of appropriate elicitation to ask a stakeholder;
  • Generalize a set of requirements based on stakeholder interaction;
  • Describe the important of reflecting on team effectiveness and the role of refactoring in an agile environment;
  • Validate a set of requirements for completeness and accuracy.

Prerequisites

Timing considerations

50 minutes for 2 sprints, 1 hour 10 minutes for 3 sprints.

Number of participants

This activity works well with teams of up to 5 participants.

Logistics

Each student needs a separate small building space. One table will be used to place all models. All discussions occur within a single team. Each team has its own baseplates to build a model representing the system.

Materials and supplies

  • LEGO sets for each student (same as for the LSP skill building exercise): one LSP exploration bag per student. Also, any large LEGO Classic sets, along with some LEGO City sets (those with minifigures, etc.) can be used;
  • Sticky notes and marker(s) or access to a whiteboard (for each team)
  • Notepad and pen OR tablet (for the instructor to take notes)
  • Sample Stakeholder Requirements:
    • Initial requirements:
      • House with 3 rooms, where each room has a window and a doorway.
      • House is single story, with a single (front) door.
      • Doors and Doorways shall be sized to fit a minifigure.
      • A single outer wall shall be a solid color.
      • The house shall have landscaping. NOTE: This is intentionally vague as these parts may not be consistent across kits.
    • Suggested requirements that require refactoring:
      • A loft needs to be added to the house (a 2nd floor room).
      • The solid color wall needs to be striped with 2 alternating colors.
      • The roof needs a skylight.

References

Scenario of the activity

  1. Requirements elicitation: 30 minutes
    1. Students will prototype a system, which manifests as a house. The stakeholder (instructor) has a small set of requirements for the system that are needed, and some that are desired but not critical. Students are instructed to devise effective questions for the stakeholder (instructor), whereby the responses are used to prototype the system based on the derived features.
    2. Each team needs to elicit requirements, so in order to do so in a manner that will provide them with useful information they must decide as a group what 3 questions will be the most effective in terms of gathering requirements. They can write their questions on post-its or on their whiteboard when their questions are ready for the stakeholder to respond with answers. The team can raise their hands when they need to interact with the stakeholder. The stakeholder needs to respond to the question as it was written (not what they meant) – For example, if a team wrote a question as a yes/no question then the response needs to be yes/no.
    3. The students build their prototype based on your responses. The students document the features they elicited on sticky notes.
    4. At the end of the sprint, each team briefly explains their prototype in terms of what features it represents. Each team places their sticky notes on the board.
    5. The stakeholder shares the initial requirements that they wanted (setting aside these postings or circling them to call them out), and ask teams to reflect on the effectiveness of their questions were at eliciting these requirements.
  2. Refactoring: 20 minutes (for each new sprint)
    1. A new sprint is starting, and the stakeholder has a new requirement (see Materials & Supplies for a suggested list). The new requirement should require refactoring.
    2. Give the teams time to refactor their system to meet the new requirement. They also need to meet the other prior requirements that were missed.
    3. At the end of the sprint, each team briefly explains their prototype in terms of what feature it represents and how the prototype was refactored to meet the revised requirements. Also, how did the team work to refactor the prototype efficiently? What could have been done to be more efficient?
    4. Check the requirements for consistency. Are there any ambiguities or contradictions?
      Learning point: requirements validation—requirements must be complete and consistent.

Practical observations

  • Keep track of the questions that each team asks to help you keep track of what team asked what question(s).
  • If the activity can be conducted in a 50-minute class session, it can be helpful to keep a timer to help keep track of the time.
  • If using LEGO identical sets for each team, be mindful that the models return to the correct storage container. One tip is to place the model inside of the container and disassemble it inside of the container to minimize the loss of parts.

Notes on scaling up/down

This is a team-based activity. It has been run successfully with larger classes, though the challenge is having enough time to facilitate discussion with large numbers of teams (8+). For larger classes, a TA should help serve as a stakeholder so that the teams can be divided across both the instructor and the TA.