System Development Life Cycle: Investigation, Analysis, Design
|1. Recognition of need
|What is the problem or opportunity?||Statement of scope and
|2. Feasibility Study
Evaluation of existing
system and procedures
Analysis of alternative
|What are the user’s demonstrable needs?
Is the problem worth solving?
How can the problem be redefined?
|Technical / behavioral
Cost / benefit analysis
System scope and objectives
Statement f new scope and
Detailed evaluation of
|What must be done to solve the problem?
What are the facts?
|Logical model of system
e.g. data dictionary, data flow
Output, Input, Files
|In general, how must the problem be solved?
Specifically, how must the problem be solved?
What is the system (processing) flow?
Does the user approve the system?
How well do individual
programs / modules test out? How ready are
programs for acceptance test?
|Design of alternative
Final cost/ benefit analysis
Approval of systems by user
Programs, Test plans
Security, audit and operating
Actual hardware use
Formal system test
File / system
|What is the actual
operation? Are user
manuals ready? Are
these delays in loading
|Is the key system
running? Should the
system be modified?
|User requirements met
User standards met
STAGE I: INITIAL INVESTIGATION
The objective is to determine whether request is valid and feasible before a recommendation is reached to do nothing, improve or modify the existing system or build a new one.
The user’s request form specifies the following:
- User assigned title of work requested.
- Nature of work requested (problem definition).
- Date request was submitted.
- Date job should be completed.
- Job objective (s) – purpose of job requested.
- Expected benefits to be derived from proposed change.
- Input/ Output description – quantity and frequency of inputs and outputs of proposed change
- Requester’ signature, title, department, and phone number.
- Signature, title, department and phone number approving, the request.
User need identification and analysis are concerned with what the user needs rather than what he/she wants. This step is intended to help the user and the analyst understand the real problem rather than its symptom.
DETERMING THE USER’S INFORMATION REQUIREMENTS
There are three strategies for gathering information regarding the user’s requirements.
- Asking: This strategy obtains information from users by simply asking them about the requirements. It assumes a stable system where users are well informed and can overcome biases in defining their problem. There are three key asking methods:
- Questionnaire: Questions may be open-ended or closed. An open-ended question allows the respondent to formulate a response. It is used when feelings or opinions are important. In contrast, a closed question requests one answer from a specific set of responses. It is used when factual responses are known.
- Brainstorming: It is technique used for generating new ideas and obtaining general information requirements. This method is appropriate for gathering nonconventional solutions to problems. A guided approach to brainstorming asks each participant to define ideal solutions and then select the best feasible one. It works well for users who have system’s knowledge but have difficulty accepting new ideas.
- Group Consensus: It asks participants for their expectations regarding specific variables. In a Delphi inquiry, for example, each participant fills out a questionnaire. The results are summarized and given to participants along with a follow-up questionnaire. Participants are invited to change their responses. The results are again summarized and fed back to the participants. This debate by questionnaire continues until participants responses have converged enough. This method has an advantage over brainstorming in that participants are not subjected to psychological pressure from others with presumed authority or influence.
- Getting information from the existing information system: Determining information from an existing application has been called the data analysis approach.
It simply asks the user what information is currently received and what other information is required. It relies heavily on the user to articulate information needs.
The analyst examines all reports, discusses with the user each piece of information examined, and determines unfulfilled information needs by interviewing the user. The analyst is primarily involved in improving the existing flow of data to the user.
The data analysis method is ideal for making structured decisions, although it requires that users articulate their information requirements. A major drawback is a lack of established rules for obtaining and validating information needs that are not linked to organizational objectives.
This strategy for determining user information requirements is used when the user cannot establish information needs accurately before the information system is built. The reason could be the lack of an existing model on which to base requirements or a difficulty in visualizing candidate systems. In this case, the user needs to anchor on real-life systems from which adjustments can be made. Therefore, the iterative discovery approach captures an initial set of information requirements and builds a system to meet these requirements. As users gain experience in its use, they request additional requirements or modifications, in the system. In essence, information requirements are discovered by using the system. Prototyping is suitable in environments where it is difficult to formulate a concrete model for defining information requirements and where the information needs of the user are evolving, such as in Decision Support System (DSS).
4. PROBLEM DEFINITION AND PROJECT INITIATION:
The first step in an initial investigation is to define the problem that led to the user request. The problem must be stated clearly, understand, and agreed upon by the user and the analyst. It must state the objectives the user is trying to achieve and the results the user wants to see.
Once the project is initiated, the analyst begins to learn about the setting, the existing system, and the physical processes related to the revised system.
After obtaining this background knowledge, the analyst begins to collect data on the existing system’s outputs, inputs, and costs. The tools used for information gathering are:
- Review of Written Documents: The first step to gather information of a system is to search and review the various forms of written documents such as professional references, procedure manuals, textbooks, company studies, government publications, consultant studies, etc. of that system.
- On-site observations: The major objective of on-site observation is to get close to the real system being studied. The methods used may be natural or contrived, obtrusive or unobtrusive, direct or indirect, and structured or unstructured. The main limitation of observation is the difficulty of observing attitudes and motivation and the many unproductive hours that often are spent in observing one-time activities.
- Interviews: It is a face-to-face interpersonal meeting designed to identify relations and capture information as it exists. It is flexible tool, offering a better opportunity than the questionnaire to evaluate the validity of the information gathered. The major drawback is preparation time. Interviewing is an art that requires experience in arranging the interview, setting the stage, establishing rapport, phrasing questions clearly, avoiding arguments, and evaluating the outcome.
- Questionnaires: It is a self-administered tool that is more economical and requires less skill to administer than the interview. It examines a large number of respondents at the same time, provides standardized wording and instructions, and places less pressure on subjects for immediate response. The main drawback is the low percentage of returns.
In constructing a questionnaire, the analyst must focus on question content, wording, and format. These are considered with validity and that stem from respondent’s failure to remember specific details, reluctant to report the true impressions of what occurred, or inability to communicate information.
An interview or a questionnaire may be structured or unstructured. The unstructured approach allows respondents to answer questions freely in their own words, whereas the structured approach requires specific response to open-ended or closed questions.
There are five major varieties of closed questions:
- Fill-in-the-blanks questions request specific information.
- Dichotomous questions offer a two-answer choice.
- Ranking scales questions ask the respondent to rank a list of items in order of importance or preference.
- Multiple-choice questions ask for specific answer choices.
- Rating scales questions ask the respondent to rank various items along a single dimension (scale).
As data are collected, they must be organized and evaluated and conclusions drawn for preparing a report to the user for final review and approval. Many tools are used for data organization and analysis. The tools are known as the tools of structured analysis.
It is a set of techniques and graphical tools that allow the analyst to develop a new kind of system specifications that are easily understandable to the user.
The tools used for structured analysis are:
- Data flow diagram (DFD).
- Data Dictionary.
- Structured English.
- Decision trees.
- Decision tables.
Data flow diagram:
A DFD, also known as a “bubble chart”, has the purpose of clarifying system requirements and identifying major transformations that will become programs in system design. So, it is starting point of the design phase that functionally decomposes the requirements specifications down to the lowest level of detail. A DFD consists of a series of bubbles joined by lines. The bubbles represent data transformations and the lines represent data flows in the system.
- A square defines a source or destination of system data.
- An arrow identifies data flow – data in motion
- A circle or a “bubble” represents a process that transforms incoming data flow(s) into outgoing data flow(s).
- An open rectangle is a data store – data at rest, or a temporary repository of data.