Transcript Ways to Gather Requirements

Interviews
 Joint Application Development
 Questionnaires
 Document Analysis
 Observation


Prepare to interview users by reading background
documentation first.

To reduce conflicts, identify user groups and ask the
client to select official user representatives/subject
matter experts who are authorized to speak for all the
users they represent and who have current, working
knowledge of the area to be discussed.

Make a written list of questions to help you interview.

Provide them in advance so the interviewees can
prepare.

Information needed depends on the system,
information to find out from users might
include:
› What are the user types, their required skills?
› What work do they do; what do they authorize?
› What problems and irritations they have doing the
work?
› What are the work cycles and timing; how often
something is done and how long it takes; what is the
criticality of its timing?
› What is the sequence of work steps or processing? (In
addition to ensuring the system performs the work
correctly, this information can affect project
planning if the system will be made operational in
stages.)
› What is the work product at the conclusion of
each step? (In addition to tangible items,
decisions, approvals, completed reviews, and
other intellectual outputs are also work
products.)
› Where is the work is performed?
› What organizational goals and objectives, legal
requirements, or other needs does the work
support?
› How the work is performed (don't assume it is
done the same way you know from another
organization)?
› What information is required to do the work;
what are the sources?
› What parts of the work tend to change and
how often they change?
› What the outcomes of the work are
(decisions, reports, items, etc.)
› Is there any information that was missed by
your questions?

Watch for areas in the business process
that use subjective decision-making.
› You will need to work with users or their
management to clarify policy if this activity
will be automated.
› Delays in agreement on the policy often
occur and can stall your effort.

Users may present a requirement as a
solution.
› Find out why they want this solution by asking
"what" that solution provides or does.
› Asking "why" makes it sound as if their
request must be justified to you.

Users resent being told the information they are
providing is not needed.
If the information is relevant to the topic, but too detailed
for the current discussion, ask if you can return for that
information later.
› Be sure to put in your notes that additional detail is
available and from whom so you can come back for it
without having to ask who has it.
›

Requesting the same information over and over
indicates incompetence.
› Users will complain to their management about this
›
›
›
›
because it keeps them from doing their real work, and it
will come back to you.
Establish and index a library of documents that have been
provided.
Put meeting notes and minutes in the library. Ideally this
will be an electronic repository so it can be used by the
entire team.
Do not go to users for information until you have checked
the repository.
Keep track of hardcopy documents, also.

If possible, assign one analyst to take notes while another
interviews.
›
›
›
›
›
›

Keep track of issues and unresolved items during the meeting, get
concurrence on notes taken during the meeting before the meeting ends.
Reserve time to read notes back. It works better than distributing notes for
comment after the meeting.
People forget or try to insert agendas when no one else is there to object.
You will also clear up misunderstandings while the subject is still fresh in
everyone's mind.
Assign/get volunteers to resolve issues. Obtain user prioritization of the
requirements.
Provide everyone with written notes from the meeting within a couple of
days after the meeting.
Remember, it isn't the users' job to tell you what kind of
technology they need.
›
If you want to know what kind of technical capabilities they might like, be
prepared to give them examples.

Try to see the work performed.
› Get copies of forms, outputs, and information used in
the work, including help sheets and notes posted by
the users at their desks.

Identify all parties who will use the requirements (for
example, testers, designers, architects).
› All of them, along with the users/subject matter experts,
›
›
›
›
are responsible for reviewing the requirements and
approving them.
The formal review and sign-off may require additional
revisions before the requirements can be baselined.
Resolve requirements conflicts by prioritization,
additional clarification of the requirements, and
negotiations with affected parties.
During negotiations, have everyone explain their roles
to the other parties so all gain perspective on the
effects of the requirement.
More than one meeting may be required.
 In
establishing responsiblities for the
various reviewers, remember that
approval of the requirements for
baselining is not necessarily approval
for implementation. Determining if a
requirement should be scheduled for
implemention is based on priority,
cost, and other considerations. The
decision is usually made by a project
sponsor or project manager.

A popular fact-finding technique that brings users
into the development process as active participants.

The JAD process is based on four simple ideas:
› People who actually do a job have the best
understanding of that job.
› People who are trained in information technology have
the best understanding of the possibilities of that
technology.
› Information systems and business processes rarely exist in
isolation -- they transcend the confines of any single
system or office and affect work in related departments.
People working in these related areas have valuable
insight on the role of a system within a larger community.
› The best information systems are designed when all of
these groups work together on a project as equal
partners.


Executive Sponsor: The executive who charters
the project, the system owner. They must be
high enough in the organization to be able to
make decisions and provide the necessary
resources and support for the project. They
might attend the opening and closing session.
Project Leader/Manager: Generally the leader
of the application development team answers
questions about the project regarding scope,
time, coordination issues and resources. They
may contribute to the sessions as long as they
do not inhibit the participants.




