Computer Science · 11th Grade

Active learning ideas

Requirements Gathering and Analysis

Active learning works for requirements gathering because students must experience firsthand how assumptions shape outcomes. When students practice interviewing real stakeholders or critiquing vague requests, they confront the gap between what people say and what they truly need, which is impossible to grasp through lecture alone.

• Common Core State Standards
• CSTA: 3B-AP-19

• 30–40 min
• Pairs → Whole Class
• 4 activities

Activity 01

• World Café
• 35 min · Pairs

Role-Play: Stakeholder Interview Practice

Pairs take turns as developer and user for a fictional app idea. The developer must elicit requirements using only open-ended questions; the user plays a domain expert who doesn't know technical vocabulary and describes their current workaround rather than what they actually need. Pairs then write three user stories from the interview and compare how much each story changed from the user's first answer.

Explain various techniques for gathering software requirements from stakeholders.

Facilitation Tip

During Role-Play: Stakeholder Interview Practice, coach students to probe beyond initial answers by asking 'Why?' at least twice before taking notes.

What to look for

Present students with a scenario where two stakeholders have conflicting requirements for a simple app (e.g., a note-taking app where one wants simple text entry and another wants rich formatting). Ask: 'How would you facilitate a discussion to resolve this conflict and arrive at a clear, agreed-upon requirement?'

• Understand
• Apply
• Analyze
• Social Awareness
• Relationship Skills

Activity 02

• World Café
• 30 min · Small Groups

Sorting Activity: Requirements Clarity

Provide a set of 12 fictional requirements written at varying levels of clarity and ambiguity. Groups sort them into 'clear enough to build from,' 'needs clarification,' and 'too vague to use.' Groups then rewrite two 'too vague' requirements into testable user stories with acceptance criteria and share their rewrites for peer feedback.

Analyze the importance of clear and unambiguous requirements for project success.

Facilitation Tip

During Sorting Activity: Requirements Clarity, have students justify each placement by reading the requirement aloud and pointing to the specific source text.

What to look for

Provide students with a vague feature request, such as 'Make the website faster.' Ask them to write two specific, testable user stories and their acceptance criteria that address different interpretations of 'faster.' For example, one story might focus on page load time, another on search response time.

• Understand
• Apply
• Analyze
• Social Awareness
• Relationship Skills

Activity 03

• World Café
• 40 min · Small Groups

Workshop: Acceptance Criteria Peer Review

Each team writes acceptance criteria for one feature of their capstone project, then swaps with another team. The reviewing team evaluates whether each criterion is testable, specific, and complete using a provided checklist. Authors revise based on the feedback before the criteria are finalized for sprint planning.

Design user stories and acceptance criteria for a given software feature.

Facilitation Tip

During Workshop: Acceptance Criteria Peer Review, rotate pairs so each student receives feedback from at least two different peers before revising.

What to look for

Have students write a user story and acceptance criteria for a feature in a hypothetical app. Then, have them exchange their work with a partner. Instruct the assessor to answer: 'Is the user role clear? Is the goal specific? Is the reason compelling? Are the acceptance criteria measurable and unambiguous?'

• Understand
• Apply
• Analyze
• Social Awareness
• Relationship Skills

Activity 04

• World Café
• 35 min · Small Groups

Case Study Discussion: When Requirements Fail

Analyze a real project failure rooted in requirements problems -- the Healthcare.gov launch or the Denver Airport baggage system work well. Small groups identify the specific requirements failures, then propose what a better requirements process could have caught. Groups report out and the class synthesizes a checklist of common requirements risks.

Explain various techniques for gathering software requirements from stakeholders.

Facilitation Tip

During Case Study Discussion: When Requirements Fail, ask students to map each failure back to a specific misstep in the requirements process before suggesting fixes.

What to look for

Present students with a scenario where two stakeholders have conflicting requirements for a simple app (e.g., a note-taking app where one wants simple text entry and another wants rich formatting). Ask: 'How would you facilitate a discussion to resolve this conflict and arrive at a clear, agreed-upon requirement?'

• Understand
• Apply
• Analyze
• Social Awareness
• Relationship Skills

A few notes on teaching this unit

Experienced teachers approach this topic by treating requirements as living conversations, not static documents. Avoid teaching that requirements must be perfect at the start; instead, emphasize iterative refinement through activities that reveal gaps early. Research shows that students grasp the importance of probing questions faster when they see how misunderstandings cascade into unusable software.

Successful learning looks like students confidently distinguishing goals from workarounds, resolving conflicting inputs with evidence, and writing acceptance criteria that teams can actually test. By the end of these activities, students should articulate why vague requirements lead to rework and how to prevent it.

---

Watch Out for These Misconceptions

• During Role-Play: Stakeholder Interview Practice, watch for students who accept every answer at face value and write it down verbatim without probing for underlying goals.

  After the role-play, debrief by replaying snippets where the 'user' gave vague or contradictory answers. Ask students to identify what they should have asked next to uncover the real need, and have them revise their notes accordingly.

• During Sorting Activity: Requirements Clarity, watch for students who treat user stories as mini-specs and copy the entire requirement into the user story field.

  During the activity, have students highlight the user role, goal, and reason in different colors for each user story. Then, ask them to rewrite any story longer than one sentence into a single concise statement with clear acceptance criteria.

• During Case Study Discussion: When Requirements Fail, watch for students who blame the user for 'not knowing what they want' instead of the process for failing to surface those needs.

  In the debrief, ask students to trace each failure back to a specific gap in the requirements process—such as unstated assumptions, conflicting stakeholders, or untested acceptance criteria—and propose one change to prevent it next time.

---

Methods used in this brief

• World Café