<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">

Approaches to Analysis & Design

These notes are taken from Systems Analysis & Design,
D. Yeates, M. Shields & D. Helmy

In this lecture the traditional approach to the analysis and design of information systems will be presented. This will be followed with an explanation of why this approach has failed, the alternative structured approach to the analysis and design of information systems will examined. Finally, a brief review of popular structured methods will be presented.

1. Traditional Approaches

The traditional approach will usually involved:

  • the analysts and designers using their experience and knowledge of the business domain and technical environment to develop a system which meets the users' requirements as they perceive them;
  • consideration of the business and technical requirements will usually be undertaken in parallel.

1.1 Typical Stages in the Traditional Approach

Although it is difficult to define a sequence of activities in the traditional approach, the following three stages of requirements analysis, requirements specification and high level design are typical.

Analysis of Requirements

The analyst examines the current system (if there is one) and discusses with the users any problems and their requirements for the new system.

Generally, no attempt is made to separate functional and non-functional requirements, functional requirements concern the functions of the system, that is what the system will do, non-functional requirements concern resource restrictions on the system such as the maximum number of users and factors such as future expansion, security and reliability.

Any documentation produced will not be delivered to the users but will be used by the analysts and designers to devise their specifications. Hence users will not usually be asked to review analysis documentation for accuracy.

Specification of Requirements

The analyst reviews the analysis documentation and produces a specification of the system requirements. This will usually cover both functional and non-functional requirements and may incorporate proposals for hardware and software. Screen and report design specifications may be included.

These specifications are likely to be mainly text based with some flowcharts or other diagrams. For a reasonable sized system there may be considerable documentation.

This documentation is usually reviewed by the user although the language used and quantity of documentation may act as a barrier to thorough review.

High Level Design

Once the requirements specification has been approved, the designer produces a high-level design of the system. This may include:

  • database design;
  • menu structures;
  • the general structure of on-line enquiries and reports.

Individual program specifications will be produced at the detailed design stage.

1.2 Review of the Traditional Approach

Key points from this brief overview of the traditional approach:

  • involvement of the system's users is not mandatory, although good analysts will try to involve them the only stage where they must be consulted is when they are presented with the system specification to review and approve;
  • analysis and design tends to be seen as the province of the technician, rather than as a partnership between developers and users;
  • specific skills for which training would be required tend to focus on fact-finding techniques such as interviewing;
  • documentation resulting from traditional methods tends to be big and mainly textual, creating a barrier to thorough review by either the system developers or the users.

Additionally, as witnessed by the software crisis:

  • IT development is littered with a large number of projects were either started and never finished or which, even if completed, failed to provide the users with what they wanted or needed;
  • system developers often produce functionality which is never used, this is not cost effective.

It is concluded that traditional methods have the following shortcomings:

  • large quantities of written documentation act as a barrier, rather than as an aid, to communication between users and developers;
  • there is a lack of continuity between the various stages of analysis and between analysis and design, so that requirements are lost in the process;
  • there is no way to ensure that the analysis and design work is complete because it is difficult to cross-check the findings from the analysis stage;
  • systems developed traditionally lack flexibility and are therefore difficult, and expensive, to operate, maintain and adapt to changing circumstances;
  • traditional development methods tend to assume the use of a particular hardware and/or software platform; this constrains the design so that the users may not get what their business really needs - and the project can be thrown badly off course if the organisation changes platforms during development.

To summarise, traditional methods have failed to deliver the goods in terms of robust and flexible systems which meet the needs of their users.

2. Structured Approaches

In the late 1970's it was recognised that traditional approaches had failed and that there was a need for new methods of analysis and design that would offer:

  • greater formality that would bring system development nearer to a scientific or engineered discipline;
  • clearer specification of requirements by using graphical representation as well as text - a picture says a thousand words;
  • less scope for ambiguity and misunderstanding;
  • a greater focus on understanding and satisfying business needs;
  • more traceabilty, to enable a business requirement to be followed through from initial analysis, into the business-level specification and finally to the technical design;
  • more flexible designs of systems, not unduly tied to specific technical platforms;
  • much more user involvement at all stages of the development process.

2.1 Focus on Data Structures

Most methods place an emphasis on the data requirements of the proposed system. This is because:

  • whilst processing requirements may change, the underlying data is usually relatively stable - hence it provides a sound basis for the development process;
  • if the underlying structure of the data is very rigid this may cause problems later when requirements change, however creating data in a flexible structure from the beginning can help later in the life of the system.

