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.

Themes for information-gathering
questions
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
Sample Order Form for RMO
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
Sample Checklist to Prepare for User
Interviews
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
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 doesnt 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 couldnt be
learned from a textbook, but only from experience
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).

Sample Agenda
for Interview
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
A Sample Open-Items List
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
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

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

Activity Diagram Symbols
Activity
Diagram
that
Models a
Workflow
Activity Diagram with Concurrent Paths
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
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
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
Sample RMO
Questionnaire
quantitative
Closed-ended
open-ended
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
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
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)
A JAD Facility
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.)
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

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
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
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
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!
Structured walkthrough
What and When
First item to review is documentation that was
developed as part of the analysis phase. It can be:
A narrative describing a process
A flow chart showing a workflow or model diagram
documenting an entire procedure
Better to conduct several smaller walkthroughs every
week or two, than bigger ones with reviewing a number of
documentation
Very important to be scheduled as soon as documents
have been created!

Structured walkthrough
Who
Two main parties involved in walkthroughs:
Person (or persons) who need their work to be reviewed
Group who reviews it
It is best to have experienced analysts involved in the walkthrough who
reviews the documentation especially for verification since they have seen lots
of problems before!
For validation good to have stakeholders involved
Could also include technical staff, or even external users whoever is best
for validating the work

How
Requires the same steps as an interview (i.e., preparation, execution and
follow-up)
Preparation: The analyst whose work is to be reviewed should:
Get materials ready for review
Identify appropriate participants and provide them copies of the material
Schedule a time and place and notify all participants
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

Structured
Walkthrough
Evaluation
Form
Readings
Todays lecture: Chapter 4 Investigating System
Requirements

For next lecture: Chapter 5 Modeling System
Requirements