Professional Documents
Culture Documents
SAD IT Chapter One Part II
SAD IT Chapter One Part II
ANALYSIS: Requirement
Determination
1
Introduction
2
Introduction
logic and
3
Introduction
Process modeling show the flow of data
between manual or automated systems.
4
Types of Requirements
Requirements are partitioned into:
functional requirements and
non-functional requirements.
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.”
6
Functional Requirements
7
Nonfunctional Requirements
for example:
8
Nonfunctional Requirements
Typical non-functional requirements are:
Performance - Response Time, Throughput
Scalability
Capacity
Availability (24/7)
Reliability
Recoverability
Maintainability
Serviceability
Manageability
Usability
Interoperability
9
Performing Requirements Determination
Sources of information???
10
The process of determining requirements
Users
Reports
Forms
Procedures
11
The process of determining requirements
Deliverables????? 12
Deliverables and Outcomes
Business objective
Information needs
14
Deliverables and Outcomes
15
Traditional Methods for Determining Requirements
16
Interview
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.
19
Interview
20
21
22
Administering Questionnaires
Questionnaires are:
More cost-effective than interviews
Limited number of questions
24
Choosing between Interviews and Questioners
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
29
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.
33
Workflow Diagram Symbols
34
Practical work analysis
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.
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
1. 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
41
Types of work flow
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
Delivery
Dispatch
Sales
Agent
Customer
43
Types of work flow
44
Types of work flow
Organizational level WFD
Promotion Accounts
Club Receivable
Member
various
Promotion Reports
Marketing
various Subscription Reports Department
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