Useful presentation

1. Systems Analysis and Design
Lecturer: Albert Osei

2. PARIS MODEL

3. PHASE I
Planning the approach
One of the main causes of project failure is
inadequate understanding of the requirements
one of the main causes of inadequate
understanding of the requirements is poor
planning of system analysis.

4. Cont…
The first step taken by the systems analyst
should be to plan the approach carefully,
bearing in mind the old saying that
‘failure to prepare is to
prepare to fail!’

5. Cont..
Before requirement gathering starts, the
analyst needs to stand back, recall the
objectives of the project, and consider the
following three points in order to plan;
What type of information is required?
What are the constraints on the investigation?
What are the potential problems?

6. CASE Study
Let’s consider an example: You work for a Company
based in UK. Your company has just won the following
contract with Nestle Gh. Limited. The contract covers:
– Analysis of Nestle’s current warehousing, stock control and
manufacturing systems and the integration of these systems;
– an investigation of Nestle’s current problems and of future
strategic plans in this area;
– production of a report outlining your company’s proposals for
meeting Nestle’s future systems requirements in warehousing,
stock control and manufacturing systems.

7. Cont..
Nestle is an international company and has
presence all over the world.
The company has four manufacturing sites at
Accra, Kumasi, Takoradi and Tamale. There are
warehouses at each manufacturing site;
Against this background think about how you
would plan this investigation.

8. It will be good to think about the:
The critical information you require before the
investigation starts;
HOW you will get that information;
WHAT techniques will be appropriate;
What are the constraint- to the project and the
company.

9. Planning is the answer….

10. Planning
As part of the planning process, analysts must
ensure that:
– He understand the objectives and terms of reference
agreed with the client;
– He must be aware of constraints that affect the
analysis process;
– they plan the research, initial contact and other tasks
to be completed during
– the investigation and manage time appropriately

11. Objectives &
Terms of Reference
To understand more about the client’s
expectations, you need to ask a number of
key questions at the beginning of the
analysis phase of the project:
– Who initiated the project?
– What is their role in the organisation?
– What are their objectives for the project?
– What are the company objectives

12. Cont..
Once you know the answers to these
questions, you can begin to understand
the context in which the analysis is to be
carried out.

13. Projects are usually initiated to meet
organisational need:
– Senior management: strategic planning and
decision making
– Line managers: system to support their activities
– The IT dept: cost-efficiency, new technologies or
method of working

14. Whatever the case might be, management of
organisation expect to benefit, e.g:
increased profitability;
improved cash flow;
more effective utilisation of resources,
improved customer service leading to customer
satisfaction.
faster access to management information;
better management control

15. Analyst will be in good position to address
management’s problems if they are able to
prioritized the OBJECTIVE. To help in;
Planning the analysis phase
Writing proposal after the analysis

16. The stated objectives of the client are
usually recorded in the terms of reference.
main areas included in the terms of
reference.
System boundaries-(Scope)
Constraints
Objectives
Permissions
Deliverables

17. System Boundaries
System boundary define the area of the
organisation under investigation and may
also specify the limit of any new system
Implemented as a result of the project.
Should be a paragraph or a series of dot
points, describing where the
process/system/operation/issue to be
studied begins and ends

18. Constraints
Restrict the project, or the solution, in many
ways. May be expressed in terms of;
Fig 1.0: Constraints on possible solution

19. Objectives
An unambiguous statement of the
expectations of those in the client’s
organisation who have initiated the
project. These may be broken down by
function or department.
Well-defined objectives are clear and
measurable.

20. Permission
This will indicate who in the client’s
organisation is responsible for the
supervision of the project.
and, if permission needs to be granted –
for example to extend the scope of the
analysis – who has the authority to do so.
Points of contact and the appropriate
reporting structure may also be defined.

21. Deliverable
A description of the deliverable or end
products of the investigation.
Usually they fall into making
recommendation for:
– solving a problem;
– improving a process or a system;
– making a change;
– creating a new system

22. USES OF TR
Planning
Reference point for the project
Resolving conflicts that may arise
Thus;
Must exist, if none exist, create it and
agree with the client

23. Constraints
After understanding the TR and the Objective
It’s important that all constraints are understood
in order to help with planning and to avoid
problems
Constraints may be set by the customer to limit
the options that may be presented as part of the
system proposals.
They may be expressed in the TR

24. They may be expressed in terms
of;
– Technology: software or
hardware
– Environment: skilled or unskilled
users, place of use..
– Timescale: delivery time base
on customer/gov policy
– Budget: cash available for the
purchase of hardware or
software, limitations on the
operation budget
– Scope: area under investigation,
system boundary
Fig 1.1: Constraints on possible solution

25. Other constraints are:
.
Fig 1.2: Constraints on investigation -
help in selecting the right fact-finding approach

