2012 Chap 03 Requirement Analysis

Chapter 3 Requirement Analysis
fig_01_03
Outline
Analysis
Requirements determination
Requirements analysis techniques Requirements-gathering techniques
Key Definitions
SDLC is the process by which the organization
moves from the current system to the new system.

The As-Is system is the current system and may or
may not be computerized The To-Be system is the new system that is based on updated requirements
The System Proposal is the key deliverable from
the Analysis Phase or the outcome of the analysis phase.

PowerPoint Presentation for Dennis, Wixom, & Roth Systems Analysis and Design, 4th Edition Copyright 2009 John Wiley & Sons, Inc. All rights reserved.
3-4
Analysis
Analysis refers to breaking a whole into its
parts with the intent of understanding the parts nature, function, and interrelationship.
focuses on capturing the business requirements for
the system. Identifies the what of the system Leads directly into the design phase (how of the system)
The goals of the analysis phase: To understand the requirements of the new system and To develop a system that addresses them -- or decide a new system isnt needed.
Analysis
Deliverables: requirements definition, use cases,
process models, and data model All deliverables are combined into a system proposal (key deliverables), and submitted to the approval committee for decision, whether or not to move ahead with the project.
The System Proposal is presented to the
approval committee via a system walkthrough.

Walk-through is a meeting at which the concept
for the new system is presented to the users, managers, and key decision makers.
Analysis
Systems analysis incorporates initial systems
design.
The line between the analysis and design phases is
very blurry: the deliverables created in the analysis phase are really the first step in the design of the new system.
Requirements determination is the single
most critical step of the entire SDLC. It is here that the major elements of the system first begin to emerge.
3-7
Requirements Determination
What is a requirement?
Requirements definition
Determining requirements Creating the requirements definition
From System Request to Requirements
This is a part of analysis in which the project team
turns the very high level explanation of the business requirements stated in the system request into a more precise list of requirements.
What is a requirement?
Requirements a document that lists the new
systems capabilities.
A statement of what the system must do or what
characteristics it needs to have.

Business requirements describe the what of the
system. System requirements describe how the system
Functional Requirement
a process the system
Nonfunctional Requirements
refer to behavioral properties
has to perform ex. the

ability to search for available inventory, access to the customer order system
information it needs to
or characteristics that the system must have, such as performance and usability --examples:
contain ex. the system must

include actual and budgeted expenses
The ability to access the system through a web browser
define the functions
used in the design phase
that the system needs to have flow directly into the

next steps of the analysis process (use cases, process models, data model)
when decisions are made about the user interface, the hardware and software, and the systems underlying architecture.
Requirements Definition Requirements definition report
Text report that lists the functional and nonfunctional
requirements in an outline form Priorities may be included, can be ranked as high, medium, or low
Obvious purpose:
To provide the information needed by other deliverables
in the analysis phase, which include use case, process models, and data models To support activities in the design phase
Key purpose is to define the project scope: what is
and is not to be included.

Serves to establish the users expectations for the
3 - 13
system Serves as a resource for clarification
Requirements Determination:
Determining Requirements
Participation by business users is essential
Both businesspeople and analysts working together
to determine business requirements

Three techniques (based on the degree of
change anticipated in the to-be system) help users discover their needs for the new system:
Business Process Automation (BPA) Business Process Improvement (BPI) Business Process Reengineering (BPR)
3 - 14
Requirements Determination:
Determining Requirements The requirements analysis strategy:
Understand the As-Is system Identify improvement opportunities Develop the To-Be system concept
Techniques vary in amount of change BPA small change BPI moderate change BPR significant change Additional information gathering techniques
are needed as well like: interviews, questionnaires, observation, JAD, and document analysis. PowerPoint Presentation for Dennis, Wixom, &
3 - 15 Roth Systems Analysis and Design, 4th Edition Copyright 2009 John Wiley & Sons, Inc. All rights reserved.
Requirements Determination: Creating the requirements definition

