System Analysis and Design – Is it Science, Art or both?

You can’t fix it if you don’t know how it works, and how it should work. You can’t improve it unless you understand it. You can’t control it unless you comprehend what happens. That, in a nutshell is the importance of Systems Analysis & Design. (Anonymous)

It is both. Systems Analysis and Design is a subset of Software Engineering and therefor a science. It is most commonly called the practical side of Computer Science in the business setup. It is offered as a major in the science faculty of most universities world-wide.

Here are some sub-disciplines of Software Engineering that you will come across quite often

  1. Software Requirements / Requirements Engineering
  2. Software Design
  3. Software Construction
  4. Software Testing
  5. Software Maintenance
  6. Software Configuration Management
  7. Software Quality

The following is some Software Engineering types of disciplines that you will come across quite often

  1. Systems Engineers (SE’s)
  2. Multiple-Discipline Engineers
  3. Specialty Engineers
  4. Business Systems Analysts
  5. Quality Assurance(QA) and Software QA’s
  6. Project Engineers
  7. Functional Managers and Executives

 

Methodologies

There are three key differentiators when you look at methodologies:

  • Analysis Methodologies
  • Modeling Techniques
  • Modeling Notation

 

Analysis Methodologies

Analysis Methodologies falls into four broad categories

Structured Systems Analysis (Information Engineering – IE)

This type of analysis mainly focuses on logical systems and functions, and aims to convert business requirements into computer programs and hardware specifications.

The major steps involved in the structured analysis process are:

  • Studying the current business environment
  • Modelling the old logical system
  • Modelling a new logical system
  • Modelling a new physical environment
  • Evaluating alternatives
  • Selecting the best design
  • Creating structured specifications

There are three orthogonal views related to structured analysis:

  • Functional View: This involves data flow diagrams, which define the work that has been done and the flow of data between things done, thereby providing the primary structure of a solution.
  • Data View: This comprises the entity relationship diagram and is concerned with what exists outside the system that is being monitored.
  • Dynamic View: This includes state transition diagrams and defines when things happen and the conditions under which they may happen.

Object Orientated Analysis (Function & Data)

Object–Oriented Analysis (OOA) is the procedure of identifying software engineering requirements and developing software specifications in terms of a software system’s object model, which comprises of interacting objects.

The main difference between object-oriented analysis and other forms of analysis is that in object-oriented approach, requirements are organized around objects, which integrate both data and functions. They are modelled after real-world objects that the system interacts with. In traditional analysis methodologies, the two aspects – functions and data – are considered separately.

The key points in the last two sentences is worth emphasizing. With OO, Data and Functions is integrated whereas with other methodologies, Data and Functions are considered separately.

You will see this concept being repeatedly discussed in future posts.

Object-based Systems Analysis (TSM=IE + OO)

The Seer Method (TSM) as automated in HP’s analysis toolset is an example. This method builds on Structured Systems Analysis by incorporating OO “objects” but does not accommodate the polymorphic aspects of OO methods.

Component-based Systems Analysis (Commercialized OO)

This is very much an OO approach which is extended to allow the commercialization of software components. Components comprise OO objects and other components.

Having studied and used both IE and TSM, having been on numerous OO courses, and having done personal research on CB development, I can with certainty state that the difference between these 4 types of analysis approaches are significant, although not wholly unrelated.

 

Analysis organizations which have never really done formal analysis must thus choose one of these approaches and apply it until the practitioners (business & IT) have matured enough to allow progression to more advanced approaches and associated technologies, i.e. only once ONE analysis methodology is understood properly by all should one consider advancing in this way.

Each of these approaches builds on the concepts and successes of the previous one, subscribing to the sequence as listed above.

The most advanced approach (that I am aware of) is to MIX the concepts of various analysis approaches, this as required in a particular situation or on a project.

That’s it for Methodology categories and we still have not mentioned AGILE. Take a guess why not.

While you guessing, let’s move on to the next key differentiator –

Modelling Techniques

There is a plethora of modelling techniques out there, but to save you some time I will just mention the most popular

  • Business process models (BPMN)
  • UML diagrams
  • Flowchart technique
  • Data flow diagrams
  • Role activity diagrams
  • Role interaction diagrams
  • Gantt charts
  • Integrated definition for function modeling
  • Colored petri-nets
  • Object oriented methods
  • Workflow technique
  • Simulation models

You can really go bonkers here! In the next couple of posts, we will re-visit modelling techniques with some case studies that suggests how best to go about selecting the techniques to work with.

Modeling Notations

  • UML
  • SysML
  • BPMN
  • ArchiMate
  • Yourdon
  • Gane-Sarson
  • Etc, Etc, Etc …..

You can go crazy while going bonkers with these! Same as with techniques, we will re-visit modelling notation with some case studies that suggests that using only THREE of these notations will cover all your modelling requirements.

In order to remain sane amidst the chaos, it would be wise for you to hang on to the fundamentals by constantly sharpening a specific type of thinking.

Systems Thinking

Source: Unslpash

Systems Thinking is a wide and varied subject, but our objective over the next couple of posts, is to use only those parts that can be applied to Systems Analysis & Design. Here are those parts in no particular order

  • Mastering Complexity
  • General Systems Thinking
  • Observing and Interviewing
  • Trading off Quality versus Cost
  • Understanding the Designer’s Mind
  • Design Philosophy

 

So…. Let’s recap

Systems Analysis & Design is a subset of Software Engineering. You will fast track from an average Analyst to a Super Analysts by starting to think like a Software Engineer with Business knowledge (Domain) to boot. There are only THREE key differentiators (Analysis Methodology Categories, Modelling Techniques and Modelling Notations).

The secret to becoming a top-notch Systems Analyst is to… well – Think in Systems.

Author: Llewellyn Daniels – Lead Analyst Consultant