Translate a working demo into explicit service and product requirements.
1. Quality requirements
Define successful task completion, unacceptable errors and user correction behavior. A fluent answer is not a service-level objective.
2. Operational requirements
Set budgets for latency, availability, cost and data retention. State which failures must degrade gracefully and which should block the operation.
3. Architecture boundaries
Separate Android presentation, domain logic, inference adapters and backend policy. This allows independent tests and avoids coupling UI state to provider-specific response objects.
Worked scenario
A document assistant must cite authorized sources and refuse unsupported claims. A generic “answer generated” metric would miss both requirements.
Apply it
Write a one-page requirements document with measurable success and failure conditions.
Check your understanding
Every architecture choice can be traced to a product or operational requirement. Explain the decision and show evidence from your implementation or design. If you cannot demonstrate it yet, revisit the relevant section before continuing.