Chapter - 12 - Fit, Criteria and Rationale

Fit, Criteria and Rationale

Formality Guide

A pleasing aspect (amongst many) of Kent Beck’s extreme Programming technique is its insistence on writing test cases before writing the code. The test case defines the yardstick that the implemented code must match. The fit criterion is the same thing: It is a yardstick for the requirement. By adding a fit criterion to the requirement, you are writing its test case.

Rabbits use a blog or wiki to discover the non-functional requirements. For each of the non-functional requirements yielded by the blog, we now suggest deriving the appropriate fit criterion, confirming it with the stakeholder, and writing the test case using that fit criterion. Horse projects need to have a precise and easily shareable understanding of the meaning of requirements. It has been our experience that when the project has multiple stakeholders—which is the norm for horse projects— different stakeholders assign different meanings to requirements. Adding a rationale and a fit criterion to each requirement means it is virtually impossible for misunderstandings to occur. We recommend that horse projects include both in their requirements. Elephant projects must use rationales and fit criteria. These projects are forced to produce a written specification to be handed on to some other party, either another part of the organization or an outsource. Having a specification containing only unambiguous, testable requirements is crucial to elephant projects if the other party is to understand and then deliver the correct product.

Why Does Fit Need a Criterion?

When you have a requirement for the product to perform some function or to have some property, the testing activity must demonstrate that the product does, indeed, perform that function or possess the desired property. To carry out such tests, the requirement must have a benchmark such that the testers can compare the delivered product with the original requirement. The benchmark is the fit criterion—a quantification of the requirement that demonstrates the standard the product must reach.

The Rationale for the Rationale

The rationale is the reason, or justification, for a requirement. We have found that attaching a rationale to the requirement makes it far easier to understand the real need. Quite often, stakeholders may tell you their perceived solution to the problem, rather than their real need. Alternatively, they may state a requirement that is so vague as to be (for the moment) unusable. In the example given previously, the client asked for a “user-friendly” product, but you could make sense of it when you learned that the rationale was that the project needed the users to readily adopt the product.

Scale of Measurement

Any requirement can be measured: All you must do is find a suitable scale with which to measure it. The scale of measurement is the unit you use to test the conformance of the product to its requirement. For example, if the requirement is for a certain speed of operation, then obviously the scale is time—microseconds, minutes, months—to complete a given action or set of tasks. For a usability requirement, you can measure the time needed to learn a product, or the time taken before achieving a level of competence, or perhaps even the error rate of the work done using the product. Scales of measurement exist for all sorts of qualities. Color can be measured by specifying its component colors as a percentage of cyan, magenta, yellow, and black. Loudness and softness of sound are measured in terms of decibels. An amount of light is measured in units of lumens. Typefaces can be measured by face names and point sizes. In fact, there is a scale of measurement for almost everything.

Product Failure

The fit criterion might be determined by asking your stakeholder, “What would you consider a failure to meet this requirement?” Suppose you have this requirement: Description: The product must produce the road de-icing schedule within an acceptable time. Clearly, the scale of measurement here is time. Your client can tell you how much time he thinks would constitute a failure. For example, the client would consider the product unacceptable if the engineer must wait for more than 15 seconds for the schedule to become available. This means you have the following fit criterion, with suitable business tolerances applied: Fit Criterion: The road de-icing schedule shall be available to the engineer within 15 seconds from when he makes his request for 90 percent of the times that it is produced. It shall never take longer than 20 seconds.

Standards

Sometimes numbers are not appropriate, or you can create a better fit criterion by citing a standard. For example, the requirement mentioned earlier that the product is “not offensive to any group” could be handled by citing your organization’s standards of conduct. Alternatively, your communications department might have standards for what is and what is not allowed to be said or displayed for public consumption. By citing that the product must comply with that standard, you are in effect setting the benchmark for lack of offensiveness.

Defining the Data

