The Bridge - Fall 2006

the

CONNECTING BUSINESS REQUIREMENTS TO TECHNOLOGY

Fall 2006

Categorizing and Presenting Requirements What is a Requirement?

Supplemental Requirements

The Business Analyst Toolbox

Barbara Stroope

Kevin Brennan

Book Review

IIBA Update

More About Software Requirements

Carol Lapp

letter from the editors he fall is a busy time for many Business Analysts; many projects are getting started as we are all back from our summer vacations.

We are excited to offer you another issue of the bridge and hope you find its contents helpful. This fall there are several conferences for Business Analysts which provide opportunities for professional development (see page 9 for the list of upcoming events). We hope to see many of you at these conferences where business analysis experts will share their insights on ways to enhance your business analysis skill set.

With the upcoming conferences and the development of the Business Analysis Body of Knowledge (BABOK™) we chose to focus TINA JOSEPH and BARBARA CARKENORD this issue on what many people consider to be the most important deliverable of business analysis – requirements. As you read through this issue you will find that “requirements” are defined and viewed in many different ways. Our main article, Categorizing and Presenting Requirements helps to clarify our shared definition of the word “requirement,” discusses many approaches to representing requirements, and gives guidance on presenting requirements in a consistent manner that best fits your organization’s need.

Kevin Brennan, Vice President BABOK, shares his view of the variety of requirements analysis techniques in his article, The Business Analyst Toolbox. His article describes where the most common requirements techniques fit within the Zachman framework of enterprise architecture development. Kevin’s article demonstrates the complexity of choosing the appropriate technique for each requirement situation.

We like to share best practices from our readers’ organizations. This month Barbara Stroope, with Acxiom, shares her experience with identifying and managing supplemental requirements for projects in her article Spotlight on Supplemental Requirements.

The IIBA held its third Annual General Meeting in July. Carol Lapp, President, IIBA Chapter Council, gives us a recap of this meeting and the latest developments within the IIBA in this issue’s IIBA Update.

With the focus of this issue being requirements, Lost in Translation provides some specific tips about searching for the right requirements. Ask the Experts encourages BAs to ensure that the proposed solution is in fact the most appropriate solution. Finally, the book review in this month’s issue is of Karl Wiegers’ most recently published book—More About Software Requirements.

We encourage you to continue to visit our website often to participate in our Business Analyst Blog and find new resources for your profession. If you wish to provide articles or materials that we can share with your peers forward them to sales@b2ttraining.com.

T

TINA JOSEPH

Certified Woman Owned Business

BARBARA CARKENORD

the Fall 2006

volume 3 l issue 2

table of contents 3

Categorizing and Presenting Requirements

by Barbara Carkenord

7

IIBA Update

by Carol Lapp

9

Lost in Translation In Search of the Right Requirements

10

Spotlight on Supplemental Requirements

by Barbara Stroope

11

Page 10

by Kevin Brennan

Entity

n ctio un w) (Ho

ta Da at) h (W

Scope (Lvl.1)

Entity / Relationship

Overall P Mod

stem Model (Lvl.3)

Logical Data Model

Detailed Descri

Detailed entation (Lvl.5)

13

Page 3

Did You Know?

Requirements Template Package

Proces

iness Model (Lvl.2)

nology Model (Lvl.4)

The Business Analyst Toolbox

14 15

New Certified Business Analysts Ask the Experts Is the Proposed Solution the Right Solution?

Page 11

15

Book Review More About Software Requirements by Karl E. Wiegers

New Business Analyst Blog

M

17

To subscribe to the bridge, please visit www.b2ttraining.com.

B2T Training • 11675 Rainwater Drive, Suite 325 • Alpharetta, GA 30004 • 866.675.2125 B2T Training is a woman-owned business based in Atlanta, GA. We offer Business Analyst training that focuses on proven skills and techniques to define and scope the business problem, elicit and analyze requirements, document the requirements, model the requirements, and follow through with the development of business requirements test plans to ensure the project has met its defined objectives.

Our training is offered nationally and on a limited international basis. Most of our classes are taught onsite and are tailored to the unique environments of each organization. Public classes are also available in various cities around the US. CEO, Executive VP, Sales/Marketing Tina Joseph

President Barbara A. Carkenord

VP, Business Development Angie Perris

©2006 B2T Training. All rights reserved.

the bridge l Fall 2006 2

Categorizing and

BY BARBARA A. CARKENORD, PRESIDENT, B2T TRAINING, BABOKTM CORE TEAM

BABOK definition of requirement According to the IIBA: A requirement is a condition or capability needed by a stakeholder to solve a problem or achieve an objective.

BABOK 1.6 July 2006

3 Fall 2006 l the bridge

B

efore you start reading this article, take a moment, close your eyes and visualize a “requirement.” You might be surprised to learn that if you gather a group of Business Analysts and ask each one to describe what he or she envisions, you would hear many different descriptions. As I talk about presenting requirements, think about how your view of a requirement may differ from mine.

What is a requirement?

Every experienced BA has her own understanding of what a “requirement” looks like, but as a group we do not have a shared understanding. It is almost like a piece of art. If I see a canvas with various colors of paint spattered on it, I may think of it as art while someone else may think of it as a mess.

To me a requirement is anything that is important enough to discuss, analyze, document, and validate (see IIBA definition at left). A requirement can be documented and presented in any of the following ways or in any number of other formats.

• a sentence (“The system shall . . .)

• a structured sentence (as in a business rule) • structured text template • a table or spreadsheet (list of stakeholders) • a diagram (workflow) • a model (entity relationship diagram with associated details) • a prototype or simulation • a graph The format or representation does not qualify it as a requirement, it is the intent and the stakeholder need that make it a requirement. Many BAs do not include design documentation in their definition of requirements. They argue that these are not needs. I agree that business needs or requirements should come first, but once the solution has been identified and the business stakeholders help design a screen

Presenting Requirements layout – doesn’t this screen layout become a requirement because the user now needs it? I think we should broaden the term requirement to include everything that BAs produce to communicate with their stakeholders to accomplish the completion of the product.

Additionally, BAs often create diagrams, notes, spreadsheets, scribbles, etc. that they use to analyze and think through a particular problem. These “work products” may not be presented to a stakeholder, but they assist the BA in his work.

Note that the IIBA definition does not say anything about the format or representation of the requirement. We are free to represent it in any way that clearly communicates to our stakeholders.

to categorize—biographies are shelved in alphabetic order by the subject of the biography (i.e., biographies about Thomas Jefferson are shelved by the letters of his last name). Other books are more difficult—where do we find a book on World War II? It could be in history, historical fiction, biography, sociology, or American studies. Categorizing requirements presents this same challenge.

Deciding on categories and placing specific requirements into these categories is as much of an art as it is a science. Each

challenge as deciding how to categorize books. We have to balance our stakeholder needs when organizing requirements.

Business stakeholders want to review business requirements – usually at a high level. Technical stakeholders need to review functional and technical requirements and want them organized for easy development.

Deciding on categories is time consuming and challenging so it is inefficient to develop a new set of categories every time you start a project.

Your organization will be most efficient if it decides on one general categorization scheme and uses it consistently. What ever system you decide on will not be perfect. But any system is better than none.

A standard set of categories gives BAs, subject matter experts, and technical teams a consistent system with which they can learn to work.

The format or representation does not qualify it as a requirement, it is the intent and the stakeholder need that make it a requirement.

Categories of requirements While working on the BABOKTM my colleagues and I have shared our BA experiences and have found them to be very similar, yet when we tried to agree on a set of categories for requirements, our experiences and opinions were significantly different.

There are many opinions about how to categorize requirements, but we do agree that they need to be organized and categorized. We need these categories because when requirements are correct and complete they are usually very detailed.

Most projects include a large number of these detailed requirements. When we have a large number of “things” to keep track of, we usually organize these “things” into logical categories so they can be found and used quickly.

An analogy – categorizing books Think about how we keep track of books: fiction, non-fiction, biography, children’s, etc. When we walk into a bookstore or library looking for a particular book, the categories help us find the book for which we are searching. Some books are very easy

person who looks at a requirement may categorize it in a different way. There may be more than one category that is applicable to a particular requirement.

Over the years of book publishing, we have developed some general guidelines for categorizing books. Libraries in the United States use the Dewey Decimal System.

Many bookstores generally follow these guidelines but make changes as appropriate for their customers, publishers, authors, and employees. Having general guidelines makes the search for books much easier.

If you opened a bookstore how would you categorize books? Will you use a system that makes sense to your employees, so that they will quickly shelve new stock as it arrives? Will you use a system that makes sense to your customers, so that they will quickly find the book they want?

Would you use the Dewey Decimal System, a well accepted industry standard?

What if a new book is published that doesn’t belong in any of your categories?

Would you create a new category? Would you re-organize all of your categories once a month? Once a year? Never?

Deciding how to categorize requirements presents us with a similar

BABOK Categories The BABOK committee discussed categories of requirements for hours, each member bringing their own system to the group. In the end we decided that there is not one right system that works for all organizations. We agreed that any logical system will work if used properly. We decided to define some standard categories that are well documented in published sources: business requirements, user requirements, functional requirements, quality of service requirements, and technical requirements (See the latest version of the BABOK for definitions of each at www.theiiba.org).

Each organization should consider which of these categories (or any others) are appropriate for their business and create internal standards and guidelines. This article gives you some ideas for setting up your own system. the bridge l Fall 2006 4

Developing your organization’s “Dewey Decimal System” for requirements There are many factors to consider when designing your requirements category system. You must balance these factors to create the best system for your organization. Understanding why you are documenting requirements will help you decide how best to categorize them. Think about the following questions: • Should requirements be separated by their type? Business versus functional?

This is a great question and one that initially seems very obvious. Of course we want the business requirements (business needs that are independent of technology) to be listed separately from functional (behaviors of software). But there are some reasons why you might not want to separate them in your documentation. When you look at specific examples, the answer becomes less clear.

Let’s look at a simple data element in

with a screen prototype). This was a decision based on ease of review and reusability. So our requirement looked something like the chart on this page.

• In what order will the requirements be gathered? For a BA who has a requirements gathering plan, documenting requirements in the order gathered will be easiest. When the BA reviews the requirements as he or she iterates through more detailed levels, the requirements will be easy to follow and missing pieces will be obvious.

Unfortunately, requirements are often not elicited or gathered in a logical order.

Our business stakeholders don’t always talk about their needs in a straightforward, linear fashion. In addition, the iterative nature of requirements development means that the BA will often be finding unrelated requirements and then figuring out where to “put” them. Imagine if a publisher delivered a large box of books to your bookstore that were not in any

• How is each requirement used? This consideration is important when your requirements relate to software development. Most developers are not anxious to read through volumes of business requirements. They want to know exactly what you want the software to do. They also prefer the requirements to be separated by the technology needed.

For example, put all data elements together to assist the database designer or list all users together to make the security design easier. Are your developers onsite or offshore? How often will you be communicating with them? These factors will also play into your decision.

• How are the requirements related to each other? Tracing requirements to each other is a very important technique to ensure completeness and decrease change management time. I would argue that there are very few requirements that are not related to at least one other requirement. These relationships between requirements make their presentation more complex.

Name Unique? Mandatory? Repeating? Datatype Valid values Definition This aspect of requirements Course number of days N Y N Numeric 1-5 number of days in argues for a unique name or length that a particular number for every requirement. course spans These unique identifiers are particular order, placing each book on invaluable for tracing. This is also one of our business area: course number of days. the correct shelf in relation to the the many areas where a requirements This data element represents the number existing books would take some time and management tool is very beneficial. of days in length that a particular course an understanding of your system. spans. For example, Essential Skills for the (Continued, see Requirements page 17) Business Analyst is a 4-day course, course • Who will review each requirement? A number of days is 4. The data element BA’s most important job is to clearly and its definition are business communicate with his or her requirements – we would not be a stakeholders. Often there are several training company without this core piece stakeholders who will be reviewing of data. And there are business rules your requirements document and it about this data element, e.g., every would be most efficient for the course must have a course number of days. reviewers if the document is organized When we wrote software to support by reviewer area. For example, if a our business, we decided that this data stakeholder from Accounts Payable element should be included in a database only needs to review a few key and displayed on a screen. We wrote financial requirements, should we functional requirements about the data require him to read the entire element. The data element called course package and search for the items number of days is a numeric field, it is about which he is interested? On allowed to be a number from 1 to 5 and the other hand, do many of the the default value for it is 4. requirements that affect We chose to document all of the Accounts Payable also affect requirements related to this data element other stakeholders? together, business and functional (along

5 Fall 2006 l the bridge

U P D AT E

2006 IIBA Annual General Meeting

BY C A RO L L A P P, P R E S I D E N T I I BA C H A P T E R C OU N C I L

The IIBA held its third Annual General Meeting on Wednesday, July 12, 2006. If you were unable to attend, here’s what you missed…

We’ve come a long way, baby!

Since 2004, the IIBA membership increased from 37 to over 2,300, with 5,000 projected by December of this year.

In 2004, we were an idea. By March of 2005, we had our first solid chapter, and this July we have 42 chapters with 45 projected for December. From the two countries represented at the first meeting in 2004, we have grown to 36 with another 4 countries projected by year end.

As our membership has increased, we have refined our vision of a Business Analysis Professional. The new definition removes the restriction to the IT world, and describes the spread of business analysis throughout the organization, see definition below.

A Business Analysis Professional works as a liaison among stakeholders to elicit, analyze, communicate, and validate requirements for changes to business processes, policies, and information systems.

A Business Analysis Professional understands business problems and opportunities in the context of the requirements and recommends solutions that enable the organization to achieve its goals.

There were a lot of accomplishments in 2005. In addition to the growth of the organization, two versions of the Business Analysis Body of Knowledge (BABOKTM) were published, a Draft Candidate Handbook and Checklist were created, the Certification Process Flow was determined and a Code of Conduct was produced.

Certified Business Analysis Professional (CBAP) Well, it’s a great title, but what does it mean? In the world of business analysis, most of us know what we do, but few of our employers can delineate it. The oftenused (and misused) phrase, “Anyone can do the analysis” is probably familiar to everyone. There is a set of skills, however, that every qualified Business Analyst should possess. Some of these skills are shared by Project Managers, a few by Developers and Architects, but they are rarely honed to the level that a Business Analyst provides.

The designation, CBAP, indicates that a Business Analysis Professional possesses these skills, has used them in a business setting, and can provide value in determining the stakeholder’s true needs and helping to craft the right solution.

You don’t just take a test to become a CBAP. You must also demonstrate a significant amount of work experience, sufficient training to maintain your skills, and a grasp of the necessary knowledge areas. In addition, you will be expected to recertify on a regular basis to ensure that your skills are current.

The specifics of certification are still being fine-tuned, but expect to document

Putting us Out There No group becomes known just by existing.

It takes a focused campaign to ensure that the right people are aware of your presence and reason for being. Our Marketing and Communications committee has created brochures and booth graphics for our appearance at conferences, launched a newsletter to keep us current with the progress we’re making as a group, and developed marketing collateral and a website to help us get the message out.

The website is being updated with a new look-and-feel and a set of templates that each chapter can use to ensure that we maintain our brand recognition.

In addition, we are developing a set of speaking engagements, advertising opportunities, and meetings designed to help chapters make their marks locally.

Chapter Council With membership growing so quickly, the organization has two major needs: Help members establish new chapters and provide consistency across those chapters.

With that in mind, our Vice President of Chapters has created the Chapter Council.

The chapter council is tasked with two major assignments. The first is to create a

What have we done & where are we going?

Members

March 2004

March 2005

Dec 2005

July 2006

Dec Forecast

37

181

1091

2,300

5,000

1

21

42

45

3

18

36

40

Chapters Countries

7 Fall 2006 l the bridge

five years work experience in analysis (over the last 10 years), experience in at least four of the six knowledge areas, and three of the five underlying fundamentals, education requirements, 21 hours of professional development (over the last four years) and to provide two references (from clients, career managers, or other Certified Business Analysis Professionals).

2

standardized set of policies and guidelines so that all chapters maintain the same standards of quality. The second is to act as a liaison among the individual chapters and between the chapters and the Executive Board. The Council will also share information and provide answers to questions.

With members spread across 36 countries, on five continents, the necessity of a consistent channel of communications is clear. The Chapter Council provides each chapter with a contact to assist with the information and guidance to ensure the chapter’s success.

Now What?

In 2006, we will participate in seven conferences, six for Business Analyst World and one for the World Congress for

Business Analysts. At the World Congress, in November, we will be presenting version 2.0 of the Body of Knowledge, the version that will be used as the basis for the initial offering of the Certification Exam.

We have just become incorporated in Canada, and will continue to pursue activities to ensure that all our chapters are compliant with the guidelines and policies to support the organization.

We will be implementing a new website, one that will provide additional functionality and consistency, while affording the chapters greater control over their sections of the site.

We will be formalizing our Advisory Boards, which will include respected names in the business analysis community.

We will be aligning with other key

organizations in the business sector, such as PMI. We will continue to grow our membership and chapters and align them with the international organization. In addition, we will continue to push for recognition in the international community with members and chapters in additional countries around the world.

How Can I Help?

Are you a Business Analysis Professional?

Are you a member of the IIBA? Would you like to join or start a local chapter? Start at the IIBA website (www.iiba.com) to learn more about the organization and find out what we can do to support each other. I You may contact Carol at carol.lapp@SEMichigan.theiiba.org

Who’s Running the Show?

Now to the fun part… Election of Officers. After the meeting, we elected nine officers. Each officer will have a set of appointed personnel to ensure that we meet our goals. For the near future, all of these positions remain volunteer staff, with the possible exception of office staff and website maintenance personnel.

Kathleen Barret President Wayne McAlpine CIO

Louis Molnar Executive VP

Dean Hunter / Maria Cheung CFO

Kevin Brennan BABOK

Carol Deutschlander Education & Certification

Mary Simpkins Marketing & Communications

Membership Services

Body of Knowledge

Cleve Pillifant Role Definition

Jacqueline Young Special Events

Sponsorship

BOK Review

Endorsed Educ Providers

Web Master

Expert Panel

Certification Framework

Chris Becker Secretary

Indy Mitra Governance

Tina Joseph VP Chapters

Glenn Brule Int’l Development

Carol Lapp Chapter Council

the bridge l Fall 2006 8

lost in translation In Search of the Right Requirements

BY A N G I E P E R R I S, P M P,

ver many years, in the software industry, people working on projects have gathered and implemented requirements—some with great success and others – well let’s just say – with less than stellar results. Requirements have been misunderstood, misplaced, poorly defined, incorrectly communicated, and sadly lost in translation.

Unfortunately according to recent statistics, even though we have made great strides in developing software, eliciting the right requirements is still problematic and requirements tasks often get overlooked or short-changed. Some companies still think that unless there is coding going on, the project has been stalled. Really smart organizations are beginning to recognize that skilled Business Analysts, who know how to elicit and organize the right requirements in an acceptable timeframe, are now much more in demand than programmers! Additionally, there are several best practices that can help organizations and their BAs move toward defining excellent requirements:

much needs to be documented will vary somewhat from project to project, but using a standard template to house the complex and simple requirements will really help manage expectations from project stakeholders who must review, validate, verify, and approve the requirements.

O

M

1) Adopt a standard requirements template. A consistent requirements template will help all project members and customers know what to expect in techniques and documentation when they have to review a requirements package. Every project is unique and how

