LECTURE 04

Chapter Objectives
Explain the concept of a business case and how a business case affects an IT project
Describe the strategic planning process and why it is important to the IT team
Explain the purpose of a mission statement
Describe the SDLC, and explain how it serves as a framework for systems development and business modeling
Describe risks and risk management features
List the reasons for information systems projects and the factors that affect such projects
Explain the initial review of systems requests and the role of the systems review committee
Define operational feasibility, technical feasibility, economic feasibility, and schedule feasibility
Describe the steps in a preliminary investigation and the end product of an investigation

I . Systems Development Life Cycle (Planning)

System Development Life Cycle
PLANNING
 Initial stage in the systems development life cycle (SDLC )
 Preliminary investigations which includes a feasibility study
 Learn how IT projects get started, how systems analysts evaluate proposed project and
 Determine the feasibility of a project, the reasoning behind the proposed system development = business case

II . PRELIMINARY INVESTIGATION
An inquiry to determine whether there is sufficient evidences for a system to be proposed
• Company Selection – an existing company
• Problem Assessment – do the problems post great loss and missed opportunities for the company?
• SWOT Analysis – would the proposed solution benefit the entire company? Its users? Internal? External? Will
this give rise to the strengths and eliminate the weaknesses of the company?
• Problem Assessment – do the problems post great loss and missed opportunities for the company? What are the
critical business issues?
• Main Reasons for Systems Proposals/Projects
 Systems request
 Improved services
 Support for new products and services
 Better performance
 More information
 Reduced cost
 Stronger controls (encryption, biometrics)
• SWOT Analysis – would the proposed solution benefit the entire
company? Its users? Internal? External? Will this give rise to the strengths
and eliminate the weaknesses of the company? Success factors? Case for
action?
• Factors that affect Systems Proposal/ Projects
 Internal factors (strategic plans, higher management, client
satisfaction, existing systems and processes)
 External factors (customers, competition, regulatory agencies,
technology, environment, suppliers)

 Company Assessment – research on facts

regarding the entire company and their nature
 Mission Statement
 Vision
 Goals
 Objectives
 Stakeholders
 Organizational Hierarchy
 Business Rules
 Business Processes

• Determine the feasibility of building a case for the selected company based on several preliminary investigations
• Look into the future: how could the company survive or continue its operations without the proposed system?
 • New industries, products, and services emerging from amazing advances in information technology, customers
who expect world-class IT support, a surge in Internet-based commerce, and a global business environment that is
dynamic and incredibly challenging
• Upon close examination and investigation, a business case should be developed
• The business case should be comprehensive, yet easy to understand
• it should describe the project clearly, provide the justification to proceed, and estimate the project’s financial
impact

III. FEASIBILITY
FEASIBILITY ANALYSIS - The process of confirming that a strategy, plan or design is possible and makes sense.
This can be used to validate assumptions, constraints, decisions,
approaches and business cases.
FEASIBILITY
 Describes how easy or difficult it is to do something
 Taking into consideration relevant factors for the
implementation of the project proposal
 Types of feasibility
 Schedule (time)
 Operational (business)
 Technical (technology)
 Economic (monetary)

1. SCHEDULE FEASIBILITY
 The probability of a project to be completed within its scheduled
time limits
 If a project has a high probability to be completed on-time, then
its schedule feasibility is appraised as high
 May include the following methods or measurements:
 Project Estimation
 Gantt and PERT Chart
 CPM (Critical Path Method)
 Change Management

 Gantt Chart

2. OPERATIONAL FEASIBILITY
 Gain an understanding of whether the proposed system will likely solve the business problems, or take
advantage of the opportunities or not
 Assess the following areas:
 Project Size – number of users
 IPO – inputs, processes, outputs
 Management support
 Environment assessment – are the users going to change

3. TECHNICAL FEASIBILITY
 refers to technical resources needed to develop, purchase, install, or operate the system
 Includes evaluating the ability of computer hardware and software to handle workloads adequately.
 List all the specifications of all hardware and software currently in use by the company and the
proposed ones as well

4. ECONOMIC FEASIBILITY
 Method for evaluating the effectiveness of a new system
 Procedure is to determine the benefits and savings that are expected from a candidate system and
compare them with costs
 Compute for the total costs incurred affected by the current system (hardware, software, utilities,
overhead, operating costs, …) and compare with the costs incurred affected by the proposed system
  Indicate proper sources of monetary values
 Calculate for the Payback Period (pp) and the Return on Investment (roi)

RETURN ON INVESTMENT (ROI)

= ( Net Profit / Total Investment ) * 100%
◦ Net profit should be determined through communication with the company (Estimated sales/revenue –
Operating Cost)
◦ Total Investment should be determined through the economic feasibility provided in the previous section
You are a house flipper. You purchased a house at the courthouse auction for $75,000
and spent $35,000 in renovations. After sales, expenses, and commission, you netted
$160,000 on the sale of the renovated house. What is the ROI?

PAYBACK PERIOD (PP)

