Chapter 5 - Investigating the Work
The starting point for any product that will be built is the owner's work.
The book mentions that business analysts go "trawling" after business requirements.
The first task in the business requirements gathering process is to understand and investigate the work that is being done. Once that's understood, then the "essence needs to be understood, that is the clean picture of the business, without technology.
In this chapter the "Brown Cow Model" is also introduced. Which is divided into 4 parts:
The book mentions that business analysts go "trawling" after business requirements.
The first task in the business requirements gathering process is to understand and investigate the work that is being done. Once that's understood, then the "essence needs to be understood, that is the clean picture of the business, without technology.
In this chapter the "Brown Cow Model" is also introduced. Which is divided into 4 parts:
- How-Now: shows the implementation of the work as it currently exists, including physical artifacts, people and processors to do the work.
- What-Now: shows the real business policy (essence). No machines, people, or organizational departments.
- Future-What: shows the business as your owner wants to have it, but still with no technology applies to it.
- Future-How: shows the idealized future business policy, augmented with the technology and people needed to bring it into the real world.
Some techniques to understand the "How-Now" of the business are:
- Apprenticing
- BUC Workshops (desired outcomes, scenario and business rules must be provided to participants.
- Interview stakeholders
- Look for reusable requirements
- Use quick and dirty process modeling: Post-its
- Prototypes and sketches
- Mindmaps
- Murderbooks
- Photographs and videos
- Wikis, blog and discussion forums
- Document archeology
- Family therapy
The main message in this chapter is that before providing any type of solution, it's fundamental to fully understand the work.
Source: Mastering the Requirements Process - Getting Requirements Right; pages: 86- 127
The term trawling to depict the movement of exploring the business. This term brings out the idea of what we are doing here: angling. Not inactively dangling a line while trusting a fish may drop by, yet rather systematically maintaining a net through the business to get each conceivable necessity. With a little encounter and great systems, the captain of a trawler realizes where to angle so he gets the fish he needs, and maintains a strategic distance from the ones that doesn't. A business expert trawls for information by exploring the customer's work. The similarity of running a net through the association is fitting: You have to filter through a great part of the business before you can locate the most ideal approach to improve it.
ReplyDeleteApprenticing—
ReplyDeleteBased on the old idea of masters and apprentices—is a wonderful 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 capture all the requirements—if you
are away from your work, you tend to generalize. Generalizations can be useful, but they do
not provide enough detail for them to work every time.
If the user is doing his job in his normal workplace, he can provide a running commentary and
provide details that might otherwise be lost. So if you want to get an accurate explanation of
the work, go to the work; sit beside the user in the normal workplace and get a running
commentary on the work as it happens. While he is working, the user can describe his task
precisely and tell you why he is doing things. If the explanation is not clear, the apprentice asks
questions: “Why did you do that?” “What does this mean?” “How often does this happen?”
“What happens if this piece of information is not here?” You also get to see the things that can
go wrong, and the special cases, and the work-arounds he uses when things are not normal.
Through the process of apprenticing, you come to see all the cases and the actions the user
takes for each.
Prototyping and sketching—they are actually something very similar—can be powerful procedures for inspiring necessities. The fundamental thought is to outline some proposed item, and afterward figure out the necessities from the sketch. This is an especially helpful methodology in the accompanying circumstances:
ReplyDelete● The item has not existed previously, and it is hard to picture.
● The partners for the item have no involvement in either the sort of item or the proposed innovation.
● The partners have been doing their work for quite a while and are stuck in the manner that they do it.
● The partners are experiencing difficulty articulating their prerequisites.
● The necessities investigators are experiencing difficulty understanding what is required.
● The attainability of a prerequisite is in question.