The Bridge - Summer 2005

online ordering

Get Order Status

Place Order

Cancel Order

Return Product

UML for theBusiness Analyst

Changing theBusiness AnalysisEnvironment

Book ReviewApplying UML and Patterns

Business AnalystIndustry SurveyResults

the CONNECTING BUSINESS REQUIREMENTS TO TECHNOLOGY

Summer 2005

DemystifyingBusiness Use Cases

New Course

letter from the editors

In this issue of the bridge we are highlighting UML (the Unified Modeling Language) and its usefulness toBusiness Analysts. Plenty of software development organizations are using UML and Object Oriented

techniques to design and develop software. An effective Business Analyst must be able to “talk” with the

developers in this language. In some organizations this means that Business Analysts will be expected to createUML diagrams and deliverables; in other organizations, the BA will just be expected to be aware of the concepts.And for Business Analysts working in organizations that are not using UML, staying on top of this development

process is necessary for your personal career development.

To help introduce some of the UML topics we have included an article about Business Use Cases. UML wasoriginally designed for software development but many analysts are using the same concepts to do Business

Modeling. The article on pages 3-5 reminds us that regardless of what techniques are used, the critical job of aBusiness Analyst is to understand the business needs and communicate them accurately.

We conducted an online survey during April asking you about your role as a Business Analyst. The highlights ofthe survey results are shown on page 7. We believe this is the first survey of Business Analysts ever conductedand although the number of respondents was small (270), it gives us a baseline on which to measure futuregrowth of the industry.

Also included in this issue is an article by one of our Certified Business Analysts! Diane Talbot describes how her

organization’s environment is changing to embrace business requirements and the role of the Business Analyst.

Between issues of the bridge we invite you to visit our website, www.b2ttraining.com, frequently for currentarticles and events relevant to the Business Analyst community. These can be found on our BA Resources page.Our certification program continues to be strong with over 100 people certified!

We look forward to seeing you at upcoming events. This year there are three conferences planned exclusively forBusiness Analysts! This is a great indicator of our industry’s growth because only two years ago, we didn’t haveany conferences to attend. See the ads for the conferences in the magazine. Please continue to let us know ofareas of interest for future issues of the bridge. We continue to be excited by the enthusiasm of Business Analystsworking to make their organizations more successful.

TINA JOSEPH BARBARA CARKENORD

Certified Woman OwnedSmall Business

t a b l e o f c o n t e n t sDemystifying Business Use Cases

Changing the Business Analysis Environment

Business Analyst Industry Survey Results

Business Analyst Certification Program

UML Brain Teaser

Ask the ExpertsUML Diagrams

Book ReviewApplying UML and Patternsby Greg Larmen

Lost in TranslationUML Conceptual Class Diagrams are Not Just Fancy ERDs!

B2T Training New CourseUML for the Business Analyst

B2T Training Core Courses

B2T Training Additional Course Offerings

B2T Training • 11795 Northfall Lane, Suite 601 • Alpharetta, GA 30004 • 865-675-2125

B2T Training is a woman-owned small business based in Atlanta, GA. Our training focuses on proven skillsand techniques to define and scope the business problem, gather requirements, document the requirements,model the requirements, and follow through with the development of business requirements test plans toensure 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.

Vice President, Sales and MarketingTina Joseph

©2005 B2T Training. All rights reserved.

theSummer 2005

3

6

7

8

9

10

10

11

13

15

17

the bridge l Summer 2005 2

Business

Worker Add a member

Membership Processing System

Member

Services Rep

Vice President, TrainingBarbara A. Carkenord

Director of Business DevelopmentAngie Perris

volume 2 l issue 1

Page 10

Page 7

64%

64%

27%

2%2%2%3%

Business Analyst

System Analyst

Programmer/Analyst

Consultant

Product Manager

Various Titles/Others

PRIMARY JOB TITLE FOR BUSINESS ANALYSTS

27%

2%2%2%

3%

Business Analyst

System Analyst

Programmer/Analyst

Consultant

Product Manager



66%

12%

3%9%10%

IIBA

PMI

Six Sigma

None

Other

ARE YOU INVOLVED IN ANY INDUSTRY ORGANIZATIONS?

WHAT ARE THE PRIMARY ROLES PERFORMED BY THE BUSINESS ANALYSTS IN YOUR ORGANIZATION?

0 20 40 60 80 100

Scoping the Project 66%

Gathering Data Requirements 84%

Document Use Case Requirements 62%

Document Process Workflows 75%

Gathering Buisness Rules 76%

Process Reengineering 35%

Facilitating Information Gathering Sessions 69%

Screen Design 43%

Writing System Specifications 41%

Cost Benefit Analysis 33%

Requirements Management 65%

Project Management 45%

User Acceptance Testing 56%

Other 6%

Anew requirements techniquecalled the Business Use Case isbeing discussed in the softwaredevelopment industry. This

artifact or deliverable is developed duringthe Business Modeling or RequirementsGathering phase of project life cycles. Weknow the phrase Use Case from the objectoriented/UML (Unified ModelingLanguage) development approaches whereUse Cases are goals of the software. So byputting the word “business” in front ofthem it sounds like we are talking aboutgoals of the business. What a great concept– using a well established technique for anew type of work. But really understandingand creating these Business Use Cases hasturned out to be harder than it looks. Thisarticle will attempt to explain the history ofthese new artifacts and “de-mystify” themfor Business Analysts.

OO/UML methodologies addresssoftware development, they were notcreated with business modeling in mind.These approaches assume that a decisionhas already been made that software is thesolution to the business problem. Theyassume that a “Business Model” has alreadybeen created and is available for all softwaredevelopment projects. The existence of thisBusiness Model implies that we alreadycompletely understand the businessprocesses and the business objectives.

