Lecture#8

Requirement Elicitation
 Business Use Cases

Business events are

determined using the
triggering data flows from the
adjacent systems on the
context diagram. The
business use cases are the
work’s responses to the
business events, and these are
studied until the analyst
understands the way the work
functions.
 Trawling for Knowledge

The business analyst trawls for knowledge by

investigating the client’s work. The analogy of
running a net through the organization is
appropriate: You need to sift through much of the
business before you can find the best way to improve
it.
 The job of the analyst
✦ He has to inspect the work, interview the business
stakeholders, understand what they are saying, and
then translate that knowledge into a form that can be
communicated to and understood by the developers.
• Observe and learn the work, and understand it from the point
of view of the owner.
• Record the results in the form of stakeholder-understandable
analysis models.
 Brown Cow Model
Current Future
business policy/essence business policy/essence

Current Future
implementation implementation
 Brown Cow Model
✦ How-Now: Current Implementation of the work,
including people, technology, processes, etc.
✦ What-Now: Current essence (business policy),
technologically neutral.
✦ What-Future: The business as your owner wants to
have it, but still without the technology that might be
used to implement that business.
✦ How-Future: How you implement the future
business.
 Models of How-Now
✦ Building models as a way of investigating the work is
best done when you need to :
• understand a medium-to-large work area for which no
documentation exists.
• This technique is also used when the current users struggle to
give you an idea of how the work fits together.
• It is also useful when you know that there will be a significant
legacy from the existing work.
 Building Models

Knowing where to ask questions, and

which questions to ask, is almost as
useful as knowing the answers. If your
model has flows going nowhere,
processes without inputs, read-only
or write-only data stores, or other
breaches of the modeling
conventions, then you need to ask
your stakeholders more questions
about those aspects of the work.
 Data Flow Model

Process for interrogating commercial databases. This model shows the technology used for the task. As the user
described the work, the modeller modelled and demonstrated their understanding. This model uses conventional
data flow notation. Most process models would do the job equally well, so use whichever model you are most
familiar with.
 Modelling - Activity Diagram

A UML activity diagram showing the same piece of work. Business analysts should use whatever models they feel most comfortable
with.
 Quick and Dirty Process
Modelling

With quick and dirty process

modeling, the business
analyst uses Post-it notes to
build an informal model of the
work. Large notes are stuck
on the wall and linked by
masking tape. Naturally,
interested stakeholders are
partners in this modeling
activity.
 Apprenticing

The requirements analyst

learns the work while sitting
at the user’s desk, sometimes
building models of the work
while learning it.
 Business Use Case
Workshops

The business use case workshop

records the proposed
functionality using scenarios and
sketched prototypes. The
workshop serves as a forum for
interested stakeholders to
communicate effectively, express
their understanding, ask
questions, and give their
aspirations for the work.
 Workshop outcomes
✦ Desired outcome for the BUC
✦ A normal case scenario that describes the work done
by the BUC
✦ Exception scenarios describing what can go wrong
and what the work does to correct them (these can
be postponed until later if desired)
✦ The business rules are management prescriptions:
e.g., The maximum length of a truck driver’s shift is 5
hours.
✦ Sketched prototypes used to help stakeholders
visualize the business use case—these throwaway
sketches are optional and are not intended to be
kept beyond the requirements phase
 Interviewing Stakeholders
✦ Some requirements analysts draw up a questionnaire
and send it to the stakeholder in advance of the
interview
✦ Stakeholders should not remain completely passive
during the interview (Feedback loops are useful)
✦ Keep the brown cow model in mind..
 Interview Guidelines
✦ Guidelines:
• Set the interview in context
• Limit the duration of the interview to the time stated in the agenda
• Have business use cases serve as an anchor for the interview
• Ask a question, listen to the answer, and then feed back your
understanding
• Draw models and encourage the user to change them
• Use the stakeholders’ terminology and artifacts, both conceptual
and real.
• Keep samples or copies of artifacts and log them for future
reference
• Thank the stakeholders for their time and tell them what you
learned and why it was valuable
• Write down what you were told. We guarantee you’ll have more
questions.
 Reusable Requirements
✦ Why sending rockets to space is so expensive?
✦ The rocket cannot be reused.
✦ Cost: 1.5 billion per flight..
 Reusable Requirements
✦ Many of the our projects deliver similar products.
✦ That is, if you work for a finance house, then almost
all of your projects will deliver some kind of financial
system.
✦ Given that your organization has been doing this for
a number of years, it is likely that someone, at some
time, has studied a piece of work that is similar to
yours and has written requirements for a product that
is similar to yours.
✦ You don’t have to do it all again when you can
borrow from those who have gone before.
 Prototypes and Sketches

Requirements prototypes are used to display the functionality of a potential product.

The prototype is intended to prompt stakeholders to tell you whether you have
understood the needed functionality and, as a result of “using” the prototype, to give
you additional requirements suggested by it.
 Prototypes and Sketches
✦ The product has not existed before, and it is difficult
to visualize.
✦ The stakeholders for the product have no experience
with either the kind of product or the proposed
technology.
✦ The stakeholders are having trouble articulating their
requirements.
✦ The requirements analysts are having trouble
understanding what is required.
✦ The basic idea is to sketch some proposed product,
and then reverse engineer the requirements from the
sketch.
 Low or High?
