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.