Contents

7 The Systems Life Cycle.....................................................................................................................1

7.1 Analysis......................................................................................................................................1
7.1.1 Analyse the Current System................................................................................................2
7.1.2 Record and analyse information about the current system.................................................2
7.1.3 System specification...........................................................................................................3
7.2 Design.........................................................................................................................................4
7.2.1 Design.................................................................................................................................4
7.2.2 Validation routines..............................................................................................................5
7.2.3 Input formats (data capture forms)......................................................................................6
7.2.4 Output formats – screen layouts and report layouts............................................................6
7.3 Development and testing............................................................................................................7
7.3.1 Testing.................................................................................................................................7
7.4 Implementation...........................................................................................................................9
7.4.1 System implementation.......................................................................................................9
7.5 Documentation.........................................................................................................................10
7.5.1 Documentation..................................................................................................................10
7.6 Evaluation.................................................................................................................................11
7.6.1 Evaluate a solution............................................................................................................11
7 The Systems Life Cycle
A cycle of events take place until a fully-working system is signed off and handed over to the
management team. This whole process is called the systems life cycle.

7.1 Analysis
7.1.1 Analyse the Current System

7.1.2 Record and analyse information about the current system

In second stage, analyst is required to find out:
 What input and output takes place

 What processing is done
 What problems exist with the current system
 User and information requirements for the new system.
Data Flow Diagram: One of the ways to analyse process of current system is DFD. From the DFD,
one can get the following information:
  What inputs take place during the customer enquiry
 What outputs are produced
 What processing is done
 What storage may be needed

Upon looking at each stage in the DFD process, analysts will identify:
 Any problems that occur in the current system, by looking at the data flows in each stage of the
process and looking for bottlenecks and other potential areas where errors do/could occur.
 User and information requirements

User requirements
Creation of a computer system is the job of coders/system developers. However, they don’t understand
how the business works neither do business managers know how to word their requirements as
understood by developers. Analysts act as a go between business and developers. They design the user
requirements in consultation with the business owner/client.
 User requirements are written by the analyst for the business managers/customers
 They are written in natural language with very few technical details or jargon.
 Their purpose is to allow the customers to check that what the analyst proposes, following the
investigations, is exactly what they originally specified
 The user requirements will also describe what the analyst thinks the customer does with their
system.

Information requirements
 Information needed to support the business.
 The information requirements are made up of:
o what? (data)
o when? (timing).
A systems analyst turns the information and user requirements into a functional requirements
specification. These specify how the new system will be developed and implemented, including
timescales. The requirements are typically defined as a list of, for example:
 Who the customers are and how they interface with the system?
 Who the vendors are (the sellers of the products), and how they interface with the system?
 Who the employees are and how they interface with the system?

7.1.3 System specification

Information gathering processes allow the analysis team to identify hardware and software
requirements of the new system.
Identify and justify hardware
 Identification and justification of which input devices are needed might be, for example:
– barcode readers (avoids the need to manually input data about goods, more efficient, less
error-prone and less expensive in the long run)
– scanners (used to convert any existing paper documents into an electronic format during the
implementation stage, if necessary)
– touch screens (best information gathering tool, can be used as a notebook to ensure an
employee does not miss any important data during a customer conversation).
 Identification and justification of which output devices are needed; for example:
– 3D printer (for prototype building)
– very large 60” (152 cm) monitors (the company may be using CAD software and the need for
very large, expensive monitors, may be justifiable)
– speakers (in case of employees with disabilities, verbal outputs may be necessary, justifying
the requirement of speakers.)
Identify and justify software
 Identification and justification of which software is required; for example:
 – operating system (client may need a speciality OS, or use Mac alone necessitating
development targeting that OS)
– applications software:
o off-the-shelf software, like Word or Excel, may be required for smooth functioning. Such
OTS software don’t require special training and have a big user base to tap into for
troubleshooting.
o bespoke software (written specifically for the company) – needs time, & money to
develop. Users need considerable training, and help needed from technical team as no
userbase.
 Storage requirements also need to be considered; for example:
– size of storage (both present and future)
– type of storage (hard disk drives, solid-state drives or magnetic tape drives) – the
choice could depend on:
o data access and data write speeds
o number of read-write operations
o type of access – (serial access/direct access)
o if huge amounts of storage are required and data access time is not that important,
magnetic tape may still be the best option.
7.2 Design
7.2.1 Design
Once the analysis of the existing system has taken place, and the systems analyst has a better idea of
the scale of the problem. The next stage in the process is design.

