What are we looking at?
Where do new analysts usually slip, and how do we stop it?
Requirements analysis is one of the most sensitive stages of system design. An error here is like an error in surveying a building: it affects all later design and construction. These are the most common mistakes analysts make early on.
1. Not asking the right questions
A common mistake is that the analyst only writes down what was said and doesn’t dig deeper. The user says, “We want a reporting system,” and the analyst notes exactly that, without asking which reports, in what format, for which audience, from which data source. The remedy is to be curious and precise and to ask open, clarifying questions.
2. Assuming without documenting
Sometimes an analyst unintentionally makes assumptions but neither documents them nor checks them. Like “users will probably work on phones.” That assumption may be wrong and change the whole design. Every assumption must be written down and explicit and reviewed during the project, and it is better to mention it in requirement-review meetings too.
3. Relying only on explicit wishes
Users can’t always, or don’t know how to, say exactly what they want. Many needs are hidden or even contradictory. The analyst must draw the real need out of what is said, and this takes observation, experience, scenario analysis and comparison with similar projects.
4. Ignoring indirect stakeholders
Some analysts talk only to the client or one manager and don’t ask the rest: end users, the technical team, external customers. We should list all stakeholders, take feedback from each group separately and hold multi-layer meetings.
5. Incomplete or vague documentation
If the documents are vague, unstructured or lack examples, the technical team won’t understand properly; the result is rework, disputes and delay. To prevent it, write requirements numbered, grouped and prioritised, use tables, diagrams and visual samples, and set out for each need its goal, source and acceptance criterion.
6. Ignoring change
An analyst must know that requirements change over the course of a project. If they deny it, the project runs into crisis later. From the start we need a mechanism for change management, to version and date the requirements, and to record every change with stakeholder approval.
In sum
I think a good analyst asks more than they write, observes more than they hear, and checks more than they feel sure.