Requirements analysis turns a customer’s business objectives into a testable account of what an ML system must do and whether it is practical to deliver. Start by listening to the sponsor, even when the request is high-level or technically imprecise. Clarify and revisit the requirements rather than trying to settle them all in a fixed order: performance targets, deployment constraints, and the intended business use affect one another. section 2.3.2
Capture three kinds of requirement:
- Functional: who the system serves, its inputs and outputs, the task its model performs, and the accuracy, robustness, and reliability needed. section 2.3.2 section 3.1
- Nonfunctional: limits on latency, throughput, execution cost, and carbon footprint. Check these early; an ambitious model may not meet a fast response target on constrained hardware at an acceptable cost. section 2.3.2
- System: where the model will run, how it will be maintained and integrated, how people or systems will consume its results, and what resilience is required. section 2.3.2
Make a recommendation request testable
A functional requirement can state that a user profile, budget, and date must produce a set of book recommendations. Nonfunctional requirements can then require each recommendation to cost less than $0.0001 and arrive in under 200 ms. The output alone does not establish whether the proposed system is viable. section 3.1
Turn the analysis into a list of business opportunities and delivery challenges. Recheck that list against findings about data, project setup, and security; remove or revise concepts that prove impractical. For viable concepts, draft system stories describing delivery and user stories covering sponsors, users, customers, and affected people. Use the stories to test whether implementation and business impact have plausible paths, and to identify possible acceptance criteria, harms, and corner cases. Detailed stories can wait until the project has funding and resources. section 3.1