= determines the amount of time required for an investment to generate sufficient cash flows to recover initial cost
Averaging method: ABC International expends $100,000 for a new machine, with all funds paid out when the machine is
acquired. Over each of the next five years, the machine is expected to require $10,000 of annual maintenance costs, and will
generate $50,000 of payments from customers. The net annual positive cash flows are therefore expected to be $40,000.
When the $100,000 initial cash payment is divided by the $40,000 annual cash inflow, the result is a payback period of 2.5
years.
Subtraction method: Take the same scenario, except that the $200,000 of total positive cash flows are spread out as follows:

Year 1 = $0; Year 2 = $20,000; Year 3 = $30,000; Year 4 = $50,000; Year 5 = $100,000

In this case, we must subtract the expected cash inflows from the $100,000 initial expenditure for the first four years before
completing the payback interval, because cash flows are delayed to such a large extent.

Thus, the averaging method reveals a payback of 2.5 years, while the subtraction method shows a payback of 4.0 years.

 Benefits (tangible or intangible)

 Tangible – measured in monetary terms or in tangible assets (reduced costs, assets not spent on)
 Intangible – have significant impact on the company (time saved, productivity, efficiency, data accuracy)

EVALUATING FEASIBILITY
 Projects where management has a choice in implementing them are called discretionary projects
 Projects where no choice exists are called nondiscretionary projects
 Identify and weed out systems requests that are not feasible
 Even if the request is feasible, it might not be necessary
 Feasibility analysis is an ongoing task that must be performed throughout the systems development process

IV. INITIAL STUDY

Initial Study Overview
1. Understand the Problem or Opportunity
 Ishikawa Diagram
 Pareto Chart

2. Define the Project Scope and Constraints

 Project Scope
 Project Creep
 Constraints
 Present versus future
 Internal versus External
 Mandatory versus Desirable

3. Perform Fact-Finding
 Analyze company’s processes and operations
 Conduct Interviews
  Determine the people to interview
 Establish objectives for the interview
 Develop interview questions
 Prepare for the interview
 Conduct the interview
 Document the interview
 Evaluate the interview
 Review documentation
 Observe
 Survey

4. Evaluate Feasibility
 Evaluate based on the evaluation analysis provided in the previous section

5. Estimate Project Development Time and Cost

 What information must you obtain, and how will you gather and analyze the information?
 What sources of information will you use, and what difficulties will you encounter in obtaining
information?
 Will you conduct interviews? How many people will you interview, and how much time will you need to
meet with the people and summarize their responses?
 Will you conduct a survey? Who will be involved? How much time will it take people to complete it?
How much time will it take to prepare it and tabulate the results?
 How much will it cost to analyze the information gathered and to prepare a report with findings and
recommendations?
 You should provide an estimate for the overall project, so managers can understand the full cost impact
and timetable

6. Present Results and Recommendations to the Management

 The final task in the preliminary investigation is to prepare a report to management
 The format of the preliminary investigation report varies from one company to another
 Follow the guidelines provided

Chapter Summary
 Systems planning is the first phase of the systems development life cycle
 Effective information systems help an organization support its business process, carry out its mission, and serve its
stakeholders
 Strategic planning allows a company to examine its purpose, vision, and values and develops a mission statement,
which leads to goals, objectives, day-to-day operations, and business results that affect company stakeholders
 Systems projects are initiated to improve performance, provide more information, reduce costs, strengthen
controls, or provide better service

 Various internal and external factors affect systems projects

 During the preliminary investigation, the analyst evaluates the systems request and determines whether the project
is from an operation, technical, economic, and schedule standpoint

 Analysts evaluate systems requests on the basis of their expected costs and benefits, both tangible and intangible
 The steps in the preliminary investigation are to understand the problem or opportunity; define the project scope
and constraints; perform fact-finding; estimate the project’s benefits; estimate project development time and cost;
and present results and recommendations to management
 The report must include an estimate of time, staffing requirements, costs, benefits, and expected results for the
next phase of the SDLC

Lecture 05
Chapter Objectives

 List and describe system requirements, including outputs, inputs, processes, performance, and controls
  Explain the importance of scalability in system design
 Use fact-finding techniques, including interviews, documentation review, observation, questionnaires, sampling, and research
 Define total cost of ownership (TCO) and explain the concept
 Conduct a successful interview
 Develop effective documentation methods to use during systems development

Introduction

-This chapter describes requirements modeling techniques and team-based methods that systems analysts use to
visualize and document new systems
-The chapter then discusses system requirements and fact-finding techniques, which include interviewing,
documentation review, observation, surveys and questionnaires, sampling, and research

I. SYSTEMS DEVELOPMENT LIFE CYCLE (SYSTEM

ANALYSIS)
Systems Analysis
- The overall objective is to understand the proposed project,
ensure that it will support business requirements, and build a
solid foundation for system development
- You use a models and other documentation tools to
visualize and describe the proposed system

II. SYSTEM ANALYSIS ACTIVITIES

 Requirements Modeling – Input, Processes, Outputs,
Performance, Security/Control
 Data and Process Modeling
 Object Modeling
 Development Strategies – System Requirements Document

