Chapter - 7 Understanding the Real Problem

This chapter is of particular importance to rabbits. 

As a rabbit project, you are likely to be using techniques such as story cards, Post-it notes, or sketches on a whiteboard. These artifacts display, more often than not, proposed solutions to unstated problems.The essence does not have to be written as the first draft of the story card (it helps if it is) but it must be revealed during the requirements conversation.

Horse projects’ aspirations to informality are helped if the business analysts and the stakeholders talk about only the essence of the work. Using this approach, they generate fewer models and possibly cut down on the amount of communication needed.

Elephant projects might involve outsourced development, in which case it is vital that they solve the right problem. If not, the delivered product has to be corrected and the outsource charges for the corrections.

The Brown Cow Model

Abstraction 

At this stage, it might be helpful to talk a little about abstraction. Abstraction and getting to the essence are pretty much the same thing, but possibly abstraction is the more natural way to think about this concept. The word has Latin roots—abs, which “means away from,” and trahere, which means “to draw.” Thus abstraction, as we use the term here, 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 

The way of thinking discussed here follows from understanding the abstracted essence. This section is relevant to all requirements analysts, regardless of the size or nature of the project. It is equally applicable to iterative and traditional development methods.

Moving into the Future 

So far in this book we have been looking at the current implementation of the business, and then deriving the essence of the business and arriving at the correct problem to solve. Of course, all this activity relates to the current business, its current technology, and its current essence. If you refer to the Brown Cow Model, you have achieved respectively the How-Now and the What-Now views of the work. 

-------------------------------------------------------------------------------

We suggest something along these lines for planning and running innovation workshops: 

1. Set the scope of the innovation. It should not be too narrow, as many innovations are originally thought of as outside the remit of the team. Invite all stakeholders who have an interest in this scope to participate in the workshop. 

2. Partition the scope using business events to allow the participants to concentrate on the end-to-end business processes, while keeping in mind that systemic thinking usually involves all of the business events. 

3. Plan the workshop. You will probably have to use several innovation techniques. Some of these are discussed in this book, and a number of excellent texts on creativty also available. You will have to facilitate the workshop and lead your stakeholder through the techniques. 

4. Record everything that happens in the workshop. Do not try and assess ideas during the workshop. Innovating and assessing are two separate activities and should not be tackled at the same time. 

5. After the workshop, feed the results back to participants. 

6. Incubate. Sometimes the really great idea does not happen for some time. People are quite capable of coming back days later with some profound improvement to one of the workshop innovations. These workshops are intended to be more structured than regular brainstorming sessions. The intention is to use a mixture of innovation techniques to generate a more interesting outcome. 

--------------------------------------------------------------------------------

Brainstorming Brainstorming 

It is one way of innovating. It is useful for generating lots of contributions regarding the scope of the problem,or what it could be. This strategy is not intended to promote unconstrained scope creep. Instead, the brainstorming session generates ideas that could lead to a better product without incurring additional expense.

Piggyback a new idea onto an old one. That is, build one idea on top of another. 

Write every idea down, without censoring. 

If you get stuck, seed the session with a word pulled randomly from a dictionary, and ask participants to make word associations that have some bearing on the product. 

Make the session fun. You cannot mandate creativity; you have to let it come naturally. 

You won’t see many ground-breaking ideas if the boss is present at the session and says something like, “I want to hear only ideas that are marketable.” 

Back to the Future 

Let’s return to what we are doing here. Your task is to change the current work into the future work, or as we have described it previously, to transform the How-Now into the Future-What. Looked at it another way, this effort involves changing business policy, and the new policy should be innovative. As we have said several times—and it is worth repeating—there is little value in simply re implementing some old piece of work. If your project is to provide something valuable to the organization, then it must provide an advance, some fresh thinking, to make the end product as useful as possible. 

Chapter 5 - Investigating the Work

Chapter 5 - Investigating the Work

