Software Development: Analysis

Analysis is the process (phase) of discovering what the system is intended to do, without getting drawn into how it is going to do it. One way to think of it is that analysis is the process of describing the problem for which we will subsequently design and develop a solution.

Generally there are many different stakeholders who place requirements on the system being developed, these may include, for example:

The end user (of the system)
The customer (who is paying for the system)
The business (who is developing the system)

There are three outputs from the analysis phase

Problem Space Concepts and Relationships
Use Cases and Actors
External Interfaces

A good starting point for performing system (or requirements) analysis is the text that is provided as the ‘Requirements’ from each of the stakeholders. Although text is a very ambiguous and thus poor means to express requirements, it is the easiest way to capture the initial communication of requirements.

The analysis phase in the development process is where we develop the initial ambiguous requirements into something precise that can be verified, and which enables an indication that the system has been finished.

Object-Oriented Analysis is a technique where we identify objects and relationships in ‘the requirements’ and express these in the form of a UML Class Diagram. These ‘Classes’ are not classes in the sense of ‘programming language’ (e.g. Java) classes, they are simply a way to represent a set (class) of objects that exist in the Problem Space for which we are developing a Solution.

Software Development: Examples: Hello World: Design

The design of the system is presented from a number of different viewpoints. There is no specific ordering of these viewpoints, they simply present different aspects of the design of system.

  • LogicalThe conceptual aspects of the system, uncluttered by deployment or target platform issues.
  • PhysicalThe physical, tangible, aspects of the system. I.e. what can be picked up and touched.
  • DeploymentHow does the Logical map to the Physical.
  • ImplementationThis viewpoint focuses on the organization of artefacts that are stored and need to be configuration controlled, e.g. source files, folders, binaries, config files, etc.
  • Runtime: The viewpoint focuses on the objects that exist or are constructed at/during runtime, i.e. whilst the system is operating.

Software Development: Examples: Hello World: Requirements

The ‘Hello World!’ example does not have complicated requirements, or many of them. Of course, different implementations of the example may imply different requirements. For this tutorial we will use the following requirement:

  1. When the system is started it shall display to the user the message ‘Hello World!’.

Software Development: Examples: Hello World


Most programming languages start with a simple example known as ‘Hello World!’. Although MDE is not a programming language, we can use the same simple example to introduce some of the concepts of MDE.

Obviously, we do not need all of the extra stuff introduced here in order to produce an application that displays ‘Hello World!’ to the user. However, in a more complex system the ‘extra stuff’ becomes very useful.

The Engineering Development Plan

The Development Process

In order to develop any reasonably sized software system, with good engineering practices, it is necessary to have a development process. This process is an important part of the engineering development plan.

We will use a fairly standard and recognisable process comprising the following phases:

  • Requirements: what does the customer want.
  • Analysis: clarify what the customer wants, ensure it is what the end user wants, define the problem for which you will produce a solution.
  • Architecture: Define one or more solutions to the problem.
  • Develop: Create, construct, build, test the parts that comprise the (or one of the) solution.
  • Integrate: Connect the parts and check they all work together as intended/expected.
  • Verify: Test and confirm that the solution does actually solve the problem defined as part of the analysis.
  • Validate: Test and confirm that the solution does actually solve the problem that the end user wanted solving.