Requirements Modeling
Determine the system requirements
Five General Categories
1. Inputs
- Manufacturing employees must swipe their ID cards into online
data collection terminals that record labor costs and calculate production efficiency
The department head must enter overtime hours on a separate screen
2. Processes
- The student records system must calculate the GPA at the end of each semester
As the final step in year-end processing, the payroll system must update employee salaries, bonuses,
and benefits and produce tax data required by the IRS
3. Outputs
- The Web site must report online volume statistics every four hours, and hourly during peak periods
The inventory system must produce a daily report showing the part number, description, quantity on hand,
quantity allocated, quantity available, and unit cost of all sorted by part number
4. Performance
- The system must support 25 users online simultaneously
Response time must not exceed four seconds
5. Security/Control
- The system must provide log-on security at the operating system level and at the application level
An employee record must be added, changed, or deleted only by a member of the human resources department

SYSTEM ANALYSIS SKILLS AND TECHNIQUES

• Systems Analysis Skills
 Analytical skills
- If you are analytical, you are good at taking a problem or task and breaking it down into smaller elements
in order to solve the problem or complete the task. The opposite type of problem-solving is called the
intuitive approach in which a person senses the correct action to take without proof or reasoning.

 Interpersonal skills
 • Team-Oriented Methods and Techniques
 Joint application development (JAD)
- JAD is a methodology that involves the client or end user in the design and development of an application
through a succession of collaborative workshops known as JAD sessions or in other words, a group
information gathering technique of systems development. JAD was developed by IBM in the late 1970s
originally as a process for designing computer-based systems. JAD centers more on people than on
technology. By following a structured method that utilizes group dynamics, electronic software, visual aids
and software modeling tools, JAD encourages a partnership between business clients, management and IS
personnel (4). The aim is to get all groups with a stake in the project to work together by getting the team
together in meeting rooms with U-shaped or round tables, white boards, overhead projectors and audio-
visual tools. This allows everyone in the room to talk and be heard. By hearing each other the team is able
to produce the appropriate systems requirements. Therefore JAD sessions require the right mix of people
actively participating in order to achieve the goals of the session. A typical JAD session can last between
four days and an entire week and is usually held away from the main office (3). A typical JAD team is has
five to eight roles depending on the project.

 Rapid application development (RAD)

- Rapid Application Development (RAD)
- This application development methodology goes further than JAD in reducing the time taken to develop an
application, is not always as structured as the JAD and focuses more on software development than JAD.
- Rapid Application Development is defined as a methodology created to radically decrease the time needed
to design and implement information systems by relying on extensive user involvement, JAD sessions,
prototyping, integrated CASE tools, and code generators (in particular, object-oriented programming).
(11).
- RAD is based on the concept that systems can be developed faster and of higher quality by gathering
requirements through workshops or focus groups, prototyping and early, reiterative user testing of designs,
use of already existing software components and less formality in reviews and other team communication
(8).

SYSTEM ANALYSIS MODELING TOOLS AND TECHNIQUES

• Functional Decomposition Diagram
 top-down representation of a function or process
 is the process of taking a complex process and breaking it down into its smaller, simpler parts.
- For instance, think about using an ATM. You could decompose the process into:
Walk up to the ATM , Insert your bank card , Enter your pin
- Each of which can be broken down further. Once you've reached the most decomposed pieces of a subsystem,
you can think about how to start coding those pieces. You then compose those small parts into the greater whole.
Check out this Wikipedia Article:
- Decomposition (programming)
- The benefit of functional decomposition is that once you start coding, you are working on the simplest
components you can possibly work with for your application. Therefore developing and testing those components
becomes much easier (not to mention you are better able to architect your code and project to fit your needs).

• Business Process Modeling (previous lecture)

• Data Flow Diagrams – graphically represent the flow of data in a business information system
• Use Case Diagrams - visually represents the interaction between users and the information system. (CASE tools)
• Unified Modeling Language – widely used method of visualizing and documenting software systems design
- UML contains different diagrams and Use case is one of it. Use Case diagram defines Behavioural
component of Software Design i.e. Actor communicating with the system through Task - Use Case. Use
case-external user
- UML also contains Structural diagrams as well as - such as Class Diagram.
- UML is a superset and USE case is subset.
 Use case diagrams
 Sequence diagrams
- shows the timing of interactions between objects as they occur. A systems analyst might use a sequence
diagram to show all possible outcomes, or focus on a single scenario.
-
SYSTEM ANALYSIS BENEFITS, COSTS, AND FUTURE GROWTH
• SCALABILITY
- is the property of a system to handle a growing amount of work by adding resources to the system. In an economic
context, a scalable business model implies that a company can increase sales given increased resources.
 A scalable system offers a better return on the initial investment
 To evaluate, you need information about projected future volume for all outputs, inputs, and processes
• TOTAL COST OF OWNERSHIP
-ownership is a financial estimate intended to help buyers and owners determine the direct and indirect costs of a
product or system. It is a management accounting concept that can be used in full cost accounting or even
ecological economics where it includes social costs.
 Total cost of ownership (TCO) is especially important if the development team is evaluating several
alternatives
 One problem is that cost estimates tend to understate indirect costs
 Rapid Economic Justification (REJ)
- REJ - is a framework to help IT professionals analyze and optimize the economic performance
of IT investments, and appropriate optimal resources and capital for IT projects.

SYSTEM ANALYSIS – FACT FINDING

• Fact-Finding Overview

 The first step is to identify the information you need

 Develop a fact-finding plan
 Who, What, Where, When, How, and Why?
 Difference between asking what is being done and what could or should be done

