System Analysis 3.0
Introduction and purpose
What kind of actions have to be carried out before programming starts in a software development project? Commonly two groups of activities are mentioned in this context: First, raising the requirements and then, designing the solution. ‚First … then …‘ – that sounds like waterfall. Indeed, this procedure does not offer the flexibility needed by modern agile practices.
This article presents a methodology called System Analysis 3.0 which aims to overcome the barriers between eliciting requirements and designing solutions. The analyst is working on a solution from the very first moment using requirements as a resource.
Agile needs a holistic view
A lot of tasks have to be completed in a software development project. This fact is shown by a wide range of job titles: There are developers, data analysts, process analysts, requirements engineers, business analysts, project managers and many more of them. On the other hand, agile methods in software engineering know a much smaller number of roles. E.g., in Scrum there are just three roles: the Scrum Master, the Scrum Product Owner and the Development Team . The tasks have to be distributed among just a few roles.
So, with regard to analysis in software engineering, in agile projects ist is not advisable that one group of persons is just eliciting and managing requirements and the other group is designing a solution on that base. Understanding the problem, elicitation of requirements, and finding a solution have to go hand in hand in agile projects. Only in this way can the needed flexibility be ensured.
System Analysis 3.0 is a process model that overcomes the barriers between finding requirements and designing the solution. For that reason, it is particularly suitable for agile projects, but it is not limited to them.
About the name „System Analysis 3.0“
Why do we call this kind of process model „System Analysis 3.0“?
- Let us start with the term „Analysis“. Analysis means „decomposition“. A problem or an area of expertixe is decomposed into smaller components. So it can be better understood
- The word „System“ means that the subject matters an not a more or less big number of isolated requirements. The goal of the analyst ist to build a system. The components are in relationship to each other. The analyst has to describe the components and relationships between them – and this is called a system. That means the analyst analyzes (and designs) system, so he (in this article, „he“ is used to indicate the person – he or she – being discussed) is a System Analyst.
- And what about the version number 3.0? In IT-projects there has always been analysis in the sense of upfront thinking and planning what should be implemented subsequently. and there have been certain supporting methods. For a long time this activity was called System Analyses – in our way of thinking it was version 1.0. Later – about 10 or 12 years ago – standards have been developed by organizations like the International Requirements Board (IREB®)  and the International Institute of Business Analysis (IIBA®) . This may be considered version 2.0 of System Analysis.
The concepts and ideas of Business Analysis and Requirements Engineering are combined into one process model that integrates the requirements and designing the solution seamlessly. We call this process model System Analysis 3.0.
The Basic Idea
Designing is not only part of the IT analyst’s job, the solution design is the ultimate goal of his work. Consequently, solution design is central to System Analysis 3.0. Finally, the analyst has to deliver the design of a system – and not just a well-organized list of requirements. The basic idea of System Analysis 3.0 is that producing this design is not divided into two steps: first raising the requirements and then finding the solution based on these requirements. Rather, the solution is central from the beginning. As soon as there is some basic information about the relevant business domain, the analyst formulates a solution hypothesis. He may or may not present this preliminary design to the stakeholders. In each case it serves as a basis for the analyst’s future work with the stakeholders.
In the process of System Analysis 3.0 this solution hypothesis is refined step by step, so that in the end there is the final solution that can be described in system analysis artifacts.
In order to evolve a final solution design from a preliminary solution hypothesis, the system analyst has to carry out three basic activities:
These three tasks are not performed in a strict chronological order. However they stand in mutual relationship to each other. This relationship may be called the „Micro-Process of System Analysis“. In turn several Micro-Processes are forming the „Macro Process of System Analysis“.
It is obvious that analyzing is a main task in System Analysis. Nevertheless it is necessary to emphasize this fact. Sometime the impression is given, that gathering and organizing the requirements is sufficient to find a solution.
In any IT project the solution is a system consisting of elements and their relationships. Finding out these elements and forming them to a system is the task of the main element „Analyzing“.
But what does analyzing actually mean? What does an analyst do when he analyzes?
- Literally „to analyze“ means to decompose a thing into its parts. When we analyze a problem or a business domain, we decompose it into its parts. These parts are small enough that they can be totally understood.
- To be able to do this decomposition, first of all the analyst mainly needs one thing: information. This information is necessary to find out the essence of the business domain. How does this domain work? What are its aims? What are the general conditions? These are the questions to be answered.
- Finally the elements of the domain have to be re-assembled in a new way – and that is the design of the solution.
Analyzing means decomposition. But what are the parts into those the business domain is decomposed?
In IT-analysis we have to deal with two different topics:
- The world of data describes the information that is processed and stored (static view).
- The world of functions describes the activities and algorithms that are producing and processing data (dynamic view).
It was the aim of object-oriented analysis, which was quite popular some time ago, to unite these two topics one single concept. Data is divided into classes that include the functions in the form of methods. The separation between data and functions would have been eliminated. But in analysis – unlike in the area of programming languages – the object-oriented concept did not become the rule.
For that reason in our further consideration we will presume a separation between data analysis and functional analysis. In each of the both areas we will define a „Primary Analysis-Object“. This is the object central to the analysis considerations, the element that forms the whole system – even if a more detailed analysis is possible (and usually necessary).
The Primary Data-Analysis-Object
There are many „things“ in every business domain, we are working in as a system analyst. „Things“ – that has to be interpreted in the widest possible sense. Of course, „things“ can also be persons. Those things are often material, but can be immaterial as well, e.g. a journey or another service. They can even be abstract, something that does not exist in reality.
As these „things“ are not always real things, we will call them „objects“. And as we are interested in the information about these objects we call them „Information Objects“.
Figure 1: From „Things“ to Information Objects
It is the task of the system analyst to find out these Information Objects – to decompose the business domain into these Information Objects. The Primary Data-Analysis-Objects are the Information Objects.
The Primary Function-Analysis-Object
In a business domain to be analyzed there are a lot of activities and tasks to do. Analyzing means to put things in order in this unsorted set of activities. There are various possibilities to do so. One of the most common ways ist to arrange the activities in processes. A process defines the order in which activities (= process steps) are carried out, which of them can be performed in parallel. Processes can be branched and reunited.
A means of finding out the processes in a system that has become quite popular is the „Use Case“. A „Use Case“ is a system’s answer to an external event. Examples for Use Cases are: „To borrow a book“, „to withdraw money“, or „to check an account balance“. Use Cases and processes are in relationship to each other but they are not identical. A Use Case represents the behavior of a system in the external view, while process show the internal view consisting of single process steps and their relationship to each other. A Use Case is detailed by the description of a process.
The main focus of the analyst is the single process step. One process step may be an action that occurs in several processes. Therefore this action – the process step – is our Primary Funktion-Analysis-Object. This action can include several sub-actions. It is the challenge for the analyst to differentiate the actions from one another, so that compact units are formed.
In System Analysis 3.0 we call these actions (or process steps) „transactions“. In software engineering transactions are activities that are carried out completely or not at all. In analysis we define this term in a similar manner. A „transaction“ is a business function that – normally – is carried out as a whole.
So, transactions are the elements that build our processes, they are our Primary Function-Analysis-Object.
Figure 2: From Activities to Transactions
Data and Functions – united
Although analysis of data and analysis of function can be separated to a certain degree, we desire one system that comprises data and functions.
The joint model of data and functions is the design of the solution.
One technique that checks if data model and function model are complete and consistent is the so called CRUD-Matrix. CRUD stands for the basic transactions „Create“, „Read“, „Update“, and „Delete“. This matrix gives not only a good overview over the „Primary Analysis-Objects“. Furthermore it delivers an opportunity to check, if there are still gaps between data analyis and function analysis.
Previously we have shown a business domain is decomposed into its elements and how these elements are used to build a new system – the solution design. But this system does not end in itself. this system must solve a problem or it must create value for the organization for which it is developed.
If the analyst is not an expert in the business domain himself, he must acquire knowledge about it. Usually there are several sources for that knowledge. One of these sources is people: the persons already working in this area, experts, end users, and others. Usually, we call these people stakeholders . To gain this knowledge he must primarily do one thing: talk to them. Or to use a more business-like word: communicate.
A special kind of knowledge are requirements. Requirements are essential characteristics of the future solution formulated by the stakeholders. Perhaps these requirements are the most important information about the future solution for the analyst .
Figure 3 shows the communication model of System Analysis 3.0. This model shows the following: Every time an analyst communicates with a stakeholder, he has already some idea of the solution. In early stages this will be a rather vague idea. The more information the analyst already has about the domain or the problem to solve, the more tangible this idea will be.
We call this idea the „solution hypothesis“. Sometimes the analyst will present his solution hypothesis when he is communicating with a stakeholder, sometimes he will not. But the solution hypothesis is always in the analyst’s mind and influences the questions the analyst asks to the stakeholders.
Figure 3: The Communication Model in System Analysis 3.0
The purpose of communication is to gain information. This information can be divided into three types:
- General information about the business domain: In this way the analyst can deepen his knowledge about the business domain.
- Requirements: there are fluid boundaries between general information and requirements. In any case it is the analyst’s responsibility to consider whether and how this information will be part of his solution design.
- Feedback on the current solution hypothesis: if the analyst presents his ideas to the stakeholder, he will usually get answers. He will get confirmation in some points, in other points he will have to change his hypothesis.
The analyst returns with a pack of information from every communication event that has to be processed. This processing is nothing else than analyzing. We remember: Analyzing means decomposition, finding the Primary Analysis Objects and the relationships between them. The result is a modification of the solution hypothesis. Sometimes the solution hypothesis has to be discarded entirely because of the gained information and a new hypothesis has to be found.
There are many different ways how communication can happen – oral, written and other types. A description of these types would be beyond the scope of this article.
Solution design is an immaterial thing that first only exists in the analyst’s mind. In order to be effective, the design must be transmitted to several groups of persons. These persons can be summarized into two groups: those stakeholders that have to decide whether the suggested design will meet the business need on the one side. And the persons who will build the software on the other side.
To transmit his design to these groups the analyst has to produce analysis artifacts. There are basically two types of artifacts :
- Text in natural language
- Model based artifacts.
Each of the types has its advantages and disadvantages. So in most cases a mix of both types is the most suitable approach. The content of the artifacts must describe the system of the solution design in its both dimensions: data and functions. So, with regard to model-based documentation there are two main types of models that are needed in nearly every initiative:
- Data models: several modeling languages are available to express the Primary Data-Analysis-Objects and their relationships. For a long time Entity-Relationship-Modeling was the most important way to document data models. Today the class models of UML (Unified Modeling Language) are the preferred way to describe data models.
- Process models: for documenting the functional system there are several ways as well. A common way to do so are the Activity Diagrams of UML.
These two types of models will exist in nearly every IT-project. In addition, there are many other ways to describe the solution design, e.g.:
- Mockups: if a dialog-system is to be built, it is helpful for the stakeholders to have an idea, how the future system will look like. Screen mockups (or wireframes) allow the analyst to outline the screen designs.
- State diagrams: in cases where the elements of the designed system go through several states a state (transition) diagram can bring more clearness.
- Sequence diagrams: this kind of model shows how processes operate with one another and in what order.
Case by case other forms of models can be helpful for documenting the solution design.
The Micro-Process of System Analysis
Above we have identified three main elements of System Analysis 3.0 – Analyzing, Communicating, and Producing. Now we are going to see how these three elements are put together to one process, in which information and requirements are gathered and seamlessly the solution design evolves.
Figure 4 depicts this process. We see that „Analyzing“ is not only the main activity, it is the first activity as well. The analyst never starts from zero. There is always a certain amount of information at the beginning. Maybe the analyst has worked on a similar task in the past, maybe he knows the regarding organization as a customer, maybe he has got some theoretical knowledge of the business domain. At least he knows the heading of the task to be fulfilled.
With that basic information a picture of the solution design will form in the analyst’s mind. This will happen in either way. The difference between other methodologies and System Analysis 3.0 ist, that the former „forbid“ to think about the solution as long as requirements are not yet raised, whilst System Analysis 3.0 encourages the analyst to accept the involuntarily emerging ideas and to work with them. We call this preliminary idea about the solution design the „solution hypothesis“.
The analyst must not hold on this first idea about the solution. Quite the contrary, he must aim to find reasons, why this solution design needs to be changed. Where can he find such reasons? We distinguish two possible sources:
- General information like textbooks on the regarding domain, articles in newspapers, other publications
- Information that can be achieved form persons already knowing the business domain. Some of this information we call requirements.
Figure 4: The Micro-Process of System Analysis 3.0
First of all, the analyst must look for information that helps him to create a better solution design than the current solution hypothesis. More information changes (hopefully improves) the solution hypothesis. Getting this information is not a one-way-process. Communicating with the stakeholders is based on give and take. What an analyst can give to the stakeholder is his current idea about the solution design – the current solution hypothesis. Sometimes – especially in later stages of the analysis process – this can be a formal presentation. In earlier stages this giving may be expressed just in the form of the questions the analyst asks. This gives the stakeholder the opportunity to agree – or to disagree – with the analyst and the analyst can modify his design accordingly.
This cycle, solution hypothesis – communicating – analyzing, will be executed for a certain period. In that period the solution design will improve continuously and, thus, will meet the business need better and better.
But when will this cycle stop? There is no unambiguous answer to this question. Each iteration more will improve quality of the solution. But these improvements become smaller and so time will come, when the cost of one iteration more exceeds the benefit. And this is the time when the cycle should be stopped. It is one of the challenges for an analyst to see when this moment has come.
However this analysis cycle can also be stopped earlier, e.g. when there ist some time or cost pressure. It is one of the major advantages of System Analysis 3.0 that the analysis process can be stopped at any moment – and there will be a solution design. It may not be the best possible solution, but there will be a design that can be implemented.
The Macro-Process of System Analysis
Sometimes a single Micro-Process of System Analysis is sufficient in an IT initiative. This might be the case in a rather small project or a strict waterfall model is used. In all other cases there will be some or many of such Micro-Processes. Together, these Micro-Processes combine to the Macro-Process of System Analysis as shown in figure 5.
Figure 5: The Macro-Process of System Analysis 3.0
The Macro-Process of System Analysis is composed of a series of Analyzing-Communicating-Producing-blocks, i. e. of Micro-Processes of System Analysis. Number and structure of these blocks depend on the organization of the development process. The process shown in figure 5 could be a typical agile process. After one block for obtaining overview over the whole initiative there is a series of smaller blocks representing the iterative approach in an agile project. In the case of a Scrum process these blocks would correspond to the sprints.
Before the first Micro-Process can be started some preparation activities are necessary. For these activities an own phase simply called „Start“ is provided. The following activities are carried out in this „Start“-phase:
- Definition of goals: What shall be reached with the current initiative?
- Definition of initial scope: What are the borders of the project? What is inside and what is outside? This limitation can change during the works on the project. It is, however, a directive for the analyst.
- A first definition of existing stakeholder: This list of persons affected by the initiative can change as well. Over the course of time the analyst will find more persons and groups of persons that are interested in the project and that are affected by it.
- Definition of the planned approach: What are planned milestones, which artifacts are to be produced, and many more questions to provide an effective approach.
With System Analysis 3.0 we propose a methodology for analysis in IT-initiatives that is characterized by the following features:
- It is the goal of an IT-analyst to find and create a solution design.
- The solution design has three resources: knowledge, requirements, and ideas.
- Requirements do not fully describe the solution design.
- The analyst starts with an idea of the solution design: the solution hypothesis.
- The first solution hypothesis evolves to the final solution design by proceeding three activities: Analyzing, Communication, Producing.
References and Literature
 Business Analysis Body of Knowledge, Version 3.0, IIBA, 2015
 Gerstbach Ingrid, Peter: Basiswissen Business Analyse, Redline 2015
 Heap Tony: There’s no such thing as a requirement; http://www.its-all-design.com/theres-no-such-thing-as-a-requirement/
 Hruschka Peter: Business Analyse und Requirements Engineering, Hanser 2014
 International Scrum Institute; http://www.scrum-institute.org/Scrum_Roles_The_Scrum_Team.php
 International Institute of Business Analysis; http://www.iiba.org
 International Requirements Engineering Board; http://www.ireb.org
 Konnerth Tina: Der kreative Prozess; http://www.zeitzuleben.de/2452-kreativitat-was-ist-das-eigentlich/2/
 Krallmann Hermann, Trier Mathias: Systemanalyse; http://www.enzyklopaedie-der-wirtschaftsinformatik.de/wi-enzyklopaedie/lexikon/daten-wissen/Informationsmanagement/Information-/System/Systemanalyse
 Robertson Suzanne, James: Mastering the Requirements Process, Addison Wesley 2013
 Rouse Margaret: transaction; http://searchcio.techtarget.com/definition/transaction
 Das VOLERE-Requirements-Portal; http://www.volere.de