Tangible – Objects and Things which can be touched, Concrete, Palpable,

Systems analysts use a process called business process modeling to represent

company operations and information needs. Business process modeling requires a
business profile and a series of models that document business processes.

A business profile is the starting point for the modeling process.

A rough sketch might be sufficient to document a simple business process. For

complex operations, however, analysts apply computer-based modeling tools that
use a standard language called business process modeling notation (BPMN).
This popular form of online B2B interaction is called supply chain management
(SCM), or supplier relationship management (SRM).

SYSTEMS DEVELOPMENT METHODS

Structured Analysis

Object-Oriented Analysis

Agile Methods

SYSTEMS IMPLEMENTATION During the systems implementation phase, the

new system is constructed. Whether the developers use structured analysis or
O-O methods, the procedure is the same — programs are written, tested, and
documented, and the system is installed.

Other Development Methods

IT professionals know that the key to success is user input — before, during, and
after a system is developed. Over time, many companies discovered that systems
development teams composed of IT staff, users, and managers could complete their
work more rapidly and produce better results. Two methodologies became popular:
joint application development (JAD) and rapid application development
(RAD).

Business Case
Analyzing the Business Case
The term business case refers to the reasons, or justification, for a proposal

A CASE Tool Example

You are a systems analyst working for Sally, the IT manager for a large hotel chain.
Sally is working with top management to develop a strategic plan, and she asked
you to assist her. The plan will guide future company goals and objectives, including
IT projects. Sally has experience with the Visible Analyst CASE tool, but she has
never used it for strategic planning, so she asked you to do some research. First,
you navigate to the strategic planning section, where you can enter planning
statements such as assumptions, goals, objectives, critical success factors, and
others. Planning statements also can document strengths, weaknesses,
opportunities, and threats, as shown in Figure 2-6. After you visit the Help section to
learn more about the strategic planning features, you feel confident that you can
work effectively with this powerful tool. When you present your results to Sally, she
seems pleased. Because the term is new to you, you ask her what critical success
factors are, and she replies that critical success factors are vital objectives that
must be achieved for the company to fulfill its mission.

Systems Request
Systems Request Concentrations

BETTER PERFORMANCE The current system might not meet performance

requirements. For example, it might respond slowly to data inquiries at certain
times, or it might be unable to support company growth. Performance limitations
also result when a system that was designed for a specific hardware configuration
becomes obsolete when new hardware is introduced.

MORE INFORMATION The system might produce information that is insufficient,

incomplete, or unable to support the company’s changing information needs. For
example, a system that tracks customer orders might not be capable of analyzing
and predicting marketing trends. In the face of intense competition and rapid
product development cycles, managers need the best possible information to make
major decisions on planning, designing, and marketing new products and services.

STRONGER CONTROLS A system must have effective controls to ensure that data is
secure and accurate. Some common security controls include passwords, various
levels of user access, and encryption, or coding of data to keep it safe from
unauthorized users. Hardware-based security controls include biometric devices
that can identify a person by a retina scan or by mapping a facial pattern. A new
biometric tool scans hands, rather than faces. The technology uses infrared
scanners that create images with thousands of measurements of hand and finger
characteristics, as shown in Figure 2-9. In addition to being secure, data also must
be accurate.
Controls should minimize data entry errors whenever possible. For example, if a
user enters an invalid customer number, the order processing system should reject
the entry immediately and prompt the user to enter a valid number. Data entry
controls must be effective without being excessive. If a system requires users to
confirm every item with an “Are you sure? Y/N” message, internal users and
customers might complain that the system is not user-friendly

REDUCED COST The current system could be expensive to operate or maintain as a

result of technical problems, design weaknesses, or the changing demands of the
business. It might be possible to adapt the system to newer technology or upgrade
it. On the other hand, cost-benefit analysis might show that a new system would be
more cost effective and provide better support for long-term objectives.

CUSTOMERS Customers are vitally important to any business. Information systems

