categorizing and presenting requirements · business analysis body of knowledge (babok™) we chose...

Supplemental

Requirements

Barbara Stroope

Book Review

More About Software

Requirements

IIBA Update

Carol Lapp

The Business

Analyst Toolbox

Kevin Brennan

the CONNECTING BUSINESS REQUIREMENTS TO TECHNOLOGY

Fall 2006

Categorizing

and Presenting RequirementsWhat is a Requirement?

letter from the editors

The fall is a busy time for many Business Analysts; many projectsare getting started as we are all back from our summer vacations.

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

With the upcoming conferences and the development of theBusiness Analysis Body of Knowledge (BABOK™) we chose to focusthis issue on what many people consider to be the most importantdeliverable 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 helpsto clarify our shared definition of the word “requirement,” discusses many approaches to representingrequirements, and gives guidance on presenting requirements in a consistent manner that best fits yourorganization’s need.

Kevin Brennan, Vice President BABOK, shares his view of the variety of requirements analysis techniques inhis article, The Business Analyst Toolbox. His article describes where the most common requirements techniquesfit within the Zachman framework of enterprise architecture development. Kevin’s article demonstrates thecomplexity 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 articleSpotlight on Supplemental Requirements.

The IIBA held its third Annual General Meeting in July. Carol Lapp, President, IIBA Chapter Council, givesus 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 aboutsearching for the right requirements. Ask the Experts encourages BAs to ensure that the proposed solution is infact the most appropriate solution. Finally, the book review in this month’s issue is of Karl Wiegers’ mostrecently published book—More About Software Requirements.

We encourage you to continue to visit our website often to participate in our Business Analyst Blog and findnew resources for your profession. If you wish to provide articles or materials that we can share with your peersforward them to [email protected].

TINA JOSEPH BARBARA CARKENORD

Certified Woman Owned Business

TINA JOSEPH and BARBARA CARKENORD

t a b l e o f c o n t e n t sCategorizing and Presenting Requirementsby Barbara Carkenord

IIBA Updateby Carol Lapp

Lost in TranslationIn Search of the Right Requirements

Spotlight on Supplemental Requirementsby Barbara Stroope

The Business Analyst Toolboxby Kevin Brennan

Did You Know?Requirements Template Package

New Certified Business Analysts

Ask the ExpertsIs the Proposed Solution the Right Solution?

Book ReviewMore About Software Requirements by Karl E. Wiegers

New Business Analyst Blog

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 thatfocuses on proven skills and techniques to define and scope the business problem, elicit and analyzerequirements, document the requirements, model the requirements, and follow through with thedevelopment 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 onsiteand are tailored to the unique environments of each organization. Public classes are also available in variouscities around the US.

CEO, Executive VP, Sales/Marketing Tina Joseph

©2006 B2T Training. All rights reserved.

the

Fall 2006

3

7

9

10

11

13

14

15

15

17

the bridge l Fall 2006 2

PresidentBarbara A. Carkenord

VP, Business DevelopmentAngie Perris

volume 3 l issue 2

Page 11

Entity Proces

Entity /Relationship

Overall PMod

Logical DataModel

Detailed Descri

Scope

(Lvl.1)

Data

(What)

unctio

n

(How

)

iness Model

(Lvl.2)

stem Model

(Lvl.3)

nology Model

(Lvl.4)

Detailed

entation (Lvl.5)

Page 10

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

Categorizing and

3 Fall 2006 l the bridge

efore you start reading thisarticle, take a moment, closeyour eyes and visualize a“requirement.” You might be

surprised to learn that if you gather agroup of Business Analysts and ask eachone to describe what he or she envisions,you would hear many differentdescriptions. As I talk about presentingrequirements, think about how your viewof a requirement may differ from mine.

What is a requirement?

Every experienced BA has her ownunderstanding of what a “requirement”looks like, but as a group we do not have ashared understanding. It is almost like a

piece of art. If I see a canvas with variouscolors of paint spattered on it, I may

think of it as art while someone elsemay 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). Arequirement can be documented andpresented 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 notqualify it as a requirement, it is the intentand the stakeholder need that make it arequirement. Many BAs do not includedesign documentation in their definition ofrequirements. They argue that these are notneeds. I agree that business needs orrequirements should come first, but oncethe solution has been identified and thebusiness stakeholders help design a screen

BY BARBARA A. CARKENORD,

PRESIDENT, B2T TRAINING,

BABOKTM CORE TEAM

BABOK definition of requirement

According to the IIBA: A requirement is a conditionor capability needed by astakeholder to solve aproblem or achieve anobjective.

BABOK 1.6 July 2006

B

Presenting Requirementslayout – doesn’t this screen layout becomea requirement because the user now needsit? I think we should broaden the termrequirement to include everything thatBAs produce to communicate with theirstakeholders to accomplish thecompletion of the product.

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

Note that the IIBAdefinition does not say anything about the format or representation of therequirement. We are free torepresent it in any way thatclearly communicates to ourstakeholders.

Categories of requirements

While working on the BABOKTM mycolleagues and I have shared our BAexperiences and have found them to bevery similar, yet when we tried to agree ona set of categories for requirements, ourexperiences and opinions were significantlydifferent.

There are many opinions about how tocategorize requirements, but we do agreethat they need to be organized andcategorized. We need these categoriesbecause when requirements are correct andcomplete they are usually very detailed.Most projects include a large number ofthese detailed requirements. When we havea large number of “things” to keep track of,we usually organize these “things” intological categories so they can be found andused 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 orlibrary looking for a particular book, thecategories help us find the book for whichwe are searching. Some books are very easy

to categorize—biographies are shelved inalphabetic order by the subject of thebiography (i.e., biographies about ThomasJefferson are shelved by the letters of hislast name). Other books are moredifficult—where do we find a book onWorld War II? It could be in history,historical fiction, biography, sociology, orAmerican studies. Categorizingrequirements presents this same challenge.Deciding on categories and placing specificrequirements into these categories is asmuch of an art as it is a science. Each