How to create the requirements definition:
Determines the kinds of functional and non-
functional requirements Use a variety of requirement-gathering technique The analysts work with the entire project team and business users---to verify, change, and complete the list and help prioritize the important requirements
Requirements Analysis Techniques

How to analyze requirements:
Business process automation Business process improvement Business process reengineering
Comparing analysis techniques

The basis process of analysis is divided into three
(3) steps:
Understanding the as-is system skipped when no
current system exists Identifying improvements identifying the needs of the new system Developing requirements for the to-be system
To move the users from here to there, an
analyst needs strong critical thinking skills. Critical thinking is the ability to recognize strengths and weaknesses and recast an idea in an improved form.
needed in order for the analyst to understand issues
and develop new business processes

How to analyze requirements: Three
requirement analysis techniques which help the analyst lead users through the three (or two) analysis steps so that the vision of the of the business can be developed:
BPA means keeping basic business operations
intact while incorporating computer technology to do some of the work BPI means making moderate changes to the way in which the organization operates to take advantage of new opportunities offered by technology or to copy what competitors are doing. BPR means changing the fundamental way in which organization operates.
Requirements Analysis Techniques: Business Process Automation

identify possible problems in the current system
Improve organizational efficiency or ease of use

Minor improvements - The least impact and value
for the business Two popular activities:

Problem analysis Root cause analysis
Requirements Analysis Techniques: Business Process Automation

Two popular activities: Problem analysis the ideas produced tend to
be solutions to problems.
Address a symptom of the problem, not the true
problem or root cause itself means asking the users and managers:
to identify problems with the as-is system and to describe how to solve them in the to-be system.
Root cause analysis focuses on problems first
rather than solutions

The true problem and not just symptoms of
problems and solve that
Requirements Analysis Techniques: Business Process Improvement

Moderate changes take advantage of new
opportunities offered by technology or copy what competitors are doing. Improve efficiency (doing things right) and improve effectiveness (doing the right things) Focus on improving business processes Three popular activities:
Duration analysis
Activity-based costing
Informal benchmarking
Requirements Analysis Techniques: Business Process Improvement

Three popular activities:
Duration analysis examines the time to perform
each process in the current as-is system. Activity-based costing examines the cost of each major process or step in a business process. Informal benchmarking is fairly common for customer-facing business processes
Benchmarking refers to studying how other organization
perform a business process in order to learn how your organization can do something better. By visiting the website or place of your competitor, by joining the forum to ask questions
Requirements Analysis Techniques: Business Process Reengineering

Changing the fundamental way of doing business
Making major changes to take advantage of new
ideas and new technology Allot little time to understanding the as-is system focus on new ideas and new ways of doing business Three popular activities:
Outcome analysis Technology analysis
Activity elimination
Requirements Analysis Techniques: Business Process Reengineering

Three popular activities:
Outcome analysis focuses on understanding the
fundamental outcomes that provide value to customers.

The system analysts encourage the managers and project
sponsor to pretend that they are customers and to think carefully about: What the products or services enable to do What they could enable to do
Technology analysis starts by having the analyst and
managers develop a list of important and interesting technologies. Activity elimination the analysts and managers work together to identify:
How to eliminate each and every activity in the business
process How the function could operate without it
Comparing Analysis Technique: Potential Business Value

BPA
-Potential Business Value: Have the potential to improve the business; Benefits in projects are tactical and small in nature; Do not change the business processes, only process efficiency can be improved -Project cost: lowest cost -Breadth of analysis: examine a single
BPI
-Potential Business Value: Offer moderate potential benefits; both efficiency and effectiveness can be increased; -Project cost: moderately expensive -Breadth of analysis: much narrower scope that includes one or several business function
Breadth of analysis scope of analysis
BPR
-Potential Business Value: Create large potential benefits -Improve the nature of the business or redesigning of the business process -Project cost: expensive -Breadth of analysis: broad perspective, spanning several major business processes, even across multiple organizations
fig_03_05
Requirements Analysis Techniques: Risk