• The Zachman Framework

-is an enterprise ontology and is a fundamental structure for Enterprise Architecture which provides a way
of viewing an enterprise and its information systems from different perspectives, and showing how the
components of the enterprise are related.
 Zachman Framework for Enterprise Architecture

 Helps managers and users understand the model and assures that overall business goals translate into
successful IT projects

III. FACT – FINDING TECHNIQUES

 Interviews
 Observation
 Document Review
 Questionnaires and Surveys
 Research
 Sampling
** Use triangulation method ** means using more than one method to collect data on the. same topic. This is a
way of assuring the validity of research through. the use of a variety of methods to collect data on the same topic,
which. involves different types of samples as well as methods of data collection.
Method 1 and method 2 - compare
1) Interviews
1. Determine the people to interview
2. Establish objectives for the interview
3. Develop interview questions
 Creating a standard list of interview questions helps to keep you on track and avoid unnecessary
tangents
 Avoid leading questions
 Open-ended questions
 Closed-ended questions
 Range-of-response questions
> A leading question is a question which subtly prompts the respondent to answer in a particular way. Leading
questions are generally undesirable as they result in false or slanted information.
4. Prepare for the interview
 Careful preparation is essential because interview is an important meeting and not just a casual
chat
  Limit the interview to no more than one hour
 Send a list of topics
 Ask the interviewee to have samples available
5. Conduct the interview
 Develop a specific plan for the meeting
 Begin by introducing yourself, describing the project, and explaining interview objectives
 Use engaged listening
 Allow the person enough time to think about the question
 After interview, summarize the session and seek a confirmation
6. Document the interview
 Note taking should be kept to a minimum
 After the interview, record the information quickly
 After the interview, send memo expressing appreciation, including the main points discussed so
the interviewee has a written summary and can offer additions or corrections
7. Evaluate the Interview

2) Document Review
 a data collection method for evaluation
 includes a basic overview of document
 when to use i
 how to plan and conduct i
 how it affects the system and the business processes
 its advantages and disadvantages

3) Observation
 Seeing the system in action gives you additional perspective and a better understanding of the system
procedures
 Plan your observations in advance
 Hawthorne Effect
4) Questionnaires and Surveys
 Structured and Unstructure
 When designing a questionnaire, the most important rule of all is to make sure that your questions collect
the right data in a form that you can use to further your fact-findin
 Fill-in form

5) Research
 Can include the Internet, IT magazines, and books to obtain background information, technical material,
and news about industry trends and developments
 Site visit

6) Sampling
 Systematic sample
 Stratified sample
 Random sample
 Main objective of a sample is to ensure that it represents the overall population accurately

Interviews versus Questionnaires

o Interview is more familiar and personal
o Questionnaire gives many people the opportunity to provide input and suggestions
o Brainstorming
o Structured brainstorming
o Unstructured brainstorming

IV. DOCUMENTATION

The Need for Recording the Facts

 Record information as soon as you obtain it
  Use the simplest recording method
 Record your findings in such a way that they can be understood by someone else
 Organize your documentation so related material is located easily
 Software Tools
1. CASE tools
2. Productivity software
o Word processing, spreadsheets, database management, presentation graphics programs
o Histogram
3. Flowchart
4. Graphics modeling software
5. Personal information managers
o Personal information manager (PIM)
o Handheld computers
o Personal digital assistants (PDAs)
6. Wireless communication devices
7.
V. DOCUMENTATION – FLOWCHART
- A business flowchart shows the steps that make up a business process, along with who's responsible for each
step.
- They are useful for analyzing current processes, planning improvements, and crystallizing communication
between process participants.
Flowchart Symbols
• Flowcharting symbols can be divided into the following four categories:
1. Input/output symbols
o Document

o Online keying

o Display

o Input / Output

2. Processing symbols
o Manual operations

o Computer processing

3. Storage symbols
o Magnetic disk

o Magnetic tape

4. Flow and miscellaneous symbols

o Document or processing flow

o On-page connector

o Off-page connector

o Terminal

o Decision

TYPES OF FLOWCHART

• Document
  Illustrates the flow of documents and information between areas of responsibility within an organization.
 A document flowchart is particularly useful in analyzing the adequacy of control procedures.
• System
 System flowcharts depict the relationship among the input, processing, and output of an AIS
• Program
 A program flowchart describes the specific logic to perform a process shown on a systems flowchart

IMPORTANCE OF THE SYSTEMS ANALYSIS PHASE

 The systems analysis phase includes three activities: requirements modeling, data and process modeling, and
consideration of development strategies
 The main objective is to understand the proposed project, ensure that it will support business requirements, and
build a solid foundation for the systems design phase
 The conclusion of the requirements modeling allow systems developers to have a clear understanding of the
business processes and system requirements
 The next step is to model the logical design of the system
 The fact-finding process includes interviewing, document review, observation, questionnaires, sampling, and
research
 Systems analysts should carefully record and document factual information as it is collected, and various
software tools can help an analyst visualize and describe an information system

Lecture 06
Chapter Objectives
 Describe data and process modeling concepts and tools, including data flow diagrams, a data dictionary, and process