person who looks at a requirement maycategorize it in a different way. There maybe more than one category that isapplicable to a particular requirement.

Over the years of book publishing, wehave developed some general guidelines forcategorizing books. Libraries in the UnitedStates use the Dewey Decimal System.Many bookstores generally follow theseguidelines but make changes as appropriatefor their customers, publishers, authors,and employees. Having general guidelinesmakes the search for books much easier.

If you opened a bookstore how wouldyou categorize books? Will you use asystem that makes sense to your employees,so that they will quickly shelve new stockas it arrives? Will you use a system thatmakes sense to your customers, so that theywill quickly find the book they want?Would you use the Dewey DecimalSystem, a well accepted industry standard?What if a new book is published thatdoesn’t belong in any of your categories?Would you create a new category? Wouldyou re-organize all of your categories oncea month? Once a year? Never?

Deciding how to categorizerequirements presents us with a similar

challenge as deciding how to categorizebooks. We have to balance our stakeholderneeds when organizing requirements.Business stakeholders want to reviewbusiness requirements – usually at a highlevel. Technical stakeholders need toreview functional and technicalrequirements and want them organized foreasy development.

Deciding on categories is timeconsuming and challenging so it isinefficient to develop a new set ofcategories every time you start a project.

Your organizationwill be most efficientif it decides on onegeneralcategorizationscheme and uses itconsistently. Whatever system you

decide on will not be perfect. But anysystem is better than none.

A standard set of categories gives BAs,subject matter experts, and technical teamsa consistent system with which they canlearn to work.

BABOK Categories

The BABOK committee discussedcategories of requirements for hours, eachmember bringing their own system to thegroup. In the end we decided that there isnot one right system that works for allorganizations. We agreed that any logicalsystem will work if used properly. Wedecided to define some standard categoriesthat are well documented in publishedsources: business requirements, userrequirements, functional requirements,quality of service requirements, andtechnical requirements (See the latestversion of the BABOK for definitions ofeach at www.theiiba.org).

Each organization should considerwhich of these categories (or any others)are appropriate for their business and createinternal standards and guidelines. Thisarticle gives you some ideas for setting upyour own system.


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

Developing your organization’s

“Dewey Decimal System” for

requirements

There are many factors to consider whendesigning your requirements categorysystem. You must balance these factors tocreate the best system for yourorganization. Understanding why you aredocumenting requirements will help youdecide how best to categorize them. Thinkabout the following questions:

• Should requirements be separated bytheir type? Business versus functional?This is a great question and one thatinitially seems very obvious. Of coursewe want the business requirements(business needs that are independent oftechnology) to be listed separately fromfunctional (behaviors of software). Butthere are some reasons why you mightnot want to separate them in yourdocumentation. When you look atspecific examples, the answer becomesless clear.

Let’s look at a simple data element in

our business area: course number of days.This data element represents the numberof days in length that a particular coursespans. For example, Essential Skills for theBusiness Analyst is a 4-day course, coursenumber of days is 4. The data elementand its definition are businessrequirements – we would not be atraining company without this core pieceof data. And there are business rulesabout this data element, e.g., everycourse must have a course number of days.

When we wrote software to supportour business, we decided that this dataelement should be included in a databaseand displayed on a screen. We wrotefunctional requirements about the dataelement. The data element called coursenumber of days is a numeric field, it isallowed to be a number from 1 to 5 andthe default value for it is 4.

We chose to document all of therequirements related to this data elementtogether, business and functional (along

with a screen prototype). This was adecision based on ease of review andreusability. So our requirement lookedsomething like the chart on this page.

• In what order will the requirements begathered? For a BA who has arequirements gathering plan,documenting requirements in the ordergathered will be easiest. When the BAreviews the requirements as he or sheiterates through more detailed levels, therequirements will be easy to follow andmissing pieces will be obvious.Unfortunately, requirements are oftennot elicited or gathered in a logical order.Our business stakeholders don’t alwaystalk about their needs in astraightforward, linear fashion. Inaddition, the iterative nature ofrequirements development means thatthe BA will often be finding unrelatedrequirements and then figuring outwhere to “put” them. Imagine if apublisher delivered a large box of booksto your bookstore that were not in any

particular order, placing each book onthe correct shelf in relation to theexisting books would take some time andan understanding of your system.

• Who will review each requirement? ABA’s most important job is to clearlycommunicate with his or herstakeholders. Often there are severalstakeholders who will be reviewingyour requirements document and itwould be most efficient for thereviewers if the document is organizedby reviewer area. For example, if astakeholder from Accounts Payableonly needs to review a few keyfinancial requirements, should werequire him to read the entirepackage and search for the itemsabout which he is interested? Onthe other hand, do many of therequirements that affectAccounts Payable also affectother stakeholders?

• How is each requirement used? Thisconsideration is important when yourrequirements relate to softwaredevelopment. Most developers are notanxious to read through volumes ofbusiness requirements. They want toknow exactly what you want the softwareto do. They also prefer the requirementsto be separated by the technology needed.For example, put all data elementstogether to assist the database designer orlist all users together to make the securitydesign easier. Are your developers onsiteor offshore? How often will you becommunicating with them? These factorswill also play into your decision.

• How are the requirements related toeach other? Tracing requirements to eachother is a very important technique toensure completeness and decrease changemanagement time. I would argue thatthere are very few requirements that arenot related to at least one otherrequirement. These relationshipsbetween requirements make their

presentation more complex.This aspect of requirementsargues for a unique name ornumber for every requirement.These unique identifiers are

invaluable for tracing. This is also one ofthe many areas where a requirementsmanagement tool is very beneficial.


Name Unique? Mandatory? Repeating? Datatype Valid values Definition

Course number of days N Y N Numeric 1-5 number of days in length that a particular course spans

(Continued, see Requirements page 17)

