CHAPTER FIVE

ANALYSIS: Requirement
Determination

1
Introduction
 System analysis determine how
the current information system
functions and assess what users
would like to see in new system.
 There are three sub phases in
analysis:
 Requirements determination
 Requirements structuring, and
 Alternative generation and choice.
2
Introduction
 We will first study the more traditional
requirements determination then
 Discuss modern methods for collecting
system requirement (JAD).
 Structuring system requirement is
modeling
 a system process,
 logic and
 conceptual data that provides a way for
analysts to see how various process action
diagrams (data flow, entity relationship)
3
Introduction
 Process modeling show the flow of
data between manual or automated
systems.
 Logic modeling show the decision
logic of processing data finally
 Data modeling depicts the
characteristics and natural structure
of data independent of how it is
stored in side the computer.

4
Types of Requirements
 Requirements are partitioned into
functional requirements and non-
functional requirements.
 Functional requirements are associated
with specific functions, tasks or
behaviours the system must support.
 Non-functional requirements are
constraints on various attributes of
these functions or tasks.
5
 Functional Requirements
 Functional requirement specifies
what the system should do or
supposed to do, specify specific
behavior or functions, for example:
 "Display the heart rate, blood pressure
and temperature of a patient
connected to the patient monitor."
 “The customer must place an order
within two minutes of registering”

6
 Functional Requirements
 Typical functional requirements are:
 Business Rules
 Transaction corrections, adjustments, cancellations
 Administrative functions
 Authentication
 Authorization –functions user is delegated to perform
 Audit Tracking
 External Interfaces
 Certification Requirements
 Reporting Requirements
 Historical Data
 Legal or Regulatory Requirements

7
Nonfunctional Requirements
 Non-functional requirements are
requirements that specify criteria that can be
used to judge the operation of a system,
rather than specific behaviors.
 Non-functional requirements are often called
qualities of a system.
 They specify system or user criteria, constraint
or restriction that judge the operation of a
system, rather than specific behaviors when
designing the solution, for example:

"Display of the patient's vital signs must respond to a
change in the patient's status within 2 seconds."

“The customer must be able to access their account
24 hours a day, seven days a week.”
8
Nonfunctional Requirements
 Typical non-functional requirements are:

Performance - Response Time, Throughput, Utilization, Static
Volumetric

Scalability

Capacity

Availability

Reliability

Recoverability

Maintainability

Serviceability

Security (log in, system audit, etc..)

Regulatory

Manageability

Environmental

Data Integrity

Usability

Interoperability

9
Performing Requirements
Determination
 The three sub phases to systems
analysis are separate steps,
 However, you should consider
these steps as somewhat parallel
and iterative.

10
The process of determining
requirements
 Once management has granted permission
to pursue development of a new system
and a project is initiated and planned you
begin determining what the new system
should do.
 Gather information on what the system
should do from many sources
 Users
 Reports
 Forms
 Procedures

11
The process of determining
requirements
 Characteristics for gathering
requirements
 Impertinence
 Question everything
 Impartiality
 Find the best organizational solution
 Relaxation of constraints
 Traditions are different from rules and policies,
Assume anything is possible.
 Attention to detail
 Every fact must fit with every other fact.
 Reframing
 View the organization in new ways
12
 Deliverables and
Outcomes
 The primary deliverables from
requirements determination are:

Various forms of information gathered
during the determination process:

Transcripts of interviews;

Notes from observation and analysis of
documents;

Analyzed responses from questionnaires;

Sets of forms, reports, job descriptions, and

Other documents; and computer-generated
output such as system prototypes.

13
Deliverables and
Outcomes
 Understanding of organizational
components
 Business objective
 Information needs

 Rules of data processing

 Key events affecting data values

14
Deliverables and
Outcomes

15
Traditional Methods for
Determining Requirements

16
 Interview
 Interviewing is one of the primary ways of
gathering information.
 Interview people about

their work,

the information they use to do it, and