descriptions
 Describe the symbols used in data flow diagrams and explain the rules for their use
 Draw data flow diagrams in a sequence, from general to specific
 Explain how to level and balance a set of data flow diagrams
 Describe how a data dictionary is used and what it contains
 Use process description tools, including structured English, decision tables, and decision trees
 Describe the relationship between logical and physical models

Introduction
The development of a logical model of the proposed system and document the system requirements
◦ Logical model shows what the system must do
◦ Physical model describes how the system will be constructed

I. DATA AND PROCESS MODELING TOOLS

Overview of Data and Process Modeling Tools
• Systems analysts use many graphical techniques to describe an information system
• A data flow diagrams (DFD) uses various symbols to show how the system transforms input data into useful
information

DATA FLOW DIAGRAM

• A data flow diagram (DFD) shows how data moves through an information system but does not show program
logic or processing steps
• A set of DFDs provides a logical model that shows what the system does, not how it does it
• DFDs are subdivided into successively lower levels in order to provide increasing amounts of detail.
• CONTEXT DIAGRAM
• Highest level (most general)
• Purpose: shows inputs and outputs of the system
• Only one process symbol
• LOWER LEVEL DIAGRAMS (Level – 0, …)
• Purpose: show all major activity steps of a system
• Processes are labeled 1.0, 2.0 and so on

DATA FLOW DIAGRAM SYMBOLS

•Gane and Sarson Symbols
• Yourdon-Coad Symbols

1. External Entity
o An external entity is a source or destination of a data flow which is outside the area of study. (Terminators,
Source, Sink)
o Only those entities which originate or receive data are represented on a business process diagram.
o The symbol used is an oval containing a meaningful and unique identifier.
2. Process
o A process shows a transformation or manipulation of data flows within the system. Receives input data
and produces output that has a different content, form, or both
o Contain the business logic, also called business rules. Referred to as a black box
o The symbol contains two descriptive elements:
a. An identification number appears in the top part to show the process number
b. A descriptive title is placed in the center of the box. This should be a simple imperative sentence
with a specific verb, for example 'maintain customer records' or 'find driver'.
3. Data Flow
o A data flow shows the flow of information from its source to its destination.
o A data flow is represented by a line, with arrowheads showing the direction of flow. Information always
flows to or from a process and may be written or electronic.
o Each data flow may be referenced by the processes or data stores at its head and tail, or by a description
of its contents.
o Names of data flows are in NOUN format
4. Data Store
o A data store is a holding place for information within the system
o Data stores may be long-term files such as sales ledgers, or may be short-term accumulations: for
example batches of documents that are waiting to be processed
o Each data store should be given a reference followed by an arbitrary number.
COMMON DFD MISTAKES
• Illegal data flows
 An external entity cannot provide data to external entity without a process
 Data cannot move directly from an external entity to a data store without being processed
 Data cannot move directly from a data store to an external entity without being processed
 Data cannot move directly from one data store to another without being processed
• Black Hole
• Miracle / Spontaneous Generation
• Grey Hole
• Same names for the data flows, data stores, processes, and entities

II. CREATING A SET OF DFDS

DFD Creation Guidelines
• Draw the context diagram so that it fits on one page
• Use the name of the information system as the process name in the context diagram
• Use unique names within each set of symbols
• Do not cross lines
• Provide a unique name and reference number for each process
• Obtain as much user input and feedback as possible
DFD Creation
• Create a graphical model of the information system based on your fact-finding results
• Three-step process
 Step 1: Draw a context diagram (Process 0 )
 Step 2: Draw a diagram 0 DFD
o Parent diagram
o Child diagram
o Functional primitive

 Step 3: Draw the lower-level diagrams

o use leveling (exploding, partitioning or decomposing)

o use balancing (input and output data flows of the parent DFD are maintained on the child
DFD)
III. PROCESS DESCRIPTION TOOLS
Process Description
Documents the details of a functional primitive, and represents a specific set of processing steps and business
logic
Process Description Tools
1. Modular Design – is based on combinations of three logical structures, sometimes called control structures,
which serve as building blocks for the process
2. Structured English – is a subset of standard English that shows the iteration structure and describes logical
processes clearly and accuratel
3. Decision Tables – logical structure that shows every combination of conditions and outcome
4. Decision Trees – graphical representation of the conditions, actions, and rules found in a decision table

VI. LOGICAL AND PHYSICAL MODELS

Logical vs Physical Models

 While structured analysis tools are used to develop a logical model for a new information system, such tools also
can be used to develop physical models of an information system
 A physical model shows how the system’s requirements are implemented

Sequence of Models
  - Many systems analysts create a physical model of the current system and then develop a logical model of the
current system before tackling a logical model of the new system
 - Performing that extra step allows them to understand the current system better

Four-Model Approach
 Develop a physical model of the current system, a logical model of the current system, a logical model of the new
system, and a physical model of the new system
 The only disadvantage of the four-model approach is the added time and cost

CHAPTER SUMMARY
 - During data and process modeling, a systems analyst develops graphical models to show how the system
transforms data into useful information
 - The end product of data and process modeling is a logical model that will support business operations and meet
user needs
 - Data and process modeling involves three main tools: data flow diagrams, a data dictionary, and process
