0% found this document useful (0 votes)
50 views24 pages

Chapter 3

Uploaded by

panhra
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
50 views24 pages

Chapter 3

Uploaded by

panhra
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd

Build Bright University Systems Analysis and Design

(Chapter
(Chapter 3)
3)
SYSTEMS
SYSTEMS ANALYSIS
ANALYSIS (Phase-2)
(Phase-2) ~~ PART
PART 11
-- Requirements
Requirements Modelling
Modelling

 Systems Analysis Phase Overview

 Systems Requirements Checklist

 Fact-Finding techniques

 JAD

 Documentation

Slide 3-1
Build Bright University Systems Analysis and Design

Systems Analysis Phase Overview

The systems analysis


phase includes the four
activities: requirements
modeling, data and
process modeling,
object modeling, and
the transition to
systems design.

Slide 3-2
Build Bright University Systems Analysis and Design

Systems Requirement Checklist

System requirements fall into five general categories:


outputs, inputs, processes, performance, and controls.
Typical examples of system requirements are:

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, and unit cost of all parts – sorted by part number.

Slide 3-3
Build Bright University Systems Analysis and Design

Inputs
• The department head must enter overtime hours on
a separate screen.
• Each input form must include date, time, product code,
customer number, and quantity.

Processes
• The human resources system must interface properly
with the existing payroll system.
• The student records system must allow record access
by either the student name or the student number.

Slide 3-4
Build Bright University Systems Analysis and Design

Performance
• Response time must not exceed four seconds.
• The system must be operational 7 days a week, 365
days a year.

Controls
• 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.

Slide 3-5
Build Bright University Systems Analysis and Design

Fact-Finding

In order to identify the information you need, you begin


by asking a series of questions, such as: What business
functions are supported by the current system? What
business requirements must be supported by the new
system? What are the benefits and costs of the proposed
system? What transactions will the system process? What
information do users and managers need from the system?
Must the new system interface with legacy system? What
procedures could be eliminated by business process
reengineering? What security issues exists? What risks
are acceptable? What budget and timetable constraints
will affect system development?

Slide 3-6
Build Bright University Systems Analysis and Design

Fact-Finding

WHO, WHAT, WHEN, WHERE AND HOW?


Fact-finding involves answers to five familiar questions:
who, what, when, where, and how.

1. Who? Who performs each of the procedures within


the system?
2. What? What is being done?
3. Where? Where are operations being performed?
4. When? When is a procedure performed?
5. How? How is a procedure performed?

Slide 3-7
Build Bright University Systems Analysis and Design

Fact-Finding Techniques

Interviews
The interviewing process consists of these seven steps:

1. Determine the people to interview.


2. Establish objectives for the interview.
3. Develop interview questions. (open-ended and
closed-ended)
4. Prepare for the interview. (location of interview)
5. Conduct the interview.
6. Document the interview.
7. Evaluate the interview.

Slide 3-8
Build Bright University Systems Analysis and Design

Document Review
Obtain copies of actual forms and operating documents
currently in use. Review blank copies of forms, as well
as samples of actual completed forms.

Observation
Personal observation also allows you to verify
statements made in interviews and determine whether
procedures really operate as they are described.

Questionnaires and Surveys


A questionnaire, also called a survey, is a document
containing a number of standard questions that can be
sent to many individuals.

Slide 3-9
Build Bright University Systems Analysis and Design

Sampling
The samples include records, reports, operational logs,
data entry documents, complaint summaries, work
requests, and various types of forms. Sampling
techniques include systematic sampling, stratified
sampling, and random sampling.

Slide 3-10
Build Bright University Systems Analysis and Design

Interviews vs. Questionnaires

(Advantages of Interview)
• More familiar and personal.
• React immediately to anything the interviewee says.
• Watch for clues to determine if responses are
knowledgeable and unbiased.
• Improved human relations.

(Disadvantages of Interview)
• Costly and time-consuming process.
• Preparation and follow-up work is required.

Slide 3-11
Build Bright University Systems Analysis and Design

