CPT 264 TTC Data Flow Diagram for Clothes Management Questions

Assignment 5,

Part A: Context Level Data Flow Diagram (DFD),

Part B: Level 1 Data Flow Diagram (DFD),

and Part C: Data Dictionary.

CPT264 ASSIGNMENT #5
(System Design Specification Sheet)
ASSOCIATED READING

Read Chapter 2 and Chapter 3 in your “Systems Analysis and Design” Textbook
Report Guidelines and Group Communication (10 points):
1.
2.
3.
4.
5.
6.
Your member name(s), date, and assignment # must be at the top of each page.
Each new section/part of your paper needs to have a title.
Text must be double-spaced.
Bullet points must be used where appropriate.
Insert page numbers at the bottom of each page.
There should be NO spelling, writing or grammar errors. Do not use slang or short-hand. Proper
grammar and sentence structure count.
7. The Group Discussion thread must be up-to-date and meet all reporting guidelines.
Part A: WORTH 30 POINTS—Context Level Data Flow Diagram (DFD)
a. Create a complete and accurate Context Level Data Flow Diagram of your intended
Information system.
b. Use the instructions and illustrations in your textbook and the sample in the module as a
guide.
c. Use MS Word to generate the correct shapes and arrows for your diagrams.
Part B: WORTH 35 POINTS— Level 1 Data Flow Diagram (DFD)
a. Create a complete and accurate Level 1 Data Flow Diagram of your intended Information
system
b. Use the instructions and illustrations in your textbook and the sample in the module as a
guide.
c. Use MS Word to generate the shapes and arrows for your diagram.
Part C: WORTH 20 POINTS— Data Dictionary
a. Create a Data Dictionary for Level 1.
b. Use the sample in the module as a guide.
Note: The Data Dictionary must include a detailed description of all data elements in the
DFD Level 1.
c. Use MS Word to generate the table and content for your Data Dictionary.
Part D: WORTH 5 POINTS – Member Contribution Report
1. Create a new page to document the contribution(s) of each member of your team to this
assignment. For each team member list:
a. Who (group member name)
b. What they contributed to this assignment
Assignment Submission Steps:
1. Save your document with name, Group#_Assignment#
2. Submit in the Assignment folder in D2L.
a. All items (Context Level Data Flow Diagram, Level 1 Data Flow Diagram, Data Dictionary
and Member Contribution Report) MUST be comprised in a single Word file.
REMINDER: Only the Group Leader submits group assignment files; in the assignment dropbox.

