Software Engineering Capstone: Project Planning

Active learning works for project planning because students must experience the tension between idealized plans and real-world constraints. When they practice gathering requirements from a mock client or defend scope decisions in a group, they confront the messy gaps between user needs and technical execution.

• 12th Grade
• Computer Science
• 4 activities
• 30 min–75 min

Learning Objectives

1. 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.
2. Analyze user feedback and existing documentation to translate ambiguous user needs into specific, measurable, achievable, relevant, and time-bound (SMART) technical requirements.
3. 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.
4. Critique the scope of a proposed software project to identify potential areas of scope creep and propose strategies for mitigation.

Project-Based Learning

⏱ 40 min·Pairs

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.

Prepare & details

Design a comprehensive project plan, including scope, timeline, and resource allocation.

Facilitation Tip: During the Role-Play: Client Requirements Interview, circulate with a clipboard to note which students ask clarifying questions versus those who jump to solutions.

Setup: Flexible workspace with access to materials and technology

Materials: Project brief with driving question, Planning template and timeline, Rubric with milestones, Presentation materials

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

Think-Pair-Share

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

Prepare & details

Analyze the challenges of translating user needs into technical requirements.

Facilitation Tip: In the Think-Pair-Share: Scope Definition Challenge, stop the pair discussion after two minutes to call on groups that disagree on feature prioritization.

Setup: Standard classroom seating; students turn to a neighbor

Materials: Discussion prompt (projected or printed), Optional: recording sheet for pairs

• Understand
• Apply
• Analyze
• Self-Awareness
• Relationship Skills

Gallery Walk

⏱ 45 min·Small Groups

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.

Prepare & details

Justify the choice of development methodologies for a given project.

Facilitation Tip: For the Gallery Walk: Development Methodology Trade-offs, post a large matrix on the wall where students physically place sticky notes to mark their preferred methodology for each scenario.

Setup: Wall space or tables arranged around room perimeter

Materials: Large paper/poster boards, Markers, Sticky notes for feedback

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

Project-Based Learning

⏱ 75 min·Individual

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.

Prepare & details

Design a comprehensive project plan, including scope, timeline, and resource allocation.

Facilitation Tip: In the Design Workshop: Full Project Plan Draft, require each group to present their project plan to another group before submitting it for peer review.

Setup: Flexible workspace with access to materials and technology

Materials: Project brief with driving question, Planning template and timeline, Rubric with milestones, Presentation materials

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

Teaching This Topic

Teachers should treat this topic as a cycle of negotiation, not a linear process. Research shows that students grasp project planning best when they repeatedly revise artifacts under time pressure, so avoid letting groups finalize documents too early. Emphasize that the goal is not perfection but disciplined iteration, where students learn to surface assumptions and adjust based on feedback.

What to Expect

Successful learning looks like students shifting from vague ideas to concrete artifacts with measurable constraints. They should begin articulating user needs as testable requirements, defining scope with explicit trade-offs, and aligning their design choices with methodology trade-offs.

Watch Out for These Misconceptions

Common Misconception

During Role-Play: Client Requirements Interview, some students may assume the client’s first answer is the final requirement.

What to Teach Instead

After the role-play ends, have students revisit their notes and circle any requirements that are vague or tied to assumptions. They must draft follow-up questions to refine those requirements before moving to the next activity.

Common Misconception

During Think-Pair-Share: Scope Definition Challenge, students may believe adding more features always improves the project.

What to Teach Instead

Use the group’s shared document to highlight where features conflict with the time box. Ask each pair to defend their top three features against the project timeline, then remove one feature if it exceeds the scope.

Common Misconception

During Gallery Walk: Development Methodology Trade-offs, students might think Agile is always superior to Waterfall.

What to Teach Instead

Provide a scenario with high regulatory constraints (e.g., medical software) and ask students to justify why a hybrid approach might work better. They must present their reasoning to the class during the gallery walk.

Assessment Ideas

Exit Ticket

After Role-Play: Client Requirements Interview, provide each student with a sticky note. Ask them to write one requirement they gathered and one assumption they still have about the project.

Quick Check

During Think-Pair-Share: Scope Definition Challenge, circulate and listen for pairs that explicitly state their prioritization criteria (e.g., 'We chose this feature because it aligns with the client’s primary goal').

Discussion Prompt

After Design Workshop: Full Project Plan Draft, facilitate a peer-assessment where groups rotate to review another group’s project plan, using a rubric that includes 'clear scope boundaries' and 'realistic timeline' as criteria.

Extensions & Scaffolding

• Challenge: Ask students to draft a risk register with mitigation strategies for their project plan.
• Scaffolding: Provide sentence stems for user stories (e.g., 'As a [user type], I want [action] so that [benefit]').
• Deeper exploration: Have students research one real-world project failure tied to poor scope definition and present the lessons learned.

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.