Computer Science · 11th Grade · Capstone Software Development · Weeks 28-36

Requirements Gathering and Analysis

Defining what the software needs to do by understanding user needs and project goals.

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

About This Topic

Requirements gathering is the process of understanding what a software system needs to do before any code is written. It sounds straightforward, but it is one of the most common sources of project failure. Users often describe their current workaround rather than their actual goal. Stakeholders disagree. Implicit assumptions go unstated. For US 11th graders beginning a capstone project, requirements gathering is the foundational work that directly determines whether what gets built is useful.

Standard techniques include stakeholder interviews, surveys, observation, and collaborative workshops. The outputs are typically user stories and acceptance criteria, which translate needs into specific, testable behaviors. A user story follows the format 'As a [type of user], I want [goal] so that [reason].' Acceptance criteria define what 'done' looks like for that story. This specificity protects teams from scope creep and from building features no one asked for.

Active learning is particularly valuable here because requirements work is inherently social and conversational. Practicing interviews with real partners, writing user stories for actual classmates, and debating whether a requirement is clear enough builds the collaborative skills that professional software teams use every day.

Key Questions

1. Explain various techniques for gathering software requirements from stakeholders.
2. Analyze the importance of clear and unambiguous requirements for project success.
3. Design user stories and acceptance criteria for a given software feature.

Learning Objectives

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

Before You Start

Introduction to Software Development Life Cycle

Why: Students need a basic understanding of the phases of software development to appreciate where requirements gathering fits in.

Basic Project Management Concepts

Why: Familiarity with concepts like goals, objectives, and deliverables helps students understand the purpose of defining requirements.

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.

Watch Out for These Misconceptions

Common Misconception

Requirements gathering is just asking users what they want and writing it down.

What to Teach Instead

Users often describe their current process rather than their underlying goal. They assume developers share unstated context. Conflicting stakeholders give contradictory inputs. Effective requirements work involves probing, synthesizing, and validating -- not just transcription. Interview role-play exercises reveal these gaps quickly because even a willing 'user' gives answers that are incomplete or inconsistent when played realistically.

Common Misconception

User stories are the same as detailed requirements documents.

What to Teach Instead

Traditional requirements documents describe system behavior in exhaustive detail. User stories are intentionally short -- they serve as placeholders for a conversation, not complete specifications. The acceptance criteria attached to a story do the heavy work of defining done. Students who treat user stories as mini-specs tend to write them too long and skip acceptance criteria entirely, which defeats the purpose.

Common Misconception

Once requirements are gathered and documented, they shouldn't change.

What to Teach Instead

Requirements evolve as users see working software, market conditions shift, and teams learn. Agile treats changing requirements as a normal and expected part of development, not a failure of planning. The goal of good requirements work is to build shared understanding that can be updated with the least possible rework -- not to lock everything down before development begins.

Active Learning Ideas

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.

35 min·Pairs

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.

30 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.

40 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.

35 min·Small Groups

Real-World Connections

• Software developers at Google use techniques like user interviews and usability testing to gather requirements for new features in Android apps, ensuring they meet the needs of millions of users worldwide.
• Product managers at Netflix analyze user feedback and viewing data to define requirements for new recommendation algorithms or streaming interface improvements, directly impacting customer engagement.
• Game designers at Blizzard Entertainment conduct playtesting sessions and gather feedback from beta testers to refine game mechanics and features, ensuring the final product aligns with player expectations and project goals.

Assessment Ideas

Discussion Prompt

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?'

Quick Check

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.

Peer Assessment

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?'

Frequently Asked Questions

What is a user story in software development?

A user story is a short description of a software feature from the perspective of the person who will use it. The standard format is: 'As a [user type], I want [action] so that [benefit].' User stories keep focus on value to the user rather than technical implementation details. They are typically written on index cards or tickets and estimated by the development team before being scheduled into a sprint.

What are acceptance criteria and why do they matter?

Acceptance criteria are specific, testable conditions that a feature must meet to be considered complete. They remove ambiguity about what 'done' means and give QA testers clear scenarios to verify. Without acceptance criteria, developers and stakeholders often have different mental models of what was requested, leading to rework after delivery -- one of the most expensive forms of waste in software development.

What techniques do professional software teams use to gather requirements?

Common techniques include one-on-one stakeholder interviews, observation sessions where analysts watch users perform their current work, collaborative workshops that surface conflicting stakeholder needs, surveys for large user groups, and prototype-based feedback where users react to mockups. Most professional teams combine several techniques since each one surfaces different types of requirements and uncovers different blind spots.

How does active learning improve requirements gathering skills?

Requirements gathering is a conversational skill that improves through practice, not through reading. Classroom role-play with an intentionally vague user forces students to ask better questions and synthesize conflicting inputs -- exactly the conditions they will face in real projects. Peer review of user stories and acceptance criteria also builds the habit of testing assumptions before building begins.