Functional Requirements

Where Design Starts

Functional requirements (FRs) state what the system does — behaviors a user or another system can trigger and observe. They come first because every component in the final diagram exists to serve one. Skipping straight to architecture produces boxes looking for jobs.

Extraction Method: Actors → Actions → Flows

 STEP 1: name the ACTORS              STEP 2: list each actor's ACTIONS
 ┌───────────────────────┐            rider:   request ride, track trip,
 │ Rider                 │                     pay, rate
 │ Driver                │     ───►    driver: go online, accept, navigate,
 │ Admin/ops (backstage) │            │             complete, earn view
 └───────────────────────┘            admin:  suspend, refund, metrics
 
 STEP 3: order actions into FLOWS
 request → match → pickup → in-trip → dropoff → payment → rating
 every FR attaches to a step of a flow; orphan actions get questioned

Running Example: RideShare Core FRs

This section’s running example — stated once, reused by every later lesson:

#	Requirement	Notes
FR1	Rider requests ride from origin to destination	Includes fare estimate
FR2	System matches request to nearest suitable driver	Sub-second decision
FR3	Both parties see live trip tracking	Driver location stream
FR4	Payment captured on completion; receipt issued	Card on file
FR5	Either party rates the other post-trip	Affects future matching
FR6	Riders view trip history	Read path

Explicit non-goals recorded now prevent drift: no carpooling, no scheduled rides, no driver chat (v1).

Well-Formed vs Poorly-Formed FRs

 POOR: "The app should be fast and handle rides."
 - mixes NFR into FR; untestable; vague scope

 WELL-FORMED: "A rider can request a ride and receive a driver match
 within 30 seconds, or an explicit 'no drivers available' response."
 - single behavior, named actor, observable outcome, failure case defined

The discipline: each FR names one capability, its trigger, and its observable result including the rejection path.

Functional Decomposition Preview

FRs hint at components before any diagramming — each cluster smells like an owning service:

 FR1+FR2  → matching/trip service      (write-heavy, latency-sensitive)
 FR3      → location service           (extremely write-heavy, ephemeral)
 FR4      → payments integration       (correctness-critical, mostly external)
 FR5+FR6  → user/trip-history service  (read-mostly)

That mapping is provisional at this stage — its value is knowing which requirements will fight each other architecturally (location writes vs history reads).

Interview Framing

Requirements take ~5 minutes and set the entire interview’s trajectory. The pattern that scores: enumerate actors fast, list 5–7 core FRs out loud, mark two as “deep-dive candidates,” state explicit non-goals. Interviewers steer here deliberately when candidates rush past requirements — slowing down is the signal they want.