The book mentions that Understanding the Real Problem find the true essence of the business, and so deliver the right product—one that solves the right problem.

Abstraction

The book mention that in this step is drawing away or removing physical implementation so as to reduce it to its essential characteristics. In other words, an abstraction is the idea, not the implementation.

SOLVING THE RIGHT PROBLEM

In this point, the book mentions the elements to consider to solve a problem using proper strategies

SOLVING THE RIGHT PROBLEM

The book defines solving the right problem involves questioning and enhancing the current business essence to make the business more effective, efficient, and innovative.

HOW TO BE INNOVATIVE

The book mention that to be innovative, business analyst have to looking for ways to improve his client’s work, and these improvements almost always come about through innovation.

The book also describes these concepts:

SYSTEMATIC THINKING: As an idea of innovate systematically

Starbucks is now throwing more support behind its refreshment category.

VALUE: Capability of the product to be worthwhile

As a brand that can have a daily interaction with its customers, there is an expectation for Starbucks to innovate and lead the category at pace and scale. This comes to life across three main areas: people, place and product.

They always ensure that they will continue to support customers values as part of what they do every day.

PERSONAS: When real users are not available or are too numerous for you to interview all of them. The persona is a virtual character that substitutes for the human users.

 

 

This Chapter, describes the scenarios and the steps to recognize the activities into them.

Those scenarios are related with current conditions of the business, and how Business Analyst works to improve solutions to these conditions.

1- Business Use Case Name

2- Trigger

3- Preconditions

4- Interested Stakeholders

5- Active Stakeholders

6- Outcome

ALTERNATIVES:

The book mentioned that alternatives arise when you wish the user to have a choice of possible actions. These choices are intentional, as they are wanted and defined by the business.

EXCEPTIONS:

The book mentioned that exceptions are unwanted but inevitable deviations from the normal case. They are unwanted in the sense that the owner of the work would rather that they did not happen.

MISUSE CASES AND NEGATIVE SCENARIOS

The book mention that exceptions are misuse cases show negative or harmful possibilities, such as someone abusing the work or attempting to defraud it.

 

 

In this Chapter, authors comprehend the possible problems during the developing process of the project, and how teams make the planning to have a clear vision of the scope to avoid these difficulties.

Blastoff deliverables:

• Purpose of the project: Quantified statement of what the product is intended to do.
• Scope of the work: Understand the area affected before developing the project
• The Stakeholders: People interested in the project
• Constraints:Restrictions on the scope or style of the product.
• Names: Terminologies to be used in the project.
• Relevant facts and assumptions: Possible assumptions that project need to consider
• The estimated cost: Possible expenses
• The risks: to reveal the main risks faced by the project
• Go/no go decision: Viability decition

 

Formality Guide

Rabbit: should have a sketch of the work scope diagram pinned to the wall close to their user stories; close by should be a list of stakeholders

Horse: should be more formal and hold a blastoff meeting; they should also record their deliverables and communicate them to the appropriate stakeholders

Elephant project: should take the additional step of having the quality assurance (QA) people test their blastoff deliverables: Elephant projects are critical, and costly if they make errors, so the foundation of the requirements must be proved to be rock solid. Risk analysis and cost estimation are important to elephant projects; having a clearly defined and properly understood work scope is crucial.

SETTING THE SCOPE

The author describes this point as a way to understand what that owner is doing, and what he wants to do, if you are to deliver optimal value. In any event, if you want to build something valuable, then you have to understand what the owner values and what he is trying to achieve when he uses your product.

 

 

This Chapter of the book, describes a requirements process that authors have derived from their years of working in the requirements arena—working with clever people who do clever things, and working on projects in wonderfully diverse domains.

The Volere Requirements Process:

PROJECT BLASTOFF

The key purpose of the project blastoff is to build the foundation for the requirements discovery that is to follow, and to ensure that all the needed components for a successful project are in place. The principal stakeholders—the sponsor, the key users, the lead requirements analyst, technical and business experts, and other people who are crucial to the success of the project—gather together to arrive at a consensus on the crucial project issues.

TRAWLING FOR REQUIREMENTS

Each business use case is an amount of functionality needed by the work to make the correct response to a business event. (These terms will be fully explained soon.) A requirements analyst is assigned to each of the business use cases—the analysts can work almost independently of one another—for further detailed study. The analysts use trawling techniques such as apprenticing, scenarios, use case workshops, and many others to discover the true nature of the work.

QUICK AND DIRTY MODELING

One quick and dirty modeling technique the book mention is using Post-it notes to model functionality; each note can be used to represent an activity, and the notes can be rapidly rearranged to show different ways the work is done or could be done. The authors find that stakeholders relate to this way of modeling their business processes, and are always willing to participate with hands-on manipulation of the Post-its to show what they think the work should be.

SCENARIOS

Scenarios show the functionality of a business process by breaking it into a series of easily recognizable steps, written in English (or whatever language you use at work) so that they are accessible to all stakeholders. The IceBreaker analysts used scenarios to describe the business processes and present their understanding of the needed functionality. These scenarios were then revised as needed—different stakeholders took an interest in different parts of the scenario, and after a short time, the business analysts were able to have everyone understand and come to a consensus on what the work was to be.

WRITING THE REQUIREMENTS

QUALITY GATEWAY

To ensure correctness, the quality gateway tests the requirements. The IceBreaker team has set up a single point that every requirement must pass through before it can become a part of the specification. This gateway is manned by two people—the lead requirements analyst and a tester—and they are the only people authorized to pass requirements through the gateway. Working together, they check each requirement for completeness, relevance, testability, coherency, traceability, and several other qualities before they allow it to be passed to the developers.