Facilitator/Session Leader: Chairs the meeting and
directs traffic by keeping the group on the meeting
agenda. The facilitator is responsible for identifying
those issues that can be solved as part of the
meeting and those which need to be assigned at the
end of the meeting for follow-up investigation and
resolution. The facilitator serves the participants and
does not contribute information to the meeting.
Scribe/Modeller/Recorder/Documentation Expert:
Records and publish the proceedings of the meeting
and does not contribute information to the meeting.
Participants: Customers in the business area directly
or indirectly being affected by this project, who are
experts in their field and can make decisions about
their work. They are the source of the input to the
session.
Observers: Generally members of the application
development team assigned to the project. They are
to sit behind the participants and are to silently
observe the proceedings.3,6,7,8,
Identify project objectives and limitations It is vital to have clear
objectives for the workshop and for the project as a whole. The
pre-workshop activities, the planning and scoping, set the
expectations of the workshop sponsors and participants.
Scoping identifies the business functions that are within the
scope of the project. It also tries to assess both the project
design and implementation complexity. The political sensitivity of
the project should be assessed. Has this been tried in the past?
How many false starts were there? How many implementation
failures were there? Sizing is important. For best results, systems
projects should be sized so that a complete design - right down
to screens and menus - can be designed in 8 to 10 workshop
days.
 Identify critical success factors It is important to identify the
critical success factors for both the development project and
the business function being studied. How will we know that the
planned changes have been effective? How will success be
measured? Planning for outcomes assessment helps us judge the
effectiveness and the quality of the implemented system over its
entire operational life.


Define project deliverables In general, the deliverables from a
workshop are documentation and a design. It is important to
define the form and level of detail of the workshop
documentation. What types of diagrams will be provided? What
type or form of narrative will be supplied? It is a good idea to
start using a CASE tool for diagramming support right from the
start. Most of the available tools have well to great diagramming
capabilities but their narrative support is generally weak. The
narrative is best produced with your standard word processing
software.

Define the schedule of workshop activities Workshops vary in
length from one to five days. The initial workshop for a project
should not be less than three days. It takes the participants most
of the first day to get comfortable with their roles, with each
other, and with the environment. The second day is spent
learning to understand each other and developing a common
language with which to communicate issues and concerns. By
the third day, everyone is working together on the problem and
real productivity is achieved. After the initial workshop, the teambuilding has been done. Shorter workshops can be scheduled
for subsequent phases of the project, for instance, to verify a
prototype. However, it will take the participants from one to
three hours to re-establish the team psychology of the initial
workshop.
Select the participants These are the
business users, the IS professionals, and
the outside experts that will be needed
for a successful workshop.
 Prepare the workshop material Before
the workshop, the project manager and
the facilitator perform an analysis and
build a preliminary design or straw man
to focus the workshop. The workshop
material consists of documentation,
worksheets, diagrams, and even props
that will help the participants understand
the business function under investigation.


Organize workshop activities and exercises The facilitator must design
workshop exercises and activities to provide interim deliverables that build
towards the final output of the workshop. The pre-workshop activities help
design those workshop exercises. For example, for a Business Area Analysis,
what's in it? A decomposition diagram? A high-level entity-relationship
diagram? A normalized data model? A state transition diagram? A
dependency diagram? All of the above? None of the above? It is important
to define the level of technical diagramming that is appropriate to the
environment. The most important thing about a diagram is that it must be
understood by the users. Once the diagram choice is made, the facilitator
designs exercises into the workshop agenda to get the group to develop
those diagrams. A workshop combines exercises that are serially oriented to
build on one another, and parallel exercises, with each sub-team working on
a piece of the problem or working on the same thing for a different
functional area. High-intensity exercises led by the facilitator energize the
group and direct it towards a specific goal. Low-intensity exercises allow for
detailed discussions before decisions. The discussions can involve the total
group or teams can work out the issues and present a limited number of
suggestions for the whole group to consider. To integrate the participants,
the facilitator can match people with similar expertise from different
departments. To help participants learn from each other, he can mix the
expertise. It's up to the facilitator to mix and match the sub-team members to
accomplish the organizational, cultural, and political objectives of the
workshop. A workshop operates on both the technical level and the political
level. It is the facilitator's job to build consensus and communications, to
force issues out early in the process. There is no need to worry about the
technical implementation of a system if the underlying business issues cannot
be resolved.
Prepare, inform, educate the workshop participants All of the
participants in the workshop must be made aware of the
objectives and limitations of the project and the expected
deliverables of the workshop. Briefing of participants should take
place 1 to 5 days before the workshop. This briefing may be
teleconferenced if participants are widely dispersed. The briefing
document might be called the Familiarization Guide, Briefing
Guide, Project Scope Definition, or the Management Definition
Guide - or anything else that seems appropriate. It is a
document of eight to twelve pages, and it provides a clear
definition of the scope of the project for the participants. The
briefing itself lasts two to four hours. It provides the psychological
preparation everyone needs to move forward into the
workshop.
 Coordinate workshop logistics Workshops should be held off-site
