CS 201 “Systems Analysis and Design”

LECTURE 4:
Investigating System Requirements

1
Lecture Outline

 The Analysis Phase

 System Requirements
 Models and Modeling
 Stakeholders
 Information Gathering
 Prototypes
 Joint Application Design Sessions
 Structured Walkthrough

2
The Analysis Phase in More Detail

 Gather information (from people who will be using the system)

• by interviewing them
• by observing their work
• by reviewing documents and policy statements (e.g. at a bank)

 Define system requirements

Functional and nonfunctional

 Prioritize requirements

 Prototype for feasibility and discovery

 Generate and evaluate alternatives

 Review recommendations with management 3

The Activities of the Analysis Phase

4
The Analysis Phase

Gather Information
System analyst needs to become an expert in the
business area the system will support or should
even actually do some or part of the task to get a
feel for what is done (e.g., in order to automate
order-entry, may need to know how orders are
processed)
Gathered information involves:
• Understanding the existing system
• Identifying all current and future users, locations,
system interfaces (inside and outside the organization)
• Identifying possible software package solutions that
might be used

5
The Analysis Phase

Prioritize Requirements
• Establish which functional and technical requirements are most
critical
• Why? Since resources are always limited and you want to address
the most important things
• Unless evaluation priorities, system requirements tend to expand
as users make more suggestions (called “scope creep”)

Prototype for Feasibility and Discovery

• If system involves new technology, the team may need to get
experience working with it. Creating prototypes can be very
valuable
• Prototyping helps to understand possibilities and limitations of the
technology
• Good idea for projects where requirements are hard to define
beforehand
• By showing prototypes to end users can get feedback into what is
really needed
• Prototypes help users (and analysts) to discover requirements they
might not thought about otherwise, i.e. think creatively
6
 The Analysis Phase

Generate and Evaluate Alternatives

• Could include considering more than one method to develop system
• Could involve in-house development or outsourcing to a consulting
firm
• Might be able to use “off the shelf” software package
• Each alternative has costs and benefits to be considered
• Also must consider technical feasibility
Review Recommendations with Management
• Usually done when all the above are completed
• Must decide if project should continue at all
• Must decide on which alternative is best (if you are going ahead with
the project)
• NOTE: at this point should include CANCELLATION of the project as
an option
Possible reasons
• May have found costs were too high
• May have found benefits were lower than thought
• Business environment may suddenly change making the project less
important 7
Activities of the Analysis Phase
and Their Key Questions

8
System Requirements

 System requirements – specifications

that define the functions of the new
system
 Two sets of requirements:
Functional requirements
Nonfunctional requirements

9
Functional requirements

 Functional requirements
Activities system must perform (use
cases)
Based on procedures and business
functions
Documented in analysis models
 E.g.: “reduce fuel costs by calculating
where is it best to fuel up”

10
Nonfunctional requirements

 Nonfunctional requirements
Technical requirement – hardware and software
Performance requirement – workload measures
Usability requirement – user interface,
workflow
Reliability requirement – outages, error
detection
Security requirement – access & protection

 E.g.: “the new system must be run in a client-

server environment with Windows NT”, “must
have one second response time” 11
Models and Modeling

 Requirements are describes by a

collection of models
 Complex systems require more than
one type of model
 Models represent some aspect of the
system being built
 Process of creating models helps analyst
clarify and refine design
 Models assist communication with
system users 12
Reasons for Modeling

13
Types of Models

 Different types of models are used in

information systems development

Mathematical – formulas that describe technical

aspects of the system (e.g., processing rules)

Descriptive – narrative memos, reports, or lists

that describe aspects of the system

Graphical – diagrams and schematic

representations of some aspect of the system

14
Some Descriptive Models

15
Overview of Models Used
in Analysis and Design

 Analysis activities named “define system

requirements”
Logical models
Provide detail without regard to specific
technology (perfect technology
assumption)
 Design models
Physical models
Provide technical details (non-perfect
technology assumption)
Extend logical models 16
Models
Created
During
Analysis