descriptions
 - Data flow diagrams (DFDs) graphically show the movement and transformation of data in the information
system
 - DFDs use four symbols
 - A set of DFDs is like a pyramid with the context diagram at the top
 - The data dictionary is the central documentation tool for structured analysis
 - Each functional primitive process is documented using structured English, decision tables, and decision trees
 -Structured analysis tools can be used to develop a logical model during one systems analysis phase, and a
physical model during the systems design phase

LECTURE 07
Chapter Objectives
 Describe the concept of Software as a Service
 Define Web 2.0 and cloud computing
 Explain software acquisition alternatives, including traditional and Web-based software development strategies
 Describe software outsourcing options, including offshore outsourcing and the role of service providers
 Explain advantages and disadvantages of in-house software development
 Discuss cost-benefit analysis and financial analysis tools
 Describe the system requirements document
 Explain the transition from systems analysis to systems design

Introduction
The main objective of the systems analysis phase is to build a logical model of the new information system. Let us
evaluate the different alternative solutions, preparation of the system requirements document, and presentation of
the system requirements document to the management.

Development Strategies Overview

Selecting the best development path is an important decision that requires companies to consider three key topics
• The impact of the Internet
• Software outsourcing options
• In-house software development alternatives

The Impact of the Internet

• Software as a Service
 A model of software deployment where an application is hosted as a service provided to customers over
the Internet. SaaS reduces the customer's need for software maintenance, operation, and support
 The Software and Information Industry Association (SIIA) believes that the concept of software as a
service is redefining the way that companies develop and deploy their information systems
• Traditional vs Web-based Systems Development
 Traditional development
• System design is influenced by compatibility issues
• Systems are designed to run on local and wide-area company networks
• Web-based features are treated as enhancements rather than core elements of the design
  Web-based development
• Systems are developed and delivered in an Internet-based framework such as .NET or
WebSphere
• Internet-based development treats the Web as the platform, rather than just a communication
channel
• Web-based software usually requires additional layers, called middleware
 WebSphere
 Microsoft’s .NET
 Many firms rely on traditional systems

Outsourcing
• The transfer of information systems development, operation, or maintenance to an outside firm that provides these
services, for a fee, on a temporary or long-term basis
• Outsourcing can refer to relatively minor programming tasks, renting software from a service provider,
outsourcing a basic business process (often called business process outsourcing, or BPO), or handling a
company's entire IT function
• The Growth of Outsourcing
 Traditionally, firms outsourced IT tasks as a way of controlling costs and dealing with rapid technological
change
 Outsourcing has become part of an overall IT strategy for many organizations
 A firm that offers outsourcing solutions is called a service provider
 Application service providers (ASP)
 Internet business services (IBS)
• Also called managed hosting
• Outsourcing Fees
 A fixed fee model uses a set fee based on a specified level of service and user support
 A subscription model has a variable fee based on the number of users or workstations that have access to
the application
 A usage model or transaction model charges a variable fee based on the volume of transactions or
operations performed by the application
• Outsourcing Issues and Concerns
 Mission-critical IT systems should be out-sourced only if the result is a cost-attractive, reliable, business
solution that fits the company’s long-term business strategy
 Outsourcing also can affect day-to-day company operations and can raise some concerns
 A company must review carefully issues relating to insurance, potential liability, licensing and
information ownership, warranties, and disaster recovery
 Mergers and acquisitions also can affect outsourcing clients
 Outsourcing can be especially attractive to a company whose volume fluctuates widely, such as a defense
contractor
• Offshore Outsourcing
 also known as global outsourcing
 Practice of shifting IT development, support, and operations to other countries

I. IN-House Software Development Options

 Make or Buy Decision

 The choice between developing versus purchasing software often is called a make or buy, or build or buy
decision
 The company’s IT department makes, builds, and develops in-house software
 A software package is obtained from a vendor or application service provider
  Software vendors – companies that develop software for sale
 Value-added reseller (VAR) – a firm that enhances a commercial package by adding custom features and
configuring it for a particular industry
 Horizontal application – available for every type of activity, separate divisions
 Vertical application – for a specific type of business

In-house development Purchasing a software package

• Satisfy unique business requirements • Lower costs

• Minimize changes in business procedures and
policies
• Meet constraints of existing systems
• Meet constraints of existing technology
• Develop internal resources and capabilities
• Requires less time to implement
• Proven reliability and performance benchmarks
• Requires less technical development staff
• Future upgrades provided by the vendor
• Obtain input from other companies

 Customizing a Software Package

1. You can purchase a basic package that vendors will customize to suit your needs
2. You can negotiate directly with the software vendor to make enhancements to meet your needs by paying
for the changes
3. You can purchase the package and make your own modifications, if this is permissible under the terms of
the software license
 Creating User Applications
1. User application
2. User interface
3. Help desk or information center (IC)
4. Screen generators
5. Report generators
6. Read-only properties

ROLE OF THE SYSTEM ANALYST

• When selecting hardware and software, part of the evaluation and selection team
 Eliminate system alternatives that will not work
 Rank the system alternatives that will work
 Present the viable alternatives to management for a final decision

II. THE SOFTWARE ACQUISITION PROCESS