Fields Primary Key

Files Records Fields

Fields
Common Data types

7.2.2 Validation routines

Validation is the process where data entered into a computer is checked to see if it satisfies certain
criteria. It is an automatic check carried out by the computer as part of its programming. Any data
failing these criteria should be rejected. Validation is not a check on whether the data is correct or
accurate; it is only a check to see if it is reasonable.
7.2.3 Input formats (data capture forms)
Data capture forms are often used to input data into a computer. These forms ensure data is input into
the computer in the correct format. They need to be designed very carefully to ensure that the format
of the data matches, for example, the database where the data is being stored.
Data capture forms will be either paper-based or electronic-based depending on the application.
Paper-based forms need to:
 Have a heading to make the purpose of the form clear
 Make it clear to the person filling in the form where they must place their answers
 Make use of text boxes which will limit the amount of information collected
 Make use of character boxes for data such as surnames, telephone numbers, and so on (each box
allows one character only)
 Make use of printed text boxes to allow for easy input of items such as date of birth
 Make use of tick boxes to make choices easier (such as sex – male or female)
 Make sure there is sufficient space to write answers
 Make use of clear fonts and clear text colours to ensure the form is easy to read.

7.2.4 Output formats – screen layouts and report layouts

The output from any system should be designed:
 to make sure the size of all the output fields is correct
 so that any instructions/descriptions are clear
  so that the full screen is utilised
 so that colours and fonts (size and type) make the output clear.

If the output is on paper, then consideration must also be given to the type of output. Items such
as headers and footers, fitting the page correctly, whether it should be in colour, etc.

Reports (eg output from a database search) should clearly show all the fields that were included in the
search criteria.
7.3 Development and testing
7.3.1 Testing
The need for testing
After design stage, system is developed (coded) and fully test it.

 If the system contains files (for example, a database) then the file structure would need to be
finalised at this stage. For example
o What type of data is being stored in each field?
o Length of each field
o Which field will be the primary key field?
o How will the data files be linked, etc.?
 Once the file structure has been determined it is then created and needs to be fully tested to make
sure it is robust when the system actually goes live.
 Since one needs to ensure that the correct data is stored in files (etc.), certain techniques need to be
adopted to make sure the data populating the files/database is of the right type and conforms to
certain rules. (Validation routines and verification methods). These routines have to be fully
tested to ensure they trap unwanted data, and to make sure any data transferred from a paper-based
system to an electronic system has been done accurately.
 System’s user interface will be tested for efficiency and accuracy. And to check if they are user
friendly.
 User interface will also be tested against user requirements to check if it confirms to client’s
requirements,
Test designs
Test designs cover how a system is to be tested. In test designs we need to ensure the following aspects
can be achieved:
 Testing the data structures
 Testing the file structures
 Testing the input methods
 Testing the output formats
 Testing the validation rules.
Test strategies
 Software is often developed in modular form. This method allows it to be broken down into
smaller parts (known as modules). Each module is developed separately by a programmer (or
team of programmers).
 Each module needs to be tested separately to see if it functions correctly. Any problems resulting
from the testing require the module to be modified and then tested again.
 Once the development of each module is completed, the whole system needs to be tested as a
whole (with all modules functioning together). Even though each module may work satisfactorily,
when they are all put together there may be data clashes or incompatibility, memory issues, etc.
 All of this may lead to a need to improve the input and output methods, file/database structures,
validation and verification methods, etc. and then fully test everything again. It is a very time-
consuming process, but has to be as perfect as possible before the system uses live data.

Test plan, test data and live data

Once the testing designs and strategy have been determined, it then becomes necessary to formulate a
test plan for each module. The test plan should include:
 A list of all the tests to be performed
 What data is to be used in the testing
 What type of testing the data is designed to check (i.e. Normal, abnormal or extreme – see notes
below)
 What live data should be used
 What the expected outcomes are from the testing
 Do the actual outcomes match what is expected?
Types of data:
Normal – this is data which is acceptable/valid and has an expected (known) outcome;
Extreme – this is data at the limits of acceptability/validity;
Abnormal – this is data outside the limits of acceptability/validity and should be rejected or cause an
error message;
Once a system has been fully tested, it is then tested with live data. This is data with known outcomes.
Live data is entered into the new system and the results compared with those produced from the
existing system. If the two outcomes do not match, then further modifications to the system may be
needed.

Example of a test plan

