Field entry, published 2026-11-03T00:00:00.000Z, updated 2026-11-03T00:00:00.000Z. Group: Digital and technology occupations
How are systems analysts classified in general terms?
| Major group | Major Group 2: Professionals |
|---|---|
| Skill level | 4 |
| Code ladder | General ladder only: major group, then sub-major group, then minor group, then unit group for ICT professionals |
Classification only, not a job decision
This entry explains a classification family in general terms only. It does not classify any reader, and it is not advice about a role.
Systems analysts are classified in general terms with ICT professionals when their main work is studying an organisational problem, defining what a system must do, and designing a system that can meet that need. Their centre is the bridge between a problem in the world and a technical solution for it. They translate needs that are often expressed in business, service, or operational language into requirements, models, and designs that developers and other specialists can build from.
That bridging character is what gives the family its identity. An analyst may spend much of the working week listening, mapping current processes, testing assumptions, and weighing options, rather than writing production code. The output is often a specification, a design, or a recommendation, and its quality depends on understanding both the problem and the technical possibilities. A job that mainly produces such analysis and design belongs in this broad family, even when its holder can code.
What does systems analysis work look like day to day?
Analysis usually starts with inquiry. Analysts examine how work is currently done, where it breaks down, and what a new or changed system must achieve. They may interview users, observe processes, review documents, and gather data about volumes, exceptions, and constraints. This stage matters because a system built on a misunderstood problem will faithfully solve the wrong thing.
From inquiry, analysts move to definition. They set out requirements in a form that can be checked, distinguishing what is essential from what is merely desirable. They may model processes, data flows, and interactions, and they may compare alternative approaches, including changing a process without new technology, adapting an existing system, or building something new. Cost, risk, maintainability, and security can all enter the comparison, even though the analyst is not necessarily the person who will implement the chosen option.
Design follows definition, at least in broad terms. Analysts may design the structure of a system, the way its parts relate, and the way users will interact with it. They may also test a design against requirements, advise during implementation, and help to resolve questions that arise when a design meets reality. Implementation itself, especially writing and testing production software, is neighbouring work rather than the centre of analysis, although the boundary can be close in small teams.
How is analysis different from nearby professional work?
Software development is the closest neighbour, and the two families often share a team, a vocabulary, and sometimes a person. The general contrast is one of emphasis and output. Development centres on creating working software, while analysis centres on defining and designing the system that software will realise. A job that spends most of its defining time on requirements and design sits with analysis in general terms, while a job that spends most of its defining time on building and testing software sits with development.
Business analysis without a technical system at its centre is a different neighbour. Analysts who mainly study markets, finance, or organisational strategy, without designing an information system, are doing business work rather than ICT systems work. The presence of computers in their daily routine does not move them into ICT, because their specialisation is the business field, not the system design. Conversely, an ICT systems analyst who studies a business process does so in order to design a system, and that purpose keeps the work in the ICT family.
Project and programme coordination can also overlap. Coordinating schedules, stakeholders, and delivery is important work, but it is not the same as analysis. A job whose main duties are coordination and delivery management has a different centre, even when it requires a good understanding of systems. Analysis remains defined by inquiry, definition, and design.
Which features point toward the professional level?
Systems analysis at professional level typically requires a broad body of knowledge about systems, data, processes, and the field in which the system will operate. Analysts are expected to exercise judgement when requirements conflict, when information is incomplete, and when a design choice will affect users long after implementation. They may advise decision makers, evaluate proposals from suppliers, and explain technical trade offs in terms that non specialists can use.
That depth is why the family sits at the highest skill level in general terms. Technician work in ICT can involve detailed technical knowledge and careful diagnostic skill, yet its centre is usually installation, operation, maintenance, or user support. Analysis, by contrast, centres on defining and designing systems before they exist or before they are changed. When that defining work dominates a job, the professional systems family is its broad home, whatever title the employer happens to use.
Sources checked
Back to the Digital and technology occupations group or browse all occupations.