Unfortunately, most organizations don’thave the time to build a Business Model ordocument any business requirements until aproject has been approved. Often a solutionhas been proposed before the problem isfully understood. Experienced analysts keepan open mind about possible solutionswhile they are gathering requirements andtry to develop a Business Model beforedocumenting functional requirements. TheBusiness Use Case Model is a technique fordocumenting this Business Model (business

requirements) as the first step in thesoftware development process.

Background/HistoryThere is a long and successful history ofanalysts borrowing techniques from softwaredevelopers. In the 1970s Ed Yourdondeveloped the data flow diagram as a toolfor designing software systems. Programswere represented as “bubbles” and arrowsshowed how data and parameters were sentfrom program to program. Data flowdiagrams were quickly adopted by manydevelopers because they presented a clearpicture of how the software componentsshould be built to work together.

About a decade later, when businessrequirements were recognized as animportant part of the softwaredevelopment process, analysts used the dataflow diagramming symbols and techniquesfor their own work. The “bubbles” becamebusiness processes and the arrows showedhow information flowed from one businessprocess to another. Business stakeholdersfound these diagrams very useful forreviewing requirements and even forbusiness process reengineering. The highestlevel dataflow is the Context Level DataFlow diagram which is commonly used forproject scoping.

The Business Use Case ModelIn the OO/UML development approaches,organizations have been using System UseCases for many years to define how thesoftware should work and communicatethis to the development team. Manybusiness people find these System Use Case descriptions easy to review. With the Business Use Case, analysts are tryingto use the same format for BusinessRequirements. With the introduction of Business Use Cases the OO/UMLapproach has taken a software design

technique and adapted it to be used forgathering, analyzing, and documentingbusiness requirements.

Advocates of Business Use Cases suggestthat this new artifact can support businessmodel development and then can easily betranslated into the software developmentSystem Use Cases to speed thedevelopment process.

As with any new tool or technique,Business Use Cases must be clearly definedand used consistently before we canevaluate their effectiveness. Unfortunately,consistent standards and guidelines forcreating Business Use Cases have not been accepted. It is necessary for BusinessAnalysts choosing to use this technique toset their own standards and guidelinesbefore they attempt to use them on theirprojects. Some suggestions for thesestandards are included below.

In OO/UML methodologies, a SystemUse Case can be represented 1) on a UseCase Diagram, 2) on a UML activitydiagram, and 3) is detailed with a Use Case Description. The collection of theseartifacts is referred to as the System UseCase Model. Most teams start with the Use Case Diagram as the high levelrequirements artifact.

Utilizing System Use Case ModelComponents in a Business UseCase ModelActors. In a System Use Case an actor(stick figure in the diagram) is defined as a resource that is outside the automationboundary and uses the software. These canbe people, other systems, or hardwaredevices. For a Business Use Case thedefinition of an actor must be expanded to be “any resource that is outside thebusiness area and uses the business”. Actorsare not under the direct control of thebusiness area being studied.

3 Summer 2005 l the bridge

DemystifyingBusiness Use Cases

BY B A R B A R A A . C A R K E N O R D, V P, T R A I N I N G , B 2 T T R A I N I N G ,

Business

Worker Add a member


Member

Services Rep

The Use Case. In traditional approachesthe Use Case (oval in the diagram) isdefined as a goal of the software,something that provides value to an actor.Again, if we look at this from a businessperspective we would define a Business UseCase as a goal of the business, somethingthat provides value to an actor.

Each Use Case is described in detailwith a Use Case Description (see chartbelow).

Associations. The lines that connectactors to Use Cases on the diagram areassociations and show how each actor isinvolved with each Use Case. Theseassociations could be used in the same wayfor Business Use Cases.

The automation boundary. Atraditional Use Case Diagram contains a large rectangle that represents theautomation boundary. Actors are shownoutside the rectangle with lines attachingthem to particular Use Cases. Thisboundary shows what is included in thesoftware functionality and shows wherepeople and other systems will interfacewith the software. In the case ofpeople, these interfaces are usuallyscreens, web pages or reports. ForBusiness Use Cases, this rectanglecould represent the business areabeing studied.

So far, all of the componentsfrom the System Use Case Modelseem to translate pretty easily andthis seems like a technique thatwill work well for BusinessRequirements. However, there aresome differences between BusinessRequirements and SoftwareRequirements that must beconsidered before we can commit

to the validity of the Business Use CaseModel.

Differences between System UseCases and Business Use CasesAs with any requirements deliverable orartifact, our first questions should be: • Why are we creating this artifact? • Who will be using the artifact? • And for what purpose will they be using it?

Business Analysts are specialists atcommunicating complexinformation to differentaudiences for differentpurposes because this is ourmain job function. When wecreate System Use Cases theanswers to the questions arepretty straightforward: we arecreating the System Use Casesto describe how we wantsoftware to work, the businessstakeholders will review themto approve the functionality,

and the developers will use them to writecode.

However, answering these questions forBusiness Use Cases is where the confusionreally becomes obvious. What we discoveris that Business Use Cases are very flexibleand may be used for any number ofpurposes. But if their purpose is unclear,they may not be developed consistentlyand may become useless!

There are at least three possible reasonsfor creating a Business Use Case Model:1. To clarify the understanding of how the

current business performs its work2. To serve as a high level starting point

for software design

3. To provide a true, essential BusinessModel, independent ofprocedural/system descriptions

These three options for usage will result inthree different Business Use Case Models.Allow me to review each option by usingan example.

The example is a Business Use CaseModel for a membership business area.

Exhibit 1. This diagram shows how thebusiness currently operates. You will noticea special type of actor here: the BusinessWorker. This is a new modeling componentthat IBM/Rational has proposed to showpeople who are working in the businessarea. In this example, the Member is anactor but only has access to the businessthrough a business worker. This diagram isuseful when the project team needs tounderstand the current business beforerecommending a possible change.