Author: Zac Dewit

Trawling 

• Trawling is usually a term for fishing. It defines hanging out your net and continuing to drive the boat so that fish will be caught without much effort as they can be unaware they were caught. This also applies to requirements gathering. 
• A person that is good at trawling will know where to find the fish or information as it is usually in similar locations from one day to the next. Once you have found a spot that works, it can be smart to revisit it for future projects.
• It is also important to realize that you can't be too slow whilst doing this. You need to get through this stage so the project can truly begin. Do not worry as you can always come back if there is something you missed. 
• One last thing to realize is that all stakeholders are different and need to be addressed as such. You need to understand how the business works, how the project will help the business and what each stakeholder wants out of the project. 

Formality Guide

• For each of the project sizes, there are different guides to finding your requirements. 
• Rabbit - For these small projects (less than 6 months)  it is especially important to work as fast as you can. You are encouraged to go to the shop in small slices and to understand how it works and what needs to be fixed. Projects like this are usually iterative projects meaning they are repetitive and steps are usually repeated. Using a repeated process will also help you save on paperwork and other documentation. 
• Horse - Since a horse project (6 months to 2 years) has a high capacity of stakeholders, different techniques like apprenticing and interviewing are key. Use case workshops can also be a very helpful tool. These three tools can help with documentation which will help with the decisions later in the project. These projects can have a much larger scope and effect range. This means that the BA needs to have a greater knowledge of the company. 
• Elephant - Since these projects can take such a long time (over 2 years), it is important to keep up to date documentation. Other parts of elephant projects can include outsourcing. This also needs special documentation. 

Brown Cow Model

• One unique way of looking at the work and requirements is by using the brown cow model. This model splits everything into 4 sections. How now, What now, Future What, Future How.
• How now - This quadrant is the usual place to start. This shows how the work is being done currently. This view is the ground zero for where your new system or idea will come into play. It is important to realize that this new thing needs to be unique and different from the current way or else it is not worthwhile. There must be a change. 
• What now - This part is all about the essence of the work. This view is technologically neutral meaning it shows no direct link to the tech or humans within the company. It is a clean way of thinking about how the company operates.
• Future What - This is where you put your dreams. This being anything that you could want or need from your company. In this section you can put all the ambitions you have as an owner. 
• Future How - This last quadrant takes all the aspects of the previous and finds a technological way of solving and implementing that into the current system. 

Business Use Case Workshops

• A business use case or BUC is all about how business events trigger a response in the form of work. This work is then broken down and divided into manageable chunks.
• Now that the work is in chucks a helpful tool to analyze and make improvements is a BUC workshop. 
• In these workshops, the interested stakeholders discuss what work they are currently involved with and what they hope to do in the future. This is like the "how now" and " future what" sections of the brown cow model. 
• Then you can uses scenarios to help people understand what will help them achieve what they want. 

Interviewing Stakeholders

• Interviewing stakeholders is a basic way to understand what the company needs and what the solution to the problem could be. This is one of the simplest ways to understand the company and all the different aspects that can be changed.
• This, however, is not without its downsides as it requires the stakeholders to verbalize what they want. For some people that is easy but for many, it is difficult to explain what they do to someone who hasn't had their level of training. The BA also needs to ask specific and targeted questions so the interviewee can stay on track and give accurate replies. 

Chapter-4 Business Use Cases

Chapter-4
(Business Use Cases)

Created by:- Ramandeep Kaur

1. What are the business events and their responses?

Answer: A business event happens at the moment the adjacent system decides to do something, or as part of its work some processing condition occurs. The adjacent system tells the work that the event has happened by sending a triggering data flow. When this stream of data arrives, the work responds by processing the incoming data, and by retrieving and recording stored data.

2. Explain formality guide in business use case?

Answer: Rabbit—small, fast, and short-lived. Rabbit projects are typically smaller projects with shorter lifetimes, where close stakeholder participation is possible. Rabbit projects usually include a lesser number of stakeholders.

