Purpose of the Assessment
This assignment is intentionally built around requirements that are incomplete, inconsistent, or ambiguous. A successful submission should therefore be judged on more than whether it matches one hidden implementation. Students should demonstrate that they can notice uncertainty, ask useful questions, make defensible decisions, decompose a system, and test whether the pieces work together.
Suggested Grading Principles
Reward consistency
A documented product decision that is implemented and tested consistently is stronger evidence than code that accidentally matches an expected value.
Assess the system
Because the assignment requires separate components, students should show both component-level correctness and correct behavior across component boundaries.
Make communication visible
The limited question budget is part of the learning objective. High-value questions and concise decision records should count toward the grade.
Suggested 100-Point Rubric
This rubric is intended as a starting point. The point distribution deliberately gives substantial weight to requirements work, decomposition, and testing so that the assignment does not collapse into a code-generation exercise.
| Category | Exemplary | Proficient | Developing | Beginning |
|---|---|---|---|---|
|
Requirements analysis & interpretation
20 pts
|
Exemplary Identifies important ambiguities, inconsistencies, missing information, and risky assumptions. Documents the decisions the team made when the specification did not fully determine behavior. |
Proficient Addresses several important ambiguities but misses some high-impact issues or records decisions inconsistently. |
Developing Mostly implements the apparent requirements without showing much evidence of analyzing them. |
Beginning Little evidence of requirements analysis; major contradictions or missing information are ignored. |
|
Use of the Product Manager question budget
10 pts
|
Exemplary Uses the limited questions strategically. Questions are precise, high-value, and reduce uncertainty that affects multiple parts of the system. |
Proficient Questions are relevant and useful, though one or more could have been more precise or higher leverage. |
Developing Questions focus mainly on implementation details or resolve relatively low-impact issues. |
Beginning Questions are unused, exceed the allowed number, or do not meaningfully reduce uncertainty. |
|
Program decomposition & interfaces
15 pts
|
Exemplary The system is divided into sensible components with clear responsibilities and clean data flow between them. Separate files/classes/functions support testing and integration. |
Proficient The design is mostly modular, with a few components that are too tightly coupled or responsibilities that are unclear. |
Developing Some decomposition is present, but important logic is concentrated in a small number of places or interfaces are inconsistent. |
Beginning Little meaningful decomposition; most behavior is implemented in one place or components cannot be tested independently. |
|
Functional behavior
20 pts
|
Exemplary The implementation behaves consistently with the team's documented decisions and the clarified requirements. Core workflows complete successfully with representative inputs. |
Proficient Most core behavior works, with a few incorrect cases or mismatches between documented decisions and implementation. |
Developing A substantial portion works, but several required behaviors are incomplete or inconsistent. |
Beginning Core workflow is incomplete or frequently fails on ordinary inputs. |
|
Unit testing
10 pts
|
Exemplary Unit tests cover the major components, important boundary cases, and at least some error conditions. Tests clearly communicate the intended behavior of each component. |
Proficient Most major components have useful unit tests, but important boundaries or error cases are missing. |
Developing Some unit tests exist, but coverage is narrow or tests mostly repeat simple happy-path examples. |
Beginning Few or no meaningful unit tests. |
|
Integration testing
10 pts
|
Exemplary Integration tests exercise realistic multi-component workflows and verify that information moves correctly across component boundaries. |
Proficient At least one useful end-to-end or multi-component test is present, with minor gaps in coverage. |
Developing Integration testing is limited or mostly duplicates unit tests. |
Beginning No meaningful integration testing. |
|
Handling invalid or unsupported inputs
5 pts
|
Exemplary Invalid breeds, locations, values, or unsupported cases produce understandable errors rather than crashes or silent incorrect results. |
Proficient Most invalid inputs are handled clearly, with a few rough edges. |
Developing Some validation exists, but several unsupported cases fail unclearly. |
Beginning Invalid inputs frequently cause confusing failures or incorrect output. |
|
Technical communication & reflection
10 pts
|
Exemplary The submission clearly explains important design decisions, unresolved risks, testing strategy, and what changed after clarification or testing. The explanation is concise and specific. |
Proficient The explanation covers most important decisions and testing choices but lacks some detail or specificity. |
Developing A brief explanation is present but focuses mainly on what the code does rather than why decisions were made. |
Beginning Little or no explanation of decisions, risks, or testing. |
Suggested Evidence to Collect
The easiest way to grade the learning goals is to require a small set of artifacts that make student reasoning visible. These can be submitted alongside the code or included in a short README.
Before coding
- A short list of ambiguities or risks the team noticed.
- The questions they chose to spend on the Product Manager.
- A sketch or short description of planned components and responsibilities.
With the implementation
- The source files/classes/modules.
- Unit tests for individual components.
- Integration tests for multi-component workflows.
- A short decision log for ambiguities that remained unresolved.
After testing
- One example of a test that exposed a misunderstanding or design problem.
- One change made because of clarification, testing, or integration.
- One remaining risk or question the team would investigate next.
Optional demonstration
- A brief live or recorded walkthrough of one requirement from specification to test.
- A short explanation of how two components interact.
- A response to one unseen edge case supplied by the instructor.
Assessment in a Generative-AI Setting
One motivation for this activity is that the implementation itself is intentionally within the range of what a modern code generator can often produce. If AI tools are permitted, the assessment should therefore focus on evidence that the student can specify, evaluate, test, and revise the generated work.
A useful policy is to require students to record their requirements analysis, question choices, and proposed component structure before using a code generator. Afterward, students can be asked to identify at least one place where the generated code made an assumption, missed a requirement, or needed a new test.
If AI use is not permitted in a particular course, the same rubric still works; the categories evaluate software reasoning rather than the means by which syntax was produced.
Instructor Commentary and Grading Notes
Distinguish specification errors from implementation errors
When a submission fails, consider asking: did the student misunderstand the requirement, make an explicit but different product decision, or simply implement their own stated decision incorrectly? These are different kinds of problems and can receive different feedback.
Prefer targeted feedback over large point deductions
A single misunderstood ambiguity can affect several downstream calculations. Avoid deducting full points in every category for the same root cause. Instead, score the requirements decision once, then evaluate whether the rest of the system is internally consistent with that decision.
Use the tests as communication artifacts
A strong test suite should tell the reader what the team believes the system is supposed to do. Test names, edge cases, and integration scenarios are therefore part of the student's technical communication, not merely a mechanism for catching bugs.
Consider a short oral check
If authorship or AI assistance is a concern, a two- to five-minute explanation can provide strong evidence of understanding. Ask a student to explain one design decision, one test, and one ambiguity rather than asking them to reproduce code from memory.
Possible Assessment Variations
Lower-stakes CS1 version
Reduce the rubric to requirements analysis, decomposition, functional behavior, unit tests, integration tests, and reflection. Grade primarily for completion plus evidence of thoughtful decisions.
Team version
Add a short individual reflection identifying the student's contribution and one requirement or test they personally investigated.
AI-explicit version
Require a brief comparison between an AI-generated implementation and the team's tests, including at least one issue the tests exposed.
Testing-focused version
Provide partial implementations and shift more points toward test design, ambiguity identification, and integration behavior.