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, what 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.

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 “epic” a little differently from a shop that runs a formal SDLC. 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 that says 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.

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. 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 3 — 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 11 you map one to the other. Every functional requirement in your specification needs them. See also Definition of done, Test case, Functional requirement.

Acceptance testing · Week 11 — 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. In this course you are your own customer, so acceptance tests run directly against the acceptance criteria in docs/requirements.md, one test per criterion, with the results recorded. 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 demo.

Accessibility · Week 4 — 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 measurable targets written in Week 4, not a panic sweep in Week 15 — the W3C’s Web Accessibility Initiative (https://www.w3.org/WAI/) is the standard starting point. It is not exclusively a web concern, and it is not a legal box to tick; it is the requirement whose beneficiary you will never meet.

AI-usage log · Week 10; policy decided Week 1 — The record kept in docs/ai-usage.md of where an AI assistant contributed to your project: what you asked for, what it produced, what you changed, and how you verified it. 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 Prompt contract, Hallucination, Appendix C.

Architecture decision record (ADR) · Week 5 — 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. See also Appendix B.

Assumption · Week 4 — 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 8 design review; that is when the false ones are still cheap.

B

Backlog · Week 7; board stood up Week 1 — The ordered list of work not yet done: tasks derived from your work breakdown structure, defects from the defect log, 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. Your project board is the backlog made visible, and every item on it should carry the requirement identifier it serves.

Baseline · Week 8 — A version of an artifact that has been reviewed, approved, and frozen, after which it changes only through change control. Week 8 baselines your requirements specification and technical specification; 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 that 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.

Branching strategy · Week 9 — 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. A solo capstone is well served by short-lived feature branches off a protected main that continuous integration must pass. This is not ceremony — it is what makes “main always runs” true, and “main always runs” is what the clean-machine test in Week 13 depends on.

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 7 — A chart of remaining work against time, updated weekly, 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 it only works if you update it faithfully in the weeks when the news is bad. See also Velocity, Hours log, Schedule.

Bus factor · Week 14 — 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 14 exists: the handoff package, the runbook, and the decision records are the instruments that raise it. Higher is better; a bus factor of one is the risk, not the achievement. Ask the honest question this week: what do you know about this system that exists nowhere except inside your head? See also Handoff package, Onboarding guide.

C

Change control · Week 8 — 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. Student projects rarely die of change; they die of unrecorded change. See also Change request, Baseline, Impact analysis.

Change log · Week 12 — A human-readable CHANGELOG.md listing what changed in each version, grouped by release, written for a reader rather than generated from commit subjects. A grader in Week 16 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) · Week 12 — 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. Three honest lines of impact analysis is 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.

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 the first artifact you produce and the one you re-read whenever a shiny idea arrives in Week 11 wearing the costume of an obvious improvement. A charter is not a requirements document — it is the thing your requirements must stay consistent with, and the thing you point at when you say no.

Clean-machine test · Week 13, repeated Week 16 — 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. 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 is trying to expose. Passing it once is the requirement; failing it in Week 16 is the most common avoidable loss on the whole rubric. See also README, Runbook, Reproducibility.

Code freeze · Week 12 — A declared point after which only defect fixes at or above an agreed severity are permitted into the release branch. It exists so that verification measures a target that stops moving. A freeze is not the end of work — it is the beginning of the release candidate cycle, and it is what makes a test result mean something a day later.

Configuration · Week 14 — 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 (or equivalent) that lists every key 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.” See also Secret, Deployment, Reproducibility.

Constraint · Week 4 — 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 language your reviewer must be able to read. Constraints bound the solution space before design starts, which is exactly why they belong in the requirements specification rather than being discovered in Week 12 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. See also Assumption, Dependency.

Context, container, and component diagrams · Week 6 — Three levels of architecture picture, zoomed from far to near: context shows your system, its users, and the outside systems it talks to; container shows the runnable pieces (application, API, database, scheduled job); component shows the modules inside one container. Draw the first two for every project and the third only where the design is genuinely non-obvious — then stop, because the fourth level is the code, and the code is already its own diagram. Label every arrow with what flows across it and in which direction; an unlabeled arrow is a decision you have not made yet.

