Learning Goals
Students should experience that programming is not only the act of writing code. In this activity, implementation is intentionally manageable for a CS1 student while the harder work lies in deciding what the system should mean and how to know whether it behaves correctly.
Requirements precision
Notice ambiguity, contradiction, missing information, and assumptions hidden inside apparently concrete requirements.
Strategic communication
Use a limited question budget to ask high-value questions of the Product Manager rather than asking for implementation help.
Design and decomposition
Break the system into components with clear responsibilities, interfaces, and data flow.
Testing as specification
Use unit and integration tests to make decisions explicit and verify both individual pieces and whole-system behavior.
Instructor Preparation
- Publish the student-facing specification and data tables without the teacher ambiguity notes.
- Decide whether students work individually, in pairs, or in teams of 3–4.
- Prepare the Product Manager answer sheet so responses stay consistent across teams.
- Choose the question limit; three questions per team is the default.
- Decide whether questions are spoken, submitted on paper, or posted through a form/chat.
- Prepare Java and/or Python starter structures if students are not expected to build scaffolding themselves.
- Confirm that students know how to run unit tests in the selected language.
- Decide whether AI tools are prohibited, permitted after planning, or fully permitted with documentation.
- Prepare one or two acceptance-test scenarios that cross several components.
- Decide whether the first acceptance-test run is formative, graded, or purely diagnostic.
90–115 Minute In-Class Lesson Plan
This version is centered on a 105-minute meeting. The time tags show where the plan can be compressed or expanded.
Launch: “What counts as correct?”
Introduce the fictional ParvoCure project and explain that incorrect behavior can come from incorrect code or unclear requirements. Tell students they will have only a small number of opportunities to clarify the product.
Compress to 7Expand to 12
Team formation and roles
Form teams and designate a Product Owner/spokesperson. Only that person submits the team’s Product Manager questions. Other members focus on requirements, design, and tests.
Compress to 3Expand to 7
Requirements analysis
Students inspect the specification, tables, inputs, outputs, and component descriptions. Ask them to record ambiguities, conflicting information, missing information, and risky assumptions. Teams also sketch likely component boundaries.
By the end of this phase, each team chooses its limited Product Manager questions.
Core activityKeep at least 15 min
Product Manager questions
Take questions one team at a time or collect them simultaneously and answer from the prepared answer sheet. Keep the constraint visible: teams may ask only the allowed number of questions.
Default: 3 questions/team
Design and test planning
Require a quick architecture checkpoint before coding: What files/classes/modules will exist? What does each component receive and return? Which behaviors need unit tests? Which workflow needs an integration test?
If AI is allowed, this is a good point to freeze the planning artifact before code generation begins.
Compress to 10Expand to 18
Implementation + unit testing
Teams implement components and unit tests. In a short meeting, do not require every component to be complete before moving on. Circulate and ask, “What requirement does this test represent?” and “What assumption did you make here?”
Compress to 20Expand to 30
Integration / acceptance-test challenge
Give teams one end-to-end scenario or have them run their own integration test. The goal is to expose interface mismatches, inconsistent interpretations, or assumptions that only become visible once components interact.
Treat the first failure as diagnostic evidence rather than simply as a correctness penalty.
Keep at least 10 min
Team retrospective
Each team records one ambiguity they caught, one they missed, one question they wish they had asked, and one test or integration failure that changed their understanding.
Compress to 5
Whole-class wrap-up
Compare interpretations. Close by connecting the experience to generative AI: code generation does not remove the need to decide what should be generated, what assumptions are acceptable, and how correctness will be checked.
Optional in 90-minute version
Multi-Day Project Plan
The multi-day version allows students to build the complete system, write stronger tests, and revise their design after integration failures. This five-day sequence can be compressed to three days by combining Days 1–2 and Days 4–5.
| Day | Primary focus | In-class work | Checkpoint / artifact | Instructor role |
|---|---|---|---|---|
| Day 1 | Requirements and risk | Introduce scenario; teams read the specification; identify ambiguities, inconsistencies, and missing information; select Product Manager questions. | Risk/ambiguity log, three proposed questions, initial component sketch. | Resist resolving everything. Ask what could go wrong if an assumption is wrong. |
| Day 2 | Clarification and architecture | Product Manager question session; teams revise their understanding; define component responsibilities and interfaces; write initial unit-test cases before or alongside implementation. | Updated decision log, architecture plan, at least one unit test per major component. | Answer only through the Product Manager role; check that tests correspond to stated decisions. |
| Day 3 | Implementation and unit testing | Build the separate files/classes/modules; load reference data; implement validation; run component-level tests. | Working components, passing unit tests for most components, list of known failures. | Coach decomposition and debugging. When students ask “what should it do?”, redirect to their decision log or PM answers. |
| Day 4 | Integration and system behavior | Connect components; run realistic checkout scenarios; add integration tests; investigate mismatches between individually-correct components. | At least one complete end-to-end test plus a record of one integration problem and its resolution. | Run or release acceptance-test scenarios. Encourage teams to diagnose root causes rather than patch outputs. |
| Day 5 | Acceptance, revision, and reflection | Final acceptance tests; revise code/tests/documentation; prepare a short technical explanation or demo; complete reflection. | Final code, unit/integration tests, decision log, short reflection, optional demo. | Debrief across teams. Highlight different reasonable interpretations and the value of explicit assumptions. |
Optional out-of-class work
- After Day 1: refine the ambiguity log and rank uncertainties by risk.
- After Day 2: create test cases from clarified requirements before writing additional implementation.
- After Day 3: finish component implementations and bring a failing test to class.
- After Day 4: revise integration tests and prepare one question about a remaining system risk.
- After Day 5: submit a short reflection connecting the activity to AI-assisted programming.
Facilitating the Product Manager Role
The limited-question mechanic works best when students see the Product Manager as a scarce source of domain clarification, not as a debugging assistant.
Good questions
- Resolve a requirement that changes system behavior.
- Clarify units, time windows, or the source of required data.
- Resolve contradictions between requirements.
- Affect multiple components or tests.
Low-value questions
- Ask how to write a loop, class, or dictionary.
- Ask the Product Manager to debug syntax.
- Repeat information already stated clearly.
- Spend a question on a safe engineering decision the team can document.
If a team asks a programming question, the Product Manager can respond: “That is an engineering decision; what product behavior do you need clarified?”
Options for Generative-AI Use
Option A: No AI
Use when the course still needs students to practice implementation fluency. The same requirements and testing goals remain.
Option B: AI after planning
Require the ambiguity log, Product Manager questions, component design, and initial tests before AI use. This best matches the assignment’s intended framing.
Option C: AI throughout
Allow AI from the beginning, but grade the student’s ability to identify unsupported assumptions, write tests, revise generated code, and explain the resulting system.
Useful reflection prompt
“Identify one place where generated code could be syntactically correct and still be wrong because the requirement was unclear.”
Debrief Prompts
- Which requirement looked clear at first but became ambiguous when you tried to implement or test it?
- Which of your questions produced the most useful information? Why?
- What did your team assume without asking?
- Did two individually-correct components disagree when integrated? What caused the mismatch?
- Which test best expresses a requirement that was not obvious from the original specification?
- What would have happened if your incorrect assumption reached production?
- What work in this assignment could a code generator do easily? What work still required human judgment?
- If you had one more Product Manager question, what would you ask now?
Additional Facilitation Notes
Keep ambiguity productive, not arbitrary
Students should be able to discover that something is underspecified and make progress by asking, documenting, or testing. Avoid ambiguities that depend on obscure domain knowledge.
Do not let one early mistake destroy the rest of the project
If a team makes a reasonable but different product decision, allow them to continue so long as they document it and implement it consistently. Reserve acceptance-test failures for clarified requirements or contradictions within the team’s own decisions.
Use integration failures as discussion material
When one component expects a value in a different unit, format, or meaning than another component provides, resist fixing it immediately. Ask which interface contract was assumed and where that contract should have been recorded or tested.
Preserve time for reflection
The retrospective is where the activity becomes more than a quirky programming problem. Even five minutes of explicit reflection helps students connect requirements work to software engineering practice and the limitations of code generation.