Systems Analysis

How Systems Analysis Works

At the beginning of a Systems Analysis is a question and, with it, the decision about which part of reality is to be examined at all.

This can include, for example:

• components and actors involved
• processes and states
• data and data flows
• interfaces to other systems
• technical and organizational dependencies
• requirements and constraints
• known risks and uncertainties

From this information, a model of the system or system segment under consideration is created.
Such a model is not identical to the real system. It represents only those properties that are relevant to the particular purpose of the analysis. Systems Analysis therefore also includes the question of which assumptions have been made, which information is missing, and within which boundaries a model is valid.
Systems Analysis is typically iterative: New findings can lead to the model being extended or corrected, or to the boundary of the system under consideration being changed.

Why Systems Analysis Should Precede a Solution

Technical problems often become apparent somewhere other than where their cause lies.
A slow process can, for example, be caused by software, but equally by an unsuitable interface, duplicate data entry, organizational processes, or a dependency on another system.
If a solution is developed immediately before these relationships have been sufficiently examined, there is a risk of merely changing the visible symptom.

Systems Analysis therefore first attempts to create a robust basis for the decision:

• What do we know?
• What are we only assuming?
• Which parts of the system are relevant to the question?
• Which dependencies exist?
• Which alternatives are there?
• What impacts and risks would possible changes have?

The result of a Systems Analysis therefore does not have to be a new technical solution immediately. The finding that a planned change is unnecessary, too risky, or would make more sense elsewhere can also be a result.

Why Systems Analysis Has Practical Effects

• Better decisions: Changes can be based on examined relationships rather than exclusively on assumptions.
• Visible dependencies: Interfaces and interactions are considered before individual components are changed.
• Dealing with uncertainty: Missing knowledge and assumptions can explicitly be part of the model.
• Comparison of alternatives: Different solution approaches can be examined using common criteria.
• Limited scope of investigation: Even with large systems, a system segment relevant to the particular question can be considered.
• Iterative learning: The model can be extended or corrected as new findings emerge.

Typical Example

A company wants to replace an old software system.
Instead of immediately selecting a new product, it first examines which tasks the existing system actually performs, which data is processed in it, which other systems access it, and which manual workflows are associated with it.
This may reveal, for example, that an apparently insignificant data export is required by another business process or that knowledge about certain special cases is held only by individual employees.
Systems Analysis thus initially provides a more robust model of the relevant system segment.
Only on this basis can it be meaningfully assessed which parts should be replaced, changed, retained, or possibly left unchanged.

Distinction

Systems Analysis is not the same as System Architecture.

Systems Analysis examines a system or possible system variants and provides information for decisions. System Architecture, by contrast, describes fundamental structures, elements, relationships, and principles of a system.
A Requirements Analysis is also only one possible component or adjacent process. It focuses on identifying, structuring, and examining requirements.
Systems Analysis is also not synonymous with a complete description of an organization or technical system. The scope and precision of an analysis depend on its question, the available information, and the selected system segment.

Further Reading

Related Concepts

→ System Architecture
→ Solution Architecture
→ System Integration
→ Verification and Validation
→ Legacy System
→ Legacy Modernization