We’ve come a long way, baby!Since 2004, the IIBA membershipincreased from 37 to over 2,300, with5,000 projected by December of this year.In 2004, we were an idea. By March of2005, we had our first solid chapter, andthis July we have 42 chapters with 45projected for December. From the twocountries represented at the first meeting in2004, we have grown to 36 with another 4countries projected by year end.

As our membership has increased, wehave refined our vision of a BusinessAnalysis Professional. The new definitionremoves the restriction to the IT world,and describes the spread of businessanalysis throughout the organization, seedefinition below.

A Business Analysis Professional worksas a liaison among stakeholders toelicit, analyze, communicate, andvalidate requirements for changes tobusiness processes, policies, andinformation systems.

A Business Analysis Professionalunderstands business problems andopportunities in the context of therequirements and recommendssolutions that enable the organization to achieve its goals.

There were a lot of accomplishments in2005. In addition to the growth of theorganization, two versions of the BusinessAnalysis Body of Knowledge (BABOKTM)were published, a Draft CandidateHandbook and Checklist were created, theCertification Process Flow was determinedand a Code of Conduct was produced.

Certified Business Analysis

Professional (CBAP)Well, it’s a great title, but what does itmean? In the world of business analysis,most of us know what we do, but few ofour employers can delineate it. The often-used (and misused) phrase, “Anyone can dothe analysis” is probably familiar toeveryone. There is a set of skills, however,that every qualified Business Analystshould possess. Some of these skills areshared by Project Managers, a few byDevelopers and Architects, but they arerarely honed to the level that a BusinessAnalyst provides.

The designation, CBAP, indicates that aBusiness Analysis Professional possessesthese skills, has used them in a businesssetting, and can provide value indetermining the stakeholder’s true needsand helping to craft the right solution.

You don’t just take a test to become aCBAP. You must also demonstrate asignificant amount of work experience,sufficient training to maintain your skills,and a grasp of the necessary knowledgeareas. In addition, you will be expected torecertify on a regular basis to ensure thatyour skills are current.

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

five years work experience in analysis (overthe last 10 years), experience in at least fourof the six knowledge areas, and three of thefive underlying fundamentals, educationrequirements, 21 hours of professionaldevelopment (over the last four years) andto provide two references (from clients,career managers, or other CertifiedBusiness Analysis Professionals).

Putting us Out ThereNo group becomes known just by existing.It takes a focused campaign to ensure thatthe right people are aware of your presenceand reason for being. Our Marketing andCommunications committee has createdbrochures and booth graphics for ourappearance at conferences, launched anewsletter to keep us current with theprogress we’re making as a group, anddeveloped marketing collateral and awebsite to help us get the message out.

The website is being updated with anew look-and-feel and a set of templatesthat each chapter can use to ensure that wemaintain our brand recognition.In addition, we are developing a set ofspeaking engagements, advertisingopportunities, and meetings designed tohelp chapters make their marks locally.

Chapter CouncilWith membership growing so quickly, theorganization has two major needs: Helpmembers establish new chapters andprovide consistency across those chapters.With that in mind, our Vice President ofChapters has created the Chapter Council.The chapter council is tasked with twomajor assignments. The first is to create a


The IIBA held its third Annual GeneralMeeting on Wednesday,July 12, 2006. If youwere unable to attend,here’s what youmissed…

U P DAT E

2006 IIBA Annual General MeetingBY CAROL LAPP, PRESIDENT

I IBA CHAPTER COUNCIL

What have we done & where are we going?

March 2004 March 2005 Dec 2005 July 2006 Dec Forecast

Members 37 181 1091 2,300 5,000

Chapters 1 21 42 45

Countries 2 3 18 36 40

standardized set of policies and guidelines sothat all chapters maintain the same standardsof quality. The second is to act as a liaisonamong the individual chapters and betweenthe chapters and the Executive Board. TheCouncil will also share information andprovide answers to questions.

With members spread across 36countries, on five continents, the necessityof a consistent channel of communicationsis clear. The Chapter Council provides eachchapter with a contact to assist with theinformation and guidance to ensure thechapter’s success.

Now What?In 2006, we will participate in sevenconferences, six for Business Analyst Worldand one for the World Congress for

Business Analysts. At the World Congress,in November, we will be presenting version2.0 of the Body of Knowledge, the versionthat will be used as the basis for the initialoffering of the Certification Exam.We have just become incorporated inCanada, and will continue to pursueactivities to ensure that all our chapters arecompliant with the guidelines and policiesto support the organization.

We will be implementing a newwebsite, one that will provide additionalfunctionality and consistency, whileaffording the chapters greater control overtheir sections of the site.

We will be formalizing our AdvisoryBoards, which will include respected namesin the business analysis community.

We will be aligning with other key

organizations in the business sector, such as PMI.

We will continue to grow ourmembership and chapters and align themwith the international organization. Inaddition, we will continue to push forrecognition in the international communitywith members and chapters in additionalcountries around the world.

How Can I Help?Are you a Business Analysis Professional?Are you a member of the IIBA? Would youlike to join or start a local chapter? Start atthe IIBA website (www.iiba.com) to learnmore about the organization and find outwhat we can do to support each other. �You may contact Carol [email protected]


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 appointedpersonnel to ensure that we meet our goals. For the near future, all of these positions remain volunteer staff, with the possible exceptionof office staff and website maintenance personnel.

Kathleen BarretPresident

Wayne McAlpineCIO

Louis MolnarExecutive VP

MembershipServices

Body ofKnowledge

Cleve PillifantRole Definition

Jacqueline YoungSpecial Events

Indy MitraGovernance

Glenn BruleInt’l Development

Sponsorship BOK ReviewEndorsed Educ

Providers

Expert PanelCertificationFramework

WebMaster

Carol LappChapter Council

Kevin BrennanBABOK

Carol DeutschlanderEducation &Certification

Mary SimpkinsMarketing &

Communications

Chris BeckerSecretary

Tina JosephVP Chapters

Dean Hunter /Maria Cheung

CFO


Over many years, in the softwareindustry, people working on projects

