Requirement elicitation

techniques

Nehal kanoun 2778

1. Discuss interviews , workshops , observations , Questionnaires techniques

2. Explain the user interface analysis

3. Talk about importance of document analysis

4. Discuss duration of elicitation process

5. Outline techniques of undiscovered requirement

1. Interviews are a traditional source of requirements input for both commercial products and
information systems, across all software development approaches. Most BAs will facilitate some
form of individual or small-group interviews to elicit requirements on their projects

Establish rapport :To begin an interview, introduce yourself if the attendees don’t already know you,
review the agenda, remind attendees of the session objectives, and address any preliminary questions
or concerns attendees have.

Stay in scope : As with any elicitation session, keep the discussion focused on its objective. Even when
you are talking with just one person or a small group, there’s a chance the interview will go off topic.
Prepare questions and straw man models ahead of time :Prepare for interviews by drafting any
materials you can beforehand, such as a list of questions to guide the conversation. Draft materials will
give your users a starting point to think from. People can often critique content more easily than they
can create it.

Suggest ideas :Rather than simply transcribing what customers say, a creative BA proposes ideas and
alternatives during elicitation. Sometimes users don’t realize the capabilities developers can provide;
they might get excited when you suggest functionality that will make the system especially valuable

Listen actively: Practice the techniques of active listening (leaning forward, showing patience, giving
verbal feedback, and inquiring when something is unclear) and paraphrasing (restating the main idea of
a speaker’s message to show your understanding of that message)
2. Workshops encourage stakeholder collaboration in defining requirements. Ellen Gottesdiener
(2002) defines a . requirements workshop as “a structured meeting in which a carefully selected group
of stakeholders and content experts work together to define, create, refine, and reach closure on
deliverables (such as models and documents) that represent user requirements.” Workshops are
facilitated sessions with multiple stakeholders and formal roles, such as a facilitator and a scribe.
Workshops often include several types of stakeholders, from users to developers to testers.

Establish and enforce ground rules The workshop participants should agree on some basic operating
principles. Examples include starting and ending on time; returning from breaks promptly; silencing
electronic devices; holding one conversation at a time; expecting everyone to contribute; and focusing
comments and criticisms on issues rather than individuals

Fill all of the team roles A facilitator must make sure that the following tasks are covered by people in
the workshop: note taking, time keeping, scope management, ground rule management, and making
sure everyone is heard. A scribe might record what’s going on, while someone else watches the clock.
Plan an agenda Each workshop needs a clear plan, as discussed in the “Preparing for elicitation”
section later in this chapter. Create the plan and workshop agenda ahead of time, and communicate
them to participants so they know the objectives and what to expect and can prepare accordingly

Stay in scope Refer to the business requirements to confirm whether proposed user requirements lie
within the current project scope. Keep each workshop focused on the right level of abstraction for that
session’s objectives.

Use parking lots to capture items for later consideration An array of random but important
information will surface during elicitation discussions: quality attributes, business rules, user interface
ideas, and more.
Timebox discussions Consider allocating a fixed period of time to each discussion topic. The discussion
might need to be completed later, but timeboxing helps avoid the trap of spending far more time than
intended on the first topic and neglecting other important topics entirely.

Keep the team small but include the right stakeholders Small groups can work much faster than
larger teams. Elicitation workshops with more than five or six active participants can become mired in
side trips, concurrent conversations, and bickering.

Keep everyone engaged Sometimes certain participants will stop contributing to the discussion. These
people might be frustrated for a variety of reasons. Perhaps their input isn’t being taken seriously
because other participants don’t find their concerns interesting, or maybe they don’t want to disrupt the
work that the group has completed so far.
3. Observations When you ask users to describe how they do their jobs, they will likely have a hard
time being precise—details might be missing or incorrect

Observations are time consuming, so they aren’t suitable for every user or every task. To avoid
disrupting the users’ regularly assigned work activities, limit each observation time to two hours or less.
Select important or high-risk tasks and multiple user classes for observations. If you use observations in
agile projects, have the user demonstrate only the specific tasks related to the forthcoming iteration
4. Questionnaires are a way to survey large groups of users to understand their needs. They are
inexpensive, making them a logical choice for eliciting information from large user populations, and
they can be administered easily across geographical boundaries.

