Capella CS FlexPath Capstone Guide

The CS capstone typically asks students to design, build, and document a complete software system: a full application, a service with a defined API, or a substantial extension of an existing codebase. The trap most students fall into is treating the code as the deliverable and the documentation as an afterthought. In FlexPath, the reverse is closer to the truth. Your evaluator scores what you can demonstrate against written criteria, and code that works but is poorly explained routinely scores below code that is modest but thoroughly documented, justified, and tested.

What the CS capstone actually requires

While requirements vary by course version, most CS capstone projects share a consistent shape: a project proposal defining scope and requirements, a design document covering architecture and key technical decisions, the implemented software itself, a testing and validation section with real evidence, and a final report that ties the finished system back to the original requirements. Each of these maps to specific scoring-guide criteria, which means each one needs deliberate attention rather than being produced as a byproduct of writing code.

Notice that only one of the five rows is the code. That ratio is a fair reflection of how scoring weight tends to be distributed. A capstone evaluator is not going to run your test suite line by line; they are going to read your documentation and judge whether it demonstrates each competency the scoring guide names.

Choosing a project scope you can finish and document

Scope selection decides more capstone outcomes than technical skill does. Strong CS capstone projects tend to be systems with three to five core features, a clear user or consumer, and at least one genuinely non-trivial technical decision to justify: a scheduling application with conflict detection, an inventory API with role-based access control, a data pipeline with validation and error recovery. Projects that are too ambitious (a full social platform, a game engine) run out of time before the documentation phase, and projects that are too thin (a single CRUD form) leave nothing substantial to analyze in the design and testing sections. The general principles in our capstone topic selection guide apply directly here, with one CS-specific addition: pick a project where the interesting decisions are architectural, because architecture is what the scoring guide rewards you for explaining.

Documenting architecture decisions to scoring-guide standard

The design document is usually the highest-leverage deliverable in the entire capstone, and the difference between an adequate one and an excellent one comes down to a single habit: recording decisions, not just descriptions. A description says "the system uses PostgreSQL and a REST API built with Express." A decision record says what problem the choice solves, what alternatives were considered, and why the chosen option won for this specific project.

A practical format is a short architecture decision record for each major choice, three to six of them across the project. Each record covers four things in a few paragraphs: the context (what the system needed), the options considered (two or three realistic alternatives), the decision and its rationale (tied to your stated requirements, not to personal preference), and the consequences (what the choice makes easier, and what trade-off you accepted). Writing "I chose PostgreSQL over MongoDB because the inventory data is relational, requires transactional consistency for stock adjustments, and benefits from foreign-key enforcement between orders and items; the trade-off is a more rigid schema during early iteration" demonstrates the evaluation-of-alternatives competency in one sentence. Writing "I used PostgreSQL because it is popular and reliable" demonstrates nothing, and this exact pattern, a technology named without a requirements-linked reason, is one of the most common weaknesses evaluators flag in CS capstone design documents.

The same principle applies at smaller scales. Why a layered structure rather than putting logic in route handlers. Why JWT sessions rather than server-side sessions. Why input validation lives at the API boundary. You do not need to justify everything, but the scoring guide language around "analyzes," "evaluates," and "justifies" is telling you precisely what the evaluator is instructed to look for, and unjustified choices read as unexamined ones.

Documenting the code itself: what evaluators can actually assess

Evaluators review code the way a busy technical lead reviews a pull request: structure first, details second. That means the highest-value code documentation is the material that makes the codebase navigable in ten minutes. A README that explains how to install, configure, and run the system, including environment variables and seed data. A short map of the repository layout: what lives in each directory and why. Comments that explain intent at the tricky points, the concurrency guard, the retry logic, the non-obvious validation rule, rather than restating what each line does. Consistent naming that matches the vocabulary of your design document, so a component called the "reservation service" in the architecture diagram is actually named that in the code.

One habit pays off more than any other: keep the design document and the code in vocabulary lockstep. When an evaluator can open your architecture diagram, pick a box, and find a folder or module with the same name doing the same job, the claim that you built what you designed becomes verifiable in seconds. When the diagram says "notification engine" and the code has a file called misc-utils doing that work, the evaluator has to take your word for it, and scoring guides do not reward taken words.

Testing and validation: evidence, not assertion

The testing section is where the largest scoring gap between otherwise similar capstones tends to appear. Weak submissions assert that testing happened: "the application was tested thoroughly and all features work as expected." Strong submissions show evidence: a test plan that maps each functional requirement to at least one specific test, actual results (a test-runner summary, a table of manual test cases with pass/fail outcomes, screenshots of edge-case behavior), and an honest account of coverage limits.