26. Getting Ready
for Detailed Analysis
In order for analysts to be well prepared for the later
stages of systems analysis, and to increase their
credibility in interviews with client staff and
stakeholders more time needs to be spent on research
during the planning stage
This means:
Understanding the TR
Reviewing relevant documents
– Contract documents
– Annual reports
– Organisation structures
Identify the types of information you will need to collect during your
investigation
The areas to be investigated

27. Following are examples of topics that the analyst may wish to investigate:
Growth
– What plans does the organisation have for future growth,
– what would be the information requirements to support this growth
Functionality.
– What are the major areas of the business
– the functions – that will be investigated during the system,
– and what are the client’s requirements for the functionality of the system?
Procedures.
– What procedures, standards and guidelines govern the way in which the
organisation conducts its business
– are they recorded somewhere

28. Volumes.
– What are the volumes of data that pass through the system?
how many orders are processed by the sales department in a week?
How many amendments are made to customer records each month?
Fluctuations.
– What bottlenecks or hold-ups are there in the system,
– Where and when do these occur in the current system?
– What steps are taken to deal with these?
Information required.
– What information is currently required by the business in order to carry out its
functions effectively,
– what are the sources of this information?
– What information, if available, will it benefits the organisation?
Environment.
– In what type of environment is the business conducted
– how does this affect the way in which information is exchanged?
Problems.
– In the view of users, what are the main problems with the system,
– what are the implications of these problems,
– how can the problems be overcome?

29. In planning the approach to analysis, an
important area to consider is the:
– First face-to-face contact with the client.

30. Why Face-to-face
Contact
To gather requirements
To build a good relationship with the client
To establish the analyst’s credibility

31. Face-to-face
Meeting Ethics
In all meetings with users, the following guidelines
represent good practice:
– Focus on confidentiality, integrity, respect and confidence-
building.
– Recognise expertise in the users and welcome their input.
– Have as a key objective the need to build the client’s
confidence.
– Keep everybody informed. This includes client contacts and
project staff.
– Be discreet and diplomatic.
– Double-check any information gathered.

32. There are many tasks to complete during
systems analysis however there are
limited time;
Time management is one of the factors to
be taken into consideration
It should be budgeted for, managed and
used

33. To help you manage your time as effectively
as possible, here are some guidelines:
– List objectives and set priorities.
– Make a daily ‘to do’ list
– Handle paper only once.
– Set and keep deadlines
– Ask yourself frequently ‘What’s the best use of my time right now?’
– Always carry a notebook
– Do it now (The right time is now..).

34. The Feasibility Study
The objectives of a feasibility study are to find out if the project
can be done (...is it possible?...is it justified?) and to suggest
possible alternative solutions
A feasibility study should provide management with enough
information to decide:
– Whether the project can be done;
– Whether the final product will benefit its intended users;
– What are the alternatives among which a solution will be chosen (during
subsequent phases)?
– Is there a preferred alternative?
After a feasibility study, management makes a go/no-go
decision.

35. Thus, analyst should concentrate on
providing answers to four key questions:
– How much - The cost of the new system.
– What - The objectives of the new system.
– When - The delivery timescale.
– How - The means and procedures used to
produce the new system.

36. What to study
Things to be studied during the feasibility study phase:
The present organizational system
– users, policies, functions, objectives,...
Problems with the present system –
– inconsistencies, inadequacies in functionality, performance,...,
Objectives and other requirements for the new system
– What needs to change?
Constraints, including non-functional requirements on the system
– preliminary pass
Possible alternatives
– the current system is always one of those
Advantages and disadvantages of the alternatives
Things to conclude: Feasibility of the project and the preferred alternative.

37. Types of Feasibility
Operational
– Define the urgency of the problem and the acceptability of any solution; If the
system is developed, will it be used? Includes people-oriented and social issues:
internal issues, such as manpower problems, labour objections, manager
resistance, organizational conflicts and policies; also external issues, including
social acceptability, legal aspects and government regulations.
Technical
– Is the project feasibility within the limits of current technology? Does the
technology exist at all? Is it available within given resource constraints (i.e.,
budget, schedule,...)
Economic (Cost/Benefits Analysis)
– Is the project possible, given resource constraints? Are the benefits that will
accrue from the new system worth the costs? What are the savings that will
result from the system, including tangible and intangible ones? What are the
development and operational costs?
Schedule
– Constraints on the project schedule and whether they could be reasonably met.

