Transcript of 1-25

10.1 acceptance & or evaluation criteria. These are really just requirements that must be met in order to give a solution, feature, or a pass or fail. The difference between the two is that acceptance criteria are typically used for something under development, as a user story in a sprint and evaluation criteria are more common when you are comparing features of different software that you are potentially acquiring. You should expect to do this a lot as a BA.

10.2 Backlog management is basically how your scrum team manages your backlog in terms of definitions of ready, definitions of done, and so forth. I would definitely look into researching scrum backlog practices for this one.

10.3 Balanced scorecard is a technique intended to gauge the health of your organization. It involves measuring 4 categories. Customer Satisfaction, Employee Growth, Business Process Efficiency, and Financials. I honestly can’t imagine an entry-level business analyst being asked to do this, because it might include some tough conversations with some high-level people. In fact, to truly be unbiased, I could see a consulting agency doing this for a company

10.4 Benchmarking and marketing analysis is simply a way of comparing how you are doing to industry standards. The important thing here is to make sure you are comparing the right measures, but otherwise, conceptually it is pretty straight forward. If every competitor does A, B, and C, you have to measure how well you are doing A, B, and C.

10.5 Brainstorming is an umbrella term for coming up with ideas. You can brainstorm alone or you can facilitate brainstorming with a group.It involves good preparation with context areas and having the right people involved. It involves creating an environment for all people to share and explore freely and without judgment and finally, it involves outputting everything that was collected in a valuable manner.

10.6 Business Capability Analysis is similar to benchmarking in that you are essentially comparing to a standard of some kind. This is another thing I’d expect to happen with an experienced business analyst and likely from a consulting company. Often times its depicted as a bunch of boxes which organized by category and color-coded for like a pass, fail, and maybe some nuances in between.

10.7 Business Cases is basically something you write to justify spending time, resources, and money for a project to change something or buy something. It would likely include items from the balanced scorecard and how it’ll improve them.

10.8 Business Model Canvas is just a standard way to essentially show what your organization does and how it produces value. It very is reminiscent of what Enterprise Architects do which is a common career path for business analysts.

10.9 Business Rules Analysis basically documents the policies in which a business operates and helps inform how to formulate a business process. For example, a business rule might be that you don’t sell to people under 18. That might mean that the business process needs to have a step to validate age and paths for passing or failing age verification.

10.10 Collaborative Games are basically activities the help groups of people essentially create focus and direction for what the group needs to accomplish. In my own experience, I’ve used affinity mapping many times since its easy for people to understand and participate. It also gets people up and moving around.

10.11 Concept Modelling at a high level is just taking a bunch of terms or concepts from your domain and modeling out how they all relate to each other. I find them fun to make and extremely useful in understanding a new domain or helping others understand a domain. It is what I recommend BA when they first start a new project

10.12 Data Dictionary is basically a glossary for all your data. It often uses slightly more complex organization structures than say a dictionary and helps create an understanding of all the elements involved in a system. For example, you might define a person as a thing, and define a child as a subcategory of a person defined by an age range, then adult… you get the idea. Facilitates clarity.

10.13 Data Flow Diagrams are pretty key business analyst diagrams. They basically illustrate applications and what data flows between them. It helps create a sort of context in understanding what teams need to be worked with when something is going to change. 

10.14 Data Mining comes in two forms, looking at data to find an answer to a question, or look at data with no question to answer just to see what it tells you. Data helps inform a lot of decisions, so you should be comfortable doing some degree of data analysis to better perform your job as a business analyst. 

10.15 Data Modelling is a way to document how data is organized typically using standard notations. It often is used to model how databases structures will actually be organized. There is value in understanding data modeling to better understand and communicate constraints or opportunities in making decisions related to data.

10.16 Decision Analysis is about organizing information to make it easier to make a decision. There are different ways to accomplish this, but a common method is a scorecard with all the variables listed, values assigned and weighted, and seeing how different choices stack up side by side.

10.17 Decision Modelling is more focused on visualizing how the decisions are made and the outcomes. A decision model would theoretically be a big cascade of business rules.

10.18 Document Analysis is probably the most boring and one of the most used techniques of a business analyst. It’s literally learning from looking at existing documentation. Could be manuals, help documents, or documents created by a previous business analyst. It typically helps you build a degree of understanding so you can make the best of your time when in meetings and such.

10.19 Estimation for a business analyst is another big umbrella category of many techniques to estimate the future value of something. Most organizations have standards for how they prefer to estimate things, but if it’s something that impacts your work a lot, it could be valuable to explore different methods of estimation.

10.20 Financial Analysis revolves around assessing the benefit to the bottom line, usually over time and is one reason by business analyst new hires are business majors focused in IT because they would have had to take some finance and accounting classes. The more senior you become the more likely you’ll have to deal more and more with the financial aspects of projects.

10.21 Focus Groups are typically used to basically ask a group of people how they feel about something. For example, and HR business analyst working on a project for new hires onboarding might have a focus group with a bunch of new hires to ask how they felt about their experience.

10.22 Functional Decomposition is basically breaking down a high-level thing into its lower-level parts. This might mean breaking down a business requirement into the functional requirements for each part or system that needs to change, or Epics/Features down into user stories. You’ll be doing this a lot as a business analyst. It’s kinda like your main thing.

10.23 is a Glossary. Basically, if you have a bunch of nuanced terms or acronyms in your space, keeping a glossary will help you and anybody new to space.

10.24 Interface Analysis for a business analyst is looking at any interface whether its data interfaces, user interfaces, application interfaces, and basically documenting what’s there and why it exists. Very important to know before making changes to something.

10.25 is Interviews. Its how you learn stuff from people and I really hope you already knew that. The only thing I’ll say here is to make sure you have a goal for the interview before conducting it to help focus the conversation.

Examples of Mind Maps

From ResearchGate – Mind Map Order Subsystem

From SimpleMind: How to Mindmap

From MindMap Art – Health

Examples of Concept Models

From UIE – Concept Models 

From Medium – The Concept Model (I recommend checking this site out)

What confused me was that a lot of what I read said requirements should be written as “system must do this” and “system shall do that”. So when I came across business rules for the first time, they had a similar structure, so I thought business rules were just another way to write requirements, which isn’t entirely true.

Business rules are not quite requirements

Business rules are meant to convey a state of affairs, much like a process diagram does. They describe how the business works (or how it should work in the future). They are NOT system/solutions requirements. For example, a business rule might be “Customers must be 21 to make a purchase”. This is a rule set by the business outside of any system. 

Now if this was a new rule the business wants to implement, then as a BA your goal is to write solutions requirements against this rule. For example, “the system must be able to validate the age of a customer”. 

Business rules should be kept to represent how the business operates, and in most cases where companies don’t specifically document business rules, you can actually find them embedded within process diagrams. For example:

So just to bring back to what you are supposed to do with them, business rules help you document the current or future state and are meant to represent how a business operates, and the system or application should work to make the business rule happen.

First, business analysis isn’t a single task. It actually encompasses a few value-adding activities. For the purposes of this article, I’ll break them up into the following sections or categories that make sense in terms of deliverables.

• Understanding The Business
• Planning Your Work
• Defining The Solution
• Evaluating The Solution

Let’s break these down so you can understand what they are and what deliverables would come out of each. One thing to remember is that different companies may name some of these items or concepts differently, so what’s important is understanding the value of the end result not what it is named.

Understanding the Business

This part of the job is where you figure out whether there is really anything to be solved. This is not always done by a person titled “business analyst,” because at this point you are figuring out returns on investment, getting business justifications, etc which more senior business analysts tend to be more prepared for. Depending on the company, this senior business analyst may have many different titles. My company, for example, calls it an IT Partner, usually partnering with a particular business segment like marketing, sales, etc.

The High-Level Deliverable: A Business Case

The business case is typically what comes out of this, and it may include outputs of various techniques that come together to show that a problem needs to be solved or there is an opportunity to take advantage of.

Planning Your Work

Once you or someone else has determined there is a project worth doing. It is time to plan how you are going to do the rest of the business analysis work. Planning is important because a business analyst can’t do very much alone. Analysts need to plan how they are going to interact with all the stakeholders and get what they need out of them to create a solution that works for them. It prepares everyone involved and also ensures they have the resources (people, tools, facilities, etc) they need. This becomes especially important if you are a contractor and statements of work will be required.

The High-Level Deliverable: The Business Analysis Plan

While at high-level everything that comes out of this might be included in a business analysis plan, they may be broken down into smaller common deliverables like work breakdown structure (WBS), communication plan, business analysis approach (plan vs change driven), and requirements management plans.

Defining the Solution

This step is typically what people believe the “business analysis” is, and what their deliverables should be centered around. Defining the solution is essentially documenting what the future solutions should be capable of doing to meet the business needs, also known as requirements gathering.

The High-Level Deliverable: A Requirements Document

This can come in many shapes and sizes. Requirements document makes it sound like it should be a paper document, but it doesn’t always have to be. The BABOK terms this the “requirements package” which I think better describes what it is. This could include a traceability matrix, use cases, business requirements, stakeholder requirements, solutions requirements and they can be textual or in the form of diagrams, models, or wireframes.

Evaluating the Solution

Sometimes your job may require you to evaluate whether a given solution actually meets business needs. This can happen in two ways. The first is when the requirements document has been done, the solutions have been designed/built, and you need to make sure it meets the actual business needs. The second is when the requirements are defined, and you want to assess a bunch of different potential solutions. Kind of like creating a list of things you want in a car and checking cars out to see which models meet your criteria (instead of building your own).

High-Level Deliverable: Acceptance/Evaluation Criteria & User Acceptance Test Cases

Acceptance and Evaluation criteria are typically lumped together, the main difference is acceptance describes the first scenario where you make sure what you build or purchased is really meeting your needs. Evaluation is usually used when you are using your list to decide on which option you are going to go with. This can come in the form of user acceptance test criteria, vendor selection criteria, etc.

***

I hope that helped and put some perspective into your BA world. Do any of you have examples of specific deliverable names you have ben asked to deliver?

Side note: Even in an agile world, a BA needs to accomplish these same things, but they are done within the scope of sprints/iterations and are typically named differently.

Don’t forget to check out

3 Types of Business Analyst Tools to Produce High-Quality Deliverables

&

Business Analysis Tips to Produce Effective Deliverables

It’s super valuable in terms of knowing the job is complete, managing changes, and assessing impact. The reason people don’t do it is that it is a monumental pain in the behind to manage with the most common tools available to use (Word and Excel). Based on responses from professionals in the field, its managed in usually one of three ways.

In Document Requirements Traceability

If you working in your standard Word document (or equivalent word processing file), the one method is to by creating internal document links. For example, if you start with your high-level required capabilities at the top of the document, you can either list each requirement that relates to it that exist in the sub-requirements or you can list the related high-level requirements within the sub-level requirements [pictured below]. Because requirements gathering is such a dynamic sport, trying to keep up with all of the changes can become a whole job on its own, so people tend to become lazy about it as the project progresses or just don’t even bother.

Excel (Spreadsheet) Requirements Traceability Matrix

Managing the traceability in excel is better because excel is meant for slicing and dicing important data, but now you are having to manage 2 separate documents, on for the requirements themselves and one for the traceability, so it still sucks. It’s mostly used as transition verification in a waterfall methodology. For example…

• Do the solution requirement cover all the business requirements?
• Do the system specifications cover all my solution requirements

Requirements Management Tool Traceability

In my experience and in hearing from other business analysts, the only valuable way to properly trace requirements is with a requirements management tool. When I say “valuable” I’m really referring to the cost-vs-benefit of doing it. Sure the end product can be valuable, but the cost of maintaining outside of the tool is often too high in the long term.

Requirements management tools not only give you the ability to create relationships on the fly. You could trace business requirements to solution requirements, business rules, business processes, etc. Then some time after the fact you can create reports that are actually valuable to someone and can be used to make an informed decision about your solution. For example…

• Business user:  “I want to change this functionality to be like this because it will be better for me this way.”
• Future business analyst: “Well we need to keep in mind that it works that way because of policy X and to satisfy business object Y, so the new functionality must also satisfy those needs”

A solid requirements management tool with good tracing capabilities can be infinitely valuable if you manage your deliverables or work products effectively within the tool. Different stakeholders can see information as they need it instead of having to get value our of a deliverable that was intended for a different audience.

If you need a more generic overview of all deliverables for a business analyst check out 4 Types of Business Analysis Deliverables Every Good Business Analyst Should Know

Many of us get confused when we are told a business analyst writes requirements, but then we are told we also write use cases, user stories, business rules, decision tables, functional requirements, and so forth. So, I’ll start with a basic hierarchy to get the ball rolling, then break it down from there

Business Processes

• Business Rules
• Decision Tables

Business Requirements – User Stories

• Stakeholder Requirements – Use Cases
• Solution Requirements
  • Functional Requirements – Acceptance Criteria – Non-Functional Requirements
• Transition Requirements

First: The Business

The first thing you need to understand is that as a business analyst, your first task is to analyze the business before you determine any needs. This analysis should be about how the business runs and should remain separate from the tools used to run it (in most cases, your project will be to determine which features or capabilities best fulfill the business needs). This is typically done by business processes, business rules, and decision tables.

The business process, if done well, is a set of sequential tasks that are performed that are supposed to achieve business value. The tasks usually follow a “verb + noun” structure

• Example:  [receive order] -> [process order] -> [ship product]

The business rules and decisions tables usually relate to the individual tasks and help guide the process against the business rules. This is where you will likely get into the business of writing “must” or “shall”.

• Example:
  • [process order]
    • Rule 1.0 Order must have a valid purchase order number
    • Rule 1.1 Order must contain a valid shipping address
    • Decision 1.0 If the order contains software send to software fulfillment
    • Decision 1.1 If the order contains hardware send it to hardware fulfillment

The business process, rules, and decisions should exist before any type of project requirement are developed and the requirements should fulfill the process, rules, and decisions of the business. (Side note: Business Rules and Decisions help keep the business process from looking too crazy with so many decision diamonds and branches. Great for quick and easy readability/understandability)

Second: The Project

The second thing you need to understand is that “requirement” is a generic term that basically means “capability.” In fact, you can refer to requirements as “required capabilities” after all, when you do a gap analysis, you are analyzing the gap in capabilities that eventually become business requirements.

Generally, business requirements are at the highest level and represent the enterprise’s needs. Next, you need to determine what stakeholders will need to be able to do to meet those needs, so you develop stakeholder requirements. You can write these types of requirements as user stories, use cases, business requirements, or stakeholder requirements.

As you dig in to get more detail, you start moving into solutions requirements, which are literally what the system needs to be able to do. Sometimes these are functional or non-functional. Generally speaking, business requirements and solution requirements revolve around “ability”. Some practitioners advocate using “the ability to” or “must be able to” in your requirements statements. Some examples

• the ability for the company to do something (business requirements) to do something
  • The organization must be able to process orders
• the ability for a user/stakeholder to do something
  • The salesperson must be able to override pricing
• or the ability of the system to do something
  • The system must be able to double authenticate logins (non-functional requirement)

User Acceptance criteria are another form of requirement and can be used as requirements because they are literally what the system must do (capabilities), in order to be considered a successful project. These are more popular to use with SaaS/Cloud software since you won’t be building it internally, you only need to evaluate whether it meets your business needs.

Finally: Deployment

Sometimes, in order to get a system up and running, you need to do a few things in order to manage the transition. The easiest example of this is when migrating into a new system, you might need to build a capability to import masses of data into the new system from the old. However, once the migration is done, the capability is basically obsolete. This is a transition requirement. It can technically fall into any of the above “requirements” types; the only difference is that it’s temporary.-