Section 2: Four Promises Every Ballot Keeps - Requirements (Functional & Non-Functional)
Executive Summary: This section turns Section 1's answers into a contract for Northfield College's student election. We number seven functional requirements and walk Alex's vote through them. Then we separate the features from the four invariants that actually define a voting system: only eligible voters, at most one ballot each, no table linking a voter to their ballot, and a tally anyone can reproduce. Finally we set the non-functional targets with v1 numbers (p99 ≤ 1 s, 99.9% availability, results within 15 minutes of close) and defend the one interviewers push on hardest: why an election does not need five nines.
The clarifications are done. The interviewer leans back: "So what are you committing to?" The weak answer, "students can vote securely and see results," is untestable and hides what makes this problem hard. A vote must be checked against who you are and then forget who you are. So the contract has two halves: the features a demo can show, and the invariants a hostile tester would try to break.
The Functional Contract
Seven numbered requirements cover the college election, so Section 4's endpoints and Section 5's tables can trace back to a promise.
| # | Requirement | What it commits us to |
|---|---|---|
| FR1 | Admins define an election | The student election committee creates races, candidates and a voting window (48 hours). Races and the roll freeze once the election is scheduled. |
| FR2 | Import the electoral roll | The registrar's list of enrolled students (8,000) is the only source of eligibility. Nobody self-registers. |
| FR3 | Sign in with college SSO | Identity comes from the college identity provider's token and nothing else. |
| FR4 | See my ballot | Five races: president, vice-president, treasurer (plurality) and two referendum questions (yes/no). |
| FR5 | Cast once, get a tracking code | Submitting is final. The response is a random-looking tracking code that does not reveal the selections. |
| FR6 | Results after close | Counted only after the window closes, published within 15 minutes as a public page. |
| FR7 | Audit and verification | A public bulletin board of tracking codes, plus an audit export: anonymized ballot records, the tally, and the admin action log. |
Now walk Alex through it. On day one at 09:04, Alex signs in with college SSO (FR3). The system finds Alex on the roll the registrar imported (FR2) and shows the five-race ballot the committee defined (FR1, FR4). Alex votes and gets tracking code K7Q-2MF-9XD (FR5). After close, Alex opens the results page (FR6), then searches the bulletin board for K7Q-2MF-9XD and finds it (FR7). The code proves the system received Alex's ballot. It says nothing about how Alex voted, and it can't show that the ballot's content was counted as cast.
Two choices are already hiding in this table, and each has a rejected alternative:
- Identity from SSO, not our own username and password accounts or email magic links. Our own accounts mean storing 8,000 sets of credentials and a second identity that can drift from the registrar's. Magic links make a forwardable mailbox the identity.
- Results only after close. Live counters during voting are rejected. Section 3 makes the full case with numbers.
And one omission is deliberate: Alex cannot change their vote. One ballot, final. The flip trigger is real coercion of remote voters, and Section 10 works through what revoting would cost.
Quick check before moving on:
Sign in to continue reading
The rest of this lesson is available with a free account. Signing in with Google or Microsoft is free.
Sign in to read the full lesson