the types of information processing that might
supplements their work.
 Other stakeholders are interviewed to understand

organizational direction,

policies expectations managers have on the units they
supervise, and

other non routine aspects of organizational operations.
 Interviewing and Listening
 Gather facts, opinions and speculations
 Observe body language and emotions

17
 Interview
 Guidelines for effective interview
 Plan
 Prepare the interview (Appointment)
 Checklist, agenda, and questions
 Be neutral
 Listen carefully and take note
 Seek a diverse view
 Review notes with in 48 hrs.
 Choosing Interview Questions: You
need to decide what mix and sequence of
open-ended and closed-ended questions
you will use.
18
Interview
 Open-ended questions are usually used
to probe for information for which you
cannot anticipate all possible responses or
for which you do not know the precise
question to ask.

The person being interviewed is encouraged to
talk about whatever interests him or her within
the general bounds of the question.
 Closed-ended questions provide a
range of answers from which the
interviewee may choose.
 Effective way to communicate with people
 Very expensive and time consuming
19
Interview

20
21
22
Administering
Questionnaires
 Questionnaires are:
 More cost-effective than interviews
 Limited number of questions
 Passive and often less in-depth or
understanding
 Possible to gather information from
many people and less biased in
interpretation.
 It is important to specific purposes
rather than for more general
information.
23
Administering
Questionnaires
 Choosing respondents
 Should be representative of all users
 Types of samples

Convenient

Random sample

Purposeful sample

Stratified sample
 Designing questionnaires
 Mostly closed-ended questions
 Can be administered over the phone, in
person or over the Internet or company
intranet
24
Choosing between Interviews
and Questioners
 Interviews Vs. Questioners
 Interviews are good for collecting rich,
detailed information.
 Interviews are time-intensive and
expensive.
 Questionnaires are more cost-effective
 With questionnaires specific information
can be gathered from many peoples.
 Which method to use and what strategy to
employee will vary with the system being
studied and its organizational context

25
Choosing between Interviews
and Questioners

26
Observation
 Directly Observing Users
 People are not reliable informant
 They don’t have accurate appreciation of what they
do.
 Generally, people can’t always be trusted to reliably
interpret and report their own action
 Serves as a good method to supplement interviews
 Provides firsthand and objective measures of
employees interaction with information system.
 It is more accurate reflection of reality than
what employees themselves believe.
 Often difficult to obtain unbiased data
 People often work differently when being observed
27
Analyzing Procedures and
Other Documents
 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
 Rules for processing data

28
Analyzing Procedures and
Other Documents
 One type of useful document is a
written work procedure.
 Procedures are not trouble-free
sources of information.

It will reveal a duplication of effort in two or
more jobs.
 A procedure is missing.
 Procedure is out of data
 Formal procedures may contradict
information you collected from interviews,
questionnaires, and observation

29
Analyzing Procedures and
Other Documents
 All of these problems illustrate the
difference between formal systems and
informal systems.

Formal systems are systems recognized by
the official documentation of the
organization
 informal systems are the way in which the
organization actually works.
 A second type of document useful to
systems analysts is business form.
 A third type of useful document is a
report generated by current systems.
30
Analyzing Procedures and
Other Documents

31
 Workflow Analysis
Modeling
 Workflow analysis modeling help to facilitate
standard analysis methodologies.
 A workflow is a depiction of a sequence of
operations, declared as work of a person, work of a
simple or complex mechanism, work of a group of
persons, work of an organization of staff, or
machines.
 A workflow diagram is a graphic representation of
all the major steps of a process. It can help you:

Understand the complete process.

Identify the critical stages of a process.

Locate problem areas.

Show relationships between different steps in a process.

32
 Workflow Analysis
Modeling
 With the help of such diagram it is possible to
see the path of the task in a workflow, the
person who is responsible for its execution on
each stage.
 Workflow diagram is a sort of flowcharts that
consist of six types of blocks.

