Requirements analysis turns conversations into a shared definition of what a project should build, why it matters, and how stakeholders will confirm that it is right. It separates stakeholders—the people requesting or judging the project—from users, who will use the result. section 8.2
A practical requirements process follows four connected moves:
- Interview stakeholders and users to uncover goals, needs, and the people who will rely most heavily on the result. section 8.2 section 9.3.1
- Find the data required to power the requested features, visuals, filters, controls, parameters, and accessibility needs. section 8.2 section 9.3.1
- Document what is in scope and out of scope, making the requirements specific enough to guide decisions rather than invite guesswork. section 9.3.1
- Get feedback and approval before treating the requirements as a firm foundation; explain openly when later changes affect schedule, cost, or priorities. section 8.2 section 9.3.1
A dashboard request
Suppose a team asks for a productivity dashboard. Interview the main users, identify the data needed, list every intended visual and control, and record what the dashboard will not include. If a new feature appears later, explain its effect on the finish line and bottom line so stakeholders can choose whether to accept it or deprioritize something else. section 9.3.1
Figure 8.1 The research and planning phase consists of four steps: interviewing stakeholders and users, finding the data, documenting the requirements, and getting feedback and approval on those requirements.
Use the four-step diagram to scan the workflow from interviews and data discovery through documented requirements and approval. section 8.2