(Advantages of Questionnaires)
• Opportunity to provide input and suggestions.
• Recipients can answer questions at their convenience.
• Allows anonymous responses.

(Disadvantages of Questionnaires)
• Preparing a good questionnaire requires skill and time.
• Question can be misinterpreted.
• Recipients might view them as time-consuming, and
impersonal.

Slide 3-12
Build Bright University Systems Analysis and Design

Joint Application Development

Joint Application Development or Joint Application


Design (JAD) is an information-gathering techniques that
allows the users, manager, and IT staff to work together to
identify requirements for the system.

JAD Setting
 U-shaped seating
 Away from distractions
 Whiteboard/flip chart
 CASE tools

Slide 3-13
Build Bright University Systems Analysis and Design

JAD Meeting Room


Slide 3-14
Build Bright University Systems Analysis and Design

Typical JAD Participants and Roles


Participations Roles
JAD project Develops an agenda, acts as a facilitator,
leader and leads the JAD session.
Top Provides enterprise-level authorization
management and support for the project.
Managers Provide department-level support for the
project and understand how the project
must support business functions and
requirements.

Slide 3-15
Build Bright University Systems Analysis and Design

Users Provide operational-level input on


current operations, desired changes,
input and output requirements, user
interface issues, and how the project will
support day-to-day tasks.
Systems Provide technical assistance and
analysts and resources for JAD team members on
other IT staff issues such as security, backup,
members hardware, software, and network
capability.
Recorder Documents results of JAD sessions and
(scribe) works with systems analysts to build
system models and develop CASE tool
documentation.

Slide 3-16
Build Bright University Systems Analysis and Design

Typical JAD Agenda


JAD project • Introduce all JAD team members.
leader • Discuss ground rules, goals, and
objectives for the JAD sessions.
• Explain methods of documentation and
use of CASE tools, if any.
Top • Explain the reason for the project and
management express top management authorization
(sometimes and support.
called the
project owner or
sponsor)

Slide 3-17
Build Bright University Systems Analysis and Design

Project leader • Provide overview of the current system


and proposed project scope and
constraints.
• Present outline of specific topics and
issues to be investigated.
Open discussion • Review the main business processes,
session, tasks, user roles, input and output.
moderated by • Identify specific areas of agreement or
project leader
disagreement.
• Break team into smaller groups to
study specific issues and assign group
leaders.
Slide 3-18
Build Bright University Systems Analysis and Design

JAD team • Discuss and document all system


members requirements.
working in • Develop models and prototypes.
smaller group
sessions,
supported by IT
staff
Group leaders • Report on results and assigned tasks
and topics.
• Present issues that should be addressed
by the overall JAD team.

Slide 3-19
Build Bright University Systems Analysis and Design

Open discussion • Review reports from small group


session, sessions.
moderated by • Reach consensus on main issues.
project leader
• Document all topics.
Project leader • Present recap of JAD sessions.
• Prepare report that will be sent to JAD
team members.

Slide 3-20
Build Bright University Systems Analysis and Design

Managing Problems in JAD Sessions


 Reducing domination
 Encouraging non-contributors
 Side discussions
 Agenda merry-go-round
 Violent agreement
 Unresolved conflict
 True conflict
 Use humor

Slide 3-21
Build Bright University Systems Analysis and Design

The Need for Recording the Facts

You should document your work according to the


following principles:

• Record information as soon as you obtain it.


• Use the simplest recording method possible.
• Record your findings in such a way that they can be
understood by someone else.
• Organise your documentation so related material is
located easily.

Slide 3-22
Build Bright University Systems Analysis and Design

Software Tools

Many software programs are available to help you


record and document information. Some examples are:

Case Tools
You can use CASE tools at every stage of systems
development.

Word Processing
Create reports, summaries, tables, and forms.

Spreadsheets
Track and manage numerical data or financial
information.
Slide 3-23
Build Bright University Systems Analysis and Design

Databases
Manage information about events, observations, and
samples.

Presentation Graphics
Organizing and developing your formal presentation.

Slide 3-24

You might also like