have gathered and implementedrequirements—some with greatsuccess and others – well let’s justsay – with less than stellarresults. Requirements havebeen misunderstood,misplaced, poorlydefined, incorrectlycommunicated, and sadly lost in translation.Unfortunately according to recent statistics, eventhough we have made greatstrides in developing software, eliciting theright requirements is still problematic andrequirements tasks often get overlooked orshort-changed. Some companies still thinkthat unless there is coding going on, theproject has been stalled. Really smartorganizations are beginning to recognizethat skilled Business Analysts, who knowhow to elicit and organize the rightrequirements in an acceptable timeframe,are now much more in demand thanprogrammers! Additionally, there areseveral best practices that can helporganizations and their BAs move towarddefining excellent requirements:

1) Adopt a standard requirementstemplate. A consistent requirementstemplate will help all project membersand customers know what to expect intechniques and documentation whenthey have to review a requirementspackage. Every project is unique and how

much needs to be documented will varysomewhat from project to project, butusing a standard template to house the

complex and simple requirementswill really help manage

expectations fromproject stakeholders

who mustreview, validate,verify, andapprove therequirements.

2) Organizerequirementsusing standardrequirementscategories. For example,business requirements, functionalrequirements, quality of servicerequirements, and technicalrequirements. Organizing requirementsin different categories, such as these,makes reviewing requirements easier,allows more flexibility in definingsolution alternatives, creates neededreusable documentation, and makestraceability of requirements simpler.Keep in mind, not every businessrequirement requires a software solution!You may trace certain businessrequirements to an improved,streamlined process, or an organizationalchange.

3) Model requirements using differenttechniques to capture different views,

dimensions, and levels of detail. Themore complex the project, the more avariety of techniques should be used tomake sure that critical requirementcomponents are not missed. Smallerprojects or projects where requirementsare very clearly understood by everyonerequire less modeling.

4) Trace all requirements beginning withthe initial project purpose, objectives,and scope. Each business requirementshould support the project purpose andbusiness objectives. Each functionalrequirement should originate from abusiness requirement. Each technicalrequirement should support thefunctional requirements, etc. Eachquality of service requirement shouldsupport the business environment andthe customer expectations in terms ofsecurity, performance, maintainability,flexibility, portability, reliability, etc.

5)Allow BAs enough time to truly elicitexcellent requirements. It takes timefor a BA to investigate and elicitexcellent requirements. BAs need tounderstand the project time, scope, and cost constraints to estimate theappropriate time commitment needed to define requirements. You can paynow or later in rework for missedrequirements when costs increaseexponentially if requirements tasks areshort-changed.

6) Staff projects with trained andexperienced BAs. These are critical teammembers, especially for projects that willneed an IT solution. �

lost in translation In Search of the Right RequirementsBY ANGIE PERRIS, PMP,

�

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

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

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

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

Upcoming Business Analyst and Related Events

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


In most projects, some needs/constraintsexist that must be incorporated into the

software solution, about which the clientisn’t likely to ask or be aware. If you’ve everbeen part of a large or complex softwaredevelopment project, you may havestruggled with these types of requirements.Where should they be stored? Should theybe shared with the client? And, wouldn’t itbe great if these requirements couldmagically make their way into the solutionbuild?

If you answered yes to thislast question, you may bewrestling with what hascommonly been calledsupplemental requirements.When building a softwaresolution, a Business Analystwill elicit requirements from aclient – either from clientsoutside of your company orfrom other groups within yourcompany. In many cases thesolution will also be affected by requirements that originatefrom sources other than the client. Often thesesupplemental requirements are overlooked because they are not explicitly stated by the client.

What is a Supplemental

Requirement?

A supplemental requirement is arequirement that doesn’t directly support aparticular function, but that the softwaresolution must nevertheless meet. In otherwords, even if these requirements areinitially hidden to your client, they arenecessary for the solution or business.Version 1.6 of the IIBA Business AnalysisBody of Knowledge (BABOKTM) refers tothese as Quality of Service Requirementsdefined as requirements that captureconditions that do not directly relate to the

behavior or functionality of the solution.See box for examples.

How do I recognize a supplementalrequirement? You may want to ask yourselfthe following questions: • Is it a requirement that must be part of

the solution, but the client isn’t likely toask for?

• Does this requirement need to bedocumented and traced throughout theproject?

• Should thisrequirement be communicated to yourclient for approval?

How should Supplemental

Requirements be stored?

Often supplemental requirements will bereusable across different projects. Forexample, security requirements at yourcompany or industry are likely to besimilar no matter what the project’scontext. Consider convening a group of

subject matter experts to write these typesof supplemental requirements. If you use arequirements management tool, you shouldadd these reusable, supplementalrequirements to your project template sothey will be pre-populated with thecreation of each new project. If you don’tuse a requirements management tool,create a master document that includes allof these supplemental requirements andstore it somewhere that is accessible by

your Business Analyst community.For companies or projects with

a lot of supplemental requirements,designate an owner to maintainand update these requirements atcertain intervals. If your company’ssecurity team updates its policieson a quarterly basis, then makesure a security representativeupdates the supplemental securityrequirements appropriately.

Should the client approve

Supplemental

Requirements?

In most cases, yourrequirementselicitation process

will create adocument that is

sometimes referred to asa Software Requirements

Specification (SRS). Thisdocument acts as a contract

between the group building thesolution and the client.

Supplemental requirements should behandled as any other sort of requirement ishandled. They should be included in theSRS and should go through the sameapproval or sign-off process as all otherrequirements.

If you can gather, store, communicate,and manage these supplementalrequirements, your solution will no doubtprofit from it. �

S P O T L I G H T O NSupplemental RequirementsBY BARBARA STROOPE, BUSINESS ANALYST, ACXIOM

Supplemental Requirement Examples

• Audits

• Globalization and localization

• Legal or regulatory issues

• Hardware and software interfaces

• Project glossaries

• Operational

• Performance requirements

• Privacy requirements

