Skip to main content
Disciplines
Automotive Business IT + Informatics Construction + Real Estate Electrical Engineering + Electronics Energy + Sustainability Insurance + Risk Finance + Banking Management + Leadership Marketing + Sales Mechanical Engineering + Materials
Events
DE
EN
Books
Journals
Topic Page
Marketing
Start single access now
Access for companies
EXTENDED SEARCH
Log in
Top

1978 | Book | 2. edition

Introduction Read chapter Read first chapter

A Handbook of Systems Analysis

Authors: John E. Bingham, A.C.I.S., A.M.B.I.M., M.B.C.S., M.D.P.M.A., Garth W. P. Davies, M.A. (Cantab.), M.I.Inf.Sc.

Publisher: Macmillan Education UK

Included in: Professional Book Archive

Login to get access
insite
SEARCH

Table of Contents

Frontmatter

Introduction

Introduction
Abstract
This book is about the analysis of business systems—not about computers. In many cases, of course, this highly valuable tool will be the means selected to implement the solution to a business problem. Indeed, the growth of systems analysis is closely related to the growth in the use of computers. Nevertheless, the principles of systems analysis are independent of the mechanisms used to apply them. How, then, does systems analysis differ from the longer established organisation and methods (O & M) approach? Or for that matter from any other problem-solving discipline? Cannot the approach of a mathematician be used? Or a psychologist? Or an economist? The answer to these questions is that systems analysis is in fact an extension of traditional problem-solving disciplines which have already been used in the business area. However, the very fact that systems analysis uses the approaches of the mathematician, the psychologist, the economist and the O & M man gives rise to the need for the separate discipline of systems analysis. There is clearly a need to combine those elements of the different approaches which are best suited to the solution of problems in the business environment, oriented, though not exclusively, to the use of computers.
John E. Bingham, Garth W. P. Davies

The Six Steps of Systems Analysis

Frontmatter
1. The Structure Of Systems Analysis
Abstract
If you ask the average systems analyst to describe and define the work he does, you will probably receive a very vague answer. This is not because his work is particularly complex or difficult to describe (it is NOT as this book attempts to show), but simply because most systems analysts themselves do not have a very clear idea of the structure of their task. They are usually heavily overworked and manage to do their daily work because in most companies there is always a backlog of systems work which is clearly defined due to its urgency. So they follow a series of short-term goals rather than a methodology of systems analysis.
John E. Bingham, Garth W. P. Davies
2. Step 1: System Project Selection
Abstract
Every systems project must at some stage have been the object of a selection process. Usually the systems analyst does not take significant part in this process and in many cases he first becomes involved when the decision has already been made. Nevertheless, the systems analysis function begins in the first place by identifying the area for study, even if this phase is often undertaken by general management rather than by systems analysts.
John E. Bingham, Garth W. P. Davies
3. Step 2: The Feasibility Study
Abstract
The objective for this phase is a report indicating the possible ways of accomplishing the project objective, stating the costs and benefits of each approach. Normally, a recommendation for the best way is implicit, if not explicit. Here are the main activities comprising the feasibility study:
  • Identify the main characteristics of the system.
  • Determine the main output requirements, including response times.
  • Analyse the organisation chart, geographical distribution, etc., of the department(s) involved.
  • Determine the varieties of data and estimated volumes.
  • Consider possible alternative ways of meeting the requirements of user(s).
  • Examine other systems meeting similar requirements.
  • Prepare gross estimates of probable overall implementation and operation costs for each possible alternative.
  • Prepare gross estimates of probable overall direct and indirect benefits for each possible alternative.
  • Document the Feasibility Study in a report for user and systems management.
  • Determine that the requirements of the system are consistent with the company objectives.
John E. Bingham, Garth W. P. Davies
4. Step 3: Definition Phase
Abstract
The objective of this phase is to obtain a System Definition, which will then be implemented, if accepted, in the subsequent design phase. In contrast to the Feasibility Study, detailed analysis of every aspect of the system must be carried out. The basic activities are:
  • Determine objectives of current system.
  • Study current system to see how far it meets its objectives.
  • Analyse users’ and company’s requirements to develop new objectives.
  • Identify constraints imposed by users’ environment.
  • Identify users’ responsibility for data inputs and outputs to other systems.
  • Examine interaction of proposed system with other systems.
  • Prepare details of requirements of users—data elements, volumes, response times, etc.
  • Prepare design specifications.
  • Prepare plan for design and implementation phases.
  • Produce a report for the user and systems management.
