Analysis is all about looking at how a job is done at present and

seeing if the job could be done better or more efficiently by

upgrading or developing a new system.
With this goal in mind, the Systems Analyst will:
• observe staff at work
• interview staff about their work
• send out questionnaires about working
practices
• inspect documents such as User guides, data
capture forms and any printouts that the
current system creates

Feasibility study
Having investigated the present system, the
Systems Analyst will produce a feasibility study.
This will look at whether the new system is:
• Technically feasible - is the new system
technically possible to implement in the time
available?
• Economically viable - will the cost of the new
system be offset by savings once it is
implemented, i.e. will it save the organization
time, money or increase its performance?
The project will only continue to the next stage if the
answer to both of these questions is yes.
At this point the decision makers in the
organization, e.g. the board of directors, decide
whether or not to go ahead
The next step is to draw up a requirements specification that
outlines exactly what the new system will do. For example, it will
mention:
• what hardware is needed
• what software is needed
• what inputs are needed
• what processing must take place
• what information needs to be output
Development is all about creating a new system that is works well
and is error-free

The stages of Development are divided into 4 parts:

• Creating a file structure to store data
• Creating validation rules to make sure data is entered
sensible
• Creating a User-Interface to allow data to be entered
into the system
• Creating output formats (Reports, Payslips, Bills, etc.)
Most systems are required to store lots of data.
File Structures allow this data to be stored in an organized way.
Test data is entered to make sure data is being stored correctly
The data entry form
makes use of Forms
controls appropriately
On screen outputs may have features not included in printed outputs like:
Hyperlinks, Animations, Sound, Video
Printed outputs are limited to text, images, colours and charts
Once the system has been created, it needs to be thoroughly tested.
A test plan is usually written whilst the system is being developed. The
test plan contains details of every single thing that needs to be tested,
eg:
• Does the system open and close properly?
• Can data be entered?
• Can data be saved?
• Can reports be printed?
• When you do something wrong, does an error message appear?
• Is invalid data rejected? E.g. if you are not allowed to enter an
amount above £1,000 on the system, then a value of 1,001 should
not be accepted (i.e. does the validation work?)

Test plans are very detailed with the type of test data used and what is
expected to happen
When choosing what data to use to test a system, you need to think
about why we are testing the system: to see if it works, and to
check it doesn't break.
To do this, we use three types of test data...
Normal Data Values
This is data that would normally be entered into the system and the
system should accept it, process it, and then check the results that are
output to make sure they are correct.
E.g. In a system that was designed to accept and process test marks
(percentages), then normal test values would include:
- 10
- 25
- 63
- 89
Extreme Data Values
Extreme values are still normal data.
However, the values are chosen to be at the absolute limits of the normal range.
Extreme values are used in testing to make sure that all normal values will be
accepted and processed correctly.
E.g. In a system that was designed to accept and process test marks
(percentages), then extreme test values would be:
- 0 (lowest possible value)
- 100 (highest possible value)
In systems that deal with text, the extreme values are defined by how long the text
can be. The limits would be:
- "" (nothing entered)
- "ABCDEF..." (max. length)
Abnormal Data Values
This is data that should not normally be accepted by the system - the values are
invalid.
The system should reject any abnormal values.
Abnormal values are used in testing to make sure that invalid data does
not break the system.
E.g. In a system that was designed to accept and process test marks
(percentages), then abnormal test values would include
- 101
- 200
When is the System Tested?
Testing is normally done in two stages...

The first phase of testing is done by the designers and engineers who created
the system, usually before the system is delivered to the customer.
The test data that is used in this first phase is similar to data that would be used
by the actual customer.

The second phase of testing is done after the system has been delivered and
installed with the customer. The data used in the second phase is usually 'live'
data - data that is actually part of the customer's business / organization.
These two phases of testing are often referred to as Alpha Testing (testing by the
designers/engineers) and Beta Testing (testing by real users, with real data)

What Happens if the System Fails Some Tests?

The whole point of testing is to try and find areas that don't work as they should,
or areas that can be improved.
If any failures are found, the systems analyst goes back and does some
further research, analysis and design to fix these areas.