In this module, we come to an understanding of what the business is doing and start to think about what it might like to do.
TRAWLING THE BUSINESS
We use the term trawling to describe the activity of investigating the business.
This term evokes the nature of what we are doing here: fishing. Not idly
dangling a line while hoping a fish might come by, but rather methodically running a net through the business to catch every possible requirement.
TRAWLING THE BUSINESS
We use the term trawling to describe the activity of investigating the business.
This term evokes the nature of what we are doing here: fishing. Not idly
dangling a line while hoping a fish might come by, but rather methodically running a net through the business to catch every possible requirement.
With a little experience and good techniques, the skipper of a
trawler knows where to fish so that he gets the fish he wants, and avoids the
ones that he doesn’t. The objective in this chapter is to show you some trawling
techniques, and give you guidelines on how to get the best from them.This chapter explores the techniques for discovering the business processes and the people involved in those processes. Inevitably, you will need a variety of techniques to achieve this feat, and you will find that not all
techniques are equally acceptable to your stakeholders. For this reason, it
will be necessary to vary your approach to best suit the stakeholders who are
providing the requirements.
TWARL FOR KNOWLEDGE
We build products to help us do work. For our purposes, it doesn’t matter
whether the work is processing insurance claims, analyzing blood samples,
designing automotive parts, predicting when ice will form on roads, keeping
track of a “things to do” list, controlling a telephone network, downloading music or movies, monitoring a household, manipulating photographs, or
one of many other human activities. In all instances, the product that you
are being asked to build must improve this work.
THE BUSINESS ANALYST
The business analyst is also known as a systems analyst, a requirements engineer,
and probably several other titles. We use “business analyst” because it
is the most commonly used name. Whatever name you use, this person is
an investigator and a translator: 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. Tasks of the business analyst are as follow:
Observe and learn the work, and understand it from the point of view of the
owner. As you work with your users, you study their work and question
them about what they are doing, and why they are doing it.
● Interpret the work. A user’s description of some work is not always factual
despite the user being the expert on that part of the work. The analyst
must filter the description to strip away the current technology, thereby
revealing the underlying essence of the work, not its incarnation.
● Record the results in the form of stakeholder-understandable analysis models.
The analyst must ensure that he and the stakeholders have the
same, and agreed, understanding of the work. We suggest using models
as a common language for communicating your knowledge to the
stakeholders.
THE BROWN COW MODEL
Good research Simran.
ReplyDeleteI want to go into details for some crucial aspects.
Interviewing the Stakeholders: It is the common technique used by the projects to gather requirements. However, it should not be the only technique. Interviews should be conducted with the existence of other techniques.
In the interviewing part, we rely on the stakeholders to gather as much knowledge as possible. It requires some communication ability on the side of stakeholders. This method could not be much successful where, interviewee is not familiar. That is why, it should not be the single method to get the information.
In the preparation of the interview, sometimes the questionnaires are sent to the interviewee is advance. These questionnaires may include a brief description of the topic, so that interviewee have some ideas to think and speak about.
Stakeholders should be involved as much as possible by using building models like use case, business event response. We could use some guidelines to make interview effectives like,
Limiting the duration
Asking questions and listening to answers properly
drawing models for information
Keep samples or artifacts for future references
Asking the right questions:
Here is the another crucial factor which is asking the right questions while using the methods like Brown Cow.
Business analysts should use open questions which starts from "What, How, When, Where, Why or Who". The answers should be detailed enough rather than just answering in "yes" or "no".
Good job guys!
ReplyDeleteTalking about the formality guy, on the chapter 5, we learned that the Rabbit project demand to explain the work as it currently is, as well as what the work is to be. Because rabbit projects are usually constant, you are inclined to inspect the current work in small portion and then proceed to locate its
core and conclusively its result.
Horse projects, due to their larger number of stakeholders, supposedly produce more extensive need of apprenticing, interviewing, and use case workshops. These techniques make some documentation, and while documenting the ongoing work is by no means the intention of the project, it is too good as input to consecutive resolution.
Elephant projects, due to their larger number of stakeholders, require documenting their discovery as they work about trawling for their requirements. Because of the more large-scale set of possibilities for elephant projects, we propose that you read this integral chapter, paying certain attention to the “owl
endorsement.”
Good work team !
ReplyDeleteI would like to continue and explain what apprenticing is:
Apprenticing—based on the old idea of masters and apprentices—is a won-
derful way to observe and learn the work as it really happens. In this case,
the requirements analyst is the apprentice, and the user assumes the role of
master craftsman. The analyst sits with the user at the user’s place of work,
learning the job by making observations, asking questions, and perhaps
doing some of the work under supervision. This technique is also sometimes
known as “job shadowing.”
It is unlikely that many users can explain what they do in enough detail
for the business analyst to completely understand the work and thereby cap-
ture all the requirements—if you are away from your work, you tend to gen-
eralize. Generalizations can be useful, but they do not provide enough detail
for them to work every time.
Nor can you expect users to have the presentation and teaching skills
needed to present their work effectively to others. Conversely, almost every-
one is good at explaining what they are doing while they are doing it.