Appendix E — Glossary

“Let what you say be simply ‘Yes’ or ‘No’; anything more than this comes from evil.” — Matthew 5:37 (ESV)

Every profession has a vocabulary, and the vocabulary is not decoration. It is compression. When a project manager says “that’s a change request, not a defect,” she has just settled who pays for it, which document it touches, and what happens next — in six words. When a senior engineer says “your bus factor is one,” he has diagnosed the thing your handoff guide exists to fix. You are about to walk into rooms where people speak this way, and the ones who cannot keep up spend the meeting nodding.

In eight weeks that compression stops being a nicety and becomes a schedule item. You have 160 hours. You cannot afford a Week-4 review in which you and your reviewer spend twenty minutes discovering you meant different things by “done.” So learn these the way you learn any rep: not by reading them once, but by using them correctly until using them wrongly feels bad.

Two warnings before you start. First, usage varies between organizations and between traditions — a shop that runs Scrum uses “iteration” a little differently from a shop that runs a formal life cycle. Where that happens, this glossary gives you the sense this course grades, and tells you where the confusion usually lives. Second, several of these words are more often misused than used. For those you will find a sentence saying what the term does not mean. Read those sentences twice. Half of professional communication failure is two people using the same word for different things and neither of them checking.

How to read an entry. The bold word is the term. The italic tag names the week that teaches it in depth — click through if the definition raises a question. Then the definition in the sense a practitioner means it, followed where useful by a See also line pointing at the terms it lives next to. Repository filenames appear in code font; those are the real names of the real files in your submission.

The six terms this edition adds

The sixteen-week edition and this one grade the same artifacts to the same standard. What is different is that you do not shop for an idea, so six pieces of vocabulary exist here that do not exist there. They are the accelerated skill, named: Fast-Start brief, inherited requirement, adaptation pass, adopt-or-deviate, the two-thirds rule, and the halfway audit. If you learn six terms on this page, learn those six. Four of them describe how you take somebody else’s work and make it honestly yours; two of them are the arithmetic that keeps you from attempting a full-length project in half the calendar.

Scripture puts the point plainly enough. Christ’s instruction in Matthew 5:37 is about integrity of speech: say the thing, mean the thing, and let the word carry exactly what it claims. Paul makes the engineering version of the argument in 1 Corinthians 14 — words nobody can interpret leave you “speaking into the air” (ESV). A requirement nobody can verify, a specification nobody can build from, a README nobody can follow: all of it is speaking into the air. And in this edition there is a second edge on it, because many of the sentences in your documents started life in somebody else’s brief. A word you inherited is still a word you are answering for. Precise language is not pedantry. It is how you love the neighbor who has to read what you wrote after you have graduated and gone.

A

Acceptance criteria · Week 2 — The specific, checkable conditions that decide whether a requirement has been met, written so that someone who did not build the thing can run them and get an unambiguous yes or no. Good criteria name the starting state, the action, and the observable result: “the user can log in” is not acceptance criteria; “given a registered account, submitting the correct email and password returns the dashboard in under two seconds” is. They are not test cases — criteria say what “done” means, test cases say how you will prove it, and in Week 6 you map one to the other. Every criterion you inherit from a Fast-Start brief must be re-checked against data your project actually has. See also Definition of done, Test case, Inherited requirement.

Acceptance testing · Week 6 — Testing that answers the customer’s question — does this system do what the requirements say — rather than the developer’s question of whether the code behaves as written. You are your own customer here, so acceptance tests run directly against the acceptance criteria in docs/requirements.md, one test per criterion, with results recorded in docs/test-results.md. It is a level of testing, not a phase you bolt on at the end, and it does not mean clicking around the app the night before the presentation.