38. Operational Feasibility:
The PIECES Framework
The PIECES framework can help in identifying operational problems to be
solved, and their urgency:
Performance - Does current mode of operation provide adequate
throughput and response time?
Information - Does current mode provide end users and managers
with timely, ‘to the point’, accurate and usefully formatted information?
Economy- Does current mode of operation provide cost-effective
information services to the business? Could there be a reduction in costs
and/or an increase in benefits?
Control - Does current mode of operation offer effective controls to
protect against fraud and to guarantee accuracy and security of data and
information?
Efficiency- Does current mode of operation make maximum use of
available resources, including people, time, flow of forms,...
Services- Does current mode of operation provide reliable service? Is it
flexible and expandable?

39. How do end-users and managers feel about the problem
(solution)?
It's not only important to evaluate whether a system can work
but also evaluate whether a system will work.
A workable solution might fail because of end user or
management resistance.
– Does management support the project?
– How do the end users feel about their role in the new system?
– What end users or managers may resist or not use the system?
People tend to resist change. Can this problem be overcome?
If so, how?
– How will the working environment of the end users change?
– Can or will end users and management adapt to the change

40. Technical Feasibility
Is the proposed technology or solution
practical?
Do we currently possess the necessary
technology?
Do we possess the necessary technical
expertise, and is the schedule reasonable?
Is relevant technology mature enough to be
easily applied to our problem?
– Some firms like to use state-of-the-art
technology, but most firms prefer to use mature
and proven technology.

41. – A mature technology has a larger customer base
for obtaining advice concerning problems and
improvements.
Assuming that required technology is
practical, is it available in the information
systems shop? If the technology is available,
does it have the capacity to handle the
solution.
If the technology is not available, can it be
acquired?

42. Schedule Feasibility
We may have the technology, but that doesn't mean we
have the skills required to properly apply that technology.
True, all information systems professionals can learn new
technologies. However, that learning curve will impact the
technical feasibility of the project; specifically, it will
impact the schedule.
Given our technical expertise, are the project deadlines
reasonable? Some projects are initiated with specific
deadlines. You need to determine whether the deadlines
are mandatory or desirable. If the deadlines are
desirable rather than mandatory, the analyst can propose
alternative schedules.
It is preferable (unless the deadline is absolutely
mandatory) to deliver a properly functioning system two
months late than to deliver an error-prone, useless
information system on time!
Missed schedules are bad, but inadequate systems are
worse!

43. Economic Feasibility
The bottom line in many projects is economic
feasibility.
During the early phases of the project, economic
feasibility analysis amounts to little more than
judging whether the possible benefits of solving
the problem are worthwhile.
As soon as specific requirements and solutions
have been identified, the analyst can weigh the
costs and benefits of each alternative.
This is called a cost-benefit analysis.

44. Cost/Benefit Analysis
The purpose of a cost/benefit analysis is to answer
questions such as:
– Is the project justified (because benefits outweigh costs)?
– Can the project be done, within given cost constraints?
– What is the minimal cost to attain a certain system?
– What is the preferred alternative, among candidate solutions?
Examples of things to consider:
– Hardware/software selection
– How to convince management to develop the new system
– Selection among alternative financing arrangements
(rent/lease/purchase)
Difficulties - discovering and assessing benefits and
costs; they
– can both be intangible, hidden and/or hard to estimate, it's also
– hard to rank multi-criteria alternatives

45. Feasibility study report
A report is written after the study
The content should include:
Fig 1.3: Feasibility study report content

46. Background
Terms of reference.
Reasons for the study
This section will outline the background to
the project and the way it relates to the
stated objectives of the organisation.

47. The current situation
Overview of current situation.
Problems and requirements identified.

48. Proposed solution
A description of the requirements of a new system along with
a number of options explaining how this solution might be
implemented. Each option will address:
Technical implications
– how it meets the requirements, the hardware and software needed.
Operational implications
– the impact the solution will have on the business in terms of human,
organisational and political aspects.
Cost implications
– both initial (capital) and continuing (operational). There are a number of
methods of assessing the costs of solutions. In the feasibility report, the
analyst should use the cost assessment method specified by the client.

49. Cost–benefits analysis
A comparison of costs and benefits
prepared using whatever evaluation
technique is favoured by the organisation.

50. Recommendations
A brief statement that presents the main points of the
previous sections of the report.
3 types of recommendation can be made in a
feasibility report:
– Advising the client to progress with the full detailed
analysis. If this is the case, a plan would also be included
for this phase of the project.
– Advising the client to review the terms of reference or the
scope of the study before proceeding further or making any
judgement on feasibility.
– Advising the client to scrap the project as it is not feasible;
the resources could be better spent elsewhere.

51. Once the feasibility report has been
delivered
Assuming that the recommendation made
by the analyst is to proceed, the detailed
systems analysis phase can begin

52. To start the investigation the following
needs to be done;
– collect information about the current system
– record the problems & requirements
– building up a picture of the required system
Next…
Asking Questions & Collecting Data