that interact
with customers usually receive top priority. Many companies implement customer
relationship
management (CRM) systems that integrate all customer-related events and
transactions, including marketing, sales, and customer service activities.

One of the newest RFID applications is called electronic proof of delivery

(EPOD). Using EPOD, a supplier uses RFID tags on each crate, case, or shipping unit
to create a digital shipping list. The customer receives the list and scans the
incoming shipment. If a discrepancy is detected, it is reported and adjusted
automatically. Because they would be expensive to investigate manually, small
shipping inconsistencies might not otherwise be traced. This is an example of
technology-related cost control.

Factors that Affect Systems Projects

1. Internal Factors
2. External Factors

CUSTOMERS Customers are vitally important to any business. Information systems

that interact with customers usually receive top priority. Many companies
implement customer relationshipmanagement (CRM) systems that integrate all
customer-related events and transactions, including marketing, sales, and customer
service activities.Vendor-oriented CRM systems often interconnect with supplier
relationship management (SRM) systems, which were discussed in Chapter 1. CRM
components can provide automated responses to sales inquiries,Web-based order
processing, and online inventory tracking. Because an efficient warehouse is just as
important as a successful Web site,suppliers use smart forklifts that can read RFID
tags or UPC numbers and transmit data to a CRM system, as shown in Figure 2-12.

One of the newest RFID applications is called electronic proof of delivery

(EPOD). Using EPOD, a supplier uses RFID tags on each crate, case, or shipping
unit to create a digital shipping list. The customer receives the list and scans the
incoming shipment. If a discrepancy is detected, it is reported and adjusted
automatically. Because they would be expensive to investigate manually, small
shipping inconsistencies might not otherwise be traced. This is an example of
technology-related cost control.

PROJECT MANAGEMENT
EVALUATION OF SYSTEMS REQUESTS
1. Systems Request Forms
2. Systems Review Committee
3. OVERVIEW OF FEASIBILITY
1. Operational Feasibility
2. Technical Feasibility
3. Economic Feasibility
4. Schedule Feasibility
Factors that Affect Priority
When assessing a project’s priority, a systems analyst should consider the
following:
• Will the proposed system reduce costs? Where? When? How? How much?
• Will the system increase revenue for the company? Where? When? How? How
much?
• Will the systems project result in more information or produce better results?
How? Are the results measurable?
• Will the system serve customers better?
• Will the system serve the organization better?
• Can the project be implemented in a reasonable time period? How long will the
results last?
• Are the necessary financial, human, and technical resources available?

Whenever possible, the analyst should evaluate a proposed project based on

tangible costs and benefits that represent actual (or approximate) dollar values. For
example, a reduction of $8,000 in network maintenance is an example of a tangible
benefit

Discretionary and Nondiscretionary Projects

Is the project absolutely necessary? Projects where management has a choice in
implementing them are called discretionary projects. Projects where no choice
exists are called nondiscretionary projects. Creating a new report for a user is an
example of a discretionary project; adding a report required by a new federal law is
an example of a nondiscretionary project.

Planning the Preliminary Investigation

Six steps in a preliminary investigation

Step 1: Understand the Problem or Opportunity

Fishbone diagram, or Ishikawa diagram,

Step 2: Define the Project Scope and Constraints

Some analysts find it helpful to define project scope by creating a list with
sections called Must Do, Should Do, Could Do, and Won’t Do.

Projects with very general scope definitions are at risk of expanding

gradually, without specific authorization, in a process called project creep.
To avoid this problem, you should define project scope as clearly as possible.
 You might want to use a graphical model that shows the systems, people,
and business processes that will be affected. The scope of the project also
establishes the boundaries of the preliminary investigation itself. A systems
analyst should limit the focus to the problem at hand and avoid unnecessary
expenditure of time and money.

PRESENT VERSUS FUTURE, INTERNAL VERSUS EXTERNAL, MANDATORY

