Computer Science · Grade 10

Active learning ideas

Requirements Gathering and Specification

Active learning works well for requirements gathering because it mirrors real-world software development, where communication and clarity are critical. Students practice skills they will use daily as developers, turning abstract ideas into concrete specifications through collaboration and iteration.

• Ontario Curriculum Expectations
• CS.HS.D.2
• CS.HS.D.3

• 20–45 min
• Pairs → Whole Class
• 4 activities

Activity 01

• Collaborative Problem-Solving
• 30 min · Pairs

Role-Play: Stakeholder Interviews

Assign pairs: one as developer, one as client with a vague app idea like a school event planner. The developer asks targeted questions to uncover needs, then drafts initial requirements. Pairs switch roles and compare specs for clarity.

Differentiate between functional and non-functional requirements.

Facilitation Tip

During stakeholder interviews, provide students with role cards that include hidden constraints to encourage deeper questioning.

What to look for

Present students with a scenario, e.g., 'Design a simple online library catalog.' Ask them to list two functional requirements and two non-functional requirements for this system. Review responses for clarity and correctness.

• Apply
• Analyze
• Evaluate
• Create
• Relationship Skills
• Decision-Making
• Self-Management

Activity 02

• Collaborative Problem-Solving
• 45 min · Small Groups

Small Groups: Spec Building Workshop

Provide a problem statement, such as designing a grade tracker app. Groups brainstorm and categorize functional and non-functional requirements, then write a complete spec document. Share one key requirement per group with the class.

Construct a set of clear and unambiguous requirements for a software project.

Facilitation Tip

In the spec building workshop, supply a template for requirements that includes fields for measurability and testability to guide precision.

What to look for

In pairs, students draft a set of 3-5 requirements for a hypothetical app (e.g., a task manager). They then swap documents and use a checklist to evaluate their partner's requirements for clarity, testability, and potential ambiguity. The checklist includes questions like: 'Is each requirement specific?' 'Can this requirement be tested?'

• Apply
• Analyze
• Evaluate
• Create
• Relationship Skills
• Decision-Making
• Self-Management

Activity 03

• Collaborative Problem-Solving
• 35 min · Whole Class

Whole Class: Requirements Review Walkabout

Students post their specs on posters. Class members rotate, noting issues in completeness, consistency, or ambiguity using a checklist. Debrief as a group to refine originals.

Evaluate the completeness and consistency of a given set of requirements.

Facilitation Tip

For the requirements review walkabout, ask students to leave sticky notes with questions or suggestions on each group's specs to foster peer feedback.

What to look for

Provide students with a poorly written requirement, such as 'The app should be fast.' Ask them to rewrite it as a clear, testable non-functional requirement and explain why their revision is better.

• Apply
• Analyze
• Evaluate
• Create
• Relationship Skills
• Decision-Making
• Self-Management

Activity 04

• Collaborative Problem-Solving
• 20 min · Individual

Individual: Iterative Refinement

Students revise their specs based on peer feedback and class discussion. Add test cases to verify each requirement, then self-assess against criteria for unambiguity.

Differentiate between functional and non-functional requirements.

Facilitation Tip

During iterative refinement, give each student a different change request to simulate real-world updates, then have them revise their specs accordingly.

What to look for

Present students with a scenario, e.g., 'Design a simple online library catalog.' Ask them to list two functional requirements and two non-functional requirements for this system. Review responses for clarity and correctness.

• Apply
• Analyze
• Evaluate
• Create
• Relationship Skills
• Decision-Making
• Self-Management

A few notes on teaching this unit

Experienced teachers approach this topic by emphasizing the iterative nature of requirements gathering. They avoid treating specs as static documents, instead modeling how to revisit and revise them based on new insights. Research suggests that students learn best when they see the direct link between poor requirements and project failures, so include examples of real-world cases where vague specs caused problems. Encourage students to ask 'how will I test this?' for every requirement to build testability into their thinking from the start.

Successful learning looks like students creating clear, testable requirements that balance user needs with system constraints. They should demonstrate the ability to distinguish functional from non-functional needs and adapt their specifications as new information arises.

---

Watch Out for These Misconceptions

• During the Spec Building Workshop, watch for students who list only functional requirements and ignore quality aspects like performance or accessibility.

  Provide a checklist of non-functional categories (e.g., usability, security) and ask students to brainstorm at least two examples for each before finalizing their specs.

• During the Requirements Review Walkabout, watch for students who accept vague descriptions like 'user-friendly interface' as valid requirements.

  At each station, give students a 'red flag' card to mark vague language and require them to rewrite the requirement on the spot using measurable terms.

• During the Iterative Refinement activity, watch for students who treat requirements as fixed once written.

  Introduce a 'change log' template where students must document every revision, including the reason for the change and how it affects other requirements.

---

Methods used in this brief

• Collaborative Problem-Solving