• Quality requirements

• Failure and disaster recovery

• Maintainability

• Scalability

• Safety

• Security

• Training


Over the last few decades, the businessconsulting and software development

communities have developed a bewilderingarray of different business analysistechniques to understand and describeprocesses, policies, and systems. As apractical matter, a Business Analyst is nevergoing to have the time or need to become askilled practitioner of all of thesetechniques.

While you can leave the techniquesyou’ll study up to the discretion of theorganization for which you work, how willyou know if your skills are portable? Howcan you be sure that you’ve masteredenough techniques to handle newsituations that might arise? Fortunately, aBA can usually manage with only a smallset of carefully chosen techniques, as longas he or she picks the right set ofcomplementary analysis methods.

Figuring out which techniques to learncan be tricky. However, most methodsaspire to provide coverage for a completeapplication development lifecycle, but theymay not address things that fall outside theapproach envisioned by the method’screators. Other resources, like the Guide tothe Business Analysis Body of Knowledge(BABOKTM) are comprehensive but notprescriptive, as they are forced to bemethodology-neutral.

Enterprise Architecture

An enterprise architecture isintended to provide guidance toan organization as to what sortsof processes are needed tosupport ongoing systemsdevelopment and changeimprovement efforts. Anenterprise architectureframework will help anorganization address everythingfrom strategic planning toapplication maintenance andoperational support. Bydefinition, then, everything aBA does should fit into theenterprise architecture adoptedby an organization. If you

know enough different analysis techniquesto cover the breadth of an enterpriseframework, you know enough to addressalmost any conceivable situation or projectthat might arise.

The Zachman framework(www.zifa.com) is one of several models forthe development of an enterprisearchitecture. It focuses on documentingdifferent perspectives of an organization,which makes it easy to show which analysistechniques can be used to describe specificcells in the framework. However, if youwork in an organization that has adopted adifferent architecture framework, thelessons should still apply.

The Zachman framework takes the sixclassical questions (who, what, where, why,when, and how) and describes the modelsrequired to answer those questions in thecontext of a particular organization. Forexample, the question “how?” translates to“how does this organization do things?”

The framework then defines six differentlevels of abstraction for the answers to eachquestion. At the top level, we define theoverall scope of the business—whatprocesses, people, and events exist that areof interest to us. The second level, thebusiness model, looks at how all thosethings of interest relate to each other and

interact with one another. Below that there’sa system model, which describes in detailwhat each of those things are. Thiscontinues down until we have the actualapplications, data, and so forth.

Not all of the levels of the Zachmanframework are relevant to a person in thebusiness analysis role. When we look at thescope of the BABOK, we find that BAsgenerally work down as far as the systemmodel but will in some cases go a littledeeper. Figure 1 is adapted from theZachman framework and shows how itmaps to the range of activities found in theBABOK.

The Questions

If you bother to count, you’ll see that theBA has a role to play in filling in 21 of 36cells in the framework. That sounds like alot, I know. However, it doesn’t require 21different techniques to describe all thosemodels. In practice, you should need tomaster no more than six or seven—one forevery column in the framework. That’sbecause most analysis techniques areintended to operate at multiple levels ofabstraction, and also because manytechniques cover the same columns.

Data models focus on describing whatthe business knows about things of interest

The Business Analyst’s ToolboxBY KEVIN BRENNAN, SENIOR CONSULTANT, b lue sands inc. , V ICE PRESIDENT BABOK TM

Entity Process List Locations of theEnterprise

List ofOrganizations /

Divisions

Major BusinessEvents or Cycles

Business Strategy

Entity /Relationship

Overall ProcessModel

Interactionsbetweenlocations

OrganizationChart, List of

Roles

DetailedSchedule

Business PlanProject

Objectives

Logical DataModel

Detailed ProcessDescription

DetailedInteraction

Model

Business RuleModel

User InterfaceDesign and Flow

Business RuleSpecification

Detailed UI,Security

Business RuleDesign

Entity History,Processing

Scope

(Lvl.1)

Data

(What)

Functio

n

(How

)

Netw

ork

(Where

)

People

(Who)

Tim

e

(Where

)

Motiva

tion

(Why)

Business Model

(Lvl.2)

System Model

(Lvl.3)

Technology Model

(Lvl.4)

Detailed

Representation (Lvl.5)

Functioning

Enterprise (Lvl.6)

FIGURE 1: General Scope of Business Analysis Activities in the Zachman Framework

Gray cells indicate cells that fall outside of the scope of the BA role.


and the relationships that those things haveto one another.

Function models describe how thebusiness gets things done and how thebusiness works to achieve its goals. Afunction model will generally involvemultiple people over a period of time—work that can be done by a single personin a single sitting is covered by peoplemodels.

Network models describe where theenterprise does work and how workperformed at different locations isintegrated. Of all of the columns, this oneis probably the least important to thetypical BA—as the name suggests, thepeople in IT who it concerns most are thenetwork support personnel.

People models tell you who is ofconcern to the solution. In many cases, thismodel is nothing more than a stakeholderdefinition, but for commercial products, itmay include things like a marketsegmentation. At lower levels, peoplemodels describe how stakeholders interactwith a solution to accomplish theirpersonal goals and responsibilities throughthe user interface.

Time models describe when eventshappen and when events can happen. Atime model does not cover sequencing(that’s a function model) but ratherexpresses regular cycles that the businesshas to go through (like tax filing) or eventsthat require a response.

Motivation models describe how thebusiness makes decisions and why thosedecisions are made. A policy modeldescribes who may make a decision, theinformation that they use to make thatdecision, and the rules that guide them inmaking that decision.

Model Coverage

Figure 2 shows which requirements typecan be expressed by which common (and acouple of less common) business analysistechniques. Obviously, these techniqueshave strengths and weaknesses that will notbe obvious from just looking at the chartbelow—but it will tell you what a

technique can be used to do.So how does this help a BA figure out

which techniques to master? You should beable to use at least one primary techniquefor each column in the Zachmanframework, and consider learningsecondary techniques as and whererequired. You may find that text ormatrices will suffice for describing somerequirements (for instance, motivationrequirements, especially the higher levelones, are often described in a Business Caseor Vision document).

The particular techniques you choose tolearn will depend on the business domainyou work in, the methodologies chosen byyour enterprise, and other matters. Notevery project requires that you be able tocompletely describe all possible kinds ofrequirements. On the other hand, if youwork intensively in a particular cell of the

framework, you may want to be familiarwith more than one technique that appliesto it for use with different audiences or toresolve different issues.

When the time comes to handle a newproblem, though, you should have thetools you need to figure out whethersomething you already know how to dowill help you solve it—or whether it’sgoing to be necessary to learn somethingnew. �

Kevin Brennan is a Senior Consultant withblue sands inc. and serves as the IIBA’s Vice-President of the BABOK. He has ten years ofexperience as a BA in multiple industries,including mortgage banking, courier services,auto manufacturing, energy retailing, andregulatory bodies. You may reach him [email protected].

FIGURE 2: Specific Analysis Techniques and the Zachman Framework

Technique Data Function Network Time People Motivation

Activity Diagram 2,3 • 3

Business Process/ • 1,2,3 3 •Workflow Diagram

Business Rules • • 3,4,5

Class Model 1,2,3

CRUD Matrix • 5 4,5

Data Dictionary 3

Data Flow Diagram • 1,2,3 • • •

Data Transformation •

and Mapping

Deployment Diagram 1,2

Entity Relationship 1,2,3 •

Diagrams

Event Identification • 1,2 •

Flowchart 2,3 3,4 •

i*/Goal Oriented • 1,2,3Requirements Language

Metadata Definition • • •

Sequence Diagram • 3 5

State Machine Diagram • 1,2,3 •

Storyboards/ Screen Flows 3,4,5

Use Cases 1,2,3 • 2,3,4 •

User Interface Designs 3,4,5

User Profiles 1,2 •

User Stories • • •

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


One of the most frequent comments we hear from organizationsis that they want a consistent way to document requirements.

Since this issue of the bridge is dedicated to the discussion ofrequirements, we feel it is appropriate to share with you one resourcethat we have available on our website for your requirementsdocumentation. B2T Training developed a Requirements Packagetemplate which is currently being used by many companies andBusiness Analysts. Regardless of the methodology you are using foranalysis and design, the templates provide an outline fordocumenting all of the requirements for your project.

The Requirements Package template is a MS Word® documentthat provides sections for textual descriptions and tables to fully detailthe core requirement components. We also recommend insertingdiagrams or referring to them inside the document as a visualrepresentation of the requirements. The following graphic representsthe categories included in the Requirements Package.

The templates may be used as interviewing tools while elicitingrequirements and as a documentation format for the requirementsdetails. Templates provide an easier way for subject matter experts toreview requirements versus reading a long detailed textual document.They also eliminate the need for the developer to pull out therelevant information necessary to make any technological changes orenhancements required. Sample templates for documenting the corebusiness components are presented at right.

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

did you know? Requirements Package Templates

ESSENTIAL PROCESS DETAILS


ENTITY

RELATIONSHIPS (DATA RELATED BUSINESS RULES)

SYSTEM USE CASE DESCRIPTION

Submit an article to the bridge!The bridge is published twice a yearand focuses on a particular area ofinterest within business analysis.Articles relevant to the topic area arepreferred; however, any articles aboutbest practices, project success stories,BA resources (books or tools) will alsobe considered. Submission deadlinesfor 2007 spring and fall issues areFebruary 5, and July 9, 2007. To submitan article send an email [email protected].

New Certified Business AnalystsWe are pleased to highlight the latestindividuals who have earned the title ofCertified Business Analyst since the lastissue of the bridge. To date, we havemore than 2,800 people in our program,with over 175 who have completed andreceived certification. We have anadditional 350 candidates that havepassed three proficiency exams and arein the final stage of the process. B2TTraining Certified Business Analystshave demonstrated knowledge andapplication of business analysis and wecongratulate them on their success.

Dawn AberbachChris BeckTerry ChesneyTaryn DraneDianna HoustonPam JusticePatricia A. KlineLois V. KoczonShirl LevanduskyBill LiswellMelissa MarseeLana K. McCainEdward S. MeglisSusan ParsleyBridget SchmollingSandi SpillnerMichelle Nicole ThomasonLisa TuckerDonna WestJack WidmanCarrie (Kairui) Yi


Question: I am a Business Analyst in anIT organization and often my project startsafter there is a proposed IT solution. Howshould I proceed to ensure that software is theright solution? Answer: This is a very common scenario.Many BAs are not brought into projectsuntil a decision is made that a softwaresolution is needed to address the customer’sneeds. This situation is likely to continue.An excellent BA needs to make the effort to understand the business and theenvironment to make sure the proposedsolution is the best/right solution. Forexample, assume a business sponsor cameto your team and said he needs a websitecreated to help grow market share. The BAshould not just run out and begingathering detailed functional requirements

for a website. Rather, the BA should takesome time up front to validate theproposed solution. This is accomplished byeliciting and analyzing the detailed businessrequirements. The BA should ensure thecustomer identifies why he needs thewebsite and what business activity will beaccomplished on the website. Is thatbusiness activity done today? Is it beingdone well? What impact will the websiteactivity have on the rest of theorganization, etc?

I am not saying that all successfulprojects require detailed businessrequirements to be elicited, analyzed, anddocumented, but when they are accuratelyelicited and analyzed there is a higherprobability that the solution will meet thebusiness need. I have been involved in

software implementation projects where theteam delivered a solution meeting thedetailed functional requirements. Then,once in production, the system was notused, primarily because the solution didnot meet the business requirements, whichwere not analyzed in detail.

