Professional Documents
Culture Documents
Information System Analysis and Desgin 01
Information System Analysis and Desgin 01
7170
Summer 2000
HIGHER STILL
Information
Systems
Systems Analysis and Design
Advanced Higher
Support Materials
*+,-./
CONTENTS
Outcome 1
1 The Analysis and Design Cycle
1.1 Introduction
1.2 Analysis
1.3 Design
1.4 The Analysis and Design Cycle
Outcome 2
2 Analysing a Manual System
2.1 Introduction
2.2 Beltane Books: The Current System
2.3 Analysing the Current System
Outcome 3
3 Designing a Computerised Information System
3.1 System Specification
3.2 Data Flow Diagram
3.3 Data Dictionary
3.4 File Structures
Teacher/Lecturer Notes
Target audience
Many students embarking on this unit are likely to have gained Higher Information
Systems or Higher Computing.
The unit may also be taken as a stand-alone unit in which case students should have a
level of knowledge which would have enabled them to achieve the Higher course in either
Computing or Information Systems.
Progression
This unit forms part of the Advanced Higher course in Information Systems and may
provide a suitable area of study for the Project at Advanced Higher.
It has not been written as a stand-alone open learning unit, but with limited guidance,
students should be able to work through this unit for long spells on their own. After initial
orientation students should be able to work independently through all three Outcomes,
with your guidance to ensure that their work is focussed.
The requirements for all Outcomes are met through the Assessment Pack for this unit. All
this information is summarised as follows:
The suggested number of hours for each section includes time for an introduction to the
topic, discussion and exemplification of concepts, practical work, reading and assessment.
An easy-to-read book which covers the basic concepts of systems analysis and design and
why it should be carried out, through to the different stages of SSADM. Lots of helpful
examples.
Systems Analysis and Design, Don Yeates, Maura Shields and David Helmy
Financial Times Prentice Hall, 1994, £26.99, ISBN: 0273600664
This book provides information on the activities involved in the analysis, design and
implementation of computer-based information systems. It includes an SSADM-based
case study which puts the principles and techniques to practical use.
Structured Systems Analysis: Tools and Techniques, Chris Gane and T Sarson
McDonnell Douglas, 1977, ISBN: 0686376765
One of the first books on structured systems analysis and, after nearly 25 years, still one of
the best. Excellent explanations of Data Flow Diagrams and Data Dictionaries.
Unfortunately, this book was out-of-print at the time of writing, but you may still be able
to find one in a second-hand book shop or a library.
Student Notes
You should spend around 10 hours on this outcome, including the unit assessments.
Outcome 2 – You will learn about the analysis and documentation of a simple and familiar
manual system. On completion of this Outcome you should be aware of a variety of data
gathering and recording techniques, e.g. interviewing, questionnaires, discussion reports.
However, it is likely that only one technique will be used to any great extent. You should
also be aware of the techniques used to formalise procedure descriptions (e.g. narrative,
structured English, structure diagrams etc.) and be able to use at least one of these. This
Outcome is illustrated by a Case Study which continues in to the next section.
You should spend around 15 hours on this outcome, including the unit assessments.
Outcome 3 – You will learn about the design of a simple computerised information
system. On completion of this outcome you should be able to produce a system
specification consisting of a system outline (inputs, files, processes and outputs), data flow
diagrams, a data dictionary and file structures (showing field size and type). Only first-
level data flow diagrams are required. You are not required to normalise files. Where
normalised files are required to produce a meaningful system, details of these will be
supplied by your tutor. This outcome is illustrated by a Case Study which continues from
the previous section.
You should spend around 15 hours on this outcome, including the unit assessments.
The first assessment can be completed can early in the unit since the descriptions involved
in Outcome 1 will be covered during the initial stages of the unit. The second assessment
will be carried out over an extended period of time during the remainder of the unit.
An easy-to-read book which covers the basic concepts of systems analysis and design and
why it should be carried out, through to the different stages of SSADM. Lots of helpful
examples.
Systems Analysis and Design, Don Yeates, Maura Shields and David Helmy
Financial Times Prentice Hall, 1994, £26.99, ISBN: 0273600664
This book provides information on the activities involved in the analysis, design and
implementation of computer-based information systems. It includes an SSADM-based
case study which puts the principles and techniques to practical use.
Structured Systems Analysis: Tools and Techniques, Chris Gane and T Sarson
McDonnell Douglas, 1977, ISBN: 0686376765
One of the first books on structured systems analysis and, after nearly 25 years, still one of
the best. Excellent explanations of Data Flow Diagrams and Data Dictionaries.
Unfortunately, this book was out-of-print at the time of writing, but you may still be able
to find one in a second-hand bookshop or a library.
Study Materials
1.1 Introduction
Systems Analysis and Design is the process of investigating an existing system (often a
manual system) and designing a new replacement system (usually a computerised system)
to carry out the same functions. Systems projects are complex and can last for many
months, or even years. People who work in this area are known as Systems Analysts or
Systems Designers. In these notes, we will use the term "Systems Analyst", or simply
"Analyst" to refer to the person who carries out both Analysis and Design.
Analysts require various skills. They must have social and interpersonal skills such as
diplomacy and the ability to put people at ease, as well as being technically competent in
order to translate user requirements into successful computer-based systems.
Analysts often begin their career as Computer Programmers, before moving into Analysis.
Some organisations employ Analyst Programmers, who do both Programming and
Analysis. However, some analysts start from a functional area, such as Sales or Finance
and are trained in Computing concepts before transferring to Analysis.
A systems project normally begins with Terms of Reference provided by the user.
These outline the scope of the system to be investigated and specify any constraints under
which the analyst must work. For example, a new system may have to run on existing
hardware, or may have restrictions on file formats to ensure compatibility with other
systems. If the system is a complex one, a Feasibility Study may be carried out to ensure
that it is worth developing a new system and draw up the terms of reference.
During our discussions of this area, you're likely to come across some unfamiliar terms, or
familiar ones used in a different context. Some of these are listed below:
• information: data with some structure imposed upon it, e.g. by grouping items
together into records and/or by sorting in some order;
• system: a group of procedures which operate together as a coherent whole to carry out
a specified task. Systems may be either manual or computerised. A computerised
system may incorporate manual elements and will certainly have hardware and
software components;
• sub-system: a constituent part of a system which carries out some clearly defined
subtask;
• systems design: a breakdown of the system specification into logical and physical
components;
• interface: the connections between the system and its environment or other related
systems, e.g. the link between an order acceptance system and an invoicing system;
Analysis
Once the scope of the study has been agreed, a detailed investigation is undertaken to
determine the operations carried out by the current system and the requirements for the
new system. This will involve speaking with the users of the current system and
examining all the paperwork involved.
Design
Design is the process of specifying the new system. This details the tasks to be carried
out and the data to be input, output and stored on files. Initially a logical design is
produced, specifying the functions to be carried out by the new system without tying these
down to specific hardware or software. Then a physical design is produced, giving
precise details of hardware, software, file formats etc.
Implementation
Implementation includes software development (programming) and the changeover to the
new system. This can take place all at once or in stages. Implementation also includes
training users in the operation of the new system.
Testing
Testing includes program testing, to ensure that the individual programs work correctly
in isolation and system or integration testing to ensure that the programs work together
correctly as a complete system. The analyst carries out both these types of testing. The
final stage is acceptance testing, which is carried out by the user to ensure that the system
meets the specified requirements.
Maintenance
Maintenance ids the process of amending a system after it is up and running. This
includes both ad-hoc amendments to deal with undiscovered bugs as well as planned
maintenance to cope with changing circumstances within the organisation (e.g. addition
of new product ranges) or the environment (e.g. changes in tax structure).
The systems analysis and design cycle does not necessarily progress in a linear fashion,
with each completed leading directly the next phase. It is often necessary to go back to a
previous phase if continuing to the next phase would result in improper analysis, design or
implementation. It is common to return to the analysis phase several times before
completing the design phase, because these two are closely related. This process of
iteration and revision is normal in most systems projects.
The most important source information is the end users of the current system, who are
often also the potential users of the new system. They may range from novices to
highly-skilled individuals. The information gathered from end users will be crucial
during the analysis and design phases. Later, the analyst will also discuss technical
aspects of the system with programmers, network engineers and other technical staff.
A secondary source of information for the analyst can be found in the existing paper work
or documents within the organisation. Documents represent the formal information flow
through the current system. The analyst must collect sample copies of all relevant
documents, e.g. input forms, output documents, reports, invoices etc to understand how
data flows and is used in the current system. This information can be important in the
subsequent design of files for the new system.
All the information gathered by the analyst must be recorded in a suitable format. Most
organisations have standards specifying how this should be done. This often amounts to
the use of a standard set of forms, similar to those you will use during this course.
Interviewing
Interviewing is the commonest and most effective technique. An interview is an
exchange of information between the analyst and the end user. It is planned in advance
and has a specific purpose.
There are two basic types of questions: open ended and closed ended. Open-ended
questions are neutral and non-restrictive. They allow interviewees to answer questions
in any way they wish, and they encourage them to reveal information. For example:
Closed-ended questions are specific and provide the interviewer with greater control
over the interview. However, they achieve only what they ask and discourage
interviewees from opening up and revealing relevant information which the interviewer
did not anticipate. For example:
The interviewer must take care that closed-ended questions are not loaded or leading.
Questions can be sub-divided into two categories: primary and secondary; both can be
open or closed-ended. Primary Questions address a specific topic. Secondary
Questions are follow-up questions designed to obtain more information than was given in
response to a Primary question.
Questionnaires
Questionnaires allow the analyst to collect information from a large number of people,
possibly spread over several sites. Standardised question formats can yield more reliable
data than other fact-finding techniques, and wide distribution ensures that respondents
remain anonymous. This can lead to more honest responses.
However, questionnaires don't let the analyst see the expressions or reactions of
respondents. Respondents may not complete questionnaires as a high-priority task. If
everyone doesn't reply, the respondents can become a self-selected group, which can lead
to problems with data reliability.
Questionnaires are expensive to develop and distribute. Analysts must consider the
objectives of the questionnaire and determine what structure will be most useful and
easiest to understand. Questionnaires should be tested before being printed and
distributed.
Questionnaire recipients should be selected for the information they can provide. The
analyst should make sure that they have the background and experience to enable them to
answer the questions.
Observation
Observation is another technique used to gather information by observing people
performing various aspects of their jobs. It allows the analyst to determine what is being
done, how it is being done, who does it, when it is done, how long it takes, where it is
done and why it is done.
Consistency Checking
The analyst must check that information obtained from different sources is consistent. In
general, information should be obtained from at least two sources to allow consistency
checks to be carried out. Any inconsistencies must be investigated. It is unlikely
(although not unknown) that anyone will deliberately supply an analyst with wrong
information. However, different people do have different knowledge and different
memories of events, so inconsistencies often occur.
The analyst will also have to describe the processes involved in the current system. One
way of doing this is by a simple narrative, i.e. a few paragraphs of every day English.
Other methods include the use of Structure Diagrams, a graphical technique derived from
structured programming, or Structured English, a more rigorous form of English, which is
written in a similar manner to a programming language. Both of these techniques are
described in more detail in the next section.
The symbols used in these notes are based on those recommended by the National Centre
for Information Technology (NCC). Templates of the symbols are readily available.
This section introduces the basic concepts of DFDs. More detailed examples of their use
are given in subsequent sections. DFDs show the movement of data or goods through a
system. They make use of five basic symbols:
Data Flows
A data flow is a route that allows data to travel from one location to another. It is
represented by a line, with an arrowhead showing the direction of flow. Data can flow
from a source to a process, from one process to another, or from a process to a data store
or destination. Each data flow should be given a unique descriptive title.
Physical Flows
A physical flow is a route which allows goods or materials to travel from one location to
another. It is represented by a heavier line (or sometimes a double line) with an
arrowhead showing the direction of flow. Goods can flow from a source to a process,
from one process to another, or from a process to a destination. Each physical flow
should be given a unique descriptive title.
Processes
Processes show actions or transformations carried out on data. They are represented by a
rectangle and should have an incoming data flow and an outgoing data flow.
Processes should also be given descriptive names, ideally in the form of a verb followed
by an object, e.g. ‘calculate total price’. They are often numbered to aid identification.
Data stores show collections of data, e.g. manual or computer files. They are represented
by a narrow rectangle with one end left open. They should be given simple, descriptive
names. The same data store may appear more than once on a DFD to simplify the
diagram and avoid crossing data flows.
External Entities
External entities include sources and destinations. Sources are the origins of data or
goods and destinations their ultimate end point. They are represented by an oval or
lozenge shape and should be given simple, meaningful names.
Sources and destinations are outwith the boundaries of the system. They show how data
and goods initially enter the system and how they leave the system. A source or
destination may appear more than once on a DFD to simplify the diagram and avoid
crossing data flows.
Levelling DFDs
DFDs are used an a hierarchical fashion. Each process can be exploded into a lower-level
DFD, giving a series of DFDs showing increasing levels of detail.
Different levels of DFD can be used in discussing the system with different grades of
staff, e.g. the highest level diagrams may be used in discussion with senior management,
while the lower levels are used with line managers.
The highest level of DFDs are usually referred to as Level 0, with lower levels being
Level 1, Level 2 etc., down to the required level of detail. Level 0 diagrams are
sometimes known as context diagrams.
Numbering must be kept consistent in the different levels of diagram, e.g. a process
numbered 2 in the Level 0 diagram may be broken down into three processes, numbered
2.1, 2.2 and 2.3 in the Level 1 diagram. Process 2.2 may be further decomposed to 2.2.1
and 2.2.2 in the level 2 diagram.
It is essential to ensure that all the flows and stores connected to a process in a higher level
diagram also appear in the lower-level DFDs. Similarly, no new flows or stores should
be introduced in the lower-level DFDs. If these turn out to be necessary, the higher level
DFDs must be amended to include them.
Choose an input from a source or an output to a sink and insert a box where a process is
required to transform data in some manner. Check whether all the required data is flowing
into the process to carry out the desired transformation and produce the required output - if
not, you may have to add additional input data flows. DFDs can be useful in identifying
the need for additional data items that were not obvious from a verbal description.
Do your initial drafts freehand with a pencil. Your first draft will probably be wrong and
end up as a hopelessly tangled scribble.
It normally takes at least three drafts before a DFD starts to make sense.
Most processes should access a store of some kind - if this is not the case, check carefully
for mistakes or omissions.
DFDs are a useful modelling tool, which provides a clear indication of how data makes its
way through the system. However they lack the detail about data which is required at the
Systems Design stage. This detail is provided by the Data Dictionary, which we will look
at next.
• Logical Data Flow Diagrams: showing what the new system will do in outline.
These follow the same conventions as the data flow diagrams we used earlier.
• Data Dictionary: recording the new processes and data stores in the system;
• File Structure: showing how the data will be collected together into related files or
tables.
Logical DFDs can have two types of data stores, manual data stores and computerised
data stores. Manual data stores will contain physical objects such as stock, money or
paperwork, whereas the computerised data stores will contain the customer databases,
stock records etc. used by the new system.
The functions shown in the logical data flow diagrams will reflect the procedures which
are carried out by the new system. Titles might include:
• update database
There may be more function boxes in the new system than there were in the current
system. Function boxes represent the main functions carried out by the new system.
No analyst can carry all the details of a system in his head, so records are vital. The data
dictionary is an essential component of the analyst's record. The most important features
of a data dictionary are completeness and consistency.
• Description: a short description of the meaning of the data item, e.g. StockQuant =
quantity in stock
• Valid Range: specifies the boundaries of the data, e.g. 1 - 99 or AA000 - ZZ999
• Storage format: how the data is stored, e.g. integer, real, alphanumeric, alphabetic
A description should be given for each of data flow in the required logical level 1 DFD
which flow to or from an external entity. For each flow you should state:
Data Contents, i.e. information which is conveyed by the flow, e.g. for an Invoice
invoice number
date
description
amount
The files which may be designed are program files used in Pascal or COBOL which you
have designed to be written, or Application Package files such as Database or Spreadsheet.
Any files should have the fieldname, the length of the field to hold the longest entry, and
the type of the field entry e.g. numeric, alphanumeric, character or logical.
Customer Database
the files should be drawn with the headings and column details.
A short description of the purpose and use of each file should also be included.
1.3.6 Controls
It is essential in every computer system that control is taken over the security of the data,
procedures are in place for backup and security, and that there are measures to deal with
system failures. The areas to be addressed include:
• Archiving Policy
• Error Handling
• Audit Requirements
At this stage, the hardware for the system should have been selected and site preparation
commenced. When the equipment arrives everything should be ready for installation.
A programming team should be formed and should start by reviewing the design
specifications to ensure clear understanding before coding and testing start.
Staff may require acoustic privacy panels, printer enclosures and ergonomically designed
furniture and workstations. These should comply with the current Health and Safety
Regulations, including the Display Screen Equipment Regulations (1992).
Training Personnel
No system can function effectively unless all users are properly trained. Training
increases staff expertise and facilitates acceptance of the new system - an important factor
in a system's ultimate success. Three groups require training:
• mainstream users who will interact with the system to perform tasks;
• indirect users who require to know what the system can do.
Training should begin early enough to be completed around the same time as the system
becomes operational. Training increases user confidence and minimises disruption during
early stages of systems operation.
Training ranges from a brief tutorial showing one user how to perform a simple task to
training most of the users throughout the organisation for a major new system. A training
schedule must be drawn up to make efficient use of resources. Training may be provided
in-house or bought in from vendors or other outside suppliers.
• User Documentation: tells users how to use the system and perform tasks. This may
be on-line or contained in a procedures manual. Documentation also tells users how to
complete source documents and data entry screens, generate reports, and check the
validity of output. It should accurately reflect what users learned during training.
• Systems Documentation: shows what the system can do. It is a communication tool
for keeping everyone informed about the design of the system and provides
management with an accurate basis for reviewing and evaluating the system design.
• Operations documentation: this gives the computer operators the information that is
required to change files, disks etc. It contains key information and diagrams about the
operational aspects of the system.
• Parallel Conversion: both systems are run side-by-side for an agreed period. This
gives some protection against the failure of the new system, since the output from the
existing system can always be used.
1.3.11 Testing
At least three levels of testing are required for a new system:
• Program Testing: this is normally carried out by the programmers who write the
system. Each individual program is tested in isolation to ensure that it performs
properly, i.e. valid items of data are processed correctly and produce the right output,
while invalid items of data are rejected with a meaningful error message.
• Integration Testing: this is usually carried out under the supervision of the systems
analyst to ensure that all the programs making up the system work together correctly,
i.e. the data output from one program can be used successfully as input data to the
next. This area is notorious for uncovering problems due to differing interpretations of
program specifications.
• Acceptance Testing: is carried out by the users, to ensure that the new system meets
user requirements under operating conditions. The test group should include a sample
of those who will work with the new system. Acceptance testing is the last chance to
make changes before the software goes live.
Test Data
There are two different types of test data - live and artificial. Each has its own advantages
and disadvantages.
• Live Data: live test data is the data actually used by an organisation. An analyst may
ask users to enter data from their normal activities. It can be difficult to obtain enough
live data to test a system rigorously. Live data doesn't usually contain a high
proportion of errors, so it doesn’t test all combinations of data which can enter the
system.
• Artificial Data: artificial test data is created purely for testing purposes. It can be
generated to test all combinations of formats and values, including all possible error
conditions. This type of data can be often be produced by a test data generator
program which will test all the logic paths in the system.
The information obtained during the post-implementation review is used to perform initial
maintenance. After this, periodic reviews and user requests will be the principal sources
of requests for maintenance.
After initial maintenance is carried out, the maintenance workload should decline.
However, after some years, the number of maintenance requests is likely to rise,
increasing the cost of maintenance and the effort involved. When a system becomes a
major problem to users, the whole cycle begins again and a new system is developed.
The cost of software maintenance is increasing steadily. Some organisations are now
estimated to spend 80% of their systems budget on maintenance. In extreme cases the
entire budget can be spent in this area and no new systems are developed.
Maintaining Hardware
Hardware maintenance is an important element of any maintenance schedule. It is
normally preventative maintenance involving the repair, replacement or addition of parts
and components to keep the hardware in working order.
Maintenance requirements can often lead to a repeat of several previous stages. For
example, a change in the format of telephone numbers could lead to changes in input
design, output design and file design, followed by implementation and testing.
The systems analysis and design cycle is often described as being iterative in nature. This
is because it is always possible to backtrack to earlier stages and that stages can be
repeated as often as required until all the objectives of the system have been achieved.
2.1 Introduction
This part of the course involves the analysis and documentation of a manual information
system. The system to be investigated will be simple and familiar e.g. systems for use in a
video rental shop or a record store. The case study we will use involves a book supplier,
Beltane Books.
A variety of data gathering and recording techniques can be used, e.g. interviewing,
questionnaires, discussion reports. However, it is likely that only one technique will be
used to any great extent.
Order Entry
Most customers submit their orders on a standard Order Form (Doc1) which goes initially
to the Order Entry department.
If the customer phones in an order, it is taken down by Order Entry staff on the standard
Order Form.
If a customer sends in an order in the form of a letter or fax, rather than the standard Order
Form, the details are transferred to an Order Form.
The Order Forms are then passed to the Order Processing Department.
Order Processing
Details of the books in stock are held on Book Cards (Doc 2), filed in Book Code order.
If a book is in stock, a Despatch Request (Doc3) is passed to the Despatch Department and
the quantity in stock on the Book Card is decreased by the quantity ordered.
If the quantity remaining in stock is less than the Reorder Level, a Reorder Request
(Doc4) is sent to the Book Orders department.
If the book is not in stock, a Book Unavailable Note (Doc5) is sent to the Customer.
Despatch Department
When a Despatch Note arrives, the books are located, packed and posted off to the
customer. The Despatch Date is marked on the Despatch Note, which is then passed to the
Accounts Department to allow the customer to be invoiced.
Problem Areas
The company has now become overwhelmed with work and wishes to improve its
efficiency by computerising operations, starting with Order Processing. Your task is to
investigate and record the operation of the existing Order Processing system and to design
a computerised replacement system which can easily be extended to incorporate other
aspects of the company's activities.
You can assume that the company has an adequate accounting system in operation and
you need not bother with issues relating to the billing of customers.
Doc1
BELTANE BOOKS ORDER FORM
CUSTOMER DETAILS
BOOK DETAILS
Doc2
BELTANE BOOKS BOOK CARD
Doc3
BELTANE BOOKS DESPATCH NOTE
CUSTOMER DETAILS
BOOK DETAILS
Doc4
BELTANE BOOKS REORDER REQUEST
BOOK DETAILS
<date>
<Customer Name>
<Address 1>
<Address 2>
<Address 3>
<Postcode>
Dear <Customer>
Thank you for your valued order. Unfortunately the undernoted books are no longer
available. You may wish to resubmit your order after a couple of months to see if we have
been able to obtain additional copies. Otherwise we suggest that you try a reputable
second-hand bookseller if you still wish to obtain them.
Yours faithfully,
Colin Gilchrist
Order Processing Manager
Keep in mind that this is a slightly artificial situation. In the real world, the information
given in the case study would be obtained by the techniques described earlier. The most
useful techniques would be interviewing and observation, since the organisation is too
small for questionnaires to be of any real use.
External Entities
Sources: these are the places where data arises, outwith the system boundary. In this case
there is only one sources, the Customers who order books.
Destinations: where data or goods finally end up, outwith the system boundary.
Customers are a destination, since books go to there. The Accounts Department is a
destination, since details of the books supplied to customers are sent there. The Book
Orders department is also a destination.
Data Stores
These are the places where data is stored, temporarily or permanently within the system.
There is only one data store in this system, the Book File, consisting of the Book Cards
with details of the books held in stock.
Data Flows
There are a number of Data Flows in this system:
Physical Flows
There is only one physical flow in the system:
Order Entry
Order Processing
Despatch
Subsystems
There are two distinct subsystems in the current system:
Order Entry and Processing
Despatch
All the information gathered at this stage should be summarised on Proforma 1 (overleaf).
Stores:
Book File
Processes:
Order Entry Order Processing
Despatch
Sub-systems:
Order Entry and Processing Despatch
Data Flows:
Customer Orders Customers -> Order Entry
Order Forms Order Entry -> Order Processing
Reorder Requests Order Processing -> Book Orders
Book Unavailable Notes Order Processing -> Customers
Despatch Notes Order Processing -> Despatch
Completed Despatch Notes Order Processing -> Accounts
Physical Flows:
Books Despatch -> Customer
(note that we have combined two data flows into one here, as both
take place within the Order Entry and Processing subsystem)
These data flows, plus the physical flow (Books flowing from Despatch to Customers)
should be recorded on a data flow diagram using Proforma 2 (overleaf)
The Book File is referenced (and possibly updated) by Order Processing, so there is a
bi-directional data flow of Book Details.
Despatch
Completed Accounts
Despatch
Notes
Book File
Structure Diagrams
It is sometimes useful to have a graphical representation of the structure of a process. We
can diagrams known a structure charts. A problem can often be more readily understood
when it is broken down into a more concise and less complex format.
Sequence
A sequence is a group of actions which are carried out in a linear fashion, one after the
other. In a structure diagram this is represented as follows:
B C D
This diagram shows module A, which calls modules B, C and D (in that sequence).
*
B
This diagram shows a program module A, which calls module B a number of times. The
asterisk (*) indicates a repeated component.
Selection
Selection implies a choice between a number of options. In programming terms this
usually appears as an if ... else statement if the number of options is restricted to one or
two, or a case statement (Pascal) or switch statement (C) if the number of options is
larger. Selection is represented in a structure diagram as follows:
O O O
B C D
Structured English
Structured English (sometimes referred to as pseudocode) is a tool used to clarify program
design. It involves writing down a solution to a problem in a clear, unambiguous style.
This style is similar to the structure of a programming language without using the exact
syntax (or grammar) of any specific language.
Structured English is rather subjective and depends to a great extent on the analyst.
However, when properly used it is a valuable aid in process design. Its use may be
illustrated using a non-computing problem:
Structured English
if it is raining then
go to work by car
have lunch in office
else
walk to work
have lunch in park
endif
go jogging
• it can be long-winded;
• it is ambiguous;
• it is difficult to maintain.
Structured English is not an exact science. Most analysts develop their own personal
version, usually related to the programming language they are most familiar with.
Data Store 2:
Most customers submit their orders on a standard Order Form (Doc1). If the customer
phones in an order, it is taken down on the standard Order Form.
The Order Forms are then passed to the Order Processing Department.
Details of the books in stock are held on Book Cards (Doc 2), filed in Book Code order.
If a book is in stock, a Despatch Note (Doc3) is passed to the Despatch Department and
the quantity in stock on the Book Card is decreased by the quantity ordered.
If the quantity remaining in stock is less than the Reorder Level, a Reorder Request
(Doc4) is sent to Book Orders.
If a book is not in stock a Book Unavailable Note (Doc5) is sent to the customer.
Process 3: Despatch
When a Despatch Request arrives, the books are located, packed and posted off to the
customer.
A Despatch Note (Doc9) is passed to the Accounts Department to allow the customer to
be invoiced.
Process 4:
• Fill Customer Orders, update the Book File and supply details of books to Despatch;
This completes the Systems Analysis component of the Case Study. We are now ready to
proceed to Systems Design.
User Requirements:
• Fill Customer Orders, update the Book File and supply details of books to Despatch;
This part of the course involves the design of a computerised information system. Once
again, the system considered should be simple and familiar. We will continue with the
Beltane Books Case Study.
The system specification consists of a system outline (inputs, files, processes and outputs),
data flow diagrams, a data dictionary and file structures (showing field size and type).
Only first-level data flow diagrams are required.
Students are not required to normalise files. Where normalised files are required to
produce a meaningful system, details of these should be supplied by the tutor. These
details should consist of a list of the data items to be included in each file. It should be left
to the student to determine the size and type of each data item.
System Outline
As with the manual system, the only Source of information is the Customers who submit
Book Orders. The only Destination is the Customers who receive books. However, some
of the Destinations shown in the manual system (e.g. Accounts Department and Book
Orders) will eventually make use of information which is now stored in files. This takes
place outwith the boundaries of the Order Processing system.
The biggest change from the manual system is the number of Stores or files involved. The
only file used in the manual system was the Book File. This continues to exist in the
computer system and has virtually the same format (see Proforma 2b). This is read and
updated by the Order Processing process.
Customer details are now held on a Customer File (Proforma 2a). This is assumed to be
maintained outwith the Order Processing System. The Despatch process accesses this file
in order to obtain address information to send books out to Customers.
Customer Orders are now written to an Orders File (Proforma2c). This is written by the
Order Entry process and will contain all orders, whether received as Order Forms or by
letter, telephone or fax. It is read by the Order Processing process.
Details of the books to be despatched to customers are held on the Despatch File
(Proforma 2d). This is almost identical in format to the Orders File, but has an additional
field to hold the Despatch Date. It is written by the Orders Processing process.
Details of books to be reordered are written to the Reorder File (Proforma 2e) by the Order
Processing process. This information can be accessed by Book Orders who do the actual
reordering, outwith the Order Processing system. Note: reordering of goods is a
notoriously difficult process to automate. Requests must be examined manually to see
whether or not reordering is advisable. For example, if a book is declining in popularity, it
may be as well to cancel the reorder, or reduce the reorder quantity. On the other hand, if
a book is selling better than expected it may be useful to increase the reorder quantity.
Order Entry: writes all Orders (however received) to the Orders File.
Order Processing: checks whether book is in stock and if so, updates the Stock Quantity
on the Book File and writes a record to the Despatch File. If the Stock Quantity drops
below the Reorder Level, a Reorder Request is written to the Reorder File.
Despatch: locates books, packs them and sends them to the customer. Updates the
Despatch File with the Despatch Date. (This file can be used later to generate invoices,
but this is outwith the boundary of the Order Processing system.)
System Outline
Enter the components of the proposed computer system in the boxes below:
Sources:
Customers
Destinations:
Customers
Stores:
Customer File
Book File
Order File
Reorder File
Despatch File
Processes:
Order Entry
Order Processing
Despatch
*+,-./
SYSTEMS ANALYSIS AND DESIGN (ADVANCED HIGHER)
Customers
Orders
Order
Entry Orders
Book
Unavailable Orders File
Notes
Orders
Order
Processing Reorder
Details
Reorder File
Despatch
Details
Despatch
Despatch Despatch File
Details
*+,-./
SYSTEMS ANALYSIS AND DESIGN (ADVANCED HIGHER)
Data Dictionary
Data Name Description Valid Range Storage Format
Custno Customer Number 00000 - 99999 Character
Title Customer Title Mr., Mrs., Ms. Character
Surname Customer Surname Alphabetic Character
Initials Customer Initials Alphabetic Character
Address1 Customer Address - 1 Alphanumeric Character
Address2 Customer Address - 2 Alphanumeric Character
Address3 Customer Address - 3 Alphanumeric Character
Postcode Customer Post Code Alphanumeric Character
Telephone Customer Telephone No. Numeric Character
Bookcode Book Code 00000 - 99999 Character
Author Author Alphabetic Character
Title Title Alphanumeric Character
Publisher Publisher Alphabetic Character
Suppcode Supplier Code 00000 - 99999 Character
Pubdate Publication Date dd/mm/yyyy Character
ISBN ISBN Alphanumeric Character
Stock Stock Quantity 000 - 999 Numeric
Onorder Quantity on Order 000 - 999 Numeric
Reorder Reorder Level 000 - 999 Numeric
Reordate Reorder Date dd/mm/yyyy Character
Rprice Retail Price 000.00 - 999.99 Numeric
Wprice Wholesale Price 000.00 - 999.99 Numeric
Ordno Order Number AA0000 - ZZ0000 Character
Ordate Order Date dd/mm/yyyy Character
Despdate Despatch Date dd/mm/yyyy Character
Ordquant Quantity Ordered 00 - 99 Numeric
Reordquant Reorder Quantity 000 – 999 Numeric
*+,-./
SYSTEMS ANALYSIS AND DESIGN (ADVANCED HIGHER)
Custno 5 Character
Title 4 Character
Surname 20 Character
Initials 4 Character
Address1 25 Character
Address2 25 Character
Address3 25 Character
Postcode 6 Character
Telephone 15 Character
Author 20 Character
Title 30 Character
Publisher 20 Character
Suppcode 6 Character
Pubdate 10 Character
ISBN 12 Character
Stock 2 Numeric
Onorder 2 Numeric
Reorder 2 Numeric
Ordate 10 Character
Rprice 2 Numeric
Wprice 2 Numeric
Ordno 6 Character
Ordate 10 Character
Custno 5 Character
Ordquant 2 Numeric
Ordno 6 Character
Ordate 10 Character
Custno 5 Character
Ordquant 2 Numeric
Despdate 10 Character
Bookcode 5 Character
Reordquant 2 Numeric