17
Stakeholders—The Source of
System Requirements

 People with interest in successful system implementation

 Three primary groups of stakeholders

Users (use system)

Clients (pay for and own system)

Technical staff (ensure system operation)

 Every type of stakeholder is identified by analyst - one of

the most important first steps in determining systems
requirements
 The second task is to identify the critical person from each
stakeholder type to be available as the business expert.
18
Stakeholders Interested
in New System Development

19
Users as Stakeholders

 Horizontal users (i.e., across departments)

 Vertical users or hierarchy within a
department (i.e., clerical staff, middle
management, and senior executives)
Business users – perform day-to-day operations
(transactions): provide information about daily
operations and how system supports them
Information users - who need current information
Management users – who need summary
information
Executive users – who need strategic information
External users may have access to system (e.g.,
via Internet) 20
Clients and Technical Staff as
Stakeholders
Client Stakeholders
• They pay for the project so they are important!
• Project team must provide project status reviews
to the clients

Technical Stakeholders
• The technical staff includes people who establish
and maintain the computing environment of the
organization
• They are source of many technical requirements
– provide guidance in such areas as programming
language, computer platform, equipment, etc.

21
RMO
Stakeholders

22
Techniques for Information
Gathering
 Analysis phase done to understand business
functions and develop system requirements
 Original structured approach
Create physical and logical models of existing
system
Derive requirements from existing system model
Create physical and logical models of new system
 Current approach
Identify logical requirements for new system
Balance the review of current business functions
with new system requirements
23
Traditional Approach to Identifying
System Requirements

24
Current Approach to Identifying
System Requirements

25
The transition from information
gathering to model building

26
Methods of Information Gathering

 Distribute questionnaires to stakeholders

 Review existing reports, forms, and procedure
descriptions
 Interview and discuss processes with users
 Observe and document business processes
 Build prototypes
 Conduct joint application design (JAD)
sessions
 Research vendor solutions

27
Just For Fun

28
Question Topics

• What kind of information are we looking for during

information gathering?
• We need to obtain information that will enable us to build the
logical model of the new IS

• What Are the Business Processes? – i.e. understanding of

business functions, building a comprehensive list of all the
business process (focus on the current system).
• How is the Business Processes Performed? – i.e., focus on
how the new system should support the functions (visualize
new and more efficient approaches to performing the
business processes by new system)
• What Information is required? – i.e., elaboration of the
second information in terms of defining specific information
that the new system must provide.

29
Themes for information-gathering
questions

30
Review Existing Reports, Forms,
and Procedure Descriptions

Serves two purposes:

