Compiled by: Raed Gharzeddine

System life cycle

A new system following the waterfall method of software development
evolves through a life cycle:
1) Requirements are specified by the client and recorded by the analyst
2) A designer will then follow a requirements specification in order to
produce a design which will show the client what the new system
will look like
3) When the client is happy with the design specification, the system
will be developed based upon the design specification
4) The developed system will then be tested before being installed for
the client
5) The client will be provided with user documentation
6) An evaluation will take place to review the system life cycle of the
project
7) Any ongoing maintenance will be handled by the maintenance
team.
Compiled by: Raed Gharzeddine

Stage 1: Analysis
Analysis involves finding out how the current system works and what the
client’s requirements for the new system are.
Data needs to be collected about the current system and research must
be done about the requirements of the new system. This step can be in a
variety of methods:

Questionnaires
Questionnaires are used when information is required from many users,
and it is impractical to interview them all at once.
▪ Many users also means that there is a large sample size for the
results of the questionnaire to be quantified and compared
▪ They are not suitable when there are only a small number of users
involved because there is not a large enough sample size to
evaluate opinions and it would be quicker to conduct interviews
than spend time preparing questionnaires. However, this may be
exempted if it's impossible to arrange an appointment with the
users
Questions need to be asked in a way in which the required information
can be extracted from the users, but also so that responses can be
analysed collectively.
A good way to do this is providing multiple choice responses so that each
response can be counted.
It's also important that:
▪ The questionnaire does not take too long for users to complete
▪ Questions are written in a way that does not threaten users and the
way they currently work
▪ Users should be given the opportunity to return their
questionnaires anonymously because that means more honest
answers are likely to be recorded
Compiled by: Raed Gharzeddine

▪ The questionnaires should be completed online. This means that

results are immediately stored and readily available for detailed
analysis in the form of graphs and tables. Also, filters can be
applied to the results and responses can be compared based on the
answers given to another question.
Quantitative questions will be extracted using the multiple-choice
questions.
Qualitative questions will be extracted using open questions can be asked
(the user is able to suggest alternative ideas to those presented in the
questionnaire).

Interviews
An interview involves a direct conversation between the analyst and the
client.
Interviews are useful when there is a single end user or a small group of
end users.
▪ Questions can be asked of the users on the conversation can take
place which can expand upon answers that are given
▪ Questions to be asked during interviews should be planned and
designed to extract the required information from the client
▪ The questions will vary depending on who is being interviewed
▪ Interviews can take place with groups of users or focus groups that
represent user groups or customers
▪ Honesty is important during interviews so that the analyst can get
an accurate picture of how tasks are completed. This can sometimes
be difficult to achieve because end users may not want to admit to
taking shortcuts in their tasks or not carrying out tasks to the best
of their ability
The logistics of each interview also needs to be planned as sometimes it
can be difficult to find a time when both the analysts on the client are
available especially during a busy schedule.
Compiled by: Raed Gharzeddine

Observation
Observation involves the analyst watching the processes that take place
within an organisation to find out how tasks are being completed.
This can involve:
▪ This can involve sitting with users to understand the tasks they have
to complete, with an opportunity to ask questions of the users to
extract further information that could be needed for a requirements
specification.
What a user
▪ Wandering around the office.
needs the new
system to do.

Disadvantage: when users are being observed they may do things

differently from normal or there they may be more efficient and so this
does not give the analyst a true picture of what is happening.

Document analysis
This is when the analyst can use existing documents within an
organisation to know about the information that is currently being used:
▪ The analyst will need to see examples of any documents that show
output information or give an indication of what data is being
collected for input to a system
▪ The analyst can sometimes also identify processes that take place
by looking at the documents
▪ It's possible to estimate the amount of data that is likely to be
required if the volume of documents is known
This method is not to be used on its own, but rather in conjunction with
other analysis methods, because it is difficult to identify the processes
just by looking at documents.
Compiled by: Raed Gharzeddine

Also, this method only shows data that's currently output and doesn't
give the analyst an opportunity to find out what additional data an
organisation might need, or what data the organisation does not need.

The content of specifications

1) Requirements specification
This is a contract between the developer and the client. It will specify
exactly what the client needs the system to do, so that the developer can
produce a system that meets the client’s needs.
The analyst will usually write the requirements specification in
consultation with the client who will approve it.
A requirements specification should include:
▪ The purpose of the system
▪ The main objective of the system
▪ The data that must be output from the system (invoices, sales,
reports)
▪ The data that needs to be input in order to generate an output
▪ Validation and verification of input data
▪ Processes that need to take place to convert inputs to outputs
▪ Data that needs to be stored
▪ Functional requirements
▪ Deadlines for each milestone with the project