2.2 Use of Diagrams and Structured English

A common feature of structured methods is their use of diagrams. This is because:

  • diagrams are generally easier for people to assimilate than large quantities of text;
  • diagrams provide an easy means of communication between analysts, designers and users;
  • diagrams highlight omissions and ambiguities where as mistakes can be lost in long, text based specifications.

Many methods also make use of Structured English which aims to reduce the ambiguities inherent in our everyday use of the English language. Different variants exist, each of which uses a restricted and precise syntax with verbs such as ADD, MOVE and Boolean operators such as LESS THAN as well as logic terms such as WHILE...DO.

Additionally, methods commonly use decision tables or similar to show the processing logic.

2.3 Concentration on Business Requirements

Another important feature of structured methods is the separation of the logical (what needs to be done) and physical (how it is to be done) aspects of the analysis and design process. This is done so that the business requirements of the proposed system can be concentrated on rather than considering too soon the technical details of the implementation.

It may be argued that leaving physical considerations to a late stage in the lifecycle is foolish - it may be impossible to provide the user with what they want. Whilst this is true, the following should also be considered:

  • the increasing power, flexibility and range of hardware/software platforms makes it unlikely that a suitable platform can not be found to support the business requirements;
  • by focusing on the business requirements the user maintains control rather than them having to accept the constraints imposed by the knowledge and experience of the technical staff;
  • if business requirements can not be met due to technical limitations then it may be better to abandon the project rather than continue and deliver something that does not satisfy the user.

2.4 Typical Stages in the Structured Approach

The following is a typical example of the stages in a structured approach.

Analysis of Current Physical System

The existing system, if there is one, is studied and documented warts and all. A variety of techniques will be used (diagrams, text etc.), all of which will show the current situation - including anomalies and peculiarities. The key is to show how the current system is implemented rather than what it is supposed to achieve. The outcomes from this stage should be reviewed with the users to ensure that they are correct.

Derivation of Current Logical System

The physical aspects of the current system are removed to give a picture of what the current system does. This can then be used as a basis for deciding what the new system should do. Again, this should be reviewed with the user.

Specification of Required Logical System

Further detailed analysis is undertaken to ensure that the requirements of the new system are fully understood. The new system is then designed, initially at a logical level. This provides a detailed specification of what the system is supposed to do with out giving any consideration to technical aspects. The users should be involved throughout this stage.

Specification of Required Physical System

Once all the business requirements have been specified the design can then be translated into a physical design suitable for implementation on specific hardware and software platforms. This is a technical stage and has limited involvement from the user until the end.

2.5 Advantages of Structured Methods

  • concentration on systems' data - a system built around a flexible data structure will be easier to change and have a longer life;
  • the use of diagrams and structured English improves communication between users and developers, increasing the chance of a system that satisfies the user requirements;
  • structured methods encourage rigour and cross checking, making it easier to spot errors and omissions in the analysis;
  • business requirements rather than technical issues are focused on - technology is not used for its own sake but is used to support the business requirements;
  • because technical considerations are left until late in the lifecycle, the design will be suitable for implementation on a variety of platforms (one platform will not have dominated development), therefore, if the users' hardware or software policies change it should be possible to go back to the logical design phase and redevelop for the new platform
  • designs can often be fed directly into a code generator, allowing delivery of the finished system soon after the analysis and design phases have been completed;
  • complete, consistent documentation will have been developed, making future maintenance easier;
  • training requirements are identifiable, for analysts, designers implementers and users, at an early stage;
  • by using a structured method, the project owner can change developer part way through a project - structured method documentation should follow a set format.

2.6 Disadvantages of Structured Methods

The main disadvantages of structured methods are:

  • because much more effort is spent at the early stages (analysis and design) the user has to wait a long time before seeing any results - they must be patient;
  • the amount of user involvement required may be perceived as a hindrance to the user - the reason why it is necessary must be clearly explained;
  • some structured methods remain the intellectual property right of the developers who provide advice, training, consultancy and sometimes support tools for their use - there is a danger if being locked-in to a particular method;
  • CASE tools are becoming more widely used in association with structured methods, some structured methods are difficult to use without CASE tool support, CASE tools can be difficult to learn and expensive although ultimately they will aid the application of structured methods.

References

[Yeates et al, 1994] Yeates, D., Shields, M. and Helmy, D., Systems Analysis and Design, Pitman Publishing , 1994