VERSUS DESIRABLE,

Step 3: Perform Fact-Finding

3.1 ANALYZE ORGANIZATION CHARTS

3.2 CONDUCT INTERVIEWS

The primary method of obtaining information during the

preliminary investigation is the interview. The interviewing process
involves a series
of steps:
1. Determine the people to interview.
2. Establish objectives for the interview.
3. Develop interview questions.
4. Prepare for the interview.
5. Conduct the interview.
6. Document the interview.
7. Evaluate the interview.
3.3 REVIEW DOCUMENTATION
3.4 OBSERVE OPERATIONS
3.5 CONDUCT A USER SURVEY
3.6 ANALYZE THE DATA

“What else do
you think I should know about the system?” or “Is there any other relevant
information
that we have not discussed?”

Systems analysts use many techniques to locate the source of a

problem. For example, the Pareto chart is a widely used tool for visualizing issues
that need attention. Named for a nineteenth century economist, a Pareto chart is
drawn as a vertical bar graph, as

PROJECT MONITORING AND CONTROL

Monitoring and Control Techniques

Maintaining a Schedule
Maintaining a project schedule can be challenging, and most projects run into
at least some problems or delays. By monitoring and controlling the work, the
project manager tries to anticipate problems, avoid them or minimize their
impact, identify potential solutions, and select the best way to solve the
problem. The better the original plan, the easier it will be to control the
project. If clear, verifiable milestones exist, it will be simple to determine if
and when those targets are achieved. If enough milestones and frequent
checkpoints exist, problems will be detected rapidly. A project that is planned
and scheduled with PERT/CPM can be tracked and controlled using these
same techniques. As work continues, the project manager revises the plan to
record actual times for completed tasks and revises times for tasks that are
not yet finished. Project managers spend most of their time tracking the tasks
along the critical path, because delays in those tasks have the greatest
potential to delay or jeopardize the project. Other tasks cannot be ignored,
however. For example, suppose that a task not on the critical path takes too
long and depletes the allotted slack time. At that point, the task actually
becomes part of the critical path, and any further delay will push back the
overall project.

REPORTING
Project Status Meetings
Project Status Reports
A project is in trouble, but the project manager is reluctant to report the
problems.The case highlights important ethical issues that often arise in this
situation. A project manager must report regularly to his or her immediate
supervisor, upper management, and users. Although a progress report might
be given verbally to an immediate supervisor, reports to management and
users usually are written. Gantt charts often are included in progress reports
to show project status graphically. Deciding how to handle potential problems
can be difficult. At what point should you inform management about the
possibility of cost overruns, schedule delays, or technical problems? At one
extreme is the overly cautious project manager who alerts management to
every potential snag and slight delay. The danger here is that the manager
loses credibility over a period of time, and management might ignore
potentially serious situations. At the other extreme is the project manager
who tries to handle all situations single-handedly and does not alert
management until a problem is serious. By the time management learns of
the problem, little time might remain in which to react or devise a solution. A
project manager’s best course of action lies somewhere between the two
extremes, but is probably closer to the first. If you are unsure of the
consequences, you should be cautious and warn management about the
possibility of a problem. When you report the situation, you also should
explain what you are doing to handle and monitor the problem. If you believe
the situation is beyond your control, you might want to suggest possible
actions that management can take to resolve the situation. Most managers
 recognize that problems do occur on most projects; it is better to alert
management sooner rather than later.

Work Breakdown Structure

GANTT Chart
Network Diagram

MANAGING FOR SUCCESS

Business Issues
The major objective of every system is to provide a solution to a business problem
or
opportunity. If the system does not do this, then it is a failure — regardless of
positive
reaction from users, acceptable budget performance, or timely delivery. When the
information
system does not meet business requirements, causes might include unidentified
or unclear requirements, inadequately defined scope, imprecise targets, shortcuts
or
sloppy work during systems analysis, poor design choices, insufficient testing or
inadequate
testing procedures, and lack of change control procedures. Systems also fail
because of changes in the organization’s culture, funding, or objectives. A system
that
falls short of business needs also produces problems for users and reduces
employee
morale and productivity.
As you learned in Chapter 2, projects without clear scope definitions are risky,
because they tend to expand gradually, without specific authorization, in a process
called project creep. However, even when a project is clearly described, it must be
managed
constantly

