Systems Analysis:

Determining System Requirements

 Questions and Outcomes in Analysis
 Questions:
 Why do we need a new system – how the current system
function?
 What do we want to accomplish with a new system – what
users would like to see in a new system?

 Outcomes:
 Requirement determination – Fact-finding/Information-
gathering activity, Requirement Modeling
 Structuring systems requirement:
o Process Modeling: the sequence of data movement and handling
operations
 Flowchart, Data Flow Diagram (DFD)

o Data Modeling: the inherent structure of data -

 Entity-Relationship Diagram (ER Diagram)

2
 The Activities in Analysis
 Gather information
 Define system requirements
 Functional and nonfunctional
 Prioritize requirements
 Prototype for feasibility and discovery
 Generate and evaluate alternatives
 Review recommendations with management

3
Activities of the Analysis Phase
and Their Key Questions

4
 Difficulties in
Information Requirements Analysis

· Constraints on humans in specifying information

requirements
· Communication gap among people
· Unwillingness of some users to provide requirements for
political or behavioral reasons
· Variety and complexity of information requirements
· Problems with existing documents
· “Analysis Paralysis,” “Scope Creep”

5
 Performing Requirements Analysis
 Impertinence
 Question everything
 Impartiality
 Find the best organizational solution
 Relaxation of constraints
 Assume anything is possible and eliminate the infeasible
 Attention to detail
 Every fact must fit with every other fact
 Reframing
 View the organization in new ways

6
 System Requirements
 Functional requirements
 Activities and processes that the system must perform
 System’s actions to respond to or triggered by “Events”
 e.g., Order Entered (Event) -> Order Processing (Function)
 Nonfunctional requirements
 Technical requirements
 Performance requirements
 Usability requirements
 Reliability requirements
 Security requirements

7
Themes for Information-Gathering
Questions

8
 Techniques for Information
Requirements Analysis
 Asking Directly:
 Analysts obtain information requirements from persons in the
utilizing system sole by asking them what their requirements
are. This strategy assumes that users can structure their
problem space and overcome of compensate for biases.
 Questionnaire, Interview
 Structured group techniques
o Brainstorming, Nominal Group Technique (NGT)
o Joint Application Development (JAD) with GSS

 Reviewing existing documents, reports, forms, and procedure

description:

9
 Techniques for Information
Requirements Analysis
 Deriving from Existing Information Systems:
 An explicit use of anchoring and adjustment of existing
systems that will be replaced by the new system, existing
system in another, similar organization, proprietary system or
package, or descriptions in textbooks, handbooks, industry
studies, etc.

 Discovering from Experimentation with an Evolving Information

System – Prototyping Approach:
 The systems is initially designed for ease of change. As users
employ the system, they request additional requirements.
After initial requirements establish an anchor, additional
requirements are discovered through use of the system -
prototyping or heuristic development

10
 Techniques for Information
Requirements Analysis
 Research vendor solutions

 Synthesis from characteristics of the utilizing system: Object

System Analysis:
 The most logical and complete method for obtaining
information requirements is from an analysis of the
characteristics of the utilizing system, or the object system.

 Radical approach for determining information requirements:

 Business Process Reengineering

11
 Questionnaires
 Limited and specific information from a large number of users
 Preliminary insight into business
 Not well suited for gathering detailed information
 Closed-ended questions direct person answering question
 Open-ended questions encourage discussion and elaboration

12
 Conducting Interview
 Step 1: Determine the People to Interview
 Informal structures
 Step 2: Establish Objectives for the Interview
 Determine the general areas to be discussed
 List the facts you want to gather
 Step 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

13
 Conducting Interviews
 Step 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
 Step 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

14
 Conducting Interviews
 Step 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
 Step 7: Evaluate the Interview
 In addition to recording the facts obtained in an interview,
try to identify any possible biases

15
A Checklist to Prepare for User Interviews

16
 Working with a Group of Users:
Joint Application Development (JAD)
 Expedites investigation of system requirements
 Seeks to compress fact-finding, modeling, policy formation, and
verification activities into shorter time frame
 Critical factor is to have all important stakeholders present
 Intensive group-oriented requirements determination technique.
 Team members meet in isolation for an extended period of time.
 Highly focused.
 Resource intensive.
 Started by IBM in 1970s.

17
 Joint Application Development
Participants
 Session leader trained in group dynamics and JAD group
