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.

• Grade 12
• Computer Science
• 3 activities
• 35 min–45 min

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.

Prepare & details

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.

Setup: Open space or rearranged desks for scenario staging

Materials: Character cards with backstory and goals, Scenario briefing sheet

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

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.

Prepare & details

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.

Setup: Open space or rearranged desks for scenario staging

Materials: Character cards with backstory and goals, Scenario briefing sheet

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

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.

Prepare & details

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.

Setup: Open space or rearranged desks for scenario staging

Materials: Character cards with backstory and goals, Scenario briefing sheet

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

Teaching This Topic

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.

What to Expect

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

Common Misconception

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

What to Teach Instead

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.

Common Misconception

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

What to Teach Instead

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.

Common Misconception

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

What to Teach Instead

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.

Assessment Ideas

Peer Assessment

After the Role Play: Client Interview Simulation, have students provide feedback to each other on the clarity and completeness of the elicited requirements and the effectiveness of the questioning techniques used.

Quick Check

During Use Case Diagram Creation, circulate and ask students to explain the purpose of specific actors and use cases, checking for understanding of system interactions and scope.

Discussion Prompt

After the Requirements Analysis: Case Study, facilitate a class discussion asking students to identify the key lessons learned about functional versus non-functional requirements and how they could have prevented the project's failure.

Extensions & Scaffolding

• Challenge: For students who finish early, have them consider potential scope creep scenarios for the client interview and brainstorm strategies the business analyst could use to manage them.
• Scaffolding: For students who struggle, provide a template for the client interview with pre-written prompts for functional and non-functional requirements, or offer a simplified case study with clearer failure points.
• Deeper Exploration: For students seeking more, research and present on different requirements elicitation techniques (e.g., workshops, surveys) and discuss their pros and cons.