TOPIC 3

REQUIREMENT
A N A LY S I S

A N A L I S I S DA N P E R A N CA N GA N S I S T E M I N F O R M A S I
CSIM603183
Learning Objectives
1. Able to create and define a requirement in IS project
2. Able to explain the various technique for requirement analysis in IS
project
3. Able to apply the various technique for requirement analysis in IS
project
4. Able to explain the utilization of requirement analysis technique in
IS project
5. Able to explain how to do requirements-gathering by using interview,
JAD, questionnaires, document analysis, and observation in an IS project
6. Able to explain the utilization of each requirements-gathering
technique
Session Outline
1. Requirement Determination
2. Requirement Analysis Strategies
3. Requirement Gathering Techniques
4. The System Proposal
 1.1
REQUIREMENT
D ET E R M I N AT I O N
Key Ideas
• The As-Is system is the current system and may or may not be
computerized
– Get as clear as possible the existing system
• The To-Be system is the new system that is based on updated
requirements
– Show that to-be system is much better than as-is system
• The System Proposal is the key deliverable from the Analysis Phase
– It’s a proposed logical information systems: functional and non-functional
requirements
Key Ideas
• The goal of the analysis phase is to truly understand the requirements of the new
system and develop a system that addresses them – or decide a new system isn’t
needed
• The System Proposal is presented to the approval committee
• The first challenge is finding the right people to participate.
• The second challenge is collecting and integrating the information.
• Requirement determination is the critical step in the SDLC
– The purpose of requirement determination is to turn the very high level
explanation of the business requirements stated in the system request into a
more precise list of requirement that can be used as inputs to the rest of
analysis (creating functional. structural, and behavioral model).
A Requirement
• A statement of what the system must do
• A statement of characteristics the system must have
• Focus is on business user needs during analysis phase  business
requirement
• Requirements will change over time as project moves from analysis
to design to implementation
– So, be aware of project scope creep due to the requirements
change.
What is the differences between
requirement in analysis phase and design
phase?
User (business person) perspectives VS Developer perspectives

User, Clients System Analyst Programmer, Developer

Business Analyst, Logical Req. Technical Analyst

Requirement Types
1. Functional Requirements: relates to a process or data
– A process the system has to perform
– Information the system must contain
– Focus on functionality of features
2. Nonfunctional Requirements: relates to performance or usability
– Behavioral properties the system must consider
• Operational
• Performance
• Security
• Cultural and political aspects
– Nonfunctional requirements can influence functional, structural, and
behavioral model
Example of Functional and Non-Functional
Requirements
Non-Functional Requirements
Requirement type Example
Operational • The system should be able to fit in a pocket or purse
• The system should be able to integrate with the existing inventory
system.
Performance • Any interaction between the user and the system should not exceed
2 seconds.
• The system should receive updated inventory information every 15
minutes.
Security • Only direct managers can see personnel records of staff
• Customers can see their order history only during business hours.
Cultural & Political • The system should be able to distinguish between United States and
European currency
• The system shall comply with insurance industry standards.
Documenting Requirements
• Requirements definition report
– Text document listing requirements in outline form
– Priorities may be included
• Key purpose is to define the project scope: what is and is not
to be included.
• Your accountability and responsibility to the IS Project is proven
by this documentation.
Documenting Requirements
• Requirements definition report
– Text document listing requirements in outline form
– Priorities may be included
• Key purpose is to define the project scope: what is and is not
to be included.
• Your accountability and responsibility to the IS Project is proven
by this documentation.
Purposes of
a requirements specification documents
A requirements specification document is used by many
different stakeholder for different purposes:
1. Customer - part of a formal contract
2. Manager - basis for the project plan
3. Developer - basis for the design and implementation
4. Tester - document to test the system against
5. Maintainer - starting point for understanding the system
Determining Requirements
• Participation by business users/experts and IT analyst is
essential
– If done only by IT analyst, may not address true business needs
– If done only by business experts, may not take advantage of technology 
simply automate an existing systems
• Three techniques help users discover their needs for the new
system:
1. Business Process Automation (BPA)
2. Business Process Improvement (BPI)
3. Business Process Reengineering (BPR)
Basic Process of Analysis
(Determining Requirements)
1. Understand the “As-Is” system
2. Identify improvement opportunities
3. Develop the “To-Be” system concept

• Techniques vary in amount of change

