1

Charlie Abela - Edited by

Riccardo Flask
Systems Development 1
Systems LiIe Cycle
Large systems development projects involves many
people working Ior many months.
Development process has to be planned well to
ensure that the project is delivered on time and to the
required speciIication
System liIe cycle development process is very
methodical and sequential.
Each stage is composed oI well deIined activities
and responsibilities and has to be completed beIore
the next stage begins
Charlie Abela - Edited by
Riccardo Flask
Systems Development 2
Classical WaterIall Model
SoItware liIe cycle is also reIerred to as the
'WaterIall Model
The WaterIall Model usually includes the
Iollowing processes:
{ Problem deIinition
{ Feasibility study
{ Requirements analysis
{ Design
{ Programming and module testing
{ Integration and system testing
{ Delivery
{ Maintenance
2
Charlie Abela - Edited by
Riccardo Flask
Systems Development 3
WaterIall Model
Post-
impIementation
review
Conversion
Coding and
testing
Design
Requirements
AnaIysis
FeasibiIity
study
AnaIysis
Design
ImpIementation
Review and
Maintenance
Charlie Abela - Edited by
Riccardo Flask
Systems Development 4
WaterIall Model
One stage Ieeds its output or deliverable into
the next stage
The deliverables Irom every stage are clearly
deIined
All parties involved (end-users, management
and developers) have to approve the
deliverables beIore the next stage can be
started
3
Charlie Abela - Edited by
Riccardo Flask
Systems Development 5
Problems
DiIIiculty oI accommodating change aIter the process is
underway. One phase has to be complete beIore moving
onto the next phase.
InIlexible partitioning oI the project
Only appropriate when the requirements are well-
understood and changes will be Iairly limited during the
design process.
Few business systems have stable requirements.
The waterIall model is mostly used Ior large systems
engineering projects where a system is developed at
several sites.
Systems Development
Preliminary Investigation
4
Charlie Abela - Edited by
Riccardo Flask
Systems Development 7
Feasibility Study (TELOS)
Main aim: understand the problem and determine as much
as possible all the issues involved should the problem be
tackled
Technical feasibility: investigate whether the technology
exists to implement the proposed system, or whether it is a
practical proposition
Economic feasibility: establish iI proposed system is cost-
eIIective iI beneIits do not outweigh costs, it's not worth
going ahead.
Charlie Abela - Edited by
Riccardo Flask
Systems Development 8
Feasibility Study (TELOS) |cont|
Legal feasibility: determine iI there is any conIlict
between the proposed system and legal requirements
e.g. the Data Protection Act
Operational feasibility: determines iI the current
work practices and procedures are adequately
supported by the new system: how change aIIects the
working liIe oI workers
Schedule feasibility: looks at how long the system
will take to develop, or whether it can be done in a
desired time-Irame
Deliverable Irom this stage is a Ieasibility report
produced by the system analyst. II the project is to
proceed then a project plan and budget estimate Ior
the other stages oI development will be produced.
5
Systems Development
Requirements SpeciIication
and Analysis
Charlie Abela - Edited by
Riccardo Flask
Systems Development 10
Requirements engineering
The process oI establishing the services
that the customer requires Irom a system
and the constraints under which it operates
and is developed.
The requirements themselves are the
descriptions oI the system services and
constraints that are generated during the
requirements engineering process.
6
Charlie Abela - Edited by
Riccardo Flask
Systems Development 11
What is a requirement?
May range Irom a high-level abstract statement
oI a service or oI a system constraint to a
detailed mathematical Iunctional speciIication.
Requirements may serve a dual Iunction
{ May be the basis Ior a bid Ior a contract
(interpretation)
{ May be the basis Ior the contract itselI (detail)
{ Both these statements may be called requirements.
Charlie Abela - Edited by
Riccardo Flask
Systems Development 12
Functional Requirements
Describe Iunctionality or system services.
Depend on the type oI soItware, expected
users and the type oI system where the
soItware is used.
{ Iunctional user requirements may be high-
level statements oI what the system should do
{ Iunctional system requirements should
describe the system services in detail.
7
Charlie Abela - Edited by
Riccardo Flask
Systems Development 13
Example: Functional Requirements
Some Iunctional requirements oI a
university library system
{ to search Ior a library item by speciIying a
key word
{ to issue a library item to a library member
{ to reserve a library item on line
Charlie Abela - Edited by
Riccardo Flask
Systems Development 14
Non-Functional Requirements
These deIine system properties and
constraints
Non-Iunctional requirements may be more
critical than Iunctional requirements. II
these are not met, the system is useless.
8
Charlie Abela - Edited by
Riccardo Flask
Systems Development 15
Non-Functional classiIication
Product requirements
{ Requirements which speciIy that the delivered product must
behave in a particular way e.g. execution speed, reliability, etc.
Organisational requirements
{ Requirements which are a consequence oI organisational
policies and procedures e.g. process standards used,
implementation requirements, etc.
External requirements
{ Requirements which arise Irom Iactors which are external to the
system and its development process e.g. interoperability
requirements, legislative requirements, etc.
Charlie Abela - Edited by
Riccardo Flask
Systems Development 16
ATM Example: Functional and
Non-Functional Requirements
The Iunctional requirements oI the ATM:
{ authorization process
{ transaction (withdrawal process)
The non-Iunctional requirements
{ The ATM network has to be available 24 hours a day.
{ Each bank may be processing transactions Irom
several ATMs at the same time.
{ The ATM must be able to use several data Iormats
according to the data Iormats that are provided by the
database oI diIIerent banks.
9
Charlie Abela - Edited by
Riccardo Flask
Systems Development 17
Requirements completeness and
consistency
In principle, requirements should be both
FRPSOHWH and FRQVLVWHQW.
Complete
{ They should include descriptions oI all
Iacilities required.
Consistent
{ There should be no conIlicts or contradictions
in the descriptions oI the system Iacilities.
In practice, it is impossible to produce a
complete and consistent requirements document.
Charlie Abela - Edited by
Riccardo Flask
Systems Development 18
Problems oI requirements analysis
Stakeholders don`t know what they really want.
Stakeholders express requirements in their own
terms.
DiIIerent stakeholders may have conIlicting
requirements.
Organisational and political Iactors may
inIluence the system requirements.
The requirements change during the analysis
process. New stakeholders may emerge and the
business environment change.
10
Charlie Abela - Edited by
Riccardo Flask
Systems Development 19
Requirements Analysis Process
During this phase a more detailed investigation into the current system
and its requirements are made
This phase can be divided into 3 sections
{ Determining requirements: Persons responsible oI this phase have to
gather information about the status oI the existing system and the
requirements oI the new one. This entails defining a set of questions,
deciding on which sources of information to use and determine the most
appropriate information-gathering technique to use
{ Analyzing these requirements: The collected data will be used to gain a
clear understanding oI the status oI the present system and the
requirements oI the new system. In order Ior this process to be eIIective the
raw data needs to be presented in an appropriate Iormat.
{ Produce a report: When the analysis has been undertaken, a report is
presented to the manager responsible Ior approving the next stage oI the
development.
Charlie Abela - Edited by
Riccardo Flask
Systems Development 20
The Analyst
Someone with the ability to capture user
and system needs at diIIerent levels
Someone who can envisage a system Irom
diIIerent aspects (points oI view)
Someone who can communicate ideas on a
non-technical basis
Someone who can save (or cost) an
organization a lot oI eIIort and money
11
Charlie Abela - Edited by
Riccardo Flask
Systems Development 21
Determining Requirements
What Iunction does the
current system perIorm?
What are the shortcomings in
the current system that the new
system will remove?
What data will be required Ior
the new system?
What are the sources oI the
data?
How will the data be collected
and inputted?
What outputs will be required
by the new system?
How will the old system
interact with the new one?
What questions need
to be asked?
What sources of information
can be used?
External sources:
Customers/clients
Suppliers
Government agencies
Consultants
Competitors
Internal sources:
Direct users
Indirect users
Senior managers
Technical support staII
Existing policies, reports,
organisation docs
Existing systems and
procedures
Structured interviews with
individuals, i.e. questions
determined in advance
Unstructured interviews with
individuals, i.e. open-ended
discussions
Observation oI existing
practice
Reading oI documentation,
journals, manuals
Questionnaires to users
Examination oI
documentation related to
current system
Visits to other organisations
What information gathering
techniques can be used?
Charlie Abela - Edited by
Riccardo Flask
Systems Development 22
Scenarios/Use-Cases
Scenarios: real-liIe examples oI how a system can be
used. They should include
{ A description oI the starting situation;
{ A description oI the normal Ilow oI events;
{ A description oI what can go wrong;
{ InIormation about other concurrent activities;
{ A description oI the state when the scenario Iinishes.
Use-cases
{ Use-cases are a scenario-based technique which identiIy the
actors in an interaction and which describe the interaction itselI.
{ A set oI use cases should describe all possible interactions with
the system.
12
Charlie Abela - Edited by
Riccardo Flask
Systems Development 23
Example: ATM Scenario
Scenario: A successful withdrawal attempt at an automated teller
machine (ATM).
{ John Smith presses the Withdraw Funds button
{ The ATM displays the preset withdrawal amounts (Lm25, Lm30, etc)
{ John chooses the option to speciIy the amount oI the withdrawal
{ The ATM displays an input Iield Ior the withdrawal amount
{ John indicates that he wishes to withdraw Lm50
{ The ATM displays a list oI John`s accounts, a checking and two savings
accounts
{ John chooses his checking account
{ The ATM veriIies that the amount may be withdrawn Irom his account
{ The ATM veriIies that there is at least Lm50 available to be disbursed Irom the
machine
{ The ATM debits John`s account by Lm50
{ The ATM disburses Lm50 in cash
{ The ATM displays the 'Do you wish to print a receipt? options
{ John indicates 'Yes
{ The ATM prints the receipt
Charlie Abela - Edited by
Riccardo Flask
Systems Development 24
Example: ATM Use-Case
13
Charlie Abela - Edited by
Riccardo Flask
Systems Development 25
Analysing Requirements
There are several analytical techniques that can be
applied to achieve this.
Data Flow Diagrams
DFDs represent diagrammatically the relationship between diIIerent
systems in the organisation and how data moves around in these systems.
They contain Iour main components:
Entities (e.g. customers)
Processes (e.g. computing total)
Data Flow (ie. the origin, destination and direction oI data transIer)
Data Store (any location where data is held e.g. customer data Iile)
Charlie Abela - Edited by
Riccardo Flask
Systems Development 26
Data Flow Diagrams (DFD)
Shows how data moves through a system
and what data stores are used.
It does not speciIy what W\SH oI data is
used and KRZ the data is stored.
14
Charlie Abela - Edited by
Riccardo Flask
Systems Development 27
DFD Symbols
External
Entity
datastore 1
Data source or data destination: eg. people who generate data
such as a customer order, or receive inIormation such as an
invoice
An operation perIormed on the data. The top
section oI the box is used to label the process.
The middle part is used to give a brieIs explanation.
Represents a data store such as a Iile held on disk or a batch
oI documents.
Data Ilow representation: the arrow represents the movement
between entities, processes and data stores. It should be labelled
to describe what data is involved
1
Process
1
Process
OR
Charlie Abela - Edited by
Riccardo Flask
Systems Development 28
DFD: DiIIerent levels oI abstraction
View the system at diIIerent levels oI details
{ Level 0 (Context diagram)
Comprises a single process, all agents, and input/output data
Ilows
Purpose: IdentiIy and examine the external interIaces
{ Guidelines Ior drawing Level 0
Look Ior entities that give data to the system
Look Ior entities that accept data Irom the system
IdentiIy the data elements at an abstract level
Draw the diagram