Computer Science · Grade 12

Active learning ideas

Requirements Engineering

Requirements engineering is best learned through active practice, as it requires students to step into different roles and analyze complex scenarios. Engaging in simulations and case studies helps solidify understanding of the nuances involved in defining and documenting software needs.

• Ontario Curriculum Expectations
• CS.SE.5
• CS.PM.2

• 35–45 min
• Pairs → Whole Class
• 3 activities

Activity 01

• Role Play
• 45 min · Pairs

Role Play: Client Interview Simulation

Students pair up, with one acting as a client and the other as a business analyst. The analyst interviews the client to gather requirements for a hypothetical application, documenting functional and non-functional needs. Roles can be switched for broader practice.

Explain the difference between functional and non-functional requirements.

Facilitation Tip

During the Role Play: Client Interview Simulation, ensure the 'client' student is prepared to articulate vague needs, prompting the 'business analyst' to practice probing questions that uncover specific functional and non-functional requirements.

• Apply
• Analyze
• Evaluate
• Social Awareness
• Self-Awareness

Activity 02

• Role Play
• 40 min · Small Groups

Use Case Diagram Creation

Given a scenario for a simple application (e.g., a library book checkout system), students individually or in small groups create a use case diagram. They identify actors, use cases, and relationships, then write brief descriptions for each use case.

How do ambiguous requirements impact the success of a software project?

Facilitation Tip

During Use Case Diagram Creation, circulate to check that students are correctly identifying actors, use cases, and their relationships, ensuring the diagrams accurately represent the system's intended interactions.

• Apply
• Analyze
• Evaluate
• Social Awareness
• Self-Awareness

Activity 03

• Role Play
• 35 min · Small Groups

Requirements Analysis: Case Study

Present students with a case study detailing a software project that failed due to poor requirements. In small groups, they analyze the case to identify specific requirement issues and propose how better requirements engineering could have prevented the failure.

Design a set of clear and testable requirements for a simple application.

Facilitation Tip

During the Requirements Analysis: Case Study, prompt students to identify specific points in the case where poor requirements gathering led to problems, connecting these issues directly to the project's failure.

• Apply
• Analyze
• Evaluate
• Social Awareness
• Self-Awareness

A few notes on teaching this unit

Experienced teachers approach requirements engineering by emphasizing its practical application rather than just theoretical definitions. They use active learning strategies that allow students to experience the challenges of elicitation and the consequences of poorly defined requirements firsthand, moving beyond simple memorization.

Students will demonstrate a clear understanding of functional and non-functional requirements by successfully eliciting them in a simulated client interview and analyzing their impact in a case study. They will be able to differentiate between various requirement types and articulate their importance in project success.

---

Watch Out for These Misconceptions

• During the Role Play: Client Interview Simulation, watch for students treating requirements as a simple wish list from the client.

  Redirect by asking the business analyst student to identify specific, measurable, and testable requirements derived from the client's 'wishes' and explain how these translate into actionable development tasks.

• During Use Case Diagram Creation, watch for students failing to differentiate between functional and non-functional requirements when defining use cases.

  Prompt students to explicitly label or describe how each use case contributes to a functional requirement (what the system does) and then to consider how non-functional requirements (like performance or security) might impact the design or implementation of those use cases.

• During the Requirements Analysis: Case Study, watch for students overlooking the impact of non-functional requirements on the project's failure.

  Guide students to identify specific instances in the case study where issues like poor performance, inadequate security, or usability problems, stemming from neglected non-functional requirements, directly contributed to the project's downfall.

---

Methods used in this brief

• Role Play