Describe the problem through a real situation
Many projects begin with a feature list: a dashboard, an application, a report or a customer portal. That list helps start a conversation, but it does not yet explain the problem. Walk through a real working day instead: who is waiting for information, which task is repeated, and where is a decision made without the necessary context? These examples separate the need from an initial idea of the solution.
Take boundaries as seriously as features
Scope includes more than what will be built. Identify which system supplies each piece of data, who owns each integration, what is excluded from the first stage and which decisions depend on the client. Even a simple map of these boundaries makes estimates more understandable and provides a shared basis for evaluating changes.
Connect acceptance to observable behaviour
“Fast and professional” is not a sufficient acceptance criterion. A useful scenario identifies the user’s role, the information entered, the expected result and what happens when something goes wrong. Writing these behaviours before implementation moves quality discussions beyond preference and makes testing part of the problem definition.
Analysis should lead to decisions
The purpose of analysis is not to produce documents for their own sake. It should clarify the first delivery stage, responsibilities, dependencies and acceptance criteria. The right decision may be bespoke software, an integration between existing tools or a process improvement before automation. A project starts well when the team knows what it is building, for whom and how success will be recognised.