For example, within the Ice Breaker project requirements often refer to Road Section. If you look in the data dictionary, you will find this definition: Road Section = Road Section Identifier + Road Section Coordinates You can then expect to find a definition of each of the attributes—for example: Road Section Identifier = *Unique identifier for 500 meters of road. The maximum number of road sections per road is 10,000.* Another strategy for defining the data is to define each term as part of the fit criterion of each individual requirement. However, as you will usually reference the same term in more than one requirement, it makes sense to maintain a central dictionary that can act as a cross-reference between requirements. Your growing understanding of the data means that you can progressively build a business data/information model that specifies the essential stored data for the requirements you are specifying.

Graphic Fit Criteria

When writing fit criteria, the aim is to be as implementation neutral as possible, thereby giving the designers and developers the maximum amount of freedom in choosing how to meet each requirement. The problem is that natural language is inherently procedural (you are forced to write words in a serial order) and sometimes that order is interpreted incorrectly as part of the requirement. You might consider the following approaches.

Decision Tables

Suppose that your fit criterion defines the rate of discount that a customer should have depending on how long he has been a customer, what his cumulative spending is, and whether he is a member of the customer loyalty program.

Maintainability Requirements

Maintainability requirements specify expectations about the maintenance of the product. Usually the fit criteria for these requirements quantify the amount of time allowed to make certain changes. This is not to say that all maintenance changes can be anticipated, but where changes are expected, then it is possible to quantify the time allowed to adopt those changes. Fit Criterion: All functionality must be migrated to the new website with no more than 10 minutes of unavailability of the site.

Security Requirements

Security is too important to be left to the whims or the goodwill of the developers. Your organization probably has some security standards in place, either specific to the industry or specific to your type of product. It is important to know which standard applies and to include it in your fit criterion. Taking this step has an added benefit: CYA. If a breach occurs in the future, at least you can say your product complied with the standard.

Cultural Requirements

Cultural requirements, by their nature, are subjective and slightly more difficult to quantify. The fit criterion is usually based on who will certify the product’s acceptability. For example: Fit Criterion: The Shatnez Laboratory of Brooklyn shall certify that the product complies with the shatnez rules. Fit Criterion: The communications department shall give the opinion that the product displays no words or symbols that could be construed as religious or political.

Chapter - 10 Functional Requirements

CHAPTER - 10

(Functional Requirements)

Created by:- Ramandeep Kaur

  

Functional Requirements


Functional requirements describe what the product has to do to support and enable the owner’s work. They should be, as far as possible, independent of the technology used by the eventual product. The Functional Requirements Specification is designed to be read by a general audience. Readers should understand the system, but no particular technical knowledge should be required to understand the document.

Uncovering the Functional Requirements 

The scenario is a convenient way to work with stakeholders to determine the necessary functionality for a product use case. Each of the scenario’s steps is decomposed into its functional requirements. The collection of functional requirements reveals what the product has to do to fulfill the product use case. 

This use case diagram shows the product generating the road de-icing schedule. This PUC is triggered by the Truck Depot Supervisor; the Thermal Mapping Database is a cooperative adjacent system providing information to the product use case upon request. The objective is to write enough functional requirements for your developers to build exactly the product your client is expecting and your actor needs to do the work.

Data, Your Secret Weapon

A class diagram showing the stored data that the business needs to predict the formation of ice on roads. A truck is dispatched to treat a road when the readings from the weather station and the forecast indicate the road section is about to freeze. There is a dependency between a product’s stored data and its functionality: You cannot have stored data unless there is some functionality to store and retrieve it, and functions can exist only if they process data.

Technological Requirements 

Technological requirements arise purely because of the chosen technology. This need is a technological requirement; that is, it arises purely because of the chosen technology. If the designer had selected a different technology to handle this part of the work—say, a direct fiber-optic link—the result would be different technological requirements. 

Grouping Requirements

A hierarchy of requirements. The work context is the highest-level statement of requirements; it is decomposed into the next level, the business events. The level below the business events comprises the product use cases, each of which is decomposed into a number of product use case steps. The lowest level includes the atomic requirements, each of which can be traced back to the hierarchy. Activity diagrams and user stories are also used to group atomic requirements. Features are a grouping often used by stakeholders from marketing or product version planning.

Chapter- 11 Non-functional requirements

Non-Functional Requirements

 Non-functional requirements
Ans: Non-functional requirements define system attributes such as security, reliability, performance, maintainability,  scalability, and usability. They serve as constraints or restrictions on the design of the system across the different backlogs. They ensure the usability and effectiveness of the entire system. Failing to meet any one of them can result in systems that fail to satisfy internal business, user, or market needs, or that do not fulfill mandatory requirements imposed by regulatory or standards agencies. Proper definition and implementation of NFRs is critical. Over-specify them, and the solution may be too costly to be viable, under- specific or underachieve them, and the system will be inadequate for its intended use. An adaptive and incremental approach to exploring, defining, and implementing NFRs vital skill for Agile teams.


 Difference between functional and non-functional 
requirements
Ans: Functional Requirements: Functional requirements specifies a function that a system or 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. Use cases can be textual enumeration lists as well as diagrams, describing user actions. Each use case illustrates behavioural scenarios through one or more functional requirements. Often, though, an analyst will begin by eliciting a set of use cases, from which the analyst can derive the functional requirements that  must be implemented to allow a user to perform each use case. 
Non-functional requirements: Non-functional requirements are any other requirement than functional requirements. This are the requirements that specifies criteria that can be used to judge the operation of a system, rather than specific behaviours. Non-functional requirements are in the form of system shall be, an overall property of the system as a whole or of a particular aspect and not a specific function. The system's overall properties commonly mark the difference between whether the development project has succeeded or failed.


Use Case model
Ans: A use-case model is a model of the system's intended functions and its surroundings, and serves as a contract between the customer and the developers. Use cases serves as a unifying thread throughout system development. The same use-case model is the result of the requirements discipline, and is used as input to Analyses & Design and Test disciplines.
There are many ways to model a systems, each of which may serve a different purpose. However, the most important purpose of a use-case model is to communicate the system's behaviour to the customer or end user. Consequently, the model must be easy to understand.

Examples of Non-Functional requirements
Ans: Users must change the initially assigned login password immediately after the first successful login. Moreover, the initial should never be reused. Employees never allowed to update their salary information. Such attempt should be reported to the security administrator. Every unsuccessful attempt by a user to access an item of data shall be recorded on an audit trail. A website should be capable enough to handle 20 million users with affecting its performance. The software should be portable. So moving from one OS to other OS does not create any problem. Privacy of information, the export of restricted technologies, intellectual property rights, etc. should be audited.

Advantages and Disadvantages of Non-functional requirements.

Ans: Advantages:

• The nonfunctional requirements ensure the software system follow legal and compliance rules.
• They ensure the reliability, availability, and performance of the software system
• They ensure good user experience and ease of operating the software.
• They help in formulating security policy of the software system.

Disadvantages:

• None functional requirement may affect the various high-level software subsystem
• They require special consideration during the software architecture/high-level design phase which increases costs.
• Their implementation does not usually map to the specific software sub-system,
• It is tough to modify non-functional once you pass the architecture phase.

Chapter - 8 Starting the Solution

We cannot make this book an exhaustive treatise on the design of software and organizational systems. Each organization has its own unique implementation environment, which means that the designers will come up with a unique design. Nevertheless, we can identify the variables that you need to consider to make the design decisions in your environment.

Iterative Development 

Iterative development techniques don’t always appear to do much in the way of upfront design, relying instead on frequent releases of software to gauge the design’s suitability. Although this approach can certainly work, it can be time-consuming if the initial releases are not very close to what is actually needed, or if the problem is so poorly understood or defined by the stakeholders that any solution is bound to be wide of the mark. In any event, it is usually more efficient to begin the discovery of need with abstract models and conversations, instead of concrete implementations.

Determine the Extent of the Product 

The task of business analysis is to determine what the work should be in the future and how the product can best contribute to that work. As noted earlier in this text, business use cases are responses to requests from the outside world for the work’s service. The optimal response is to provide the most valuable service (from the outsider’s point of view) at the lowest cost in terms of time, materials, or effort (from your organization’s point of view), and in the most pleasing and encouraging manner (from the end user’s point of view). Thus the product you craft should be a contributor to the optimal business use case—one that makes the product cheaper and faster and more convenient and all of the other things your project is to deliver.

Innovation 

This is the time for you to be innovative. If no innovation occurs, then the new product will be much the same as whatever it replaces. It is, of course, important not to disrupt the essential requirements, but there are a number of things that you can do to make a more innovative and acceptable end product.

Innovation, as we use the term here, means thinking differently about the problem to find a new and better way to do the work, or in some cases to find better work to do. Instead of rushing ahead with the first-to-mind solution or the obvious solution, we urge you to spend just a little time with fellow business analysts and other stakeholders to come up with something better, something that will be longer lasting and more appealing, something innovative.


------------------------------------------------------------
Cooperative adjacent systems are usually computer systems acting as if they are part of the work.

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

Sketching the Interface

Sketching has certain advantages. It is quick, which is definitely a benefit. Moreover, if the sketch is rudimentary enough, it will dissuade users from trying their hand at screen design. They are not qualified to do so, and it is far too early in the development process to be going into detailed design. 

There is no point in having a carefully crafted screen layout when you’re still unsure of all the functionality (and non-functionality) that could influence the interface. Anything you can do to dissuade business users from designing screens is very much to your advantage. Similarly, when you use rough sketches, no one has too much ego invested. Subsequent tasks in crafting a solution could well mean significant changes to your sketches. No one seems to mind if a sketch is changed, but most people mind if their carefully crafted design is changed.

Product Use Case Scenarios 

The business analyst uses product use case (PUC) scenarios to communicate the intention of the automated product to the stakeholders. Naturally, the PUC scenario is not the only document available to you at this time. Even so, because it shows the functionality of the product, it is an easy document with which to convey your intentions to the stakeholders. We suggest that you present the PUC scenario to the stakeholders at some suitable meeting. Do not simply e-mail it to them—you need their feedback.

To begin, first identify the business events. Pick one of them and trawl to discover the functionality that responds to that event (the business use case). As a way of showing your understanding, write a business use case scenario for this event. When your stakeholders are happy with the scenario, determine how much of that BUC can be implemented as the product. Whatever that turns out to be becomes the product use case.

Cost, Benefit, and Risks 

Naturally enough, choosing a solution is not just a matter of drawing a few lines on process models and hoping for the best. You have the responsibility to come up with the optimally valuable product—that is, optimally valuable to its owner. This implies that the cost of your solution must be in proportion to the benefit it brings to the owner. There is little point spending $10 to develop the product if the benefit it brings is worth only $1—unless, of course, the $1 saving is part of a repetitive process and is applied thousands of times.

Putting It All Together 

There is no formulaic method for arriving at the optimal solution; you have lots of factors to juggle, and the best design is simply the best compromise among all of them.

Chapter 6 - Scenarios

Chapter 6 - Scenarios

Author - Zac Dewit

Scenarios

• A scenario is an outline of a series of steps. This term is used to describe the parts of a section of work. Chapter 4 taught us how to split the work into parts. The scenario takes those parts and defines its functionality. 
• These scenarios are especially used to create business use cases (BUC) with the help of the stakeholders. 
• A scenario is simple and is easy to understand for all stakeholders. However, not all stakeholders need to see or hear about it. It can be specifically made for groups or can be made for all the people involved.
• Once these scenarios have been made and shown, it should help the stakeholders reach an agreement on the work that needs to be done. Then you make more scenarios to describe how each person will interact with this new system
• Each part of the scenario should be a part of the functions in a BUC. There should be 3 to 10 steps. This way there is still a clear path, but it is not overly complicated.

The Essence of the Business

• If we think back to the brown cow model, the scenarios belong to the "how now" quadrant. To move to the "what" side of things, we need to consider the essence of the problem and in turn the essence of the business. 
• To do this we need to eliminate any technology-based bias that we have while asking one simple question. What does this business do? By breaking it down to the simple form here we can refocus on what really needs to be done to make the business better.  

Alternatives 

• Alternatives are choices that you have created for the user. These choices are put here on purpose. They are a desire of the business. These choices are usually available to make the user's life easier or more straightforward.
• An example of this is when you buy textbooks and choose if you want digital or actual copies. 
• These are positives and appeal to our desire to have options in life. 

Exceptions

• Exceptions are the unwanted deviations. They are unwanted because the owner would have preferred if they never existed. This includes things like when people forget their passwords or do not have proper documents.
• Do not look for exceptions until after you have found all your normal scenarios. It can be easy to spend forever thinking of exceptions that will likely never happen. It is important to save this step until nearer to the end. 
• The goal of these scenarios is to understand how to safely and respectfully handle these exceptions to your normal work.

What if? Scenarios

• Finally "what if?" scenarios are when you explore strange and outside the box ideas. You can ask questions like "What if we did this?" or "What if we rearranged this?". These questions can get stakeholders to reimagine how work can be done and even if you don't immediately find a solution to a problem, it can give a greater understanding of how the business works and how the parts of the work interact with one another. 
• Another aspect of this is to find what is currently a constraint in the business. What is it that is holding you back from achieving so much more? If you can find these and eliminate them, you can improve the business.

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.  

Chapter-4 Elicitation and Collaboration

Elicitation and Collaboration 

Created By: Aishveen Kaur Gill

Ques:1 What is Elicitation and collaboration?

Ans: Elicitation and collaboration describes the tasks that Business Analysts perform to prepare for and conduct elicitation activities and confirms the result obtained. It also describes the communication with stakeholders once the business analysis information is assembled and the ongoing collaboration with them throughout the business analysis activities.

Elicitation and collaboration can be planned, unplanned or both. Planned activities includes the surveys that can be structured and organized in advance, workshops and experiments while the unplanned activities are happened at the moment without any notice and these activities requires deeper exploration through planned activities.

Ques:2 What types of task Elicitation and collaboration composes?

Ans: Prepare for Elicitation: It understand of the scope of elicitation, select elicitation techniques, set up logistics for each elicitation activity, identify supporting material to conduct elicitation activity and prepare stakeholders to elicitation work.

Conduct Elicitation: It guides the elicitation activities and capture elicitation outcomes.

Confirm Elicitation Results: It compares elicitation results against sources information and compare elicitation result against other

Communicate Business Analysis Information: It deterimines the objectives and format of communication and communict business analysis package.

Manage Stakeholder Collaboration: It gain agreement on commitments, monitor stakeholder engagement and collaboration.

Ques:3 What are the techniques to prepare for elicitation?
Ans: Brainstorming: used to collaboratively identify and reach consensus about which sources of business analysis information should be consulted and which elicitation techniques might be effective.
Estimation: time and effort estimation required for the elicitation as well as the cost associated in business.
Data Mining: used to collect the data, information or patterns for an investigation.
Risk Analysis and Management: The plans for the elicitation should be adjusted to identify, assess, and manage conditions or situations.
Interviews: used to identify concerns about the planned and unplanned elicitation to procced with specific options.

Stakeholder List, Map, or Personas: used to consulted while preparing for the elicitation, who should  participate in the event, and the appropriate roles for each stakeholders.

Ques:4 How manage a stakeholder collaboration is important in Business Analysis?

Ans: Managing the collaboration of stakeholders in business activities is key to obtain success as stakeholder engagement encourages the stakeholder to work towards a common goal. Choosing the right stakeholder for engagement at a right time is more important than just managing their engagement. Business analyst is the one who determines the roles of the stakeholder and communicate with them. Business analyst encourages stakeholder involvement in order to reduce the impact of negative reactions and constantly supervise their involvement in the business analysis activities and establish a relationship with them as the poor relationships will be detrimental for business analysis.

Ques:5 What are the common guideline and tools to manage  stakeholders collaboration?

Ans: Business Analysis Approach: Each group member should describes the nature and level of collaboration to perform planned BA activities.
Business objectives: To achieve the future state one should describes the desired directions needed and to achieve the desired business outcomes they have to focus diverse stakeholders on a common vision.
Future state description: defines the desired future state and the expected value it present to give more focus on stakeholders to achieve the goals.
Recommended Actions: to improve the focus oitationn stakeholders to achieve goals communicating should be done and the value of solution can help to support and focus.
Risk Analysis Results: Risks related to stakeholder will be needed to address to ensure stakeholders collaboration for business activities.