✦ Low Fidelity Prototypes (Sketches)
• Helps the stakeholder focus on the subject matter
• Pencils, whiteboards, flip charts, Post-it notes, index cards
✦ High-Fidelity Prototypes
• Built using software tools and have the appearance of working
product
• Effective for discovering usability requirements
Mind Maps
 The Murder Book
✦ Collect every document and other piece of
“evidence” into a binder, sometimes several binders.
✦ Intention is to create a trail of items that can be
referred to later from a central
✦ The technique is simple: Add every document,
interview note, model, mind map, user story, and
paper prototype—in fact, everything—to the murder
book
✦ Add your artifacts in chronological order
 Videos & Photographs
✦ A video or photograph is a way of capturing some
moments in time so that you can study them later.
✦ It is a particularly useful technique if you want to
show the current work to people who cannot visit the
stakeholders’ workplace.
✦ Take photos of whiteboards—to show the
progression of ideas—and refer back to these
images and include some of them in documents.
✦ Video and photographs are especially useful tools for
distributed teams.
 Wikis, Blogs, Discussion
Forums
✦ This technique can apply to many types of projects.
✦ However, because it requires participation from a
number of stakeholders, it is most effective for larger
projects.
✦ You can use the web to find out about similar
projects.
SCENARIOS
How Now to What Now
A scenario tells the story of the business use case
An airline check-in for
an international flight.
As we go through the
scenario for this case,
see if it matches your
experience of
checking in for a flight.
Airline Check-In
 “I call the next customer in line. When he gets to my desk, I ask for a
ticket. If the passenger is using an e-ticket, I need the booking record
locator. Most of the passengers are not organized enough to have it
written down, so I ask them their name and the flight they are on. Most
people don’t know the flight number, so I usually ask for their
destination. They must know that!
“I make sure I have the right passenger and the right flight. It would be
pretty embarrassing to give away someone else’s seat or to send a
passenger to the wrong destination. Anyway, somehow I locate the
passenger’s flight record in the computer. If he has not already given it to
me, I ask for the passenger’s passport. I check that the picture looks like
the passenger and that the passport is still valid.
“If there is no frequent-flyer [FF] number showing against the booking, I
ask the passenger if he belongs to our mileage scheme. Either he hands
me the plastic card with the FF number, or I ask him and if he wishes to
join I give him the sign-up form. We can put temporary FF numbers
against the flight record so the passenger is credited for that trip.
“If the computer has not already assigned a seat, I find one. This usually means I ask
if the passenger prefers a window or an aisle seat, or, if the plane is already almost
full, I tell him what I have available. Of course, if the computer has assigned a seat, I
always ask if it is okay. One way or another we settle on a seat and I confirm it
with the computer system. I can print the boarding pass at this stage, but I usually
do the bags first.

“I ask how many bags the passenger is checking and, at the same time, verify that
he is not exceeding the carry-on limit. Some people are unbelievable with what
they want to carry into a fairly space-restricted aircraft cabin. I ask the security
questions about the bags and get the passenger’s responses. I print out the bag tags
and securely attach them to the bags, and then I send the bags on their way down
the conveyor belt.

“Next I print the boarding pass. This means that I have everything done as far as
the computer is concerned. But there is one more thing to do: I have to make sure
that everything agrees with the passenger’s understanding. I read out from the
boarding pass where he is going, what time the flight is, and what time it will board,
and if a gate has been assigned, I tell him that, too. I also read out how many bags
have been checked and confirm that their destination matches the passenger’s
destination. I hand over the documents, and wish the passenger a good flight.”
 Draft One
✦ Sketch out the scenario.
✦ Break the story down to the steps that you consider to
be the best ones to capture the normal path through
the story.
 Formalized Scenario
✦ Part I: identity and name

✦ Part II: Start up mechanism or trigger. Data and

request coming from outside the work, or time-
triggered event.

✦ Part III : Pre-conditions. They indicate the state of

the work at initiation. Usually this means certain
other business events must have occurred before
this business use case makes any sense.
 Formalized Scenario
✦ Part IV (optional): Interested Stakeholders. These
people have an interest in the outcome of the
business use case.

✦ Part V: Active Stakeholders. Active stakeholders are

the people or systems that do the work of the
business use case.
How Now to What Now
 How-Now, What-Now

Before

After

Before

After
Before

After

Or
An activity
diagram showing
the passenger
checking in for a
flight. This is the
equivalent of the
scenario shown
previously.
Alternatives
 Exceptions

✦ What happens if this step cannot be completed, or does not go to completion,

or comes up with a wrong or unacceptable result?
✦ What can go wrong at this step?
✦ What could happen to prevent the work from reaching this step?
✦ Could any external entity disrupt or prevent this step, or this business use
case?
✦ Could any technology used to implement this step fail or become unavailable?
✦ Could the end user fail to understand what is required of him, or mis-
understand the information presented by the product?
✦ Could the end user take the wrong action—intentionally or unintentionally—or
fail to respond?
What-if? Scenarios
 Mis-use Cases & Negative
Scenarios
Misuse cases (you might like to think of them as “unhappy
cases”) show negative or harmful possibilities, such as
someone abusing the work or attempting to defraud it.
Scenario Template