A polished app demo does not necessarily prove a strong computer science capstone. An interface can work while difficult requirements remain untested; a research model can appear promising without a valid comparison. The important question is what the student contributes—and what evidence supports that contribution.
This guide helps you evaluate a proposed or completed project using eight quality criteria, a self-review worksheet, and a worked example. Use it to identify gaps before discussing your project with an instructor.
When you compare academic submission with career presentation, use FileMakr’s capstone project vs portfolio project guide to decide what to prioritize and how to adapt your case study.
Jump to: Eight criteria · Evidence by project type · Scorecard · Worked example · FAQs
Why do U.S. course expectations differ?
There is no universal U.S. university capstone grading rubric. A course may emphasize an end-to-end software product, algorithmic analysis, or research methodology. The relevant standard is the current rubric for your class.
| Official guidance | Distinct emphasis | Implication for your project |
|---|---|---|
| Northern Arizona University: CS capstone sponsor guidance | A defined software product with substantial design and coding | Specify the product and explain the software challenge. |
| George Washington University: 2026–27 Senior Design criteria | Both algorithmic and technical components; a database-backed website alone is insufficient as the core contribution | Identify the computing challenge and how you will evaluate it. |
| University of Colorado Boulder: sponsor guidelines | Requirements, design choices, implementation, verification, validation, and deployment | Connect engineering deliverables to inspectable evidence. |
| Harvard CS50 Web: final-project instructions | A distinctive web application, a complexity explanation, and substantial documentation | Follow the specific submission requirements if taking that course. |
These sources describe their respective courses and programs. Harvard CS50 Web’s final project is a particular course assignment, not a degree-wide Harvard computer science capstone standard. The other examples likewise should not be generalized to every U.S. institution.
ABET’s 2026–27 computing criteria include a major project integrating earlier knowledge and skills within the computer science program criteria. Accreditation requirements concern programs; they are not a universal scoring rubric for individual students.
The eight criteria for a good CS capstone
| Criterion | Key question | Evidence to inspect |
|---|---|---|
| 1. Rubric alignment | Does the project meet mandatory course requirements? | Requirements mapping and instructor guidance |
| 2. Problem clarity | What problem or research question matters? | Problem statement, supporting evidence, and success conditions |
| 3. Technical contribution | What computing challenge does the student address? | Algorithm, architecture, method, or meaningful technical comparison |
| 4. Feasibility | Can the essential work be completed and evaluated? | Bounded scope, resources, milestones, and fallback plan |
| 5. Design justification | Why are these methods appropriate? | Alternatives, assumptions, and decision records |
| 6. Evaluation | How will claims be tested, or what results support them? | Proposal: protocol; completion: executed results and limitations |
| 7. Reproducibility | Can another person inspect or repeat the work? | Documented environment, versioned materials, and review procedure |
| 8. Responsibility | Are permissions, attribution, and foreseeable risks addressed? | Policy checks, licenses, contribution records, and risk notes |
About this framework: These criteria are FileMakr’s editorial synthesis for student self-review. They are not an official or validated grading instrument and do not predict academic approval.
1. Map the project to the actual rubric
List mandatory outcomes and deliverables before assigning a score. A course may require algorithmic work, a sponsor, a technical report, a presentation, or a deployed system.
For each requirement, identify the proposed deliverable and the evidence that will demonstrate compliance. Record instructor feedback accurately; a promising proposal is not approved until approval has actually been granted.
Inspect: a course requirement → deliverable → evaluation evidence mapping.
2. Define and validate the problem
“Student planner” is a topic. “Detect invalid prerequisite sequences and generate feasible term schedules under specified course constraints” is a concrete computing problem.
For a user-facing project, support the problem statement with a documented stakeholder requirement, observation, or other relevant evidence. Define how you will assess usefulness. A technically correct feature may still fail to address the intended user’s need.
For research, identify the gap or uncertainty in existing work that makes the question worth investigating. A research project does not need a commercial customer, but it does need a justified question.
Inspect: problem statement, supporting evidence, intended users or research scope, inputs, outputs, and success conditions.
3. Specify the technical contribution
A contribution might involve graph algorithms, consistency guarantees, operating-system design, data analysis, or a controlled experimental comparison.
Using libraries is normal. Explain what you designed, implemented, evaluated, or learned beyond routine configuration. Technical depth should be judged against the course requirements.
Inspect: the technical claim, relevant alternatives, and a clear account of the student’s own work.
4. Bound the essential work
A minimum viable product, or MVP, is the smallest end-to-end implementation that addresses the central problem.
For research, define a minimum viable experiment: a narrow question, accessible data, a baseline, and a credible evaluation procedure.
Separate essential work from optional features. Include time for integration, documentation, accessibility, and evaluation. Check important dependencies early and identify a fallback if a critical assumption fails.
For detailed planning, use FileMakr's capstone scope guide.
Inspect: must-haves, exclusions, resource access, milestones, risks, and fallback options.
5. Justify engineering and research methods
Compare the proposal with a relevant existing tool, method, or published study. State what you will reuse, which limitation you will address, and what your contribution will be. For research, use this comparison to justify the question and baseline.
Explain why the selected algorithm, database design, architecture, or experimental method fits the constraints. Document plausible alternatives and the trade-offs behind your choice.
A diagram helps when it explains a decision or relationship.
Inspect: architecture or methodology, existing-work comparison, decision log, and unverified assumptions.
6. Evaluate results, including failure cases
An acceptance criterion is an observable condition defining whether a requirement passes.
A baseline is a reference method used for comparison, such as a straightforward algorithm or an existing process.
At proposal stage, specify cases, expected outcomes, metrics, and comparison conditions. At completion, record actual results, anomalies, and limitations. Do not report a planned test as a passed test.
A demonstration shows selected behavior. An evaluation tests a stated claim against defined conditions and preserves the outcomes—including unfavorable ones.
Inspect: planned evaluation procedures for a proposal; executed tests or experiments, version information, and actual-versus-expected outcomes for completed work.
7. Make independent review realistic
Reproducibility means another person can follow enough documented steps to inspect and, where appropriate, repeat the work.
At proposal stage, specify the intended environment, dependencies, commands, data or fixtures, versioning approach, and independent-review procedure. A completed setup trial is not necessary merely to document that plan, unless the course explicitly requires one.
During implementation, ask someone unfamiliar with the system to follow the permitted materials and instructions. Record missing dependencies, unclear steps, and setup failures.
Inspect: proposal—reproduction plan; completion—actual package, commands, permitted data, and review results.
8. Make ownership and limitations transparent
Use authorized data, protect credentials and personal information, and address foreseeable security and accessibility limitations. Document licenses, reused material, and AI assistance according to the course policy.
For group work, record responsibilities and support them with design notes, issue history, code reviews, tests, or other relevant artifacts. Commit counts alone do not establish contribution. Prepare the required report and demonstration so a reviewer can understand the problem, method, results, and limitations.
Inspect: permissions, attribution, policy checks, contribution records, disclosures, and risk notes.
What evidence should different CS capstones provide?
The evaluation should match the technical claim. A database system, research investigation, and optimization algorithm should not be assessed solely through the same screenshot checklist.
| Project type | Example evidence to plan and preserve |
|---|---|
| Web or database system | Functional and integration tests, authorization failures, integrity checks, and meaningful error cases |
| Machine learning | Valid data separation, leakage checks, held-out metrics, baseline results, and error analysis |
| Algorithms or optimization | Correctness on defined inputs, runtime or resource measurements, and comparison with an appropriate alternative |
| Data analysis | Source provenance, repeatable transformations, sensitivity checks, and interpretation limits |
| Security-focused application | Scoped threat model, authorized defensive tests, and unresolved risks |
| Accessibility-focused application | Relevant accessibility evaluations and documented task-completion observations |
| Hardware or embedded system | Repeatable physical measurements, test conditions, failure modes, and hardware constraints |
These are examples, not universal requirements.
Hypothetical research example: A student investigates whether a heuristic reduces timetable conflicts compared with a first-available-slot baseline. Both methods use the same synthetic inputs, constraints, objective, and measurement conditions. The plan includes cases where the heuristic offers no improvement.
For machine-learning studies, also prevent data leakage: evaluation information must not improperly influence model development.
From course requirement to evidence
Evidence chain: Start with a course requirement, explain the design decision it informs, choose an evaluation method, and preserve the resulting evidence.
For example, a requirement to reject invalid prerequisite ordering leads to an ordering check, a deliberately invalid schedule, and a recorded validation result. A reviewer should be able to follow the chain from requirement to conclusion.
CS capstone quality scorecard: Copyable worksheet
Choose one assessment stage:
- Proposal readiness: Judge the documented plan and prerequisites for undertaking it.
- Completed-project review: Judge the implemented work and evidence actually produced.
Use these scoring anchors:
| Score | Proposal-stage meaning | Completed-project meaning |
|---|---|---|
| 0 | The requirement, method, or essential supporting information is missing or unresolved | Required work or supporting evidence is absent |
| 1 | The plan has relevant detail but important gaps remain | Evidence exists but is incomplete or does not fully support the claim |
| 2 | Relevant plans and prerequisites are sufficiently documented for review | Inspectable evidence supports the criterion within stated limitations |
A proposal-stage 2 for reproducibility means the reproduction package and review procedure are specified. A completion-stage 2 requires the actual package and review evidence.
Permissions are not satisfied by a promise to check later. If required access, licensing, or course-policy compliance is unresolved, record that gap even when the rest of the proposal is detailed.
Copy and complete:
Project: ___
Stage: Proposal / Completed project
Course rubric and version: ___
Assessment date: ___| Criterion | Score: 0–2 | Evidence, gap, and next action |
|---|---|---|
| Rubric alignment | ___ | ___ |
| Problem clarity | ___ | ___ |
| Technical contribution | ___ | ___ |
| Feasibility | ___ | ___ |
| Design justification | ___ | ___ |
| Evaluation: planned or executed | ___ | ___ |
| Reproducibility | ___ | ___ |
| Responsibility and attribution | ___ | ___ |
| Total | ___ / 16 | Decision and review owner: ___ |
Interpret the finding, not just the total
| Finding | Meaning | Next action |
|---|---|---|
| Mandatory blocker | A required outcome, permission, resource, or permitted method is missing | Resolve it or agree on a revised project with the instructor |
| Evidence gap | A claim may be reasonable, but its plan, measurement, or documentation is incomplete | Identify the missing evidence and assign responsibility |
| Optional improvement | A refinement could help but does not establish a required outcome | Defer until the essential work and evaluation are credible |
A high total does not compensate for an unmet mandatory requirement. A project scoring 14/16 can still be unsuitable if it violates a course requirement.
There is no validated passing cutoff. Proposal and completion totals assess different stages and should not be treated as interchangeable.
Worked example: Evaluating a course-planning capstone
Hypothetical proposal: This fictional example illustrates an assessment method. It does not represent a completed student project or faculty approval.
A student proposes a tool that checks prerequisites and suggests term-by-term schedules using a fictional course catalog. It is an educational software project, not official academic advising.
A basic version lists courses and saves selections. A stronger proposal models prerequisites, validates ordering, and compares a scheduling method with a simple baseline under stated constraints.
| Basic application | Stronger technical proposal |
|---|---|
| Course list with a save button | Defined graph representation and prerequisite validation |
| Form accepts any course order | Checks that reject invalid sequences |
| Scheduler returns a list | Independent validation and baseline comparison |
| Demo uses one ordinary input | Boundary cases and known-infeasible inputs |
| Screenshot shows a schedule | Versioned inputs, outputs, methods, and test records |
Whether this meets the course standard still depends on the actual rubric.
Evaluation protocol and outcome definitions
Optional detailed example: This protocol illustrates one scheduling project. Use evidence appropriate to your own claim; a web application, hardware project, or research study may need a different evaluation design.
Define a fixed suite of 20 synthetic cases before testing. The number is illustrative, not a university requirement.
Specify the planning horizon, required courses, previously completed courses, offerings, and credit limits. Every output labeled valid must cover all required courses within the horizon and satisfy all modeled constraints.
Model scope: Every listed prerequisite must be completed in an earlier term. Alternative prerequisites, co-requisites, waivers, and minimum-grade rules are outside scope unless explicitly modeled. Apply the same interpretation in the scheduler and independent checker.
Use a separately implemented checker. Include:
- Known-feasible cases supported by a valid example schedule.
- Known-infeasible cases supported by a proof or exhaustive search within the finite model.
- Boundary cases involving unavailable courses, insufficient capacity, or prerequisite cycles.
A cycle in an unrelated part of the catalog does not automatically invalidate every schedule.
| Outcome | Meaning |
|---|---|
| Valid schedule found | The output passes the checker, including required-course coverage |
| Proven infeasible | Evidence establishes that no schedule satisfies the stated model and horizon |
| Unresolved search | The method stops without a validated schedule or proof of infeasibility, whether because of a resource limit or exhaustion of its incomplete search strategy |
| Invalid candidate | A returned schedule fails one or more checks |
| Input or model error | The input or model is malformed; report this separately from scheduling outcomes |
If a heuristic times out, report “no schedule found within the time limit.” That does not prove impossibility. Google OR-Tools documentation likewise distinguishes proven infeasibility from an unknown outcome.
Compare the proposed method with a specified baseline—for example, filling each term with eligible courses in course-ID order, subject to offerings and credit limits, without backtracking. Give both methods the same inputs, constraints, hardware, and per-case time limit.
Record the following measures:
- Feasible-case success rate: For one run on each case, divide the number of known-feasible cases producing a checker-validated schedule by the total number of known-feasible cases attempted. Include timeouts and unsuccessful runs in the denominator. Exclude known-infeasible and unknown-ground-truth cases. Report the numerator and denominator; if there are no known-feasible cases, report “not applicable.”
- Constraint violations: Record prerequisite, offering, credit-limit, and missing-course violations separately for each returned candidate. If no candidate is returned, record violation counts as “not applicable,” not zero.
- Runtime and termination: Preserve elapsed time and termination reason for every attempt. State whether timing includes validation. Do not summarize successful runs alone.
- Known-infeasible outcomes: Separate proven infeasibility, unresolved search, and invalid outputs. A heuristic need not prove infeasibility unless that is part of its claim.
- Randomized behavior: Predeclare the seeds and repetitions, and run every known-feasible case once for each seed. Calculate the feasible-case success rate separately for each seed using the same case set, then report the mean and range across seeds. Retain every run and report runtime variation separately. Do not count a case as successful merely because one selected seed worked.
For randomized comparisons, use the same number of runs and the same per-run budget for both methods. If you also report whether a case succeeded at least once across several runs, label that as a separate measure and disclose the total search budget.
A valid schedule is not necessarily optimal. Claims about shortest completion time or another objective require a separate objective definition and evaluation.
A small inspectable fixture
Assume two required courses, A and B, worth three credits each. No courses have already been completed. Each course must be assigned to one of two terms. B requires A in an earlier term.
Set the maximum load to six credits per term, so capacity does not independently prevent both courses from being placed in Term 1.
| Fixture | Offerings | Expected outcome and reason |
|---|---|---|
| Feasible | A: Term 1 only; B: Term 2 only | A in Term 1 and B in Term 2 satisfies all constraints. |
| Infeasible | A: Term 1 only; B: Term 1 only | A must be completed before B. Both courses are offered only in Term 1, so no assignment satisfies the prerequisite rule. |
Before applying the constraints, assigning each of the two courses to one of two terms gives four combinations to check. The feasible fixture has one valid assignment; the infeasible fixture has none.
These fixtures illustrate expected outcomes. They do not establish that a scheduler implementation works.
Worked scoring example: 12/16 for a hypothetical proposal
Assume a fictional software-engineering rubric and a documented mapping between its requirements and the proposed work.
| Criterion | Score | Illustrative evidence and remaining action |
|---|---|---|
| Rubric alignment | 2 | The fictional rubric is mapped to proposed deliverables. A real student must use the actual course rubric. |
| Problem clarity | 2 | Invalid prerequisite ordering is defined, with an assumed documented stakeholder requirement and success conditions. |
| Technical contribution | 2 | Graph validation and the scheduling comparison are specified at proposal level. |
| Feasibility | 1 | Synthetic data is available, but workload and resource assumptions need a documented feasibility check. |
| Design justification | 1 | A graph representation is proposed, but alternatives and trade-offs remain incomplete. |
| Evaluation plan | 1 | Acceptance targets and comparison rules exist, but the full case matrix and expected-results register are unfinished. |
| Reproducibility | 1 | A README and data generator are identified, but environment, commands, fixture versions, and independent-review procedure are not fully specified. |
| Responsible ownership | 2 | Assume the proposal documents permitted synthetic data, compatible licenses for planned reuse, the applicable course AI policy, and attribution responsibilities. |
| Total | 12/16 | Planning illustration, not a faculty grade |
For responsibility, recheck permissions and disclosures if implementation choices change. If the assumed checks have not actually been completed in a real proposal, award a lower score and record the unresolved requirement.
If the proposal documented a feasibility check (+1), completed its evaluation plan (+1), and fully specified its reproduction package and independent-review procedure (+1), its proposal-readiness score would rise from 12/16 to 15/16.
Design justification would remain incomplete. At completion, reassess reproducibility using the actual package and review results.
Requirement-to-proof matrix
| Requirement or claim | Evaluation method | Evidence to retain |
|---|---|---|
| Detect prerequisite cycles | Supply a graph with a known cycle | Fixture, version, expected and actual detection |
| Respect prerequisite ordering | Supply an invalid course sequence | Input, validation output, and failure details |
| Honor offerings, credits, and coverage | Check every returned candidate independently | Constraint definitions, candidate, and checker log |
| Explain algorithmic value | Compare both methods under the same conditions | Per-case and per-seed outcomes, runtime, rates, and limitations |
| Support independent review | Have an unfamiliar reviewer follow the package instructions | Setup report and corrections |
Completed-project results record: Blank template
<p>Create one record for each method, case, and run. Enter actual outcomes only after execution.</p>
Use these records to reassess the completed project. Planned evaluation points must not be carried forward as if tests had passed.
How to strengthen a proposed capstone in five steps
- Check eligibility. Map course requirements, permissions, and mandatory blockers.
- Write the technical claim. State what the project will build, test, or investigate and why it matters.
- Check feasibility early. Confirm resources and address the highest-risk assumption.
- Design the evaluation. Specify acceptance criteria, baseline, cases, metrics, and evidence records.
- Request instructor review. Bring the worksheet and unresolved findings. Record whether the proposal is approved, needs revision, or remains undecided.
For formal submission structure, use FileMakr's capstone project proposal guide.
Common mistakes that reduce capstone quality
| Mistake | Why it matters | Better response |
|---|---|---|
| Treating an attractive interface as proof of value | The intended problem may remain unsupported | Document the need and evaluate usefulness |
| Reporting a planned test as passed | Confuses intention with evidence | Separate expected and actual outcomes |
| Selecting metrics after seeing results | Encourages selective reporting | Define metrics and comparison rules first |
| Ignoring baseline failures | A favorable average can hide weaknesses | Report failure cases and limitations |
| Treating search failure as impossibility | An incomplete method may miss a valid solution | Distinguish unresolved from proven infeasible |
| Reporting only the best random seed | Conceals variability and unsuccessful runs | Preserve all runs and report the defined aggregate |
| Leaving permissions undocumented | Can block otherwise sound work | Verify access, licenses, and policy compliance |
| Testing only on the developer’s setup | Hides dependencies and unclear instructions | Conduct independent reproduction |
| Treating the worksheet as approval | Self-review cannot replace an instructor’s decision | Apply the actual rubric and record feedback |
Frequently asked questions
Does a CS capstone have to be completely original?
No universal rule requires an unprecedented product. Originality depends on the course requirements and may come from an implementation, algorithmic contribution, experimental design, or justified improvement. Attribute reused material honestly.
Is a CRUD web application enough for a capstone?
It depends on your course rubric. CRUD means create, read, update, and delete—the basic operations used to manage stored records.
Some courses emphasize complete, tested systems. GWU’s 2026–27 criteria require both algorithmic and technical components and do not accept a database website alone as the core contribution.
Do I need AI or machine learning?
No. Systems, algorithms, accessibility, database, and software-engineering projects may provide appropriate depth without machine learning.
If ML fits the problem, justify its use and choose a valid baseline and evaluation procedure. The presence of a model is not proof of technical quality.
How is a research-based capstone different from a software-product capstone?
A research project centers on a focused question, method, comparison, and evidence-supported conclusions. A software-product project centers on an implemented system, requirements, and verified behavior.
Both need transparent evidence. Some programs, including NAU’s sponsored software capstone, specifically expect a defined software product rather than open-ended research assistance.
What evidence should I show a professor?
Present the rubric mapping, supported problem statement, contribution explanation, design or research method, scope, resource checks, evaluation plan, and known limitations.
After implementation, include executed results, the final package, and evidence of individual contributions where relevant.
How do I know whether my idea is ready for approval?
Resolve mandatory blockers and document a plausible contribution, feasible scope, and evaluation plan. Then request instructor review.
A strong self-assessment means you are prepared for that discussion; it does not guarantee approval.
How much testing does a good capstone require?
Enough to support the important claims under relevant conditions. Use requirements-based coverage, appropriate comparisons, and meaningful failure cases.
A large test count alone does not establish correctness, generalizability, security, or usefulness.
Can I use ChatGPT or other AI tools in a CS capstone?
Only within the policy governing your submission.
For example, Harvard CS50 Web’s final-project guidance permits generative AI assistance for the README and only the README. That restriction is course-specific. Check your own current rules for code, writing, disclosure, and attribution.
Can a failed experiment still support a strong capstone?
Potentially. A research project can produce useful work when its hypothesis is not supported, provided the method is sound, the results are reported honestly, and the conclusions match the evidence.
An unmet mandatory deliverable is a different issue. Check how your course evaluates negative results and incomplete implementation.
Conclusion: Assess the proof, not just the promise
A strong computer science capstone connects a supported problem to an appropriate technical contribution and credible evidence within the course rules.
Complete the worksheet for your current stage. Resolve mandatory blockers first, close evidence gaps next, and defer optional refinements until the essential work is supported.
Next step: Take your most important unresolved requirement and supporting evidence to your instructor.
If you still need a topic, explore FileMakr's computer science capstone project ideas. If your concern is challenge versus available capacity, read how difficult a capstone should be.
