Term Project Proposals
Purpose
Your proposals are the most important documents you will write for this project. They are where you decide what your project is and does. When you ask Claude to help implement a feature, Claude will build from your specification. Anything your specification leaves vague, Claude will fill in, and every gap it fills is a design decision you didn’t make. A detailed specification keeps the project yours.
Each proposal centers on a “By next week…” specification for the features you will have working by the following milestone. It has three parts: what those features do, the algorithms at their core, and hand-drawn sketches. You do not need to specify implementation details such as class names, helper functions, or drawing code. Claude may help with those. You do need to specify, in detail, what the user experiences and how your core algorithms work.
You will not have every answer when you write a proposal. That’s expected. When you don’t know something yet, write it down as an open question rather than leaving it out.
A test for “detailed enough”: If two different programmers each built next week’s features from your specification alone, would a user be able to tell their programs apart? If yes, your specification is leaving decisions to someone else. Add detail until the answer is no.
What to submit at each milestone
Upload each proposal to Gradescope as a single PDF, with photos of your sketches included, by the milestone deadline. Late proposals receive 0. Proposals at TP0, TP1, and TP2 have two sections: Section 1 depends on the milestone, and Section 2 holds the “By next week…” specification. The TP3 proposal has only Section 1.
| Milestone | Section 1 | Section 2: By next week… |
|---|---|---|
| TP0 | Project overview | A basic set of features that will be working by TP1 |
| TP1 | Summary of progress | The features that bring your project to MVP |
| TP2 | Summary of progress | The advanced features you will add by TP3 |
| TP3 | Final summary of progress, with demo video link | None |
Section 1 at TP0: Project overview
In Section 1 of your TP0 proposal, give a basic overview of what your project will be. In a few short paragraphs, describe:
- what the project is and what the user does in it,
- the experience you want the user to have,
- roughly what you expect the finished project to include.
This overview sets a direction. It is not a full specification, and it may change as you build. Section 2 is where the detail goes.
Section 1 at TP1, TP2, and TP3: Summary of progress
In Section 1 of your TP1, TP2, and TP3 proposals, give a short summary comparing what you built to what your last “By next week…” proposal said. Keep it brief, about half a page:
- which proposed features are working,
- which are not finished, or work differently than proposed, and why,
- any design changes you made, and the reason for each,
- sources and AI help: the external code, assets, course examples, and other sources you used since the last milestone, and what Claude or other AI helped with.
At TP3, also list known limitations and include a link to your narrated 1–3 minute demo video.
Falling short of a proposal is normal. What matters is that you can explain what happened and adjust your next proposal accordingly.
Section 2: By next week…
Section 2 specifies only the features you will have working by the next milestone. Title it “By next week” followed by the week’s goal, for example “By next week: A playable board.” What it should target depends on the milestone:
- TP0 → TP1: a basic set of features. Choose a real part of your project that will work end to end, not only a splash screen or decorative setup.
- TP1 → TP2: MVP. The features that make your project fully functional, at roughly 800–1,200 lines of code.
- TP2 → TP3: advanced features. The features that take your project beyond MVP.
Section 2 always has the three parts below. Describe the week’s new features in full detail, along with how they connect to what already works. You don’t need to re-specify features from earlier proposals unless you are changing them.
Part A: What these features do
- Overview. In a short paragraph, describe this week’s features and how they change the user’s experience.
- Screens and modes. For each screen or mode that is new or changes this week (title screen, main game, editor, results, and so on), describe:
- what the user sees,
- every action the user can take (keys, clicks, drags),
- what happens in response to each action,
- how the user gets to and leaves this screen.
- Rules and behavior. State the rules of your project precisely. Use numbers where numbers matter: speeds, sizes, scores, limits, timings. “Enemies get faster” is vague; “each wave, enemy speed increases by 10%, up to a maximum of 3× the starting speed” is a specification.
- Edge cases. List unusual situations and what should happen in each. What if the user clicks outside the board? What if two events happen at the same moment? What if the input file is empty? What if the player wins on the very first move?
- Design decisions. For each significant choice, record what you chose, what alternatives you considered, and why you chose this one. Reasons connected to the experience you want are the most useful kind.
- Out of scope. List features you have decided not to include this week, and whether you plan them for a later week. This is a decision too.
Part B: Core algorithms
Identify the one to three algorithms that this week’s features depend on. These are the problems you’d describe if someone asked, “What was hard about building this?” For each one:
- The problem. What does this algorithm need to accomplish, in one or two sentences?
- Data. What information does it take in, and what does it produce? How is that information represented (a 2D list, a dictionary, a set of objects, and so on)?
- Steps. Describe the algorithm in pseudocode or numbered steps, written by you.
- A worked example by hand. Choose a small, concrete input and walk through your algorithm step by step, showing the state at each stage. Then show the output.
- Edge cases. What inputs might break it, and how should it handle them?
- Open questions. What parts are you not sure how to solve yet?
Your algorithm plan must be your own work, completed before Claude implements the algorithm. You may ask Claude or course staff to explain general concepts, but the steps and the worked example must come from you.
Part C: Hand-drawn sketches
Draw your sketches by hand on paper or a whiteboard, and include photos or scans. Artistic talent is not graded; clarity is. Do not use AI image tools, digital mockup tools (such as Canva), or a digital tablet (like an iPad) for these. Keep to the few sketches that matter most, usually two or three:
- the most important screen that is new or changes this week, labeled with what each element is and what it does,
- a screen-flow diagram showing how the user moves between screens, if that flow is new or changes significantly this week,
- a diagram of your most important core algorithm (for example, the board before and after one step).
Using AI when writing proposals
You may use Claude to explain concepts, answer questions about what cmu_graphics can do, or help you think about whether something is feasible. You may not have Claude write any part of your specification, generate your design decisions, write your algorithm steps, or produce your sketches. Your mentor will discuss each proposal with you at the milestone meeting. You should be able to explain any choice in it and why you made it.
Keeping it current
Each proposal builds on the last. Keep every earlier proposal so your mentor can see how your thinking developed, and don’t rewrite an old proposal to match what you built. If your design changes during the week, explain the change and the reason in your next summary of progress. When you ask Claude to implement a feature, point it to the relevant part of your current proposal, and check the result against it.
Sample proposals
These samples follow one hypothetical project, Gem Cascade, through all four proposals: