the
CONNECTING BUSINESS REQUIREMENTS TO TECHNOLOGY
Summer 2005
Demystifying Business Use Cases online ordering
Get Order Status
Place Order
Cancel Order
Return Product
New Course UML for the Business Analyst
Changing the Business Analysis Environment
Book Review Applying UML and Patterns
Business Analyst Industry Survey Results
letter from the editors n this issue of the bridge we are highlighting UML (the Unified Modeling Language) and its usefulness to Business 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 create UML 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.
I
To help introduce some of the UML topics we have included an article about Business Use Cases. UML was originally 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 a Business 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 of the survey results are shown on page 7. We believe this is the first survey of Business Analysts ever conducted and although the number of respondents was small (270), it gives us a baseline on which to measure future growth 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 current articles 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 for Business Analysts! This is a great indicator of our industry’s growth because only two years ago, we didn’t have any conferences to attend. See the ads for the conferences in the magazine. Please continue to let us know of areas of interest for future issues of the bridge. We continue to be excited by the enthusiasm of Business Analysts working to make their organizations more successful.
TINA JOSEPH
Certified Woman Owned Small Business
BARBARA CARKENORD
the
Scoping the Project 66% Gathering Data Requirements 84% Document Use Case Requirements 62% Document Process Workflows 75%
PRIMARY JOB TITLE FOR BUSINESS ANALYSTS
3%
Gathering Buisness Rules 76%
2% 2% 2%
Process Reengineering 35%
27%
Screen Design 43%
Business Analyst
Writing System Specifications 41%
System Analyst
Cost Benefit Analysis 33%
Programmer/Analyst Consultant
Requirements Management 65%
Product Manager
Project Management 45%
Various Titles/Others
User Acceptance Testing 56%
volume 2 l issue 1
64%
Summer 2005
Facilitating Information Gathering Sessions 69%
Other 6%
0
20
40
60
80
100
table of contents 3 6 7 8 9 10
Demystifying Business Use YOU INVOLVED IN ANY INDUSTRY ORGANIZATIONS? ARE Cases
PRIMARY JOB TITLE FOR BUSINESS ANALYSTS
64%
27% 3%
2% 2% 2%
Page 7
Business Analystthe Business Analysis Environment Changing 66%
IIBA
System Analyst
PMI
Programmer/Analyst
12%
Six Sigma
Business Analyst Industry Survey Results Consultant 10% 9%
Product Manager
None
3%
s Businesr Worke
stem sing Sy Proces rship Membe er memb Add a
Other
Various Titles/Others Business Analyst Certification Program
er Memb Rep s Service
UML Brain Teaser Ask the Experts UML Diagrams
10
Book Review
Page 3
Applying UML and Patterns by Greg Larmen Page 10
11
Lost in Translation UML Conceptual Class Diagrams are Not Just Fancy ERDs!
13
B2T Training New Course UML for the Business Analyst
15 17
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 skills and 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 to ensure the project has met its defined objectives. Our training is offered nationally and on a limited international basis. Most of our classes are taught onsite and are tailored to the unique environments of each organization. Public classes are also available in various cities around the US. Vice President, Sales and Marketing Tina Joseph
Vice President, Training Barbara A. Carkenord
Director of Business Development Angie Perris
©2005 B2T Training. All rights reserved.
the bridge l Summer 2005 2
stem sing Sy Proces rship Membe s Businesr Worke
er memb Add a
er Memb Rep s Service
Demystifying Business 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 ,
new requirements technique called the Business Use Case is being discussed in the software development industry. This artifact or deliverable is developed during the Business Modeling or Requirements Gathering phase of project life cycles. We know the phrase Use Case from the object oriented/UML (Unified Modeling Language) development approaches where Use Cases are goals of the software. So by putting the word “business” in front of them it sounds like we are talking about goals of the business. What a great concept – using a well established technique for a new type of work. But really understanding and creating these Business Use Cases has turned out to be harder than it looks. This article will attempt to explain the history of these new artifacts and “de-mystify” them for Business Analysts. OO/UML methodologies address software development, they were not created with business modeling in mind. These approaches assume that a decision has already been made that software is the solution to the business problem. They assume that a “Business Model” has already been created and is available for all software development projects. The existence of this Business Model implies that we already completely understand the business processes and the business objectives. Unfortunately, most organizations don’t have the time to build a Business Model or document any business requirements until a project has been approved. Often a solution has been proposed before the problem is fully understood. Experienced analysts keep an open mind about possible solutions while they are gathering requirements and try to develop a Business Model before documenting functional requirements. The Business Use Case Model is a technique for documenting this Business Model (business
A
3 Summer 2005 l the bridge
requirements) as the first step in the software development process.
Background/History There is a long and successful history of analysts borrowing techniques from software developers. In the 1970s Ed Yourdon developed the data flow diagram as a tool for designing software systems. Programs were represented as “bubbles” and arrows showed how data and parameters were sent from program to program. Data flow diagrams were quickly adopted by many developers because they presented a clear picture of how the software components should be built to work together. About a decade later, when business requirements were recognized as an important part of the software development process, analysts used the data flow diagramming symbols and techniques for their own work. The “bubbles” became business processes and the arrows showed how information flowed from one business process to another. Business stakeholders found these diagrams very useful for reviewing requirements and even for business process reengineering. The highest level dataflow is the Context Level Data Flow diagram which is commonly used for project scoping.
The Business Use Case Model In the OO/UML development approaches, organizations have been using System Use Cases for many years to define how the software should work and communicate this to the development team. Many business people find these System Use Case descriptions easy to review. With the Business Use Case, analysts are trying to use the same format for Business Requirements. With the introduction of Business Use Cases the OO/UML approach has taken a software design
technique and adapted it to be used for gathering, analyzing, and documenting business requirements. Advocates of Business Use Cases suggest that this new artifact can support business model development and then can easily be translated into the software development System Use Cases to speed the development process. As with any new tool or technique, Business Use Cases must be clearly defined and used consistently before we can evaluate their effectiveness. Unfortunately, consistent standards and guidelines for creating Business Use Cases have not been accepted. It is necessary for Business Analysts choosing to use this technique to set their own standards and guidelines before they attempt to use them on their projects. Some suggestions for these standards are included below. In OO/UML methodologies, a System Use Case can be represented 1) on a Use Case Diagram, 2) on a UML activity diagram, and 3) is detailed with a Use Case Description. The collection of these artifacts is referred to as the System Use Case Model. Most teams start with the Use Case Diagram as the high level requirements artifact.
Utilizing System Use Case Model Components in a Business Use Case Model Actors. In a System Use Case an actor
(stick figure in the diagram) is defined as a resource that is outside the automation boundary and uses the software. These can be people, other systems, or hardware devices. For a Business Use Case the definition of an actor must be expanded to be “any resource that is outside the business area and uses the business”. Actors are not under the direct control of the business area being studied.
The Use Case. In traditional approaches
the Use Case (oval in the diagram) is defined as a goal of the software, something that provides value to an actor. Again, if we look at this from a business perspective we would define a Business Use Case as a goal of the business, something that provides value to an actor. Each Use Case is described in detail with a Use Case Description (see chart below).
Associations. The lines that connect actors to Use Cases on the diagram are associations and show how each actor is involved with each Use Case. These associations could be used in the same way for Business Use Cases.
to the validity of the Business Use Case Model.
Differences between System Use Cases and Business Use Cases As with any requirements deliverable or artifact, 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 at communicating complex information to different audiences for different purposes because this is our main job function. When we create System Use Cases the answers to the questions are pretty straightforward: we are creating the System Use Cases to describe how we want software to work, the business stakeholders will review them to approve the functionality, and the developers will use them to write code. However, answering these questions for Business Use Cases is where the confusion really becomes obvious. What we discover is that Business Use Cases are very flexible and may be used for any number of purposes. But if their purpose is unclear, they may not be developed consistently and may become useless! There are at least three possible reasons for creating a Business Use Case Model: 1. To clarify the understanding of how the current business performs its work 2. To serve as a high level starting point for software design
The automation boundary. A traditional Use Case Diagram contains a large rectangle that represents the automation boundary. Actors are shown outside the rectangle with lines attaching them to particular Use Cases. This boundary shows what is included in the software functionality and shows where people and other systems will interface with the software. In the case of EXHIBIT 1 people, these interfaces are usually screens, web pages or reports. For Business Use Cases, this rectangle Business Worker could represent the business area being studied. So far, all of the components from the System Use Case Model Member Services Rep seem to translate pretty easily and this seems like a technique that will work well for Business Requirements. However, there are some differences between Business Requirements and Software Requirements that must be Member considered before we can commit
Business Use Case Model Current “AS IS” Process Membership Processing System
3. To provide a true, essential Business Model, independent of procedural/system descriptions These three options for usage will result in three different Business Use Case Models. Allow me to review each option by using an example. The example is a Business Use Case Model for a membership business area. Exhibit 1. This diagram shows how the
business currently operates. You will notice a special type of actor here: the Business Worker. This is a new modeling component that IBM/Rational has proposed to show people who are working in the business area. In this example, the Member is an actor but only has access to the business through a business worker. This diagram is useful when the project team needs to understand the current business before recommending a possible change. If you are documenting how work is currently done, Business Use Case Models most closely compare to Workflow Diagrams. The Use Case Diagram shows who does the work and the Use Case Descriptions describe how the work is performed. There are two main differences between using Workflow analysis and Business Use Cases: 1) the Business Use Cases can have a textual component “behind” the graphic, 2) Workflow diagrams typically show how business processes interact with each other while Business Use Cases show how actors interact with the processes. Both tools offer the analyst ultimate flexibility in terms of level of detail, level of formality, ease of documentation, and ability to communicate a large number of ideas and concepts.
Add a member
Change member profile Service Provider Request Club Service
Exhibit 2. This diagram shows how the business would like to operate in the future. The Member will be able to access the membership system via a web page. Notice that Members will be allowed to join the club or change their profile but will need to continue to work through the business worker to request services. This diagram Continued on page 5 the bridge l Summer 2005 4
Business Worker Business Use Case Model Add a member Current “AS IS” Process Membership Processing System Change
member implementation options. This present recommendations Perspective AS IS TO BE profile diagram isService also useful for for changes and as a scope diagram for the Essential Current business New business Add a member analyzingProvider new business areas or software development project. business activities activities processes independent of independent new business processes. It would If you are designing software Request Club Change Service “WHAT” of how they of how they Member to support your business also be useful for modeling a automation member Services Rep profile are performed. will be brand newService business area. processes, Business Use Cases most closely performed. Provider compare to System Use Cases. Business Implementation Current business Proposed If you are analyzing the Use Cases can be detailed and turned into Club Request “HOW” procedures business Member Service business, independent of System Use Cases during the project. This and software procedures technology, the Business Use Case is probably the most common use of features. and software Diagram most closely compares Business Use Cases today. A starting point features. to the Context Level Dataflow for software functionally descriptions, they Member the perspective of the actor who initiates Diagram. In the Dataflow diagram we show are initially very high level and often used them, while essential business processes are External Agents and their interactions with to scope the software features. This will Business Use Case Model named from the perspective of the business the business. The advantage of the Business probably continue to be the best New “TO BE” Software area. Understanding perspective and using Use Case Diagram over the Context Level application of Business Use Cases. New Membership Web Site it consistently are the keys to success in any DFD is that it shows Business Use Case Model requirements gathering technique. EXHIBIT 2 the activities going on Join theBE” club Software New “TO As you can see, Business Use Cases are inside the business area, Member New Membership Web Site very flexible. And as every good analyst while the DFD only knows, the more flexible the tool the more shows the outside Change member difficult it is to use consistently. Business Join the club interactions. profile Service Member Use Cases are an additional tool in the BA Essential Business Provider Toolkit and the Business Analyst must Use Case descriptions Change member Request Club continue to make choices about which tool profile most closely compare Service Service is best suited to each project need. to Essential Business Provider Member Process descriptions. Services Rep Request Club Specific Recommendations Essential Business Service Business 1. Before developing a Business Use Case Processes are Worker Member Services Rep Model be certain how and why it is independent of who being used, and set standards to ensure performs them, how Business Worker consistency. they are performed, 2. Clearly label all requirements artifacts. and what order in Make sure that diagram titles include the which they are Business Use Case Model EXHIBIT 3 perspective. Use standard language such performed. As a Essential - Independent of “how” as AS IS vs. TO BE, and WHAT (core matter of fact, the Membership Business Use Case Model business process). vs. HOW requirements in B2T Essential - Independent of “how” (implementation). Training’s Essential Join the club Membership 3. Always choose the technique that is most Process template are appropriate for your project and your the same requirements Join the club Change audience. that should be gathered member profile Whether or not you choose to develop a 4. for a Business Use Service Member Change Business Use Case Model, a good practice Provider Case! member profile is to always prefix the words “Use Case” Both offer great Service Member Request Club Provider with either the word “System” or Service flexibility for imagining “Business.” This will avoid confusion for future alternative Request Club Service reviewers and other analysts. solutions. Until Business Use Cases become more commonly accepted and industry standards Exhibit 3. This diagram shows a It’s all about perspective! are agreed upon, this new technique will Each of the example diagrams above could technology independent or essential view of continue to “mystify” analysts who have the business. In true essential modeling we accurately be titled “The Business Use not thought through its implications. n do not show how work is done or who does Case Model for the Membership System”. the work. This models the business in its But notice the differences in the diagrams. Sign up for B2T Training’s new UML for the purest form. This diagram allows the most All of these differences stem from the Business Analysis course to learn to write flexibility when re-engineering business perspective from which the model is built. Business Use Cases. processes or looking for alternate In addition, Use Cases are named from
Member Business can be used to Rep ServicesWorker
5 Summer 2005 l the bridge
Changing the Business Analysis Environment BY D I A N E TA L B OT, S E N I O R B U S I N E S S A N A LYST, N AT I O N A L AS S O C I AT I O N O F I N S U R A N C E C O M M I S S I O N E RS
Y
ou’ve taken Business Analysis classes; you know which tool to use in which situation. You are ready to make a positive impact on the way your company approaches analysis. That, however, may be your biggest challenge. In environments where no business analysis standard exists, convincing Project Managers, Development Teams and even other Business Analysts that what you are doing can work for everyone, is not an easy task. It is, however, a task that is worth doing, so don’t despair. Here are some ideas to help you get started. Understand resistance to change
It is human nature to resist change. In work environments where change is constant, Project Teams evolve processes over time that get them consistent results. Though a new process may improve the results, the established process has the appearance of stability-people know what to expect. Changing their processes to adjust to something new introduces an unknown complexity to the project and Project Teams do not want to worry about justifying a missed deadline because the Business Analyst decided to try something new. Don’t fight this natural resistance to change; there are ways to work with it. Be patient and remember that the established processes were not developed over night; they cannot change over night. Start Small
As a Business Analyst, you have a powerful set of tools in your tool box. Each diagram, table or analysis method is designed for specific situations. Don’t drop the whole tool box on the table at one time. The information overload will overwhelm the Project Team. Find one tool that will work for the majority of situations at your company and use it at every opportunity. As you introduce it, call it by name and explain the purpose. Tell them how it will make
you more efficient and how it will help the team communicate and understand the project. Show them how it works. The first time you introduce the new tool, you will be battling the factors of change and surprise. Prepare to spend a lot of time explaining what the tool is and why you believe it will be helpful. The second time you introduce the tool, the team will not be surprised, but they will still not understand how it is helpful. Be prepared to explain it again. Repetition is the key. When project teams begin asking questions and requesting the results of using the new tool on other projects they work on, you have successfully made a small step toward a new Business Analysis methodology!
with the previous tool you introduced. Remember, this one is new, so don’t skimp on the explanations. Then look for ways to measure the results of your new additions when the project is complete. Compare this project with previous projects without the new tool. Were there fewer open issues discussing the scope? Did the Development Team hit the ground running, rather than spending time redesigning? The project teams may be able to say that something was different about the project, but may not make the connection to the new tools you introduced. Demonstrating measurable success, project by project, will give you the fuel needed to make a permanent change. Be a Model
Give them something they need
Every company, no matter how successful, has something that could be improved. What does your company need? What tool do you have available to fill this need? For example, do the Project Managers need better time estimates on the analysis part of their projects? Give it to them. Track your time spent on the project pieces you handle for the next few projects. Over time, you will have a pretty good estimate of how much time you need for each project piece. The next time a project comes along, go to the Project Manager with your own time estimates for analysis, showing the trends over the last few projects. Give the Project Manager information that facilitates more informed decisions and they will sit up and take notice. Look closely at the processes in place in your company. Where can your Business Analysis tools make an impact? Find the need and you will be on your way to starting a change. Build on Success
Once you have a small success, build on it. Find the next logical tool from your tool box to introduce. Demonstrate how it fits
Most importantly, you know that the tools you have available as a Business Analyst can make a positive impact on the projects at your company, but it may take a while to get others to understand. Above all, project teams need a Business Analyst to efficiently bridge the gap between the Business Partners and the Development Team. Quiet confidence in your abilities, and a proven track record of success over time, will go a long way toward helping the company understand the need for a Business Analysis methodology that will make every project as successful as your projects have been. If the smallest step you can make is to wait until other Business Analysts come to you for guidance on making their projects more successful, you have made an impact that will go a long way toward changing your company’s approach to Business Analysis. Any step in the right direction is movement toward your goal of positively improving the way your company approaches Business Analysis. Believe in the Business Analysis tools you have available, track your improvements over time and look for the opportunities to demonstrate the value a Business Analyst can bring to your company. n the bridge l Summer 2005 6
Consultant Product Manager Various Titles/Others
Business Analyst Industry Survey Results 64%
C O N D U C T E D BY B 2 T T R A I N I N G
he objective of the survey was to gain a better understanding of Business Analyst Group how organizations are structuring their business analysis groups, Several issues that are being debated within organizations today are: their roles, titles, and in general an overview of the Business Analyst should there be a centralized group for performing Business community. A total of 270 individuals responded to the survey which was conducted during April PRIMARY JOB TITLE FOR BUSINESS ANALYSTS 2005, using a website survey in conjunction with an email solicitation targeted directly to business analysts. The respondents were surprisingly Business Analyst 64% balanced representing various sizes of organizations System Analyst and geographical regions of the country.
T
Programmer/Analyst
27%
S U R V E Y R E S U LT S Business Analyst Roles One of the questions we asked concerned what BAs did during the execution of their responsibilities. We were encouraged to see the results (see chart below). What is obvious from the results is that the majority of respondents are gathering and documenting data requirements, process work flows and business rules requirements. This supports the industry definition of the role of a Business Analyst. It also supports the theory that a Business Analyst often bridges the gaps by taking on the role of Project Manager or Quality Assurance.
Consultant 3%
Product Manager Various Titles/Others
2% 2% 2%
Analysis, and if so, where within the organization should the unit report? Further what title should represent the job they are performing? Should the Business Analyst ideally have a technical to business background? The survey showed that a little more than half of the organizations represented have a Business Analyst group and almost WHAT ARE THE PRIMARY ROLES PERFORMED BY THE 70% of those groups report to the BUSINESS ANALYSTS IN YOUR ORGANIZATION? Information Technology division. Scoping the Project 66% While there was some diversity among the title being used for business Gathering Data Requirements 84% analysis, 64% use the words Business Document Use Case Requirements 62% and Analyst in their title. In the industry, we do see a trend Document Process Workflows 75% of organizations utilizing more Gathering Buisness Rules 76% individuals from the business units than in the past, however 70% of our Process Reengineering 35% respondents that were performing Facilitating Information Gathering Sessions 69% business analysis still had held previous positions within Information Screen Design 43% Technology. Writing System Specifications 41% Less than 1% of the respondents claimed that business analysis was Cost Benefit Analysis 33% their first job. Most individuals performing this role have many years Requirements Management 65% experience either in the technical or Project Management 45% business unit and sometimes both. Due to the growing role of the User Acceptance Testing 56% Business Analyst, we see this job being Other 6% performed in the future by even more senior level individuals. The following 0 20 40 60 80 100 chart shows the current information as
7 Summer 2005 l the bridge
Product Manager
Project Management 45%
Various Titles/Others
User Acceptance Testing 56%
it relates to years of experience and the respective salary ranges. There were only slight elevations in the salaries for the Northeast and West, when comparing the data across the US and almost no difference when comparing various sizes of organizations, indicating that there is fairly consistent compensation for this role.
Other 6%
0Years Experience 20as Business Analyst < $50,000
0-2 3-5 6 - 10 > 10
NESS ANALYSTS Business Analyst Community
ANNUAL SALARY 40 60 80 $50,000 - $75,000 $75,000 - $100,000
35.62% 29.49% 10.00% 13.51%
52.05% 48.72% 42.50% 37.84%
10.96% 20.51% 35.00% 32.43%
100
> $100,000 1.37% 1.28% 12.50% 16.22%
ARE YOU INVOLVED IN ANY INDUSTRY ORGANIZATIONS?
Until recently, there has not been an industry organization for Business Analysis professionals. Business As stated above,Analyst many of the individuals performing business System Analystanalysis have backgrounds in other roles and have participated in those industry Programmer/Analyst groups. We expect to see a significant change in theseConsultant results as the professional organization of the IIBA, International Product Manager Institute of Business Analysis, grows. n
IIBA
66%
PMI 12%
Six Sigma 10%
None 9%
3%
Other
Various Titles/Others
Update he IIBA continues to work to develop the BA Body of Knowledge, the certification program, and creation of local chapters. The IIBA has close to 1,000 members and membership is growing. We encourage Business Analysts to participate in the organization and help strengthen the profession.
Certification
Body of Knowledge
Chapters
The outline of the body of knowledge is available on the IIBA web site for review. There is now a forum available for members to give feedback on the specifics of the knowledge areas. Please visit the web site and help us develop a quality body of knowledge.
Formation meetings have been held in Boston, Des Moines, Minneapolis, and Atlanta. In addition, Dallas, Detroit, and New York groups have expressed interest in starting a chapter. If you are interested please contact USchapters@iibacom. n
T
The IIBA continues to define its accreditation program. An outline of the proposal is also available on their web site, www.iiba.com. Their goal is to have the program defined by mid-2006 and the program started as soon as feasible.
About your B2T Certification Many of our students have asked how the IIBA certification program will compare to the existing B2T Training certification program. Since the IIBA certification program has not yet been defined fully a comparison is not possible. We are supporting the development of the IIBA certification program because we feel that an independent certification would benefit our industry. We may at some point offer study guides or preparation training for the IIBA exam but we still plan to continue 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 to continue 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 in volunteering for IIBA and we really want to help make the IIBA a success. Our list of certified business analysts continues to grow and we feel that our personal attention to our candidates, our excellent courses and instructors, our challenging certification process, and our selection of the best skills and practices needed by business analysts to succeed are all reasons why we will continue to provide tangible benefits to everyone involved in our B2T Certification program.
New Certified Business Analysts We are pleased to be able to highlight the latest individuals who have earned the title of Certified Business Analyst since the last issue of the bridge. To date, we have more than 1,500 people in the program, with just over 100 who have completed and received certification and an additional 100 individuals in the final stage of the process. Marc Beller Jennifer Besecker Bobbi Brown Dione Christian Tina Coccie Cecilia Correll Gail M. Culter Shelley Davidson Kim Earles Gail Fells Patricia Fusiek Rebecca Gaslin Donna Geoghegan Kelley Jacquay Allison Jarrett Michelle Jennings Benjamin Kieke Janet Kim Kelly Kokemuller Ann Montgomery Lewis
Diane Lombardo Sandy Lovell Alexandra Molestina Ann Moore Jeff O'Bryan Elizabeth Olawoyin Aaron Paige Owens Debra Panitz-Pesac Margaret Perritt Ann Peters Gail Pope Nancy Ray Patricia E. Skahan Lisa Small Denise Smith Evelyn Stevenson Diane Talbot Romany Tougaw Shawn Travis Kelly Wilkinson Sue Williams the bridge l Summer 2005 8
uml brain teaser
ACROSS 3 A requirement that has every necessary part or everything that is wanted 5 Describes tasks that an Actor wants the system to do 6 Represented by a diamond in an activity diagram 9 A graphical bar that represents a point at which an activity flow breaks into two or more parallel paths. 10 “Who” will use the software in a Use Case diagram 11 Line from an actor to a Use Case in a use case diagram 13 Evaluates as true to follow one specific flow from a decision 15 Another name for the primary path of the Use Case description 17 Lines with arrows on an activity diagram 18 To order things according to their importance or urgency 24 Stimulus that “sets off” a process 26 Actors are represented by these 28 A requirement that is appropriate to meet the goals of the project 29 Modeling language developed by Booch, Rumbaugh, Jacobson 9 Summer 2005 l the bridge
31 Represented as small ovals inside automation boundary 34 A requirement that is technologically possible for a reasonable cost 35 Rectangle that surrounds the Use Cases 36 Another word for an activity 39 Project Boundaries 40 Goals of a system 41 An identifying name DOWN 1 An organization that has a set of standard workflow symbols 2 Measurements 4 A state of the system “after” the Use Case 5 Diagram that contains locations, work flow and activities 7 “What if” workflow 8 A graphical bar that represents a point at which activity paths come back together 11 Diagram of current state 12 These are encapsulated in an object along with data 14 Unit of work that must be performed to accomplish a business goal
16 Square brackets containing text next to an activity or decision point 19 A state of the system “before” the Use Case 20 A requirement that is needed or required 21 Functional Diagrams that show how organizations interact with each other 22 An occurrence outside the scope of the business area that requires a response from the business area 23 Ending point, bull’s eye 25 A requirement that is clear in meaning or intention; unable to be misunderstood 27 A requirement that is testable 30 Shape drawn on a diagram; represents a resource, activity, decision point, or control flow 32 A Use Case that adds functionality to another Use Case “________” it. 33 Diagram that describes object relationships 37 Shape that represents a Use Case on the Use Case diagram 38 Future scenario of a Use Case Activity Diagram Answers on page 12
ask the experts UML Diagrams his month’s column was provided by two of our Certified Business Analysts
T
Question: I am a new BA and have a few questions regarding the use of Use Cases. Why would I need to create Use Cases for the testers when they should be using my ‘regular’ requirements document to build their test strategy and test cases from? And speaking of Use Cases, do I have to develop a Use Case Diagram if I have Use Cases? What if I choose not to do the diagram? Will it be confusing for the readers? Answer: Use Cases are very helpful for QA and/or testers because it gives them a clear description of how the software should work including the actor action, the system responses, the order of tasks, as well as the expected results (i.e. error messages). It’s really all spelled out for them. It will show how the system is supposed to work and how it should behave under certain
conditions. For you, this means you can be sure that your requirements will be tested in a very high quality fashion to the exact specifications of your Requirements Document. A Use Case diagram will be beneficial (although not absolutely necessary) because it shows, at a high level, everything you are outlining in your Use Cases. This gives your Project Team members the comfort level they need to sign off on your documents. It will also show if you have holes in your requirements. Question: When doing requirements analysis, what UML techniques can be utilized to ensure that complete & accurate requirements will be developed? Answer: There are many different UML diagrams that aid in requirements development. Some of these diagrams and associated benefits are:
• UML Sequence Diagram – This diagram is used to explore the sequence of interactions (messages) between example objects within a use case. • Use Case Diagram – This diagram is useful for showing design area scope. A Use Case Diagram shows how an automated computer system interacts with its users. • Activity Diagram – This shows the flow that a particular task or software function proceeds through to achieve its goal. • Class Diagram –The most important UML diagrams are Class Diagrams. Class Diagrams are used to give an overview of a system and describes the relationships that exist between the different types of objects in the system. It displays what interacts but not what happens when they interact. n Send your questions to Ask the Experts at sales@b2ttraining.com.
book review Applying UML and Patterns by Craig Larman R E V I E W E D F O R B 2 T T R A I N I N G BY A N G I E P E R R I S, P M P,
pplying UML and Patterns is geared for intermediate or senior business analysts, architects or program developers who are interested in learning more about object oriented analysis and design (OOAD) or understanding how to use UML. In comparison to other OOAD books, this is among the easiest to read and understand, so much so that it is used at several colleges and training companies to teach object-oriented analysis. It has also garnered many industry-expert accolades. Some sections that were of interest involved Use Cases. In his book Larman relates Use Cases to the lowest-level business processes. He presents examples of Use Cases written in many levels of detail, and explores the level of detail that is most
A
useful to describe functional requirements: summary, detailed or somewhere in between. He also recommends a procedure to discover Use Cases by identifying user goals first and then writing a detailed Use Case for each goal. Although Larman discusses several styles for writing Use Cases, he makes a point to say that no matter what style you use the most important thing is to capture the details of the main (successful) and alternate flows. One format he writes about is “the essential Use Case” style. This style
avoids any technical details and focuses on the real user intent. Sound familiar? It should, because these Use Cases are similar to “essential processes”. He describes this style as “expressed at the level of the user’s intentions and system’s responsibilities, rather than their concrete actions.” Some of the noteworthy features of this book are plenty of analysis and design tips and the use of a consistent, understandable case study. Additionally, his examples demonstrate the strength of iterative development, and allow you to learn how to think in objects, instead of just learning the UML notation. n B2T RATING: (scale is 1-4; 4 is the best) the bridge l Summer 2005 10
lost in translation UML Conceptual Class Diagrams are Not Just Fancy ERDs! BY A N G I E P E R R I S, P M P,
Account, Checking, Savings, etc. that are related to each other. Together they describe important aspects of a banking business area or “domain.” Additionally classes have attributes (sometimes called properties or features) just like entities. So far these classes sound almost like entities. And they are. In conceptual modeling there are even relationships between classes similar to those in an entity relationship diagram.
ne day you arrive at work to begin your new project and learn that your company has adopted a new standard – all documents must follow the UML/ object-oriented (OO) approach. Your project manager asks you to begin working with your business stakeholders to develop a Conceptual Class Diagram. You have never heard of Class diagrams! You begin to get red-faced. The PM quickly chimes, “Don’t Panic! You already have expertise in modeling data requirements using Entity Relationship Diagrams (ERDs). You can leverage those skills to develop Class diagrams. You still have questions. What is a Conceptual Class diagram? “It is a type of Class Diagram that is developed with business stakeholders.” Can an ERD substitute for a Class Diagram? “Depends on the application but ERDs are not included in the UML.” Is a Conceptual Class diagram developed the same way as an ERD? “Similar information is captured on Conceptual models but their goals are different.” Do I need to do both? “Sometimes.” Is one better than the other? “Depends on the application.” Great start but the brief answers you receive just beg for more questions which can make the head of any Business Analyst spin, especially if you have never worked on an OO project. This article will discuss similarities and differences between ERDs and Conceptual Class Diagrams, some basic UML terminology, and help you get started naming conceptual classes so that your requirements don’t get “lost in translation.”
Visualize the real world consisting of many objects that are in some way related. When you identify these “kinds of things” like dogs, cats, automobiles, they are called classes. The actual things like “Cujo” (the dog I always feared), “Bella” (my cat) and Acura (my car) are examples of class instances or “objects.” You organize objects into groups or classes. Class is a general term used in UML to represent either business things or software things (design classes). Classes are the most important artifact in object oriented analysis. OO Conceptual Class Models are fairly high level and do not refer to software. They should not be confused with the Design Class Models created in later iterations by software architects. Design classes integrate data and processes. The processes in design classes 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 software objects. The idea is to start with “real-world” classes that could eventually be traced directly to objects in a software system.
Basic OO terminology Objects are examples of ideas or things – think of nouns or noun phrases. As the name suggests, object-oriented techniques are focused on finding, naming, and organizing different types of objects or classes that interact in the business area to be studied. This is a data-centric approach.
Conceptual Classes On your projects, conceptual classes, just like entities, will be the “things of significance” that must be further defined to gain a complete understanding of the business problem (and potential software solution). For example, a bank project would have classes such as: Customer,
O
11 Summer 2005 l the bridge
What is different? One difference in conceptual modeling is that you do not have to follow the strict rules of data modeling. To demonstrate this point, consider the banking example. You could add additional classes such as: Bank, ATM, and ATM card. These classes most likely would not be found in a logical data model. In data modeling, we do not identify entity types where there is only one instance of the entity, like the Bank. We also do not name physical things that should be part of the implementation, like an ATM card. Additionally in data modeling we define unique identifiers and foreign key attributes, but these concepts are not used in conceptual modeling. Another difference is that relationships or associations used in class diagrams can show much more complex relationships (associations) than typical data modeling. These links can be unidirectional or bidirectional. Relationship types include association, aggregation, and inheritance. Conceptual class diagrams are very much like entity relationship diagrams. One good reason to build a Conceptual model is so that the entire team can visualize and understand the important concepts or things in the business area before diving into the details of the application. Rather than focusing on what processes need to be performed we look at what things are significant to us. Having such a “real world” picture will assist the development team in future iterations to design cohesive software objects that
integrate data and processes and will provide the things the business needs. How to get started creating a Conceptual Class (Domain) model 1. People often begin the Conceptual Model after they have identified their Use Cases. 2. List the nouns or noun phrases (often found in your Use Cases) and describe the Entity Relationship Diagram real world Conceptual Class Diagram concepts that we care about. What for software applications. They also believe 5. Draw lines between classes for critical terms, ideas, and concepts does the that object oriented methods lead to better, associations. (It is more important to business use to describe their world? Be more secure software that is easier to find important concepts than aware that not all conceptual classes maintain and grow in the future. Before associations at this stage). become part of the final system. using the Conceptual Class modeling 6. Refine the model as needed to capture 3. Draw rectangles that are split in two technique, or any other new UML only the relevant information in the parts to represent each conceptual class. technique, you should consider what you scope of the project or iteration of the Put the names of the classes in the top are trying to achieve, if the technique is project. part and list any important attributes in appropriate for your audience, and if the the bottom. Exclude any implementation deliverable adds value to your project. If Summary details. not, choose one that does. n As you can see, much of what you already 4. Add only attributes necessary to fulfill the know about creating ERDs will be useful information requirements. Review each Sign up for B2T Trainingâ&#x20AC;&#x2122;s new course UML when you create Conceptual Class Use Case and look at which data elements for the Business Analyst if you want to know diagrams. OO evangelists believe that will need to be held for later retrieval (i.e. more about creating Conceptual Class looking at the world in terms of objects is a the date or time of a transaction). Not all Models. For any additional comments about more natural way to organize information classes need attributes. this article email aperris@b2ttraining.com.
Answers to Brain Teaser puzzle on page 9
Submit an article to the bridge! Each issue of the bridge focuses on a particular area of interest within business analysis. Articles relevant to the topic area are preferred; however, any articles about best practices, project success stories, BA resources (books or tools) will also be considered. We will post submission deadlines for each issue so keep an eye on our website. To submit an article send an email to sales@b2ttraining.com.
the bridge l Summer 2005 12
3 Days
new course UML for the Business Analyst This course is designed for Business Analysts who need a working knowledge of UML and OO development to facilitate communication with their technology team members. Most new software development projects are using OO programming. If the Business Analyst can present requirements to the developers in a manner consistent with their design deliverables, software design and development time can be decreased and software quality increased.
Intended Audience This course is intended for experienced Business Analysts who want to learn how they can use UML/OO techniques. Prerequisites Students must have attended Essential Skills for the Business Analyst (or have equivalent experience) before attending this class.
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
t
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.com
13 Summer 2005 l the bridge
certified core courses Essential Skills for the Business Analyst
4 Days
This course covers the critical skills for the Business Analyst. Students will learn to define what is, and what is not included in the project, how to ask the right questions, when and how to hold interviews and facilitated sessions, how to write excellent requirements, how to verify that requirements are testable, how to conduct a requirements review, and have an overview of various application development methodologies. Additionally, students will be introduced to various documentation techniques and plan an approach for documentation.
3 Days Detailing Business Data Requirements The Data portion of the business requirements is a critical component to defining complete requirements. Every process uses data and almost all business rules are enforced by data. Missing a critical piece of data or incorrectly defining a data element contributes to the majority of maintenance problems and results in systems that do not reflect the business needs. This course teaches students an in-depth approach to identify and define all necessary data components using both textual templates and an entity relationship diagram to create a data model.
4 Days Detailing Process and Business Rule Requirements
t
This course continues the development of the requirements package by defining the processes and business rules for the project. Students will learn to identify and define the processes from a business and functional perspective. Various techniques are taught including decomposition diagrams, templates, workflow models, and Use Case diagrams and descriptions. Additionally, this course teaches techniques to ensure that requirements have not been missed.
More detailed outlines are available on our website, www.b2ttraining.com
the bridge l Summer 2005 16
additional course offerings Requirements Testing for the Business Analyst
3 Days
This course provides an excellent foundation for Business Analysts to achieve best practices in software quality assurance (SQA). The course will improve the Business Analyst's development of requirements so that they can be used to build quality test cases. It will also enable the Business Analyst to create specific test cases from the requirements. The course includes a workshop case study that provides a cohesive learning experience.
Overview of Business Analysis
4 Hour Seminar
This seminar presents the Business Analyst role to managers and others who lead and work with Business Analysts. In order for the Business Analyst to be successful, both the IT and business community must embrace the business analysis process. The seminar can be used as a working session to discuss how your organization will implement the business analysis process and approaches for documenting the requirements.
Advanced Business Analysis Workshop
3 Days
t
Business Analysts are constantly striving to improve their skills and increase the quality of their project requirements by learning advanced requirements gathering techniques. This course enhances the efficiency and effectiveness of Business Analysts by giving them additional techniques and strategies for gathering, documenting, and reviewing requirements. Techniques such as advanced data definition, traceability, and gap analysis help BAs to document more accurate and complete requirements. The course also presents the concept of Requirements Management and requirement reuse. Implementing a requirements management process into your organization can significantly reduce the time required to make software changes and develop software interfaces.
For more information on these courses visit www.b2ttraining.com
17 Summer 2005 l the bridge
2005 public class schedule Essential 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 sales@B2Ttraining.com
B2T Training 11795 Northfall Lane, Suite 601 Alpharetta, GA 30004
Prsrt Std U.S. Postage PAID Permit #309 Knoxville, TN