In conclusion, the IT BA may not be theinitial person eliciting and documentingdetailed requirements. The customer mayfeel he or she has already gathered anddocumented the requirements. To increasethe probability of meeting the true customerneed, the BA should ensure detailedbusiness requirements are elicited, agreedupon, and analyzed before determining asolution. �Send your questions to Ask the Experts [email protected].

ask the experts Is the Proposed Solution the Right Solution?

book reviewMore about Software Requirementsby Karl E. WiegersREVIEWED BY BARBARA A. CARKENORD, PRESIDENT, B2T TRAINING,

Karl Wiegers has followed up his verysuccessful book Software Requirements

with a new book called More AboutSoftware Requirementssubtitled Thorny Issues andPractical Advice. Wiegers’first book has becomealmost a required part ofevery Business Analyst’slibrary. I anxiously doveinto his new book hopingto find the same kind ofhelpful reference material.While Wiegers does agood job of describing thethorny issues that BusinessAnalysts face, his practical advice is notspecific and basically states that the BAmust use his or her judgment on theseissues. I do agree and I think this justdemonstrates that to be a successful BA, alot of practical experience is required andthe answers to many of the questions we

face cannot be found in a book. I also agree with Wiegers’ definition of

the word “requirement” referring to the“many kinds of informationthat fit into this big pot of soup we call ‘therequirements’.” He includesall of the various types andlevels of requirementsrepresented in a variety ofways (see the main article inthis issue of the bridge for adiscussion about the word“requirement”).

There are many goodsuggestions in the book,

reinforcing his first book and refining someof the material originally presented.Wiegers presents some great researchstatistics that may help BAs justify howmuch of a project’s time should be spenton requirements and what the payoff willbe for the project. He also does a great job

of showing how a BA is really a key playerin a successful project.

As with the first book, this book focuseson software requirements, only brieflymentioning business requirements. BAsneed to be aware that software may or maynot be the correct solution for everyproduct. I think that this book will bemost helpful to mid-level BAs who arebeginning to understand the subtle issuesthey face in deciding how to elicit anddocument requirements. �

Barbara A. Carkenord is the President ofB2T Training. She has worked in therequirements gathering and documentationfield for over 20 years and has conductedhundreds of seminars for Business Analysts.Comments are welcome [email protected].

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 BusinessAnalysis Body of Knowledge (BABOK) and will help prepare you for both the B2T TrainingCertification and the IIBA Certification when it is available. The BABOK is a collection of businessanalysis tasks categorized into like groupings called knowledge areas. The BABOK is not amethodology and does not infer any particular order of performing the activities. B2T Training’sprogram is taught in a series of courses that reflect the order of work and iterative nature of businessanalysis. The graphic below illustrates the alignment between the BABOK and B2T Training courses.

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 andguidelines.

Please review the comparison information above and if you have any questions please contact

us at [email protected].

EnterpriseAnalysis

Requirements Planning & Management

RequirementsElicitation

RequirementsAnalysis &

Documentation

RequirementsCommunications

Solution Assessment

and Validation

Fundamentals

B2T Training Core Course Alignment

Business Analysis Body of Knowledge

Essential Skills for theBusiness Analyst

Detailing Business DataRequirements

Detailing Process andBusiness Rule Requirements

Additional B2T Training Course Alignment

Advanced Business Analysis Techniques

Facilitating Requirementsfor Business Analysis

Requirements Testing for the Business Analyst


�

Recently we launched a new blog on theB2T Training website. The Business

Analyst Blog is an online resource forBusiness Analysts. It contains fresh thoughts,brief articles, business analysis tips, andindustry updates written by B2T TrainingBusiness Analyst experts.

Each week a new topic is posted by aB2T Training business analysis expert andreaders are encouraged to participate bysharing their thoughts and experiences.Topics covered in the blog include businessanalysis tips, articles, and industry updates.The blog serves as a springboard for BusinessAnalysts to share ideas and learn from eachother and is a great resource and reference tohelp keep you focused and up-to-date on thelatest trends and industry best practices.

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!

• Should the same requirement bepresented in different ways for differentstakeholders? Ideally the answer to thisquestion is no. BAs have enough work todo as it is, we don’t want to be re-packaging the same information multipleways. However, a BA’s most importantjob is to clearly communicate with ourstakeholders (Did I already say that?Well, we can’t say it enough!) If arequirement is clear to one stakeholderin a graphical format and clear toanother stakeholder in a sentence, thenwe may have to present multipleversions. If this is necessary (and I wouldmake sure that it is absolutely necessary),then make sure you keep both versionsup to date when there are changes.

• Which requirements are reusable? Manyrequirements are re-usable on futureprojects and it may be helpful todocument them together. This is anotherarea where a requirements managementtool is very helpful.

Conclusions

1. I hope that we can open our minds toconsider broader definitions of the wordrequirement. We may not agree, but weneed to be aware that there is not justone definitive understanding of the wordrequirement and quality communicationcan only take place when weacknowledge these differences.

2. Regardless of how you categorize andpresent requirements you must let yourreviewers know where to find things. Atable of contents for a requirementspackage is absolutely essential.

3. If your organization does not have aconsistent categorization schema –implement one. Create one, try it, andrevise as you learn, any system is betterthan none. Most projects have a largeenough number of requirements tojustify categorizing them into groups.These groupings make the requirementseasier to document, double check, andreview. I recommend business,functional, technical, and quality ofservice (also referred to as supplementalrequirements, see article on page 10), asgood solid categories for a starting point.

4. Tools for categorizing and presentingrequirements will make BAs much moreproductive and we should continueworking with tool vendors to help themunderstand the complexity ofcategorizing requirements. �

New Business Analyst Blog


(Requirements, continued from page 5)


certified core courses

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

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

Detailing Business Data RequirementsUnderstanding and documenting business data requirements is a critical componentin defining complete requirements. Every process uses data and almost all businessrules are enforced by data. Missing a critical piece of data or incorrectly defining adata element contributes to the majority of maintenance problems and results insystems that do not reflect the business needs. This course teaches students an in-depth approach to identify and define all necessary data components using bothtextual templates and an entity relationship diagram.

