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.

• 11th Grade
• Computer Science
• 4 activities
• 30 min–40 min

Learning Objectives

1. Explain at least three distinct methods for gathering software requirements from diverse stakeholders.
2. Analyze how ambiguous requirements can negatively impact project timelines and user satisfaction.
3. Design user stories and corresponding acceptance criteria for a given software feature, adhering to a specified format.
4. Evaluate the clarity and completeness of user stories and acceptance criteria developed by peers.
5. Identify potential sources of conflict or misunderstanding among stakeholders during the requirements gathering process.

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.

Prepare & details

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.

Setup: Small tables (4-5 seats each) spread around the room

Materials: Large paper "tablecloths" with questions, Markers (different colors per round), Table host instruction card

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

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.

Prepare & details

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.

Setup: Small tables (4-5 seats each) spread around the room

Materials: Large paper "tablecloths" with questions, Markers (different colors per round), Table host instruction card

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

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.

Prepare & details

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.

Setup: Small tables (4-5 seats each) spread around the room

Materials: Large paper "tablecloths" with questions, Markers (different colors per round), Table host instruction card

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

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.

Prepare & details

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.

Setup: Small tables (4-5 seats each) spread around the room

Materials: Large paper "tablecloths" with questions, Markers (different colors per round), Table host instruction card

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

Teaching This Topic

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.

What to Expect

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

Common Misconception

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.

What to Teach Instead

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.

Common Misconception

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.

What to Teach Instead

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.

Common Misconception

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.

What to Teach Instead

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.

Assessment Ideas

Discussion Prompt

After Role-Play: Stakeholder Interview Practice, present a new conflicting scenario and ask students to facilitate a discussion to resolve it, using evidence from their debrief notes to justify their approach.

Quick Check

During Sorting Activity: Requirements Clarity, collect three sample requirements from the activity and ask students to write one specific, testable user story and two acceptance criteria for each.

Peer Assessment

After Workshop: Acceptance Criteria Peer Review, have students exchange their revised user stories and use a checklist to assess each other’s work for clarity, measurability, and alignment with the original request.

Extensions & Scaffolding

• Challenge students who finish early to rewrite a vague user story from the sorting activity into a concise user story and measurable acceptance criteria within five minutes.
• Scaffolding for students who struggle: Provide a 'starter pack' of goal verbs (e.g., 'edit,' 'search,' 'filter') to help them turn vague requests into specific outcomes.
• Deeper exploration: Have students interview a real stakeholder outside the classroom and present their findings along with a revised set of requirements and acceptance criteria.

Key Vocabulary

Stakeholder	An individual, group, or organization who may affect, be affected by, or perceive themselves to be affected by a decision, activity, or outcome of a project. This includes end-users, clients, and project managers.
User Story	A short, simple description of a feature told from the perspective of the person who desires the new capability, usually in the format 'As a [type of user], I want [goal] so that [reason].'
Acceptance Criteria	Conditions that a software product must satisfy to be accepted by a user, customer, or other authorized entity. They define what 'done' means for a user story.
Requirements Elicitation	The practice of detecting, articulating, and understanding the needs and constraints for a system. This involves active communication with stakeholders.
Scope Creep	Uncontrolled changes or continuous growth in a project's scope. This often happens when requirements are not clearly defined or managed.