– BPA (Business Process Automation) – small change
– BPI (Business Process Improvement) – moderate change
– BPR ((Business Process Reengineering) – significant change
• Additional information gathering techniques are needed as well
Requirement Definition
• Creating a requirements definition is an iterative and ongoing process.
• However, the evolution of the requirements definition must be carefully
managed  scope creep
• Real-world problem with requirement determination:
1) Access to the correct set of users to uncover the complete set of
requirements
2) Specification of the requirements may be inadequate
3) Some requirements are simply unknowable at the beginning of a
development process
4) Verifying and validating of requirements can be very difficult
 1.2
REQUIREMENT
A N A LY S I S
TECHNIQUES
Discovering Needs of New Systems
1. Business Process Automation
2. Business Process Improvement
3. Business Process Reengineering
Business Process Automation
Characteristics:
• Doesn’t change basic operations
• Automates some operations

Goal: Efficiency for users

What are the negative and positive

impacts of BPA?
Business Process Automation
Pros: Cons:
– Quick wins (unless processes are – Only small efficiency gains are
extremely complex) realized
– Less culture shock – Automating non-value add
– Reduce human error processes

– Start collecting process metrics – Missed opportunity to optimize

baselines to analyze future process work flow
improvements – May never get A chance to
– Reduce paper, fax, emails, etc. improve processes
Business Process Improvement

• Changes how an organization operates

• Changes operation with new techniques (i.e., take advantage of
new opportunities offered by technology)
• Can improve efficiency (i.e., doing things right)
• Can improve effectiveness (i.e., doing the right things)
• More focus on to-be system for improvement (i.e., less on as-is
system than BPA)
Business Process Improvement
Goal: Efficiency and effectiveness for
users

What are the negative and positive

impacts of BPI?
Business Process Improvement
• Pros • Cons
– Reduce or eliminate waste – Potential culture shock issues
– Potential huge return on – Requires more executive support
investment – More expensive to implement
– Improve employee performance – Requires more attention to change
and customer experience management
– Reduce complexity of systems
– Financial justification of process
steps
Requirement Analysis Strategy in Identifying
Improvement
1. Problem Analysis
2. Root-Cause Analysis
3. Duration Analysis
4. Activity Based Costing
5. Informal Benchmarking
6. Outcome Analysis
7. Technology Analysis
8. Activity Elimination
Problem Analysis & Root Cause Analysis
• Problem Analysis
– Identify problems with as-is system and to describe how to solve
them in the to-be system  Ask users to identify problems and
solutions
– Improvements tend to be small and incremental
– Rarely finds improvements with significant business value
• Root Cause Analysis
– Challenge assumptions about why problem exists
– Trace symptoms to their causes to discover the “real” problem
– Identify the root causes of problems rather than symptoms of
problems
Root Cause Analysis Example
Duration Analysis
• Calculate time needed for each process step
• Calculate time needed for overall process
• Compare the two – a large difference indicates a badly
fragmented process
• Potential solutions:
– Process integration – change the process to use fewer people, each with
broader responsibilities
– Parallelization – change the process so that individual step are performed
simultaneously
Activity-Based Costing
• Examine the cost of each major process or step in a business
process rather than time taken.
• Calculate cost of each process step
• Consider both direct and indirect costs
• Identify most costly steps and focus improvement efforts on
them
Informal Benchmarking
• Studying how other organizations perform the same business
process
• Helps the organization by introducing ideas that employees may
never have considered but that have the potential added value.
• Common for customer-facing processes
• Interact with other business’ processes as if you are a customer
Outcome Analysis
• Consider desirable outcomes from customers’ perspective.
• System analysts encourage the managers and project sponsor to
pretend they are customers and consider what the organization
could enable the customer to do
Technology Analysis
• Analysts list important and interesting technologies
• Managers list important and interesting technologies
• The group identifies how each might be applied to the business
and how the business might benefit
Activity Elimination
• Identify what would happen if each organizational activity were
eliminated
• Use “force-fit” to test all possibilities
Comparing Analysis Techniques
1. Potential business value
2. Project cost
3. Breadth of analysis
4. Risk
Project Characteristics
Your Turn 
For the plan web system, what type of requirements are
those:
1. Be accessible to web users
2. Include the company logo
3. Provide management reports
4. Includes pictures of the plants
5. Print the page
6. Restricts access to profitability information
Your Turn 
 How do you know whether to use business process
