Section 2: Three Customers and One Signature - Requirements (Functional & Non-Functional)
Executive Summary: This section turns Section 1's assumptions into a contract a test could check. We list functional requirements for three actors: the developer, the user, and the platform itself. We state the one invariant that is a law rather than a service level: a device only ever installs bytes the store signed for that app, and an app's signing identity never changes silently. Then a non-functional table puts a number and a reason on every promise. Delivery and purchases get 99.99%, the storefront 99.95% and publishing 99.9%. A rollout must be downloadable within 15 minutes, and a completed purchase is never lost. The tiers differ on purpose.
The interviewer glances at your assumptions. "Fine. What does it have to do, and what does 'working' mean?"
Most candidates give a feature list and stop. The design comes from the second half: which promises are numbers, which are absolute, and which are deliberately loose.
Functional Requirements, by Actor
Section 1 found two customers plus the platform, which has duties of its own.
| Actor | Capability | Demoable sentence |
|---|---|---|
| Developer | Create app, upload bundle | Trailhead Labs owns com.trailhead.maps and uploads one 92 MB bundle for 4.3.0 (versionCode 4300) |
| Developer | Manage listing per locale | Title, description and screenshots in en, pt-PT and hi, each edited independently |
| Developer | Tracks and staged rollout | 4300 goes to internal testing, then production at 1%, about 20,000 of 2 million installs |
| Developer | Halt | One click (or the store's automation) stops 4300 reaching any new device |
| Developer | See stats | Installs and crash rate per versionCode and device model |
| User | Browse, search, view details | Priya searches "hiking maps" in Hindi and sees only apps her Pixel 7 can run |
| User | Install | Her install downloads 38 MB, not 92 MB |
| User | Auto-update | 4210 becomes 4300 overnight on Wi-Fi, a 9 MB download, without opening the store |
| User | Purchase, restore | She buys the ₹399 Offline Maps Pack once, even if she taps twice; on her next phone it is still hers |
| User | Rate and review | One review per account per app, editable |
| Platform | Scan and review | Every submission is scanned; risky ones go to a human |
| Platform | Sign | Every file a device receives is signed with the app's signing key |
| Platform | Take down | Pull an app or release per country or everywhere, within minutes |
"Halt is on your developer list. Isn't that an ops runbook, not a feature?"
You: "It's the feature that justifies staged rollout at all. A rollout you can't stop is just a slow full release. So halt is one status change: the release becomes HALTED, and within 60 seconds the update index offers it to no device. The store can trigger it alone, because a crash spike at 03:00 Lisbon time shouldn't wait for someone to wake up. It is not a rollback: Android doesn't downgrade installed apps, so devices on 4300 keep it, and the fix is 4310 with a higher versionCode. Section 9 builds that loop."
Key Insight: "Auto-update" reads like a client feature, but it is the largest server requirement on the list. Every device must be able to ask "anything new for my 40 apps?" and get a correct, personal answer. Section 3 shows that question and its downloads carry most of the load; Section 8 answers it without any per-device server state.
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