Continuous integration (CI) · Week 9 — 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 14. From Week 9 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 Regression testing, Unit testing.

Critical path · Week 7 — 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 so you know which slips are emergencies: a delay on a task nothing waits for is not the same problem as a delay on the task every later task needs. It is not “the important work” — a critical-path task can be trivial and boring and still control your finish date.

D

Defect · Week 11 — 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 a large part of why Weeks 3 through 6 come before Week 9.

Defect log · Week 11 — The single table, at docs/defect-log.md, of every defect found from Week 9 to Week 16, 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 Severity vs priority, Test plan.

Defect report · Week 11 — 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 · Week 4, enforced Week 10 — The checklist every task must satisfy before you may call it finished — 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 mercy, because its entire value is being non-negotiable at one in the morning in Week 12. “Done” does not mean “it works on my machine and I’ll write the test later” — that exact sentence is the reason this artifact exists. See also Acceptance criteria, Work package.

Demo script · Week 15 — 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 semester. See also Runbook.

Dependency · Week 4 (project), Week 7 (task) — Two senses, both live in this course. 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 the risk register with a stated fallback. A task dependency is a “B cannot start until A finishes” relationship in your schedule, and it is what creates the critical path. Do not let the word blur: one is a supplier, the other is a sequence.

Deployment · Week 14 — 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 October. Cost, credential ownership, and teardown are part of the deliverable, not afterthoughts. See also Reproducibility, Release tag, Configuration.

Design review · Week 8 — 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 whole class of defect that testing can never reach — a missing requirement, an impossible interface, an unexamined 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.

E

Elicitation · Week 3 — The active work of getting requirements out of people and out of the world: interviews, observation, document analysis, prototypes, 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 the solution they proposed. When the stakeholder is you, elicitation means interrogating your own assumptions in writing, ideally against a skeptical reader whose output you then rewrite in your own words. See also Stakeholder, Persona, User story.

Entry and exit criteria · Week 11 — 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 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.

Epic · Week 3, decomposed Week 7 — A body of work too large to build or verify in one sitting, which exists to be broken down into user stories or work packages: “inventory management” is an epic, “the resident adds an item by barcode” is not. Epics are containers for planning and traceability, never units of work you assign to a week. An epic is not simply a story you have not estimated yet — if you can build and verify it in an afternoon, it was never an epic.

F

Feasibility screen · Week 2 — The three-question filter every candidate idea must pass before it can become your project: 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 somewhere by Week 14 at a price you can pay. An idea that fails any one of the three is not a smaller project — it is a different project. Run the screen on all three candidates before you fall in love with one of them. See also Appendix D, Minimum viable scope.

Functional requirement · Week 3 — 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 person 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. See also Acceptance criteria, Non-functional requirement, MoSCoW, Requirement identifier.

G

Golden set · Week 11 — 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 · Week 12 — 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 in Week 6 and you test it in Week 12 by deliberately breaking the dependency, not by hoping. Demo day is precisely when the outage happens; this is what makes that survivable.

H

Hallucination · Week 5, and everywhere AI appears — An AI assistant’s production of confident, fluent, specific content that is false: a version number, a license term, an API parameter, a price, a citation, a configuration flag. It is not an occasional glitch but a property of how these systems generate text, which is why this course requires that every factual claim you carry from an assistant into an artifact 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 package · Week 14 — The set of artifacts that lets a successor take the project over without ever speaking to you: README.md, docs/runbook.md, the architecture overview, the decision-record index, the open-defect list, a backlog with what you would do next, credential and ownership instructions, and an honest known-limitations section, gathered in docs/handoff.md. 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. The discipline is noticing when you have the wrong one on: writing code during requirements week is not being productive, it is hiding.