Horse—fast, strong, and dependable. Horse projects are probably the most common corporate projects—they are the “halfway house” of formality. Horse projects need some formality—there is likely a need for written requirements so that they can be handed from one department to another. Horse projects have medium longevity and involve more than a dozen stakeholders, often in several locations, factors that necessitate consistently written documentation.

Elephant—solid, strong, long life, and a long memory. An elephant project needs a complete requirements specification. If you are outsourcing the work, or if your organizational structure requires complete, written specifications, you’re an elephant. In certain industries, such as pharmaceuticals, aircraft manufacture, or the military, regulators demand not only that full specifications be produced, but also that the process used to produce them be documented and auditable. Elephant projects typically have a long duration, and they involve many stakeholders in distributed locations.

3. What is Time-Triggered Business Events with example?

Answer: A time-triggered business event happens when a prearranged time is reached. This is based on either a periodic occurrence (for example, the end of the month, or a certain time each day), a fixed time interval (for example, three hours since the last occurrence), or a certain amount of time elapsing since another business event (for example, 30 days after sending out an invoice). The normal response is to retrieve stored data, process it, and send some information to an adjacent system.

4. List of Business Events and Their Associated Input and Output Flows for the Road De-icing Work.

Answer: Event Name(Input and Output)
1. Weather Station transmits a reading Weather Station Readings (in) 
2. Weather Bureau forecasts weather District Weather Forecasts (in) 
3.  Road engineers advise there are changed roads Changed Road (in)
4.  Road Engineering installs a new weather station (in) 
5.  Road Engineering changes the weather station Changed Weather Station (in) 
6. Time to test Weather Stations Failed Weather Station Alert (out) 
7. Truck Depot changes a truck Truck Change (in) 
8. Time to detect icy roads Road De-icing Schedule (out) 
9. Truck treats a road Treated Road (in) 
10. Truck Depot reports a problem with a truck Truck Breakdown (in) Amended De-icing Schedule (out) 
11. Time to monitor road de-icing Untreated Road Reminder (out)

5. How Business Case Use is different from System Use Case?

Answer: Business Case Use: -A Business Use-Case is to do with “using a business”: this recognizes that businesses1 are created and organized to do things for people – mainly customers, but also other “actors”. So a Business Use-Case is a way in which a customer or some other interested party can make use of the business to get the result they want – whether it’s to buy an item, to get a new driving license, to pay an invoice, or whatever.


System Use Case:- In contrast, a System Use-Case is a way in which a user of a computer system can make use of the system to get the result they want. This will typically be something we can readily imagine as being done in a single sitting on a single PC or other devices such as an ATM or a mobile/cell phone, usually with a single UI, or a small number of closely-related screens such as a wizard, and taking maybe between a couple of minutes and a half-hour at most.

Chapter - 2 The Requirements Process

Project Blastoff

Imagine launching a rocket. 10 – 9 – 8 – 7 – 6 – 5 – 4 – 3 – 2 – 1 – blastoff! If all it needed were the ability to count backward from 10, then even Andorra1 would have its own space program. The truth of the matter is that before we get to the final 10 seconds of a rocket launch, a lot of preparation has taken place. The rocket has been fueled, and the course plotted—in fact, everything that needs to be done if the rocket is to survive and complete a successful mission.

Blastoff is also known as “project initiation,” “kickoff,” “charter,” “project launch,” and many other things. We use the term “blastoff” to describe what we are trying to achieve—getting the requirements project launched and flying.

Quick and Dirty Modeling

Models can be used at any time in the Volere life cycle, we show his activity as “Prototype the Work.” There are, of course, formal models such as you would find in UML or BPMN, but a lot of the time business analysts can make productive use of quick sketches and diagrams to model the work being investigated. One quick and dirty modeling technique we should mention here 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. We 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 what they think the work should be. We discuss this kind of modeling more fully in Chapter 5, Investigating the Work.

