The Systems Life Cycle
The Systems Life Cycle
The Systems Life Cycle
7.1 Analysis
7.1.1 Analyse the Current System
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?
Fields
Common Data types
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.
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.
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
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
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.
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).
Validation routines, input forms and layout, output forms and layout