Provides a preliminary understanding of
processes involved in a company
Can be useful in conjunction with interviews
Can be used to develop interview questions
Can be used in interviews themselves (as
visual aids and as working documents for
discussion
Helps to identify business rules that may not
come up in the interview
Helps to discover discrepancies and
redundancies
Can be extended to looking at other types of
documents like emails, memos, etc
31
Sample Order Form for RMO

32
Conduct Interviews and
Discussions with Users
 One of the most effective ways to understand business
functions and rules
 Can be time consuming and resource expensive
 Team members meet with individuals or groups of users
 May require multiple sessions to
Meet all users
Understand all processing requirements
 List of detailed questions prepared
 Can involve new approaches (critical incident method and
cognitive task analysis – not mentioned in text)
 To be effective should be organized in three areas:
(1) preparing for the interview
(2) conducting the interview
(3) following up the interview
33
Sample Checklist to Prepare for
User Interviews

34
Preparing for the Interview

Must establish objective – what do you want to get out of it?

Determine users
Could interview users with different levels of experience,
computer expertise, bank expertise…
Good to have at least two project team members at the
interview
Can compare notes in order to ensure accuracy
Prepare detailed questions
Good to structure the questions
Can include both open-ended (e.g. “how do you do this
function?”) and closed-ended questions (“how many
times a day do you do this?”)
Last step in preparing: make the interview arrangements
(where to meet and when – good to pick a quiet room).
Each participant should know the objective of the meeting,
have a chance to preview the questions or materials to be
reviewed
35
Conducting the Interview (1 of 2)

See text for variety of tips: like dress well, be polite and
arrive on time!
Limit the time of the interview (plan for about an our and a
half)
If it is required more time to cover all questions, schedule
another session.
It is better to have several shorter interviews than one long
“marathon”
Look for errors or exception conditions – e.g. get them to
describe when things go wrong (“What if it doesn’t arrive?”,
“What if the balance is incorrect?”)
In critical incident method can ask to describe an easy
case, as well as a “scenario from hell”
“What ifs” can be explored as well as probing about real
incidents
The ability to think of the exceptions is very important; it
couldn’t be learned from a textbook, but only from
experience 36
Conducting the Interview (2 of 2)

Probe for details

In addition to looking for exception conditions,
the analyst must probe to get a complete
understanding of procedures and rules
It is easier to get general overview than
details on how it works and what information
is used
Take careful notes (it provides the basis for the
next interview)
Try to follow some logical agenda during the
interview (it helps to prod your memory on
issues and items that should be discussed in an
interview).

37
Sample
Agenda for
Interview

38
Following Up the Interview

The first task is to absorb, understand and

document the information collected from the
interview
Can write it up as text and also document by
constructing diagrammatic models of business
processes
Review results with others who attended the
interviews (within a day or at most two)
Make a list of questions that need further
elaboration (open-items list)
Make a list of new questions based an areas that
need more elaboration or that are missing
information
Send a thank-you note or email to the users who
participated in the interview 39
A Sample Open-Items List

40
Observe and document business
processes (1 of 2)
 Varies from office walkthroughs to performing
actual tasks

 Not necessary to observe all processes at

same level of detail

 May make users nervous, so use common

sense

 Can document workflows with UML activity

diagrams 41
Observe and document business
processes (2 of 2)

Early in the investigation activities, time should be

scheduled to observe the business procedures in
the organization that the new system will support
Excellent way to learn
how people do their jobs
what problems they may have
how to improve any systems they are using
Can consist of
Quick walkthrough of the office or plant
Scheduling several hours to observe a user
doing a real task (“day in the life”)
Doing the task yourself to see what is involved
42
Documenting

A workflow (sequence of processing steps that completely

handles one business transaction) is an effective way to capture
information
Activity diagram is a type of workflow diagram that describes the
user activities and their sequential flow
Synchronization bar – symbol to control splitting or merging
of a path on an activity diagram
Swimlane – bounded area that contains activities of a single
agent
Sample
It represents a customer requesting a quote from a salesperson
If it is a simple request, the salesperson can enter the data and
create the quote
If it is a complex request, the salesperson requests assistance from
a technical expert to generate the quote
In both cases, the computer system calculates the details of the
quote
43
Activity Diagram Symbols

44
Activity
Diagram
that
Models a
Workflow

45
Activity Diagram with Concurrent
Paths

46
Building Prototypes

Prototype is an initial working model of a larger, more

complex system
Used for many purposes:
To test feasibility
To help identify processing requirements
To compare different design and interface alternatives

Different names to describe different uses

Throwaway prototypes
Discovery prototypes – used in the analysis phase for a
single discovery objective and then discarded once the
concept has been tested
Design prototypes – used in the design phase to test
various design alternatives
Evolving prototypes – prototypes that grow and evolve and
may be used as the final, live system 47
Prototypes

Characteristics of Prototypes:
Operative: a prototype should be a working
model, with some real functionality (if not
working, but just shows what it looks like, its
called a mock-up)
Focused: a prototype should be focused on a
single objective (to test a specific concept or
verify an approach)
Quick: the prototype should be built and
modified quickly (so can validate an approach,
and if it is wrong, fix it fast in an iterative
process)
Built and modified rapidly with CASE tools
48
Distribute and Collect
Questionnaires

 Have a limited and specific use

 Allow to collect information from a large number
of stakeholders
 Can be used to get a preliminary insight on the
information needs of the various stakeholders
 Not well suited for gathering detailed information
 Three groups of questions:
Quantitative (e.g., “How many customers a day?”)
Closed-ended (express opinion on a predetermined
scale: ““On a scale of 1 to 10 rate system
performance” ) - direct respondent, simple and short
answer is assumed; easy to tabulate and process
Open-ended - encourage discussion and
elaboration, no predetermined answer
49
 quantitative

Sample RMO
Questionnaire

Closed-ended

open-ended

50
Conduct Joint Application Design
Sessions
 Expedites investigation of system requirements
 JAD is a technique to define system requirements
in a single session by having all the necessary
people participating together
 Compare: Normal interview and discussion approach takes
a lots of time and effort (meet with users, document the
discussion, build models, review and revise them, place
unresolved issues on an open-items list – all of those on
iterative basis!)- May require many meetings (months)
 JAD idea is to compress all these activities into a
shorter series of meetings with users and team
members (An individual JAD session may last
from a day to a week)
 Critical factor is to have all important
stakeholders present
51
 Joint Application Design
Participants
 JAD session leader
Trained in group dynamics and facilitating group discussion
Must ensure agenda and objectives are met
Often system analyst appointed as leader but better if someone actually
trained to lead group decision making
May not be the expert in the business area though
 Users
Managers are good to have at the meeting since important decisions have
to be made
If executives cannot be at the meeting, they at least should be
contactable (or visit once a day)
 Technical staff
A representative from the technical support group should be present (e.g.
for info. regarding networks, operating environments etc.)
 Project team members
System analysts
User experts
Assist in discussion, clarify points, build models and document the results
Members of the project team are the experts on ensuring the objectives
are met 52
Joint Application Design 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)
53
A JAD Facility

