The learner can explain in their own words what an analyst does: the bridge who turns business needs into requirements the team can build, while neither deciding for the business nor writing the code.
What does an analyst actually do?
The analyst as a bridge
Every project has two worlds that speak different languages. On one side sits the business: stakeholders who know what problem they want to solve and what value they want to create, but often cannot describe it in a way engineers can act on. On the other side sits the delivery team: developers, testers, designers who need clear, precise requirements to build the right thing. The analyst lives in the middle — they are the bridge.
The analyst's job can be captured in four verbs: elicit, analyze, document, and validate requirements. Elicit means drawing out what stakeholders truly need (not just what they say they want). Analyze means structuring and clarifying those needs so they are consistent and complete. Document means writing them down in a form the team can use. Validate means confirming with stakeholders that the documented requirements correctly represent their needs.
Two boundaries are critical to understand from day one. First, the analyst does NOT make business decisions for the client. If a stakeholder asks 'should we build feature A or feature B?', that is a business decision — the analyst clarifies the trade-offs, but the business owns the answer. Second, the analyst does NOT write the code. The analyst produces requirements; the delivery team turns those requirements into a working system.
Think of the analyst as a translator and quality-checker of understanding. Without them, business needs get lost in translation, teams build the wrong thing, and expensive rework follows. With them, both sides share a common, verified understanding of what needs to be built and why.
Lesson notes
The analyst as a bridge
Every project has two worlds that speak different languages. On one side sits the business: stakeholders who know what problem they want to solve and what value they want to create, but often cannot describe it in a way engineers can act on. On the other side sits the delivery team: developers, testers, designers who need clear, precise requirements to build the right thing. The analyst lives in the middle — they are the bridge.
The analyst's job can be captured in four verbs: elicit, analyze, document, and validate requirements. Elicit means drawing out what stakeholders truly need (not just what they say they want). Analyze means structuring and clarifying those needs so they are consistent and complete. Document means writing them down in a form the team can use. Validate means confirming with stakeholders that the documented requirements correctly represent their needs.
Two boundaries are critical to understand from day one. First, the analyst does NOT make business decisions for the client. If a stakeholder asks 'should we build feature A or feature B?', that is a business decision — the analyst clarifies the trade-offs, but the business owns the answer. Second, the analyst does NOT write the code. The analyst produces requirements; the delivery team turns those requirements into a working system.
Think of the analyst as a translator and quality-checker of understanding. Without them, business needs get lost in translation, teams build the wrong thing, and expensive rework follows. With them, both sides share a common, verified understanding of what needs to be built and why.