Section 2: Promises You Can Measure - Functional & Non-Functional Requirements

Executive Summary: This section converts Section 1's assumptions into a formal contract: functional requirements that define what the Color Picker Service does, and non-functional requirements that define — in numbers — how well it must do it. We derive the availability target from downtime arithmetic rather than reflex, establish the latency and durability commitments that later sections must honor, and codify the constraints of a one-day delivery window. Every requirement written here becomes a traceable obligation that Sections 3 through 10 will discharge.

The clarification phase is over, and the interviewer leans back: "So what exactly are we committing to build?" This is a different question than it sounds. They are not asking for a feature list — they are asking whether you can write promises that can be measured. "The system should be fast" is decoration; "reads return in under 100 milliseconds at the 95th percentile" is a commitment that a test can verify and an operator can be paged on. At Staff level, the distinction is the entire game: vague requirements produce architectures that cannot be evaluated, and interviewers score the requirement-writing as heavily as the architecture it produces.

The Functional Contract: Three Operations and Their Guardians

The functional surface is deliberately minimal, and each item earns its place:

• Color Selection: A web interface offering HEX color choice. The browser's native color input covers most of the interaction — a one-day budget spends nothing reinventing controls.
• Preference Persistence: Save the chosen color for the authenticated user, replacing any previous value. Overwrite semantics, exactly as agreed in Section 1.
• Preference Retrieval: On any later visit, from any device, the saved color returns. This single requirement is what forces server-side storage — browser localStorage survives a refresh but not a second laptop.
• Input Validation: The server accepts exactly the pattern #RRGGBB and rejects all else. Validation is functional, not cosmetic: an unvalidated "color" field is a free-text field that someone will eventually feed a <script> tag.
• Honest Failure: A user with no saved color receives a clean "no preference yet," never an error; a failed save reports failure and never pretends otherwise.

Key Insight: What you exclude is scored as sharply as what you include. Color history, sharing, team palettes — all plausible, all explicitly out of scope, all deferred to Section 10 with reasons. Saying "out of scope, because—" aloud earns more credit than quietly designing three extra features ever will.