John E. Bingham, Garth W. P. Davies
5. Step 4: Design Phase
Abstract
In this step of systems analysis we proceed from the ‘what’ of the new system (discussed in Chapter 4) to the ‘how’, i.e., we move from the agreed definition of systems objectives and requirements to the detailed system design which is to be implemented. This means that the entire system has to be defined in terms of information flow, files, volumes, printed output designs, procedures, manually used forms, program specifications, etc. In addition, a revised estimate of the operational cost of the system is calculated after the design has been completed and a revised plan for implementation produced.
John E. Bingham, Garth W. P. Davies
6. Step 5: Implementation Phase
Abstract
The objective of this phase is to obtain an operational system, fully documented. The main activities which take place are:
  • Write and debug all computer programs.
  • Create master files.
  • Prepare documentation for ADP and user departments.
  • Acquire all necessary equipment, stationery, etc.
  • Train ADP and user staff to use system.
  • Supervise phasing-in of system parts.
  • The testing and proving of all parts of the system.
John E. Bingham, Garth W. P. Davies
7. Step 6: Evaluation Phase
Abstract
The work of a systems analyst on any given project does not cease when the system becomes operational and error-free. Unfortunately, too many systems analysts do consider their work complete at this stage and move on to new projects without ever carrying out the very necessary evaluation phase.
John E. Bingham, Garth W. P. Davies
8. Review of the Six Steps of Systems Analysis
Abstract
Although we have considered each of the steps separately, they are, of course, related to each other by the dependence of each step on the successful completion of the preceding one. Furthermore, the steps have been designed to provide checkpoints where decisions can be made as to whether or not it is worthwhile to continue the project.
John E. Bingham, Garth W. P. Davies

Techniques

Frontmatter
9. Fact Gathering
Abstract
Some experts consider that a systems analyst’s job is approximately 40% technical and 60% human relations. This 60% human relations content does itself have a number of facets, among the most important of which may be considered:
  • Choosing a team to conduct a project.
  • Leading a team.
  • Communicating ideas.
  • Giving technical instructions.
  • Obtaining information.
John E. Bingham, Garth W. P. Davies
10. Charting Techniques
Abstract
In the previous chapter, various ways in which an analyst may obtain information were described and it is natural to follow this with a discussion on some of the ways in which the information obtained can be documented. Charting techniques are, however, more than just ways of recording information; properly used they can also prove valuable design aids. In this chapter, some of the most useful charting techniques to an analyst are described. They are:
  • Procedure charts.
  • Flowcharts.
  • Hierarchy plus input-process-output (HIPO) charts.
  • Other charting techniques.
John E. Bingham, Garth W. P. Davies
11. Decision Tables
Abstract
This technique, which undeservedly has a high-sounding title, is both simple in concept and easy to use. It is by no means new, having been used in other fields—notably production engineering—for at least twenty years. Yet it was not until the late 1960s that it began to be used on even a modest scale in data processing. The impetus, when it came, was regrettably for the wrong reason. It became possible to convert decision tables directly into computer machine code, thus saving programming effort. This benefit, though real, is quite insignificant when compared with the true value of decision tables.
John E. Bingham, Garth W. P. Davies
12. Simulation
Abstract
Simulation is a tool which in the appropriate circumstances can be of immense value to the systems analyst. In general, simulation is used for the selection, analysis and design of medium to large systems. However, it can also be very valuable for certain aspects of even very small systems. Some of the ways in which simulation can be applied to a range of systems will be described in this chapter.
John E. Bingham, Garth W. P. Davies

General Systems Considerations

