module 7 - system analysis and design

What is a system?

A computer system is a complete, fully functional computing device or network configured to perform specific tasks. It works through an input-process-output model, and considered as an entire organisation.

These include microcomputer systems, electronic systems, control systems or information systems.

Eg. In business and industry, computers are used to help control, model, inform, analyse and act upon all types of information from the shop floor (transaction level) to the boardroom (management level).

What is the role of a System Analyst?

The systems analyst is the person who is in charge of conducting and completing the systems analysis exercise. It is also the person responsible for all the stages involved in the production of software, having the primary responsibilities as a consultant, supporting expert, and agent of change.

What is the System Life Cycle?

A set of sequential rules forming a suitable starting point for the classical methods developed for software development.

What is The Generic Waterfall Method?

A set of linear and sequential stages to develop software, where you cannot revisit previous stages. It is ideal for complex systems development.

What are the steps of the System Life Cycle?

1. Problem Definition

2. Feasibility Study

3. Requirements Elicitation

4. Analysis

5. Design

6. Implementation

7. Testing

8. Maintenance

9. Retirement

1. Problem Definition:

Identifying the problem/s with the present system. A committee is usually set up to monitor the project progress and inform all users that a new system will be implemented or the current system will be improved.

2. Feasibility Study

A preliminary investigation is essential to determine whether a project is technically and economically feasible. Its purpose is to make an outline survey of the proposed system, where the feasibility report is used to provide management with the required information so that they will be in a position to draw proper conclusions.

3. Requirements Elicitation:

A fact-finding exercise on the present system to identify and define the system’s objectives, estimate a more detailed outline of the systems costs and identify the likely hardware and software constraints. This is done by establishing sources and types of information;

• interviews and questionnaires

• observing the working personnel and their experiences

• collecting necessary information and documentation;

  • records

  • files

  • reports and forms.

4. Analysis:

The systems requirements are determined in full detail to prepare the user and software specification requirements. This includes;

• identifying the main requirements

• identifying and defining the inputs, outputs and processing requirements

• describing the system using data flow diagrams and a commentary.

• specifying the hardware and software requirements

The report should gather a clearer picture for the system analyst, as well as;

• criticism of the existing system and improvements

• such findings of the analysis stage

• objectives of the proposed system

• a broad design specification

• sample outputs

• user responsibilities

• a detailed update of the costs, development plan, and timetable for introduction.

5. Design

Producing a detailed design of the proposed system, where the system analyst usually works backwords, from the outputs to produce the inputs, leading to a systems specification. This should provide a basis for agreement and source of reference for all staff, and a reference for the computer program specifications, dialogues and manual procedures within the system. The system should be described from the user’s point of view. A prototype (small working model of the system) is usually designed to assist the client.

Divided into four design tasks:

• Outputs: Consideration to what data is outputted, the output devises to be used and the output layouts (screen, hardcopy reports, forms, etc)

• Inputs: Implementing the input requirements, together with the data collection methods and the data validations of the input data and medium used

• Files: Determine the data structure and organisation based on the number of data files required and operations to be performed on the data. Includes the methods of backing up the data files for security reasons.

• Processing: Using any conventional tool (pseudocode, flowcharts), and the design of the algorithms should be modular (each processing task has its own separate algorithm). File processing includes basic facilities (insertions, deletions, amendment, searching, querying, and sorting), and must be efficient and quick.

The overall design must have a user-friendly interface, by using a menu-driven system (where the main menu calls other submenus), making it easier to maintain.

6. Implementation:

Developing the computer programs according to the algorithms by coding the system with a team of programmers. The individual program modules are tested using test data including 1) valid data, 2) invalid data and 3) data at the extremes, before tried out together to see if they work accurately and properly. An essential part of any computerised system is printed documentation:

• User Documentation: Enabling users of a new system to successfully run the system with minimum effort, lacking technical and computer terminology. It includes;

  • a full description of what the system does

  • instructions on loading the software from the secondary medium into main memory

  • details on the input and output of the data

  • using the software, and any restrictions which the program cannot handle.