If you are documenting how work iscurrently done, Business Use Case Modelsmost closely compare to WorkflowDiagrams. The Use Case Diagram showswho does the work and the Use CaseDescriptions describe how the work isperformed. There are two main differencesbetween using Workflow analysis andBusiness Use Cases: 1) the Business UseCases can have a textual component“behind” the graphic, 2) Workflowdiagrams typically show how businessprocesses interact with each other whileBusiness Use Cases show how actorsinteract with the processes. Both toolsoffer the analyst ultimate flexibility interms of level of detail, level of formality,

ease of documentation, andability to communicate a largenumber of ideas and concepts.

Exhibit 2. This diagram showshow the business would like tooperate in the future. TheMember will be able to accessthe membership system via aweb page. Notice that Memberswill be allowed to join the clubor change their profile but willneed to continue to workthrough the business worker torequest services. This diagram


Continued on page 5

BusinessWorker

Business Use Case Model

Current “AS IS” Process

Add a member

Changememberprofile

Request ClubService


ServiceProvider

Member

Member Services Rep

BusinessWorker


New “TO BE” Software

Join the club

Changememberprofile

Request ClubService

New Membership Web Site

ServiceProvider

Member

Member Services Rep


Essential - Independent of “how”

Join the club

Changememberprofile

Request ClubService

Membership

ServiceProvider

Member

EXHIBIT 1

can be used to present recommendationsfor changes and as a scope diagram for thesoftware development project.

If you are designing softwareautomation to support your businessprocesses, Business Use Cases most closelycompare to System Use Cases. BusinessUse Cases can be detailed and turned intoSystem Use Cases during the project. Thisis probably the most common use ofBusiness Use Cases today. A starting pointfor software functionally descriptions, theyare initially very high level and often usedto scope the software features. This willprobably continue to be the bestapplication of Business Use Cases.

Exhibit 3. This diagram shows atechnology independent or essential view ofthe business. In true essential modeling wedo not show how work is done or who doesthe work. This models the business in itspurest form. This diagram allows the mostflexibility when re-engineering businessprocesses or looking for alternate

implementation options. Thisdiagram is also useful foranalyzing new business areas ornew business processes. It wouldalso be useful for modeling abrand new business area.

If you are analyzing thebusiness, independent oftechnology, the Business Use CaseDiagram most closely compares to the Context Level DataflowDiagram. In the Dataflow diagram we showExternal Agents and their interactions withthe business. The advantage of the BusinessUse Case Diagram over the Context Level

DFD is that it showsthe activities going oninside the business area,while the DFD onlyshows the outsideinteractions.

Essential BusinessUse Case descriptionsmost closely compareto Essential BusinessProcess descriptions.Essential BusinessProcesses areindependent of whoperforms them, howthey are performed,and what order inwhich they areperformed. As a matter of fact, therequirements in B2TTraining’s EssentialProcess template arethe same requirementsthat should be gatheredfor a Business UseCase!

Both offer greatflexibility for imaginingfuture alternativesolutions.

It’s all about perspective!Each of the example diagrams above couldaccurately be titled “The Business Use Case Model for the Membership System”.But notice the differences in the diagrams.All of these differences stem from theperspective from which the model is built.

In addition, Use Cases are named from

the perspective of the actor who initiatesthem, while essential business processes arenamed from the perspective of the businessarea. Understanding perspective and usingit consistently are the keys to success in anyrequirements gathering technique.

As you can see, Business Use Cases arevery flexible. And as every good analystknows, the more flexible the tool the moredifficult it is to use consistently. BusinessUse Cases are an additional tool in the BAToolkit and the Business Analyst mustcontinue to make choices about which toolis best suited to each project need.

Specific Recommendations1. Before developing a Business Use Case

Model be certain how and why it isbeing used, and set standards to ensureconsistency.

2. Clearly label all requirements artifacts.Make sure that diagram titles include theperspective. Use standard language suchas AS IS vs. TO BE, and WHAT (corebusiness process). vs. HOW(implementation).

3. Always choose the technique that is mostappropriate for your project and youraudience.

4. Whether or not you choose to develop aBusiness Use Case Model, a good practiceis to always prefix the words “Use Case”with either the word “System” or“Business.” This will avoid confusion forreviewers and other analysts. Until Business Use Cases become more

commonly accepted and industry standardsare agreed upon, this new technique willcontinue to “mystify” analysts who havenot thought through its implications. n

Sign up for B2T Training’s new UML for theBusiness Analysis course to learn to writeBusiness Use Cases.


BusinessWorker



Add a member

Changememberprofile

Request ClubService


ServiceProvider

Member

Member Services Rep

BusinessWorker



Join the club

Changememberprofile

Request ClubService


ServiceProvider

Member

Member Services Rep



Join the club

Changememberprofile

Request ClubService

Membership

ServiceProvider

Member

Perspective AS IS TO BEEssential Current business New businessbusiness activities activitiesprocesses independent of independent “WHAT” of how they of how they

are performed. will be performed.

Implementation Current business Proposed “HOW” procedures business

and software proceduresfeatures. and software

features.

BusinessWorker



Add a member

Changememberprofile

Request ClubService


ServiceProvider

Member

Member Services Rep

BusinessWorker



Join the club

Changememberprofile

Request ClubService


ServiceProvider

Member

Member Services Rep



Join the club

Changememberprofile

Request ClubService

Membership

ServiceProvider

Member

EXHIBIT 2

EXHIBIT 3

You’ve taken Business Analysis classes;you know which tool to use in which

situation. You are ready to make a positiveimpact on the way your company approachesanalysis. That, however, may be yourbiggest challenge.

