Book 28 — Information System Design

by The Editor

4. Analytical Technique

Contents List:

Strict Objectivity
Effective Business Analysis (EBA)
Start-Up
Analysis
Review
Working Prototypes

Return to:

Title Page
Library
Ardue Site Plan

See also:

3. Approach to System Specification

Strict Objectivity

The virtues of the approach recommended in chapter 3 may be obvious; what is not so obvious is how it may be put into effect. For instance, the first step in method study is to select the system or sub-system to be analysed; yet in a complex environment, system and sub-system boundaries may not be easy to draw. The views of the individual who operates one part of a system are inevitably coloured by his own perspectives and aspirations and these may not always be in harmony with those of his colleagues or accord with the views of his superiors in the organisational hierarchy. Unless an objective method of attack is adopted from the outset, much time and effort may be wasted in inconclusive and demoralising debate. In this chapter, therefore, we consider a practical technique designed to unravel the often rather nebulous complexities of an information system while reconciling contrasting views and reaching a consensus..

No information system exists in a vacuum; the effectiveness of a system can be gauged only with reference to the information needs of the organisation it purports to serve. For that reason, the analysis must begin with a clear definition of the aims and objectives of the organisation. Only then will it be possible to define a corporate information strategy to support these aims and objectives.

Effective Business Analysis (EBA)

EBA is a disciplined approach to the problem of eliciting and presenting information about an enterprise, its strategic goals, and its operational activities. The result is a clear, concise, consistent description that will provide a sound basis for subsequent information system design, specification, and construction. The description consists of discrete "chunks" of information expressed in free-form text which can be collated, indexed and cross-referred to other chunks — ideally with the aid of PC-based software tools.

The description not only defines the functions required to achieve the objectives of the enterprise but also specifies how well these functions are to be performed and at what cost in resource provision. Systematically applied, EBA naturally produces a specification of high quality because:

  1. it takes into account the requirements of users at all levels in the organisation.
  2. information may be entered as it becomes available and be linked logically with information already captured.
  3. the true business structure is revealed so that unnecessary features can be identified and removed.
  4. system objectives are expressed in terms which permit performance and costs to be measured and compared.

EBA proceeds in three basic stages:

Each of the first two stages is usually repeated at least once before Stage C can be completed satisfactorily because the review normally reveals areas of disagreement and because the analytical process itself tends to change peoples' perspectives.

Start-Up

Stage A itself has two steps:
  1. Write some "working outlines". This is the single most important task in the whole project. It must be undertaken by the organisation's top policy-makers (with the support of a business analyst) as a group exercise making use of brain-storming techniques and involving people from all levels in the organisation.

    The analyst acts as a facilitator (and sometimes as a catalyst) by applying BARTOQUE, an acronym for the topics which must be covered:

    • beneficiaries — who benefits from the system (or sub-system)?
    • actors — who plays the parts required by the system?
    • resources — what are the resource-critical constraints?
    • transformations — what are the inputs and outputs?
    • owners — who "owns" the system (or sub-system)?
    • quality — what are the criteria for success?
    • unique perspective — what is the ultimate justification for the existence of the system (or sub-system)?
    • environment — what are the constraining relationships between the system (or sub-system) and the overall ambience within which it must operate?

    An important part of the analyst's task is to capture and record any definitions and explanations of business terms as they are used by members of the brain-storming groups.

  2. Select a working outline for analysis. The outline selected should reflect the viewpoints of the "workers" as well as board-room or top-level policy. It may sometimes be appropriate to select more than one outline for further analysis to clarify important issues and help protagonists reach a consensus.

Analysis

The analysis stage has four steps:
  1. Determine relevant sub-systems. Sub-systems are represented as parts of a network, not a hierarchy. Links between sub-systems are shown on a labelled diagram.
  2. Write an outline for each sub-system. Like their parent system, sub-system outlines are also constructed by the application of BARTOQUE — normally with a different group of people who have specific knowledge related to the sub-system in question.
  3. Determine the information needs of the sub-system, defining in detail:
    • a. the inputs (and their sources).
    • b. the outputs (and where they are used and why).
    • c. how the inputs are processed to produce the outputs.
  4. Determine information dependencies. Having dealt with each sub-system independently, determine how its inputs depend on the information output by other sub-systems.

Review

The purpose of this stage is to obtain agreement that: the working outline itself is a correct representation of the required business system;
  • the detailed analysis is internally consistent; and that
  • it accurately reflects the selected overall working outline. This task will be easier if the detailed analysis is expressed using a formal methodology.

    Within each cycle, the review attempts to reveal where and why there are inconsistencies, inaccurate reflections, and incorrect representations.

    The number of reviews required will vary with the complexity of the business and on whether it is stable or in process of change. There is no substitute for good judgment in deciding when and where to stop — and the 80:20 rule should normally be applied.

    Working Prototypes

    Prototype systems or sub-systems constructed directly from the analysis enable business personnel to get a realistic preview of how the processes with which they are concerned will look and feel when they have computer assistance.

    This is particularly valuable for highlighting practical problems which may arise when a totally logical solution is implemented without paying sufficient regard to the environment in which it must operate. For example, careful attention must be paid to the siting of equipment and the lighting of the workplace so that an operator's view of a computer screen is not impaired by light from windows or reflections from other objects. Such practical considerations may influence important decisions about such matters as how many computer terminals will be required and where they should be sited.

    Prototypes are most helpful in securing the willing co-operation and commitment of the people who might otherwise fear and resent changes in working practices with which they are familiar and comfortable. With the aid of the prototype, they can see how it will benefit them directly by reducing drudgery and speeding up tedious boring tasks. It gives them an opportunity to make constructive comments and suggestions for enhancing benefits or overcoming any perceived drawbacks. Above all, they appreciate the opportunity to play a part in the design process and the feeling that their views count for something.

    Prototypes thus help to maintain momentum by generating enthusiasm for the project throughout the organisation and showing how the trauma of the analytical process is an essential preliminary to a successful outcome.