Risk of failure the likelihood of failure, due to:
Poor design Unmet needs Too much change for the organization to handle
BPA and BPI have low to moderate risk BPR less predictable, extremely risky Mike Hammer, the father of BPR, estimates that
70% of BPR projects fail.
Requirements-Gathering Techniques
An analyst is very much like a detective (and
business users sometimes are like elusive suspects).

Look for clues that uncover the solution to the
problem Not obvious---needs to notice details, talk with witnesses, and follow leads Gather requirements by a variety of techniques
Requirements-Gathering Techniques
How to gather requirements: Requirements-
gathering in practice
Interviews Joint application development sessions Questionnaires
Document analysis
Observation
Assignments:
Read all the topics
under requirementsgathering techniques. To be included in your prelim exam on Tuesday, January 8, 2013.
Interviews
Interviews involve meeting one or more people
and asking then questions. Most commonly used technique

Ex. How the system works?
There are 5 basic steps to the interview process:

Selecting interviewees Designing interview questions Preparing for the interview
Conducting the interview

Post-interview follow-up
Selecting Interviewees
Based on information needs
Best to get different perspectives

Managers Users Ideally, all key stakeholders
Keep organizational politics in mind
3 - 33
PowerPoint Presentation for Dennis, Wixom, & Roth Systems Analysis and Design, 4th Edition Copyright 2009 John Wiley & Sons, Inc. All rights
Three Types of Questions
3 - 34
Designing Interview Questions

Unstructured interview useful early in information
gathering
Goal is broad, roughly defined information
Structured interview useful later in process

Goal is very specific information
3 - 35
Top-Down and Bottom-up Questioning Strategies
3 - 36
Preparing for the Interview

Prepare general interview plan List of question Anticipated answers and follow-ups Confirm areas of knowledge Set priorities in case of time shortage Prepare the interviewee Schedule Inform of reason for interview Inform of areas of discussion
3 - 37
Conducting the Interview

Appear professional and unbiased
Record all information

Check on organizational policy regarding tape
recording Be sure you understand all issues and terms Separate facts from opinions Give interviewee time to ask questions Be sure to thank the interviewee End on time
3 - 38 PowerPoint Presentation for Dennis, Wixom, & Roth Systems Analysis and Design, 4th Edition Copyright 2009 John Wiley & Sons, Inc. All rights
Post-Interview Follow-Up
Prepare interview notes
Prepare interview report

Have interviewee review and confirm interview
report Look for gaps and new questions
3 - 39
Joint Application Development (JAD)

A structured group process focused on
determining requirements Involves project team, users, and management working together to identify requirements for the system. May reduce scope creep by 50% Very useful technique
3 - 40
JAD Participants
Facilitator
Trained in JAD techniques

Sets agenda and guides group processes Scribe(s)
Record content of JAD sessions

Users and managers from business area
with broad and detailed knowledge

3 - 41
Preparing for the JAD Sessions

Time commitment day to several weeks
Strong management support is needed to release
key participants from their usual responsibilities Careful planning is essential e-JAD can help alleviate some problems inherent with groups
3 - 42
JAD Meeting Room
3 - 43
Conducting the JAD Session

Formal agenda and ground rules Top-down structure most successful Facilitator activities

Keep session on track Help with technical terms and jargon Record group input Stay neutral, but help resolve issues
Post-session follow-up report

3 - 44
Post JAD Follow-up