2) Organize requirements using standard requirements categories. For example, business requirements, functional requirements, quality of service requirements, and technical requirements. Organizing requirements in different categories, such as these, makes reviewing requirements easier, allows more flexibility in defining solution alternatives, creates needed reusable documentation, and makes traceability of requirements simpler.

Keep in mind, not every business requirement requires a software solution!

You may trace certain business requirements to an improved, streamlined process, or an organizational change.

3) Model requirements using different techniques to capture different views,

dimensions, and levels of detail. The more complex the project, the more a variety of techniques should be used to make sure that critical requirement components are not missed. Smaller projects or projects where requirements are very clearly understood by everyone require less modeling.

4) Trace all requirements beginning with the initial project purpose, objectives, and scope. Each business requirement should support the project purpose and business objectives. Each functional requirement should originate from a business requirement. Each technical requirement should support the functional requirements, etc. Each quality of service requirement should support the business environment and the customer expectations in terms of security, performance, maintainability, flexibility, portability, reliability, etc.

5) Allow BAs enough time to truly elicit excellent requirements. It takes time for a BA to investigate and elicit excellent requirements. BAs need to understand the project time, scope, and cost constraints to estimate the appropriate time commitment needed to define requirements. You can pay now or later in rework for missed requirements when costs increase exponentially if requirements tasks are short-changed.

6) Staff projects with trained and experienced BAs. These are critical team members, especially for projects that will need an IT solution. I

Upcoming Business Analyst and Related Events

• October 21 – 24, 2006 PMI Global Congress North America – Seattle, WA For more information visit: www.pmi.org

• November 6 – 9, 2006 World Congress for Business Analysts – Lake Buena Vista, FL For more information visit: www.iirusa.com/BAW/

• October 30 – November 2, 2006 Project Summit & Business Analyst World – Boston, MA For more information visit: www.projectsummit.com/bos/

• November 13 – 16, 2006 Project Summit & Business Analyst World – Chicago, IL For more information visit: www.projectsummit.com/chi/

Additional conferences are scheduled for Canada. For a complete listing please visit www.b2ttraining.com.

9 Fall 2006 l the bridge

SPOTLIGHT ON

Supplemental Requirements

BY BA R BA R A ST ROO P E , B U S I N E S S A N A LYST, AC X I O M

n most projects, some needs/constraints behavior or functionality of the solution. exist that must be incorporated into the See box for examples. software solution, about which the client How do I recognize a supplemental isn’t likely to ask or be aware. If you’ve ever requirement? You may want to ask yourself been part of a large or complex software the following questions: development project, you may have • Is it a requirement that must be part of struggled with these types of requirements. the solution, but the client isn’t likely to Where should they be stored? Should they ask for? be shared with the client? And, wouldn’t it • Does this requirement need to be be great if these requirements could documented and traced throughout the magically make their way into the solution project? build?

If you answered yes to this last question, you may be Supplemental Requirement Examples wrestling with what has • Audits commonly been called • Globalization and localization supplemental requirements.

• Legal or regulatory issues When building a software

I

solution, a Business Analyst will elicit requirements from a client – either from clients outside of your company or from other groups within your company. In many cases the solution will also be affected by requirements that originate from sources other than the client. Often these supplemental requirements are overlooked because they are not explicitly stated by the client.

• Hardware and software interfaces • Project glossaries • Operational • Performance requirements • Privacy requirements • Quality requirements • Failure and disaster recovery • Maintainability • Scalability • Safety • Security

• Training What is a Supplemental Requirement?

• Should this A supplemental requirement is a requirement be communicated to your requirement that doesn’t directly support a client for approval? particular function, but that the software solution must nevertheless meet. In other How should Supplemental words, even if these requirements are Requirements be stored? initially hidden to your client, they are Often supplemental requirements will be necessary for the solution or business. reusable across different projects. For Version 1.6 of the IIBA Business Analysis example, security requirements at your Body of Knowledge (BABOKTM) refers to these as Quality of Service Requirements company or industry are likely to be defined as requirements that capture similar no matter what the project’s conditions that do not directly relate to the context. Consider convening a group of

subject matter experts to write these types of supplemental requirements. If you use a requirements management tool, you should add these reusable, supplemental requirements to your project template so they will be pre-populated with the creation of each new project. If you don’t use a requirements management tool, create a master document that includes all of these supplemental requirements and store it somewhere that is accessible by your Business Analyst community.

For companies or projects with a lot of supplemental requirements, designate an owner to maintain and update these requirements at certain intervals. If your company’s security team updates its policies on a quarterly basis, then make sure a security representative updates the supplemental security requirements appropriately.

Should the client approve Supplemental Requirements?

In most cases, your requirements elicitation process will create a document that is sometimes referred to as a Software Requirements Specification (SRS). This document acts as a contract between the group building the solution and the client.

Supplemental requirements should be handled as any other sort of requirement is handled. They should be included in the SRS and should go through the same approval or sign-off process as all other requirements.

If you can gather, store, communicate, and manage these supplemental requirements, your solution will no doubt profit from it. I

the bridge l Fall 2006 10

The Business Analyst’s Toolbox

BY K E V I N B R E N N A N , S E N I O R C O N S U LTA N T, b l u e s a n d s i n c . , V I C E P R E S I D E N T BA B O K

TM