A workable structure for the testing section has four parts. First, the strategy: what levels of testing you used (unit tests for business logic, integration tests for API endpoints, manual scenario testing for the UI) and why that mix fits the project. Second, the requirement-to-test traceability table: every requirement from your proposal, the test that validates it, and the result. Third, defect handling: two or three bugs you actually found during testing, what caused them, and how you fixed them. Far from weakening the submission, documented defects strengthen it, because finding and resolving faults is itself a named competency in most versions of the scoring guide. Fourth, known limitations: what you did not test, and what a production team would need to add. Stating plainly that "load testing was out of scope; the system was validated for correctness, not for concurrent load beyond ten simultaneous users" reads as engineering judgment. Silence on the same point reads as an oversight.

Mapping deliverables to the scoring guide, criterion by criterion

FlexPath evaluation is criterion-referenced: each scoring-guide criterion is judged independently, and a submission that is brilliant on four criteria and silent on a fifth gets returned on the fifth. The mechanics are covered in our guide to how FlexPath competency scoring works, and they matter doubly in the capstone because the deliverable is large enough that a criterion can get lost.

The reliable countermeasure is a traceability pass before submission. Take the scoring guide, and for each criterion write down exactly where in your submission it is addressed: section number, page, or heading. If a criterion says "evaluates the security implications of the design," you should be able to point at a specific subsection where security is analyzed, threats are named, and mitigations are tied to the implementation. If your pass turns up a criterion with no clear home, that is a returned-assessment risk you can fix in an evening; discovered after submission, the same gap costs a full revision cycle. The most common return reasons across FlexPath assessments follow this exact pattern, and our assessment return reasons guide covers the broader list.

A worked example: weak versus strong technical documentation

Consider a capstone building a clinic appointment scheduling system. A weak design section reads: "The system uses a three-tier architecture with a React frontend, Node.js backend, and MySQL database. This is a standard, industry-proven design. The backend exposes REST endpoints for appointments, patients, and providers." Every sentence is true, and none of it demonstrates analysis. It describes what exists without ever engaging with why, what else was possible, or what requirement drove the choice.

A strong version of the same section anchors each choice to a requirement and a rejected alternative: "Appointment booking must prevent double-booking of a provider slot under concurrent requests (requirement F-4). Two approaches were considered: optimistic checking in application code, and a database-level unique constraint on (provider_id, slot_start). The application-level check alone was rejected because two simultaneous requests can both pass the check before either writes. The implemented design uses the unique constraint as the source of truth and treats the constraint violation as the signal to return a 409 conflict, which pushes correctness to the layer that can actually guarantee it. The trade-off is that slot granularity is fixed at the schema level, which limits variable-length appointments; this is acceptable for the stated scope of 30-minute slots." Same project, same stack, but this version demonstrates requirement traceability, evaluation of alternatives, understanding of failure modes, and honest trade-off analysis in one paragraph. That density of demonstrated reasoning is what separates the top scoring band from a merely competent submission.

Common CS capstone mistakes

• Coding first, documenting last. Leaving the design document and test plan until after the build means reverse-engineering rationale you no longer remember, and it shows. Write the decision records as you make the decisions.
• Scope creep mid-project. Adding features that were never in the requirements dilutes the traceability story and eats the time the documentation needs. New ideas belong in the "future work" section, not in the codebase.
• Tutorial-shaped projects. A project that follows a published tutorial architecture leaves no decisions to justify and invites originality questions. Evaluators have seen every popular tutorial's todo app and e-commerce clone.
• Asserted rather than evidenced testing. "All features were tested and work correctly" without a traceability table, results, or named defects is the single most common weakness in returned CS capstones.
• Diagrams that do not match the code. An architecture diagram drawn at proposal time and never updated to reflect the built system undermines everything else, because it is the easiest inconsistency for an evaluator to spot.
• Ignoring non-functional requirements. Security, error handling, and data validation criteria appear in most CS capstone scoring guides, and a submission that only discusses features leaves those criteria unaddressed.

A practical capstone timeline

The capstone rewards front-loaded planning more than any other course in the program. A realistic split for a ten-week pace looks like this, and the pacing habits from our FlexPath time management guide apply throughout:

The most important line in that table is the last one: verifying the setup instructions on a clean environment. An evaluator who cannot run your project falls back entirely on your written evidence, so the README needs to work for someone who was not present for the build.

Before you submit: a final review pass

Read the final report the way the evaluator will: without the code open, in one sitting, scoring guide beside it. Check that every requirement from the proposal appears in the traceability table. Check that every major technology named in the report has a recorded reason. Check that the testing section contains at least one artifact of real evidence per requirement category. Then do one pass purely for consistency: component names identical across diagram, report, and code; version numbers matching; screenshots current. Inconsistencies between artifacts are cheap to fix and disproportionately damaging to leave in, because they suggest the documentation describes an imagined system rather than the one you built.

Related guides