Structuring The World: Analysis in IT

Structuring The World: Analysis in IT

Most companies are keen to lower costs, speed up their business processes and harness the latest technology to benefit their bottom line. One of the tools that is used to reach these goals is system analysis. This article will discuss the system analysis process in all its glory and challenging beauty.

I am going to post all my thoughts, reflections and conclusions bubbling in my algorithm-infested brain (think Jaws with a bunch of technicians at the helm of the boat). The motivation behind the article is a systems analysis training course I attended recently. Let’s start with a simple definition of system analysis. To do so, I would like to share the thoughts of Jarosław Żeliński, who spoke at the first training session I attended:

All that surrounds us is simple in its very nature. Complexity is not immanent to any object. It is the quantity and inter-object relations that conceive complexity. The goal of analysis is to identify these elementary objects and understand their mutual interaction. This understanding manifests itself in the ability to create a reference model of these objects along with rules of their interactions.

– from Jarosław Żeliński’s presentation (author’s translation into English of remarks made in Polish).

In general, system analysis sets out to:

  • Analyse the current situation
  • Gather requirements
  • Produce an analysis document
  • Provide the end product

Of course this is an enormous simplification, but it will suffice for our purposes.


In order to build a reliable model, it is necessary to understand how the organisation works. There are various approaches analysts can apply to do this. One of them is called “brainstorming”. A group of representatives meet the analyst and explain “how it works” and “how it should be done”. Practice shows that this may not be the most effective method. A brainstorming meeting often leads to long discussions or to people stressing conflicting interests etc. Supporters of brainstorming tend to argue that “it all depends on the moderator” or “it can be done effectively if it is well organised”. This is true, but the process requires superior interpersonal skills. The final outcome is also strongly determined by the configuration of current group members. Having said that, brainstorming may work well in some situations – for example when dealing with areas related to User Experience (UX).

In general, it is safe to say that all companies have certain things in common and function in similar ways on some levels. Of course this does not mean that all companies come from the same cookie cutter – every company has their own distinct profile. Many routines, however, such as the standard documents used for certain business processes (invoices, salary records, vacation requests etc.) are regulated by the law.

An alternative to brainstorming is that the company collects all these internal documents and evaluates them in a meeting. After that, an analyst is called in to ask precise questions to get information that the paperwork doesn’t reveal. This is effective. Documents are hard evidence that are not influenced by people’s experience, character, social skills and imagination.


This leads to another important thing: system analysts’ model business processes. There are four main characteristics of a business process:

  1. Activity
  2. Input
  3. Output
  4. Role

If any of these four are missing, it is not a process. It is also worth remembering that every process has a receiver, and that defining receivers (hypothetical or factual) is beneficial for the analysis procedure. A model must meet three conditions to be considered valid:

  1. Coherence
  2. Completeness
  3. Non-contradiction

If these conditions are met, we can expect the model to have value. However, it is a good idea for analysts to be open to the client’s feedback and input, to make sure important information is not neglected. There are cases when missing out on just one important detail proved the whole model unusable. On the other hand, it is advisable for analysts not to allow too much space for speculation that does not improve the model. It is usually sufficient to ask for feedback in two basic situations:

  1. When the model does not comply with the notes from the meeting
  2. When the model is false, i.e. when it does not represent objects or relations accurately or when special cases are missing

Limiting user feedback this way can save a lot of trouble and weeds out unnecessary discussion.


The bottom-up approach is sometimes considered one of the downsides of agile methodology. Again, for the sake of the argument, let’s avoid a conversation based on arguments like “not if it is applied in the right way”. Bottom-up analysis means starting with the most tangible items. During the process, details are connected to generate a bigger, general idea.

Unfortunately, you are likely to face many issues and dead ends. Without the bigger picture, it is difficult to proceed. It is beneficial to utilise methods that lead smoothly from general concepts to smaller details. This has been proven to be effective even in the most complex projects.


Business rules are properly defined in three statements:

  1. A business rule is a constraint in an activity flow or a requirement to take some action (that may require professional knowledge), e.g. “letters to clients should always start with appropriate polite salutation”; however, knowing when to use Mr, Mrs or Ms requires separate expertise
  2. Business rules define borders between acceptable and unacceptable behaviour in an organisation
  3. Business rules do not contain decision criteria


A model should never allow for deadlocks, as no companies accept them. Analysts should identify the methods applied to avoid “jams” where the company cannot continue to operate efficiently. This may be tough as employees tend to treat these activities as obvious or natural. This problem should always be carefully investigated. A well designed CASE tool with a model validation mechanism can be useful.


Finally, here is a checklist with general advice for analysts that may come in handy:

  • Pay attention to the products of business processes: when is it valuable to define a new one and when is it just a status
  • Mark statuses of documents (e.g. “rejected” or “approved”)
  • Annotate all diagrams
  • Ask instead of assume
  • Create a list of business functions connected to roles
  • List developers’ skills
  • Identify processes rather than create them
  • Let the client design the documents
  • Avoid extracting value from job descriptions, as they tend to be very general and have often been neglected
  • Attach activity details as notes, not additional diagrams
 Photo: Jacob Bøtter / Flickr CC