System development Lifecycle


Problem Definition (1.2.b)

The systems analyst and the client must establish the problem to be solved. The client is an expert in the problem, which the systems analyst in an expert in what is possible. This is important because if a problem is not defined precisely and accurately, then the system that is developed may not solve the problem, or the client may be charged for developing extra features they do not want or need.

Feasibility Study (1.2.c)

The systems analyst needs to decide whether it is possible to solve the problem, using a system known as "TELOS":

  • Technology: Is the technology available to solve the problem?
  • Economy: Is the solution economically possible? Will the solution be economic to run? Will the solution improve profits?
  • Legal: Is the solution within the law? For example, does it comply with the Data Protection Act?
  • Operations: Is the solution operationally possible? Does the proposed system actually solve the problem? What will the effect on the customer be - does the problem really exist?
  • Schedule: Can the solution be delivered within the time specified by the client?

Information Collection (1.2.d)                

Interviews: a small number of important people can be asked about the problems. Interviews are generally slow but it allows the analyst to ask more questions if something unplanned arises.

  • Questionnaires: these allow the analyst to ask opinions of a large number of people quickly. However, questionnaires are very restrictive because the questions must be planned in advance.
  • Meetings: meetings strike a balance between the speed in questionnaires, and the flexibility of interviews. They allow a large number of people to have their opinions taken quickly. However, a few powerful individuals can control the meeting, and make the result biased.
  • Observation: observation is possibly the most accurate form of information collection, but it is also the most time consuming. The analyst simply observes use of the current system, making notes about what the current solution does well, and what needs improving.
  • Documentation: the analyst collects all available documentation and studies it carefully. This will show how the system collects, processes, and presents data and information.

Analysis (1.2.e)

After all the information is collected, it needs to be analysed to decide what is relevant to the problem. The analyst will use both data flow diagrams and system flow charts to try and understand the current system. This allows the analyst to produce a requirements specification, which is a list of tasks the solution should complete. It is important to make sure that the client agrees with all the decisions made at this stage, because the outcomes will be used to decide whether the proposed solution satisfies the problem, and ultimately whether or not the analyst gets paid.

Design (1.2.f)

The analyst draws up a design specification. This includes key concepts and relationships between various parts of the proposed solution. Another data flow diagram and system flow chart will be drawn. These allow the analyst to work out the way that the data will


No comments have yet been made