Requirements turn a customer’s business objective into questions the project must answer before committing to delivery. Early investigation may be limited: access to customer data, computing resources, and staff time can depend on funding or contracts. Even so, unclear business requirements can misdirect the team and lead to a bid that cannot support the work. Unchecked data, security, privacy, and ethical constraints can also make an ML approach impractical or unacceptable. section 2.0 section 2.3.2
Clarify three kinds of requirements together, revisiting each as the implications become clearer:
- Functional: what the system and model must do, for whom, and with what accuracy, robustness, and reliability. section 2.3.2
- Nonfunctional: execution speed, throughput, latency, and operating costs, including carbon footprint. section 2.3.2
- System: where the model runs, how it is maintained and integrated, how its results are consumed, and what continuity measures are needed. section 2.3.2
Start by listening to the client or sponsor, even if the request is high-level or not yet technically achievable. Use clarification and reflection rather than treating requirements as a fixed, one-pass specification. Pin down specific needs and the consequences of meeting them in a particular way. section 2.3.2
Test a performance request against its setting
A large general model may not run as quickly as desired for many users on an old, slow processor. Establish the speed, user load, and hardware constraints before assuming optimization will be affordable. section 2.3.2
Figure 2.1 The Bike Shop organizational chart. Dots represent stakeholders and users, the touchpoints for the project.
Use the organizational chart to identify stakeholder and user touchpoints when asking who the system must serve. section 2.3.2