Budget Issues
Schedule Issues

CHAPTER 4 - Requirements Modelling

JAD Model
JAD Advantages and Disadvantages
Compared with traditional methods, JAD is more expensive and can be cumbersome
if
the group is too large relative to the size of the project. Many companies find,
however,
that JAD allows key users to participate effectively in the requirements modeling
process.
When users participate in the systems development process, they are more likely to
feel a
sense of ownership in the results, and support for the new system. When properly
used,
JAD can result in a more accurate statement of system requirements, a better
understanding
of common goals, and a stronger commitment to the success of the new
system.
RAD Model

Rapid application development (RAD) is a team-based technique that speeds up

information systems development and produces a functioning information system.
Like JAD, RAD uses a group approach, but goes much further. While the end product
of JAD is a requirements model, the end product of RAD is the new information
system.
RAD is a complete methodology, with a four-phase life cycle that parallels the
traditional SDLC phases. Companies use RAD to reduce cost and development
time,
and increase the probability of success.

RAD relies heavily on prototyping and user involvement. The RAD process
allows
users to examine a working model as early as possible, determine if it meets their
needs,
and suggest necessary changes. Based on user input, the prototype is modified and
the
interactive process continues until the system is completely developed and users
are satisfied.
The project team uses CASE tools to build the prototypes and create a continuous
stream of documentation.

RAD Phases and Activities

The RAD model consists of four phases: requirements planning, user design,
construction,
and cutover, as shown in Figure 4-5. Notice the continuous interaction between
the
user design and construction phases.

Cutover Tasks
• Data conversion
• Full-scale testing
• System changeover
• User training

CUTOVER The cutover phase resembles the final tasks in the SDLC
implementation
phase, including data conversion, testing, changeover to the new system, and user
training.
Compared with traditional methods, the entire process is compressed. As a result,
the new system is built, delivered, and placed in operation much sooner.
 Agile Model

Systems Requirement Checklist

1. System requirements fall into five general categories: outputs, inputs,

processes, performance, and controls. Typical examples of system
requirements for each category are listed below.
Output Examples
Input Examples
Process Examples
Performance Examples
Control Examples

FUTURE GROWTH, COSTS, AND BENEFITS

In addition to the system requirements, systems analysts must consider
scalability, which determines how a system will handle future growth and
demands, and the total cost of ownership, which includes all future operational
and support costs.

SYSTEMS DEVELOPMENT METHODS

Structured Analysis
Object-Oriented Analysis
Agile Methods

FACT FINDING TOOLS

LOGICAL MODEL

Data and process modeling involves three

main tools:
data flow diagrams, a data dictionary, and process descriptions.

DFD
Rules and Regulations to follow while developing DFD
1. Context Diagram
2. DFD
1. Diagram 1, 2 .. etc
 Process
Functional Primitive Process
When you create a set of DFDs for a system, you break the
processing logic down into smaller units, called functional
primitives, that programmers will use to develop code. A
functional primitive is a process that consists of a single
function that is not exploded further.
Levelling
Levelling is also called as Exploding, Partitioning,
Decomposing
Balancing

External Entities
Data Links
Data Stores

Data Dictionary

Process Description Tools

1. Modular Design
2. Structured English
3. Decision Tables
4. Decision Trees

LOGICAL VERSUS PHYSICAL MODELS

Sequence of Models
Four-Model Approach

LOGICAL MODEL

COSTS and BENEFITS ANALYSIS

Cost Classifications
Benefit classifications
Request for Proposal OR Request for Quotation