ver the last few decades, the business know enough different analysis techniques interact with one another. Below that there’s consulting and software development to cover the breadth of an enterprise a system model, which describes in detail communities have developed a bewildering framework, you know enough to address what each of those things are. This array of different business analysis almost any conceivable situation or project continues down until we have the actual techniques to understand and describe that might arise. applications, data, and so forth. processes, policies, and systems. As a The Zachman framework Not all of the levels of the Zachman practical matter, a Business Analyst is never (www.zifa.com) is one of several models for framework are relevant to a person in the going to have the time or need to become a the development of an enterprise business analysis role. When we look at the skilled practitioner of all of these architecture. It focuses on documenting scope of the BABOK, we find that BAs techniques. different perspectives of an organization, generally work down as far as the system While you can leave the techniques which makes it easy to show which analysis model but will in some cases go a little you’ll study up to the discretion of the techniques can be used to describe specific deeper. Figure 1 is adapted from the organization for which you work, how will cells in the framework. However, if you Zachman framework and shows how it you know if your skills are portable? How work in an organization that has adopted a maps to the range of activities found in the can you be sure that you’ve mastered different architecture framework, the BABOK. enough techniques to handle new lessons should still apply. situations that might arise? Fortunately, a The Zachman framework takes the six The Questions BA can usually manage with only a small classical questions (who, what, where, why, If you bother to count, you’ll see that the set of carefully chosen techniques, as long when, and how) and describes the models BA has a role to play in filling in 21 of 36 as he or she picks the right set of required to answer those questions in the cells in the framework. That sounds like a complementary analysis methods. context of a particular organization. For lot, I know. However, it doesn’t require 21 Figuring out which techniques to learn example, the question “how?” translates to different techniques to describe all those can be tricky. However, most methods “how does this organization do things?” models. In practice, you should need to aspire to provide coverage for a complete The framework then defines six different master no more than six or seven—one for application development lifecycle, but they levels of abstraction for the answers to each every column in the framework. That’s may not address things that fall outside the question. At the top level, we define the because most analysis techniques are approach envisioned by the method’s overall scope of the business—what intended to operate at multiple levels of creators. Other resources, like the Guide to processes, people, and events exist that are abstraction, and also because many the Business Analysis Body of Knowledge of interest to us. The second level, the techniques cover the same columns.

(BABOKTM) are comprehensive but not business model, looks at how all those Data models focus on describing what prescriptive, as they are forced to be things of interest relate to each other and the business knows about things of interest methodology-neutral.

FIGURE 1: General Scope of Business Analysis Activities in the Zachman Framework Enterprise Architecture An enterprise architecture is intended to provide guidance to an organization as to what sorts of processes are needed to List of support ongoing systems Scope Locations of the Business Major Business Entity Process List Organizations / (Lvl.1) Enterprise Strategy Events or Cycles Divisions development and change Plan Business Interactions Organization improvement efforts. An Entity / Detailed Business Model Overall Process Project between Chart, List of Relationship Schedule (Lvl.2) Model Objectives locations Roles enterprise architecture Detailed framework will help an Logical Data System Model Detailed Process Entity History, Business Rule Interaction Model (Lvl.3) Description Processing Model Model organization address everything from strategic planning to User Interface Technology Model Business Rule Design and Flow (Lvl.4) Specification application maintenance and Detailed UI, Detailed operational support. By Business Rule Security Representation (Lvl.5) Design definition, then, everything a Functioning BA does should fit into the Enterprise (Lvl.6) enterprise architecture adopted Gray cells indicate cells that fall outside of the scope of the BA role. by an organization. If you

O