33
Workflow Diagram Symbols

34
 Practical work analysis
 The first step in planning a workflow application is
to analyze the business process you want to
define.
 The steps involves in purchase order task of the
Sales Supervisor at a fictitious distributor firm are:
1. Receive a request for an estimate
2. Verify the stock balance
3. Issue the estimate
4. Place order
5. Receive materials ordered
6. Checking and Inspection
7. Send material to SOP
35
Workflow Diagram

36
 Practical work analysis
 It is important to focus on the main job when
you list steps, because if surrounding
business factors, such as financial
considerations or stock management, also
are listed, then the story is blurred.
 It is important to focus on the main job when
you list steps, because if surrounding
business factors, such as financial
considerations or stock management, also
are listed, then the story is blurred.
 workflow includes the communication among
the people involved in the business process.

37
 Practical work analysis
 The people involved in the earlier example are:

Sales supervisors

Customer

Stock keeper

Delivery person
 Each step has a pool of information. For example, if
you order a product, then information, such as the
product name, quantity, and price, is involved.
 The information pools have a relationship to each
other.
 If you draw a picture of how the information goes
around these steps with such relationships considered,
you will understand the relationship in each process
more.
38
 Practical work analysis
 The information relation of each process.

39
 Types of work flow
 User-level WFD
 Models entities and workflows described by
single user
 Presents a single user’s view point but includes
more than one entity and can model workflows
across functional areas
 Discover formal as well as informal flows of
information.

40
Types of work flow
User-level WFD

Invoice C1
Invoice C2
Customer
Sales order
Processing

Sales
Order
Clerk
Picking List

Sales Order Form Dispatch

Sales
Agent

41
 Types of work flow
 Combined user level WFD
 Integrated view of all entities and workflows
 Identify inconsistencies in user-level WFDs
 Reveals redundancies, inefficiencies
 Can be used to identify high level business
processes

Each internal entity performs a process to
generate flows to and process flows from
external entities.

Flows between internal entities can also indicate
a major process
 Can be used to define system boundaries

42
 Types of work flow
Combined user level WFD

Payment
Sales order Sales
Processing Report
Customer

Invoice C1
Management

Sales Order
Clerk
Order
Picking List Invoice C2

Sales Order Form

Delivery
Dispatch
Sales
Agent
Customer

43
 Types of work flow
 Organizational level WFD
 Collapse all internal entities in combined
user-level WFD, into a single internal
entity
 External entities and the flow of
information between the organization and
external entities
 Equivalent to Context level DFD

44
 Types of work flow
Organizational level WFD

Promotion Accounts
Club Receivable
Member

Member Order Member

Credit
Status
Warehouse

various Inquiry Reponses Revised Packing Order

New Subscription Member New Promotion
Potential
Member Services Subscription Program
Subscription Offer
System

Subscription Renewal various Sales Reports

various
Promotion Reports
Marketing
various Subscription Reports Department

Past Resubscription Offer

Member
various Member
Reports Member
Services

45
Modern Methods for
Determining Requirements
 Joint Application Design (JAD)
 Brings together key users, managers and
systems analysts
 Purpose: collect system requirements
simultaneously from key people
 Conducted off-site
 Prototyping
 Repetitive process
 Rudimentary version of system is built
 Replaces or augments SDLC
 Goal: to develop concrete specifications for ultimate
system

46
Joint Application Design (JAD)
 Participants in the JAD
 JAD session leader
 Users
 Managers
 Sponsor
 Systems analysts
 Scribe
 IT staff
 End Result
 Documentation detailing existing system
 Features of proposed system

47
48
Prototyping
 Quickly converts requirements to working
version of system
 You will still have to interview users and
collect documentation.
 Prototyping however, will allow you to
quickly convert basic requirements into a
working version of the desired information
system.
 Once the user sees requirements converted
to system, will ask for modifications or will
generate additional requests

49
 Prototyping
 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

50
Prototyping
 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
51