• Technical Documentation: Containing specific, technical and detailed information about the new system, such as the hardware specifications for running the system, the files used and their structure, for future system analysts to modify the system.

• Program Documentation: Contains detailed information on the programs developed for the new system, such as the program description, the algorithms (flowcharts, pseudocode), program listings, test data used and their results, and possible future enhancements to programs for future programmers to revise and improve the programs.

7. Testing:

The testing of the software during and after implementation, by installing and testing the overall system and further debugging and testing until all functions as expected now follow. Staff training and evaluating user interaction with the new system, system performance and overall functionality with what had been planned also takes place during this phase. The most suitable changeover (straight, parallel, pilot or staggered) is taken to introduce the new system to all users. Types of testing include;

• Unit

• Module

• System

• Integration

• Acceptance

• Top-down Vs Bottom-up testing

• Black box Vs White box testing

8. Maintenance:

Making sure that the system continues to work correctly and detecting and correcting bugs that may come to light after extensive use in the field. Maintaining the system involves implementing changes to the system such that the system can cope with the changing requirements of the organisation, new software or hardware technologies, or disruptive technologies. Includes Evaluation maintenance and System maintenance; 1) Corrective, 2) Adaptive, 3) Perfective, 4) Predictive.

9. Retirement:

The useful life of the new system comes to an end, as the system life cycle is terminated and a new system life cycle is initiated, due to the changes to the system are too expensive to implement and it would be more economical to replace the system.

1. Identification of the Problem - What prompts an organisation to develop a new system?

There are various reasons why organisations want to develop a new system. These include:

• The current system may no longer be suitable for its purpose

• The organisation faces new business demands and requirements

• Technological developments - new hardware/software is required

• Current system may be expensive to maintain

• Current system cannot be upgraded and refactored

• New system is required to gain a competitive advantage

2. Feasibility Study - What is the purpose of the feasibility study?

To make an outline survey of the proposed system and present a report on the survey to top management.

The feasibility report is used to provide management with the required information to have the ability to draw proper conclusions and make informed decisions.

2. Feasibility Study - What aspects are considered in a feasibility study?

Some aspects of the feasibility study that must be considered are the answers to the following questions:

• Will the problem/s be solved by computerisation?

• Will the proposed system work?

• How will employees and customers be affected with the new system?

• Will the new system be cost effective, that is, will the benefits outweigh the development and running costs?

2. Feasibility Study - What is the most important aspect in a feasibility study?

The most important issue of carrying the feasibility study is to determine whether a project is feasible or not. The aspects considered in the feasibility study include:

• Technical

• Operational

• Timeliness

• Economic

• Legal

• Social

2. Feasibility Study - Technical:

Checks whether the new computerised solution is technically feasible; meaning is possible to be achieved in terms of programming, hardware and business environment (referring to possible rules set by management that may make it unfeasible to produce a new computerised solution).

2. Feasibility Study - Operational:

Checks whether the business workflow (such as a procedure to accomplish a working task) remains feasible even when the computerised solution is proposed. Cannot obstruct or hinder business operations.

2. Feasibility Study - Timeliness:

Checks whether the new computerised solution has the necessary data available on time, as certain departments may require certain business data or information on time.

2. Feasibility Study - Economic:

Checks whether the new proposed solution is economically feasible in terms of financial aspects and staff resource allocation and availability. A budget should be well planned and costs should be well projected to determine whether the organisation will be in a position to pay and allocate the necessary resources for the new computerised solution.

2. Feasibility Study - Legal:

Ensures that the new computerised solution harmonizes with the law in terms of;

• Stored data

• Processed data

• Property rights of software

• Authorisation and access to business data

2. Feasibility Study - Social:

Ensures that the employees will still make use of the new solution without any regrets. Employees should have the opportunity to learn how to use the new software without difficulties.

2. Feasibility Study - What important decision is taken by top management and the system analyst at the end of this stage?

The end of the feasibility study stage is characterised by one important decision to be taken by top management and the systems analyst:

• Either to continue with the project together with reasons for justifying its development

• Or to quit the project together with reasons why it should not continue.

Provided that a positive decision was taken, the systems analyst then moves to the next stage.