Detailing Process and Business Rule RequirementsThis course continues the development of the requirements package by defining theprocesses and business rules for the project. Business Analysts are expected toanalyze and understand business problems and be able to make recommendationsto help the business stakeholders solve problems. The most effective approach toensure success is to understand the business environment and document thebusiness requirements, and then use functional requirements to document howsoftware automation can support the business.

Functional requirements document how the software should “behave.” Theserequirements must specify how users will interact with the software and how thesoftware will respond. Business Analysts are uniquely qualified to document theserequirements because of their understanding of the business needs and the user'swork environment. These requirements will be used to articulate the technologyneeds of a quality software application that will meet the business needs.

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

4 Days

3 Days

4 Days

��

�

�


� ��

�

��

��

��

��

�

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.


• 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.


• 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.


additional business analysts courses

Facilitating Requirements for Business Analysis This course teaches students to plan and conduct a facilitated session to gatherbusiness and functional requirements. The art of bringing people together to elicitrequirements 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 arequirements elicitation session for one project deliverable and to play each of the keyroles in at least one session. This class is limited to 8 students and over 60% of theclass time is spent on interactive, real-world business case study facilitated sessions.

Requirements Testing for the Business AnalystThis course provides an excellent foundation for Business Analysts to achieve bestpractices in software quality assurance (SQA). The course will improve the BusinessAnalyst’s development of requirements so that they can be used to build quality testcases. It will also enable the Business Analyst to create specific test cases from therequirements. The course includes a workshop case study that provides a cohesivelearning experience.

Advanced Business Analysis TechniquesThis course enhances the efficiency and effectiveness of Business Analysts by givingthem additional techniques and strategies for gathering, documenting, and reviewingrequirements. Techniques such as advanced data definition, traceability, and gap analysishelp Business Analysts document more accurate and complete requirements. The coursealso presents the concept of requirements management and requirements reuse.Implementing a requirements management process into your organization cansignificantly reduce the time required to make software changes and develop softwareinterfaces.


3 Days

3 Days

3 Days

�


management/technical seminars

Overview of Business AnalysisThis seminar presents the Business Analyst role to managers and others who lead andwork with Business Analysts. In order for the Business Analyst to be successful, both theIT and business community must embrace the business analysis process. The seminarcan be used as a working session to discuss how your organization will implement thebusiness analysis process and approaches for documenting the requirements.

Developer’s Introduction to Business Analysis This class provides an overview of the Business Analyst role and a detailed review ofthe requirements document provided to the development team. To ensure an integratedteam, IT developers need to understand the role of the Business Analyst. They shouldalso be familiar with the requirements that Business Analysts are gathering anddocumenting. This includes understanding categories of requirements, the corerequirement components, and the documentation formats used for each type ofrequirement. IT team members must also understand the testing life cycle and thepersonnel involved. This course gives students an overview of the role of the BusinessAnalyst, requirements documentation, and software testing.


4 Hour Seminar

1 Day

�

Essential Skills for the Business Analyst

$1,980/per student

• Oct 2 – Oct 5, 2006 Chicago, IL

• Oct 16 – Oct 19, 2006 Houston, TX

• Nov 6 – Nov 9, 2006 Dallas, TX

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

• Dec 4 – Dec 7, 2006 Seattle, WA

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

• Jan 29 – Feb 1, 2007 Atlanta, GA

• Feb 5 – 8, 2007 Dallas, TX

• Feb 26 – Mar 1, 2007 Louisville, KY

• Mar 5 – Mar 8, 2007 Chicago, IL

• Mar 19 – Mar 22, 2007 Seattle, WA

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

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

• May 21 – May 24, 2007 Atlanta, GA

• Aug 20 – Aug 23, 2007 Atlanta, GA

• Sep 17 – Sep 20, 2007 Chicago, IL

• Oct 15 – 18, 2007 Dallas, TX

• Nov 5 – Nov 8, 2007 Atlanta, GA

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

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

• Dec 10 – Dec 13, 2007 Louisville, KY

Detailing Business Data Requirements -

$1,485/per student


• Nov 14 – Nov 16, 2006 Houston, TX

• Apr 30 – May 2, 2007 Atlanta, GA

• Apr 30 – May 2, 2007 Dallas, TX

• May 7 – May 9, 2007 Chicago, IL

• May 21 – May 23, 2007 Louisville, KY

• Jun 4 – Jun 6, 2007 Seattle, WA

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

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

• Oct 15 – Oct 17, 2007 Atlanta, GA

Detailing Process and Business Rule

Requirements - $1,980/per student

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

• Oct 2 – Oct 5, 2006 Atlanta, GA

• Nov 6 – Nov 9, 2006 Seattle, WA

• Nov 13 – Nov 16, 2006 Louisville, KY

• Dec 4 – Dec 7, 2006 Chicago, IL

• Dec 11 – Dec 14, 2006 Houston, TX

• Jul 16 – Jul 19, 2007 Atlanta, GA

• 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

• Oct 15 – Oct 18, 2007 Seattle, WA

• Nov 5 – Nov 8, 2007 San Diego, CA


Facilitating Requirements for

Business Analysis - $1,485 per student


• Apr 23 – Apr 25, 2007 Atlanta, GA

Requirements Testing for the

Business Analyst - $1,485 per student

• Dec 11 – Dec 13, 2006 Louisville, KY

Advanced Business Analysis Techniques

$1,485 per student

• Oct 16 – Oct 18, 2006 Louisville, KY


2006-07 public class schedule

Please check our website foradditional public class offeringsand to check availability andregister – www.b2ttraining.com.On-site classes are also available.

Call 866.675.2125 or email us [email protected].

B2T Training11675 Rainwater Drive, Suite 325Alpharetta, GA 30004

Prsrt StdU.S. Postage

PAIDPermit #309

Knoxville, TN

categorizing and presenting requirements · business analysis body of knowledge (babok™) we chose...

Documents