facilitation
 Knowledgeable business and system users and policy makers
 Technical staff representatives to handle
 Computer and network configurations
 Operating environments
 Security issues
 Project team members

18
Joint Application Development Facilities
 Conducted in special room
 Limit interruptions
 May be off-site
 Resources
 Overhead projector, white board, flip charts, work material
 Electronic support (laptops)
 CASE tools
 Group support systems (GSS)

19
A JAD Facility

20
 Analyzing Procedures and Other
Documents
 Document Analysis
 Review of existing business documents
 Can give a historical and “formal” view of system requirements
 Types of information to be discovered:
 Problems with existing system
 Opportunity to meet new need
 Organizational direction
 Names of key individuals
 Values of organization
 Special information processing circumstances
 Reasons for current system design
 Rules for processing data

21
 Analyzing Procedures and Other
Documents
 Written work procedure
 For an individual or work group.
 Describes how a particular job or task is performed.
 Includes data and information used and created in the
process.
 Potential Problems with Procedure Documents:
 May involve duplication of effort.
 May have missing procedures.
 May be out of date.
 May contradict information obtained through interviews

22
 Analyzing Procedures and Other
Documents
 Business forms
 Used for all types of business functions.
 Explicitly indicate what data flow in and out of a system and
data necessary for the system to function.
 Gives crucial information about the nature of the organization
 Reports
 Primary output of current system.
 Enables you to work backwards from the report to the data
needed to generate it.
 Description of current information system

23
Using Prototyping During Requirements
Determination
 A prototype is a preliminary working model of a larger, more
complex system component
 Discovery, design, evolving prototypes
 Prototype should be
 Operative
o Working model to provide “look and feel”
 Focused to accomplish single objective
 Quick
o Built and modified rapidly with CASE tools
 How to use a prototype
 Quickly converts requirements to working version of system.
 Once the user sees requirements converted to system, will ask
for modifications or will generate additional requests
24
Using Prototyping During Requirements
Determination

 Most useful when:

 User requests are not clear.
 Few users are involved in the system.
 Designs are complex and require concrete form.
 History of communication problems between
analysts and users.
 Tools are readily available to build prototype.

25
 Using Prototyping During Requirements
Determination
 Drawbacks
 Tendency to avoid formal documentation.
 Difficult to adapt to more general user audience.
 Sharing data with other systems is often not considered.
 Systems Development Life Cycle (SDLC) checks are often
bypassed.
 Key Aspects:
 User interest and participation
 Maintenance of the level of users’ interest and participation
through whole prototyping session

26
Prototyping Process

Identify basic
Deternine basic needs and scope
information of application: System's boundary
requirements

Develop a working interactive

system that meets users' basic
Develop an Initial
requirements. Emphasis on speed
Prototype of building and intial system, not
efficiency

Hand-on experience and

understandings of stated
Use the prototype information requirements &
system's capability

Complete
User satisfied? Yes
systems
development

No

Revise and
enhance the
prototype

27
 Research Vendor Solutions
 Many problems have been solved by other companies
 Positive contributions of vendor solutions
 Frequently provide new ideas
 May be state of the art
 Cheaper and less risky
 Danger
 May purchase solution before understanding problem

28
 Useful Techniques in Vendor Research
 Technical specifications from vendor
 Demo or trial system
 References of existing clients
 On-site visits
 Printout of screens and reports

29
 Business Process Reengineering
and Analysis
 Business Process Reengineering (BPR): search for, and
implementation of radical change in business processes to achieve
breakthrough improvements in products and services.
 Fundamental strategic approach to organizing company
 Streamlines internal processes to be as efficient and effective as
possible
 Questions basic assumptions for doing business and seeks to find
a better way
 Uses IT as BPR enabler
 Systems analyst may discover opportunities for process
improvement
 Any project may include components of BPR

30
 Radical Methods for Determining System
Requirements
 Goals
 Reorganize complete flow of data in major sections of an
organization.
 Eliminate unnecessary steps.
 Combine steps.
 Become more responsive to future change.

31
 Identifying Processes to Reengineer
 Identification of processes to reengineer
 Key business processes
o Structured, measured set of activities designed to produce
specific output for a particular customer or market.
o Focused on customers and outcome.
o Same techniques are used as were used for requirements
determination.

32
 Disruptive Technologies
 Information technologies must be applied to radically improve
business processes.
 Disruptive technologies: are technologies that enable the
breaking of long-held business rules that inhibit organizations
from making radical business changes.

33