Writing the Requirements

A major problem in system development is misunderstood requirements. To avoid any misunderstanding, the analysts must write their requirements in an unambiguous and testable manner, and at the same time ensure that the originating stakeholder understands and agrees with the written requirement before it is passed on to the developers. In other words, the analysts write the requirements so as to ensure that parties at either end of the development spectrum are able to have an identical understanding of what is needed.

--------------------------------------------

Project Drivers—reasons and motivators for the project

1 The Purpose of the Project—the reason for making the investment in building the product and the business advantage that you want to achieve by doing so.

2 The Client, the Customer, and Other Stakeholders—the people with an interest in or an influence on the product

3 Users of the Product—the intended end users, and how they affect the product’s usability Project Constraints—the restrictions on the project and the product

4 Requirements Constraints—the limitations on the project, and the restrictions on the design of the product

5 Naming Conventions and Definitions—the vocabulary of the project

6 Relevant Facts and Assumptions—outside influences that make some difference to this product, or assumptions that the developers are making Functional Requirements—the functionality of the product

7 The Scope of the Work—the business area or domain under study

8 The Scope of the Product—a definition of the intended product boundaries and the product’s connections to adjacent systems

9 Functional and Data Requirements—the things the product must do and the data manipulated by the functions Non-functional Requirements—the product’s qualities

10 Look and Feel Requirements—the intended appearance

11 Usability and Humanity Requirements—what the product has to be if it is to be successfully used by its intended audience

12 Performance Requirements—how fast, big, accurate, safe, reliable, robust, scalable, and long-lasting, and what capacity

-------------------------------------------------------------

Rabbit—small, fast, and short-lived. Rabbit projects are typically smaller projects with shorter lifetimes, where close stakeholder participation is possible. Rabbit projects usually include a lesser number of stakeholders.

Horse—fast, strong, and dependable. Horse projects are probably the most common corporate projects—they are the “halfway house” of formality. Horse projects need some formality—it is likely that there is a need for written requirements so that they can be handed from one department to another. 

Elephant—solid, strong, long life, and a long memory. An elephant project has a need for a complete requirements specification. If you are outsourcing the work, or if your organizational structure requires complete, written specifications, you’re an elephant.

Chapter-3 Scoping the Business Problem

Scoping the Business Problem

Created By: Aishveen Kaur Gill

Ques:1 What is the scope of business and why it is important in business?

Ans: Business Scope: The scope of the business involves every activity performed by that business including sales, services, product developments, marketing, and contracts. Business scope refers to all daily operations of the business, particularly those activities required to secure revenue. The scope of a business usually covers several departments and covers a lot of different areas, depending on an organization. For example, many corporations own several businesses and companies, meaning their business scope is quite large and potentially covers multiple products and markets. Smaller businesses, such as family-owned stores have a smaller business scope as they are focused primarily on acquiring goods wholesale and selling those goods on to consumers at retail prices.
Importance of Scope: Managing the expectations of clients and stakeholders can be one of the most difficult task a Business Analyst can face. With a distant scope, it helps everyone to stay on the same page throughout the life cycle of the business. Scope management establishes control factors, proper communication that can be used to address elements that result in changes during the lifecycle of the business.

Ques:2 What are the requirements for a good scope statement in business?
Ans: A good scope statement includes the following things:

• Overall description of the work: This is where you state that the business is to "build a fence".
• Deliverables: What will be produced by the business project, and what are its key features? Also, what client need is the business satisfying?
• Justification for the business project: In order to provide a complete understanding of the scope, sometimes it is necessary to dive into the justification of why the business was initiated in the first place.
• Constraints: If the business faces certain physical boundaries, these can be a source of risk.
• Assumptions: All business have assumed certain conditions as part of their existence. For example, the fence-building business has assumed good weather and availability of tools.
• Inclusions/Exclusions: Many businesses have items that are uncertain because projects of that size sometimes do's and sometimes doesn't hurt in a scope statement.

Ques:3 What is Scope creep? What causes Scope Creep?

Ans: Scope Creep: Scope creep refers to a project that has seen its original goals expand while its in progress. It is a subtle process that starts with small adjustments and ends up resulting in projects that take far longer to complete or even fail before they are finished. Even if the project is completed, scope creep can result in final deliverables that look nothing like what was originally imagined.

Causes of Scope Creep: The primary causes of scope creep are:

• Poorly defined initial requirements
• Not involving users early enough
• Underestimating the complexity of the business
• Inflexible change control process
• Irrelevant feedback
• Lack of clarity regarding business objectives
• Poor communication between team members, team leads, project managers, stakeholders and clients
• No project scope statement

Ques:4 How to define stakeholder requirements through business analysis?

Ans: In any business analysis, requirements that describes the needs or problems of the stakeholders in achieving or supporting their goals whether it is related to organizational or operational concerns are stakeholder requirements. As stakeholder needs and business needs look-alike, stakeholder requirements define decisions about business needs, goals and objectives just as business requirements do. But from the perspective of the stakeholders and their role in business, calling them business requirements may lead you to fail to isolate the true business needs for the enterprise which may result in not identifying critical projects or objectives of the business. 

Ques:5 How should business analysts handle the current organizational division of work?

Ans:

• Understanding the requirements of the business: A vital responsibility of the BA is to function with the project stakeholders to understand their requirements and translate them into deatils.
• Possibilities of the system: At the beginning of the project, the role of BA may seem like one among the software development team designated for the project and work with consumers or stakeholders or business communications.
• Presentation and Public speaking: The main responsibility of BA is to impress the stakeholder and other authorities with their presentation and have the notable effect of growth in business.
• Elaborating the Details of Project: Evaluating the needs and guarantee the implementation team has the entire details and prepare the functional specifications or other needs in a phase that are accepted by the company and the development of the business.
• Maintenance of system and operations: The role of BA is to preventing or correcting defects, making changes, enhancements, system validation reports, deactivation plans as well as reports of other documents.
• Team Building: The role of BA is to lead teams. They are in need to coordinate, structure, and lead these team members to make their role more successfully.

Chapter-1 Some Fundamental Truths

                                 Chapter-1
                (Some Fundamental Truths)
                             Created by: Ramandeep Kaur

1.) What is the focus of business requirements gathering?

Ans: Requirement gathering is the process of generating the list of requirements like functional, technical, system, etc. from the various stakeholders that are used for the formal requirements definition. In various cases, stakeholders are not aware of the possibilities that exist because the process is not as straightforward as the stakeholders want the system to do and in the current state, it may be limited by their immersion. It focuses on the understanding of business problems and providing a solution to it.

 2.) What are the functional and non-functional requirements?

Ans. Functional requirements:- It specifies a function in which the system component must be able to perform. It can be documented in various ways. The most common ones are written descriptions in documents and use cases. A typical functional requirement will contain a unique name and number, a brief summary and a rationale. A functional requirement is what a system is supposed to accomplish. It may be calculations, technical details, data processing, and other specific functionality.

Non-functional requirements:- It specifies the criteria that can be used to judge the operation of a system rather than specific behaviors. Non-functional requirements can be divided into two main categories: execution qualities, such as security and usability, which are observable at run time and evolution qualities, such as testability, maintainability, and scalability, which are embodied in the static structure of the software system.

3.) What are the constraints? Give an example.

Ans. Constraints are global issues that shape the requirements. They can be limitations on the project itself or restrictions on the eventual design of the product. The so-called 'Triple Constraint'-the triangle of time, cost and scope-are the big hitters and every project as project drivers has one or two if not all three project constraints. An example of a constraint is the fact that there are only so many hours in a day to accomplish things.

4.) What is the process of Volere requirements?