automation, business process improvement, or business
process reengineering?
 Provide two examples.
 1.3
REQUIREMENTS
- G AT H E R I N G
TECHNIQUES
Requirement Gathering Techniques
1. Interviews
2. JAD
3. Questionnaires
4. Document Analysis
5. Observation
Interview
• Most commonly used technique
• Basic steps:
1. Selecting Interviewees
2. Designing Interview Questions (instrument development)
3. Preparing for the Interview
4. Conducting the Interview
5. Post-Interview Follow-up
Interview: Selecting Interviewees
• Based on information needed
• Create interview schedule and the purpose of the interview
• Often good to get different perspectives
– Managers
– Users
– Ideally, all key stakeholders
• People at different levels of the organization have varying perspectives on the
systems.
– Gain both high-level and low-level perspectives on an issue
Interview: Three Types of Questions
Types of Questions Examples
Closed-Ended Questions • How many telephone
orders are received per day?
• How do customers place orders?
• What additional information
would you like the new system
to provide?

• What do you think about the

Open-Ended Questions current system?
• What are some of the problems
you face on a daily basis?
• How do you decide what types of
marketing campaign to run?

• Why?
Probing Questions • Can you give me an example?
• Can you explain that in a bit
more detail?
Interview: Designing Interview Questions
• Unstructured interview
– Broad, roughly defined information
– At the earlier stage of the project
• Structured interview
– More specific information
– At the later stage of the project
Interview: Designing Interview Questions
Interview: Preparation Steps
• 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
Interview: 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
Interview: Conducting the Interview
• Don’t worry, be happy
• Pay attention
• Summarize key points
• Be succinct
• Be honest
• Watch body language
Interview: Post-Interview Follow-Up
• Prepare interview notes
• Prepare interview report
• Have interviewee review and confirm interview report
• Look for gaps and new questions
Interview Report
INTERVIEW REPORT

Interview notes approved by: ____________

Person interviewed ______________

Interviewer _______________
Date _______________
Primary Purpose:

Summary of Interview:

Open Items:

Detailed Notes:
Your Turn 
• You are interviewing the director of the PC lab at your school regarding a
new program to support keeping track of students’ borrowing software
– With a partner, write 5 questions you would ask the PC lab director
– Take turns having one pair of students posing the questions to another pair
of students
– Be sure to take notes and write up the results when you have finished.
Joint Application Development (JAD)
• A structured group process focused on determining requirements
• Involves project team, users, and management working together
• May reduce scope creep by 50%
• Very useful technique
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
JAD: Designing and Preparing for the JAD
Sessions
• It is important that the participants understand what is expected of the JAD
session.
• Time commitment – ½ day to several weeks
• Close ended questions are seldom used because do not spark the open and
frank discussion
• Strong management support is needed to release key participants from their
usual responsibilities
• The JAD session is structured Careful planning is essential
• e-JAD can help alleviate some problems inherent with groups knowledge
JAD: Setting
• U-Shaped seating
• Away from distractions
• Whiteboard/flip chart
• Prototyping tools
• e-JAD
JAD: Conducting the JAD Session
• Prepare questions as with interviews
• 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
JAD: Post JAD Follow-up
• Post-session report is prepared and circulated among session attendees
• The report should be completed approximately a week to two after the JAD
session
JAD: Managing Problems in JAD Sessions
• Reducing domination
• Encouraging non-contributors
• Side discussions
• Agenda merry-go-round
• Violent agreement
• Unresolved conflict
• True conflict
• Use humor
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
Questionnaires: Good Questionnaire Design
Document Analysis
• Study of existing material describing the current system
• Provides clues about existing “as-is” 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
• The most powerful indication that the system needs to be changed is when
users create their own forms or add additional information to existing one.
Observation
• Watch processes being performed
• Users/managers often don’t remember everything they do
• Checks validity of information gathered other ways
• Be aware that behaviors change when people are watched
• Be unobtrusive
• Careful not to ignore periodic activities
• Weekly … Monthly … Annual
• Identify peak and lull periods
Comparison of Requirements-Gathering
Techniques
System
Proposal
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
• 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.
References
• Systems Analysis and Design: An Object Oriented Approach with UML 5th ed. Alan Dennis,
Barbara Haley Wixom, and Roberta M. Roth © 2015
• http://www.ocdqblog.com/home/comic-relief-dilbert-on-project-management.html