Hours log · Week 1, kept all sixteen weeks — An honest weekly 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 that you can learn to estimate: by Week 7 it is the only calibration data in existence about how long you actually take to do things. It is not a timesheet you owe anybody, and inflating it destroys the one benefit it has. See also Three-point estimate, Reference class, Velocity, Burn-down.

I

Impact analysis · Week 12 — 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 12 quietly consumes the documentation week and takes ten rubric points with it.

Integration testing · Week 11 (defined), Week 12 (practiced) — 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, Context, container, and component diagrams.

Issue · Week 9 — 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 9 forward, every commit references an issue and every issue references a requirement, which is what makes traceability a habit instead of an archaeology project in Week 15. An issue is not a note to self; a note to self is a note to self.

Iteration · Week 10, Week 12 — A fixed-length build cycle that ends in working software you can demonstrate. This course runs two: Week 10 builds the core vertical slices, Week 12 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.

L

License · Week 5 (the ones you consume), Week 14 (the one you publish) — The legal terms under which software may be used, modified, and redistributed. Two families matter to you: permissive licenses (MIT, Apache-2.0, BSD) generally let you ship with attribution, while copyleft licenses (the GPL family) 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.

M

Milestone · every week; see Appendix C — This course’s weekly deliverable: a named artifact, due at the end of the week, that becomes a part of the final package. Milestones are graded twice: together they carry 25 percent of the course grade, and the Week-16 rubric then awards points for exactly the artifacts they produce, so a skipped milestone costs you once now and again in a week with no time left in it. Milestone numbers match chapter numbers, and there is no Milestone 8: Week 8 is the design review and the midterm checkpoint. Milestone 16 is the final submission, and it is 50 percent of your grade.

Minimum viable scope · Week 2 — The smallest version of your idea that still solves the user’s problem end to end and can be built, tested, documented, and deployed inside roughly 240 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. See also MoSCoW, Feasibility screen, Appendix D.

MoSCoW · Week 3 — 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 that fourth bucket: recording what you will not build is how you defend scope in Week 11 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. If more than roughly half your requirements are Musts, you have not prioritized, you have relabeled.

N

Non-functional requirement (NFR) · Week 4 — 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 “search returns results in under 500 ms at the 95th percentile over a 5,000-item inventory, measured by the timing test in the suite” 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 15. See also Quality attribute, Constraint, Requirements traceability matrix.

Novelty load · Week 5 — This book’s term for how many things in your project are genuinely new to you: a language, a framework, a database, a deployment target, an unfamiliar domain. Novelty is where estimates break, because you cannot estimate work you have never done, and the rule this course enforces is one new thing, chosen deliberately for what it teaches. High novelty load is not ambition; it is unpriced risk. If you insist on two, put both in the risk register with a fallback and buy information with a spike in Week 7. See also Spike, Risk register, Three-point estimate.

O

Onboarding guide · Week 13 — The document at docs/onboarding.md 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. 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. Write it for the version of yourself who has forgotten everything, because in twelve weeks that is precisely who reads it. See also Handoff package, Bus factor.

P

Persona · Week 3 — 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. One or two personas is right at this scale; five means you have not chosen a user, you have hedged. See also Stakeholder, Elicitation.