HOWARD GOULD
SYSTEMS ANALYSIS
AND DESIGN
Download free eBooks at bookboon.com
2
Systems Analysis and Design
1st edition
© 2016 Howard Gould & bookboon.com
ISBN 978-87-403-1417-5
Peer review: Dr. Amin Hosseinian Far at Leeds Beckett University
Download free eBooks at bookboon.com
3
SYSTEMS ANALYSIS AND DESIGN
Contents
CONTENTS
Acknowledgements
7
Foreword
8
1 Introduction to systems analysis and design
9
1.1
What is an information system?
9
1.2
The system development life cycle
12
1.3
Summary
21
2
Systems analysis
23
2.1
Requirements modelling
23
2.2
Functional decomposition
24
2.3
Identifying functions and processes
25
2.4
Dataflow diagram notation
28
2.5
Drawing a physical DFD
31
2.6
DFD errors
33
2.7
Drawing a logical DFD
37
2.8
Levelled data flow diagrams
40
www.sylvania.com
We do not reinvent
the wheel we reinvent
light.
Fascinating lighting offers an infinite spectrum of
possibilities: Innovative technologies and new
markets provide both opportunities and challenges.
An environment in which your expertise is in high
demand. Enjoy the supportive working atmosphere
within our global group and benefit from international
career paths. Implement sustainable ideas in close
cooperation with other specialists and contribute to
influencing our future. Come and join us in reinventing
light every day.
Light is OSRAM
Download free eBooks at bookboon.com
4
Click on the ad to read more
SYSTEMS ANALYSIS AND DESIGN
Contents
2.9
The context (level 0) diagram
43
2.10
The data dictionary
44
2.11
Process specification
46
2.12
Decision trees
46
2.13
Decision tables
47
2.14
Structured English
50
2.15
Requirements catalogue
53
2.16
Summary
56
3
Object oriented analysis
57
3.1
Objects and classes
58
3.2
Use case modelling
63
3.3
Class diagram
69
3.4
Sequence diagrams
70
3.5
State machine diagrams
72
3.6
Activity diagrams
73
3.7
Business process modelling
74
3.8
Summary
76
4
Systems design
77
4.1
Data design
78
4.2
Entity modelling
80
4.3
Normalisation
86
4.4
Identifying relations
91
4.5
Data table structures
95
4.6
Human-computer interaction
98
4.7
System architecture
108
4.8
Network topology
111
4.9
Design documentation
114
4.10
Summary
115
5
Systems implementation
116
5.1
Software design
117
5.2
Software development and testing
123
5.3
Documentation and training
124
5.4
System changeover
125
5.5
Summary
128
Download free eBooks at bookboon.com
5
SYSTEMS ANALYSIS AND DESIGN
Contents
6
Systems maintenance
129
6.1
User support and training
129
6.2
Software maintenance
130
6.3
System performance
131
6.4
System security
132
6.5
System termination
135
6.6
Summary
135
7
Bibliography
136
8
Appendices
139
8.1
Appendix A – Cost benefit analysis
139
8.2
Appendix B – Normalisation template
142
8.3
Appendix C – Project Management
143
Download free eBooks at bookboon.com
6
SYSTEMS ANALYSIS AND DESIGN
Acknowledgements
ACKNOWLEDGEMENTS
I should like to express my gratitude to Dr. Amin Hosseinian Far at Leeds Beckett University
(formerly known as Leeds Metropolitan University) for reviewing the manuscript. The idea
for this book evolved from teaching systems analysis and design to undergraduate computing
students for many years.
The majority of the modelling diagrams presented in this book have been drawn using the
QSEE SuperLite v1.1.2 CASE tool which is free to download from http://www.leedsbeckett.
ac.uk/qsee/
Trademarks
Some of the product and company names used in this book have been used for the purpose
of identification only and may be trademarks or registered trademarks of their respective
manufacturers and sellers.
PRINCE2® is a registered trademark of AXELOS Limited.
Oracle is a registered trademark of Oracle Corporation and/or its affiliates.
Microsoft is a registered trademark of Microsoft Corporation in the United States and/or
other countries.
SSADM is a registered trademark of the Office of Government Commerce (OGC) an office
of the UK treasury.
Unified Modelling Language and UML are either registered trademarks or trademarks of
Object Management Group, Inc. in the United States and/or other countries.
Download free eBooks at bookboon.com
7
SYSTEMS ANALYSIS AND DESIGN
Foreword
FOREWORD
This book has been written to provide a concise introduction to systems analysis and design
for students studying computing, IT or business related courses. Similarly, others who need
to work with systems analysts, designers or software developers when commissioning or
whilst using a new information system may benefit from an understanding of this content.
The information is presented in a form that makes it easy to grasp the essential principles
and techniques and to apply these within an information system development project.
Contents cover the full system development life cycle and include systems analysis using
structured analysis techniques and object modelling with the unified modelling language
(UML). The newer agile approaches to systems development are also introduced. Also
included is system design, incorporating data design, human computer interaction and
system architectures, along with coverage of system implementation and maintenance. A
brief introduction to IT project management techniques is also included as an appendix.
Further supporting materials can be found at the author’s website http://howard-gould.co.uk/.
Download free eBooks at bookboon.com
8
SYSTEMS ANALYSIS AND DESIGN
Introduction to systems analysis and design
1 INTRODUCTION TO SYSTEMS
ANALYSIS AND DESIGN
On completion of this chapter you should be able to:
•
•
•
•
identify the components of an information system
understand the purpose of systems analysis
be aware of the role of the systems analyst
understand the systems development life cycle.
Information technology (IT) based information systems (IS) are essential to all types of
organisations and in order for these systems to be of benefit they must be based on well-defined
requirements and designed and built using systems analysis and design (SAD) processes.
1.1
WHAT IS AN INFORMATION SYSTEM?
An information system can be defined as a set of interrelated components that function to
provide required information for a specified purpose.
A system receives input data which is processed, resulting in meaningful information –
output. (In some cases this output may be data to be used as input to another system). An
information system, shown in Fig 1.1 below, will have a control mechanism which regulates
the inputs and processes based on feedback from the outputs. A thermostat which regulates
a heating system is a good example of this. Systems work within boundaries and operate
within an environment. Large systems may comprise a number of sub-systems which work
together to support the overall function of the main system.
Input: Data
Feedback
Control
Output: Information
Processes
Storage
Fig 1.1 Elements of an Information System
Download free eBooks at bookboon.com
9
SYSTEMS ANALYSIS AND DESIGN
Introduction to systems analysis and design
The following diagram illustrates the basic elements of a payroll system. In this example,
typical inputs would include an employee’s hours worked and their tax code. This data,
along with previously stored data such as pay rates and employee details, would be used
within system processes such as “Calculate Tax” and “Calculate Pay” in order to calculate
the employees’ pay. Some of these calculated pay details would also be used as feedback
which will be used to influence future calculations for tax etc.
Here the system boundary relates to the business and its employees using the system. However,
the environment it operates within includes outside agencies such as the tax agency.
Control
Input:
Calculate Pay
Output:
Hours
Worked,
Calculate Tax
Monthly
Pay
Details
Tax Code
Employee Details
Pay Rates
Fig 1.2 Example Payroll System
Download free eBooks at bookboon.com
10
SYSTEMS ANALYSIS AND DESIGN
Introduction to systems analysis and design
The main components of an information system are:Input – the data that comes from the environment that the system will be operating in.
Process – operates on the inputs and transforms them into outputs, e.g. an application for a
driving licence results in a driving licence being issued following processing.
Storage – for data/information.
Output – the results of a process.
Feedback – an output that is fed back into the system to alter the control of the processes.
Control – regulates the system using the ‘feedback’ to ensure the system operates
to meet its purpose.
Boundary – the limit or scope of the system.
Environment – the area in which the system operates. This may include other systems or
other organisations.
Hardware – the computers and other data input and output devices.
Software – Programs, operating systems.
Data – input values and information output.
Communication – networking infrastructure, the Internet.
People – system analysts, software developers, system users.
A number of stakeholders are involved in the system development process, including:
System requester – usually a client or senior manager
System user – person who will use the system
System analyst – person who analyses and designs information systems
System developer – person who designs, produces and tests software.
Download free eBooks at bookboon.com
11
Deloitte & Touche LLP and affiliated entities.
SYSTEMS ANALYSIS AND DESIGN
1.2
Introduction to systems analysis and design
THE SYSTEM DEVELOPMENT LIFE CYCLE
The traditional approach to acquiring an information system is to use structured analysis
processes within the system development life cycle (SDLC). Structured analysis relies on
process models which show how data flows into a system and is processed by applying
business rules, which in turn leads to data being output as required information. The systems
analyst (SA) plays a leading role throughout the systems development process. A systems
analyst needs good analytical skills in order to identify problems and consider effective
solutions, and should also have good communication and interpersonal skills in order to
communicate effectively with a wide range of stakeholders ranging from senior managers
to operational employees (system users).
In recent times newer development approaches have become more team-based, utilising both
IT staff and system users to help speed up the process and so cut costs. Joint application
design (JAD) involves a group of users meeting intensively with systems analysts to help
with the information gathering and the system requirements definition process. Similarly,
rapid application development (RAD) (Martin, 1991) aims to speed up the SDLC, with
users being involved in the design and development tasks in a more interactive, iterative
way, which means that users can give feedback much sooner on the developed system than
in the traditional SDLC.
360°
thinking
.
360°
thinking
. 360°
.
thinking
Discover the truth at www.deloitte.ca/careers
© Deloitte & Touche LLP and affiliated entities.
Discover the truth at www.deloitte.ca/careers
© Deloitte & Touche LLP and affiliated entities.
Discoverfree
theeBooks
truth atatbookboon.com
www.deloitte.ca/careers
Download
Click on the ad to read more
12
Dis
SYSTEMS ANALYSIS AND DESIGN
Introduction to systems analysis and design
A newer alternative to structured analysis is object-oriented analysis and design (OOAD)
which focusses on identifying real-world objects used in a system; these objects combine
business processes with the data that they use. The O-O approach tends to be adopted when
a system is going to be developed using O-O programming languages.
The traditional systems development life cycle is primarily a sequential process which is often
referred to as a waterfall model (Royce, 1970) as it is based on a plan formed at the start
of the project, whereby each phase of the SDLC is allocated a period of time to complete
and then the outputs are fed through to the next phase until the system is completed.
Appendix C gives an overview of project planning.
The SDLC has five main phases, as shown in the diagram below:
1. Systems
Initiation
5. Systems
Maintenance
2. Systems
Analysis
4. Systems
Implementation
3. Systems
Design
Fig 1.3 Traditional Systems Development Life Cycle
Note. There are a number of variations of the SDLC, with some showing more phases and
some including iteration of a phase with the previous one, however the same activities are
included in all.
Download free eBooks at bookboon.com
13
SYSTEMS ANALYSIS AND DESIGN
Introduction to systems analysis and design
More recently Agile approaches (Beck K., et al, 2001) to systems development have become
established as a flexible alternative to the traditional SDLC. They follow an incremental/
iterative construction approach whereby small software prototypes are enhanced a number
of times following regular review meetings with stakeholders (called “scrums”, named after
the game of rugby) until it becomes an acceptable product. The iterative construction phase
includes design, code and test activities and usually has a short time period of one to four
weeks called “sprints”. The Agile approach aims to produce working software as soon as
possible whilst allowing a more adaptive form of planning which caters for changes to system
requirements. (Ambler, 2009–12) provides a more detailed explanation of Agile Life Cycles.
System
Initiation
Review
Construction
Production
Fig 1.4 A simple Agile Development Life Cycle
The following is a brief summary of the phases of the traditional SDLC:
Systems Initiation
The systems initiation phase is the starting point for a new system and is invoked following
a system request, backed by a business case which gives reasons for the request; this usually
comes from a senior manager or client. The system request is a formal document which
outlines the main requirements for a new system, or changes to an existing one. The system
request is often driven by the need for IT systems which help the organisation to meet
its strategic objectives. These generally relate to a wish to improve the effectiveness of the
existing business systems by means of offering better service or performance, or to the need
to comply with new external demands, e.g. government legislation. The system request is
often produced by the organisation’s IT department or an outside consultancy following
consultation with the senior managers, clients and other key stakeholders.
Once a system request is received by the IT department (or, depending on the organisation
and its resources, possibly an outside software consultancy) an initial investigation is
undertaken to see whether the requirements can be satisfied by an IT solution. This is
usually undertaken by a systems analyst and involves undertaking a feasibility study to
see whether in fact the project is viable, as there are a number of factors that need to be
considered before approval is given. These include whether the requirements can be satisfied
economically e.g. within the proposed budgets (development and operational).
Download free eBooks at bookboon.com
14
SYSTEMS ANALYSIS AND DESIGN
Introduction to systems analysis and design
A cost benefit analysis (Appendix A) is usually undertaken to ensure that the proposed
system would be cost effective, though in some cases the benefits of a new system may stem
from intangible benefits that are not easy to cost. Technical and organisational restrictions
need to be assessed, which includes checking that the proposed system can handle the
expected volumes of data and user numbers, whilst maintaining acceptable performance
levels. There also needs to be adequate availability of human resources such as development
staff and technical resources. Ethical consideration is also given to ensure that the system
will be legally, commercially and socially acceptable.
Following the initial investigation, the analyst may decide that the system requirements can
be satisfied by making better use of the existing IT systems or altering existing business
procedures, thus negating the need for a new system. If, however, a new system is deemed
necessary and feasible then senior management will give approval for the system development
process to proceed. A more detailed analysis of requirements will be undertaken during
phase 2 of the SDLC – Systems Analysis.
We will turn your CV into
an opportunity of a lifetime
Do you like cars? Would you like to be a part of a successful brand?
We will appreciate and reward both your enthusiasm and talent.
Send us your CV. You will be surprised where it can take you.
Download free eBooks at bookboon.com
15
Send us your CV on
www.employerforlife.com
Click on the ad to read more
SYSTEMS ANALYSIS AND DESIGN
Introduction to systems analysis and design
Note. The feasibility study may involve considering a number of alternative approaches to
satisfying the requirements. Each feasible approach will be included within the feasibility
report. The analyst will indicate the advantages and disadvantages of each approach and
make a recommendation, though ultimately the decision as to which approach will be selected
will be made by the senior management or client.
Systems Analysis
The systems analysis phase is undertaken by one or more systems analysts and is used to
identify the detailed system requirements in order to produce a requirements specification.
This specifies what needs to be included in the new system to meet the system users’
requirements. In order to develop the requirements specification, requirements capture and
modelling activities are undertaken. These involve identifying what data is needed by the
system (inputs/outputs) and the processes (business rules) which are needed to process the
data and produce the required information outputs. Additionally, any performance and
security requirements will also be identified.
Note. In the early days of IT systems development, a system was specified by the analyst
in the form of lengthy textual descriptions. These were often misinterpreted by developers
and users, frequently resulting in systems being produced that did not meet the users’
requirements. As the users often did not see the system until it was complete, any
misinterpretation of the users’ requirements proved costly to rectify. Current system
modelling methods incorporate diagrams, which helps to reduce the amount of text and
potential for misinterpretation – a case of a picture being worth a thousand words.
This information is arrived at following fact-finding activities undertaken by the analyst,
including meetings with the relevant stakeholders of the new system to establish what they
require. Other fact-finding techniques include questionnaires, observation of existing business
processes and reviewing existing system documentation, including collecting sample system
documents. The meetings may take place on an individual basis or during a JAD session
with a number of people present.
Download free eBooks at bookboon.com
16
SYSTEMS ANALYSIS AND DESIGN
Introduction to systems analysis and design
Where a new system is replacing an existing system, the analyst will initially observe and
model the existing system to help gain a better understanding of the users’ needs and any
existing problems. The analyst will record all relevant information, as this will be referenced
throughout the SDLC. This information is usually stored within a computer aided software
engineering (CASE) tool as these allow the analysts and other stakeholders to access the
important system requirements and design information quickly and easily. Some CASE tools
can also use this model information to automatically produce software elements needed for
the new system.
The requirements specification is used to build a logical model which will represent what
needs to be produced (but not how). In the case of structured analysis this will include
process and data modelling which includes data flow diagrams (DFDs) along with business
process descriptions.
Note. An alternative modelling toolset is the OMG’s unified modelling language (UML)
which is a flexible modelling language that has become established as the norm for O-O
development projects. It has 13 diagram types, although typically only a few will be produced
for a given system.
Many organisations do not enforce a modelling methodology rigidly so analysts/developers
are often free to choose appropriate models/diagrams for the task in hand. The aim should
be to ensure that whatever modelling methods are undertaken they will be understood by
those who will be using them.
Systems Design
The systems design phase is used to specify in detail the system to be built, based on
the requirements specification identified in the systems analysis phase, so that the system
developers are clear about what they need to produce. This phase involves producing physical
process diagrams (DFDs) that show how the data will be processed in the new system.
The business rules for the processes will also be specified and these may include descriptive
text, pseudo-code (written using structured English), decision trees and decision tables. In
addition, screen and report layouts will be included to show how the required information
will be input to and output by the system.
In most systems there will also be a need to store data within a database so at this stage
an entity relationship model (ERM) will be produced which will be used to identify the
database tables and their data items. This information forms the data dictionary which is
usually stored within a CASE tool. Although much of this work will be undertaken by the
systems analyst, some will be in consultation with system stakeholders to ensure that the
proposed design will satisfy their requirements.
Download free eBooks at bookboon.com
17
SYSTEMS ANALYSIS AND DESIGN
Introduction to systems analysis and design
When the design has been completed, the developers will work from the design specification
and commence the development work, coding and testing the software. The choice of
programming language, e.g. Java, C++ etc. used to develop the code will depend on the type
of application being developed and other factors such as available expertise and conformity
to the organisation’s development environment standards.
When software is developed it needs to be thoroughly tested to ensure that it performs as
expected and satisfies the specified requirements. Initial testing will relate to specific modules
or programs; when these have been satisfactorily completed integration testing can take place,
which involves testing all the modules and programs working together, as they will do when
the complete system is implemented. During this phase, if new hardware or networking is
required to support the system this will be acquired and tested to ensure that the system
will function appropriately when in use. Finally, acceptance testing will take place. This
involves asking intended users to trial the system to ensure that they are satisfied before it
is released for use. It may be necessary to make some minor amendments at this stage, but
if the earlier analysis and design phases have been carried out accurately there should be
no need for any major changes.
AXA Global
Graduate Program
Find out more and apply
Download free eBooks at bookboon.com
18
Click on the ad to read more
SYSTEMS ANALYSIS AND DESIGN
Introduction to systems analysis and design
Note. In some cases, the new system may be implemented using an existing product or
package which is purchased or acquired from an external source or vendor. This may require
some customisation, so will also need to undergo testing to ensure it functions in accordance
with requirements.
Systems Implementation
Following acceptance testing the system will be implemented (handed over for use) in its
intended environment. In order to prepare the users, it may be necessary for training on
the new system to take place first. An implementation strategy will be specified which will
indicate whether the new system will operate in parallel with the existing system for a
period of time in case there are unforeseen problems with the new system, though in the
case of a completely new system this is not possible. In some situations, it is not feasible
to run duplicate systems, so where possible, the new system is rolled out in stages, in order
to minimise risk.
Systems Maintenance
Once the new system has been implemented and is in normal use it is monitored, and
any minor problems or bugs (errors) dealt with as soon as possible. Reviews will also
be scheduled to ensure that the system is performing as expected. If any non-essential
additional requirements or changes are requested these will be considered and scheduled
for implementation if approved. In due course, when the system reaches a point at which
it is again no longer meeting the needs of the organisation, it may be discarded and if a
new system is needed to replace it the SDLC will be restarted.
Note. Some organisations have systems that have been in use for many years and there
may be a reluctance to completely replace these systems with new ones. These are often
referred to as “legacy” systems. Often, legacy systems have poorly structured software and
limited documentation. In order to continue to use these systems they can sometimes be
reverse-engineered by software tools which analyse and restructure the code. This approach
aims to provide a better understanding of the software and so aids with its integration with
newer systems.
Download free eBooks at bookboon.com
19
SYSTEMS ANALYSIS AND DESIGN
Introduction to systems analysis and design
Advantages and disadvantages of approaches / methods
Structured Analysis
Advantages:
Long established
Easier project planning and monitoring
Requirements defined and agreed early in the SDLC
Software designed based on a full understanding of all requirements.
Disadvantages:
Possibility design requirements not what the customer expects
If problems encountered with the system, cost to correct can be high as the client may only
see the system when it is complete.
Object-Oriented Analysis
Advantages:
Closer representation of real world objects
Aids development using O-O software languages
O-O software easier to maintain and with greater re-usability potential.
Disadvantages:
Can be difficult to identify all classes and objects
Not ideal for relational database designs
Models not as easy to understand for none technical users.
Download free eBooks at bookboon.com
20
SYSTEMS ANALYSIS AND DESIGN
Introduction to systems analysis and design
Agile
Advantages:
Regular system user feedback
Easier to adapt to changing situations
Quicker development.
Disadvantages:
Limited planning
Potential for scope creep – adding features and going over time and cost plans.
Lack of emphasis on design and documentation.
1.3
SUMMARY
Information systems play an important role in supporting an organisation’s aims. In order
for them to be effective they must be based on a detailed set of requirements which have
been identified using appropriate analysis and modelling techniques.
I joined MITAS because
I wanted real responsibili�
I joined MITAS because
I wanted real responsibili�
Real work
International
Internationa
al opportunities
�ree wo
work
or placements
Maersk.com/Mitas
www.discovermitas.com
�e G
for Engine
Ma
Month 16
I was a construction
Mo
supervisor
ina const
I was
the North Sea super
advising and the No
he
helping
foremen advis
ssolve
problems
Real work
he
helping
fo
International
Internationa
al opportunities
�ree wo
work
or placements
ssolve pr
Download free eBooks at bookboon.com
21
�e Graduate Programme
for Engineers and Geoscientists
Click on the ad to read more
SYSTEMS ANALYSIS AND DESIGN
Introduction to systems analysis and design
Exercise 1
Which of the following are information systems?
a) A library catalogue
b) A motor vehicle
c) A student name
d) Ebay.co.uk
Can you think of any other information systems?
Exercise 1 feedback
a) Yes
b) No – but it could be part of an information system
c) No – it is a data value
d) Yes
Other information systems: Business accounts, stock control, Amazon.com.
Exercise 2
List some possible sub-systems for a university information system.
Exercise 2 feedback
a) Student admissions
b) Student details (personal and academic)
c) Course details
d) Library loans
Exercise 3
Which of the following is the correct systems development life cycle?
a) Initiation, design, analysis, testing, implementation
b) Design, analysis, implementation, maintenance
c) Initiation, analysis, design, implementation, maintenance
Exercise 3 feedback
c)
Download free eBooks at bookboon.com
22
SYSTEMS ANALYSIS AND DESIGN
2
Systems analysis
SYSTEMS ANALYSIS
On completion of this chapter you should be able to:
•
•
•
•
2.1
produce a functional decomposition diagram
model a business situation using data flow diagramming (DFD) techniques
specify a process using decision trees, decision tables and structured English
undertake object modelling using the unified modelling language (UML).
REQUIREMENTS MODELLING
Following the initial investigation and acceptance of the feasibility study, the systems analysis
phase of the SDLC will commence. This involves requirements modelling, which includes
producing the requirements specification which describes the system to be developed. The
specification indicates functional and non-functional requirements and may include a number
of models and diagrams that describe how the system will operate. The specification is a
formal document which forms an agreement between the developers and the users. In order
to help understand the system under investigation and the system that is required, models
are produced.
These models include various diagrams, e.g. DFDs or UML diagrams, which are used to
communicate with the relevant stakeholders, i.e. users and developers, to ensure that they
accurately reflect the system under consideration. The diagrams may be changed a number
of times following feedback from stakeholders until all agree that they accurately represent
the system. The diagrams are usually produced using a suitable CASE tool, though initial
drafts may be drawn by hand. In order to produce the models, the analyst will need to
have a good understanding of the business area under consideration and to achieve this will
require a number of meetings and observations and possibly other fact – finding activities
including business document reviews and user surveys.
Where the new system is to be based on an existing system it is usual to first produce a
physical model which represents the physical view of the current implementation, in order
to gain an understanding of how the system functions. This model can then be analysed and
converted to form a logical model which allows the analyst to view the actual information
required to satisfy the requirements for the new system. Later in the system design phase
the logical model can be used to help produce a physical model of the proposed system
which will show how the new system will be implemented.
Download free eBooks at bookboon.com
23
SYSTEMS ANALYSIS AND DESIGN
Systems analysis
To understand the difference between a physical view and a logical view let us consider a
business system that sends invoices to its customers. The physical view represents the actual
physical implementation:- the system produces a printed invoice which is then sent in the
mail to the customer. However, from the logical viewpoint the system is just communicating
invoice details to the customer. By focussing on the logical view the essential information
requirements can be established. During the later design stage a decision will be made on
how best to implement the above requirement. This may result in the invoice being emailed
to the customer or giving them access to the system via the Internet so they can view the
invoice details at any time, or both.
2.2
FUNCTIONAL DECOMPOSITION
A major role of the systems analyst is fact-finding, which includes understanding the structure
of the organisation. This involves investigating the area of study and breaking it down to
identify its business processes, referred to as “top down decomposition”. These processes
can be shown using a functional decomposition diagram. This aids understanding and
provides a means of communication with others whilst helping to establish the information
requirements. A basic example showing some higher level business functions and some of
their processes is shown below. Note that a complete diagram would have more sub-levels
showing the business processes undertaken for each functional area:
93%
OF MIM STUDENTS ARE
WORKING IN THEIR SECTOR 3 MONTHS
FOLLOWING GRADUATION
MASTER IN MANAGEMENT
• STUDY IN THE CENTER OF MADRID AND TAKE ADVANTAGE OF THE UNIQUE OPPORTUNITIES
THAT THE CAPITAL OF SPAIN OFFERS
• PROPEL YOUR EDUCATION BY EARNING A DOUBLE DEGREE THAT BEST SUITS YOUR
PROFESSIONAL GOALS
• STUDY A SEMESTER ABROAD AND BECOME A GLOBAL CITIZEN WITH THE BEYOND BORDERS
EXPERIENCE
5 Specializations
Personalize your program
www.ie.edu/master-management
#10 WORLDWIDE
MASTER IN MANAGEMENT
FINANCIAL TIMES
mim.admissions@ie.edu
Download free eBooks at bookboon.com
24
Length: 1O MONTHS
Av. Experience: 1 YEAR
Language: ENGLISH / SPANISH
Format: FULL-TIME
Intakes: SEPT / FEB
55 Nationalities
in class
Follow us on IE MIM Experience
Click on the ad to read more
SYSTEMS ANALYSIS AND DESIGN
Systems analysis
Organisation
Finance
Invoicing
Manufacturing
Purchasing
Sales
Design
Check credit
Testing
Raise invoice
Production
Fig 2.1 Functional decomposition diagram
2.3
IDENTIFYING FUNCTIONS AND PROCESSES
The first step is to break down the business into its main areas of activity or functions. These
may be concerned with managing business resources such as Finance, Stock or Human.
Alternatively, they may be based on the life cycle of a product or service e.g. Marketing,
Manufacturing, Distribution. The major functional areas or activities will depend on the
nature of the organisation under investigation.
Business processes usually relate to a specific business entity which is used within a business
function. Here are some examples of business processes:– Check Credit
— Raise Invoice
— Receive Payment
Note the structure of the business processes; they should consist of a verb and a singular
object e.g. Pay Employee.
To identify business processes, consider the life cycle of the business entities e.g. for a hotel
you might identify:
— Receive Booking
— Check in Guest
— Allocate Room
— Check out Guest
Download free eBooks at bookboon.com
25
SYSTEMS ANALYSIS AND DESIGN
Systems analysis
The functional decomposition processes will be used within the dataflow diagrams (DFDs).
Exercise 1
What would you suggest are the major activities of :a) A library
b) A university
c) A hospital
Exercise 1 feedback
a) Book acquisition, loans and returns, reservations, stock management
b) Marketing, recruitment, enrolment, teaching, examinations, resources
c) Admissions, staffing, patient care, maintenance
Exercise 2
Suggest some business processes for a bicycle manufacturer to be added to those
identified below:
— Design Bicycle
— Produce Bicycle
—- Sell Bicycle
—
Exercise 2 feedback
———
Research Market
Design Bicycle
Build Prototype
Produce Bicycle
Advertise Bicycle
Distribute Bicycle
Sell Bicycle
Bicycle Aftersales Support
Download free eBooks at bookboon.com
26
SYSTEMS ANALYSIS AND DESIGN
Systems analysis
Exercise 3
For the business process Recruit Employee decompose the process by completing the
following:
a) Advertise _________?
b) __________? Candidate
c) Appoint ___________?
Exercise 3 feedback
a) Advertise Vacancy
b) Interview Candidate
c) Appoint Candidate
Download free eBooks at bookboon.com
27
Click on the ad to read more
SYSTEMS ANALYSIS AND DESIGN
2.4
Systems analysis
DATAFLOW DIAGRAM NOTATION
As mentioned in section 2.1 above, in order to ascertain the requirements for a new system
it is important to be able to understand how the current system operates. To achieve this a
physical model can be produced using dataflow diagramming (DFD) techniques. The DFD
allows you to show business processes and how data flows between them. There are a number
of DFD notations in use, e.g. Gane and Sarson, Yourdon De Marco and SSADM®. Although
each notation uses slightly different symbols the diagrams are composed and interpreted in
similar ways so you should be able to interpret a diagram based on any notation without
difficulties after following this text. This text uses the SSADM notation and the diagrams
presented have been produced using the QSEE Superlite version 1.1.2 case tool, which is
available to download from http://www.leedsbeckett.ac.uk/qsee/
SSADM® – Structured Systems Analysis and Design Method was a methodology developed
for use in the analysis and design of information systems and was widely used for UK
government projects from the 1980s onwards.
Depending on the size and complexity of the system being modelled a number of interrelated
DFDs showing different levels of detail will be produced in order to show all the information
in a manageable form. This involves applying a top-down decomposition approach which
identifies the higher level business processes, and expanding each of these to show the lower
level processes on separate DFDs, continuing until you have a set of primitive processes
which cannot be broken down any further.
The DFD uses symbols to show the four key business process elements: processes, data
flows, data stores and external entities.
A process is an activity of interest within the system that involves transforming data and
producing an output. It is defined using a verb and an object, e.g. Create Order. In effect,
a process represents the business rules that are applied to process data in order to achieve
the required output.
The process symbol will be one of the following, depending on the chosen notation:
CREATE
ORDER
SSADM
Gane and Sarson
Fig 2.2 Process symbols
Download free eBooks at bookboon.com
28
CREATE
ORDER
Yourdon
SYSTEMS ANALYSIS AND DESIGN
Systems analysis
Each process is given a process name – e.g. Create Order – and an identifier, e.g. 1, 2, 3 etc.
In SSADM the process also has a location which indicates the unit or person responsible
for carrying out the process e.g. Accounts Department.
A dataflow is a single item of data or a logical group of data items that is transferred when
a process takes place. This is shown as an arrowed line (in all three notations) showing the
direction the data travels, with a suitable label describing the data items. Note. Double
arrowed lines are permitted but only on higher level DFDs to show that the data items
may be transferred in both directions between processes.
ORDER
Fig 2.3 Dataflow symbol
A data store is a set of data items stored for use by one or more processes over time.
ORDERS
SSADM
Gane and Sarson
ORDERS
Yourdon
Fig 2.4 Data store symbols
Note. On a current system physical DFD, data stores are labelled with an “M”, “D” or “T”.
“M” is used to represent a non-computerised store, e.g. a paper file. “T” represents a
transient store, i.e. one where data resides temporarily just for use between two processes.
“D” represents a data store that is computerised. Each data store label includes a unique
identifying number e.g. M1, D1, T1.
An external entity is an organisation, person or a system that is outside of the system under
consideration but which interacts with it, e.g. a customer from another organisation who
places an order which is processed by the system under consideration.
SSADM
CUSTOMER
CUSTOMER
Gane and Sarson
Yourdon
Fig 2.5 External entity symbol
Download free eBooks at bookboon.com
29
SYSTEMS ANALYSIS AND DESIGN
Systems analysis
Note. SSADM external entity identifiers use a lower-case letter e.g. a, b, c.
To aid diagram readability it is permissible to use duplicate data stores and external entities,
these duplicate symbols are shown as follows:M1
Orders file
Fig 2.6 Duplicate symbols
Diagram labelling reminders:
• Remember to use a verb and a singular object for processes
• Use clear, meaningful names
Note Gane and Sarson and Yourdon notations use upper case labels, though it is not
uncommon to see lower and mixed case labels used on diagrams. However, you should be
consistent with your labelling, i.e. use either upper case or mixed case but not both.
Excellent Economics and Business programmes at:
“The perfect start
of a successful,
international career.”
CLICK HERE
to discover why both socially
and academically the University
of Groningen is one of the best
places for a student to be
www.rug.nl/feb/education
Download free eBooks at bookboon.com
30
Click on the ad to read more
SYSTEMS ANALYSIS AND DESIGN
2.5
Systems analysis
DRAWING A PHYSICAL DFD
The highest level DFD is called the context diagram or Level 0 diagram. This shows the
area of activity being investigated and uses only one process symbol, which represents the
area (system) and all the external entities which interact with it. The next level down is
referred to as Level 1. This shows the main processes and their data stores. If any of these
processes are further decomposed, their sub-processes will appear on a Level 2 diagram and
so on. Analysts often start with the Level 1 DFD, as it is not usually possible to identify
all the external entities and their data flows which are needed for the context diagram until
the system has been analysed in some detail. The context diagram and levelling process are
explained in more detail later.
Let us look at how these symbols can be used to produce a Level 1 physical DFD to
represent the following business process:
“A university loans equipment (e.g. video cameras) to students, on submission of a booking
form containing details of what is required. The university technician checks the item’s
availability against an inventory list before issuing the item, with a loan receipt, to the student.”
This is modelled as follows:-
Fig 2.7 Equipment loans physical DFD
This DFD is interpreted as the student’s booking form enters the system as an input to the
“Issue Equipment” process, which is carried out by the technician. This process involves
reading the booking form data (for the item required) and then checking the inventory
list which is obtained from the data store (an input to the process) in order to check the
requested item’s availability. Assuming the item is available for loan, the item and a loan
receipt are issued to the student (an output). The actual item loaned is not shown on the
dataflow to the student as the DFD is only concerned with showing the data involved, i.e.
the loan receipt, as this indicates an item has been issued.
Download free eBooks at bookboon.com
31
SYSTEMS ANALYSIS AND DESIGN
Systems analysis
Note. The box enclosing the process and data store shows the boundary of the higher level
process (or system) being modelled, although the external entity “student” is beyond the
boundary it interacts with the process directly.
Now let us look at a different Level 1 physical DFD scenario which shows how processes
are linked:A vehicle rental company hires out motor vehicles to clients. The company receives telephone
requests from customers to hire a specific car type for a period of time. When a request
is received by the company, the Rentals Manager checks to see if a suitable vehicle will be
available before issuing a rental confirmation; this involves checking the vehicle file. If a
vehicle is available, a rental form is completed and stored in the rentals file.
The Garage Manager uses a copy of the rental form to prepare the vehicle for the client,
a copy of which is then given as a receipt to the client when they collect the car. When a
vehicle is returned, the garage manager checks the vehicle and signs the copy rental form,
before amending the vehicle file to show the vehicle return.
This is modelled as follows:-
Fig 2.8 Vehicle rentals physical Level 1 DFD
Note The physical DFD is so called because it shows the physical nature of the data objects,
e.g. Order form, Sales folder etc.
Download free eBooks at bookboon.com
32
SYSTEMS ANALYSIS AND DESIGN
2.6
Systems analysis
DFD ERRORS
When drawing DFDs you must ensure that all external entities, processes, data stores and
data flows are clearly labelled and that dataflow lines do not overlap – use duplicate symbols
if necessary to avoid this.
Take care to avoid incorrect data flows when producing your DFD, as shown by the
following examples.
1.
Direct interaction between external entities is not permitted. This must be via a process
if required.
American online
LIGS University
is currently enrolling in the
Interactive Online BBA, MBA, MSc,
DBA and PhD programs:
▶▶ enroll by September 30th, 2014 and
▶▶ save up to 16% on the tuition!
▶▶ pay in 10 installments / 2 years
▶▶ Interactive Online education
▶▶ visit www.ligsuniversity.com to
find out more!
Note: LIGS University is not accredited by any
nationally recognized accrediting agency listed
by the US Secretary of Education.
More info here.
Download free eBooks at bookboon.com
33
Click on the ad to read more
SYSTEMS ANALYSIS AND DESIGN
Systems analysis
2.
Data from an external entity cannot be placed directly into a data store – it must be
transferred via a process.
3.
Data cannot be transferred directly from one data store directly to another – it must be
transferred via a process.
4.
A Black hole – data must be transformed by a process, there must be an output to a data
store, another process or to an external entity.
5.
Divine intervention – in order for data to be output from a process, some data must be input.
6. A Grey hole is one where an input would not be able to produce the required
output e.g. to calculate an employee’s pay, inputting a car registration number
would not be relevant.
Download free eBooks at bookboon.com
34
SYSTEMS ANALYSIS AND DESIGN
Systems analysis
7. A trivial process is one where no data transformation is taking place within the
process e.g.:-
Every process must have at least one relevant input data flow and one output data flow in
order to “transform” the data.
Exercise 4
Complete the following Physical DFD example which represents part of a cycling club enrolment
process.
“The secretary at the cycling club enrols applicants as members as soon as he receives their
signed application form. He updates the members’ file with their form then issues a membership
card. This completes the membership process.”
Download free eBooks at bookboon.com
35
SYSTEMS ANALYSIS AND DESIGN
Systems analysis
Exercise 4 feedback
Note The external entity could alternatively have been labelled as “Applicant”. Although at the
outset of the process the external entity is an applicant, after being accepted they would become
a member and any further interactions with the system would be as a member. The “application
form” data flow to the members’ file could alternatively be labelled “member details” if these
are stored instead of the actual application form.
Download free eBooks at bookboon.com
36
Click on the ad to read more
SYSTEMS ANALYSIS AND DESIGN
2.7
Systems analysis
DRAWING A LOGICAL DFD
The DFDs shown previously have been compiled in order to give a structured view of an
area of activity from a physical perspective, e.g. Booking form and Loan receipt. As an
analyst you need to be able to detach the physical aspects of the existing system in order
to obtain a logical view of the system to be developed. It is essential to be able to identify
the logical requirements for the new system and not be constrained by the existing system’s
implementation.
Let us now look at how you can “logicalise” a physical DFD to produce a logical DFD.
Use the following steps:
1. Data flows – examine and replace any mention of a physical representation, e.g.
documents such as forms, with their data items.
2. Data stores – rename any which refer to physical documents or records.
Consider using business data entity names for the stores, e.g. ‘Customers’ rather
than ‘customer file’. Also ensure that each logical data store is uniquely identified
with a “D” e.g. D1, D2 etc.
3. Processes – Check each process and remove any reference to people or places
(the location) and remember the processes should not be trivial – they must
represent some data transformation.
Here is a simple example to start with – the cycling club enrolment, using the physical
model shown in exercise 4 above:-
Fig 2.9 Enrol member level 1 DFD
Download free eBooks at bookboon.com
37
SYSTEMS ANALYSIS AND DESIGN
Systems analysis
Following the three steps:
1. First look at the data flows:Application form – this is a physical document name. The data needed by the process is
actually the applicant member’s information e.g. name, address etc. This can be referred
to as “member details”.
Membership card – this is also a physical item. You could rename this as “membership
confirmation”. In the new system this may take a different form such as an electronic
identification that may be used on a mobile phone or other device.
2. Data stores:Members’ file: The business entity here is “Member” but as you wish to store all the
required information about all the members in the club here then the name “Members” is
appropriate. As all logical data stores are identified with a “D,” its identifier will be “D1”.
3. Processes:Enrol Member: This is acceptable (verb and object), however no location should be
specified so “Secretary” would be removed. The reason for this is that in the new system
the process may be carried out automatically by the system.
The new logical DFD is as follows:-
Fig 2.10 Enrol member logical level 1 DFD
Download free eBooks at bookboon.com
38
SYSTEMS ANALYSIS AND DESIGN
Systems analysis
Note that the data flow from the process to the data store has been renamed “Member
details” rather than “Applicant details” as this is a more appropriate description of the data
at this point in the process.
The “logical” model describes the processes and information that are relevant to the business
or, more specifically, what is needed rather than its form. It forms the basis of further analysis
and design activities.
Exercise 5
Convert the physical level 1 DFD for the vehicle rentals company shown in Fig 2.8 to a
logical level 1 DFD.
.
Download free eBooks at bookboon.com
39
Click on the ad to read more
SYSTEMS ANALYSIS AND DESIGN
Systems analysis
Exercise 5 feedback
Logical level 1 DFD
2.8
LEVELLED DATA FLOW DIAGRAMS
As has already been mentioned, using the DFD structured diagramming technique allows
for a top-down approach to modelling so that a DFD can be decomposed (expanded) into
lower levels, each of which shows more detail for each process by separating these into their
sub-processes.
The highest level diagram – Level 0 – is also called the context diagram as it shows the
boundary for the whole system as one process, surrounded by the external entities (the
context) and their data flows that represent the interaction with the system.
The Level 1 DFD shows the main processes and data stores for the area under investigation.
A Level 2 DFD is normally produced for each process shown at level 1, though it is not
always necessary to break every process down to the next level.
Decomposition stops when processes on a diagram are regarded as primitive or elementary
i.e. they can be specified simply using another method such as “Structured English”. (This
is discussed later.)
Processes are numbered on lower levels using the following convention.
If a Level 1 DFD had a process numbered 1 which consisted of 3 sub processes, these sub
processes would be shown on a Level 2 DFD numbered 1.1, 1.2, 1.3.
Download free eBooks at bookboon.com
40
SYSTEMS ANALYSIS AND DESIGN
Systems analysis
If a second Level 1 process with an identifier of 2 had 2 sub processes, these would be
labelled as 2.1 and 2.2 on another Level 2 DFD.
The process at a given level sets the boundary for the DFD at the next lower level. It is
important that the data flows shown on the lower level DFD match those shown on the
higher level. This is referred to as “balancing” the model. CASE tools help to check that
this “balancing” has taken place as they usually transfer the data flows (and data stores)
automatically down to the next level when the subordinate diagram is created.
If a data store is only used by one process (i.e. it is “private” to that process) it would only
appear at the lower level.
External entities are shown at the lower levels if data flows are connected directly to processes
at the lower level.
Let us consider the car rental Level 1 DFD, which has three processes. The “Check rental
process” actually involves three sub processes: check vehicle availability, create rental booking
and inform the client. These sub processes can be shown on a Level 2 diagram as follows:-
Fig 2.11 Check rental level 2 logical DFD
The box around the three processes indicates the boundary of the level 1 process which is
represented by the Level 2 diagram.
Download free eBooks at bookboon.com
41
SYSTEMS ANALYSIS AND DESIGN
Systems analysis
Note the consistency between the Level 1 and Level 2 diagrams for the “Check rental”
process.
1. In and out data flows are identical on the Level 2 diagram with the process 1 of
the Level 1 diagram.
2. The two data stores involved with the Level 1 process “Check rental” match at
Level 2 as shown outside the Level 2 boundary (the large box)
3. The external entity “Client” appears at Level 2 as it is directly associated with
the Level 1 process “Check Rental” on the Level 1 diagram.
On the Level 2 diagram there are new data flows that link the processes together.
Note. If the “Inform client” process also involved storing a copy of the confirmation sent
to the client, this would be represented as a “private” data store called “Confirmations” and
linked with an output data flow from this process to the Client entity. It is referred to as
“private” because it would only be visible at this level if not used by any other processes
at a higher level.
Join the best at
the Maastricht University
School of Business and
Economics!
Top master’s programmes
• 33rd place Financial Times worldwide ranking: MSc
International Business
• 1st place: MSc International Business
• 1st place: MSc Financial Economics
• 2nd place: MSc Management of Learning
• 2nd place: MSc Economics
• 2nd place: MSc Econometrics and Operations Research
• 2nd place: MSc Global Supply Chain Management and
Change
Sources: Keuzegids Master ranking 2013; Elsevier ‘Beste Studies’ ranking 2012;
Financial Times Global Masters in Management ranking 2012
Maastricht
University is
the best specialist
university in the
Netherlands
(Elsevier)
Visit us and find out why we are the best!
Master’s Open Day: 22 February 2014
www.mastersopenday.nl
Download free eBooks at bookboon.com
42
Click on the ad to read more
SYSTEMS ANALYSIS AND DESIGN
2.9
Systems analysis
THE CONTEXT (LEVEL 0) DIAGRAM
The first diagram in the hierarchy is the Context diagram, which is also referred to as the
Level 0 DFD. This diagram shows the entire area of activity under consideration (the system)
and is often referred to as the scope of the analysis or investigation.
Logically, the context diagram is drawn first so that the extent of the area of investigation
can be identified and the external entities and data flows shown. However, in practice it is
usually easier to start with the Level 1 diagram and then transfer data flows from this and
link them into the single process box on the context diagram.
Using the Level 1 logical DFD for the vehicle rental company would produce the following
context diagram:-
Fig 2.12 Car rentals context diagram
Note the following:• Only one process symbol appears on the context diagram labelled with the
system name
• The process has the identifier number ‘zero’
• No data stores are shown on the context diagram
• There are four data flows, which match those on the Level 1 DFD for compatibility
As some context diagrams have many data flows, amalgamation is permitted to aid readability,
e.g. the two “Rental details” data flows may be shown below as one but with arrow tips at
both ends of the flow (note this is only permitted on a context diagram).
Rental details
Fig 2.13
Download free eBooks at bookboon.com
43
SYSTEMS ANALYSIS AND DESIGN
Systems analysis
Important
Always ensure compatibility with the higher level data flow diagram –
•
•
•
•
Show the boundary to represent the higher level process
Check there are the same number of data flows in and out on each level
Check the same names are used for data flows
Check external entities are compatible
Note If using the QSEE CASE tool you will need to enter the context diagram first, although
it is not always possible to identify all the external entities or data flows at this stage. This
is not a problem as the CASE tool will ensure that any external entities or data flows that
are added to the lower level diagrams, e.g. Level 1 DFD, are automatically added to the
higher level diagram(s) to ensure the diagrams remain “balanced”.
Exercise 6
Produce a context diagram for the cycling club as shown in the Level 1 logical DFD Fig 2.10
Exercise 6 feedback
2.10 THE DATA DICTIONARY
As the analyst builds the logical model, additional information needs to be captured
and stored for future reference. This collection of information is referred to as the data
dictionary or data repository and is normally stored within a CASE tool, as this allows
for easy reporting and cross checking to see where data items are used. The information
collected includes the data values from the data flows, data stores and the processes. These
data values include data records or data structures, each of which comprises individual
data items or elements.
Download free eBooks at bookboon.com
44
SYSTEMS ANALYSIS AND DESIGN
Systems analysis
An example data set (record) for a Client in the vehicle hire system would include the
data items
•
•
•
•
•
client name
client address
client home/office telephone number
client mobile phone number
client driving licence id.
Data items are further defined to include a data type, e.g. numeric or textual, and a size,
e.g. maximum number of characters. Additional related information that is often stored
includes expected data volumes, i.e. how many customer records need to be stored, or how
many transactions will be processed in a given period of time, e.g. how many orders will
be processed per day. For each data item, acceptable values or ranges will be noted along
with security details relating to user access rights. All of this information is referred to as
meta-data and is vital for use in later stages of the SDLC.
Download free eBooks at bookboon.com
45
Click on the ad to read more
SYSTEMS ANALYSIS AND DESIGN
Systems analysis
2.11 PROCESS SPECIFICATION
Each elementary process from the lowest level DFD needs to be specified in a suitable form
that clearly describes the processing necessary to accomplish its purpose. This information
forms the basis for software specifications which are used in the system design phase. There
are three main modelling techniques available for specifying this process logic: Decision
Trees, Decision Tables and Structured English.
2.12 DECISION TREES
A decision tree is used to present a graphical representation of all possible conditions and
their actions, as in the following process description which has been identified by a systems
analyst during an interview with the rental manager for a vehicle rental company:
“There are two types of client who rent vehicles, business clients and private clients. Private
clients have to pay for the vehicle rental at the time of the booking, however business clients
are given credit terms. If they have been a client for three or more years, they are allowed
credit up to £10,000; those who have been clients for less than this are allowed £5000 credit.”
This text shows that a number of decisions are made, with set actions being taken depending
on the outcome. Each business situation is identified, in this case whether the hirer is a
business or private client. Each of these may have further branches which represent further
sub-division points. At the ends of the final branches, the action to be taken is specified
as shown here:
Client for
Y
Account < 10000 N > 3 years
Y
Account < 5000 Business Y Y N N Fig 2.14 Decision tree Download free eBooks at bookboon.com 46 Deny rental Allow rental Deny rental N Client Allow rental Allow rental SYSTEMS ANALYSIS AND DESIGN Systems analysis 2.13 DECISION TABLES A decision table uses a tabular approach to show every condition and its outcome. These can be set up easily using a spreadsheet program. They are often used by analysts to show how to process a number of complicated conditions in a form that is easy for others to understand. In particular, software developers can use them to help develop the code during the system design phase of the SDLC. The table consists of four segments as shown below:Condition entry Condition Action Action entry Fig 2.15 Decision table The condition segment lists the conditions or “questions”. The condition outcomes are either “True” or “False” and are represented by a “Y” or “N”; a dash “-” is used when the outcome is immaterial. Each condition entry is referred to as a rule and these are usually numbered. The condition entry segment is used to record the responses to the condition questions as Y”, “N” or “-”. An “X” is entered into the action entry alongside the action to be taken under the condition outcome specified above it. The action entry is left blank if no action is to be taken. To create a decision table, it is necessary to list all the conditions and note the alternative answers. Then calculate the total number of alternatives of the conditions, e.g. for three conditions, each has two outcomes (“Y” or “N”) so this gives 2 × 2 × 2 = 8. List the actions in the action segment and place an “X” in the action entry boxes relating to the appropriate rules. Let us consider an example process:A bank’s decision on whether to dispense money to a customer from a cash dispenser involves checking that the amount to be withdrawn does not exceed the customer’s account balance. Download free eBooks at bookboon.com 47 SYSTEMS ANALYSIS AND DESIGN Systems analysis Fig 2.16 Bank decision table It is sometimes possible to consolidate the rules when the actions specified for two sets of rules are identical and the condition entries differ for only one condition. In this example the two rules can be amalgamated into one. This is accomplished by replacing the “Y” of the condition with a “-” and deleting the rule which has an “N”. Revisiting the previous bank example allows for simplification as follows: Need help with your dissertation? Get in-depth feedback & advice from experts in your topic area. Find out what you can do to improve the quality of your dissertation! Get Help Now Go to www.helpmyassignment.co.uk for more info Download free eBooks at bookboon.com 48 Click on the ad to read more SYSTEMS ANALYSIS AND DESIGN Systems analysis Fig 2.17 Consolidated bank decision table If the balance is not in credit, then the condition “withdrawal amount < balance” is irrelevant as the action will be the same for both conditions, thereby reducing the number of condition entries in the table. Exercise 7 Convert the vehicle rental company decision tree from Fig 2.14 into a decision table. Exercise 7 feedback The above decision table shows all 16 possible combination rules but when the rules are consolidated the result shows that only 5 rules are needed:- Remember the dash “-“ indicates that the condition entry value is not relevant. Download free eBooks at bookboon.com 49 SYSTEMS ANALYSIS AND DESIGN Systems analysis 2.14 STRUCTURED ENGLISH The final technique that can be used for describing a primitive process is Structured English. Whilst decision trees and decision tables show the different branch logic, Structured English can be used to describe all processing steps. It adopts a modular design approach and although it looks similar to pseudocode which is used by software developers to help specify program code, it is not the same, as it is used to identify the main process logic rather than specific code. Structured English utilises the three logical control structures: sequence, selection and iteration. These structures are combined in order to define the processing logic. Structured English aims to provide a clear explanation of the processing involved, which aids the software developer when designing the code during the systems development phase of the SDLC. Structured English uses three logical control structures: Sequence A sequence is where a number of statements are executed one after the other. This can be shown diagrammatically as follows:- Fig 2.18 A sequence structure Note. Any step of a sequence may consist of other sub-processes which contain logical structures. Download free eBooks at bookboon.com 50 SYSTEMS ANALYSIS AND DESIGN Systems analysis Selection. A selection checks for a condition and, depending on the outcome, performs one of two steps as follows:- Fig 2.19 A Selection structure Brain power By 2020, wind could provide one-tenth of our planet’s electricity needs. Already today, SKF’s innovative knowhow is crucial to running a large proportion of the world’s wind turbines. Up to 25 % of the generating costs relate to maintenance. These can be reduced dramatically thanks to our systems for on-line condition monitoring and automatic lubrication. We help make it more economical to create cleaner, cheaper energy out of thin air. By sharing our experience, expertise, and creativity, industries can boost performance beyond expectations. Therefore we need the best employees who can meet this challenge! The Power of Knowledge Engineering Plug into The Power of Knowledge Engineering. Visit us at www.skf.com/knowledge Download free eBooks at bookboon.com 51 Click on the ad to read more SYSTEMS ANALYSIS AND DESIGN Systems analysis Iteration (Looping) A process step or steps repeated until a condition is met:- Fig 2.20 An Iteration structure Below is a Structured English example. Note that a number of key words are used along with references to the data items (they are defined in the data dictionary) being processed. Typical key words which are used include the following:- READ, CREATE, UPDATE, WRITE, DELETE, OUTPUT, IF, ELSE, ENDIF, REPEAT, UNTIL, WHILE, THEN, DO WHILE, END WHILE, EQUAL, LT (LESS THAN), LE (LESS THAN OR EQUAL TO), GT (GREATER THAN), GE (GREATER THAN OR EQUAL TO), AND, OR, NOT, OPEN, CLOSE, FILE, EXIT. Download free eBooks at bookboon.com 52 SYSTEMS ANALYSIS AND DESIGN Systems analysis CREATE INVOICE *This process produces an invoice for every completed order; incomplete orders are reported REPEAT UNTIL (end of file) READ order file IF (order complete) OUTPUT invoice ELSE Add order no. to incomplete order report ENDIF ENDREPEAT EXIT CREATE INVOICE Fig 2.21 Structured English process description Note When using structured English only use the three constructs. Indent statements for clarity. Place one sequence statement per line. Always use UPPER case for keywords. Underline or highlight words relating to data dictionary entries. Comment lines start with a *. Use ( ) to enclose conditions. 2.15 REQUIREMENTS CATALOGUE Following identification of the system requirements they will be documented as a set of requirements catalogue entries using a template similar to the one below. These will be used in conjunction with the structured analysis and object oriented model diagrams that have been produced and are usually stored within a CASE tool repository for easy reference. Download free eBooks at bookboon.com 53 SYSTEMS ANALYSIS AND DESIGN Systems analysis Requirements Catalogue Entry System Author Requirement Number Version Number Requirement Name Description Priority Source Owner Download free eBooks at bookboon.com 54 Click on the ad to read more SYSTEMS ANALYSIS AND DESIGN Systems analysis Issues and Outstanding Questions Comments/Suggested Solutions Benefits Related Documents Related Requirements Resolution Fig 2.22 Requirements catalogue entry The template fields are completed as follows: • • • • • • • • • • • • • System – the proposed system name Author – the person who has documented the requirement, usually the analyst Requirement Number – the number or ID which uniquely identifies the requirement Version Number – used to indicate which version this requirement is as they may be amended Requirement Name – a brief name Description – a description of the functional (essential) requirement in the user’s words Non-functional requirements may be included, e.g. transaction response times which may include acceptable ranges Priority – e.g. Low, medium, high. Not all requirements are implemented so it will be necessary to agree essential ones Source – person or document that identifies the requirement Owner – person who will take responsibility for the requirement Issues and Outstanding Questions – issues to be considered Comments/Suggested solutions – ideas for consideration Benefits – need to relate to business priorities and the Priority mentioned above Download free eBooks at bookboon.com 55 SYSTEMS ANALYSIS AND DESIGN Systems analysis • Related Documents – refers to other analysis and design documents that have been produced, e.g. models/diagrams • Related Requirements – refers to other requirements that relate to the same functional area of the system • Resolution – indicate the outcome of the requirement, i.e. completed, if discarded, state reason. Finally, the software requirements specification (SRS) document is produced which incorporates the above diagrams and documentation. For an example SRS template see (Wiegers, 1999). The SRS is an essential document that is used in the next phase of the SDLC – Systems design. 2.16 SUMMARY Identifying system requirements is not a simple process and requires observation and questioning of a range of stakeholders to ascertain their requirements, some of which may be contradictory or vary in priority. Analysts often produce a physical model of an existing system in order to understand its function and then produce a logical model. This is often followed by a logical model of the proposed system, which in turn may lead to the development of a physical model representing the proposed new system. Process modelling involves producing a number of sets of diagrams. These diagrams include DFDs which enable the analyst to understand a system from a physical and a logical perspective. Complex systems require a hierarchy of DFDs; the lower the level, the more detail is shown. At the lowest level elementary processes are described using decision trees, decision tables and Structured English. As the DFDs are being produced the data requirements are also being identified and these are stored within a data dictionary for reference in later stages of the system’s development life cycle. At the conclusion of the analysis phase the new system requirements have been identified and documented. These are then referred to during the next phase of the SDLC – systems design. Download free eBooks at bookboon.com 56 SYSTEMS ANALYSIS AND DESIGN 3 Object oriented analysis OBJECT ORIENTED ANALYSIS On completion of this chapter you should be able to: • • • • understand what is meant by Object Orientation (O-O) understand key O-O terms produce common O-O analysis diagrams understand a Business Process Model (BPM) diagram. Object oriented analysis modelling provides an alternative to structured analysis modelling. It views the system as a set of objects and how they interact. Object Oriented Analysis and Design (OOAD) has become more widespread with the increased use of object-oriented programming languages such as Java and Python. Download free eBooks at bookboon.com 57 Click on the ad to read more SYSTEMS ANALYSIS AND DESIGN Object oriented analysis The Unified Modelling Language (UML) (Introduction To OMG’s Unified Modeling Language® (UML®), n.d.) includes a number of diagrams (UML2 has 13) for describing a system from an object perspective and is widely used for object modelling, so helps improve communication between analysts and users. This chapter aims to introduce you to the most popular UML diagrams in their basic form. A full description of the UML is beyond the scope of this book, however further reading references are provided. In order to produce an object model, you will need to understand the following O-O terms. 3.1 OBJECTS AND CLASSES An object represents a real world item such as a bicycle or a person, and it contains both data and methods (operations) for processing the object’s data. The object’s data is stored as a set of attributes and these data values are hidden so as to prevent direct access from outside; this is called encapsulation. Objects have different states during their lifetime and these states are altered by events. Objects belong to a class, which is a group of similar objects. A class consists of a name, a set of attributes and a set of methods and is represented as shown below. For example, a racing cycle belongs to the class named bicycle. A class is the specification template for a set of objects and has attributes and methods. Each object (instance) of the class will have a particular set of attribute values and any instance of the class will be able to carry out the class methods in response to the appropriate message. Class name Class attributes Class methods Fig 3.1 shows an object class Download free eBooks at bookboon.com 58 SYSTEMS ANALYSIS AND DESIGN Object oriented analysis Example objects (instances) of the PERSON class:- Barbara De Silva 21/02/86 Female 7 Av. Atlântica Rio DeJaneiro Brazil +55 21 2323232 Mike Smith 12/06/87 Male 6 Long Row Leeds United Kingdom +44 770454545 Ahmet Aslam 12/03/85 Male At Meydan No:222 Sultan Ahmet Istanbul Turkey +90 202 527 0239 Fig 3.2 Person Objects Exercise 1 Identify three business classes for a university system. For each class identify three attributes and two methods (operations). Download free eBooks at bookboon.com 59 SYSTEMS ANALYSIS AND DESIGN Object oriented analysis Exercise 1 feedback Class Attributes Methods Student Student name Student address Student D.O.B. Amend address Enrol on course Module Module name Module length Module level Add module Alter module level Lecturer Lecturer name Lecturer office Lecturer telno. Add lecturer Amend office Object classes can be arranged into a hierarchy in which a “sub-class” inherits the characteristics of the “super-class” The sub-class has all the attributes and methods that the super-class has. This is called inheritance. The sub-class can have additional attributes and methods and can be broken down further into more detailed sub-classes. Challenge the way we run EXPERIENCE THE POWER OF FULL ENGAGEMENT… RUN FASTER. RUN LONGER.. RUN EASIER… READ MORE & PRE-ORDER TODAY WWW.GAITEYE.COM 1349906_A6_4+0.indd 1 22-08-2014 12:56:57 Download free eBooks at bookboon.com 60 Click on the ad to read more SYSTEMS ANALYSIS AND DESIGN Object oriented analysis To alter data within an object a message must be sent to the object asking it to perform an appropriate method. A message “add person” would cause the PERSON class to add a new instance of PERSON with values for its attributes (providing class PERSON has a method to add new person). Likewise, a message “Enrol” sent from LECTURER to STUDENT would enrol the student on a course. Fig 3.3 Sub-classes and super-classes In the above example the STUDENT and LECTURER classes are sub-classes of the superclass PERSON and inherit the attributes and methods of the super-class. A particular message can be sent to different objects and result in different actions being taken. For example, the following model shows a class SYMBOL which has sub-classes SQUARE and CIRCLE. If the message “Draw” is sent to the SQUARE object a square shape will be drawn; however, if the same message is sent to the CIRCLE object a circle will be drawn. This ability to interpret messages differently depending on the object is called polymorphism. Download free eBooks at bookboon.com 61 SYSTEMS ANALYSIS AND DESIGN Object oriented analysis Message: Draw Fig 3.4 Polymorphism This e-book is made with SETASIGN SetaPDF PDF components for PHP developers www.setasign.com Download free eBooks at bookboon.com 62 Click on the ad to read more SYSTEMS ANALYSIS AND DESIGN Object oriented analysis Exercise 2 Identify two sub-classes for the STUDENT class shown above in Fig 3.3. For each of the sub-classes identify two attributes and two methods which would not be in the super-class student. Exercise 2 feedback Sub-class Attributes Methods Undergraduate student Personal tutor Student status Assign personal tutor Amend status Postgraduate student Research group Research supervisor Add supervisor Amend research group Full-time and Part-time students could also be considered for sub-classes of STUDENT. Object relationship diagrams provide an overview of the system objects and how they interact, and can provide a useful overview of the system. STUDENT Studies MODULE Teaches LECTURER Fig 3.5 Object relationship diagram 3.2 USE CASE MODELLING The UML includes Use Case Modelling which is widely used to show the functionality of a system from a user’s perspective and provide a useful way of identifying and documenting the requirements for a system. A use case diagram comprises a number of scenarios. A scenario describes how a user interacts with the system in certain situations. An external entity called an actor (a person or other system) interacts or communicates with a use case which carries out a process or function. To illustrate how a use case diagram is formed, here is an example from the point of view of a hotel receptionist. The scenario for booking a hotel room for a guest would be: Download free eBooks at bookboon.com 63 SYSTEMS ANALYSIS AND DESIGN Object oriented analysis “Ask the guest what type of room they would like and how long they wish to stay. Check the bookings system to see what rooms are available. Confirm a room and dates with the guest. Enter the booking details on the system.” Note how this is written from the point of view of the system user (the receptionist). However, consider what happens if the receptionist is unable to offer a room of the type requested. Another scenario can be specified to deal with this situation, for example the guest may be offered a different grade of room. The “Book Room” use case would consist of the main success scenario (expected to deal with most cases) and an extension scenario to deal with the exception. (Note There may be a number of extension scenarios depending on the situation). Book Room Main success scenario 1. Ask guest what type of room they require 2. Check bookings system for room availability 3. Confirm room booking with guest 4. Update the bookings system. Extensions (additional scenarios or exceptions) 1a. Room type not available 1a1. Identify alternative available room type 1a2. Return to step 3 in the main success scenario. Fig 3.6 A simple use case description Although a simple description similar to the one above may be suitable for a simple use case or for a small system, for more complex systems, analysts often produce a more comprehensive description which includes additional information. The following template illustrates this for the scenario above. Download free eBooks at bookboon.com 64 SYSTEMS ANALYSIS AND DESIGN Use case name Object oriented analysis Book room. Scenario Book hotel room for guest. Trigger Guest requests a room. Description Actors Related use cases When a guest requests a room type the receptionist checks the bookings system to see what rooms are available. If a room of the type requested is available a booking is confirmed. Hotel receptionist. Check room availability. Stakeholders Hotel management. Pre-conditions Guest requiring a room. Post-conditions Room booking confirmed. Main scenario 1. Ask guest what type of room they require 2. Check bookings system for room availability 3. Confirm room booking with guest 4. Update the bookings system. Extensions 1a. Room type not available 1a1. Identify alternative available room type 1a2. Return to step 3 in the main success scenario. Fig 3.7 Extended use case description Note. There are many use case description templates in use. However, they all include the main information requirements. A simple use case diagram based on the above scenario is shown below. System boundary Actor Communication association Use case Fig 3.8 A simple use case Download free eBooks at bookboon.com 65 SYSTEMS ANALYSIS AND DESIGN Object oriented analysis Use cases can also interact with other use cases. This is the case when one use case includes the functionality of another use case. It is shown by using the relationship. The following example shows that the use case for checking room availability would be incorporated into the use case for booking a room. Fig 3.9 A use case with association Note. The use case symbols are shown enclosed within a box to indicate the boundary of the system and the lines linking the actors to use cases are called “communication associations”. Note that some diagrams may include arrow tips pointing in the direction of the communication. An relationship can also be used to show the optional use of a use case, for example a use case “Make payment” might be extended to include a use case for “Credit card payment” and an alternative use case for “Cash payment”. www.sylvania.com We do not reinvent the wheel we reinvent light. Fascinating lighting offers an infinite spectrum of possibilities: Innovative technologies and new markets provide both opportunities and challenges. An environment in which your expertise is in high demand. Enjoy the supportive working atmosphere within our global group and benefit from international career paths. Implement sustainable ideas in close cooperation with other specialists and contribute to influencing our future. Come and join us in reinventing light every day. Light is OSRAM Download free eBooks at bookboon.com 66 Click on the ad to read more SYSTEMS ANALYSIS AND DESIGN Object oriented analysis Use cases should include all related transactions, so in the case of a guest booking into a hotel the associated transactions include room booking, issuing the bill and bill payment. This situation is shown by the use case diagram below. Fig 3.10 Hotel booking use case diagram Exercise 3 Produce a use case description for the following scenario:“The hotel housekeeping manager checks the toiletries stock file on a weekly basis to ensure that there are sufficient quantities of soaps, shampoos etc. available. Where necessary, an order is raised to be sent to the supplier. Copies of the orders are kept and used to check the supplier delivery notes and invoices when they are received. Occasionally the suppliers are unable to send the requested toiletries and will suggest alternatives. Once the toiletries have been supplied the stock file is updated.” Download free eBooks at bookboon.com 67 Deloitte & Touche LLP and affiliated entities. SYSTEMS ANALYSIS AND DESIGN Object oriented analysis Exercise 3 feedback Main success scenario 1. Check stock file weekly 2. If stock quantity < reorder level, raise supplier order 3. File order copy 4. Check order against delivery note/invoice 5. Update stock file with supplies. Extensions 2a Supplier not able to supply toiletries 2a1 Choose alternative toiletries 360° thinking 2a2 Return to step 3 in the main success scenario. . 360° thinking . 360° . thinking Discover the truth at www.deloitte.ca/careers © Deloitte & Touche LLP and affiliated entities. Discover the truth at www.deloitte.ca/careers © Deloitte & Touche LLP and affiliated entities. Discoverfree theeBooks truth atatbookboon.com www.deloitte.ca/careers Download Click on the ad to read more 68 Dis SYSTEMS ANALYSIS AND DESIGN 3.3 Object oriented analysis CLASS DIAGRAM When the analyst has identified the object classes from the use case diagrams, a logical model in the form of a class diagram is produced to show the associations between them. A class association is used to represent the relationship between two classes. It has a descriptive label and shows multiplicity. Multiplicity describes how many instances of one class in the relationship relates to instances of the other class. This is also sometimes referred to as cardinality. The multiplicity of a relationship indicates the minimum and maximum number of occurrences and is shown using the following symbols:0..1 is read as zero or one 1..1 is read as one and only one 0.. * is read as zero one or many 1.. * is read as one or many In the following class diagram the binary relationship between MODULE and LECTURER would be read from right to left as one LECTURER delivers one or many MODULEs (1..*) and read left to right, one module is delivered by zero or one lecturer (0..1). The implication here could be either that a module may not yet have a lecturer assigned to deliver it, or that it is a self-study module. Now let us consider the many-to-many relationship between STUDENT and MODULE. As a student can study one or many modules (1..*) and a module may be studied by zero, one or many students (0..*) there will be a need to store additional data generated by this relationship – the assessment mark and grade for each student taking a module. Whilst you may consider storing this information in either of the classes, this would not be a practical solution due to the potentially large number of items of data, so the data is held in a new association class named STUDIES, which is shown linked to the initial relationship with a dashed line. This approach resolves the many-to-many relationship in an effective implementation that can cope with any number of students taking any number of modules. Download free eBooks at bookboon.com 69 SYSTEMS ANALYSIS AND DESIGN Object oriented analysis Fig 3.11 Example Class diagram Note. It is important to consider each relationship from both directions to ensure you specify the correct multiplicity when drawing a class diagram. 3.4 SEQUENCE DIAGRAMS The sequence diagram is used to show the interactions between objects in the sequence that they occur. They can prove useful in showing the dynamics of how a use case works and can be used to document the requirements for the new system. They are produced using the information acquired from the use case diagrams and scenario descriptions. Sequence diagrams can be drawn in varying degrees of detail depending on where they are being used within the SDLC. The basic elements are shown in the diagram below. Download free eBooks at bookboon.com 70 SYSTEMS ANALYSIS AND DESIGN Object oriented analysis The following shows a sequence diagram for the Exercise 3 Toiletries stock check:- Fig 3.12 Simple sequence diagram for stock ordering The sequence diagram is made up of four main components:- classes, lifelines, messages and activation boxes. We will turn your CV into an opportunity of a lifetime Do you like cars? Would you like to be a part of a successful brand? We will appreciate and reward both your enthusiasm and talent. Send us your CV. You will be surprised where it can take you. Download free eBooks at bookboon.com 71 Send us your CV on www.employerforlife.com Click on the ad to read more SYSTEMS ANALYSIS AND DESIGN Object oriented analysis The classes HOUSEKEEPING MANAGER, STOCK ITEM, SUPPLIER ORDER and SUPPLIER are represented by rectangles. The classes have lifelines which are represented by the vertical dashed lines. The lifeline indicates the time period that its class object is communicating with the other objects. The messages are shown as horizontal arrowed lines pointing in the direction the message is travelling, and include a label indicating the name of the message. The first message is usually shown at the top with subsequent messages being arranged below one another. When messages are sent to an object this triggers a method (operation) within that object. Sequence numbers can be added to the messages, though this is not usually necessary as the vertical order of messages indicates the sequence. The activation boxes are shown as a vertical bar (in blue) over the lifeline and this indicates the period of time when an object is carrying out an operation often referred to as the focus of control. A large X is sometimes shown at the bottom of an activation box to indicate the destruction of an object at the end of its lifeline. Note. Complex interactions may require more than one sequence diagram to fully represent the main and alternative scenarios. Sequence diagrams are useful when you have a complex scenario to work through. 3.5 STATE MACHINE DIAGRAMS As has already been shown, objects have behaviours and states. In order to understand the various states an object goes through during its existence a state machine diagram, sometimes referred to as a state transition diagram, can be drawn. This diagram shows the transitions between the states that an object may undergo, caused by internal or external events. State machine diagrams tend to be created when examining a class with a complex life cycle. The state machine diagram shown below represents a university student and the various stages or states that they transition. The round-edged rectangles represent the states:- initially the student will be regarded as an applicant, then they will be enrolled, when they arrive they will be registered and normally they will complete their course. Whilst at the university they may be withdrawn either temporarily or permanently. The small solid circle is the initial state, i.e. when the object starts its interaction with the system. The arrows indicate the event that triggers the transition from one state to another. The solid circle with the border represents the object’s final state. Download free eBooks at bookboon.com 72 SYSTEMS ANALYSIS AND DESIGN Object oriented analysis Fig 3.13 A state machine diagram for a university student. 3.6 ACTIVITY DIAGRAMS An activity diagram is used to show actions and events in the order they take place, along with their outcomes. The following activity diagram is based on the scenario described in Exercise 3 above. The solid circle represents the start state of the diagram. The rounded rectangle represents an activity (manual or automated), the arrow represents an event (something that happens at a time and place) and the diamond represents a decision or branch, the condition value can be shown and is referred to as a guard condition. Additional symbols that can be used are a flat rectangle bar which represents a synchronisation, a fork which allows activities to take place in parallel and a join which brings events together. The final state (end of diagram) is shown by a solid circle with a border. Fig 3.14 An activity diagram for hotel stock ordering Activity diagrams can be partitioned using pairs of lines referred to as “swimlanes” to show the activities which are performed by the different roles participating in the process. A role can be a user type – e.g. manager – or a platform – e.g. a web server. In the above scenario all the activities are carried out by the hotel housekeeping manager so swimlanes have not been included. Download free eBooks at bookboon.com 73 SYSTEMS ANALYSIS AND DESIGN Object oriented analysis To create an activity diagram, consider the order in which activities take place and consider any conditions that may arise so that all the scenarios for the use case have been considered. If you have produced a physical DFD this may help to identify the order of activities. 3.7 BUSINESS PROCESS MODELLING One final graphical modelling technique that can be used to represent how systems work, showing the business processes, events and people involved, is the standard business process model and notation (BPMN) (Object Management Group Business Process Model and Notation, 2014). The BPMN can be used to model requirements and can also be used in later stages of the development cycle. Its purpose is to provide a standard notation which can be understood by analysts, developers and other business stakeholders. A diagram consists of events, activities (tasks), sequence flows and gateways, which control the direction of flows. AXA Global Graduate Program Find out more and apply Download free eBooks at bookboon.com 74 Click on the ad to read more SYSTEMS ANALYSIS AND DESIGN Object oriented analysis Hotel Receptionist Lane name Hotel Reception The following simple business process diagram shows the hotel room booking processes mentioned in section 3.2 above. Fig 3.15 Simple business process diagram for room booking “Request room” is the starting event. The first activity task “Check room type available” is carried out, followed by an exclusive gateway (diamond) which represents the “Room type” check to ascertain whether it is available; if not, another task “Find alternative room” is undertaken. This is followed by an inclusive gateway (diamond with a circle) which routes the sequence flow to the task “Book room”. The business process diagram can be partitioned to show which tasks are undertaken by different participants, although in this example all the tasks are undertaken by the hotel receptionist. A diagram typically consists of a pool (like a swimming pool, shown as a large rectangle positioned horizontally or vertically) which is partitioned into a number of lanes. Each lane shows a sub-partition of a process which is carried out by a participant. The above example only utilises one lane as the whole process is carried out by just one participant – the hotel receptionist. If further participants are involved these would appear in different swim lanes and the flows and symbols would be inserted in the relevant swim lane with flows linking across the swim lanes when necessary. Download free eBooks at bookboon.com 75 SYSTEMS ANALYSIS AND DESIGN Object oriented analysis Detailed diagrams can be drawn utilising the full set of symbols which include messages, timers, signals and further gateway types. For the full specification see http://www.omg.org/ spec/BPMN/2.0.2/ (Object Management Group Business Process Model and Notation, 2014) 3.8 SUMMARY The analyst can use the UML to analyse the system requirements from an object-oriented perspective. This involves producing a set of diagrams to reflect the user’s needs and specify the system’s requirements. These include use case diagrams, class diagrams, sequence diagrams, state machine diagrams and activity diagrams. These should be reviewed with the business users until all are satisfied that they accurately reflect the requirements. The UML models will in effect provide a detailed set of specifications to be used later in the systems design phase of the SDLC. The O-O approach to modelling aims to utilise the reusability of objects and also aids maintainability of systems. Further reading: (Agile Models Distilled: Potential Artifacts for Agile Modeling, n.d.) Download free eBooks at bookboon.com 76 SYSTEMS ANALYSIS AND DESIGN 4 Systems design SYSTEMS DESIGN On completion of this chapter you should be able to: • produce an efficient data design • design an effective user interface • describe system architectures. Following the completion of the systems analysis phase of the traditional SDLC, the system development phase can begin. However, at this point a decision may be made to consider available options for acquiring the system. Typical options include ou...