Capstone Project Options¶

Ten substantial projects. This page is how to choose one; each project has its own full specification.

This is the final tier of the project roadmap: the three tiers below it — mini, intermediate and advanced — prepare you for it, and the capstone assumes you can already make design decisions unaided.

No complete solutions are provided for any of these. That is deliberate: the capstone exists to practise independent problem solving, and a solution would replace the work with reading. The running library system you built across the sixteen labs is the worked example — if you are unsure how a capstone is structured, look there, then build something that is not it.

How to use this page¶

Choose one project, not several. Each is sized as a term's work.
Read its specification completely before writing code.
Design first. A UML class diagram with responsibilities and ownership marked, which the specification's milestones treat as the first deliverable.
Build the smallest thing that runs, then extend it in milestones.
Keep the rubric open — it is the acceptance criteria, and it is the same rubric a marker would apply.

Every specification follows one structure: the problem, the actors, the use cases, suggested classes and relationships, design constraints, milestones, minimum and advanced requirements, testing requirements, extension ideas, and an evaluation checklist.

The ten projects¶

#	Project	Core difficulty	Patterns it earns	Persistence
1	Library Management System	Loans, reservations and fines interacting over time	Strategy, observer	Books, members, loans, fines
2	Hospital Management System	Scheduling with real constraints, and records that must not lose history	Strategy, template method	Patients, appointments, records
3	University Management System	Enrolment rules, prerequisites, and many kinds of person	Strategy, factory, observer	Students, courses, enrolments
4	Banking System	Money, transactions, and an audit trail that must never be half-written	Command, strategy, factory	Accounts, transactions
5	E-Commerce System	Carts, orders and pricing rules that compose	Strategy, decorator, observer	Products, orders, customers
6	Hotel Reservation System	Date ranges that must not overlap, and cancellations	Strategy, observer	Rooms, reservations, guests
7	Vehicle Rental System	Per-day, per-km and per-category pricing over a fleet	Strategy, factory, decorator	Vehicles, rentals, customers
8	Inventory Management System	Stock levels that must stay non-negative under concurrency of operations	Observer, strategy	Items, suppliers, movements
9	Restaurant Management System	Orders moving through states, and a menu that changes	State, command, observer	Menu, orders, tables
10	Learning Management System	Assessment, grading rules and progress over a term	Strategy, observer, factory	Courses, students, submissions

How to choose¶

Choose by the difficulty you want to practise. Every project requires encapsulation, ownership, polymorphism, exception safety, persistence, patterns and tests — the difference is which of those is hard in that domain:

If you want to practise	Choose
Time, ranges and overlapping rules	Hotel Reservation, Library
Money, and a record of every change	Banking, E-Commerce
Many kinds of person or thing, with shared behaviour	University, Hospital, Vehicle Rental
State machines and transitions	Restaurant, Hospital
Quantities and invariants under many operations	Inventory, Banking
Rules that vary by configuration	E-Commerce, Learning Management, Vehicle Rental

Do not choose the library system if you built it across the labs — you would be extending work whose design decisions are already made for you. The point of the capstone is to make those decisions yourself.

The domain does not matter as much as the constraints do. Every specification below requires the same things: a documented format, a multi-file layout, tests, patterns justified by requirements, and a design report with one decision you would reverse. A supermarket system built to those constraints teaches more than a bank built to none.

The project template, and where each part lives¶

Every project in this section is described with the same seventeen elements, listed on the projects overview. These ten specifications were written before that template and are richer than it, so the content lives under different headings. This table is the map, so nothing has to be taken on trust:

#	Template element	Where the capstone specification states it
1	Title	The page title, e.g. Capstone 1 — Library Management System
2	Difficulty	The header block (`Scope: a term's work`) and the rubric; the capstone tier sits at Expert design freedom
3	Estimated effort	The header block: a term's work
4	Scenario	§1 Problem statement
5	Problem statement	§1 Problem statement
6	User requirements	§2 Actors — what each one needs from the system — and §3 Use cases
7	Functional requirements	§3 Use cases and §8 Minimum requirements
8	Non-functional requirements	§6 Design constraints (money representation, injected time, file format, warnings)
9	Suggested features	§11 Extension ideas
10	OOP concepts involved	§4 Suggested classes and §5 Relationships
11	Suggested design considerations	§4, §5 and §6 together — the class table and the relationship diagram both name what each choice is for
12	Minimum viable version	§8 Minimum requirements
13	Intermediate extension	§7 Milestones (the later ones) and the first half of §9 Advanced requirements
14	Advanced extension	§9 Advanced requirements
15	Testing checklist	§10 Testing requirements
16	Documentation checklist	§7 Milestones (the design report and diagram) and the What every project requires list below
17	Self-evaluation rubric	§12 Evaluation checklist, plus the weighted rubric

If you have already worked through an intermediate or advanced project, the shape will be familiar: the same seventeen elements, with more of them stated by requirement rather than by suggestion.

What every project requires¶

Stated once rather than ten times, and identical in every specification:

A multi-file layout with a documented build command, public headers that depend on nothing internal, and internal helpers that stay internal.
Persistence with a documented text format, a version marker, an escape rule for the field separator, and a save → load round trip that preserves every field including an empty collection.
Robust loading: missing, empty, truncated and hand-edited files each rejected with a message containing a line number, leaving the in-memory state untouched.
Failure handling designed rather than improvised: invalid operations rejected, and the rejection paths tested.
At least two design patterns, each with a written justification naming the requirement that earned it — and one documented pattern considered and declined, with the reason.
A test suite covering invariants, boundaries and failure paths, with assertions (not printouts) and one deliberate bug introduced to prove the suite notices.
A UML class diagram matching the code, with multiplicities and ownership marked.
A design report naming the decisions, the costs accepted, the alternatives rejected, and one decision you would reverse, with the cost of reversing it.
No warnings with g++ -std=c++17 -Wall -Wextra -Werror.