1. Evaluate the Information System Requirement
• Identify key features
• Prepare a request for proposal or quotation
 Request for proposal
 Evaluation model
 Request for quotation
2. Identify Potential Vendors or Outsourcing Options
 Potential use of the Internet
 Work with a consulting firm
 Source from the Internet bulletin board systems that contain thousands of forums, called
newsgroup
3. Evaluate the Alternatives
 Existing users
 Application testing
 Benchmarking
4. Perform Cost-Benefit Analysis
 Purchase software = software license
5. Prepare a Recommendation
 Recommendation that evaluates and describes the alternatives, together with the costs, benefits,
advantages, and disadvantages of each option
 Document each step and deliver a presentation
 6. Implement the Solution
 Implementation tasks will depend on the solution selected
 Before the new software becomes operational, you must complete all implementation steps,
including loading, configuring, and testing the software; training users; and converting data files to
the new system’s format

COMPLETION OF SYSTEMS ANALYSIS TASKS

• System Requirements Document
• Presentation to Management
 Implement an outsourcing alternative
 Develop an in-house system
 Purchase or customize a software package
 Perform additional systems analysis work
 Stop all further work

Lecture 08
Chapter Objectives
 Explain the concept of user interface design and human-computer interaction, including basic principles of user-centered
design
 Explain how experienced interface designers perform their tasks
 Describe rules for successful interface design
 Discuss input and output technology issues
 Design effective source documents and forms
 Explain printed output guidelines
 Describe output and input controls and security
 Explain modular design and prototyping techniques
Systems Development Life Cycle (System Design)

Introduction

The goal of systems design is to build a system that is effective, reliable, and maintainable

 System Design Guidelines

The systems analyst must understand the logical design of the system before beginning the physical design of any
one component
• Data design
• User interface
• Architecture
• System design specification

 System Design Objectives

• The goal of systems design is to build a system that is effective, reliable, and maintainable
• A system is reliable if it adequately handles errors
• A system is maintainable if it is well designed, flexible, and developed with future modifications in mind

• User Considerations
 Carefully consider any point where users receive output from, or provide input to, the system
 Anticipate future needs of the users, the system, and the organization – hard-coded
  Provide flexibility
 Parameter, default

• Data Considerations
 Data should be entered into the system where and when it occurs because delays cause data errors
 Data should be verified when it is entered, to catch errors immediately
 Automated methods of data entry should be used whenever possible
 Audit trail
 Every instance of entry and change to data should be logged
 Data should be entered into a system only once
 Data duplication should be avoided

• Architecture considerations (Use a modular design)

• Design Trade-Offs
 Most design trade-off decisions that you will face come down to the basic conflict of quality versus cost
 Avoid decisions that achieve short-term savings but might mean higher costs later

I. PROTOTYPING

 Prototyping Methods

• System prototyping
• Design prototyping
• Throwaway prototyping

 Prototyping offers many benefits

• Users and systems developers can avoid misunderstandings
• Managers can evaluate a working model more effectively than a paper specification
 Consider potential problems
• The rapid pace of development can create quality problems
• In very complex systems, the prototype becomes unwieldy and difficult to manage

 Prototyping Tools – systems analysts can use powerful tools to develop prototypes
 CASE tools
 Application generators
 Report generators
 Screen generators
 Fourth-generation language (4GL)
 Fourth-generation environment

 Limitations of Prototypes
 A prototype is a functioning system, but it is less efficient than a fully developed system
 Systems developers can upgrade the prototype into the final information system by adding the necessary
capability
 Otherwise, the prototype is discarded

FUTURE TRENDS IN SOFTWARE DEVELOPMENT

Many software development tools and technologies are in transition
• Web services
• Open source software
• Service-oriented architecture (SOA)
• Loose coupling
• Software quality is more important than ever
II. USER INTERFACE
- Describes how users interact with a computer system, and consists of all the hardware, software, screens,
menus, functions, output, and features that affect two-way communications between the user and the
computer

 Graphical User Interface - uses visual objects and techniques that allow users to communicate effectively with
the system.

 Usability – user satisfaction, support for business functions, and system effectiveness
 Process-control systems – allow users to send commands to the system
 User-centered systems – how users communicate with the information system, and how the system
supports the firm’s business operations
- Requires the understanding of human-computer interactions and user-centered design principles

 Human-Computer Interaction describes the relationship between computers and people who use them to
perform their jobs
 Electronic health records (EHRs)

SEVEN HABITS OF SUCCESSFUL INTERFACE DESIGNERS

1. Understand the Business
2. Maximize Graphical Effectiveness
3. Think Like a User
4. Use Models and Prototypes
5. Focus on Usability
6. Invite Feedback
7. Document Everything

User Interface Design

• User Interface Controls
 Menu bar
 Toolbar
 Command button
 Dialog box
 Text box
 Toggle button
A Handbook for User Interface Design

1. Rule 01: Create an interface that is easy to learn and use

2. Rule 02: Enhance user productivity

 Consider a natural language feature that allows
users to type commands or requests in normal text
phrases (Help)
 Group functions
 Alphabetize menu lists
 Provide shortcuts

3. Rule 03: Provide users with help and feedback

4. Rule 04: Create an attractive layout and design
 Use appropriate colors
 Use hyperlinks that allow users to navigate to related topics
 Be consistent with the terminologies used

