Software Analysis Techniques

Introduction

This document describes various techniques used during the analysis phase of software development. More specifically, the techniques described here grew out of experience in the multi-threaded event driven embedded systems domain, but much of what is described is applicable to software development in general.

Analysis is the process of understanding the problem that is to be solved. In its most informal sense, analysis is what we do when we think about the problem. Contrast this with design, which is thinking about how to solve the problem. The more accurate our analysis of a problem, the more likely we are to be able to design a solution that actually solves the problem completely. Since all but the most trivial problems are actually compond problems, it is all to easy to only solve part of a problem correctly.

It is important to note that analysis is the process of understanding the problem, not one of defining the problem. The definition of the problem is established by requirements. Requirements are rarely (if ever) complete when a new problem (project) is started. Questions concerning specific requirements inevitably arrise during analysis. Such questions should always be answered by adding the new requirement to the appropriate documentation with an explanation of the reason for the requirement.

When analysis gives rise to new requirements the waterfall model is violated. Requirements for a new non-trivial problem are never perfectly complete, and thus the waterfall model of development does not reflect the reality of the development cycle. The two stages are dependent upon one another, and the acknowledgement of this relationship is the basis of the iterative development model.

The output of an analysis is a document that describes the problem to be solved in a way that can be easily referenced

Establish Problem Boundaries

Identifying System Interfaces

Characterizing Interfaces

Periodic interface, as the name implies, require that information is transferred across the interface at regular intervals during normal operation. The direction of the transfer may be either an input or an output. Many real-time problems require that inputs be sampled with a minimum frequency, and the outputs updated at a related frequency. The deadline is directly related to these frequencies in that the processing between input and output must not take any longer than the period of the highest frequency.

Aperiodic interfaces are characterized by sporadic behavior with respect to the transfer of information across the interface. That is to say that information is not transferred across the interface at regular intervals, but rather as the information becomes available. General data communications interfaces are good examples of this type of interface. While data may only cross the interface at a maximum rate determined by the communications media, the arrival depends upon the types of applications that exist on the data communications channel.

Request/Response interfaces are typified by a client sending of a request to a server, and the server subsequently returning a response when the request is completed. Almost all procedural sub-routine calls can be characterized as request/response interfaces.

Identify Problem Domain Objects

Identify Relationships Between Objects


Here is a list of activities that are typically performed during the analysis phase.


mike@mnmoran.org