In environments where no businessanalysis standard exists, convincing ProjectManagers, Development Teams and evenother Business Analysts that what you aredoing can work for everyone, is not an easytask. It is, however, a task that is worthdoing, so don’t despair. Here are some ideasto help you get started.

Understand resistance to changeIt is human nature to resist change. In workenvironments where change is constant,Project Teams evolve processes over timethat get them consistent results. Though anew process may improve the results, theestablished process has the appearance ofstability-people know what to expect.Changing their processes to adjust tosomething new introduces an unknowncomplexity to the project and Project Teamsdo not want to worry about justifying amissed deadline because the BusinessAnalyst decided to try something new.

Don’t fight this natural resistance tochange; there are ways to work with it. Bepatient and remember that the establishedprocesses were not developed over night;they cannot change over night.

Start SmallAs a Business Analyst, you have a powerfulset of tools in your tool box. Each diagram,table or analysis method is designed forspecific situations. Don’t drop the wholetool box on the table at one time. Theinformation overload will overwhelm theProject Team.

Find one tool that will work for themajority of situations at your company and use it at every opportunity. As youintroduce it, call it by name and explainthe purpose. Tell them how it will make

you more efficient and how it will help theteam communicate and understand theproject. Show them how it works.

The first time you introduce the newtool, you will be battling the factors ofchange and surprise. Prepare to spend a lotof time explaining what the tool is and whyyou believe it will be helpful. The secondtime you introduce the tool, the team willnot be surprised, but they will still notunderstand how it is helpful. Be preparedto explain it again. Repetition is the key.

When project teams begin askingquestions and requesting the results ofusing the new tool on other projects theywork on, you have successfully made asmall step toward a new Business Analysismethodology!

Give them something they needEvery company, no matter how successful,has something that could be improved.What does your company need? What tooldo you have available to fill this need?

For example, do the Project Managersneed better time estimates on the analysispart of their projects? Give it to them.Track your time spent on the project piecesyou handle for the next few projects. Overtime, you will have a pretty good estimate ofhow much time you need for each projectpiece. The next time a project comes along,go to the Project Manager with your owntime estimates for analysis, showing thetrends over the last few projects. Give theProject Manager information that facilitatesmore informed decisions and they will sit upand take notice.

Look closely at the processes in place inyour company. Where can your BusinessAnalysis tools make an impact? Find theneed and you will be on your way tostarting a change.

Build on SuccessOnce you have a small success, build on it.Find the next logical tool from your toolbox to introduce. Demonstrate how it fits

with the previous tool you introduced.Remember, this one is new, so don’t skimpon the explanations.

Then look for ways to measure theresults of your new additions when theproject is complete. Compare this projectwith previous projects without the new tool.Were there fewer open issues discussingthe scope? Did the Development Team hitthe ground running, rather than spendingtime redesigning? The project teams maybe able to say that something was differentabout the project, but may not make theconnection to the new tools you introduced.Demonstrating measurable success, projectby project, will give you the fuel needed tomake a permanent change.

Be a ModelMost importantly, you know that the toolsyou have available as a Business Analyst canmake a positive impact on the projects atyour company, but it may take a while toget others to understand. Above all, projectteams need a Business Analyst to efficientlybridge the gap between the BusinessPartners and the Development Team. Quietconfidence in your abilities, and a proventrack record of success over time, will go along way toward helping the companyunderstand the need for a Business Analysismethodology that will make every project assuccessful as your projects have been.

If the smallest step you can make is towait until other Business Analysts come toyou for guidance on making their projectsmore successful, you have made an impactthat will go a long way toward changing yourcompany’s approach to Business Analysis.

Any step in the right direction ismovement toward your goal of positivelyimproving the way your companyapproaches Business Analysis. Believe inthe Business Analysis tools you haveavailable, track your improvements overtime and look for the opportunities todemonstrate the value a Business Analystcan bring to your company. n

Changing the Business Analysis EnvironmentBY DIANE TALBOT, SENIOR BUSINESS ANALYST, NATIONAL ASSOCIATION OF INSURANCE COMMISSIONERS


The objective of the survey was to gain a better understanding ofhow organizations are structuring their business analysis groups,

their roles, titles, and in general an overview of the Business Analystcommunity. A total of 270 individuals respondedto the survey which was conducted during April2005, using a website survey in conjunction withan email solicitation targeted directly to businessanalysts. The respondents were surprisinglybalanced representing various sizes of organizationsand geographical regions of the country.

S U R V E Y R E S U LT S

Business Analyst RolesOne of the questions we asked concerned what BAsdid during the execution of their responsibilities. Wewere encouraged to see the results (see chart below).

What is obvious from the results is that themajority of respondents are gathering anddocumenting data requirements, process work flows and businessrules requirements. This supports the industry definition of the roleof a Business Analyst. It also supports the theory that a BusinessAnalyst often bridges the gaps by taking on the role of ProjectManager or Quality Assurance.

Business Analyst GroupSeveral issues that are being debated within organizations today are:should there be a centralized group for performing Business

Analysis, and if so, where within the organization should the unitreport? Further what title should represent the job they areperforming? Should the Business Analyst ideally have a technical tobusiness background?

The survey showed that a little more than half of theorganizations represented have aBusiness Analyst group and almost70% of those groups report to theInformation Technology division.While there was some diversity amongthe title being used for businessanalysis, 64% use the words Businessand Analyst in their title.

In the industry, we do see a trendof organizations utilizing moreindividuals from the business unitsthan in the past, however 70% of ourrespondents that were performingbusiness analysis still had held previouspositions within InformationTechnology.

Less than 1% of the respondentsclaimed that business analysis wastheir first job. Most individualsperforming this role have many yearsexperience either in the technical orbusiness unit and sometimes both.Due to the growing role of theBusiness Analyst, we see this job beingperformed in the future by even moresenior level individuals. The followingchart shows the current information as

