Requirements Engineering

Focus on Use Cases


Students are provided with a description of a hypothetical software system used to post, submit, and grade homework assignments at a college or university. Students will identify actors, use cases, and the connections between them and build corresponding LEGO models. These models will help students visualize the problem at hand and provide an easy-to manipulate medium to discuss various possibilities for (re)arranging the actors, use cases, and their connections during brainstorming to gain a better shared understanding of the problem by the team, and to resolve any possible ambiguities and omissions. As a result of this activity, students will be able to see how their LEGO model of the system’s use cases maps into a UML use case diagram.

Learning outcomes

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

  • Identify unique use cases in a set of functional requirements;
  • Validate the consistency of user requirements;
  • Design and explain UML use case diagrams;
  • Organize use cases with include and extend dependencies.


Timing considerations

60-70 minutes.

Number of participants

This activity works well for teams of 8-12 participants. Larger groups should be broken down into two or more teams working in parallel.


Each team needs a separate building space (a large table), with or without chairs. 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 for each team:
    • A set with a diverse combination of bricks. Suitable sets include LEGO Classic Large Creative Brick Box 10698.
    • A set of minifigures (with at least two minifigures per person), preferably with accessories. Suitable sets include LEGO Education Community Minifigure Set 45022.
    • Two large baseplates. Suitable baseplates include 10714 or 10700.
    • At least two connectors per person. Instead of using these LEGO connectors, it may be more practical to improvise with a length of thread that can be secured between two interlocked LEGO bricks at each end. [TBD: need a picture]
  • Handouts: problem description (see below).
  • A whiteboard with marker(s).


Scenario of the activity

  1. Introduction: 3 minutes
    1. Distribute the handout with the problem description. Mention that it is likely incomplete and that there may be some ambiguities.
    2. Explain that the objective of this activity is work on the systems requirements by identifying actors and use cases, connecting them, and creating a UML use case diagram.
  2. Identify actors: 5 minutes per iteration
    1. Each student identifies and builds a model representing a single actor. Everyone builds individually, in silence, with no discussions. Time: 2 minutes.
    2. Once the models are built, each student within the team very briefly (no more than 20 seconds per person) justifies their choice of actors to their team.
      Typical (expected) actors: student, instructor, teaching assistant. Sometimes students also identify these actors that are much less relevant in the context of the presented system: system administrator, registrar, secretary, hacker.
    3. Each team groups similar actors together on a small platform. There will be one platform per actor so that there are several students, a few instructors, several teaching assistants, etc.
      From now on, each actor will be represented by a single platform with several mini figures on it.
    4. Ask students if there are any additional important actors that are not yet represented and repeat the current step (2), if necessary.
  3. Identify use cases: 15 minutes per iteration
    1. Each student within a team needs to identify and build a model representing a single use case. Everyone builds individually, in silence, with no discussions. Time: 3 minutes.
    2. Once the individual models are built, each student tells their team a story explaining their chosen use case (no more than 30 seconds per story).
      Very likely, some students within the team will come up with similar use cases. In that event, group similar individual models.
    3. Place each unique use case model on a large baseplate (or several baseplates pushed together).
      This produces a large model identifying the system boundaries.
    4. Repeat this step (3) as necessary.
      Typically, at least two iterations are needed to identify a reasonable set of use cases covering the functionality of the system provided in the original problem description.
  4. Make connections: 15 minutes
    1. Students connect each use case in their team’s model to one or more actors using connecting elements. It works best to ask each student to start by making connections for the use cases they created.
      Step back and observe the big picture, then repeat this step (4.a) to add any missing connections.
    2. Check if there are any use cases that are left unconnected to any of the actors.
      This might indicate an issue not noticed earlier. This may also indicate a functionality/feature that is outside of the system’s scope, which should be moved outside the system boundary (off the baseplate).
    3. The resulting model should now resemble a UML use case diagram with use cases connected to actors.
      It may be helpful to rearrange the models representing actors and/or use cases to reduce the number of overlapping connectors.
  5. UML diagram and debrief: 5-10 minutes
    1. Start with one team, and ask them to briefly explain one or two of their most important use cases and the actor(s) they are connected to. Ask the other teams if they identified similar use cases and the related actors. Repeat, asking each team to share their use case(s) that have not been identified previously. Write down all identified use cases on the whiteboard.
    2. Using one of the resulting models as an example, point out all of the identified use cases. Draw a UML use case diagram trying to mimic the layout of the LEGO model.
    3. Discuss the importance of everyone’s input to form the final outcome.
      Even if there are use cases that ended up outside the system boundaries, that is still useful because it helped the team gain a better understanding of the scope of the system’s functionality.

Practical observations

  • Students will be asking for clarifications regarding the requirements stated in the problem description. They are intentionally incomplete to prompt students to think outside the box and, possibly, invent new actors and use cases. Avoid offering any additional details in addition to what is stated in the problem description.
  • Since this is a longer activity, it is very important to keep a close eye on the clock to ensure that there’s enough time for every part of this activity.
  • As with many other activities, its learning outcomes are fully achieved through a successful debrief. The debrief in this activity is concentrated at its very end. Do not skip it. Ensure that there is ample time to discuss and draw the resulting UML diagram based on the student models.


Problem description and a sample use case diagram

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 over thirty. The vast majority of work is done by teams in parallel. The only possible bottleneck that requires the instructor’s interaction with each team is during testing. As noted above, it’s important not to linger too long with each team during the testing phases of the activity.