How IT analysis undersells itself and why that’s bad for everyone

What does an analyst do in an IT project? Whilst the tasks of other IT roles are clearly defined (developers, project managers, testers), the description of an IT analyst is relatively vague. But it’s not a new field – ever since there’s been software, it has been analyzed before programming started. About 35 years ago, the position was described like this[1]:

The job position of system analyst – as the job was then called – is responsible for the following tasks:

• Determining the needs of new information systems or of changes to existing information systems.
• Analysis of the current state of existing systems.
• Development of proposed solutions and target concepts for new information systems.

Creating and documenting requirements…

These days, people don’t speak much of “system analysis”. In many areas, the job title “requirements engineer” has spread. Normally, if you ask what a requirements engineer does, you will get an answer like this: Finding and documenting requirements.

A quick look at the documents that define the quasi-standard of the profession of requirements engineering seems to confirm this statement:

In the curriculum for the certification exam for CPRE (certified professional for requirements engineering) from the international requirements engineering board (IREB), the following tasks are defined for a requirements engineer[2]:

• Elicit requirements
• Document requirements
• Verify and confirm requirements
• Manage requirements

The second authoritative standard for IT analysis is the business analysis body of knowledge (BABOK) by the international institute of business analysis (IIBA)[3]. This is structured in “knowledge areas”. Three of the six knowledge areas are about recording and managing requirements.

This source summarizes the task of an IT analyst as eliciting and clearly recording requirements.

…or designing solutions

When the work of an analyst is considered practically, a completely different picture emerges. It goes beyond finding and writing requirements – there are far more aspects to consider. Models are designed, data models on one page and process models on the other. Interfaces are discussed – mainly the user interfaces – the dialogs where data is entered and shown. All these activities can’t really be described as requirements management. Rather, they describe exactly what the partial task “development of solution proposals and concepts for new information systems” describes. A better definition of these activities than “requirements management” is “solution design”.

This also fits well with the model that Bitkom, Germany’s digital association, describes on their website www.erlebe-it.de (link in German). There, the different job descriptions that exist in IT environments are summarized in three groups:

• Software engineer: These are the people who know and understand technology; who have mastered programming languages and other tools that are needed to develop an IT system.
• Software designer: Determines which user needs are fulfilled and enable users to work efficiently. They are creative people from the real world who plan and design the future of software.
• Software manager: Even IT projects have to get by with limited resources. The manager makes sure that the available resources (time, budget) are dealt with efficiently.

It’s obvious which group IT analysis is allocated to: software design. Without this activity, an IT system will never achieve its tasks – or to put it another way: its requirements.

Two paradigms

“Requirements management” and “solution design” are two theoretical views of IT analysis – and as we find it in practice. But even here, black and white thinking is inappropriate: these approaches are not completely separate from each other. Despite the emphasis on requirements engineering and documentation, the CPRE curriculum also contains many methods and tools that are necessary for solution design. This also applies to the BABOK, which also introduces many of these methods and tools in the chapter “Techniques”. Examples of these are:

• Data modelling
• Process modelling
• Prototyping
• Etc.

These methods can’t be described by “recording and documenting” requirements. Here, you have to reflect, experiment, fail here and there, start again, be creative – everything that analysis does, basically. On the other hand, the practical needs of the professional field can’t be ignored in a procedure that puts solution design front and center. Here, you might speak less of requirements and traceability. Professional needs immediately flow into the solution design – the solution is front and center. “Requirements management” or “solution design” – in the end, the differences aren’t that big.

The outward picture

Under all the different tasks that an IT analyst does, one section is prioritized: creation and documentation of requirements. The other tasks are subordinated: IT analysts are identified with “documentation and elicitation of requirements” – as suggested by both the “four main activities of requirements engineering” and the BABOK knowledge areas.

This means that we tend to carry out more complex and skilled tasks than we would say of ourselves. The design of technical data models, analysis of re-organized processes, the definition of interfaces – either with users or with other systems. All of this is far more demanding than the description “finding and documenting requirements” would imply. To put it in other words: We are underselling ourselves. For many non-insiders, an IT analyst is just a scribe: we ask someone what they need and then write it down. That’s it.

Bad for IT analysts…

As mentioned above, that is a limited view of things. But that’s the impression that an outsider gets of requirements engineering. Of course, this is bad for IT analysts themselves, who carry out skilled tasks, such as designing software systems, but aren’t recognized for it, because it is seen as less skilled work. “Documenting requirements” – it’s not ludicrous that a manager should put this task on the stakeholders so as to save the money on this position. The stakeholders must know what they want – and documenting requirements can’t be that hard.

…and bad for the project, too.

It’s not just about the analysts’ feelings. If an activity is no longer required, then that is so. This has happened to a lot of professions in the past and will happen to many more in the future. We have to live with that.

The problem is that the task of solution design in an IT project is necessary. And if this is not taken seriously by IT analysis, then there is often no one who feels responsible for this. Not many projects have solutions engineers, who are sometimes described as responsible for this and who make requirements into solutions. And even when projects do have them, sharing the work between requirements engineering and solution drafts is not useful. Most requirements can only be understood in one solution context. Requirements and solutions have to be related to each other and consecutively designed.

Developers, on the other hand, are normally burdened with the technical aspect of an IT solution and they don’t have the capacity to take over the professional solution development or to lead the dissections and agreements necessary for this task. The suppression of IT analysts in the role of requirement recording clerks leads to gaps in IT projects. Luckily, many IT analysts take the role of solution designer very seriously despite the theoretical side. Requirements engineering without solution design cannot be successful.

Summary and plea

Collect and document requirements – this is the basic idea of what an IT analyst does. But this definition ignores the actual work that many analyst do – which is designing solutions. Working with requirements is a part of this, nothing more and nothing less. But creatively finding and modelling solutions is the actual work of analysts. Let’s stop limiting ourselves to the task of recording clerk – instead, let’s talk about what we actually do. It’s for our own wellbeing, and that of our projects.

[1] H.R.Hansen: Wirtschaftsinformatik I, Stuttgart 1983
[2] https://www.ireb.org/en/cpre/
[3] International Institute of Business Analysis, A Guide to the Business Analysis Body of Knowledge, Toronto 2015