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.