3. Requirements Elicitation - Examples of fact-finding exercises to learn about existing procedures and problems:

• Interviews

• Questionnaires

• Inspection of documents

• Observation

  • existing system

  • work/business processes

3. Requirements Elicitation - Observation of the Existing System:

System analysts/ business analysts may require spending some time in the department or organisation concerned, seeing at first hand the procedures used, the workloads involved and any bottlenecks envisaged (means foreseeing or anticipating points of congestion in a process, project, or system where progress slows down, gets stuck, or is restricted).

3. Requirements Elicitation - Inspection of Documents:

Reading the documentation associated with the system to establish type of current reports and data currently used. Involves also inspecting any documentation associated with the current system to establish the;

• data input

• type of current output reports

• data currently being used

3. Requirements Elicitation - Involve Staff:

Asking clerical staff to keep special counts during a specific period of investigation to establish where problems might lie. Unknowingly staff might present problems that might help to eliminate or solve with the new system.

3. Requirements Elicitation - Questionnaires:

Prepare questionnaires (set of questions) to a wide range of different staff. Can be useful when a lot of people will be affected by the new system, and even more useful if the system might entail different users using one system.

3. Requirements Elicitation - Interviews:

Most common and useful way of fact finding. Interviews must be well planned and considerations must be made to such factors as;

• whom to interview

• when to interview

• what to ask

• where to hold the interview

3. Requirements Elicitation - Off-the-Shelf V.S Tailor-Made / Purpose-Built software considerations:

Off-the-shelf:

• readily available and cheaper

• tried and tested, error-free

• general functionality, may not fulfil all business needs → may lack functions important to a particular business and might have to align their operational processes with these off-the-shelf software systems

• other competitors are using it

Tailor-made / Purpose-Built:

• not available, have to be purposely built → allowing for custom development

• tailored functionality for a specific business and fulfils all business’ needs as it aligns with current business’ processes.

• expensive

• not tried and tested fully, not error-free

• can put a business in a competitive advantage

3. Requirements Elicitation - Alternative Solutions to Off-the-Shelf or Tailor-Made / Purpose-Built:

• Renting systems/parts of systems/functionality

• Cloud based solutions;

  • SaaS (Software as a Service)

  • IaaS (Infrastructure as a Service)

  • PaaS (Platform as a Service

3. Requirements Elicitation - What is the important stage in the development life cycle? What are the categories of the software requirements?

An important stage is deriving all the new requirements for the new feasible computerised solution. The Systems Analyst must elicit what should be inputted, processed, outputted and stored in the new computerised solution. Dividing the software requirements into:

• outputs

• inputs

• the processing required

• data storage

At this stage the project is feasible, yet;

• more information needs to be collected to develop the new software requirements specification

• a more detailed report of the overall costs of the project will be estimated and undertaken.

Many systems analysts usually work backwards, 1) starting from outputs the user needs, 2) then defining necessary inputs, 3) the processing involved to output the wanted information and 4) identify the What, How and Where data is stored.

3. Requirements Elicitation - Outputs:

These include:

• what type of information is to be outputted from the new software

• which users will be authorised to read/access that particular information

• the output devices to be used with the new software

• preparation of views (output screen layouts for different users accessing the same database), hardcopy reports and forms

3. Requirements Elicitation - Inputs:

These include:

• what type of data is needed for inputting

• all data collection methods (e.g. barcode, MICR, etc)

• data validations to be implemented on the inputted data

• the input devices to be used

3. Requirements Elicitation - Data Processing:

These include:

• what data should be processed

• basic or detailed flowcharts to determine how data is processed

• modular algorithmic design - each processing task has its own separate algorithm

• the use of Data Flow Diagrams to identify where data is actually flowing

3. Requirements Elicitation - Data Storage:

These include:

• What data to be stored

  • What data is actually needed for the new software

• How data should be stored

  • What relations are needed to store related data

  • What are the constraints made on each relation

  • What data types are required

  • Security constraints

• Where data should be stored

  • In which infrastructure? Which server

  • Estimated costs are reviewed as the organisation may opt for buying new