Ans. The process is to start testing the requirements as soon as we writing them. There is a need to make a requirement testable by adding its fit criterion. This fit criterion measures the requirement, making it possible to determine whether a given solution fits the requirement.

5.) How to understand the business problem and find a solution?

Ans. There are three main steps in the problem-solving process in business:

• Identify the problem:- It's important to understand the causes of the problem, rather than simply looking at its effects. State the problem and develop a detailed problem description.        

• Consider the options:- Consider the specific factors that must be addressed in the solution. Identify potential solutions that address most or all of the factors.

• Choose the best solution:- Weigh the risks of tentative solutions. This is the opportunity to prepare for and take steps to avoid any potential negative effects of final decision at no cost. Choose the most appropriate solution to implement.

Chapter 6 - Strategic Analysis

Chapter 6 - Strategic Analysis

Author: Zac Dewit

What is strategy analysis?

• The main concept behind strategy analysis is looking within a company and discovering what is wrong or lacking. After solving for these areas of weakness, you make and implement a strategy to solve these problems, whether fully or partially. 
• Throughout all these phases, there are many helpful tools to understand and organize data such as SWOT analysis or a value chain analysis.

How to analyze the Current State. 

• Before any change can be made or utilized, it is important to understand why exactly change is necessary. It is also important to know what will be affected by any changes. 
• To find what needs changing, first look into a business and find where any wastes are taking place. Lean mentality can be useful in this stage. Look for bottlenecks, time waste, or most often error correction. Once you find problems within your business, it is key to have stakeholder buy-in. Think of what a business will need and what the stakeholders will want. Knowing where a business should be headed will help you stress and motivate people to the necessity of change. 
• When making a change, be aware of the dynamic nature of an organization. It is difficult to imagine a business that does not change automatically on a minor scale. This means that a change you want to implement may already be taking place without your input, but more often the situation surrounding your desired change will shift and force you to take a new approach. 

Defining the Future State.

• To define the future state of a business or an organization, you need to understand where you want to be and what you what to have achieved after a period of time. After you know your final position, you need to work backward and solve what you need to accomplish to reach that final destination. 
• Part of understanding the final destination is creating a success determinant. This means that any change can be graded for success or failure. Be aware that failure can still have some benefits, just not what you were originally intending. An example here is 3M. The staff here used a failed glue product to create a brand new product that was extremely successful. 
• A future state description includes all parts of the business that are affected. This includes any small changes in processes or functions, but also the major changes like company structures or the quality of the staff through training and education. 

Risk Assessment.

• Alongside any change comes the possibility of failure or backfiring. This may come in the form of direct issues, or indirect. Indirect refers to the long line of minor problems or challenges created that total up to a loss for the business. 
• This is why risk assessment is key to increasing success rates. Risk assessment is the process of breaking down a change and finding any places that errors may occur. After they have been determined, the analyst must also find creative solutions to these issues. 
• A major factor to address is the likelihood of a risk. If there is little to no chance of a risk occurring, you can keep an eye out for it, but allow the change to continue without reworking it. This is because in the end there is no way to prove something has a 100% probability of going by unhitched. Something can and likely will go wrong, so it is important to minimize the threat and adjust accordingly. 

What is Define Change Strategy?

• The purpose here is to choose the best possible option for change. This means finding which changes will lead to your future goal, while also taking into account the risk possibilities. 
• As this is the final stage, it is where you begin bringing forth a final product and idea to the stakeholders. While before you had given a pitch, now you must show that all the effort and time so far was worth it. 
• There are many formats to show this change strategy such as a business case, Statement of Work, or an enterprise strategic plan. These methods help show the stakeholders the thought involved and reassure them that change is for bettering the business. 
• Finally, it is important to address which parts of the future plan will be affected by this change. You need to show exactly which goals will be met, and which will not. After all this planning and consideration, it is in the stakeholder's hands to begin implementation or reject your proposal.