SDLC Step 1: Problem Analysis

Before you start trying to solve a problem it's important to study the existing system before embarking on major changes.

Consider the Analysis phase like a visit to the doctor. You would be pretty worried if you told the doctor you had a headache and the doctor immediately started merrily injecting you with various things before even looking at you or asking you any questions. Such behaviour is likely to cause more problems than it solves, so doctors always analyse their patients - observing, questioning, testing - before beginning any treatment.

So also do problem solvers study the system they intend to change, and the organisation it's in, before they decide what needs to be done. By thoroughly understanding a system, its operation, its context, its strengths and weaknesses, one can better decide how to start improving it.

Why should the information system be changed?

Possible reasons for change:

• new laws that force organisations to do new things, or do old things differently
• changes in society, such as growing demand for better security over personal data
• a desire to improve competitiveness in the fact of reducing profits and market share
• changes in technology - e.g. a new operating system may force upgrades to computers
• a need to increase productivity, quality or efficiency
• concern that existing equipment is a health and safety menace
• changes in work processes, expansion of the business, changes in business requirements or the environment in which the organisation operates may all lead to a reassessment of information system requirements.
• ghe current system may be too inflexible or expensive to maintain, or may reduce the organisation's ability to respond quickly enough to customer's demands.

Reasons for change can come from within the organisation or from outside it .

Factors can be technological, economic, social, legal or political.

Changing something just for the sake of change is an expensive - and potentially destructive - hobby. There had better be a good reason for changing systems. Many good reasons stem from a desire to better achieve organisational goals, while some other reasons are imposed on the organisation from the outside and are beyond the organisation's control.

If there is no compelling reason to take action, why waste time, effort and money? The preliminary investigation should mount a case to answer these questions: 

Questions that need to be asked during analysis

There's not much good getting heavily into a project if the whole thing is a silly idea to start with. The preliminary investigation is an early test of whether the project should even be started.

Is there really a problem?

Imagine a manager thinking his organisation was losing sales because customers could not shop online. He spends thousands of dollars and hundreds of man-hours to implement an online shopping system. After it's launched, no-one actually uses it because they were happy with the old system. A waste of time and money.

If there is a problem, is it worth fixing?

Assuming a valid problem has been identified, you must consider a "cost/benefit" analysis. In other words: is fixing the problem worth it?

A manager decides the company logo and letterhead looks old fashioned. He spends thousands on graphic design consultants, market research, psychological testing of consumer reactions; he recalls and destroys all existing stationery and company publications and reprints them with the new logo and letterheads; he has signwriters repaint all company vehicles and buildings. It cost millions, and it simply not worth it.

Determining whether a problem is worth fixing involves a feasibility study. The aim of the feasibility study is to understand the problem and to determine whether it is worth proceeding. There are five main factors to be considered:

• Technical feasibility - investigating whether the technology exists to implement the proposed system, or whether this is a practical proposition.
• Economic feasibility - has to do with establishing the cost-effectiveness of the proposed system - if the benefits do not outweigh the costs, then it is not worth going ahead.
• Legal feasibility - determines whether there is any conflict between the proposed system and legal requirements - for example, will the system contravene the Information Privacy Act?
• Operational feasibility - Operational feasibility is concerned with whether the current work practices and procedures are adequate to support the new system. It is also concerned with social factors - how the organisational change will affect the working lives of those affected by the system.
• Schedule feasibility - looks at how long the system will take to develop, or whether it can be done in a desired time-frame.

To answer these questions, data has to be collected about the system. You might need to:

• measure things, like how long different processes take, how much output is produced in a given time, how many staff are required.
• count things, like the numbers of errors or system failures in an existing system.
• survey or interview workers, management, customers, and corporate partners to discover what these people know about the system's requirements, strengths or weaknesses from their specialist perspectives
• observe processes in action to see where problems lie and improvements can be made in work-flow, and consider how procedures should be changed to accommodate the new or changed system. If processes take place outside your organisation, be sure to include them too - you never know: the problem might not be in your organisation at all!
• research similar systems elsewhere to see how similar problems have been addressed
• test the existing system to determine whether suspected points of weakness are real or imagined
• study the workers in the organisation and list the types of information the system needs to produce for each type of worker

Such operations often create more questions that also need to be answered. Analysis often turns up issues that need to be investigated with further analysis. By the time you are finished analysing the problem, you should have a clear idea of:

• the context of the problem - how the system fits into its surroundings, which includes people (in your organisation and perhaps in other organisations) and other systems which interact with the system. You need to understand how input, processing and output data are managed in the organisation - including data and information destinations. An IPO chart and workflow diagram would be good to document these relationships.
• the processes - you need to know how data is transformed into information. What tasks are performed? A top-down approach makes sense: identify major processes, and keep subdividing them up into smaller processes until individual tasks are listed.

When an existing system is well understood, and the needs of the new or changed system have been defined, a design for the solution is not far away.

Formulating the Problem

It's all too easy to solve the wrong problem, or find that your eventual solution does not solve the problem fully, if at all. It all depends on how you approach and define the problem.

It's very tempting to make assumptions about the cause of the problem before you solve it: and if your assumptions are wrong, everything you do after that may well be a waste of time.

A Case Study Example of dodgy problem formulation

The scope of a problem .Problems can be formulated narrowly or broadly (or anywhere between the two).

Problem analysis breaks the problem down into its parts and describes them. Note that this step does not care what solution will be used to solve the problem. The analysis lays down the basic requirements that the eventual solution must achieve (a logical design).

Analysis does not try to describe HOW the solution will work. (That is done in the design phase)

A problem analysis will describe:

• required input (what data has to be acquired to produce the output?)
• required output (i.e. what information is the system supposed to produce?)

Data and information should be described in detail. These will include:

• data types (e.g. number, text, image etc)
• data structures (e.g. field names, field sizes, database table names, valid data ranges)
• storage (e.g. file names and locations such as hard disks, removeable media, tape)
• what processing is required to convert the input into the required output?
• constraints that must be put on the solution (e.g. operating system that is used, hardware power, minimum speed required, maximum cost allowable, necessary quality of the finished product, maximum capacity expected of the solution, how easy-to-use the solution has to be considering the skill levels of the staff who will be using it) storage requirements
  
• It is also necessary to decide what strategy will be best to manage the solution: top-down or bottom-up.
• You end up with a logical design that describes what the current system does, and what the new system needs to be able to do, but does not specify how it's done.

All the findings of the analysis stage need to be documented using appropriate logical design tools (not to be confused with physical design tools which provide details of how system components will be built).

Examples of logical design tools are: Context Diagrams, Hierarchy Charts, Org charts.

These are discussed in the next section, Design.