LEGO for Software Engineering

Overview

Students will work closely as a team to prototype a system to compete against a well-known social media system (such as Facebook, Twitter, Instagram, SoundCloud) or a well-defined hardware system (such as Roomba vacuum, Nest learning thermostat, or Amazon Echo). Students will brainstorm and identify a set of features that will implement the core functionality and help the new system distinguish itself from the competition.

Learning outcomes

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

• Synthesize a core set of requirements for a well-defined system;
• Generalize a set of requirements by identifying related and overlapping requirements;
• Distinguish between functional, non-functional, and domain requirements;
• Validate a set of requirements for completeness and consistency.

Prerequisites

• Basic familiarity with the concepts of requirements;
• LSP skills building activity.

Timing considerations

Up to 60 minutes.

Number of participants

This activity works well for teams of up to 25 participants. Larger groups can be broken down into separate teams working in parallel.

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 builds their own set of actors and use cases. Each team uses its own baseplates to build a model representing the system.

Materials and supplies

• LEGO sets: one LSP exploration bag per student. Note that LSP exploration bags are only sold in boxes of 100.
  Alternatively, any cheap ($5) LEGO Classic, LEGO City, LEGO Friends, or similar sets can be used.
• All students can also share one or several large LEGO set with a diverse combination of bricks. Suitable sets include LEGO Classic Large Creative Brick Box 10698.
• A set of minifigures with accessories may also be useful. Suitable sets include LEGO Education Community Minifigure Set 45022.
• Sticky notes and marker(s).

References

References

• S. Kurkovsky, S. Ludi, L. Clark: Active Learning with LEGO for Software Requirements / ACM DL
• S. Kurkovsky: Teaching Software Engineering with LEGO Serious Play / ACM DL

Scenario of the activity

1. Requirements elicitation: 20 minutes
1. Explain the problem:
   We are building a competitor to a well-known social media system (such as Facebook, Twitter, Instagram, SoundCloud) or a well-defined hardware system (such as Roomba vacuum, Nest learning thermostat, or Amazon Echo). We need to brainstorm and come up with some features that will implement the core functionality and help us distinguish ourselves from the competition. Emphasis on the word features, not requirements or functionality. We should refer to an existing system such that students are already familiar with, have enough general knowledge about, and which allows a lot of room for interpretation and extension.
2. Asks an open-ended question: what features would you envision in the system?
   Emphasize the word ‘feature’ to make it clearer to the students what they should focus on. Instead of replying, each student builds a model representing a singly feature of the system. Time: 2 minutes.
   No discussions, interruptions, distractions.
3. Students take turns to very briefly explain the models they have built and the system features they represent. Everyone takes turns to speak. Keep the story related to the model and nothing else. Limit the discussion to the things that are in the model. Invite questions, but only limited to what’s in the model.
   Learning point: many students come up with similar ideas, but everyone may have a different perspective. It is important to consider everyone’s input to obtain a holistic unbiased picture. In requirements elicitation, all stakeholders have an opportunity to contribute their input to the list of requirements.
4. Students capture their ideas. Right after presenting their feature, each student writes a few words (no more than three, in big letters) on a sticky note describing their main idea. All sticky notes are collected and placed on the board where everyone can see them. No personally identifiable information should be left on the notes.
   Learning point: students should be able make their ideas more concrete and formulate them in a concise form.
5. Repeat, as necessary.
   A single round may not be sufficient to generate all important ideas. Only after seeing the results of one round on the board, students may start to come up with really interesting features.
2. Requirements analysis: 20 minutes
1. Once all students explained their proposed features of the system and all sticky notes are collected on the board, ask the class to suggest some logical groupings.
   Learning point: some requirements may be similar or overlapping. Clusters of requirements help us identify and focus on the core functionality of the system.
2. Reject those requirements that don’t make sense. Place them in a "trash can" on the board.
   Learning point: it takes a collective effort to see the ‘big picture’ in order to identify what is important/relevant and what is not.
3. Divide requirements into three categories: functional, non-functional, and domain requirements.
   Most likely, the vast majority of requirements identified by the students will be functional requirements. The instructor will need to suggest some non-functional and/or domain requirements, if none or too few are present on the board.
   Learning point: an opportunity to review different types of requirements.
4. Check the requirements for completeness. What are the most important requirements? Did we miss anything important? Are there any assumptions that must be identified as separate requirements? E.g., if there’s a requirement to be able to rank photos in a social media system, do we have a requirement that would allow us to post a photo? Learning point: requirements validation—requirements must be complete and consistent.
5. Check the requirements for consistency. Are there any ambiguities or contradictions?
   Learning point: requirements validation—requirements must be complete and consistent.

Practical observations

• Remind students that’s OK to propose similar requirements during the first phase. In fact, it is very helpful to have such similar/duplicating requirements to make the learning points stronger.
• It is very important to keep a close eye on the clock during the second part of the exercise to ensure that there’s enough time for every part of this activity. As with all such activities, the key to achieving the learning points is in the discussions, all of which are concentrated in the second part.
• If using LEGO identical sets for each student, it may be necessary to break up the models after each round in part one of the activity. Do not mix up the bricks from different LEGO sets.

Handouts

n/a

Notes on scaling up/down

This is a team-based activity. It has been run successfully with various number of students ranging from five to 25. This activity does not lend itself naturally to splitting into smaller groups and running portions of the activity in parallel.