Business Information Systems
Technology, Development and Management for the Modern Business
6th edition
Chapter 10
Systems analysis
Copyright © 2019, 2015, 2008 Pearson Education, Inc. All Rights Reserved
Documenting the Findings
❑In this section we will concentrate on three main diagramming tools:
➢Information flow diagrams (IFDs),
➢Dataflow diagrams (DFDs)
➢Entity relationship diagrams (ERDs).
• These techniques are used by professional IS/IT personnel, partly as documentation
tools and partly as checking tools with the user community.
• Furthermore, tools such as ERDs can be applied by end-users to assist them in
developing their own personal or departmental applications.
• As well as these tools, the requirements specification will also contain a text
description of what the functions of the software will be
Copyright © 2019, 2015, 2008 Pearson Education, Inc. All Rights Reserved
The Requirements Specifications
• The requirements specification is the main output from the systems analysis
stage.
• Its main focus is a description of what all the functions of the software will be.
• These must be defined in great detail to ensure that when the specification is
passed on to the designers, the system is what the users require.
Copyright © 2019, 2015, 2008 Pearson Education, Inc. All Rights Reserved
The Scope of Requirements Determination
• Data capture – when, where and how often. The detailed data requirements
will be specified using entity relationship diagrams and stored in a data
dictionary.
• Preferred data capture methods – this may include use of keyboard entry,
bar codes, OCR, etc.
• Functional requirements – what operations the software must be able to
perform.
• User interface layout – users will want access to particular functions in a
single screen, so the requirements specification will define the main screens of
an application.
• Output requirements – this will include such things as enquiry screens,
regular standard and ad hoc reports and interfaces to other systems
Copyright © 2019, 2015, 2008 Pearson Education, Inc. All Rights Reserved
Requirements types
❑There are three main aspects that need to be documented, usually from a user
perspective:
• Functional requirements: Consist of requirements that perform the activities that
run the business. Examples include updating master files, enquiring against data on
file, producing reports and communicating with other systems.
• Non-functional requirements: Define the performance levels of the business
functions to be supported. Examples include online response times, turn-round time
for batch processing, security, backup and recovery.
• Quantification of requirements: Refers to the need for a measure of quality if the
benefits are to be properly evaluated. Examples might include reducing customer
complaints by 75 per cent, reducing the value of unsold stock by 85 per cent or
increasing online sales by 25 per cent.
Copyright © 2019, 2015, 2008 Pearson Education, Inc. All Rights Reserved
Figure 10.2
Example of a requirements catalogue entry
Copyright © 2019, 2015, 2008 Pearson Education, Inc. All Rights Reserved
Note that: The purpose of the requirements catalogue is to act as
the repository of all requirements information. It can be used from
the initiation stage when early thoughts are being gathered about
the possible requirements, through to the design stage when user
requirements may still be emerging
Copyright © 2019, 2015, 2008 Pearson Education, Inc. All Rights Reserved
Documentation tools: (1) Information Flow
Diagrams (IFDs)
❑Information flow diagram (IFD): A simple diagram showing how information is
routed between different parts of an organisation. It has an information focus rather
than a process focus.
❑Purpose:
• To document the main flows of information around the organisation;
• For the analyst to check that they have understood those flows and that none has
been omitted;
• For the analyst to use during the fact-finding process itself as an accurate and
efficient way to document findings as they are identified;
• As a high-level (not detailed) tool to document information flows within the
organisation as a whole or a lower-level tool to document an individual functional
area of the business.
Copyright © 2019, 2015, 2008 Pearson Education, Inc. All Rights Reserved
Figure 10.3
Information flow diagrams – the basic building blocks
Copyright © 2019, 2015, 2008 Pearson Education, Inc. All Rights Reserved
Documentation tools: (1)Information Flow
Diagrams (IFDs)
• An information flow diagram has three components, shown in Figure 10.3. The
ellipse in the diagram represents a source of information, which then flows to a
destination location.
• In a high-level diagram, the source or destination would be a department or specific
functional area of the business such as sales, accounting or manufacturing
• In a lower-level (more detailed) diagram, one might refer to subfunctions such as
accounts receivable, credit control or payroll (as you would normally find in an
accounts department).
• The name of the source or destination should appear inside the ellipse.
• The source or destination is sometimes referred to as an ‘internal’ or ‘external
entity’ according to whether it lies inside or outside the system boundary.
Copyright © 2019, 2015, 2008 Pearson Education, Inc. All Rights Reserved
• Note that: A high level Diagram provides a broad view of the entire
system. It’s like a roadmap that outlines the overall plan. A Low level
Diagram delves into the specifics. It’s like a magnifying glass focused on
individual components or modules.
Copyright © 2019, 2015, 2008 Pearson Education, Inc. All Rights Reserved
• The information flow, as represented by
the arrowhead line, shows a flow of
information from a source location to a
destination.
• In an IFD the line should always be
annotated with a brief description of the
information flow.
Figure 10.4
• So, for example, if a sales department An illustration of a simple information flow
sends a customer’s order details to the
accounts department for credit
checking, the resulting flow might look
like Figure 10.4
Copyright © 2019, 2015, 2008 Pearson Education, Inc. All Rights Reserved
Example on Information Flow Diagrams
• Suppose we have a university system, and we want to visualize how student information
moves between different departments.
• Information Flow in a University:
[Link] submits application → Admission Office
[Link] Office processes application → Sends acceptance/rejection info to Student &
Registrar
[Link] records accepted students → Shares student data with Finance & Course
Enrollment system
[Link] department manages student payments → Sends fee status to Registrar
[Link] Enrollment system → Provides student details to Professors
• This IFD helps ensure all necessary information flows are accounted for.
Copyright © 2019, 2015, 2008 Pearson Education, Inc. All Rights Reserved
Example On Information Flow Diagrams
• Suppose that a university wished to move from a manual, paper-based
student records system to one that was computerized.
• The analyst would need to create a clear picture of the required information
flows to help the system designer with the blueprint for the proposed system.
• When a student enrols for the first time, they are required to fill in a form
which has some details (i.e. Forename, surname, date, home address,
telephone number, gender, course code, course description, etc).
• When the information have been completed, they are passed to the Student
Information center (SIC).
• A series of actions are taken afterwards, as follows.
Copyright © 2019, 2015, 2008 Pearson Education, Inc. All Rights Reserved
Example On Information Flow Diagrams
➢ (SIC) allocates the student a unique code number which stays with the student until they complete
their studies.
➢ SIC creates a card index of the student’s details down to and including course description, plus the
new student code number.
➢ SIC also creates a list of all students belonging to each local education authority (LEA).
➢ SIC sends the LEA list to the finance department, which then invoices the LEAs for the tuition fees
relating to the students from their area.
➢ SIC creates a study record card (SRC), giving the student details and the modules being studied.
➢ SRCs for each course are then sent to the department that runs that course.
➢ Each department will take the SRCs for its courses and produce a number of class lists, based
around the modules that the student is studying, which are then passed to the relevant module
leaders
➢ The SIC will pass a list of all new students to the library and the students’ union so that the library
can issue students with library cards
Copyright © 2019, 2015, 2008 Pearson Education, Inc. All Rights Reserved
Documentation tools: (1) Information Flow
Diagrams (IFDs)
• It is necessary to translate the above into a series of information flows and also
define the systems boundary (i.e. the line that separates what is in the system
under consideration from what is outside it).
• In order to be successful in drawing IFDs, it is helpful to follow a few simple
steps, since an attempt to draw a diagram from scratch may prove a little
tricky:
Copyright © 2019, 2015, 2008 Pearson Education, Inc. All Rights Reserved
Documentation tools: (1)Information Flow
Diagrams (IFDs)
❑To draw an IFD:
Step 1: List all the sources of information for the system under consideration (in other
words, places where information is generated).
Step 2: List all the destinations (receivers) of information for the system under
consideration.
Step 3: Make a simple list of all the information flows.
Step 4: For each of the information flows identified in Step 3, add the source and
destination that relate to it.
Step 5: Draw the IFD from your list that you produced from 3 and 4.
Copyright © 2019, 2015, 2008 Pearson Education, Inc. All Rights Reserved
Figure 10.5
A simple, high-level IFD, excluding the system boundary
Copyright © 2019, 2015, 2008 Pearson Education, Inc. All Rights Reserved
Documentation tools: (1) Information Flow
Diagrams (IFDs)
• What remains now is to consider the systems boundary.
• If this manual information system were to be replaced by a new computer-based
information system, it would be necessary to identify what would be within the
systems boundary and what would be external to the system and, hence, outside
the system boundary.
Copyright © 2019, 2015, 2008 Pearson Education, Inc. All Rights Reserved
Documentation tools: (1) Information Flow
Diagrams (IFDs)
❑For example:
➢Students are external to the system – they provide information as an input to
the system and receive outputs from the system but are not themselves part of
it – students will, therefore, be outside the system boundary.
➢The student information centre is clearly central to the whole system and,
therefore, is an integral part of the system under consideration – the SIC will lie
inside the system boundary
Copyright © 2019, 2015, 2008 Pearson Education, Inc. All Rights Reserved
Figure 10.6 The completed IFD, including the system boundary
Copyright © 2019, 2015, 2008 Pearson Education, Inc. All Rights Reserved
Documentation Tools: (2) Context Diagrams
• Context diagrams are simplified diagrams that are useful for specifying the
boundaries and scope of the system.
• They can be readily produced after the information flow diagram since they
are a simplified version of the IFD showing the external entities.
❑They show these types of flow:
1. Flow crosses the system boundary from outside with its destination inside
the boundary – it is thus an input to the system from the external
environment.
2. Flow begins inside the system boundary and its destination lies outside – it
is, therefore, an output from the system into its external environment.
Copyright © 2019, 2015, 2008 Pearson Education, Inc. All Rights Reserved
Documentation Tools: (2) Context Diagrams
❑ The main elements of a context
diagram are:
• A circle representing the system to
be investigated;
• Ellipses (or boxes) representing
external entities;
• Information flows.
Figure 10.7
Context diagram for the student loan system
Copyright © 2019, 2015, 2008 Pearson Education, Inc. All Rights Reserved
Documentation Tools: (3) Dataflow Diagrams
• Dataflow diagrams (DFDs): Define the different processes in a system and
the information that forms the input and output of the processes.
• They may be drawn at different levels. Level 0 provides an overview of the
system with levels 1 and 2 providing progressively more details.
• Dataflow diagrams of different types are one of the mainstays of many
systems analysis and design methodologies.
• Dataflow diagrams build on IFDs by adding two new symbols as well as subtly
redefining others
Copyright © 2019, 2015, 2008 Pearson Education, Inc. All Rights Reserved
Documentation Tools: (3) Dataflow Diagrams
❑DFD Elements (Explanations of Symbols):
• Sources and sinks: an information source is one which provides data for a process
and is outside the system boundary. A sink lies outside the system boundary and is a
receiver of information.
• Processes: convert data into either usable information or data in a different form for
use in another process.
Datastores: A datastore can either provide data as input to a process or receive data
that have been output from a process.
• Dataflows: A dataflow describes the exchange of information and data between
datastores and processes and between processes and sources or sinks.
• Systems boundary: This remains the same as for an IFD – it indicates the boundary
between what lies inside the system under consideration and what lies outside.
Copyright © 2019, 2015, 2008 Pearson Education, Inc. All Rights Reserved
Documentation Tools: (3) Dataflow Diagrams
Figure 10.8
Symbols used in data flow diagrams
Copyright © 2019, 2015, 2008 Pearson Education, Inc. All Rights Reserved
Documentation Tools: (3) Dataflow Diagrams
❑To draw a basic high-level DFD, there are five steps required:
1. Identify and list all processes which take place in the system under consideration.
2. Identify all the datastores which you think exist in the system under consideration.
3. For each process identified in Step 1, identify where the information used in the
process comes from (this can be from a source or a datastore or both) and identify the
output(s) from that process (which can be an information flow to a sink or to a datastore
or to both).
4. Draw a ‘mini-DFD’ for each single process, showing the process box and any relevant
sources, sinks or datastores.
5. Link the mini-DFDs to form a single diagram, using the datastores to link the processes
together.
Copyright © 2019, 2015, 2008 Pearson Education, Inc. All Rights Reserved
Documentation Tools: (3) Dataflow Diagrams
• It is necessary to introduce the concept of ‘levelling’ in DFDs.
• For anything other than a very small system with a handful of processes, it
would be almost impossible to draw a single diagram with all the processes
on it.
• It is necessary, therefore, to begin with a high-level diagram with just the
broadest processes defined.
Copyright © 2019, 2015, 2008 Pearson Education, Inc. All Rights Reserved
Documentation Tools: (3) Dataflow Diagrams
• To illustrate the levelling concept
and also to demonstrate how
process boxes should be used, we
will take the simple example of
checking a customer order. At Level
1, the process box will appear as in
Figure 10.9.
• It is desirable to split this process up
into smaller components.
An example of level 1 process in a DFD
Copyright © 2019, 2015, 2008 Pearson Education, Inc. All Rights Reserved
Documentation Tools: (3) Dataflow Diagrams
❑For Example Suppose the following are identified:
• Check customer credit limit – can the customer pay
for the goods?
• Perform stock check – to see whether the desired
goods are in stock;
• Create sales order – this may be a special order form
that is needed for each order.
• Send order to warehouse – the warehouse will need
to pick the stock ready for delivery;
• Dispatch customer order.
• Invoice customer An example of level 2 process in a DFD
Copyright © 2019, 2015, 2008 Pearson Education, Inc. All Rights Reserved
Documentation Tools: (3) Dataflow Diagrams
• Note that the process number is 1.1. This indicates that the process has been
decomposed from the higher-level process numbered 1.
• Subsequent processes would be numbered 1.2, 1.3, 1.4, and so on.
• Also note that the process name begins with a verb. The choice of verb helps
indicate more clearly the type of process that is being performed.
• Suppose now that we still need to decompose the new process 1.1 further. For
example, the credit check process may involve these steps (calculate order
value, identify current balance, produce credit check result)
• We need to present the new processes as Level 3 processes, since they have
been decomposed from the higher Level 2 process. The first of these would
be represented as in Figure 10.11.
Copyright © 2019, 2015, 2008 Pearson Education, Inc. All Rights Reserved
Figure 10.11 An example of a Level 3 process in a DFD
Copyright © 2019, 2015, 2008 Pearson Education, Inc. All Rights Reserved
Documentation Tools: (3) Dataflow Diagrams
• We will now return to the student enrolment example.
• Step 1is to identify all the processes which exist.(i.e. allocate unique student
code, create student card index, create LEA index, create student record card,
create class list, issue enrolment form, Issue new students list)
• Step 2 requires us to identify all the datastores which might exist (i.e
student card index, LEA list, student card record, class list, new student list).
• Step 3 requires us to construct a ‘mini-DFD’ for each of the eight processes
identified above. We will restrict ourselves to the first three (see figures 10.12,
10.13, 10.14)
Copyright © 2019, 2015, 2008 Pearson Education, Inc. All Rights Reserved
Figure 10.12 Mini-DFD for process 1
Copyright © 2019, 2015, 2008 Pearson Education, Inc. All Rights Reserved
Figure 10.13 Mini-DFD for process 2
Copyright © 2019, 2015, 2008 Pearson Education, Inc. All Rights Reserved
Figure 10.14 Mini-DFD for process 3
Copyright © 2019, 2015, 2008 Pearson Education, Inc. All Rights Reserved
Documentation Tools: (3) Dataflow Diagrams
• You will see from the previous figures that each of the processes we have
considered has generated an output which forms an input to the next process.
• In the next full diagram in Figure 10.15 you will see the complete picture,
including all processes, datastores, sources and sinks.
• In this diagram, you will notice that the datastore ‘card index file’ appears
more than once.
• This does not mean that there are two separate datastores with the same
name, but it have been included for a second time to make the diagram easier
to draw.
Copyright © 2019, 2015, 2008 Pearson Education, Inc. All Rights Reserved
Figure 10.15 Completed DFD for the student records system
Copyright © 2019, 2015, 2008 Pearson Education, Inc. All Rights Reserved
Documentation Tools: (3) Dataflow Diagrams
❑The benefits to an organisation of constructing a dataflow diagram can
be summed up in the following ‘three Cs’:
• Communication: A diagram can be used by an analyst to communicate to
end-users the analyst’s understanding of the area under consideration.
• Completeness: A DFD can be scrutinised by functional area personnel to
check that the analyst has gained a complete picture of the business area
being investigated.
• Consistency: A DFD will represent the results of the fact-finding exercise
conducted by the analyst
Copyright © 2019, 2015, 2008 Pearson Education, Inc. All Rights Reserved
Documentation Tools: (4) Entity Relationship
Diagrams (ERDs)
• Entity relationship diagrams (ERDs) provide a data-focused view of the main
data objects or entities within a system such as a person, place or object and
the relationships between them.
• It is a high-level view and does not consider the detailed attributes or
characteristics of an object such as a person’s name or address.
• Entity: An object such as a person, place, thing or event about which we need
to capture and store data. An entity forms a data about a particular object.
• There are a number of possible relationships between entities; a
Copyright © 2019, 2015, 2008 Pearson Education, Inc. All Rights Reserved
Documentation Tools: (4) Entity Relationship
Diagrams (ERDs)
Figure 10.16
Essential symbols in an entity relationship diagram
Copyright © 2019, 2015, 2008 Pearson Education, Inc. All Rights Reserved
ERDs: One to One Relationships
• For each occurrence of entity A there
is one and only one occurrence of
entity B.
❑The relationship can be described
in two ways according to which
entity we refer to first. The
relationships are:
➢lecturer teaches module. Figure 10.17
A one-to-one relationship
➢ module is taught by lecturer.
Copyright © 2019, 2015, 2008 Pearson Education, Inc. All Rights Reserved
ERDs: One to Many Relationships
• For each occurrence of entity A,
there may be zero, one or many
occurrences of entity B.
• For example, a lecturer belongs to a
single division, but that division may
contain many lecturers (it may, of
course, have no staff at all if it has
Figure 10.18
only just been created or if all the A one-to-many relationship
staff decided to leave)
Copyright © 2019, 2015, 2008 Pearson Education, Inc. All Rights Reserved
ERDs: Many to Many Relationships
• For each occurrence of entity A,
there may be zero, one or many
occurrences of entity B, and for each
occurrence of entity B there may be
zero, one or many occurrences of
entity A.
• For example, a course module may
Figure 10.19
be taken by zero, one or many A many-to-many relationship
students and a student may take
zero, one or many course modules
Copyright © 2019, 2015, 2008 Pearson Education, Inc. All Rights Reserved
ERDs: Many to Many Relationships
• Unfortunately, especially in database
design, many-to-many relationships
can cause certain difficulties.
• Therefore, they are usually ‘resolved’
into two one-to-many relationships
through the creation of a ‘linking’
entity.
• The decomposition is shown in
Figure 10.20. The linking entity will
Figure 10.20
contain an item of data from each of A many-to-many relationship decomposed into two
the other entities which allows the one-to-many relationships
link to be made.
Copyright © 2019, 2015, 2008 Pearson Education, Inc. All Rights Reserved
ERDs: Many to Many Relationships
• Suppose that a nation has a professional hockey
league, comprising 16 clubs.
• Each club may only play in this one league.
• Each club may employ a number of professional
players
• Each professional player may only be contracted
to one club at a time.
• Any one player may only ever play for one
national team.
• Finally, suppose that professionals may have a
number of sponsors and that each sponsor may
sponsor a number of players. Figure 10.21
First ERD for the professional hockey example
Copyright © 2019, 2015, 2008 Pearson Education, Inc. All Rights Reserved
ERDs: Many to Many Relationships
• The only obvious difficulty here is the many-
to-many relationship between professional
player and sponsor.
• This can be resolved by introducing a
linking entity which contains something
common to both an individual player and
their sponsor.
• Thus, any one player may have many
sponsorship agreements, but any one
sponsor agreement will belong to one
player and to one sponsor. Figure 10.22
Final ERD for the professional hockey example
Copyright © 2019, 2015, 2008 Pearson Education, Inc. All Rights Reserved
End of Chapter
Thank you
Copyright © 2019, 2015, 2008 Pearson Education, Inc. All Rights Reserved