The test plan shown in Figure 7.11 is designed to test a module where temperatures are input which must
be in the correct range (21 °C to 50 °C). Any temperatures outside this range should be rejected. The input
temperatures can be integer or real (decimal).

7.4 Implementation
7.4.1 System implementation
Once the system is fully tested, the next stage is to fully implement it. Changeover to the new system
may be done in different stages at under:
7.5 Documentation
7.5.1 Documentation
For the new system, there is a need to produce documentation for:
1. People who may need to modify or develop the system further at some later stage
a. The end-user.

Technical documentation: designed to help programmers/analysts to make improvements to the

system or repair/maintain the system. This can consist of any of the following:
Program listing/coding Programming language used
Program flowcharts/algorithms System flowcharts
Purpose of the system/program/software Limitations of the system
Input formats Hardware requirements
Software requirements Minimum memory requirements
Known ‘bugs’ in the system List of variables used (and their meaning/description)
File structures Sample runs (with results and actual test data used)
Output formats Validation rules
Meaning of error messages.
User documentation/Manual: designed to help users to learn how to use the software or system. This
can consist of any of the following:
How to load/install/run the software How to save files
How to do a search How to sort data
How to print out How to add, delete or amend records
Limitations of the system Screen layouts (input format)
Print layouts (output format) Hardware requirements
Software requirements Sample runs (with results and actual test data used)
Error handling/meaning of errors Troubleshooting guide/help lines/faqs (frequently asked
questions)
How to log in/log out Tutorials
Error messages/meaning of error messages Glossary of terms.
7.6 Evaluation
7.6.1 Evaluate a solution
After a system is implemented, it is evaluated for performance, maintenance etc. The following is a list
of some of the things to be considered when evaluating how well the new system has worked;
 Compare the final solution with the original task requirements.
 Identify any limitations of the system.
 Identify any necessary improvements that need to be made.
 Evaluate the users’ responses to using the new system.
 Compare test results from the new system with results from the old system.
 Compare performance of the new system with performance of the old system.
 Observe users performing set tasks (compare old with new).
 Measure the time taken to complete tasks (compare old with new).
 Interview users to gather responses about how well the new system works.
 Give out questionnaires to gather responses about the ease of use of the new system.
Is the new solution:
– more efficient? (‘to use’ or ‘for the business’)
– easy to use?
– appropriate for the task it was designed for?
Some results from the evaluation may lead to two things happening:
 Update of hardware because:
o of feedback from end-users
o new hardware comes on the market, necessitating change
o changes within the company require new devices to be added or updated.
 Update of software because:
o of feedback from end-users
o changes to the company structure or how the company works that may require modifications
to the software
o changes in legislation that may require modifications to the software.

Evaluation may result in redesign of a system, if there is strong evidence to suggest that changes need
be made.
1. Validation checks:
a. Password should be 8 characters long.
Password should contain only numbers
and letters (alphanumeric) b. Aaaaaaaa; As23; Aaaa11aa
Order of password should be c. Qwe; >12aaq; As12aa34
xxxxnnxx.
2. Validation checks
a. Name should be text only.
b. Dob format should be dd/mm/yyyy
c. Telephone number must be numeric
d. Order Ref No must follow format (mostly it’ll be auto generated) – Primary Key
e. At least one of the options must be selected.
 Data item Field Normal Abnorma Extreme
l
15 month 
12 month 
07 month 
1.6 month 
1 month 
0 month 
13 month 
March month 
1 day 
31 day 
18 day 
Tuesday day 
45 day 
0 day  
30 day
0001 year 
2021 year 
90.55 year 
−25 year 
1854 year 

2. Day: 0 < value < 31; numeric data

Month: 0 < value < 13; numeric data
Year: 0 < Value < 2023; numeric data
3.
Field name Normal Extreme Abnormal
Name of holiday resort Sunshine Resort Sunshine-Resort @Sunshine$Resort
Avg daily temp 20 45 10.0; hundred
No of hours of 6 24 48
sunshine per day