■ Provide answer options that cover the full set of possible responses.
■ Make answer choices both mutually exclusive (no overlaps in numerical ranges) and exhaustive (list all
possible choices and/or have a write-in spot for a choice you didn’t think of)
■ Don’t phrase a question in a way that implies a “correct” answer.
■ If you use scales, use them consistently throughout the questionnaire.
■ Use closed questions with two or more specific choices if you want to use the questionnaire results
for statistical
analysis. Open-ended questions allows users to respond any way they want, so it’s hard to look for
commonalities in the results.
■ Consider consulting with an expert in questionnaire design and administration to ensure that you ask
the right questions of the right people.
■ Always test a questionnaire before distributing it. It’s frustrating to discover too late that a question
was phrased ambiguously or to realize that an important question was omitted.
■ Don’t ask too many questions or people won’t respond.
 Explain the user interface analysis

1. User interface (UI) analysis is an independent elicitation technique in which you study
existing systems to discover user and functional requirements. It’s best to interact with the existing
systems directly, but if necessary you can use screen shots. User manuals for purchased packaged-
software implementations often contain screen shots that will work fine as a starting point. If there
is no existing system, you might be able to look at user interfaces of similar products.

When working with packaged solutions or an existing system, UI analysis can help you identify a
complete list of screens to help you discover potential features. By navigating the existing UI, you can
learn about the common steps users take in the system and draft use cases to review with users.
 Talk about importance of document analysis

1. Document analysis entails examining any existing documentation for potential software
requirements. The most useful documentation includes requirements specifications, business
processes, lessons,learned collections, and user manuals for existing or similar applications.
Documents can describe corporate or industry standards that must be followed or regulations with
which the product must comply. When replacing an existing system, past documentation can reveal
functionality that might need to be retained, as well as obsolete functionality

2. Document analysis is a way to get up to speed on an existing system or a new domain. Doing
some research and drafting some requirements beforehand reduces the elicitation meeting time
needed. Document analysis can reveal information people don’t tell you, either because they don’t
think of it or because they aren’t aware of it.
 Discuss duration of elicitation process

■ Elicitation objectives Plan the elicitation objectives for the entire project and the objectives for each
planned elicitation activity.

■ Elicitation strategy and planned techniques Decide which techniques to use with different
stakeholder groups. You might use some combination of questionnaires, workshops, customer visits,
individual interviews, and other techniques, depending on the access you have to stakeholders, time
constraints, and your knowledge of the existing system.

■ Schedule and resource estimates Identify both customer and development participants for the
various elicitation activities, along with estimates of the effort and calendar time required. You might
only be able to identify the user classes and not specific individuals up front, but that will allow
managers to begin planning for upcoming resource needs.
■ Documents and systems needed for independent elicitation If you are conducting document,
system interface, or user interface analysis, identify the materials needed to ensure that you have them
when you need them.

■ Expected products of elicitation efforts Knowing you are going to create a list of use cases, an SRS,
an analysis of questionnaire results, or quality attribute specifications helps ensure that you target the
right stakeholders, topics, and details during elicitation.

■ Elicitation risks Identify factors that could impede your ability to complete the elicitation activities as
intended, estimate the severity of each risk, and decide how you can mitigate or control it
 Outline techniques of undiscovered requirement

■ Decompose high-level requirements into enough detail to reveal exactly what is being requested. A
vague, high-level requirement that leaves much to the reader’s interpretation will lead to a gap between
what the requester has in mind and what the developer builds.

■ Ensure that all user classes have provided input. Make sure that each user requirement has at least
one identified user class who will receive value from the requirement.

■ Trace system requirements, user requirements, event-response lists, and business rules to their
corresponding functional requirements to make sure that all the necessary functionality was derived.

■ Check boundary values for missing requirements. Suppose that one requirement states, “If the price
of the order is less than $100, the shipping charge is $5.95” and another says, “If the price of the order is
more than $100, the shipping charge is 6 percent of the total order price.”
■ Represent requirements information in more than one way. It’s difficult to read a mass of text and
notice the item that’s absent. Some analysis models visually represent requirements at a high level of
abstraction—the forest, not the trees

■ Sets of requirements with complex Boolean logic (ANDs, ORs, and NOTs) often are incomplete. If a
combination of logical conditions has no corresponding functional requirement, the developer has to
deduce what the system should do or chase down an answer

■ Create a checklist of common functional areas to consider for your projects. Examples include error
logging, backup and restore, access security, reporting, printing, preview capabilities, and configuring
user preferences.

■ A data model can reveal missing functionality. All data entities that the system will manipulate must
have corresponding functionality to create them, read them from an external source, update current
values, and/or delete them
 Resources

 Software Requirements, Third Edition