Priority · Week 3 (requirements), Week 11 (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 semester 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 15 and priority-4 forever afterward. See also Severity vs priority, MoSCoW.

Product owner · Week 1, Week 2 — 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. When you catch yourself adding a feature because it would be fun to build, the product owner has quietly left the room. See also Hat, Charter, Scope creep.

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. 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 6 — This course’s term for 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 behavior 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 4 — 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 13 — 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 semester, and it is not where the architecture goes; keep it operational and put the reasoning in docs/architecture.md. Its acceptance test is the clean-machine test, and there is no partial credit on that test. See also Clean-machine test, Runbook, Onboarding guide.

Reference class · Week 7 — A set of comparable past efforts used to sanity-check an estimate from the outside — “the last three features like this took me nine, fourteen, and eleven hours” — instead of from the inside, where optimism lives rent-free. Your hours log is your reference class, which is exactly why the log starts in Week 1 rather than the week you need it. When your bottom-up estimate and your reference class disagree by a factor of two, the reference class is usually right. See also Three-point estimate, Hours log.

Regression testing · Week 11 — 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 semester. Regression testing is what continuous integration is for. See also Continuous integration, Defect log, Golden set.

Release candidate (RC) · Week 12 — 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 it is not “the last commit before the deadline.” See also Code freeze, Entry and exit criteria, Release tag.

Release tag · Week 14 — 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 itself matters far less than the fact that a grader in Week 16 can check out the tag and receive precisely the artifact you submitted. “Latest on main” is not a deliverable, because main moves. See also Deployment, Change log.

Requirement identifier · Week 3 — The stable label — FR-INV-04, NFR-PERF-01, CON-02 — that lets a requirement be referenced from a test case, an issue, a commit message, a diagram, and the traceability matrix without ambiguity. This course permits exactly one form for functional requirements, the area-scoped FR-<AREA>-<nn>, and NFR-<CATEGORY>-<nn> for non-functional ones; the full table of identifier forms is in Appendix B, and the Week-3 requirements linter parses no other functional-requirement heading. Assign them 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, Requirements traceability matrix.

Requirements traceability matrix (RTM) · Week 4 — A table 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. It is not bureaucratic paperwork at this scale — it is a fifteen-minute artifact that answers the two questions your grader and your Week-15 self will both ask: is it all there, and how do you know? See also Traceability, Requirement identifier, Test case.

Retrospective · Week 16 — The written, honest look backward, filed as docs/retrospective.md: what you would do differently with the same 240 hours, where your estimates were wrong and by how much, which decision you would reverse. It is graded on candor and specificity, not positivity — “I would start testing earlier” is a slogan, while “I logged 41 hours of rework in Weeks 12 and 13 that one Week-9 integration test would have prevented” is a retrospective. You have the evidence: your hours log and your defect log were built for exactly this paragraph.

Risk register · Week 7 — The living table, at docs/risk-register.md, of things that could go wrong, each with a likelihood, an impact, an observable trigger, an owner, 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. Review it weekly and record what actually fired — a register untouched since Week 7 is decoration, and graders can tell. See also Assumption, Dependency, Novelty load, Appendix B.

Runbook · Week 13 — The operations document, docs/runbook.md: how to start, stop, and monitor the system, 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.” If your project has any scheduled job, external dependency, or deployed instance, you need one. See also Handoff package, Graceful degradation.

S

Schedule · Week 7 — The mapping of work packages onto calendar weeks with dependencies, milestones, and buffer, built against the hours you actually have rather than the hours a week theoretically contains. Fifteen hours a week is the budget; the weeks you will lose to other midterms, illness, and holidays are knowable today, so put them on the calendar today. 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, Burn-down.

Scope creep · named Week 2, controlled Week 8 and Week 12 — 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. Creep is specifically the uncontrolled kind, and it is the single most common cause of an unfinished capstone. 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, MoSCoW, Scope cut.

Scope cut · Week 12 — A deliberate, recorded removal of planned work when the hours will not stretch, made early and written into the change log and the specification rather than discovered later by a grader as an unexplained absence. Cutting a Could-have in Week 12 is professional judgment; silently failing to build a Must-have is a failed requirement. The memo matters as much as the cut: what you removed, why, and what it would take to add later. See also Change request, Impact analysis.

Secret · Week 9 — 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 an example file with placeholder values only, and remember that a secret pushed even once lives in the history forever — rotate it, do not merely delete the line. This is the first commit you genuinely cannot take back, which is why Week 9 settles it before there is anything valuable to leak. See also Configuration, Deployment.

Severity · Week 11 — 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 the test plan, before you have any temptation to grade on a curve.

Severity vs priority · Week 11 — The distinction students collapse most often, and the one that 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 semester 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.

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 and agile approaches revisit the same activities many times over, 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. You will perform every activity on this list; the only question is whether you perform it deliberately or by accident at two in the morning.

Software requirements specification (SRS) · Week 3 — 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 and is baselined at the Week 8 review. 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. See also Functional requirement, Non-functional requirement, Baseline.

Spike · Week 7 — A timeboxed investigation whose deliverable is an answer, not a feature: “spend four 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. See also Novelty load, Three-point estimate.

Stakeholder · Week 3 — 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. See also Elicitation, Persona, Constraint.

T

Technical debt · Week 12 — 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. Track it as labeled issues, mention it in the handoff, and never let it be the honest answer to “why is this like this?” in your presentation.

Technical specification · Week 6 — The design document that says how the system will meet its requirements: architecture diagrams at the levels that actually help, module 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 12 — write against that test. It is not the requirements restated in more technical vocabulary, and it is not something generated from the code afterward. It lives in docs/architecture.md and is baselined at the Week 8 design review. See also Software requirements specification, Baseline, Prompt contract.

Test case · Week 11 — 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. See also Acceptance criteria, Requirements traceability matrix.

Test plan · Week 11 — 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, and by whom. 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 · Week 11 (producing evidence), Week 15 (presenting it) — 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 single time. Borrowed from empirical research, this is the discipline that separates “it’s fast” from “it returned in 180 ms at the 95th percentile over 5,000 rows on one machine, untested under concurrency.” Never present a number without the conditions that produced it.

Three-point estimate · Week 7 — 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 is a direct measurement of how much you do not know. A wide spread is a signal to buy information with a spike, not to average and walk away. It does not mean picking the middle number and feeling scientific about it. See also Reference class, Spike, Hours log.

Traceability · Week 4 — 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, issues, test names, diagrams, and documents — not by reconstructing the links in a panic in Week 15. See also Requirements traceability matrix, Requirement identifier.

U

Unit testing · Week 11 — 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 3 — 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. In this course a user story is not a requirement; it is the raw material from which a numbered functional requirement with acceptance criteria gets written. See also Functional requirement, Epic, Acceptance criteria, Elicitation.

V

Velocity · Week 7 — 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. Two weeks of data is not velocity, it is noise — which is one more reason the hours log starts in Week 1. See also Burn-down, Hours log, Schedule.

Vertical slice · Week 10 — One requirement built all the way through every layer — interface, logic, storage, tests, documentation — 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 semester, instead of arriving at Week 14 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. See also Walking skeleton, Iteration, Definition of done.

W

Walking skeleton · Week 9 — A tiny end-to-end implementation that exercises every architectural component and the entire build-and-deploy path: one trivial function traveling from the interface through the logic to storage and back, running in CI, deployed somewhere real. 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. 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, Deployment.

Work breakdown structure (WBS) · Week 7 — A hierarchical decomposition of the project into deliverables and then into work packages small enough to estimate honestly — the practical rule at this scale is nothing larger than about eight hours. 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 the specification is what makes your estimates traceable to something real rather than to a mood. See also Work package, Schedule, Three-point estimate.

Work package · Week 7 — The leaf of the work breakdown structure: the smallest unit you estimate, assign, and track — roughly two to eight hours, small enough to size with confidence and large enough to be worth tracking. Each one names its deliverable, its definition of done, and the requirement identifier it serves. 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, Velocity.

A closing word from Coach

You are not expected to memorize this page. You are expected to reach for it — in Week 3 when you cannot tell a user story from a requirement, in Week 11 when a defect feels severe and you have to decide whether it is urgent, in Week 14 when somebody asks what your bus factor is and you would like to have 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 a teammate 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.

That is what it means to speak a profession’s language. Say the thing, mean the thing, and let the word carry exactly what it claims.

Up next: The templates and worked examples for every artifact named here: Appendix B. The grading contract these terms are graded against: Appendix C. Your workbench, if you have not built it yet: Appendix A. Ideas, if you still need one: Appendix D. Then back to the week you are in — starting with Week 1.