Accessibility · Week 2 — Designing and building so that people with disabilities can actually use your software: keyboard operation, sufficient contrast, text alternatives, labeled controls, sane semantic structure. In this course it is a non-functional requirement with a measurable target written in Week 2, not a panic sweep in Week 7 — the W3C’s Web Accessibility Initiative (https://www.w3.org/WAI/) is the standard starting point. It is not exclusively a web concern and not a legal box to tick; it is the requirement whose beneficiary you will never meet. Budget the pass in docs/plan.md in Week 3 or it will not happen.

Adaptation pass · Week 2 — This edition’s name for the single sitting, roughly three hours, in which you go through every requirement you inherited from a Fast-Start brief and assign it one of four verdicts in writing, with a reason: keep, adapt, split, or withdraw. It is the accelerated skill in its purest form, and it is the reason this course can reach a written specification in 40 hours where the long edition takes 60. It is not proofreading and not a tidying exercise — a pass that returns “keep” on every line has not been run, it has been skipped politely. Do it on Monday of Week 2, before you write acceptance criteria for requirements you are about to withdraw. See also Inherited requirement, Fast-Start brief, Requirement identifier.

Adopt-or-deviate · Week 3 — The two-hour discipline for handling the technology stack a Fast-Start brief suggests: run a drivers pass over the requirements that would actually change your choice, diff the brief’s suggested pieces against the scope you ended Week 2 with, count your novelty load, check the seams — then either adopt the suggestion or deviate from it, and record whichever you chose in docs/adr/0001-choose-the-stack.md with the alternatives and the cost you accepted. The phrase applies to more than the stack: the brief’s non-goals, its hard part, and its cut list are all recommendations to adopt or deviate from. It does not mean the brief is optional and it does not mean the brief is binding — the failure is not deviating, it is deviating (or adopting) by default, with no record of the decision. A container you keep because the brief drew it is a container you must build, run, debug, document, deploy, and demo. See also Architecture decision record, Novelty load, Fast-Start brief.

AI-usage log · Week 5; policy declared Week 1 — The record kept in docs/ai-usage.md of where an assistant contributed to your project: what you asked for, what it produced, what you changed, and how you verified it. The book also calls it the disclosure log. It is a required artifact in the final package, and it protects you — a documented, reviewed, tested contribution is engineering; an undocumented one looks like something else entirely when a committee asks what you wrote. It is not a confession and carries no penalty: students who use AI heavily and log honestly score better than students who use it lightly and hide it. Log by task, not by keystroke. See also Hallucination, Prompt contract, Appendix C.

Architecture decision record (ADR) · Week 3 — A short, numbered, immutable document capturing one significant decision: its context, the options considered, the decision, its status, and the consequences you accepted. They live in docs/adr/ as 0001-choose-the-stack.md, 0002-…, and you supersede them rather than editing them, so the reasoning stays readable in the order it happened. The lightweight Context / Decision / Status / Consequences format most teams use was popularized by Michael Nygard. An ADR is not documentation of what you built — it is the record of why, written for the person who inherits the choice and is about to reverse it without knowing what it cost. In this edition your first one almost always records an adopt-or-deviate call. See also Adopt-or-deviate, Appendix C.

Assumption · Week 2 — Something you are treating as true without proof because the project cannot move until you decide — “every user has a smartphone camera,” “the department will let me deploy on their network.” Write assumptions down with identifiers, the same way you number requirements, because an assumption is a risk with a friendlier name: if it turns out false, something in your plan breaks. Keep it distinct from a constraint (imposed on you) and a dependency (outside your control but needed). Re-read the list at the Week-4 design review; that is the last point at which the false ones are still cheap. See also Constraint, Dependency, Risk register.

B

Backlog · board stood up Week 1, worked hardest Week 6 — The ordered list of work not yet done: tasks derived from your work breakdown structure, defects from docs/defect-log.md, and approved change requests. Ordered is the whole point — a backlog where everything is “high priority” is a to-do list wearing a suit. It is not a schedule: the schedule says when, the backlog says next. Every item on it should carry the requirement identifier it serves, and what remains on it in Week 7 becomes the “what I would do next” section of docs/handoff.md.

Baseline · Week 4 — A version of an artifact that has been reviewed, approved, and frozen, after which it changes only through change control. Week 4 baselines docs/requirements.md and docs/architecture.md; from that moment those documents are the standard your build is measured against. A baseline is not permanent and does not claim the design was right — it means changes from here on are deliberate, recorded, and impact-assessed. Without one you cannot tell scope creep from progress, because there is nothing to creep away from. See also Change control, Change request, Design review.

Branching strategy · conventions set Week 1, enforced from Week 3 — The written rule for how work moves into your main line: which branches exist, what must pass before a merge, and what main is guaranteed to be at all times. This course recommends a branch per requirement — fr-014-expiry-warning — off a main that continuous integration must keep green. This is not ceremony. It is what makes “main always runs” true, and “main always runs” is what the clean-machine test in Week 7 depends on. You do not need to review your own pull request and this book will not pretend you do.

Bug — See Defect. This course prefers “defect” for the written record and reserves “bug” for conversation. The distinction matters in exactly one place: a defect report is a document with an identifier, reproduction steps, severity, and disposition, whereas “there’s a bug in the parser” is a sentence that helps nobody in three weeks.

Burn-down · Week 5 — A chart of remaining work against time, so that a schedule slip appears as a line that stops falling instead of a feeling you talk yourself out of. Plot estimated hours remaining rather than tasks completed; completed-task charts flatter you, because the hard tasks are always the ones left. It is not a progress bar and not a report for somebody else — it is your early-warning instrument, and in an eight-week course it has only four data points before it stops being able to warn you about anything. Update it in the weeks when the news is bad, which are the only weeks it matters. See also Hours log, Velocity, Halfway audit.

Bus factor · Week 7 — The number of people who would have to vanish before the project could no longer continue — the grim old “hit by a bus” count. Your capstone begins at a bus factor of one, which is the entire reason Week 7 exists: docs/handoff.md, docs/runbook.md, and the decision records in docs/adr/ are the instruments that raise it. Higher is better; a bus factor of one is the risk, not the achievement. Ask the honest question that week: what do you know about this system that exists nowhere except inside your head? See also Handoff guide, Onboarding guide, Runbook.

C

Change control · Week 4 — The lightweight process by which a baselined artifact is permitted to change: a written request, an impact analysis, a decision, and an entry in the change log. In a company it is a board of people; solo, it is you in writing, on a different day than the idea occurred to you. Change control does not mean “no changes” — it means no invisible changes. Accelerated projects rarely die of change; they die of unrecorded change, and four weeks is not long enough to reconstruct what happened. See also Change request, Baseline, Impact analysis.

Change log · Week 6 — A human-readable CHANGELOG.md listing what changed in each version, grouped by release, written for a reader rather than generated from commit subjects. It also carries the change table at the top that indexes every file in docs/change-requests/, and a Known issues section that had better not be empty. A grader in Week 8 opens it to see whether the project moved deliberately or thrashed. It is not your git history: history is the evidence, the change log is the story a person can follow in two minutes.

Change request (CR) · process starts Week 4, used hardest Week 6 — A written proposal to alter something already baselined — a requirement, an interface, a scope line — carrying the reason, the impact on schedule and on other requirements, and the resulting decision. One file per request in docs/change-requests/, named CR-nnn-*.md, three honest lines of impact analysis being enough at this scale. A change request is not a defect report: a defect says the system fails to do what the specification promised, a change request says the specification should promise something different. Confusing the two is how students end up “fixing” behavior that was never specified. In this edition your first CR is very often the withdrawal of an inherited requirement.

Charter (project charter) · Week 1 — The one-page statement, kept at docs/charter.md, of what the project is, who it serves, what is in and out of scope, what success looks like, and what constraints apply. It is signed by the end of Week 1, and it is the thing you re-read whenever a shiny idea arrives in Week 5 wearing the costume of an obvious improvement. A charter is not a requirements document — it is what your requirements must stay consistent with, and the thing you point at when you say no. If a noun appears in your requirements and nowhere in your charter, one of the two documents is describing somebody else’s project. See also Scoping decision, Inherited requirement.

Clean-machine test · Week 7, repeated Week 8 — The acceptance test for your documentation: on a machine that has never seen this project, following only README.md, can a stranger clone, install, configure, run, and test it? A fresh container, a borrowed laptop, or a brand-new cloud development environment all count, and the run is written up in docs/clean-machine-test.md. Deleting your dependency directory does not count — your machine still holds the toolchain, the environment variables, the shell history, and the knowledge in your head, which are precisely the things the test exposes. Passing it once is the requirement; failing it in Week 8 is the most common avoidable loss on the whole rubric. See also README, Runbook, Configuration.

Configuration · Week 7 — Everything that varies between environments — ports, URLs, credentials, feature flags, data paths — kept out of source code and supplied by the environment, with a committed .env.example that lists every key the code reads and no real values. The test is simple: if a value differs between your laptop and the deployed instance, it is configuration, and hard-coding it is the single most common technical cause of “well, it runs on my machine.” Required values should have no defaults, so the application fails loudly at startup naming the variable it wants. See also Secret, Deployment, Clean-machine test.

Constraint · Week 2 — A limitation imposed on the project that you did not choose and cannot trade away: a required platform, an institutional hosting policy, a hard deadline, a laptop with no administrator rights. Constraints bound the solution space before design starts, which is exactly why they belong in docs/requirements.md rather than being discovered in Week 7 by a rejected deployment. A constraint is not a requirement — a requirement says what the system must do, a constraint says what you are not permitted to consider. The 160 hours are themselves a constraint, and the most binding one you have. See also Assumption, Dependency, Two-thirds rule.

Context and container diagrams · Week 3 — Two levels of architecture picture, zoomed from far to near: context shows your system as one box with the people and systems around it; container opens the box to show what actually runs, in what technology, with every arrow carrying a direction, a payload, and a protocol. Simon Brown’s C4 model (https://c4model.com) supplies the ladder, and its real gift is telling you when to stop drawing. This edition draws two levels, not four — add a component diagram only where a reviewer would otherwise have to guess, and skip class-level diagrams of your own source entirely, because they have a half-life of about four days. An unlabeled arrow is a decision you have not made yet. See also Technical specification.

Continuous integration (CI) · Week 3 — The practice of merging your work into the mainline frequently and having an automated pipeline build it and run the tests on every push, so integration problems surface in minutes rather than in Week 7. From Week 3 onward a red pipeline on main is an emergency, not a nuisance. CI is not the same thing as continuous delivery or deployment, which push a passing build onward to users; and possessing a workflow file is not having CI — having tests that fail the build when the code is wrong is. GitHub Actions is the usual choice at this scale (https://docs.github.com/en/actions). See also Walking skeleton, Regression testing.

Critical path · Week 3 — The longest chain of dependent tasks through your schedule; its length is the shortest possible duration of the project, so a day lost on it is a day lost overall. You identify it in docs/plan.md so you know which slips are emergencies, and in Week 6 it becomes a triage input: a Must requirement unmet is a more severe defect when it sits on the critical path. It is not “the important work” — a critical-path task can be trivial and boring and still control your finish date. See also Schedule, Work package, Severity vs priority.

D

Defect · Week 6 — A place where the system’s actual behavior differs from its specified behavior. Notice what that definition depends on: with no specification you do not have defects, you have opinions, and opinions cannot be triaged or closed. That dependency is most of why Weeks 2 and 3 come before Week 5, and why an accelerated course still refuses to start construction from a blank requirements file.

Defect log · Week 6 — The single table at docs/defect-log.md of every defect found from Week 5 to Week 8, each with an identifier, discovery date, reproduction steps, severity, priority, status, and resolution. It is graded, and it is graded up for containing open defects at submission: an empty defect log on a real system means you did not look. It is not a to-do list — tasks belong on the board, defects belong in the log, and the two reference each other by identifier. See also Defect report, Severity vs priority, Test plan.

Defect report · Week 6 — One entry written so that a person who is not you can reproduce the failure: environment, preconditions, exact steps, expected result, actual result, evidence. The test is mechanical — hand it to a classmate with access to your repository and no context; if they cannot make the failure happen, the report is incomplete. “Login is broken” is not a defect report; it is a mood.

Definition of done · written Week 2, applied without mercy Week 5 — The checklist every task must satisfy before you may call it finished, kept at docs/definition-of-done.md — typically: acceptance criteria met, tests written and passing, CI green, documentation updated, requirement identifier in the commit message, no new lint errors. You write it once, early, and then apply it without exception, because its entire value is being non-negotiable at one in the morning in Week 6. “Done” does not mean “it works on my machine and I’ll write the test later” — that exact sentence is why this artifact exists. See also Acceptance criteria, Work package, Vertical slice.

Demo script · Week 8 — The written, rehearsed sequence of precisely what you will show, in what order, with what seeded data, and what you will say while something loads. Live demos fail on network, credentials, and empty databases; a script plus a recorded fallback is how a professional turns that from a catastrophe into a shrug. It is not a slide about the demo — it is the runbook for the riskiest five minutes of your term. See also Runbook, Graceful degradation.

Dependency · Week 2 (project), Week 3 (task) — Two senses, both live here. A project dependency is something outside your control that your project needs — a third-party API, a dataset, a library, a person’s permission — and each one belongs in docs/risk-register.md with a stated fallback. A task dependency is a “B cannot start until A finishes” relationship in your plan, and it is what creates the critical path. Do not let the word blur: one is a supplier, the other is a sequence. Every project dependency inherited from a brief must be exercised for real in Week 1, because a dependency you have only read about is an assumption.

Deployment · Week 7 — Getting one specific, tagged version of your software running somewhere that is not your development machine, by a repeatable procedure someone else could follow. “Deployed” means a person who is not you can reach it or can stand it up from your scripts; it does not mean it ran once on a free tier in March. What it looks like depends on the shape of the project — a reachable URL for a web application, a published installable artifact for a command-line tool — and packaging genuinely is deployment for a CLI. Cost, credential ownership, and teardown are part of the deliverable. See also Release tag, Configuration, Appendix A.

Design review · Week 4 — A scheduled inspection of your specification by readers who did not write it, run to find defects rather than to fix them: the author presents, reviewers raise issues, a recorder logs them, and nothing is argued to a conclusion in the room. Reviews catch a class of defect testing can never reach — a missing requirement, an impossible interface, an inherited assumption — because you cannot test what you never wrote down. Working solo, you approximate a team with a peer reader, your instructor, and a structured adversarial pass. It is not a status meeting, and the moment it turns into one it has stopped working. Week 4 has no milestone; the review and the halfway audit are the week’s graded work. See also Baseline, Halfway audit.

E

Elicitation · Week 2 — The active work of getting requirements out of people and out of the world: interviews, observation, document analysis, and asking the question behind the request. It is not “asking users what they want and writing it down” — stakeholders reliably describe solutions rather than needs, and your job is to recover the need underneath. This is the one piece of the long edition’s requirements work that does not compress: thirty minutes with one real human being, written up the same day in docs/elicitation-notes.md, is the only evidence in your document that a real person exists. The question that does most of the work is “walk me through the last time you did this.” See also Stakeholder, Persona, Inherited requirement.

Entry and exit criteria · Week 6 — The conditions that must hold before a level of testing may begin (entry) and before you may declare it complete (exit) — for example, entry: the build deploys and the smoke test passes; exit: every Must-have acceptance criterion passes and no severity-1 defect is open. Write them in docs/test-plan.md before testing starts, or you will discover that your exit criterion was “whatever I had energy for.” Exit criteria are how you ship on purpose with known defects instead of shipping by exhaustion. See also Release candidate, Defect log.

F

Fast-Start brief · Week 1; the twelve briefs are Appendix B — A pre-scoped project specification written to be adopted: a real problem with a named user, eight to ten drafted functional requirements with acceptance criteria, four to six drafted non-functional requirements with measurable targets, the genuinely hard part named in advance, a suggested stack sized to 160 hours, and a what-to-cut-first list. It is the single place this edition buys its compression — you do not shop for an idea, and Week 1 ends with a decision instead of a shortlist. A brief is not a specification and not a starter repository: it contains no code, nothing in it is verified for your situation, and copying it into docs/requirements.md produces a document with the shape of professional work and none of the content. You may adopt one, adapt one, or bring your own project and use a brief as the template; all three are graded identically and originality earns nothing. See also Adaptation pass, Inherited requirement, Adopt-or-deviate.

Feasibility screen · Week 1 — The three-question filter your project must pass before Friday of Week 1: can you build it with the skills you have plus one new thing, can you legally and practically obtain the data or access it needs, and can you deploy it by Week 7 at a price you can pay. An idea that fails any one is not a smaller project — it is a different project. Adopting a brief does not exempt you from the screen; the brief was screened for a generic student, not for your laptop, your rights, and your institution’s network. Every external dependency gets exercised once, for real, with a date. See also Dependency, Novelty load, Appendix A.

Functional requirement · Week 2 — A statement of something the system must do, written with an identifier, an actor, an action, an object, a condition, and a priority: “FR-INV-04 (Must) — A signed-in household member shall be able to mark a pantry item as consumed, which removes it from the active pantry list.” The test of a good one is that two competent people reading it build the same thing and a third can determine whether it was met. It is not a feature name, a screen, or a task — “search” is a menu item, not a requirement. In this edition most of yours arrive drafted, which changes the work from writing to judging but not the standard they are held to. See also Acceptance criteria, Non-functional requirement, MoSCoW, Adaptation pass.

G

Golden set · Week 6 — A fixed collection of inputs paired with known-good outputs, used to test a component whose behavior is not deterministic: an AI feature, a parser that tolerates messy input, a ranking function. You assert properties and tolerances against the set rather than exact string equality, and you re-run it after every model change, prompt change, or dependency upgrade. Without one, “the AI feature still works” is a vibe, not a test result. See also Prompt contract, Regression testing.

Graceful degradation · specified Week 3, tested Week 6 — Designing so that when a dependency fails — the third-party API times out, the model provider has an outage, the network drops — the user receives reduced function and a clear message instead of a stack trace, a spinner forever, or silent wrong data. You specify the degraded behavior when you design the seam and you test it by deliberately breaking the dependency, not by hoping. Demo day is precisely when the outage happens; this is what makes that survivable. See also Demo script, Prompt contract.

H

Halfway audit · Week 4 — This edition’s evidence-based pace check, run at exactly the moment half the budget is gone: hours logged against Must requirements completed, projected forward to Week 8, with a cut list attached when the projection overruns. Eighty of your 160 hours are spent and the application does not exist yet — a skeleton walks, and that is on purpose — so the audit does the subtraction that matters: about 45 plannable hours remain across Weeks 5 to 8, and inside them roughly 27 hours of feature construction. If your remaining Must estimate exceeds those numbers, you cut this week, in writing, as a change request. The audit is not a status report and not a formality: its output is a decision, and the failure mode it exists to refuse is passing it by adjusting the budget instead of the scope. See also Two-thirds rule, Scope cut, Design review.

Hallucination · Week 4, and everywhere AI appears — An assistant’s production of confident, fluent, specific content that is false: a version number, a license term, an API parameter, a security advisory identifier, a citation, a configuration flag. It will cite section 4.7 of a document that ends at 4.5, and FR-021 in a specification that ends at FR-018. It is not an occasional glitch but a property of how these systems generate text, which is why every factual claim you carry from an assistant into an artifact must be verified against the vendor’s own documentation. The dangerous ones are never the absurd ones — they are the plausible ones: the flag that should exist, the free tier that used to be free. See also AI-usage log, Prompt contract.

Handoff guide · Week 7 — The document at docs/handoff.md that lets a successor take the project over without ever speaking to you: the architecture overview and decision-record index, the week-one ramp that ends in a merged change, the open-defect list, a backlog with what you would do next, credential and cost ownership, the license inventory, and an honest known-limitations section. It is not an archive of the code — the code was never the hard part to transfer. Grade yourself by the only test that matters: could a competent stranger ship the next feature? See also Bus factor, Onboarding guide, Runbook.

Hat · Week 1 — This course’s word for a professional role that a software team normally distributes across several people and that a solo capstone forces onto one head: product owner, business analyst, architect, project manager, developer, tester, technical writer, release engineer. Every chapter names the hat you are wearing that week, because most capstone failures are role failures rather than coding failures — a strong developer who never wore the analyst hat builds the wrong thing beautifully. In eight weeks you change hats twice as fast, which makes the discipline of noticing when you have the wrong one on twice as valuable: writing code during requirements week is not being productive, it is hiding.

Hours log · Week 1, kept all eight weeks — An honest record of your hours by task category — requirements, design, construction, testing, documentation, rework — kept in docs/hours-log.csv and entered within a day of the work, because hours reconstructed a month later are fiction with a spreadsheet around it. It exists so you can learn to estimate, and so that the Week-4 halfway audit has real data to project from; with only eight weeks, a log started late is a log that never becomes useful. It is not a timesheet you owe anybody, and inflating it destroys the one benefit it has. A grader reads it for patterns: identical durations, round numbers everywhere, a single fourteen-hour Sunday, silence in weeks the commit history says you were working. See also Velocity, Burn-down, Three-point estimate.

I

Impact analysis · Week 4, practiced Week 6 — The short written assessment attached to every change request: which requirements, modules, tests, and documents this change touches, roughly how many hours it costs, and what gets cut to pay for it. Three honest lines beat three vague pages. Skipping it is how a “quick addition” in Week 6 quietly consumes the documentation week and takes ten rubric points with it — and in an eight-week course there is no later week to borrow from. See also Change request, Scope cut.

Inherited requirement · Week 2 — A requirement that came to you already written, from a Fast-Start brief or a template, rather than from your own elicitation. Inheriting is normal and carries no penalty; what is graded is whether you re-justified it. The signature failure mode of this edition is an inherited requirement that quietly describes somebody else’s project — and the dangerous ones are never the obviously wrong ones, they are the plausible ones that fit the brief’s problem so naturally you never stop to ask whether they fit yours. Three questions catch almost all of them: does my actor appear in it, does my scope still contain it, and does the acceptance data exist in my project? The reliable tell is a noun that appears nowhere in your charter — household, barcode, administrator, tenant, subscription. See also Adaptation pass, Fast-Start brief, Charter.

Integration testing · Week 6 — Testing the seams: whether two or more components that pass their own unit tests actually work together across the interface you specified, with real calls, real payloads, and real error codes. This is where most defects in a capstone actually live, because the units are usually fine and the contracts have usually drifted. It does not mean “run the whole application and click around” — that is system or acceptance testing, and it will not tell you which side of the seam is wrong. See also Unit testing, Acceptance testing, Walking skeleton.

Issue · conventions set Week 1, lived in Week 5 — A tracked item of work in your repository’s tracker — a task, a defect, or an approved change — carrying an identifier, a state, and a link to the requirement it serves. From Week 1 forward every commit subject leads with a requirement identifier, which is what makes traceability a habit instead of an archaeology project in Week 8 and lets the change log mostly write itself. An issue is not a note to self; a note to self is a note to self. See also Project board, Requirement identifier, Traceability.

Iteration · Week 5 — A fixed-length build cycle that ends in working software you can demonstrate. This edition runs essentially one and a half: Week 5 builds the core vertical slices and ends in a demo, Week 6 integrates and hardens them into a release candidate. The rule that makes an iteration real is that it ends in something runnable — “iteration one: the database layer” is a phase wearing an iteration’s clothes. See also Vertical slice, Release candidate.

L

License · constraints noticed Week 3, yours published Week 7 — The legal terms under which software may be used, modified, and redistributed. Two families matter to you: permissive licenses generally let you ship with attribution, while copyleft licenses can require derived work to be released under the same terms — a genuine constraint if you intend to publish your repository. Your repository needs a LICENSE file naming one, because “no license” means all rights reserved, which is the opposite of what most students intend. Check the actual text of the licenses your dependencies carry — the standard identifiers are catalogued at https://spdx.org/licenses/ — and never take an assistant’s summary of a license as fact. See also Hallucination, Constraint, Handoff guide.

M

Milestone · Weeks 1, 2, 3, 5, 6, 7 and the final in Week 8; see Appendix D — This course’s weekly deliverable: a named artifact due at the end of the week that becomes part of the final package. Milestone numbers match chapter numbers, and there is no Milestone 4 — Week 4 is the design review, the halfway audit, and the midterm checkpoint. The six milestones are graded twice — together they carry 25 percent of the course grade, and the Week-8 rubric then awards points for exactly the artifacts they produce, so a skipped milestone costs you once now and again as the same points deferred to a week with no time left in it. Milestone 8 is the final submission and it is 50 percent of your grade. In an eight-week course one week is an eighth of the term, so falling behind is proportionally twice as expensive as in the long edition.

Minimum viable scope · Week 1 — The smallest version of your project that still solves the user’s problem end to end and can be built, tested, documented, and deployed inside 160 hours. It is a complete small thing, never a partial big thing — the difference between a working single-household tool and forty percent of a platform. Everything beyond it moves into Should, Could, and Won’t, where it is visible instead of assumed. The arithmetic that sizes it is unforgiving: roughly thirty hours of net feature construction, seven to nine hours per vertical slice in a stack you know. See also Two-thirds rule, MoSCoW, Feasibility screen.

MoSCoW · Week 2 — A prioritization scheme with four buckets: Must have (the release fails without it), Should have (important, painful to omit, survivable), Could have (nice, and the first thing to go), and Won’t have this time (explicitly out of scope, and written down). It comes out of the DSDM tradition, and its real power is the fourth bucket: recording what you will not build is how you defend scope in Week 6 against your own enthusiasm. It is not a one-to-N ranking, and “Won’t” does not mean “never” — it means not in this release, on purpose. Here the Must list is the schedule: three or four Musts, not five, and if more than roughly half your requirements are Musts you have not prioritized, you have relabeled. See also Two-thirds rule, Scope cut.

N

Non-functional requirement (NFR) · Week 2 — A requirement about a quality of the system rather than a behavior: performance, availability, security, privacy, accessibility, usability, maintainability, portability. It only counts as a requirement if it is measurable — metric, threshold, condition, and method of verification — so “the system shall be fast” is not one, and a p95 render target under a stated data volume and network profile, measured by a named procedure and recorded in docs/measurements.md, is. NFRs are not polish or extras: they are the requirements that most often sink a capstone, because unlike features they cannot be retrofitted in Week 7. Every inherited NFR target arrives with numbers attached to somebody else’s conditions — the numbers may survive your adaptation pass, but the conditions rarely do. See also Quality attribute, Threats to validity, Inherited requirement.

Novelty load · counted Week 1, spent Week 3 — How many pieces of your stack you have never shipped with — not read about; built, deployed, and debugged at eleven at night. Dan McKinley’s framing is that a project gets a small fixed budget of innovation tokens and every exciting new technology spends one. A sixteen-week solo capstone gets one; you have half the calendar and you still get one, spent on the piece closest to what makes your project interesting. Two is survivable only if they are nowhere near each other, and three is how an accelerated capstone dies in Week 6, because learning curves compound rather than add: when something breaks across two unfamiliar pieces you cannot tell which one is lying to you. High novelty load is not ambition; it is unpriced risk. See also Adopt-or-deviate, Spike, Risk register.

O

Onboarding guide · Week 7 — The material that carries a new contributor from zero to their first useful change: what the project is for, how the code is organized, how to run it and the tests, the conventions you follow, and a suggested first task with acceptance criteria already written. In this edition it is not a separate file — it is section 2 of docs/handoff.md, one of three deliberate merges that let Week 7 ship four documents instead of seven without losing information. It differs from the README, which gets someone running, and from the runbook, which keeps the system running, by targeting the person who has to change the code. A successor who ships something in week one has joined the project; one still reading in week three has not. See also Handoff guide, README, Bus factor.

P

Persona · Week 2 — A short, evidence-based profile of a representative user — their goal, their context, their constraint, their skill level — used to keep design decisions anchored to somebody real. A persona is not demographic decoration and not a character you invented to justify the feature you already wanted to build; it has to be grounded in at least one conversation with an actual human being. A brief hands you a user archetype, which is not the same thing: the archetype is a sketch of who has this problem in general, and your persona is the person you talked to, with a date on the conversation. One or two is right at this scale. See also Stakeholder, Elicitation.

Priority · Week 2 (requirements), Week 6 (defects) — How soon something will be addressed relative to everything else competing for the same hours. It is a scheduling judgment and it belongs to whoever owns the plan, which this term is you. Do not conflate it with severity or with abstract importance: a cosmetic defect on the screen your committee will see can be priority-1 in Week 8 and priority-4 forever afterward. Watch what happens to priorities when the adaptation pass splits one inherited requirement into two — they almost never stay equal. See also Severity vs priority, MoSCoW.

Product owner · Week 1 — The hat you wear when deciding what the software is for, who it serves, and what is worth building — the accountable “why” role. Its hardest act is saying no to a genuinely good idea because it does not serve the user you chose, and its second hardest is saying no to a good idea somebody else already wrote down for you. When you catch yourself keeping a requirement because it was in the brief, the product owner has quietly left the room. See also Hat, Charter, Inherited requirement.

Project board · Week 1 — The visible state of your work: columns for backlog, in progress, blocked, in review, and done, with each card carrying the requirement identifier it serves. Its purpose is to make hidden work visible — especially “blocked,” which is the state that silently eats weeks while you tell yourself you are making progress, and in eight weeks a silently eaten week is an eighth of the course. A board with thirty cards in “in progress” is a board that is lying to you; a solo student can genuinely hold about two. See also Backlog, Issue.

Prompt contract · Week 5; the measurable envelope specified Week 2 — The specification of an AI component’s interface, written like any other interface contract: the exact input you send, the output shape you require (a schema, not “a paragraph”), the constraints and refusals, the token and latency budget, the validation you run on every response, and the fallback when validation fails. Writing it forces the question students skip — what does the system do when the model returns nonsense? A prompt contract is not the prompt text: the prompt is an implementation detail that will change, while the contract is what the rest of your system is built against. Version it, record the model identifier you tested against, and treat a model or prompt change as a change request. See also Golden set, Graceful degradation, AI-usage log.

Q

Quality attribute · Week 2 — A property of the system as a whole — performance, security, usability, maintainability, portability — that your non-functional requirements make measurable. The word matters because attributes trade against one another: security costs latency, portability costs simplicity, maintainability costs time you would rather spend on features. Naming the tradeoff and recording the choice in a decision record is the difference between a design and a pile of hopes. See also Non-functional requirement, Architecture decision record.

R

README · Week 7 — The front door of the repository: what the project is, who it is for, prerequisites with versions, then install, configure, run, test, and where to go next — written for a stranger with fifteen minutes and no context. README.md is the single most-read file in your submission and the first one a grader opens. It is not a narrative of your term and not where the architecture goes; keep it operational and put the reasoning in docs/architecture.md. This edition’s specific trap lives in its “what it does not do” section: the brief’s non-goals are not your non-goals, and a README carrying the catalog’s list is a document quietly describing somebody else’s project. See also Clean-machine test, Runbook, Inherited requirement.

Regression testing · Week 6 — Re-running existing tests after a change to confirm that what used to work still works. The discipline that makes it real: every defect you fix gets a test that reproduces it, added to the suite permanently, so that particular failure can never return in silence. It is not testing the new feature — that is progression testing — and it is not something you do by hand at the end of the term. Regression testing is what continuous integration is for. See also Continuous integration, Defect log, Golden set.

Release candidate (RC) · Week 6 — A build you believe is shippable, frozen and offered up for final verification; if verification finds no blocking defect it becomes the release, and if it does, you fix, re-tag, and re-verify. Declaring something an RC is a claim with consequences: every Must-have acceptance criterion passes, no severity-1 defect is open, and the documentation matches the actual behavior. It is not “the version I hope works” and not “the last commit before the deadline.” Freezing matters more here than in the long edition, because verification has to measure a target that stops moving and you have one week in which to do it. See also Entry and exit criteria, Release tag, Scope cut.

Release tag · Week 7 — An immutable, named point in your version history — v1.0.0 — that lets anyone retrieve exactly the code you claim to have delivered. Semantic versioning (major.minor.patch, https://semver.org/) is the usual convention; the number matters far less than the fact that a grader in Week 8 can check out the tag and receive precisely the artifact you submitted. Deploy from the tag, never from your working copy — if the running thing came from a directory on your laptop, nobody including you can say what is in it. “Latest on main” is not a deliverable, because main moves. See also Deployment, Change log.

Requirement identifier · convention chosen Week 1, applied Week 2 — The stable label — FR-INV-04, NFR-PERF-01 — that lets a requirement be referenced from a test case, an issue, a commit message, a diagram, and the traceability matrix without ambiguity. Pick one form and never mix: area-scoped FR-<AREA>-<nn> if your project has clear areas, flat FR-<nnn> otherwise. Restate every inherited identifier in your scheme during the adaptation pass, all at once, before anything references them — and after that, assign once and never renumber. When a requirement dies, mark it withdrawn and leave the number in place as a headstone. The entire traceability discipline of this course hangs off this one small habit. See also Traceability, Adaptation pass.

Requirements traceability matrix (RTM) · Week 2 — A table, kept here as docs/traceability.csv, linking every requirement to the design element that realizes it, the code or issue that implements it, and the test that verifies it. Read left to right it proves nothing was left unbuilt; read right to left it proves nothing was built that nobody asked for — which in this edition is the check that catches an inherited requirement you implemented without ever wanting. It is not bureaucratic paperwork at this scale; it is a short artifact answering the two questions your grader and your Week-8 self will both ask: is it all there, and how do you know? See also Traceability, Requirement identifier, Test case.

Retrospective · Week 8 — The written, honest look backward filed as docs/retrospective.md: what you would do differently with the same 160 hours, where your estimates were wrong and by how much, which decision you would reverse, and — particular to this edition — how well you read the brief you inherited. It is graded on candor and specificity, not positivity: “I would start testing earlier” is a slogan, while “I logged 14 hours of rework in Week 6 that one Week-3 integration test would have prevented” is a retrospective. You have the evidence; docs/hours-log.csv and docs/defect-log.md were built for exactly this paragraph.

Risk register · Week 3 — The living table at docs/risk-register.md of things that could go wrong, each with a likelihood, an impact, an observable trigger, and a response you have already chosen (avoid, mitigate, transfer, accept). The trigger column is what turns it from a worry list into an instrument: a risk with no trigger has nothing to tell you when to act. Six risks you will actually reread beat twenty you will never open again — and you reread them in four days, because the Week-4 halfway audit opens this file in front of you. See also Assumption, Dependency, Novelty load.

Runbook · Week 7 — The operations document at docs/runbook.md: where the system runs, how to start, stop, and monitor it, what routine maintenance it needs, what its known failure modes look like, and step-by-step recovery for each. It answers “it is eleven at night and the thing is down.” It is not the README, which answers “I have never run this before.” In this edition it also carries the deployment and rollback material the long edition puts in its own document — a runbook that does not say where the thing runs is not a runbook. Four honest failure entries is the bar at this scale, not eight. See also Handoff guide, Graceful degradation, Two-thirds rule.

S

Schedule · Week 3 — The mapping of work packages onto calendar weeks with dependencies, milestones, and buffer, built in docs/plan.md against the hours you actually have rather than the hours a week theoretically contains. Twenty hours a week is the budget, 160 in total, and this course subtracts course overhead and a declared buffer before calling anything plannable — the number that survives is far smaller than the number you started with, and it is the only one worth planning against. A schedule with no slack is not aggressive; it is already late, and everyone but its author can see that. See also Work breakdown structure, Critical path, Halfway audit.

Scope creep · named Week 2, controlled from Week 4 — The uncontrolled accumulation of work that was never baselined: features added because they occurred to you, “small” improvements with unpriced costs, requirements that quietly grew a third clause. It is not the same as change — a change request with an impact analysis and a recorded decision is professional practice, not creep. This edition has a second source the long one does not: scope you never chose, arriving inside an inherited requirement you failed to withdraw. The defense is three things: a baseline, a written Won’t-have list, and the discipline to route every new idea through change control. See also Change control, Baseline, Inherited requirement.

Scope cut · cheapest Week 4, last chance Week 6 — A deliberate, recorded removal of planned work when the hours will not stretch, made early and written into docs/change-requests/ and the change log rather than discovered later by a grader as an unexplained absence. Cutting scope is not failure. Cutting scope silently is. Cut in this order: highest novelty first, then the most external dependencies, then whatever your stakeholder ranked last, then anything you inherited from a brief and never re-justified. Cut last whatever makes the Week-8 demo tell a coherent story, and never cut the tests, the documentation, or the deployment — those are the bulk of your grade. Move it, do not delete it; demote whole, not partial. See also Halfway audit, Change request, MoSCoW.

Scoping decision · Week 1 — The memo at docs/scoping-decision.md recording, by Friday of Week 1, which brief you adopted or that you brought your own, what the problem is, the evidence a real user exists, the Must list with an hour figure on every line, what is explicitly out of scope, the briefs you rejected and why, the feasibility screen, the reconciled hour budget, the one genuinely hard part, and the trigger that will fire the first scope cut. Its centerpiece is the adaptation record: every deviation from the brief, with the requirement identifiers it touches — including the word “none”, signed, if you adopted the brief as written. It is not the charter, which says what the project is; the scoping decision says what you decided to do about it and what you gave up to fit 160 hours. Everything Week 2 repairs is traced from this document. See also Charter, Adaptation pass, Feasibility screen.

Secret · settled Week 3, audited Week 7 — Any credential the system needs and the repository must never contain: API keys, tokens, passwords, connection strings, private data. Supply them through environment variables or your platform’s secret store, commit .env.example with placeholder values only, and remember that a secret pushed even once lives in the history forever. The part everybody gets backwards: if a key is already committed, rotate it at the provider first — revoke, reissue, and only then clean history, because rewriting history does not reach forks, clones, CI caches, or somebody else’s terminal scrollback. A student who leaks a key, rotates it within the hour, and logs the incident has behaved like a professional. See also Configuration, Deployment.

Severity · Week 6 — How bad the consequence is when a defect occurs, judged against the system’s purpose: data loss and security exposure at the top, cosmetic misalignment at the bottom. Severity is a property of the defect itself, and it does not shrink because your deadline got closer. Define your scale — four levels is plenty — in docs/test-plan.md, before you have any temptation to grade on a curve.

Severity vs priority · Week 6 — The distinction students collapse most often, and the one triage entirely depends on. Severity is how bad it is when it happens; priority is how soon you will fix it. They come apart in both directions: a catastrophic data-loss defect on a code path no user will reach this term can be severity-1 and priority-3, while a typo on the landing page your committee sees Friday is severity-4 and priority-1. Record both, decide with both, and never let “it’s a sev-1” mean “drop everything” by reflex — with one week of hours left, reflexes are expensive. See also Defect log, Scope cut.

Software development life cycle (SDLC) · Week 1 — The full arc of activity a software product moves through — inception, requirements, design, planning, construction, verification, documentation, deployment, transition and handoff — and the framework this entire course is organized around. It describes activities, not a mandated order: iterative approaches revisit the same activities many times, a waterfall process runs each once. The SDLC does not mean waterfall, and treating the two as synonyms is exactly how students talk themselves into believing requirements are old-fashioned. Compressing the calendar removes none of these activities; it only removes the slack between them.

Software requirements specification (SRS) · Week 2, baselined Week 4 — The single document stating what the system must do and how well, complete with identifiers, acceptance criteria, priorities, constraints, and assumptions; it lives at docs/requirements.md. It is the contract between the product owner hat and the developer hat — worn, in your case, by the same head, which is precisely why it has to be written down where you can be held to it. Everything downstream derives from it: the technical specification, the work breakdown structure, the test plan, the traceability matrix. Yours starts life partly inherited, which changes nothing about the standard it is graded to. See also Functional requirement, Baseline, Adaptation pass.

Spike · Week 3, scheduled again at the Week 4 audit — A timeboxed investigation whose deliverable is an answer, not a feature: “spend three hours determining whether the product-lookup API returns data for store-brand items, and write down what you find.” The term comes from Extreme Programming, and two rules make it real — the box (when time is up you stop and report what you know) and the write-up (a spike with no written finding did not happen). It is not permission to play with an interesting framework for a week; at 160 hours you can afford roughly one in the back half. See also Novelty load, Three-point estimate.

Stakeholder · Week 2 — Anyone whose interests the system affects, or who can affect the system: users first, but also whoever hosts it, the department that owns the data, the accessibility office, your instructor, and the successor who inherits it. Enumerate them before you elicit anything, because the requirement you miss almost always belongs to the stakeholder you never listed. A stakeholder is not a synonym for a user, and treating the two as identical is how a finished project turns out to be undeployable on the institution’s network. If your only real user stops answering in Week 4, that is a critical defect in the project, not in the document. See also Elicitation, Persona, Constraint.

T

Technical debt · Week 6 — A shortcut taken deliberately to move faster now, with a cost recorded and accepted for later. The useful distinction is deliberate versus inadvertent: debt you chose and wrote down is a decision, while debt you incurred through carelessness is simply defect with a flattering name. This course mostly refuses the phrase and makes you file the same thing under a name with teeth — an open defect in docs/defect-log.md with a severity, or a requirement deferred by change request — because “technical debt” is the term students reach for when they want the sound of a decision without the paperwork of one. Whatever you call it, it belongs in the handoff. See also Defect log, Scope cut, Change request.

Technical specification · Week 3 — The design document at docs/architecture.md saying how the system will meet its requirements: diagrams at the levels that actually help, component responsibilities, interface contracts, the data model, sequence flows for the paths that matter, and error handling. Its reader is a stranger, and the stranger is you in Week 6 — write against that test. It is not the requirements restated in more technical vocabulary and not something generated from the code afterward. Sized to eight weeks it is short by design, and it is baselined at the Week-4 review. See also Context and container diagrams, Baseline, Architecture decision record.

Test case · Week 6 — One executable check with a fixed input, stated preconditions, a procedure, and a single expected result, traceable to the acceptance criterion it verifies. The relationship runs both ways: a criterion with no test case is unverified, and a test case with no criterion is a test of something nobody asked for. “Test the login” is not a test case. Verified-requirement coverage — how many of your Musts have a passing case behind them — is a far more honest number than line coverage and the one this course grades. See also Acceptance criteria, Requirements traceability matrix.

Test plan · Week 6 — The document at docs/test-plan.md stating what will be tested and what will not, at which levels, in which environment, with what data, under which entry and exit criteria. It is written before the tests, and it is where you state honestly the limits of your verification. A test plan with no “out of scope” section is not a plan; it is an advertisement. See also Entry and exit criteria, Threats to validity.

Threats to validity · conditions written into every NFR Week 2, presented Week 8 — The written list of reasons your evidence might not support the claim you are making: a benchmark run once on your own laptop, test data you generated to match your own assumptions, a performance number measured against an empty database, a usability verdict from two friends who like you. Stating them is not weakness — it is the mark of an engineer who knows what a measurement can and cannot bear, and committees reward it every time. Never present a number without the conditions that produced it: one unsourced figure in a presentation turns every other figure in the deck into a guess. See also Non-functional requirement, Test plan.

Three-point estimate · Week 3 — An estimate expressed as three numbers — optimistic (O), most likely (M), pessimistic (P) — combined into an expected duration, commonly by the PERT weighting (O + 4M + P) / 6. Its value is not the arithmetic but the act: you are forced to say out loud what the bad case is, and the gap between O and P measures how much you do not know. If P divided by O is over four, you do not understand the task — split it or buy the information with a spike. It does not mean picking the middle number and feeling scientific about it. See also Work package, Spike, Hours log.

Traceability · Week 2 — The property that every requirement can be followed forward to the design, code, and test that satisfy it, and every artifact can be followed back to the requirement that justifies its existence. It is maintained by referencing identifiers everywhere — in commits, branches, test names, diagrams, and documents — not by reconstructing the links in a panic in Week 8. In an eight-week course the reconstruction is not merely painful; there is no week available in which to do it. See also Requirements traceability matrix, Requirement identifier.

Two-thirds rule · Week 1, enforced at the Week 4 audit — This edition’s governing constraint: 160 hours buys a project about two-thirds the size of a sixteen-week capstone, which means three to four Must features, not five and never more. The arithmetic behind it is public — roughly thirty hours of net feature construction after the skeleton, verification, deployment, and documentation take their share, against seven to nine hours for a vertical slice in a stack you know and twelve to twenty in one you do not. It is not a statement that this course is easier or that anything professional has been cut; every artifact the long edition requires, you also produce. It is a statement about volume, and it applies to the documentation as well as the features: four runbook failure entries, not eight. The single most common way to fail an accelerated course is to attempt a full-length project in half the calendar. See also Minimum viable scope, Halfway audit, Scope cut.

U

Unit testing · Week 6 — Testing one small piece of code in isolation from its collaborators — no network, no database, no clock — so that a failure names the defect’s location precisely and the whole suite runs in seconds. Unit tests are the foundation continuous integration stands on: cheap, numerous, and fast on purpose. A test that boots your web server and drives the interface is not a unit test, however it is named, and treating it as one is why student suites become slow, then flaky, then skipped. See also Integration testing, Continuous integration, Regression testing.

User story · Week 2 — A short statement of a need from a user’s point of view — “as a household member, I want to see what expires this week, so that I can cook it before it is wasted” — used to hold a conversation and drive out requirements. Stories are excellent at capturing intent and terrible as a specification: they carry no identifier, no measurable condition, and no acceptance boundary until you add them. A user story is not a requirement. This course does not ask you to produce them as a deliverable — a Fast-Start brief hands you drafted requirements instead — but you will meet the format everywhere in industry, and the mistake to avoid is the same one either way: shipping the intent and calling it the obligation. See also Functional requirement, Acceptance criteria, Elicitation.

V

Velocity · first measured Week 4, used Week 5 — How much work you actually complete per week, measured from your own history in hours or completed work packages. Its one legitimate use is forecasting your remaining schedule; comparing it to a classmate’s is meaningless, and comparing it to a professional team’s is worse than meaningless. Four weeks of data is thin, which is exactly why docs/hours-log.csv starts on day one — the halfway audit has nothing else to project from. Estimate with the velocity you have, not the one you would like to have. See also Hours log, Burn-down, Halfway audit.

Vertical slice · sized Week 1, built Week 5 — One requirement built all the way through every layer — interface, logic, storage, the error path, at least one test, and the line of documentation saying it exists — so that when it is finished you can demonstrate a real user doing a real thing. Slices are how a project stays demonstrable at every point in the term instead of arriving at Week 7 with three beautiful finished layers and nothing that works. A vertical slice is not a layer: “the database schema” is horizontal, and horizontal work is invisible to everyone, including you. It is also the unit the two-thirds arithmetic is denominated in. See also Walking skeleton, Definition of done, Two-thirds rule.

W

Walking skeleton · Week 3 — A tiny end-to-end implementation that exercises every architectural component and the entire build-and-deploy path: one trivial operation traveling from the interface through the logic to storage and back, running in CI. The term is Alistair Cockburn’s. It exists to prove the seams while you still have nothing to lose, which is why it comes before features rather than after them — and why this edition insists it walks in Week 3, not Week 5. Any seam you have never crossed gets attempted here or gets designed out; there is no later week with room for an integration surprise. It is not a prototype (thrown away), not a mockup (no back end), and not a minimum viable product (that has user value) — the skeleton is real code that does almost nothing, deliberately. See also Vertical slice, Continuous integration, Novelty load.

Work breakdown structure (WBS) · Week 3 — A hierarchical decomposition of the project into deliverables and then into work packages small enough to estimate honestly. It is decomposed by deliverable, not by time: the WBS says what must exist, and the schedule then decides when. It is not a task list and not a Gantt chart, and building it directly from docs/requirements.md is what makes your estimates traceable to something real rather than to a mood. Include the work nobody writes down but everybody does — seed data, error handling, the accessibility pass, secrets and configuration, reading and fixing generated code — because otherwise it comes out of the documentation budget at midnight in Week 7. See also Work package, Schedule, Three-point estimate.

Work package · Week 3 — The leaf of the work breakdown structure: the smallest unit you estimate, assign, and track. This course decomposes to work packages of roughly four to twenty hours and tasks of one to six, each naming its deliverable, its requirement identifier, and a done-when somebody else could check. If you cannot say what will exist in the world when it is finished, it is not a work package yet; it is a topic. See also Definition of done, Backlog, Three-point estimate.

A closing word from Coach

You are not expected to memorize this page. You are expected to reach for it — in Week 2 when you cannot tell an inherited requirement you should keep from one you should withdraw, in Week 4 when the audit says the plan does not fit and you need the right word for what you are about to do, in Week 7 when somebody asks what your bus factor is and you would like an answer better than a shrug.

Here is the test that tells you the vocabulary has landed. It is not that you can define “baseline.” It is that when someone says “let’s just add it,” you hear the missing change request, the missing impact analysis, and the missing line in the change log — and you say so, in four words, without sounding like a textbook.

And here is the test particular to this edition. In Week 8, in front of a committee, you will be asked where a requirement came from. The strong answer sounds like this: “I adopted brief number one, kept the problem and the user, replaced the suggested stack in ADR-0001, rewrote three acceptance criteria after talking to my actual user in Week 2, and cut two Shoulds in Week 4 when the halfway audit projected 190 hours against 160.” Every noun in that sentence is on this page. None of it is an apology. All of it is the language of somebody who took work that was not theirs, made it theirs on purpose, and can prove it.

Say the thing, mean the thing, and let the word carry exactly what it claims.

Up next: The workbench, if you have not built it yet: Appendix A. The twelve briefs these terms are adapted from: Appendix B. Templates and worked examples for every artifact named here: Appendix C. The rubric these terms are graded against: Appendix D. Then back to the week you are in — starting with Week 1.