Exam-style questions
1. For each of these questions, choose the correct response from the five options given. [10]
b. Live data is the data with known
outcome. It is the input that the system
handles in real world.
c. Code; known bugs/errors; File
structures
1. format check – xxx/xxxx, where x is a number
2. length check – length = 8 characters
a. direct changeover
b. pilot
c. length
d. design
e. modular development
a. Evaluation is the last stage on one iteration of system analysis and design life cycle.
Following are its characteristics:
1. It is carried out to evaluate a system once it is up and running
2. Evaluation may lead to a redesign of part/whole system
3. Following are some of the things to consider while evaluating a system:
» Compare the final solution with the original task requirements.
» Identify any limitations of the system.
» Identify any necessary improvements that need to be made.
» Evaluate the users’ responses to using the new system.
» Compare test results from the new system with results from the old system.
» Compare performance of the new system with performance of the old system.
» Observe users performing set tasks (compare old with new).
» Measure the time taken to complete tasks (compare old with new).
» Interview users to gather responses about how well the new system works.
» Give out questionnaires to gather responses about the ease of use of the new
system.
4. That is, is the new solution:
– more efficient? (Cost wise or utility wise)
– easy to use?
– appropriate for the task it was designed for?
5. Evaluaiton may lead to
» update of hardware
» update of software

b. New hardware may be required because of:

- Availability of advanced technology
- Change in user requirements.
- Certain hardware parts may no longer be serviceable, making maintenance
difficult.
c. Software update may be required because of:
- End user feedback
- Change in processes
- Change in legislation
a. range validation (Check if the number is between 1 and 100); type validation
(Number alone should be input)
b. Normal test data falls within the range of validation routine. Extreme data is at the
limits of validity. Abnormal data is outside the limits of validity.
Normal Extreme Abnormal
5; 65 0; 100 Test, @123

Live data is data with known outcome. Live data is entered into the new system and the
results compared with those produced from the existing system. If the two outcomes do
not match, then further modifications to the system may be needed.

a. 1. In the past twenty years, hardware advancements have necessitated upgrade of

software.
2. Old system may be outdated.
3. User requirements may have changed.
b. 1. Observation – Possible to get a better overview of the system and inexpensive
2. Questionnaire – Can be extensive; one can answer it in their own time.
3. Interview – interviewer can ask supplementary questions
c. 1. Direct – To replace the old system that wasn’t up to par.
2. Pilot – To test the viability of the software with a limited test subjects and
immediately roll out to larger audience upon success.
 Workbook

Method 1. Interview – This method involves analyst interviewing different

stakeholders. Analyst holds one-to-one sessions with stakeholders (clients, staff, users).
It helps the analyst get a clearer picture of the current system from different points of
view.
Advantage – An interview may have open ended questions. It also allows the analyst to
build a relationship with the interviewee and gather honest opinions/information.
Disadvantage – It is a time consuming, expensive exercise dependent on the availability
of the interviewees.
Method 2. Looking at existing documents – In this method, the analyst looks at the
existing documentation of the current system, it’s workings, data etc. to get a clear
picture of the current system’s workings.
Advantage – Analyst can find how the current system works on his own.
Disadvantage – It is time consuming and expensive.

Method 3. Observation – In this method, the analyst observes the staff/users in real
time to understand the processes of the current system.
Advantage – Analyst can obtain reliable data.
Disadvantage – It can trigger Hawthorne effect; people may be uncomfortable knowing
that they are being observed.
Method 4. Questionnaire – This method involves distributing questionnaires to
staff/users to fill out.
Advantage – It can be as extensive as required. Analyst can get set answers to questions.
Disadvantage – Respondents may not fill out the questionnaires and analyst may have to
keep reminding them over and over again.

P-178
» make it clear to the person filling in the form where they must place their answers
 » make use of text boxes which will limit the amount of information collected
» make use of character boxes for data such as surnames, telephone numbers, and so on (each box
allows one character only)
» make use of printed text boxes to allow for easy input of items such as date of birth
» make use of tick boxes to make choices easier (such as sex – male or female)
» make sure there is sufficient space to write answers
» make use of clear fonts and clear text colours to ensure the form is easy to read.

P-179
» use of text boxes to capture key data clearly
» use of on-screen help when completing the form
» use of drop-down/combo boxes where there are limited choices
» use of radio buttons and tick boxes requiring a single click of a mouse to select
» automatic validation of data as it is entered
» control buttons (such as next form, clear entry, save, etc.)
» double entry boxes (with verification rules) to check correctness of key data (for example, when
keying in an email address).

Method1: Phase changeover

Method2: Direct changeover
Method3: Pilot changeover
6b
P-175
» field name (for example, product_code)
» field length (what is the maximum number of characters that need to be stored)
» data type (see below)
» is any code being used (in this example, the codes T, A and B are being used – coding saves space
in the file because only a single character is being used; this also speeds up entry and also reduces
errors)
» the primary key field here will be product_code because it is unique.

Validation routines, input forms and layout, output forms and layout