What are we looking at?
Before designing any system, why must we be sure we’ve understood the need properly?
Why is this stage so key?
In designing any successful system, nothing is as vital as “a correct understanding of needs.” If we don’t know exactly what the user or stakeholder wants or what problem they have, how can we design a solution? That is why “gathering and analysing requirements” is the first and most important step of systems analysis.
A system means a set of components and processes designed for a specific purpose, but if that purpose or need isn’t properly defined, the whole system may head the wrong way. So before any design, even before choosing technology, we have to be sure who will use the system, what needs they have, and whether those needs are clear and measurable. If needs aren’t drawn out properly, the chance of project failure, even with the best technical team, is very high.
Two situations
In practice we meet two cases.
The user knows what they want. They state their wish with fairly good clarity, for example, “We want a system that automatically produces staff monthly performance reports.” Here the analyst’s focus is on checking feasibility, prioritising, and translating the wish into technical need.
The user doesn’t know what they want. They only feel “something has to be fixed” but don’t know exactly what; for example, they say, “Our customer follow-up is really chaotic…” Here the analyst’s role stands out. They must find the real problem through interviews, observation, data analysis and process review, and state it in an understandable language.
The analyst’s role
A systems analyst works a bit like an organisational psychologist. They are an active listener, one who hears the concerns and wishes of different stakeholders carefully, asks key questions (what isn’t working? why? how can it be better?), and discovers and translates needs, that is, turns vagueness into a precise need that can be implemented. In many projects the quality of this early analysis decides whether the project succeeds or later faces costly redesign.
In sum
I think gathering and analysing requirements means “finding a common language between the problem and the solution.” Until that common language forms, no analysis is complete. This stage isn’t only the start of the path of system design; it is the foundation on which the whole architecture of the system is built.