Business Analyst Industry Survey ResultsCONDUCTED BY B2T TRAINING


64%

64%

27%

2%2%2%3%

Business Analyst

System Analyst

Programmer/Analyst

Consultant

Product Manager



27%

2%2%2%

3%

Business Analyst

System Analyst

Programmer/Analyst

Consultant

Product Manager



66%

12%

3%9%10%

IIBA

PMI

Six Sigma

None

Other



0 20 40 60 80 100








Screen Design 43%






Other 6%

64%

64%

27%

2%2%2%3%

Business Analyst

System Analyst

Programmer/Analyst

Consultant

Product Manager



27%

2%2%2%

3%

Business Analyst

System Analyst

Programmer/Analyst

Consultant

Product Manager



66%

12%

3%9%10%

IIBA

PMI

Six Sigma

None

Other



0 20 40 60 80 100








Screen Design 43%






Other 6%

The IIBA continues to work to developthe BA Body of Knowledge, the certifi-

cation program, and creation of local chap-ters. The IIBA has close to 1,000 membersand membership is growing. We encourageBusiness Analysts to participate in the organ-ization and help strengthen the profession.

Body of KnowledgeThe outline of the body of knowledge isavailable on the IIBA web site for review.There is now a forum available for membersto give feedback on the specifics of theknowledge areas. Please visit the web site andhelp us develop a quality body of knowledge.

CertificationThe IIBA continues to define itsaccreditation program. An outline of theproposal is also available on their web site,www.iiba.com. Their goal is to have theprogram defined by mid-2006 and theprogram started as soon as feasible.

ChaptersFormation meetings have been held inBoston, Des Moines, Minneapolis, andAtlanta. In addition, Dallas, Detroit, andNew York groups have expressed interest instarting a chapter. If you are interestedplease contact USchapters@iibacom. n

Update

it relates to years of experience and the respectivesalary ranges. There were only slight elevations inthe salaries for the Northeast and West, whencomparing the data across the US and almost nodifference when comparing various sizes oforganizations, indicating that there is fairlyconsistent compensation for this role.

Business Analyst CommunityUntil recently, there has not been an industryorganization for Business Analysis professionals.As stated above, many of the individualsperforming business analysis have backgrounds inother roles and have participated in those industrygroups. We expect to see a significant change inthese results as the professional organization ofthe IIBA, International Institute of BusinessAnalysis, grows. n


New Certified Business AnalystsWe are pleased to be able to highlight thelatest individuals who have earned the titleof Certified Business Analyst since the lastissue of the bridge. To date, we have morethan 1,500 people in the program, with justover 100 who have completed and receivedcertification and an additional 100 individualsin the final stage of the process.

Marc BellerJennifer BeseckerBobbi BrownDione ChristianTina CoccieCecilia CorrellGail M. CulterShelley DavidsonKim EarlesGail FellsPatricia FusiekRebecca GaslinDonna GeogheganKelley JacquayAllison JarrettMichelle JenningsBenjamin KiekeJanet KimKelly KokemullerAnn Montgomery

Lewis

Diane LombardoSandy LovellAlexandra MolestinaAnn MooreJeff O'BryanElizabeth OlawoyinAaron Paige Owens Debra Panitz-PesacMargaret PerrittAnn PetersGail PopeNancy RayPatricia E. SkahanLisa SmallDenise SmithEvelyn StevensonDiane TalbotRomany TougawShawn TravisKelly WilkinsonSue Williams

64%

64%

27%

2%2%2%3%

Business Analyst

System Analyst

Programmer/Analyst

Consultant

Product Manager



27%

2%2%2%

3%

Business Analyst

System Analyst

Programmer/Analyst

Consultant

Product Manager



66%

12%

3%9%10%

IIBA

PMI

Six Sigma

None

Other



0 20 40 60 80 100








Screen Design 43%






Other 6%A N N U A L S A L A R Y

Years Experience asBusiness Analyst < $50,000 $50,000 - $75,000 $75,000 - $100,000 > $100,0000 - 2 35.62% 52.05% 10.96% 1.37%3 - 5 29.49% 48.72% 20.51% 1.28%6 - 10 10.00% 42.50% 35.00% 12.50%> 10 13.51% 37.84% 32.43% 16.22%

About your B2T CertificationMany of our students have asked how the IIBA certification program will compare to the existingB2T Training certification program. Since the IIBA certification program has not yet been definedfully a comparison is not possible. We are supporting the development of the IIBA certificationprogram because we feel that an independent certification would benefit our industry. We may atsome point offer study guides or preparation training for the IIBA exam but we still plan tocontinue our own Certification program as long as there is interest from our customers.

We feel an obligation to our certified business analysts and our corporate customers tocontinue to make our program the best training and preparation out there for business analysts.We will always support our Certified BAs.

The IIBA is still 2-3 years away from offering certifications. We at B2T are all very involved involunteering for IIBA and we really want to help make the IIBA a success. Our list of certifiedbusiness analysts continues to grow and we feel that our personal attention to our candidates, ourexcellent courses and instructors, our challenging certification process, and our selection of thebest skills and practices needed by business analysts to succeed are all reasons why we willcontinue to provide tangible benefits to everyone involved in our B2T Certification program.


uml brain teaser

ACROSS3 A requirement that has every

necessary part or everything that iswanted

5 Describes tasks that an Actor wantsthe system to do

6 Represented by a diamond in anactivity diagram

9 A graphical bar that represents apoint at which an activity flowbreaks into two or more parallelpaths.

10 “Who” will use the software in aUse Case diagram

11 Line from an actor to a Use Case ina use case diagram

13 Evaluates as true to follow onespecific flow from a decision

15 Another name for the primary pathof the Use Case description

17 Lines with arrows on an activitydiagram

18 To order things according to theirimportance or urgency

24 Stimulus that “sets off” a process26 Actors are represented by these28 A requirement that is appropriate to

meet the goals of the project29 Modeling language developed by

Booch, Rumbaugh, Jacobson

31 Represented as small ovals insideautomation boundary

34 A requirement that istechnologically possible for areasonable cost

35 Rectangle that surrounds the UseCases

36 Another word for an activity39 Project Boundaries40 Goals of a system41 An identifying name

DOWN1 An organization that has a set of

standard workflow symbols2 Measurements4 A state of the system “after” the

Use Case5 Diagram that contains locations,

work flow and activities7 “What if” workflow8 A graphical bar that represents a

point at which activity paths comeback together

11 Diagram of current state12 These are encapsulated in an object

along with data14 Unit of work that must be

performed to accomplish abusiness goal

16 Square brackets containing textnext to an activity or decision point

19 A state of the system “before” theUse Case

20 A requirement that is needed orrequired

21 Functional Diagrams that show howorganizations interact with eachother

22 An occurrence outside the scope ofthe business area that requires aresponse from the business area

23 Ending point, bull’s eye25 A requirement that is clear in

meaning or intention; unable to bemisunderstood

27 A requirement that is testable30 Shape drawn on a diagram;

represents a resource, activity,decision point, or control flow

32 A Use Case that adds functionalityto another Use Case “________” it.

33 Diagram that describes objectrelationships

37 Shape that represents a Use Caseon the Use Case diagram

38 Future scenario of a Use CaseActivity Diagram

Answers on page 12


This month’s column was provided bytwo of our Certified Business Analysts

Question: I am a new BA and have a fewquestions regarding the use of Use Cases. Whywould I need to create Use Cases for thetesters when they should be using my ‘regular’requirements document to build their teststrategy and test cases from?

And speaking of Use Cases, do I have todevelop a Use Case Diagram if I have UseCases? What if I choose not to do the diagram?Will it be confusing for the readers?

Answer: Use Cases are very helpful forQA and/or testers because it gives them aclear description of how the softwareshould work including the actor action, thesystem responses, the order of tasks, as wellas the expected results (i.e. error messages).It’s really all spelled out for them. It willshow how the system is supposed to workand how it should behave under certain

conditions. For you, this means you can besure that your requirements will be testedin a very high quality fashion to the exactspecifications of your RequirementsDocument.

A Use Case diagram will be beneficial(although not absolutely necessary) becauseit shows, at a high level, everything you areoutlining in your Use Cases. This givesyour Project Team members the comfortlevel they need to sign off on yourdocuments. It will also show if you haveholes in your requirements.

Question: When doing requirementsanalysis, what UML techniques can beutilized to ensure that complete & accuraterequirements will be developed?

Answer: There are many different UML diagrams that aid in requirementsdevelopment. Some of these diagrams andassociated benefits are:

• UML Sequence Diagram – This diagramis used to explore the sequence ofinteractions (messages) between exampleobjects within a use case.

• Use Case Diagram – This diagram isuseful for showing design area scope. AUse Case Diagram shows how anautomated computer system interactswith its users.

• Activity Diagram – This shows the flowthat a particular task or software functionproceeds through to achieve its goal.

• Class Diagram –The most importantUML diagrams are Class Diagrams.Class Diagrams are used to give anoverview of a system and describes therelationships that exist between thedifferent types of objects in the system.It displays what interacts but not whathappens when they interact. n

Send your questions to Ask the Experts [email protected].

ask the experts UML Diagrams

Applying UML and Patterns is geared forintermediate or senior business

analysts, architects or program developerswho are interested in learning more aboutobject oriented analysis and design(OOAD) or understanding how to useUML. In comparison to other OOADbooks, this is among the easiest to read andunderstand, so much so that it is used atseveral colleges and training companies toteach object-oriented analysis. It has alsogarnered many industry-expert accolades.

Some sections that were of interestinvolved Use Cases. In his book Larmanrelates Use Cases to the lowest-levelbusiness processes. He presents examples ofUse Cases written in many levels of detail,and explores the level of detail that is most

useful to describefunctionalrequirements:summary, detailedor somewhere inbetween. He alsorecommends aprocedure todiscover Use Cases

by identifying user goals first and thenwriting a detailed Use Case for each goal.

Although Larman discusses several stylesfor writing Use Cases, he makes a point tosay that no matter what style you use themost important thing is to capture thedetails of the main (successful) andalternate flows. One format he writes aboutis “the essential Use Case” style. This style

avoids any technical details and focuses onthe real user intent. Sound familiar? Itshould, because these Use Cases are similarto “essential processes”. He describes thisstyle as “expressed at the level of the user’sintentions and system’s responsibilities,rather than their concrete actions.”

Some of the noteworthy features of thisbook are plenty of analysis and design tipsand the use of a consistent, understandablecase study. Additionally, his examplesdemonstrate the strength of iterativedevelopment, and allow you to learn howto think in objects, instead of just learningthe UML notation. n

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

book reviewApplying UML and Patternsby Craig LarmanREVIEWED FOR B2T TRAINING BY ANGIE PERRIS, PMP,


One day you arrive at work to beginyour new project and learn that

your company has adopted a newstandard – all documents mustfollow the UML/ object-oriented(OO) approach. Your projectmanager asks you to begin workingwith your business stakeholders to develop a Conceptual ClassDiagram. You have never heard ofClass diagrams! You begin to getred-faced. The PM quickly chimes,“Don’t Panic! You already haveexpertise in modeling data requirementsusing Entity Relationship Diagrams (ERDs).You can leverage those skills to develop Classdiagrams. You still have questions.