Frontmatter
13. Data Capture and Output
Abstract
There is a widespread tendency for the data capture aspects of a system to be given scant attention, because the analyst considers that it is more important to concentrate on the computer processing part of the job. Yet this attitude ignores the fact that more time can be wasted in a system by bad data capture techniques than can ever be saved by even the most elegant programming. Similar considerations can also be applied to input and output. Furthermore, lack of attention to the input phase of a system will almost certainly increase the number of errors entering the system. This latter point will be discussed in greater detail in the section on Data Security (Part III, 15).
John E. Bingham, Garth W. P. Davies
14. Data Management
Abstract
Data is the raw material with which the systems analyst works, developing procedures (which may be thought of as analogous to processing machinery) to forge the data into the end product—information. Traditionally each analyst has been responsible for the collection and storage of the data for ‘his’ applications. This approach is inherently wasteful in that it leads to duplication and inconsistency when data is required for different purposes. More significantly, data collected in this way is difficult to process and present in ways other than that originally envisaged. In consequence computer-based systems tend to be difficult to modify and often prove incapable of responding to ad hoc requests for information within reasonable time and cost limits even if the basic data is available in computer-readable form.
John E. Bingham, Garth W. P. Davies
15. Data Security
Abstract
A systems analyst’s responsibility for a given design goes beyond the creation and implementation of the system. He must also make specific provision for the safe running of the system, to ensure that the organisation’s interests are protected in the event of accidental or deliberate threats to the security of the data. Overall data processing security is of course the responsibility of the department manager aided by his entire staff. Nevertheless, good systems design takes into account all aspects of security and, where appropriate, builds in or recommends specific additional controls.
John E. Bingham, Garth W. P. Davies
16. Working Methods and Procedures
Abstract
Most ADP practitioners like to regard themselves as professionals—in the sense that they belong to a ‘profession’ and are not ordinary salaried employees. This view which is reinforced by (or is a result of ?) such moves as the publication of the British Computer Society’s Code of Behaviour and the evident concern of data processing practitioners about the ethics of data bases argues for a disciplined and systematic approach to work as is evidenced by the legal, medical, teaching and engineering professions with which ADP would like to claim equality.
John E. Bingham, Garth W. P. Davies
17. Data Communications
Abstract
Any information system depends to some extent on data communications. The flow of data must take place through some process or processes which forward the items of data from place to place within the system. These processes may include postal services, wired connections between parts of a central processor and its peripherals or even delivery services by human beings. It is, however, the exploitation of telecommunications facilities for transmitting data which has given rise to the specialised meaning today of the term ‘data communications’.
John E. Bingham, Garth W. P. Davies
18. Systems Maintenance
Abstract
Most systems become obsolete the day they become operational. That is not to say they become without value to the organisation, but almost invariably changes are necessary to the new system right from the start. The systems analyst therefore rarely sees a system ‘completed’ but is involved almost continuously in maintaining the systems he has implemented at a satisfactory operational level.
John E. Bingham, Garth W. P. Davies
19. User Involvement
Abstract
If an experienced systems analyst is asked to name the biggest single factor which determines the success or failure of a system, he usually answers ‘User involvement’. He is referring to the desirability of having the user of the future system work closely with the analyst right from the start of the project. This has many benefits, some of which are:
  • It ensures that the analysis and design do correspond to the requirements of the user area.
  • It ensures acceptance of the system when it becomes operational. If the user himself has helped create the design, he cannot resist its use afterwards.
  • It provides built-in training capability for the user department. Although there will probably be aspects of the system best explained by the systems analyst, the user representative(s) can do much of the system introduction.
  • It provides automatic follow-up. It is very valuable to have a member of the new department who thoroughly understands the system ‘on site’ the whole time.
John E. Bingham, Garth W. P. Davies

Project Management

Frontmatter
20. Problems of Implementation
Abstract
The term ‘implementation’ in data processing is used to cover a variety of different meanings, ranging on the one hand from the simple conversion of an existing computer application to a revised or extended application, to the complete changeover from one type of hardware to another, on the other hand. In practice the problems to be overcome tend to be much the same and the differences are of degree rather than principle. By ‘implementation’ the authors of this book mean the process of converting the system design into an operational system. This chapter outlines some of the major problems which arise in this important phase of systems work, i.e. the generalised case of ‘getting the system to work’, and describes measures which may be used to minimise these problem areas.
John E. Bingham, Garth W. P. Davies
21. Planning for Implementation
Abstract
The task of a systems designer does not end when the new system, whether it be manual or computer oriented, is specified and accepted. It is his responsibility to turn that design into a working system. It is, however, in many cases a failure to understand the factors involved or the ineffective management of resources available which leads to many projects falling behind schedule during this critical phase.
John E. Bingham, Garth W. P. Davies
22. Management Control
Abstract
The previous discussions in this section on project management have concentrated on the role of the systems analyst in planning and implementing project activities. At a higher level, of course, the systems analyst himself is controlled as part of the overall systems effort, which in turn is monitored by top management in the light of company goals.
John E. Bingham, Garth W. P. Davies
Backmatter
Metadata
Title
A Handbook of Systems Analysis
Authors
John E. Bingham, A.C.I.S., A.M.B.I.M., M.B.C.S., M.D.P.M.A.
Garth W. P. Davies, M.A. (Cantab.), M.I.Inf.Sc.
Copyright Year
1978
Publisher
Macmillan Education UK
Electronic ISBN
978-1-349-15930-7
Print ISBN
978-0-333-24199-8
DOI
https://doi.org/10.1007/978-1-349-15930-7