Systems Analysis and Design – Notes

Chapter 1
System: A system is an orderly grouping of interdependent components linked together according to a plan
to achieve a specific objective. The term is derived from the Greek word systema, which means an organized
relationship among functioning units or components.
Key Implications:
§ A system must be designed to achieve a predetermined objective.
§ Interrelationships and interdependence must exist among the components.
§ The objectives of the organization as a whole have a higher priority than the objectives of its
subsystems.
Components: This can refer to physical parts (e.g., engines, computer hardware), managerial steps (e.g.,
planning, organizing), or subsystems within a larger structure. Each component must perform its function
for the system to achieve its goal.
Characteristics of a System
• Organization: Implies structure and order. It is the arrangement of components that helps achieve
objectives (e.g., a company's hierarchical structure or the physical arrangement of computer hardware).
• Interaction: Refers to the manner in which each component functions with other components of the
system (e.g., the purchasing department interacting with the production department).
• Interdependence: Means that parts of the system depend on one another. The output of one subsystem
is often the required input for another. This coordination is crucial.
Elements of a system
• Outputs and Inputs: The main objective of a system is to produce a valuable output. Inputs are the
elements (e.g., materials, information) that enter the system for processing. Determining the required
output is the first step, which then defines the necessary inputs.
• Processor(s): The operational component that performs the actual transformation of input into output.
• Control: The decision-making subsystem that guides the input, processing, and output. In a computer
system, this is the operating system and software.
• Feedback: A control mechanism where output is measured against a standard. This information is then
"fed back" to influence the inputs or processing.
• Environment: The "suprasystem" in which an organization operates. It is the source of external
elements (e.g., vendors, competitors, government) that can constrain or influence the system.
• Boundaries and Interface: Boundaries are the limits that define a system's components and processes.
The interface is where the system interacts with another system.
Types of System
• Physical or Abstract Systems:
o Physical systems are tangible entities (e.g., computer hardware).
o Abstract systems are conceptual or nonphysical, such as formulas or models representing a real
system.
• Open or Closed Systems:
o An open system has many interfaces with its environment, receiving inputs from and delivering
outputs to the outside (e.g., an information system).
o A closed system is isolated from environmental influences; completely closed systems are rare.
• Man-Made Information Systems: These are systems designed by humans to produce and communicate
information for planning and control. They include:
o Formal Information System: Based on the official organization chart, where information flows
through prescribed channels (e.g., memos, reports).
o Informal Information System: An employee-based system designed to meet personal and
vocational needs and help solve work-related problems outside of formal channels.
 o Computer-Based Information Systems: Rely on computers for handling business applications.
This includes Management Information Systems (MIS) and Decision Support Systems (DSS).
§ Management Information System (MIS): MIS is a person-machine system and a highly
integrated grouping of information-processing functions designed to provide management with
a comprehensive picture of specific operations.
§ Decision Support Systems (DSS): A Decision Support System is a "computer-aided decision
situation with enough 'structure' to permit computer support," which "assists management in
making decisions." It is a continually evolving model that often relies on operations research.

Chapter 2
Specific questions and results of each System Development Life Cycle (SDLC) step
Stage Key Question Result
• What is the problem or A statement of scope and
1. Recognition of need
opportunity? objectives; performance criteria
• What are the user's demonstrable
Technical/behavioral feasibility
needs?
assessment; cost/benefit analysis;
2. Feasibility study • Is the problem worth solving?
redefined system scope and
• How can the problem be objectives.
redefined?
• What must be done to solve the A logical model of the system
3. Analysis problem? (e.g., data dictionary, data flow
• What are the facts? diagram).
• In general, how must the
Detailed design specifications
problem be solved?
(output, input, files, procedures),
• Specifically, how must the
4. Design hardware specifications, final
problem be solved?
cost/benefit analysis, and an
• What is the system (processing) implementation schedule.
flow?
• What is the actual operation? A training program, user-friendly
5. Implementation • Are user manuals ready? documentation, and the converted
• Are there delays in loading files? system.
6. Post-implementation and • Is the key system running? Verification that user requirements
maintenance • Should the system be modified? are met and a satisfied user.
System Description
Definition: A System Description is a clear explanation of how a system works, what it is made of, and
what it does.
Purpose: The purpose of a System Description is to give a clear understanding of how a system works
so that anyone (developers, users, or managers) can see:
o What the system is supposed to do (goals and objectives).
o How the system is structured (its parts and relationships).
o How it operates (processes, inputs, and outputs).
o Where the boundaries are (what is inside vs. outside the system).
o How it interacts with its environment or other systems.

Present System
During analysis, data is collected on the files, decision points, and transactions handled by the present
system to gain a firm understanding of what needs to be done before designing a solution.
When does a project terminate?
A project may be dropped at any time prior to implementation for several reasons:
• The system design cannot meet the changing objectives or requirements of the user.
 • The benefits realized from the system do not justify the cost of implementation.
• There is a sudden change in the user's budget, or design costs increase beyond the feasibility
estimate.
• The project greatly exceeds its time and cost schedule.
• External influence or Natural cause.
Candidate system
Definition: A candidate system is a proposed system being considered as a solution to a problem. It is
developed after the analyst thoroughly understands user needs.
Considerations:
o Technical: Does the organization have the technical ability to build and support the system?
o Behavioral: How will the user staff react to the new system?
o Economic: Does the system provide a worthwhile return on investment?

What are the possible reasons a project doesn’t meet user requirement?
• User requirements were not clearly defined or understood.
• The user was not directly involved in crucial phases of development.
• Inexperienced analysts or programmers.
• Work was done under stringent time constraints.
• Poor user training.
• Deficient hardware.
• The new system left users in other departments out of touch.
• The system was not user-friendly.
• Users changed their requirements during the project.
• Hostile user staff.

Chapter 3
Technical vs. Interpersonal Skills
An analyst must possess a blend of both skill sets. The emphasis changes depending on the phase of the
project.
Skill Type Description Examples Most
Needed In
Interpersonal Skills dealing with relationships, Communication, understanding,
Analysis
communication, and establishing trust. teaching, selling, mediation.
Technical Skills focused on procedures, Creativity, problem-solving, project
techniques, and the tools of systems management, knowledge of business Design
analysis and computer science. functions and system tools.
During Implementation, both technical and interpersonal skills converge and are equally important.
Multi-faceted Role of the Analyst
• Change Agent: The analyst introduces change and must ensure it is accepted by the user.
• Investigator and Monitor: The analyst finds the root cause of a problem and monitors the project's
progress.
• Architect: The analyst creates the detailed "blueprint" for the system, translating user needs into a
technical design.
• Psychologist: The analyst must understand people's feelings, behaviors, and motivations.
• Salesperson: The analyst must "sell" the proposed system to users and management at every stage.
• Motivator: The analyst must encourage users to accept and use the new system.
• Politician: The analyst uses diplomacy and tact to gain support from all involved parties.
Chapter 4
Initial Investigation
Definition: The first step in the SDLC, prompted by a user's request to change or enhance a system.
Objective: To determine if the user's request is valid and feasible before recommending a full, detailed
feasibility study.
Process:
1. The user submits a formal User's Request Form.
2. The analyst conducts a background investigation and fact-finding.
3. The analyst performs a preliminary fact analysis.
4. A Project Proposal is created and submitted to the user for review and approval.
Actual Format Design
• User's Request Form (Figure 4-4, p. 100): This form initiates an investigation and is designed to
capture:
o Job Title and Nature of Request (New/Revision).
o Submission and required completion dates.
o Job Objective(s) and Expected Benefits.
o Specifications for Input and Output (e.g., report titles, quantity, frequency).
o Signatures of the requester and the approver.
• Information-Oriented Flowchart (Figure 4-8, p. 113): This diagram uses standard flowchart symbols
to display the relationships among forms and processes in an existing system, showing the physical flow
of documents between departments.
• Input/Output Analysis Sheet (Figure 4-9, p. 114): A simple table with columns for "Input,"
"Processing/Files," and "Output" used to provide a clear, narrative summary of a specific function.

Chapter 5
What kind of information do we need?
1. Information about the Firm: Provides context on the environment in which the system will operate.
o Policies
o Goals and Objectives
o Organization Structure
2. Information about User Staff: Focuses on the people who run the current system.
o Job functions and authority relationships
o Information requirements
o Interpersonal relationships
3. Information about Work Flow: Describes what happens to data as it moves through the system.
o Procedures for performing tasks
o Work schedules

Where does the information originate?

• Primary External Sources:
o Vendors
o Government documents
o Newspapers and professional journals
• Primary Internal Sources:
o Financial reports
o Personnel and professional staff (e.g., auditors)
o System documentation and manuals
o The user and user staff
o Existing reports and transaction documents
Information Gathering Tools
The primary tools for information gathering are shown:
• Review of literature, procedures, and forms
• On-site observation
• Interviews
• Questionnaires

Literature Review Questions

• Who uses the form(s) and how important are they?
• Is all necessary information included on the forms?
• How many departments receive the form and why?
• How readable and easy to follow is the form?
• How does the information on the form help others make decisions?
On-site Observation Guide Questions
• What kind of system is it and what does it do?
• Who runs the system and who are the key people?
• What is the history of the system?
• What is the system's role within the larger organization?
Alternative Approaches for On-site Observation
Approach Description
Natural or Contrived Observation in a normal work setting vs. a setting created by the observer (e.g., a
lab).
Obtrusive or The subject knows they are being watched vs. observation without the subject's
Unobtrusive knowledge.
Direct or Indirect The analyst watches the subject directly vs. using mechanical devices like
cameras.
Structured or The observer looks for a specific, predefined action vs. noting whatever seems
Unstructured pertinent.
Limitation of On-site observation
• The analyst's presence can cause staff to react differently.
• Attitudes and motivations cannot be observed, only actions.
• Observations are subject to the observer's misinterpretation.
• It can be very time-consuming.
The Analyst should Consider before on-site observation
Before using on-site observation, the analyst should consider:
1. What behavior can be observed that cannot be described otherwise?
2. What data can be obtained more easily or reliably by observation?
3. Can it be done without seriously affecting the behavior being observed?
4. What interpretation is needed to avoid being misled by the obvious?
5. Is the required skill available for the observation?
Interviews - 4 primary advantages
1. Flexibility: Superior for exploring areas where little is known.
2. Validity: The interviewer can observe non-verbal cues.
3. Effectiveness: Good for complex subjects and for probing feelings behind opinions.
4. Cooperation: People are often more willing to talk than to fill out a form.
How to take a successful interview?
1. Set the stage: Explain the purpose and confidential nature of the interview.
2. Establish rapport: Make the interviewee feel at ease and not threatened.
3. Phrase questions clearly: Ask questions exactly as worded to ensure consistency.
4. Be a good listener: Avoid arguments and use "probing" techniques to get more detail.
5. Evaluate the outcome: Record responses accurately and completely.
Rapport
Definition: Rapport is the harmonious relationship between people that builds trust, understanding, and
effective communication.
Purpose of Rapport:
• Builds trust and makes people open up.
• Helps in better communication and cooperation.
• Reduces conflict and misunderstanding.
• Creates a friendly, supportive environment (work, study, or personal).

Questionnaires - Close-ended vs. Open-ended

Type Description Advantages Disadvantages Best For
Open- Allows respondents Good for exploratory Difficult and time- Gaining opinions
ended to answer freely in situations; can uncover consuming to tabulate and understanding
their own words. new ideas. and score; subject to feelings.
interpretation bias.
Close- Provides respondents Quick to analyze; less More costly to prepare; Securing factual
ended with a set of costly to administer; may not cover all information (age,
alternatives from ensures consistent possible responses. salary, etc.).
which to choose. frame of reference.
Chapter 6
Structured Analysis
Definition: Structured analysis is a set of techniques and graphical tools that allow the analyst to develop a
new kind of system specification that is easily understandable to the user.
Goals of Structured Analysis:
o Use graphics wherever possible to improve communication.
o Differentiate between the logical (what the system does) and physical (how it does it) aspects.
o Build a logical system model before implementation.

The primary tools of Structured Analysis

• The Data Flow Diagram (DFD)
• Data Dictionary
• Structured English
• Decision Tree
• Decision Tables
How data flows? Diagram and Rules of Constructing a DFD
• Diagram: A Data Flow Diagram (DFD), also called a "bubble chart," is a graphical tool that describes
what data flows (logical) rather than how it is processed (physical). It clarifies system requirements and
identifies major data transformations.
• Symbol:
o Square: A source or destination of data (an external entity).
o Arrow: Identifies data flow (data in motion).
o Circle/Bubble: A process that transforms data.
o Open Rectangle: A data store (data at rest).
• Rules of Construction:
o Processes should be named and numbered for reference.
o The direction of flow is generally top-to-bottom and left-to-right.
o When a process is decomposed into lower-level details, the subprocesses are numbered
o Names of data stores, sources, and destinations are written in capital letters.
Pros and Cons of Structured Analysis Tools
Structured analysis provides several tools to describe a system. Choosing the right tool depends on the
specific problem you are trying to solve.
Tool Advantages / Pros Limitations / Cons
Data Flow • Shows flow of data clearly
• Poor at showing input/output details •
Diagram • Works for both high-level and detailed analysis
Can confuse first-time users
(DFD) • Provides good system documentation
• Doesn’t explain how the system
Data
• Simplifies and organizes data requirements works
Dictionary
• Too technical for non-technical users
Structured • Good for describing problems needing
• Less visual compared to other tools
English sequence of actions with decisions
• Useful for verifying logic with a few complex
Decision • Becomes messy and hard to follow
decisions
Trees with many decisions
• Leads to limited number of actions
• Best for complex branching logic (e.g.,
Decision • Not good for showing sequence or
discounts, commissions)
Tables process flow
• Great for communicating complex details

Chapter 7
Steps of a Feasibility Study
A feasibility study is a detailed investigation that evaluates potential solutions and helps select the best one.
1. Form a Project Team and Appoint a Project Leader: Involve future users in the design and
implementation. For complex studies, the team should include analysts, user staff, and sometimes an
outside consultant.
2. Prepare System Flowcharts: Use flowcharts and data flow diagrams to visualize the inputs, outputs,
and data flow of the existing system.
3. Enumerate Potential Candidate Systems: Identify different systems (both logical and physical) that
are capable of meeting the user's requirements.
4. Describe and Identify Characteristics of Candidate Systems: Reduce the list of potential systems to a
manageable number and describe the key features and constraints of each.
5. Determine and Evaluate Performance and Cost-Effectiveness: Evaluate how well each candidate
system meets the required performance criteria (e.g., accuracy, response time) and analyze its costs.
6. Weigh System Performance and Cost Data: If the best choice is not clear, assign a weight to each
evaluation criterion to score each system quantitatively.
7. Select the Best Candidate System: The system with the highest score (or best overall value) is selected.
8. Prepare and Report Final Project Directive: Present the findings in a formal feasibility report to
management.
How to Write a Feasibility Report
The report is a formal document for management. It should be brief, non-technical, and clear. A typical
report includes:
• Cover Letter • Economic Justification (cost comparisons,
• Table of Contents return on investment)
• Overview (purpose, scope, and background) • Recommendations and Conclusions
• Detailed Findings (on the present system and • Appendices (supporting documents)
the proposed system)
Oral Presentation
The goal of the oral presentation is to "sell" the proposed system. Its purpose can be:
• Informing: Communicating decisions that have already been made.
• Confirming: Verifying facts and recommendations that have been previously discussed.
• Persuading: Convincing management to approve the recommendations.
The presentation should be brief, factual, interesting, and well-organized, using simple visual aids to help
communicate the key points.

Chapter 8
Selecting an Evaluation Method
Once costs and benefits are identified, an evaluation method must be selected to compare them.
1. Net Benefit Analysis: Subtract total costs from total benefits. This method is simple but does not
account for the time value of money.
2. Present Value Analysis: Calculates the costs and benefits of a system in terms of today's money. This
allows for fair comparison of long-term projects.
3. Net Present Value: The present value of the benefits minus the present value of the costs. This accounts
for the time value of money and is a very common method.
4. Payback Analysis: Determines how long it takes for the accumulated benefits to equal the initial
investment. A shorter payback period is generally better.
5. Break-Even Analysis: Finds the point where the cost of the new system is equal to the cost of the
current one. After this point, the new system begins to generate savings.
6. Cash-Flow Analysis: Tracks accumulated costs and revenues on a regular basis, often in a spreadsheet
format. This is useful for projects that produce revenue.
Chapter 10
What is a Form?
A form is the physical carrier of data and information. It is a tool with a message that can authorize an action
(like a purchase order), provide information for decisions, and improve operations. Poorly designed forms
are a major source of cost and confusion.
Classification of Forms
Forms are generally classified by what they do in the system:
• Action Forms: These forms request someone to take action (e.g., purchase order, sales slip).
• Memory Forms: These forms store historical data for reference and control (e.g., inventory records,
purchase records).
• Report Forms: These forms provide summary data to guide supervisors and managers (e.g., profit and
loss statements, sales analysis reports).
Form Design
Good design focuses on clear communication and ease of use.
• Key Requirements: A form needs a clear title, easy-to-understand labels, and a logical flow.
• Layout Considerations:
o Zoning: Group related information into zones on the form.
o Flow: Data should flow from the top-left corner to the bottom-right.
o Rules and Captions: Use lines (rules) and labels (captions) to guide the user. Captions should be
clear but not so bold that they overpower the data being entered.
o Box Design: Using boxes for data entry with the caption in the upper-left corner is highly efficient,
saves space, and makes data entry easier.
• Spacing: Spacing should be consistent and adequate for either handwriting or typing. A common
standard is 3 lines per vertical inch and 5 characters per horizontal inch.
• Instructions: A well-designed form should be self-instructing. If needed, instructions should be brief
and clear.
• Paper: Choose paper based on appearance, how long the form needs to last (longevity), and how it will
be handled. Color can be used to distinguish copies.