to avoid interruptions. Projectors, screens, PCS, tables, markers,
masking tape, Post-It notes, and lots of other props should be
prepared. What specific facilities and props are needed is up to
the facilitator. They can vary from simple flip charts to electronic
white boards. In any case, the layout of the room must promote
the communication and interaction of the participants.2


Objectives in designing questionnaires
› There are two main objectives in designing a
questionnaire:
› To maximize the proportion of subjects
answering our questionnaire - that is, the
response rate.
› To obtain accurate relevant information for
our survey.
To maximize our response rate, we have
to consider carefully how we administer
the questionnaire, establish rapport,
explain the purpose of the survey, and
remind those who have not responded.
 The length of the questionnaire should
be appropriate.
 In order to obtain accurate relevant
information, we have to give some
thought to what questions we ask, how
we ask them, the order we ask them in,
and the general layout of the
questionnaire.


There are three potential types of
information:
› Information we are primarily interested in-
that is, dependent variables.
› Information which might explain the
dependent variables-that is, independent
variables.
› Other factors related to both dependent
and independent factors which may distort
the results and have to be adjusted for - that
is, confounding variables.

Open format
› Allows exploration of the range of possible themes
arising from an issue
› Can be used even if a comprehensive range of
alternative choices cannot be compiled

Closed-that is, forced choice-format
› Easy and quick to fill in
› Minimize discrimination against the less literate (in self
administered questionnaire) or the less articulate (in
interview questionnaire)
› Easy to code, record, and analyze results
quantitatively
› Easy to report results
The way questions are phrased is important and
there are some general rules for constructing
good questions in a questionnaire.
Use short and simple sentences
Short, simple sentences are generally less
confusing and ambiguous than long, complex
ones.
As a rule of thumb, most sentences should contain
one or two clauses.
Sentences with more than three clauses should be
rephrased.
Ask for only one piece of information at a time
For example, "Please rate the lecture in terms of its content
and presentation" asks for two pieces of information at the
same time. It should be divided into two parts: "Please rate
the lecture in terms of (a) its content, (b) its presentation."
Avoid negatives if possible
Negatives should be used only sparingly. For example,
instead of asking students whether they agree with the
statement, "Small group teaching should not be
abolished," the statement should be rephrased as, "Small
group teaching should continue." Double negatives
should always be avoided.
Ask precise questions
Questions may be ambiguous because a word or term
may have a different meaning. For example, if we ask
students to rate their interest in "medicine," this term might
mean "general medicine" (as opposed to general surgery)
to some, but inclusive of all clinical specialties (as opposed
to professions outside medicine) to others.
Another source of ambiguity is a failure to
specify a frame of reference.
Ensure those you ask have the necessary
knowledge
Sensitive issues
It is often difficult to obtain truthful answers to
sensitive questions.
Minimize bias
People tend to answer questions in a way they
perceive to be socially desired or expected
by the questioner and they often look for
clues in the questions. Many apparently
neutral questions can potentially lead to
bias.

Level of details
› It is important to ask for the exact level of
›
›
›
›
details required.
On the one hand, you might not be able to
fulfill the purposes of the survey if you omit to
ask essential details.
On the other hand, it is important to avoid
unnecessary details.
People are less inclined to complete long
questionnaires.
This is particularly important for confidential
sensitive information, such as personal
financial matters or marital relationship
issues.
Questionnaires must be pretested - on a
small sample of people characteristic of
those in the survey.
 This gives an idea of the questions that
may need to be rephrased
 Deletions
 Additions

Look at all the current documents
 Are workers using any self created
documentation
 Are there old we aren’t using them
documents?

› These are good in helping you avoid things
that they already found useless
› Or by asking why aren’t you using them you
can maybe see how to integrate what they
needed into the current model.

Sit and watch
› Show you what’s happening
› Versus what’s suppose to happen

Do not disturb people
› Jot down questions for later
› Remember watched people are watching
their p’s and q’s
You need to pick the right technique
 Some things to consider when choosing
a technique

You need to know the type of information
How detailed your information is
The range covered by the information
Is the information integrated among various
sources
› How involved is your user
› What is the cost
›
›
›
›
INTERVIEWING USERS—TIPS
http://www.jiludwig.com/Interviews.html
 Wikipedia - Joint application design
http://en.wikipedia.org/wiki/Joint_applicati
on_design
 How to design a questionnaire
http://student.bmj.com/back_issues/0601/
education/187.html
