Computer Science · 12th Grade · Social Impacts and Professional Ethics · Weeks 37-45

Software Engineering Capstone: Project Planning

Students initiate their capstone project, focusing on requirements gathering, project scope, and initial design.

• Common Core State Standards
• CSTA: 3B-AP-18
• CSTA: 3B-AP-20

About This Topic

The Software Engineering Capstone begins here, and the project planning phase is where many real-world projects succeed or fail before a single line of code is written. For US 12th-grade students working under CSTA 3B-AP-18 and 3B-AP-20, this topic introduces requirements gathering, scope definition, and initial design as professional practices, not just school steps to complete.

Students learn that translating what a user wants into what a system must do is a nontrivial process. User stories, use case diagrams, and acceptance criteria are tools for making ambiguous requirements concrete and testable. Scope management , deciding what is in and out of a project's boundary , is equally critical: scope creep is among the most common reasons software projects run over time and budget.

Active learning is particularly well-suited to project planning because the skills are inherently collaborative and iterative. Students who practice gathering requirements from a 'client' (a peer or teacher playing a stakeholder role), revising their scope document based on feedback, and justifying methodology choices develop the professional reasoning that distinguishes strong software engineers from those who can only implement specifications handed to them.

Key Questions

1. Design a comprehensive project plan, including scope, timeline, and resource allocation.
2. Analyze the challenges of translating user needs into technical requirements.
3. Justify the choice of development methodologies for a given project.

Learning Objectives

• Design a project plan document that includes a detailed scope statement, a phased timeline with milestones, and an initial resource allocation for a software capstone project.
• Analyze user feedback and existing documentation to translate ambiguous user needs into specific, measurable, achievable, relevant, and time-bound (SMART) technical requirements.
• Evaluate and justify the selection of a specific software development methodology (e.g., Agile, Waterfall) for a given capstone project based on its characteristics and constraints.
• Critique the scope of a proposed software project to identify potential areas of scope creep and propose strategies for mitigation.

Before You Start

Introduction to Software Development Life Cycle

Why: Students need a foundational understanding of the stages involved in creating software before focusing on the planning phase.

Basic Project Management Concepts

Why: Familiarity with basic concepts like timelines, tasks, and resources is necessary for developing a comprehensive project plan.

Key Vocabulary

Requirements Gathering	The process of collecting information from stakeholders to understand what a software system needs to do. This involves identifying user needs, system functionalities, and constraints.
Project Scope	Defines the boundaries of a project, specifying what work will be done and what will not. It includes deliverables, features, functions, tasks, deadlines, and costs.
User Story	A short, simple description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. It typically follows the format: 'As a [type of user], I want [some goal] so that [some reason].'
Acceptance Criteria	A set of conditions that must be met for a user story or feature to be considered complete and accepted by the client or stakeholders. They make requirements testable.
Development Methodology	A framework or process used to structure, plan, and control the process of developing an information system. Examples include Agile, Waterfall, and Scrum.

Watch Out for These Misconceptions

Common Misconception

Requirements gathering is a one-time step you complete before starting development.

What to Teach Instead

Requirements evolve as both the client and the development team learn more about the problem. Professional practice treats requirements as living documents that are refined through continuous stakeholder feedback. Agile methodologies formalize this by building re-evaluation into each sprint.

Common Misconception

A detailed project plan means the project will stay on schedule.

What to Teach Instead

Plans are estimates under uncertainty. The value of planning is not the plan itself but the thinking it forces: identifying dependencies, surfacing assumptions, and establishing a baseline to measure against. Experienced engineers use plans as anchors for communication, not guarantees of outcomes.

Common Misconception

More features in scope means a better project.

What to Teach Instead

Scope bloat is a primary cause of project failure. A smaller, well-executed scope delivers more value than a large, half-finished one. Active requirements review , where students must justify each feature against user needs , builds the discipline of intentional scoping.

Active Learning Ideas

Role-Play: Client Requirements Interview

Pairs take turns playing 'client' and 'developer.' The client has a brief describing a vague software need; the developer must ask targeted questions to extract specific, testable requirements. After 15 minutes, pairs swap roles with a different scenario. Debrief focuses on which questions surfaced the most useful information and which assumptions developers nearly baked in without asking.

40 min·Pairs

Think-Pair-Share: Scope Definition Challenge

Present a project brief with an intentionally broad scope (e.g., 'build an app for the school library'). Individually, students list 10 features they assume the project includes. Pairs compare lists , the divergence illustrates why explicit scope documents matter. Each pair then drafts a one-paragraph scope statement that would resolve the ambiguities they identified.

30 min·Pairs

Gallery Walk: Development Methodology Trade-offs

Post stations describing Waterfall, Agile (Scrum), Kanban, and Spiral methodologies with a project scenario attached to each. Student groups rotate and annotate each station: what are the advantages and risks of this methodology for this project? The debrief surfaces the insight that methodology choice depends on project context, not on which is 'best' in the abstract.

45 min·Small Groups

Design Workshop: Full Project Plan Draft

Each student drafts an initial project plan for their capstone: a scope statement, a list of functional and non-functional requirements, a preliminary timeline with milestones, and a justification of their chosen methodology. Peer reviewers use a structured checklist to identify gaps in requirements specificity and timeline realism before the plan is submitted.

75 min·Individual

Real-World Connections

• Software development teams at companies like Google and Microsoft use detailed project plans, including scope documents and timelines, to guide the creation of new applications and features, managing millions of dollars in development costs.
• Product managers at startups often conduct extensive user interviews and create user stories to define the minimum viable product (MVP) for their new software, ensuring they build what users actually need and can iterate quickly based on feedback.

Assessment Ideas

Exit Ticket

Provide students with a brief description of a hypothetical software project (e.g., a mobile app for local event discovery). Ask them to write down: 1) Two specific user stories for the app, and 2) One potential challenge in translating user needs into technical requirements for this app.

Quick Check

Present students with a sample project scope document that contains vague language or missing key sections. Ask them to identify at least two areas that need clarification or expansion, explaining why they are problematic for project planning.

Discussion Prompt

Facilitate a class discussion using the prompt: 'Imagine you are leading a capstone project and have two potential clients with slightly conflicting needs. How would you use requirements gathering techniques and scope definition to manage these expectations and create a unified project plan?'

Frequently Asked Questions

What is requirements gathering in software engineering

Requirements gathering is the process of identifying and documenting what a software system must do (functional requirements) and the constraints it must operate within (non-functional requirements like performance, security, and usability). It typically involves stakeholder interviews, observation, and iterative review, producing artifacts like user stories, use case diagrams, and acceptance criteria.

How do you define the scope of a software project

Project scope specifies what the software will and will not include. A good scope statement lists deliverables, identifies boundaries (what is explicitly out of scope), and sets constraints like timeline and budget. Defining scope early prevents scope creep , the uncontrolled expansion of features that derails most over-budget software projects.

What development methodology should a high school capstone project use

Agile (Scrum) is commonly recommended for student capstone projects because it structures work into short, reviewable sprints that match classroom timelines and provides checkpoints where teachers and peers can give feedback. Waterfall can work for projects with very stable requirements, but most student projects benefit from the built-in flexibility of Agile.

How does active learning support software project planning skills

Project planning is fundamentally social and iterative , it requires negotiating with stakeholders, revising documents based on feedback, and defending decisions under scrutiny. Role-play, peer review workshops, and structured design critiques give students repeated practice with these skills in low-stakes settings before their real capstone work begins.