54
Group Support Systems (GSSs)

 System that enables multiple people to participate

with comments at the same time, each on his or
her computer
• Allows for sharing of information and collaborative work
• Runs on networked computers
• Can include “chat” features to allow posting to participants
• Allows inclusion of “shy” participants
• Can store results of discussion and decisions made
• Also allows for connection with participants at distant
locations – a “virtual” meeting (could include video hookup)
 Other forms of electronic support
• Electronic white boards
• Computer support for collaborative work (CSCW) software
• Would allow for participation at remote sites who could
work on documents at same time (shared files, etc.)
55
Limitations of JAD

Can be risky
Since done very fast may end up with sub-
optimal decisions
Details may be inappropriately defined or missed
However, can be effective if it is done carefully
with the result of shortening the schedule

56
Validating the Requirements

 Make sure gathered information is correct (fixing a requirements

error later in SDLC can cost hundreds of times more than it would
have cost to fix it during the requirements definition!)
 In software development, each project is unique, so each set of
system requirements should be reviewed and tested as much as
possible
 In programming we can proof the accuracy of the code using tests
(i.e. by executing the program by entering appropriate input data
and observing the resultant output. We cannot test the requirements
that way
 In system analysis jargon it is called verify and validate (V&V) the
system requirements
• Verification means determining that the requirements are
internally consistent (test whether the field definitions are consistent
throughout all of the subsystems of a system)
• Validation means ensuring that the requirements are complete
and correctly express users’ needs
 Structured walkthrough is effective means of implementing
quality control early in project
57
Structured walkthrough

 Reviewing of the findings from your

investigation
 Reviewing of the models based on those
findings
• This approach is structured because
analysts formalize the review process into
a set procedure
 Objectives: to find errors, omissions and
problems by documenting the
requirements as the analysts understand
them and then reviewing them with the
project team
 It is not a performance review! 58
Structured walkthrough

 Execution
– During the walkthrough analyst presents material point by point
– Walks through each diagram or section of a document explaining
each component (one effective technique is to define a sample
test case and process it through the defined flow)
– The reviewers look for inconsistencies or problems and point them
out
– A librarian (helper for presenter) documents the comments, errors
and suggestions
– Corrections and solutions are not made during the walkthrough
– If there is a complex error may reschedule for another meeting
– Reviewer should only provide focused feedback
– Presenter can integrate feedback later on when gets entire set of
comments

 Follow-up
– Making required corrections
– Additional walkthrough may be needed 59
END

60