Postsession report is prepared and circulated
among session attendees The report should be completed approximately a week to two after the JAD session
3 - 45
Questionnaires
A set of written questions, often sent to a large
number of people May be paper-based or electronic Select participants using samples of the population Design the questions for clarity and ease of analysis Administer the questionnaire and take steps to get a good response rate Questionnaire follow-up report PowerPoint Presentation for
3 - 46 Dennis, Wixom, & Roth Systems Analysis and Design, 4th Edition Copyright 2009 John Wiley & Sons, Inc. All rights
Good Questionnaire Design
3 - 47
Document Analysis
entails reviewing the existing documentation and
examining the system itself. It can provide insights into the formal and informal system. Study of existing material describing the current system Forms, reports, policy manuals, organization charts describe the formal system Look for the informal system in user additions to forms/report and unused form/report elements PowerPoint Presentation for Dennis, Wixom, & Roth User changes to existing forms/reports or nonSystems Analysis and 3 - 48 Design, 4th Edition use of existing forms/reports suggest the system Copyright 2009 John
Wiley & Sons, Inc. All rights
Observation
Watch processes being performed
powerful tool for gathering information about the
as-is system because it enables the analyst to see the reality of a situation firsthand. Users/managers often dont accurately recall everything they do Checks validity of information gathered other ways Be aware that behaviors change when people PowerPoint Presentation for Dennis, Wixom, & Roth are watched Systems Analysis and 3 - 49 Design, 4th Edition Be unobtrusive (low profile, modest) Copyright 2009 John
Wiley & Sons, Inc. All rights
Selecting the Appropriate RequirementsGathering Techniques Type of information Depth of information Breadth of information Integration of information User involvement Cost Combining techniques
3 - 50
Summary
The analysis process focuses on capturing
the business requirements for the system Functional and non-functional business requirements tell what the system must do Three main requirements analysis techniques are BPA, BPI, and BPR These techniques vary in potential business value, but also in potential cost and risk
3 - 51
Summary, continued
There are five major requirements-
gathering techniques that all systems analysts must be able to use: Interviews, JAD, Questionnaires, Document Analysis, and Observation. Systems analysts must also know how and when to use each as well as how to combine methods.
3 - 52 PowerPoint Presentation for Dennis, Wixom, & Roth Systems Analysis and Design, 4th Edition Copyright 2009 John Wiley & Sons, Inc. All rights
QUIZ

2012 Chap 03 Requirement Analysis

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

2012 Chap 03 Requirement Analysis

Uploaded by

Copyright:

Available Formats

Chapter 3 Requirement Analysis

moves from the current system to the new system.

the Analysis Phase or the outcome of the analysis phase.

approval committee via a system walkthrough.

characteristics it needs to have.

system. System requirements describe how the system

refer to behavioral properties

has to perform ex. the

contain ex. the system must

The ability to access the system through a web browser

define the functions

used in the design phase

that the system needs to have flow directly into the

and is not to be included.

system Serves as a resource for clarification

to determine business requirements

Requirements Determination: Creating the requirements definition

Requirements Analysis Techniques

Comparing analysis techniques

Requirements Analysis Techniques

and develop new business processes

Requirements Analysis Techniques

Requirements Analysis Techniques: Business Process Automation

Improve organizational efficiency or ease of use

for the business Two popular activities:

Requirements Analysis Techniques: Business Process Automation

Root cause analysis focuses on problems first

rather than solutions

problems and solve that

Requirements Analysis Techniques: Business Process Improvement

Requirements Analysis Techniques: Business Process Improvement

Requirements Analysis Techniques: Business Process Reengineering

Making major changes to take advantage of new

Requirements Analysis Techniques: Business Process Reengineering

fundamental outcomes that provide value to customers.

Technology analysis starts by having the analyst and

process How the function could operate without it

Comparing Analysis Technique: Potential Business Value

Requirements Analysis Techniques: Risk

70% of BPR projects fail.

business users sometimes are like elusive suspects).

and asking then questions. Most commonly used technique

There are 5 basic steps to the interview process:

Conducting the interview

Best to get different perspectives

Keep organizational politics in mind

Three Types of Questions

Designing Interview Questions

Structured interview useful later in process

Top-Down and Bottom-up Questioning Strategies

Preparing for the Interview

Conducting the Interview

Record all information

Prepare interview report

report Look for gaps and new questions

Joint Application Development (JAD)

Trained in JAD techniques

Record content of JAD sessions

with broad and detailed knowledge

Preparing for the JAD Sessions

Strong management support is needed to release

JAD Meeting Room

Conducting the JAD Session

Post-session follow-up report