2) System specifications
This is a list of all software and hardware that is needed for the new
software.
It is crucial that:
▪ The software is identified first (as the hardware will depend upon
the software)
Compiled by: Raed Gharzeddine

▪ Only software that is needed to run the system should be specified

▪ Once the software is known, the minimum hardware required to run
that software should be identified
▪ The analyst should consider how much storage space is going to be
required for the data being used by the system. The analyst will also
probably recommend higher than minimum specs so that the
system functions at a reasonable speed
Specifications include: processing power, amount of memory, and
external hardware components (based upon the requirements of the
user).

3) Design specifications
The design specification is produced by the designer and is an illustration
of how the system will look, what the data structures will be, and how
the system will work.
It is intended to give the user an idea of what the system will look like
before it is developed so that the user’s feedback can be incorporated
into the final designs.

Stage 3: Development and testing

The development stage is the where the design is implemented.

Test data
When a system must be developed, it needs to be tested. In order to do
that, data will be created purely for the use of testing.
• test data is a simulation of live data
• there must be several types of test data that test different scenarios
within the software, including validation rules and queries
Type of test data Description
Valid Data that is accepted by the
Compiled by: Raed Gharzeddine

validation rule
Invalid Data that is not accepted by the
validation rule
Extreme Data that is at the limits of
acceptability; therefore, it is
accepted by the validation rule

The system will also need to be tested to see how it works under normal
conditions using live data.
• Live data: is the actual data being used by the system once it has
been implemented; it is a simulation of a live system to take place
Testing with the live data will be carried out by the end users in most
cases, where they will use the data as if they were doing their normal
jobs, simulating different processes that they would carry out.

Alpha and beta testing

Alpha testing is carried out by a team of developers or a specialised team
of testers before an application is delivered to the user.
• It takes place close to the end of the development stage where the
system is almost ready for the user
• It may take a long time because each time an error is found, the
testing process must be repeated when the error has been
corrected, and there may be a domino effect on other parts of the
system
• The testing is planned and structured using test data to follow all
pathways through the software
Beta testing is used when the software is being made available to many
customers. Beta testers will be real customers who have been selected to
test an early release of the application.
• It only takes place once alpha testing has been completed
Compiled by: Raed Gharzeddine

• Involves customers using the software in a real-world environment

using real data
• As bugs are found within a beta version, new beta versions will be
released for further testing before finalizing everything

Black box and white box testing

Black box testing involves selecting input data and checking that the
expected output data matches the actual output data, with no knowledge
or understanding of what happens inside the black box.
• Usually involves testing the whole system (by a team of specialised
testers) or user testing (end users)
• Focuses on ensuring that the requirements specification has been
met

White box testing involves the same process of input and output data,
but the internal structure and logic of the system is known to the tester.
• Carried out with small program modules
They will do this to check that each module is working as intended.
• Carried out by the software developers who coded the program
Therefore, they can test pathways that the black box tester does not
know about.
• Testing will be focused on whether detail designs, such as
validations, have been developed correctly
White box Black box
Needs access to a detailed Does not require knowledge of how
specification the system was developed
Each module can be tested in depth Only a limited number of test
scenarios are performed (due to
having no knowledge about how
the system was developed)
Compiled by: Raed Gharzeddine

Test plans can be created for each Tests are difficult to design, as
calculation, navigation, and input many different input data options
must be considered with pathways
through the system
Tester can identify what type of Tester may not know what the
test data will be required boundaries or validations are
Skilled tester required (as an No skilled tester is required
understanding of code is needed)

Test plan and its importance

A test plan identifies:
1. What is being tested
2. The type of test
3. The input data used for the test
4. The expected result of the test
5. Space to record results
 Test plan
Compiled by: Raed Gharzeddine example

Testing is necessary because every system is prone to errors, and these

errors need to be identified and rectified. A test plan ensures that all
pathways of the system have been reviewed and tested. Without
planning, important parts of the system might be left out, and errors
might be undiscovered
• A test plan will identify all the tests that are needed for every input,
every button, every link, every report, every screen, and all other
elements of a system
• The test plan will include different types of test data including valid,
invalid, and extreme so that inputs are tested to their limits
• The plan will also cover all the user’s requirements and ensure that
they are tested
Test plans not only test inputs, but also calculations and buttons: