These are a form of Requirement  that must be met to give a solution, feature, or functionality a pass or fail. You should expect to do this a lot as a BA as it is core to writing requirements.

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.

Older Version (Article Below)

SharePoint is a very common big corporation content management tool and in the right hands, it can be quite powerful. I want to point out that SharePoint, is NOT a requirements management tool,  but if it’s all you have, then you have to make the best of it (Creative Thinking at its finest ladies and gentlemen). Now … I can spend days droning on and on about all the different features that SharePoint has that would work for business analysis, so I’m gonna stick to my top 5.  (Don’t forget to also check out Top Requirements Management Tools, to Make You A Battle Ready Business Analyst!)

Top 5 Features for Managing Requirements (and Agile Backlogs) on SharePoint

Below are out-of-the-box features that you should be able to use on even basic installations.

#5 Managing Business Requirements and Backlogs with Lists Views

Lists are essentially tables that you can use in a variety of ways in SharePoint. You can add and modify your requirements attributes (requirement ID, requirement, additional details, impacted systems, business owners, etc).  This is great when you need to organize your requirements or when stakeholders want to make sure all of their needs are covered.

#4 Exporting Requirements to Excel

If you’re working on a giant complex project with many working parts, different business analysts, and huge amounts of stakeholders, then exporting into a tool like Excel makes slicing and dicing and getting analytics on your requirements that much easier. If you have office 2007 or earlier, you can even edit the list from excel and sync it back to SharePoint. For some reason, they don’t allow it in Office 2010 (I was quite sad to lose that feature)

#3 Requirements Traceability with Look-Up Columns

Requirements traceability is one of the biggest pains in the butt to keep track of without a good tool.  You can add a column type called “look up”, pick the business requirements list, and then select which columns you want to show up in the function specification list. This way, you can see a filter to see how each business requirement is being met or for impact analysis and so forth.

#2 Discussions for Keeping Track of Decisions

One of the best things you can do for yourself is to not allow discussions via email. Require all questions and discussions to happen strictly via SharePoint discussions. This will ensure that all of your project decisions are stored someplace where anyone can see them. It’s also a good way to make sure all questions have been answered. Personally, I enhanced my discussion boards by adding fields for “who should be responding” and “is the question resolved”, so everybody can see what is open, unresolved, and needs their attention.

#1 Workflows to Make Everything Run Smoother

SharePoint has some default workflows (like emailing a person if they are assigned to something) or you can get fancy and write your own. I found them most useful for discussions as well as when using SharePoint as an Agile Backlog tool. When a requirement was complete, the development set a status that triggered an email to the product owner (business analyst, i.e. Me). I then had my own set of statuses that either triggered an email to the development team (if it failed) or to the business unit for final validation (if it passed). We did something similar for discussions and I would say it completely changed our efficiency and generally made everyone happier.