What is a Conceptual Class diagram?“It is a type of Class Diagram that isdeveloped with business stakeholders.” Can an ERD substitute for a ClassDiagram? “Depends on the applicationbut ERDs are not included in the UML.”Is a Conceptual Class diagram developedthe same way as an ERD? “Similarinformation is captured on Conceptualmodels but their goals are different.” Do Ineed to do both? “Sometimes.” Is onebetter than the other? “Depends on theapplication.”

Great start but the brief answers youreceive just beg for more questions whichcan make the head of any Business Analystspin, especially if you have never worked onan OO project. This article will discusssimilarities and differences between ERDsand Conceptual Class Diagrams, some basicUML terminology, and help you get startednaming conceptual classes so that yourrequirements don’t get “lost in translation.”

Basic OO terminologyObjects are examples of ideas or things –think of nouns or noun phrases. As thename suggests, object-oriented techniquesare focused on finding, naming, andorganizing different types of objects orclasses that interact in the business area tobe studied. This is a data-centric approach.

Visualize the real world consisting of manyobjects that are in some way related. Whenyou identify these “kinds of things” likedogs, cats, automobiles, they are calledclasses. The actual things like “Cujo” (thedog I always feared), “Bella” (my cat) andAcura (my car) are examples of classinstances or “objects.” You organize objectsinto groups or classes. Class is a generalterm used in UML to represent eitherbusiness things or software things (designclasses). Classes are the most importantartifact in object oriented analysis.

OO Conceptual Class Models are fairlyhigh level and do not refer to software. Theyshould not be confused with the DesignClass Models created in later iterations bysoftware architects. Design classes integratedata and processes. The processes in designclasses are referred to as methods (i.e.operations, responsibilities or behaviors)and describe what the class is allowed to do.Eventually developers end up with softwareobjects. The idea is to start with “real-world”classes that could eventually be traceddirectly to objects in a software system.

Conceptual ClassesOn your projects, conceptual classes, justlike entities, will be the “things ofsignificance” that must be further definedto gain a complete understanding of thebusiness problem (and potential softwaresolution). For example, a bank projectwould have classes such as: Customer,

Account, Checking, Savings, etc. that arerelated to each other. Together theydescribe important aspects of a bankingbusiness area or “domain.” Additionallyclasses have attributes (sometimes calledproperties or features) just like entities. Sofar these classes sound almost like entities.And they are. In conceptual modeling thereare even relationships between classessimilar to those in an entity relationshipdiagram.

What is different?One difference in conceptual modeling isthat you do not have to follow the strictrules of data modeling. To demonstrate thispoint, consider the banking example. Youcould add additional classes such as: Bank,ATM, and ATM card. These classes mostlikely would not be found in a logical datamodel. In data modeling, we do notidentify entity types where there is onlyone instance of the entity, like the Bank.We also do not name physical things thatshould be part of the implementation, like an ATM card. Additionally in datamodeling we define unique identifiers andforeign key attributes, but these conceptsare not used in conceptual modeling.Another difference is that relationships orassociations used in class diagrams canshow much more complex relationships(associations) than typical data modeling.These links can be unidirectional or bi-directional. Relationship types includeassociation, aggregation, and inheritance.

Conceptual class diagrams are verymuch like entity relationship diagrams.One good reason to build a Conceptualmodel is so that the entire team canvisualize and understand the importantconcepts or things in the business areabefore diving into the details of theapplication. Rather than focusing on whatprocesses need to be performed we look atwhat things are significant to us. Havingsuch a “real world” picture will assist thedevelopment team in future iterations todesign cohesive software objects that

lost in translationUML Conceptual Class Diagrams are Not Just Fancy ERDs!BY ANGIE PERRIS, PMP,


Each issue of the bridge focuses on a particular area of interest withinbusiness analysis. Articles relevant tothe topic area are preferred; however,any articles about best practices,project success stories, BA resources(books or tools) will also beconsidered. We will post submissiondeadlines for each issue so keep aneye on our website. To submit anarticle send an email [email protected].

Submit an article to the bridge!

integrate data andprocesses and willprovide the thingsthe business needs.

How to get started creating aConceptual Class(Domain) model1. People often begin

the ConceptualModel after theyhave identifiedtheir Use Cases.

2. List the nouns ornoun phrases(often found inyour Use Cases)and describe thereal worldconcepts that wecare about. Whatterms, ideas, and concepts does thebusiness use to describe their world? Beaware that not all conceptual classesbecome part of the final system.

3. Draw rectangles that are split in twoparts to represent each conceptual class.Put the names of the classes in the toppart and list any important attributes inthe bottom. Exclude any implementationdetails.

4. Add only attributes necessary to fulfill theinformation requirements. Review eachUse Case and look at which data elementswill need to be held for later retrieval (i.e.the date or time of a transaction). Not allclasses need attributes.

5. Draw lines between classes for criticalassociations. (It is more important tofind important concepts thanassociations at this stage).

6. Refine the model as needed to captureonly the relevant information in thescope of the project or iteration of theproject.

SummaryAs you can see, much of what you alreadyknow about creating ERDs will be usefulwhen you create Conceptual Classdiagrams. OO evangelists believe thatlooking at the world in terms of objects is amore natural way to organize information

for software applications. They also believethat object oriented methods lead to better,more secure software that is easier tomaintain and grow in the future. Beforeusing the Conceptual Class modelingtechnique, or any other new UMLtechnique, you should consider what youare trying to achieve, if the technique isappropriate for your audience, and if thedeliverable adds value to your project. Ifnot, choose one that does. n

Sign up for B2T Training’s new course UMLfor the Business Analyst if you want to knowmore about creating Conceptual ClassModels. For any additional comments aboutthis article email [email protected].

Answers toBrain Teaserpuzzle onpage 9

Conceptual Class Diagram

Entity Relationship Diagram


new course

