Guest Post by

IT Analysis 2016 – Taking Stock

It’s not easy being an IT analyst, especially if it is your ambition to be the best in your profession. Many IT analysis concepts on the market today claim to support you in doing so — there are complimentary concepts, conflicting and even contradictory ones. New ones are constantly appearing too. Keeping track of all of them is no easy endeavor. So let’s take a moment to take stock of the situation.

One task—many concepts

First and foremost, we have good ol’ requirements engineering. It has spread across the world thanks to the efforts of the IREB (International Requirements Engineering Board) of Germany, it has become a standard. Even though business analysis, defined by the IIBA (International Institute of Business Analysis), emerged around the same time, it only became known in Europe in the last few months. There has been much discussion about the relationship between the two concepts. Are both even relevant for the IT world? Do they complement each other? Is their content perhaps the same?

IT analysts can’t get around having to think about agile software development methods. Only in their purist form is the necessity of the analysis even called into question. But even if you don’t go that far, what does “agile” even mean to an IT analyst? How does it change her processes? To put it simply, is it enough to draw an arrow stretching from the end to the beginning of a process in the various models in order to express iterative processes? Or are the changes perhaps deeper?

Newer concepts would include design thinking or, even more recently, hybrid thinking. Will they actually, as many have speculated, eventually replace requirements engineering. We have seen developments like the changing “Swiss Requirements Day” to “upfront thinking”. Could this be the genesis of a new paradigm?

IT Analysis 2016 Taking Stock

IT Analysis 2016 – Taking Stock

IT-Analysis Unplugged

Indeed it is not easy to keep track of it all and to choose the right concept. It is helpful then to take a step back and to ask the question: What is actually the core of the task? What if you forgot about all the methods, techniques, processes and all the terms associated with them? What is an IT analyst’s essential job? If you reduce the task to its bare bones, an IT analyst creates a plan, a blueprint for software that will eventually be implemented by software developers. What I am calling a blueprint is called “design” by the “Business Analysis Body of Knowledge”.

What is necessary to create a blueprint like this plain old common sense. All of the concepts and approaches mentioned above are expendable. Believe it or not, successful projects have been launched without having explicitly used them.

Now before the shouts of protest by readers become too loud let me categorically state that each of the concepts mentioned are useful to IT analysts and make it easier to create a blueprint, and improve its quality. I would however like to say the following about individual approaches.

Requirements engineering: in order for the software to fulfill its purpose, the blueprint will need to take the requirements of various stakeholders into consideration. Only once the requirements have been fulfilled, can the software add value. Drawing our attention to this fact is requirements engineering’s greatest achievement.

But—and this needs to be said—the analyst’s job is not restricted to finding, documenting and administering requirements. Analysis is a creative process, it is responsible for the designing the solution. By definition requirements engineering does not concern itself with designing the solution—it aims to be “neutral” when it comes to solutions.

Business Analysis: in version 3 of the Business Analysis Body of Knowledge (BABOK Guide) designing the solution is overrated. In many of the “knowledge areas” design gets explicitly mentioned, often in the same breath with requirements. The BABOK guide says very little about the designing requirements.

Agile approaches: they have definitely brought about improvements in the software development process. They allow us to react quickly to changes. What does this mean for the way we create the “blueprint?” You cannot skip creating this blueprint in the beginning. But this during the blueprint creation process it is impossible for everyone to know all the details and ramifications that it will have. Instead it provides the broad building blocks of the entire system as well as their relationship to each other. The details follow just before the implementation processes.

Other approaches comprise the other parts of the IT analysis. As I mentioned, IT analysis is a creative discipline. Design thinking or hybrid thinking can demand the necessary creativity for it. UX (user experience) and HCD (Human Centered Design) help to create user-friendly interfaces for the user.

IT-Analysis in Practice – System Analysis 3.0

So what should the IT-analyst do in the face of all these possibilities? Generally she carries out her tasks with great pragmatism and common sense: creating the blueprint for the software under development. In most cases many of the ideas in the above described concepts are applied. One uses:

  • Requirements engineering—but with the emphasis on creating solution designs
  • Business analysis—adapted to the needs of the IT task
  • Agile approaches—but with the right amount of “upfront thinking”
  • Other different methods and techniques—wherever it makes sense and contributes to creating the blueprint.

We would like to present the pragmatic and solution oriented approach that we have been using for years. We have called it “system analysis 3.0”. For clarity’s sake let’s delineate what system analysis 3.0 is not:

  • System analysis 3.0 is no alternative to requirements engineering and business analysis and
  • System analysis 3.0 cannot replace other agile software development methods like scrum, Kanban etc.

System 3.0 can be seen as applied requirements engineering and applied business analysis in IT projects. The design of the solution is the focus. In other words, the important thing is a good solution, not good requirements. Or to put it even more crudely: We want solution engineering, not requirements engineering. In this context requirements are seen for what they are: very important “raw materials” for designing solutions. Nothing more, nothing less.

Concentrating on the solution is of great importance when it comes to agility. The quality of the solution is the focus—and not the requirements. Requirements are neither good nor bad—they simply are. All the contradictions, the incomplete information, all the deficiencies are addressed with the purpose of designing the solution in cooperation with the stakeholders.

System analysis 3.0—how does it work?

The basic idea behind system analysis 3.0 is to put the solution at the center from the very beginning. As soon as some information about the tasks is available a “solution hypothesis” is created. This is an initial design, the first assumption about the solution. It generally is not very detailed—a few sketches and comments are enough. The solution hypothesis is the foundation on which the analysts create other activities which form the basis for discussions with stakeholders.

The analyst knows that this solution hypothesis is not the final solution. She still needs to test its falsifiability. The solution hypothesis will continue to be developed as more information comes to light as well as in response to requirements. Once that happens it needs to be re-cast and re-imagined.The actions which the analyst carries out from the idea phase through to the final solution can be divided into three groups.

Analysis: To state that an analyst analyzes might seem trivial but it is important to mention. This activity is not explicitly outlined in requirements engineering and business analysis. By analysis I mean dissection, breaking the topic down into bite-sized chunks. Representing these units is beyond the scope of this article. The relationship between the units forms a system, and this system is the solution design.

Communication: “Communication” referred to as “raising requirements” in requirements engineering. The difference in relationships is no coincidence. It is meant to express that speaking to stakeholders is a matter of “give and take”. It is not enough to go to stakeholders and ask what their requirements are. The analyst also needs to speak to advisors and make suggestions. The solution hypothesis is the foundation for the suggestions.

Production: The result of the analysis is mental, not physical. But it still, for practicality’s sake, needs to manifest itself in material artefacts. Only then can it be evaluated by stakeholders and implemented by developers.
Creating these artefacts requires work—often very hard work. As such it restricts flexibility. Everyone, including analysts, would think very carefully about changing anything that would jeopardize their hours’ and even days’ worth of work.

That is why system analysis 3.0 recommends holding off on producing these artefacts until the solution hypothesis is more stable.


System analysis 3.0 is the result of many years of practical experience in business analysis and requirements engineering in the agile IT world.

Josef Falk is an IT analyst at SEQIS GmbH. After completing his business degree in Vienna he started working on creating IT systems, first as a developer and later as an analyst. Over the years he has seen all kinds of trends and fads come and go. He has combined all these years’ experience with his deep understanding of IREB and IIBA standards to create “System Analysis 3.0”.

Tags: ,
0 replies

This discussion is missing your voice.

Leave a Reply

Your email address will not be published. Required fields are marked *