5. Rule 05: Enhance the Interface

 switchboard
 command button
 menu bars
 toolbar
 dialog box
 toggle button
 list boxes
 scroll bar
 option button
 radio button

6. Rule 06: Focus on data entry screens

 7. Rule 07: Use validation rules
 sequence check
 existence check
 data type check
 range check
 reasonableness check
 validity check
 combination check
 batch controls

8. Rule 08: Reduce Input Volume

 input necessary data only
 do not input data that the user can retrieve from system files or calculate from other data
 do not input constant data
 use codes

Source Document and Form Design

• The quality of the output is only as good as the

quality of the input
• Garbage in, Garbage out (GIGO)
• source document – collects input data, triggers or
authorizes an input action, and provides a record of
the original transaction
• form layout – how the form will appear and how
easy it will be to complete

Form Design

• heading zone – contains the company name/logo

and the details of the form

• control zone – contains codes, identification

information, numbers, and dates that are used for
storing completed forms
 • instruction zone – contains instructions for completing the form

• body zone – main part of the form

• totals zone

• authorization zone – contains required signatures

III. INPUT DESIGN

 Input technology has changed dramatically in recent years
 The quality of the output is only as good as the quality of the input
a. Garbage in, garbage out (GIGO)
b. Data capture
c. Data entry
 Input and Data Entry Methods
• Batch input
 Batch
• Online input
 Online data entry
 Source data automation
 RFID tags or Magnetic data strips
 POS, ATMs
• Tradeoffs

 Unless source data automation is used, manual data entry is slower and more expensive than batch input
because it is performed at the time the transaction occurs and often done when computer demand is at its
highest

 The decision to use batch or online input depends on business requirements

• Input Volume

* Guidelines that will help reduce input volume

 Input necessary data only
 Do not input data that the user can retrieve from system files or calculate from other data
 Do not input constant data
 Use codes

• Designing Data Entry Screens

 Most effective method of online data entry is form filling

* Guidelines that will help you design data entry screens

 Restrict user access to screen locations where data is entered
 Provide a descriptive caption for ever field, and show the user where to enter the data and the
required or maximum field size

 Display a sample format if a user must enter values in a field in a specific format - separator
 Require an ending keystroke for every field
 Do not require users to type leading zeroes for numeric fields
 Do not require users to type trailing zeroes for numbers that include decimals

 Design the screen form layout to match the layout of the source document
 Allow users to add, change, delete, and view records
 Provide a method to allow users to search for specific information
  Provide a way to leave the data entry screen at any time without entering the current record
 Provide users with an opportunity to confirm the accuracy of input data before entering it
 Provide a means for users to move among fields on the form

 Display default values so operators can press the ENTER key to accept the suggested value
 Use a default value when a field value will be constant for successive records or throughout the data
entry session
 Display a list of acceptable values for fields, and provide meaningful error messages

• Input Errors
 Reducing the number of input errors improves data quality
 A data validation check improves input quality by testing the data and rejecting any entry that fails to
meet specified conditions
* At least eight types of data validation checks
 Field check
 Sign check
 Limit check
 Range check
 Size check
 Completeness check
 Validity check
 Check digit verification
 Prompting
 Close-loop verification

• Source Documents
 Information should flow on a form from left to right and top to bottom to match the way users read
documents naturally
 A major challenge of Web-based form design is that most people read and interact differently with on-
screen information compared to paper forms
 Dr. Jakob Nielson believes that users scan a page, picking out individual words and sentences
 As a result, Web designers must use scannable text to capture and hold a user’s attention

INPUT CONTROL
• Every piece of information should be traceable back to the input data
• Audit trail
• Data security
• Records retention policy
• Encrypted – encryption

IV. OUTPUT DESIGN

 What is the purpose of the output?
 Who wants the information, why it is it needed, and how will it be used?
 What specific information will be included?
 Will the output be printed, viewed on-screen, or both? What type of device will the output go to?

Types of Output
 Internet-based information delivery
 E-mail
 Blogs
 Instant messaging
 Wireless devices
 Digital audio, images, and video
 Podcasts
 Automated facsimile systems
 Computer Output to Microfilm
 Computer Output to Digital Media
Printed and Screen Output
• Reports – detail reports, exception reports, summary reports
• User Involvement in Report Design – design in advance, mock-ups
• Report Design Principles
 Printed reports must be attractive, professional, and easy to read
 Report headers and footers
 Page headers and footers
 Column heading alignment
 Column spacing
 Field order
 Grouping detail lines
• Report Design Issues
 Good design standards produce reports that are uniform and consistent
 When a system produces multiple reports, each report should share common design elements
 After a report design is approved, you should document the design in a report analysis form
• Designing Character-Based Reports
 Many systems still produce one or more character-based reports
 When report designers create or modify a character-based report, they use a traditional tool that still
works well, called a printer spacing chart
• Printing Volume and Time
Requirements
 Length calculations
 Time calculations
• Ppm (pages per minute)
• Line printers often use
greenbar paper

• Output Control and Security

 Output must be accurate, complete,
current, and secure
 The IT department is responsible for
output control and security measures
 Many companies have installed
diskless workstations