UML for the Business AnalystThis course is designed for Business Analysts who need a working knowledge ofUML and OO development to facilitate communication with their technology teammembers. Most new software development projects are using OO programming. Ifthe Business Analyst can present requirements to the developers in a mannerconsistent with their design deliverables, software design and development time canbe decreased and software quality increased.

Course Outline

Introduction to UML for the Business Analyst• What is the Unified Modeling Language?• What is Object Oriented Programming?• What is Object Oriented Analysis and Design?• What is RUP (Rational Unified Process)?• What is Agile development?• What is a Tiered architecture?

Detailing Business Requirements with UML Diagrams• Learn to develop Business Use Case Diagrams and write Business Use Case

descriptions • Discuss the differences between Business Use Cases and Essential Business Processes• Learn the purpose and the components of the Conceptual Class Diagram• Discuss the differences between Conceptual Class Diagrams and Entity Relationship

Diagrams• Group Workshop: Finding the Nouns and building a Conceptual Class Diagram• Discuss the use of UML Activity Diagrams to clarify complex Use Cases• Learn to incorporate swimlanes into UML Activity Diagrams• Learn to use CRC Cards to decide which requirements need to be detailed for your

project

Detailing Functional Requirements with UML Diagrams• Learn to use Business Use Cases to create the first draft set of System Use Cases • Learn the purpose and components of a Class Diagram• Discuss the use of the Conceptual Class Diagram to develop the first draft of the Class

diagram.• Learn the purpose and components of a State Diagram• Learn the purpose and components of a Sequence Diagram

For more information on this course visit www.b2ttraining.comt

Intended AudienceThis course is intended forexperienced BusinessAnalysts who want to learnhow they can use UML/OOtechniques.

PrerequisitesStudents must have attendedEssential Skills for theBusiness Analyst (or haveequivalent experience)before attending this class.

3 Days


certified core courses

Essential Skills for the Business AnalystThis course covers the critical skills for the Business Analyst. Students will learnto define what is, and what is not included in the project, how to ask the rightquestions, when and how to hold interviews and facilitated sessions, how towrite excellent requirements, how to verify that requirements are testable, howto conduct a requirements review, and have an overview of various applicationdevelopment methodologies. Additionally, students will be introduced to variousdocumentation techniques and plan an approach for documentation.

Detailing Business Data RequirementsThe Data portion of the business requirements is a critical component to definingcomplete requirements. Every process uses data and almost all business rulesare 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 anin-depth approach to identify and define all necessary data components usingboth textual templates and an entity relationship diagram to create a data model.

Detailing Process and Business Rule RequirementsThis course continues the development of the requirements package by definingthe processes and business rules for the project. Students will learn to identifyand define the processes from a business and functional perspective. Varioustechniques are taught including decomposition diagrams, templates, workflowmodels, and Use Case diagrams and descriptions. Additionally, this courseteaches techniques to ensure that requirements have not been missed.

More detailed outlines are available on our website, www.b2ttraining.com

4 Days

3 Days

4 Days

t


additional course offerings

Requirements Testing for the Business AnalystThis course provides an excellent foundation for Business Analysts to achievebest practices in software quality assurance (SQA). The course will improve theBusiness Analyst's development of requirements so that they can be used tobuild quality test cases. It will also enable the Business Analyst to create specifictest cases from the requirements. The course includes a workshop case studythat provides a cohesive learning experience.

Overview of Business AnalysisThis seminar presents the Business Analyst role to managers and others wholead and work with Business Analysts. In order for the Business Analyst to besuccessful, both the IT and business community must embrace the businessanalysis process. The seminar can be used as a working session to discuss howyour organization will implement the business analysis process and approachesfor documenting the requirements.

Advanced Business Analysis WorkshopBusiness Analysts are constantly striving to improve their skills and increase thequality of their project requirements by learning advanced requirementsgathering techniques. This course enhances the efficiency and effectiveness ofBusiness Analysts by giving them additional techniques and strategies forgathering, documenting, and reviewing requirements. Techniques such asadvanced data definition, traceability, and gap analysis help BAs to documentmore accurate and complete requirements. The course also presents the conceptof Requirements Management and requirement reuse. Implementing arequirements management process into your organization can significantlyreduce the time required to make software changes and develop softwareinterfaces.

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

4 Hour Seminar

3 Days

3 Days

t

2005 public class scheduleEssential Skills for the Business Analyst - $1,980/per student

• Jun 6 – Jun 9, 2005 Atlanta, GA• Jun 20 – Jun 23, 2005 Houston, Tx• Jul 25 – Jul 28, 2005 Atlanta, GA• Aug 15 – Aug 18, 2005 Louisville, KY• Oct 24 – Oct 27, 2005 Atlanta, GA

Detailing Business Data Requirements - $1,485/per student

• Jun 13 – Jun 15, 2005 Chicago, IL• Jul 11 – Jul 13, 2005 Seattle, WA• Jul 26 – Jul 28, 2005 Houston, TX• Sep 19 – Sep 21, 2005 Atlanta, GA• Oct 17 – Oct 19, 2005 Louisville, KY

Detailing Process and Business Rule Requirements - $1,980/per student

• Aug 1 – Aug 4, 2005 Chicago, IL• Sep 26 – Sep 29, 2005 Houston, TX• Sep 26 – Sep 29, 2005 Seattle, WA• Nov 14 – Nov 17, 2005 Atlanta, GA• Dec 12 – Dec 15, 2005 Louisville, KY

Advanced Business Analysis Workshop - $1,485 per student

• Aug 22 – Aug 24, 2005 Atlanta, GA

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

On-site classes are also available.

Call 865-675-2125 or email us at [email protected]

B2T Training11795 Northfall Lane, Suite 601Alpharetta, GA 30004

Prsrt StdU.S. Postage

PAIDPermit #309

Knoxville, TN

The Bridge - Summer 2005

Documents

Transcript of The Bridge - Summer 2005