on ati tiv ) Mo Why (

e Tim re) he (W

le op Pe ho) (W

ork tw ) Ne here (W

n tio nc Fu ow) (H

ta Da at) h (W

11 Fall 2006 l the bridge

and the relationships that those things have to one another.

Function models describe how the business gets things done and how the business works to achieve its goals. A function model will generally involve multiple people over a period of time— work that can be done by a single person in a single sitting is covered by people models.

Network models describe where the enterprise does work and how work performed at different locations is integrated. Of all of the columns, this one is probably the least important to the typical BA—as the name suggests, the people in IT who it concerns most are the network support personnel.

People models tell you who is of concern to the solution. In many cases, this model is nothing more than a stakeholder definition, but for commercial products, it may include things like a market segmentation. At lower levels, people models describe how stakeholders interact with a solution to accomplish their personal goals and responsibilities through the user interface.

Time models describe when events happen and when events can happen. A time model does not cover sequencing (that’s a function model) but rather expresses regular cycles that the business has to go through (like tax filing) or events that require a response.

Motivation models describe how the business makes decisions and why those decisions are made. A policy model describes who may make a decision, the information that they use to make that decision, and the rules that guide them in making that decision.

Model Coverage Figure 2 shows which requirements type can be expressed by which common (and a couple of less common) business analysis techniques. Obviously, these techniques have strengths and weaknesses that will not be obvious from just looking at the chart below—but it will tell you what a

FIGURE 2: Specific Analysis Techniques and the Zachman Framework Technique

Data

Activity Diagram Business Process/ Workflow Diagram Business Rules

Function

•

1,2,3

•

•

Class Model

1,2,3

CRUD Matrix

•

Data Dictionary

3

Data Flow Diagram

•

Data Transformation and Mapping

•

1,2,3

Deployment Diagram Entity Relationship Diagrams

Network

2,3

Time

People

•

3 3

Motivation •

3,4,5

•

5

4,5

•

•

1,2 1,2,3

Event Identification Flowchart

i*/Goal Oriented Requirements Language • Metadata Definition Sequence Diagram • State Machine Diagram • Storyboards/ Screen Flows Use Cases User Interface Designs User Profiles User Stories

• •

1,2

2,3

•

3,4

•

•

1,2,3

•

•

3

5

1,2,3

•

3,4,5 1,2,3

•

2,3,4

•

3,4,5 •

1,2

•

•

•

Legend: 1, 2, 3, 4, 5 - Framework level that the technique addresses • - Indicates that the technique can

technique can be used to do.

So how does this help a BA figure out which techniques to master? You should be able to use at least one primary technique for each column in the Zachman framework, and consider learning secondary techniques as and where required. You may find that text or matrices will suffice for describing some requirements (for instance, motivation requirements, especially the higher level ones, are often described in a Business Case or Vision document).

The particular techniques you choose to learn will depend on the business domain you work in, the methodologies chosen by your enterprise, and other matters. Not every project requires that you be able to completely describe all possible kinds of requirements. On the other hand, if you work intensively in a particular cell of the

framework, you may want to be familiar with more than one technique that applies to it for use with different audiences or to resolve different issues.

When the time comes to handle a new problem, though, you should have the tools you need to figure out whether something you already know how to do will help you solve it—or whether it’s going to be necessary to learn something new. I Kevin Brennan is a Senior Consultant with blue sands inc. and serves as the IIBA’s VicePresident of the BABOK. He has ten years of experience as a BA in multiple industries, including mortgage banking, courier services, auto manufacturing, energy retailing, and regulatory bodies. You may reach him at kevin.brennan@bluesands.com.

the bridge l Fall 2006 12

did you know?

Requirements Package Templates ne of the most frequent comments we hear from organizations is that they want a consistent way to document requirements.

Since this issue of the bridge is dedicated to the discussion of requirements, we feel it is appropriate to share with you one resource that we have available on our website for your requirements documentation. B2T Training developed a Requirements Package template which is currently being used by many companies and Business Analysts. Regardless of the methodology you are using for analysis and design, the templates provide an outline for documenting all of the requirements for your project.

The Requirements Package template is a MS Word速 document that provides sections for textual descriptions and tables to fully detail the core requirement components. We also recommend inserting diagrams or referring to them inside the document as a visual representation of the requirements. The following graphic represents the categories included in the Requirements Package.

O

The templates may be used as interviewing tools while eliciting requirements and as a documentation format for the requirements details. Templates provide an easier way for subject matter experts to review requirements versus reading a long detailed textual document.

They also eliminate the need for the developer to pull out the relevant information necessary to make any technological changes or enhancements required. Sample templates for documenting the core business components are presented at right.

The Requirements Package templates may be downloaded for free at www.b2ttraining.com on our BA Resources page. n

13 Fall 2006 l the bridge

ESSENTIAL PROCESS DETAILS

ENTITY

RELATIONSHIPS (DATA RELATED BUSINESS RULES)

SYSTEM USE CASE DESCRIPTION

New Certified Business Analysts We are pleased to highlight the latest individuals who have earned the title of Certified Business Analyst since the last issue of the bridge. To date, we have more than 2,800 people in our program, with over 175 who have completed and received certification. We have an additional 350 candidates that have passed three proficiency exams and are in the final stage of the process. B2T Training Certified Business Analysts have demonstrated knowledge and application of business analysis and we congratulate them on their success.

Dawn Aberbach Chris Beck Terry Chesney Taryn Drane Dianna Houston Pam Justice Patricia A. Kline Lois V. Koczon Shirl Levandusky Bill Liswell Melissa Marsee Lana K. McCain Edward S. Meglis Susan Parsley Bridget Schmolling Sandi Spillner Michelle Nicole Thomason Lisa Tucker Donna West Jack Widman Carrie (Kairui) Yi

Submit an article to the bridge!

The bridge is published twice a year and focuses on a particular area of interest within business analysis.

Articles relevant to the topic area are preferred; however, any articles about best practices, project success stories, BA resources (books or tools) will also be considered. Submission deadlines for 2007 spring and fall issues are February 5, and July 9, 2007. To submit an article send an email to sales@b2ttraining.com. the bridge l Fall 2006 14

ask the experts Is the Proposed Solution the Right Solution?

Question: I am a Business Analyst in an IT organization and often my project starts after there is a proposed IT solution. How should I proceed to ensure that software is the right solution?

Answer: This is a very common scenario.

Many BAs are not brought into projects until a decision is made that a software solution is needed to address the customer’s needs. This situation is likely to continue.

An excellent BA needs to make the effort to understand the business and the environment to make sure the proposed solution is the best/right solution. For example, assume a business sponsor came to your team and said he needs a website created to help grow market share. The BA should not just run out and begin gathering detailed functional requirements

for a website. Rather, the BA should take some time up front to validate the proposed solution. This is accomplished by eliciting and analyzing the detailed business requirements. The BA should ensure the customer identifies why he needs the website and what business activity will be accomplished on the website. Is that business activity done today? Is it being done well? What impact will the website activity have on the rest of the organization, etc?

I am not saying that all successful projects require detailed business requirements to be elicited, analyzed, and documented, but when they are accurately elicited and analyzed there is a higher probability that the solution will meet the business need. I have been involved in

software implementation projects where the team delivered a solution meeting the detailed functional requirements. Then, once in production, the system was not used, primarily because the solution did not meet the business requirements, which were not analyzed in detail.

In conclusion, the IT BA may not be the initial person eliciting and documenting detailed requirements. The customer may feel he or she has already gathered and documented the requirements. To increase the probability of meeting the true customer need, the BA should ensure detailed business requirements are elicited, agreed upon, and analyzed before determining a solution. I Send your questions to Ask the Experts at sales@b2ttraining.com.

book review More about Software Requirements

by Karl E. Wiegers R E V I E W E D BY BA R BA R A A . C A R K E N O R D, P R E S I D E N T, B 2 T T R A I N I N G ,

arl Wiegers has followed up his very successful book Software Requirements with a new book called More About Software Requirements subtitled Thorny Issues and Practical Advice. Wiegers’ first book has become almost a required part of every Business Analyst’s library. I anxiously dove into his new book hoping to find the same kind of helpful reference material.

While Wiegers does a good job of describing the thorny issues that Business Analysts face, his practical advice is not specific and basically states that the BA must use his or her judgment on these issues. I do agree and I think this just demonstrates that to be a successful BA, a lot of practical experience is required and the answers to many of the questions we

K

15 Fall 2006 l the bridge

face cannot be found in a book.

I also agree with Wiegers’ definition of the word “requirement” referring to the “many kinds of information that fit into this big pot of soup we call ‘the requirements’.” He includes all of the various types and levels of requirements represented in a variety of ways (see the main article in this issue of the bridge for a discussion about the word “requirement”).

There are many good suggestions in the book, reinforcing his first book and refining some of the material originally presented.

Wiegers presents some great research statistics that may help BAs justify how much of a project’s time should be spent on requirements and what the payoff will be for the project. He also does a great job

of showing how a BA is really a key player in a successful project.

As with the first book, this book focuses on software requirements, only briefly mentioning business requirements. BAs need to be aware that software may or may not be the correct solution for every product. I think that this book will be most helpful to mid-level BAs who are beginning to understand the subtle issues they face in deciding how to elicit and document requirements. I Barbara A. Carkenord is the President of B2T Training. She has worked in the requirements gathering and documentation field for over 20 years and has conducted hundreds of seminars for Business Analysts.

Comments are welcome at bcarkenord@b2ttraining.com.

B2T RATING: ### (scale is 1-4; 4 is the best)

IIBA body of knowledge B2T Training’s Course Alignment with the BABOKTM The B2T Training program is a comprehensive program that aligns with all areas of the Business Analysis Body of Knowledge (BABOK) and will help prepare you for both the B2T Training Certification and the IIBA Certification when it is available. The BABOK is a collection of business analysis tasks categorized into like groupings called knowledge areas. The BABOK is not a methodology and does not infer any particular order of performing the activities. B2T Training’s program is taught in a series of courses that reflect the order of work and iterative nature of business analysis. The graphic below illustrates the alignment between the BABOK and B2T Training courses.

Business Analysis Body of Knowledge Requirements Planning & Management Enterprise Analysis

Requirements Elicitation

Requirements Analysis & Documentation

Requirements Communications

Solution Assessment and Validation

Fundamentals

B2T Training Core Course Alignment

Essential Skills for the Business Analyst

Detailing Business Data Requirements

Detailing Process and Business Rule Requirements

Additional B2T Training Course Alignment

Advanced Business Analysis Techniques

Facilitating Requirements for Business Analysis

Requirements Testing for the Business Analyst

M

Additionally, B2T Training is excited to be among the first Charter Members identified under the Endorsed Education Provider program. The EEP program identifies training vendors whose programs support the IIBA mission and the BABOK. Being granted this honor, reflects B2T Training’s commitment to providing a high-quality, up-to-date business analysis curriculum that meets IIBA standards and guidelines.

Please review the comparison information above and if you have any questions please contact us at sales@b2ttraining.com.

the bridge l Fall 2006 16

New Business Analyst Blog ecently we launched a new blog on the B2T Training website. The Business Analyst Blog is an online resource for Business Analysts. It contains fresh thoughts, brief articles, business analysis tips, and industry updates written by B2T Training Business Analyst experts.

Each week a new topic is posted by a B2T Training business analysis expert and readers are encouraged to participate by sharing their thoughts and experiences.

Topics covered in the blog include business analysis tips, articles, and industry updates.

The blog serves as a springboard for Business Analysts to share ideas and learn from each other and is a great resource and reference to help keep you focused and up-to-date on the latest trends and industry best practices.

R

Recent entries include: • Is a Model a Requirement?

• Business Rules vs. Business Process Management • How Do You Know When Requirements are Complete?

• Is an As-Is Workflow Diagram a Requirement?

• Why Does a Business Analyst Need to Understand Data

Check it out at www.b2ttraining.com!

(Requirements, continued from page 5)

• Should the same requirement be presented in different ways for different stakeholders? Ideally the answer to this question is no. BAs have enough work to do as it is, we don’t want to be repackaging the same information multiple ways. However, a BA’s most important job is to clearly communicate with our stakeholders (Did I already say that?

Well, we can’t say it enough!) If a requirement is clear to one stakeholder in a graphical format and clear to another stakeholder in a sentence, then we may have to present multiple versions. If this is necessary (and I would make sure that it is absolutely necessary), then make sure you keep both versions up to date when there are changes.

17 Fall 2006 l the bridge

• Which requirements are reusable? Many requirements are re-usable on future projects and it may be helpful to document them together. This is another area where a requirements management tool is very helpful.

Conclusions 1. I hope that we can open our minds to consider broader definitions of the word requirement. We may not agree, but we need to be aware that there is not just one definitive understanding of the word requirement and quality communication can only take place when we acknowledge these differences.

2. Regardless of how you categorize and present requirements you must let your reviewers know where to find things. A table of contents for a requirements package is absolutely essential.

3. If your organization does not have a consistent categorization schema – implement one. Create one, try it, and revise as you learn, any system is better than none. Most projects have a large enough number of requirements to justify categorizing them into groups.

These groupings make the requirements easier to document, double check, and review. I recommend business, functional, technical, and quality of service (also referred to as supplemental requirements, see article on page 10), as good solid categories for a starting point.

4. Tools for categorizing and presenting requirements will make BAs much more productive and we should continue working with tool vendors to help them understand the complexity of categorizing requirements. I

certified core courses Essential Skills for the Business Analyst

4 Days

A Business Analyst acts as a liaison between business people who have a business problem and technology people who know how to create solutions. A Business Analyst’s main responsibility is to elicit, detail, and document requirements in a format that is useful to their business stakeholders and the technical developers.

This course covers the critical skills for Business Analysts and is appropriate for new and/or experienced Business Analysts. New Business Analysts will learn the tasks they are expected to perform and why each task is important. Experienced Business Analysts will learn new techniques and more structured approaches to improve their requirements development activities.

Detailing Business Data Requirements

3 Days

Understanding and documenting business data requirements is a critical component in defining complete requirements. Every process uses data and almost all business rules are enforced by data. Missing a critical piece of data or incorrectly defining a data element contributes to the majority of maintenance problems and results in systems that do not reflect the business needs. This course teaches students an indepth approach to identify and define all necessary data components using both textual templates and an entity relationship diagram.

Detailing Process and Business Rule Requirements

4 Days

This course continues the development of the requirements package by defining the processes and business rules for the project. Business Analysts are expected to analyze and understand business problems and be able to make recommendations to help the business stakeholders solve problems. The most effective approach to ensure success is to understand the business environment and document the business requirements, and then use functional requirements to document how software automation can support the business.

M

Functional requirements document how the software should “behave.� These requirements must specify how users will interact with the software and how the software will respond. Business Analysts are uniquely qualified to document these requirements because of their understanding of the business needs and the user's work environment. These requirements will be used to articulate the technology needs of a quality software application that will meet the business needs.

For more information on these courses visit www.b2ttraining.com.

19 Fall 2006 l the bridge

M M M M M

In this course Business Analysts will learn to: • Scope the project from the Business Analyst’s perspective.

• Identify and gather the requirements that are critical to the business mission.

• Learn how to ask the right questions.

• Identify the five core requirements components.

• Know when a requirement is excellent.

• Plan an approach for documenting, categorizing, and packaging requirements.

• Verify that requirements are testable and generate testing objectives.

• Conduct a requirements review.

• Gather requirements in a group setting by preparing an agenda and managing the group discussion.

M M M M M

In this course Business Analysts will learn to: • Identify core data requirements beginning with project initiation.

• Identify excellent data requirements at the appropriate level of detail.

• Identify and detail attributive, associative, and subtype and supertype entities.

• Detail complex data related business rules.

• Discriminate between Business Data (Logical Data) and Database Design (Physical Data).

• Transition business data to database design.

• Utilize easy normalization techniques (without all the mathematical theory).

• Validate data requirements with activity (process or use case) requirements.

M M M M M

In this course Business Analysts will learn to: • Understand and document the business environment using a suggested structure, including detailed templates for defining the business and functional requirements for processes and business rules.

• Look beyond the current technology or procedures to discover the true nature of the business activity.

• Ask the right questions to identify the core business processes and the business rules that control or guide them.

• Document functional requirements which describe how the software should “behave.”

• Utilize several diagrams including the decomposition diagram, Use Case diagram, and workflow diagrams.

• Look at the business area from an objective perspective after business requirements are documented and organized to present alternative design solutions that meet the customer needs.

• Validate business processes against data requirements.

the bridge l Fall 2006 20

additional business analysts courses Facilitating Requirements for Business Analysis

3 Days

This course teaches students to plan and conduct a facilitated session to gather business and functional requirements. The art of bringing people together to elicit requirements and gain consensus on solutions is a critical success factor for all BAs. The workshops in this course ensure students have the opportunity to conduct a requirements elicitation session for one project deliverable and to play each of the key roles in at least one session. This class is limited to 8 students and over 60% of the class time is spent on interactive, real-world business case study facilitated sessions.

Requirements Testing for the Business Analyst

3 Days

This course provides an excellent foundation for Business Analysts to achieve best practices in software quality assurance (SQA). The course will improve the Business Analyst’s development of requirements so that they can be used to build quality test cases. It will also enable the Business Analyst to create specific test cases from the requirements. The course includes a workshop case study that provides a cohesive learning experience.

Advanced Business Analysis Techniques

3 Days

M

This course enhances the efficiency and effectiveness of Business Analysts by giving them additional techniques and strategies for gathering, documenting, and reviewing requirements. Techniques such as advanced data definition, traceability, and gap analysis help Business Analysts document more accurate and complete requirements. The course also presents the concept of requirements management and requirements reuse.

Implementing a requirements management process into your organization can significantly reduce the time required to make software changes and develop software interfaces.

For more information on these courses visit www.b2ttraining.com.

21 Fall 2006 l the bridge

management/technical seminars Overview of Business Analysis

4 Hour Seminar

This seminar presents the Business Analyst role to managers and others who lead and work with Business Analysts. In order for the Business Analyst to be successful, both the IT and business community must embrace the business analysis process. The seminar can be used as a working session to discuss how your organization will implement the business analysis process and approaches for documenting the requirements.

Developer’s Introduction to Business Analysis

1 Day

M

This class provides an overview of the Business Analyst role and a detailed review of the requirements document provided to the development team. To ensure an integrated team, IT developers need to understand the role of the Business Analyst. They should also be familiar with the requirements that Business Analysts are gathering and documenting. This includes understanding categories of requirements, the core requirement components, and the documentation formats used for each type of requirement. IT team members must also understand the testing life cycle and the personnel involved. This course gives students an overview of the role of the Business Analyst, requirements documentation, and software testing.

For more information on these courses visit www.b2ttraining.com.

the bridge l Fall 2006 22

2006-07 public class schedule Essential Skills for the Business Analyst

Detailing Business Data Requirements -

Facilitating Requirements for

$1,980/per student

$1,485/per student

Business Analysis - $1,485 per student

• Oct 2 – Oct 5, 2006 Chicago, IL

• Oct 23 – Oct 25, 2006 Chicago, IL

• Oct 16 – Oct 18, 2006 Chicago, IL

• Oct 16 – Oct 19, 2006 Houston, TX

• Nov 14 – Nov 16, 2006 Houston, TX

• Apr 23 – Apr 25, 2007 Atlanta, GA

• Nov 6 – Nov 9, 2006 Dallas, TX

• Apr 30 – May 2, 2007 Atlanta, GA

• Nov 13 – Nov 16, 2006 New York, NY

• Apr 30 – May 2, 2007 Dallas, TX

Requirements Testing for the

• Dec 4 – Dec 7, 2006 Seattle, WA

• May 7 – May 9, 2007 Chicago, IL

Business Analyst - $1,485 per student

• Jan 22 – Jan 25, 2007 San Diego, CA

• May 21 – May 23, 2007 Louisville, KY

• Dec 11 – Dec 13, 2006 Louisville, KY

• Jan 29 – Feb 1, 2007 Atlanta, GA

• Jun 4 – Jun 6, 2007 Seattle, WA

• Feb 5 – 8, 2007 Dallas, TX

• Jun 25 – Jun 27, 2007 New York, NY

Advanced Business Analysis Techniques

• Feb 26 – Mar 1, 2007 Louisville, KY

• Jul 16 – Jul 18, 2007 San Diego, CA

$1,485 per student

• Mar 5 – Mar 8, 2007 Chicago, IL

• Oct 15 – Oct 17, 2007 Atlanta, GA

• Oct 16 – Oct 18, 2006 Louisville, KY

• Mar 19 – Mar 22, 2007 Seattle, WA

• Nov 6 – Nov 8, 2006 Atlanta, GA

• Mar 26 – Mar 29, 2007 New York, NY

Detailing Process and Business Rule

• Apr 16 – Apr 19, 2007 San Diego, CA

Requirements - $1,980/per student

• May 21 – May 24, 2007 Atlanta, GA

• Sep 25 – Sep 28, 2006 New York, NY

• Aug 20 – Aug 23, 2007 Atlanta, GA

• Oct 2 – Oct 5, 2006 Atlanta, GA

• Sep 17 – Sep 20, 2007 Chicago, IL

• Nov 6 – Nov 9, 2006 Seattle, WA

• Oct 15 – 18, 2007 Dallas, TX

• Nov 13 – Nov 16, 2006 Louisville, KY

• Nov 5 – Nov 8, 2007 Atlanta, GA

• Dec 4 – Dec 7, 2006 Chicago, IL

• Nov 12 – Nov 15, 2007 New York, NY

• Dec 11 – Dec 14, 2006 Houston, TX

• Dec 3 – Dec 6, 2007 San Diego, CA

• Jul 16 – Jul 19, 2007 Atlanta, GA

• Dec 10 – Dec 13, 2007 Louisville, KY

• Jul 23 – Jul 26, 2007 Dallas, TX • Aug 6 – Aug 9, 2007 Chicago, IL • Sep 17 – Sep 20, 2007 Louisville, KY • Oct 1 – Oct 4, 2007 New York, NY

Please check our website for additional public class offerings and to check availability and register – www.b2ttraining.com.

On-site classes are also available.

• Oct 15 – Oct 18, 2007 Seattle, WA • Nov 5 – Nov 8, 2007 San Diego, CA • Nov 27 – Nov 30, 2007 Atlanta, GA

B2T Training 11675 Rainwater Drive, Suite 325 Alpharetta, GA 30004

Call 866.675.2125 or email us at sales@b2ttraining.com.

Prsrt Std U.S. Postage PAID Permit #309 Knoxville, TN