And what did 2011 bring us in the world we live in?  In no particular order:

• The deaths of Kim Jong Il, Moammar Gadhafi and Osama Bin Laden.

• The marriage of a Prince and his Princess in Kate and William.

• Another singer added to the “27 club” RIP Amy Winehouse.

• The courtroom drama of the year with Casey Anthony.

• Katy Perry ties Michael Jackson’s record for most number 1’s on one album.

• The record 9.0 magnitude earthquake and subsequent tsunami and tragedy in Japan.

• Two new American Idol judges who ended up more popular than Simon Cowell’s big brag the X Factor

• The “Arab Spring” with uprisings for freedom in Tunisia, Egypt, Bahrain, Syria and Libya.

• New tech gadgets changing how we live including an iPhone that talks to you.

• Occupy Wall Street.

• The end of an era including the space shuttle program, Oprah Winfrey, Borders Books, Harry Potter, Steve Jobs and the Iraq withdrawal.

• Grave predictions from the Mayan calendar for 2012.

But what of Business Analysis and the world we work in for 2011 you say?  Again, in no particular order:

• More and more companies get on the Agile bandwagon and we will explore this quite a bit in 2012.

• A very successful Building Business Capabilities conference in Ft. Lauderdale, FL (I was there – where were you?) Oh, and the theme in 2012 is Creating the Agile Enterprise.

• I saw companies changing the way they think about requirements, adapting to the changes that mobile devices (smart phones and tablets) are making in our companies and everyday lives.

• Several successful IIBA Business Analysis Development Day conferences in Minneapolis, Des Moines, Cincy, Omaha (I was there speaking at all of them – where were you? Lol).

• I saw a disturbing trend of people pushing the BA out of the Agile process (a trend we will reverse in 2012 with some good education!).

• Watermark Learning won the PMI Product of the Year Award for their new Project R.E.A.L. class (developed by someone you might know as BobtheBA. Lol, I just had to add that last part you know…). Real experience, applied learning. A new way of looking at training.

• I saw another disturbing trend of companies using workshops as their only method of eliciting requirements (another trend to reverse).

• More companies recognizing the value of the BA and investing in training (which will help reverse those previously mentioned disturbing trends).

• I saw the development of Business Architecture Forums and Enterprise Analysis rising up with a focus on good business cases (a trend that will continue).

• I worked with and saw so many people really take control of their careers this year – people that wanted to become BAs or just improve their careers and did despite the odds because they had passion, drive and understood that they needed to be leaders in their domain. Congrats people, congrats. You know who you are so now go inspire others to greatness as well!

Well, that is just a few of the things that 2011 brought us. Certainly I could go on and on and on. What did you see that we should not forget about 2011? Please feel free to share with everyone! Do you know what you are going to do in 2012? In my next blog I will chat about what 2012 has in store for us and talk a bit about how to sustain that promise of change in the New Year.

2011 BobtheBA and A Quick Look Back was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog

The close of one year tends to make one reflect on what has occurred in the past year and ponder the future. Here we ponder some trends in the Project Management and Business Analysis fields for 2012. Here are our top seven predictions for business analysts (BAs) and project managers (PMs) in 2012.

1. Divergence of the PM and BA Role. In 2009 we predicted that as the economy tightened, organizations would decrease their project budgets and combine the role of PM and BA. For 2012 we believe that organizations will see the need for both roles, particularly on strategic projects, and move away from a combined role. There are several factors for this trend:

• Business analysis is maturing as a profession. As the IIBA has gained traction, more organizations have become aware of the BA role and its importance. From 2010 to 2011 the number of IIBA members increased about 50%.
• Organizations have found that even with successful project management, many projects fail because of dissatisfaction with the end product. Having business analysts helps ensure that the product is a solution that works and is one the organization needs.
• PMI has recognized the importance of the business analyst role. In 2010 they undertook a study to determine areas of overlap, handoffs, and how the two roles could collaborate.

2. Combined Agile methods. We predict that Agile methods will continue to change and merge as organizations take advantage of the benefits of Agile. In our 2009 Trends blog we stated that “Integrating Agile methods into project management and business analysis is a trend that will continue in 2009. Currently, the industry has a wide, varied, and inconsistent use of Agile techniques. This trend is likely to continue.”

 In the two years since we wrote that article, Agile methods have continued to evolve. Although organizations have widely adopted Scrum as the predominant Agile method, they still struggle with its implementation. We think that organizations will continue to adopt Agile methods, but that these methods will continue to evolve. Combined techniques, such as Scrum-ban (which combines Scrum with the Lean technique Kanban) or Scrumerfall (a combination of Scrum and Waterfall) will be adopted for different kinds of projects.

 3. PM and BA on Agile projects. We predict that the role of the BA and PM on Agile projects will solidify. When Agile started to be adopted, some organizations thought that the roles of PM and BA were obsolete. However, more and more organizations have recognized that the need for both roles, even if the titles are new. The Scrum Master role is best filled by someone with the expertise to coordinate the initiating, planning, executing, monitoring, & controlling, and closing each iteration and release. In other words, the work typically done by a PM. The designations of Certified Scrum Master (CSM) from the Scrum Alliance and Agile Certified Professional (ACP) from PMI have solidified this role.

 The role of the BA on an Agile project has not solidified. BAs are used in a variety of ways or not at all on Agile projects. There have been heated discussions on LinkedIn discussion groups and at conferences about this role. While many organizations use BAs in the product owner role, the fundamental issue of the product owner having to make business decisions makes this problematic. Going against most of the current thinking, we predict that organizations will realize in the next few years that business analysis is essential to Agile projects. Agile projects still have requirements, and there is a need to go from high-level user stories to the detail needed to develop the needed functionality. Organizations will realize that this in-depth analysis cannot be completed during an iteration, that it has to happen just prior to development. This is called grooming the product backlog and is the perfect role for the business analyst.

 4. The BA as management consultant. We predict that in 2012 BAs will actually function as described in the BABOK® Guide, version 2.0. That is, more BAs will “recommend solutions that help the organization achieve its goals.” They will do that in a variety of ways:

• Business cases. More organizations will recognize that the BA is in the best position to develop business cases. Although often performed by PMs, this function happens prior to the initiation of a project and is input to project initiation (PMBOK® Guide – Fourth Edition). The PMBOK recognizes that the performing organization (business owner) is accountable for the business case, but it is the BA who is in the best position of developing it.
• Ability to Influence without Authority. We are seeing more organizations tell us that they want their BAs to move away from taking customer orders and start using their expertise to recommend solutions. This need correlates to the enthusiasm we have seen around the need to influence without authority.
• In her keynote at the BBC conference in Ft. Lauderdale last year, Kathleen Barrett, CEO of IIBA mentioned that one of the key competencies of the enterprise BA is management consulting.

5. BAs as change agents.We think that BAs will be more involved in change management. At the BBC conference in Ft. Lauderdale last year Kathleen Barret announced a new tag line for IIBA—that business analysis was about changing how organizations change. In other words, BAs will be more involved in change management. Changes might include changes in business processes, job descriptions, reporting structures, software, and more. Here are some of the ways we see this happening:

• Enterprise analysis. Before projects are initiated, BAs determine the business need across the enterprise and recommend solutions, which need to include the ways in which organizations will need to change when these solutions are implemented.
• Project work. While the identified at the enterprise level are by necessity high-level, the changes resulting from each project will be specific in nature. We predict that BAs will develop better tools for assessing whether or not the organization is ready for the change. We think that they will act as management consultants once the project has been defined to ease the pain associated with implementing the changes associated as with implementing the solution.
• Post-project follow-up.We believe that BAs will be called on to monitor the post-implementation changes and continue to consult with the organization on the best way to make the solution work, even when there is some organizational resistance to it.

 6. The virtual environment.Now that it is here, the virtual environment will continue to flourish, even if the economy improves. There are a variety of reasons why organizations will continue to rely on the virtual environment for completing projects, for training, and for webinars to replace live conferences.

• Travel budgets.Spurred by a sluggish world economy, many organizations have reduced travel budgets for team meetings, training, and international conferences, relying instead on the virtual environment. Although colocation of teams is ideal and preferred, it is not always possible. More teams communicate and collaborate virtually, more virtual training will occur, and more webinars will take the place of live conferences.
• Globalization has made travel impractical. Although face-to-face time, particularly during project initiation, is helpful in building trust, respect, and relationships, it is not possible to be together for all project meetings and/or requirements elicitation interviews and workshops when the team is located across the county or world.
• Collaboration toolshave made the virtual environment not only possible, but practical. Net meetings, as well as more robust training and webinar tools have supported virtual teams, so that real work can be accomplished. In addition, teams have learned how to build relationships and trust in the virtual environment. Building relationships and trust in a virtual environment is easier and quicker once people accept and feel comfortable with the virtual tools available.

 7.  “The economy, stupid,” a past political slogan said. During a slumping economy, organizations look of ways to maximize efficiencies. Focus turns to business processes and how to improve and manage them. During more prosperous times, interest in business process management tends to wane. We predict that business process management, with an emphasis on eliminating waste in organizations, will continue throughout 2012, even as the economy (hopefully) shows signs of improvement. We also predict that there will be no dominant tools for managing processes and recommend that project professionals doing business process work focus on core concepts and skills and be flexible when it comes to using BPM tools.

7 Trends in Business Analysis and Project Management to Watch for in 2012 was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog

“Bah humbug!”  Well at least that is what it sounded like to me (BobtheBA) at the time, a few Christmases ago.  And all I could think of was “What a Scrooge!”  So what’s the story that brought out the worst in two people during the holiday season?  Well before I tell you this true story just know that this person and I are close friends and I do have permission to tell the story (we laugh about it a lot now).

I was working on a small project to make some minor enhancements to a website.  The requirements were simple so I did not do much other than write up some bullet points in a MS Word document in 20 point font, double sided.  So 2 pages of bullet point requirements in large print, easy to read, they were clear, concise, correct, necessary, testable, traceable and all of the other characteristics of well-written requirements.  I was feeling pretty good, they had been discussed, signed off on and I sent the requirements to the developer so they could crank them out and we would be on to the next phase.

Time goes by and I do not hear from the developer.  This was supposed to happen quickly so I was surprised.  I sent an email and received no response.  I went to talk to the developer and as I approached, the developer took the double-sided, well-written, large font requirements and pushed it toward me and said, “I don’t value reading” and they went back to looking at their computer screen.  What???  Really?  Bah humbug you say?  I did a double take and looked behind me thinking the comment could not really have been made to me not to mention the absurdity of not valuing reading.  Yet it was and this started a multi-hour argument (yes, argument and not debate or discussion) about the requirements.  This was not about the quality, lack of understanding or how they fit into the vision, but instead the argument was about the packaging of the requirements.  It was not what they wanted.  It was two pages!  What could they possibly want?

So in the heat of the moment I went there… again, how hard is it to read two pages in large font?  I accommodated their need of not wearing their glasses (hello… 20 point font).  Was I supposed to put them on CD so they could listen?  Did they want them in user story format?  Use cases?  What?  They wanted a matrix.  Let the argument continue.  “You can’t read two pages and you are angry because it was not in a matrix?  How hard is it to read two pages in large font?”  Scrooge!  “Bah humbug, do them again.”  Sigh, what a Scroogy McScroogerton.  This was certainly feeling like I was seeing nightmares with the Ghost of Christmas Future and not drinking the Milk of Human Kindness with the Ghost of Christmas Present.

So whose fault is it?  One side can argue that it is not hard to read two pages in large font.  For the good of the project just plough through quickly and get over it.  The other side can argue that it is the BAs responsibility to ensure the right format for the right audience regardless of project size and complexity.  Well, in this case it was my lack of vision.  In every case as a Business Analyst you need to consider your audience.  I did consider them but only from a historical perspective (past projects and behaviors).  Where I missed my opportunity was that I should have also asked them directly and confirmed my approach.  If they were in agreement with the approach then the two pages would have been fine.  However, if they had been asked they would have said they needed a “matrix” and that would have given me the boundaries for what I needed to do.

I have relayed this story many times and people end up on both sides of the fence.  Some say BobtheBA you should have asked.  Others say tell Scrooge to get over it.  What do you think?  Whatever you think and in whatever you do, I hope this Holiday season you will not have reason to be called Scrooge, call someone else Scrooge or just feel Scroogy in general.  Let’s all take the approach of the Ghost of Christmas Present and have a great Holiday season!

Scrooged! was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog

1. How else are you going to specify the details needed to turn a user story into useful code? Relying on developers to do that without use cases has three huge flaws. Skipping use case development is:
   1. Inefficient. Eliciting requirements at the same time as writing code is another way of saying you will do multi-tasking. Several studies have shown that people are less efficient when trying to multi-task. (See a 2009 study done by Stanford University for a recent example.) Why would eliciting requirements and creating software be any different? Doing analysis, design, and coding during a sprint is inefficient unless your scope is really small.
   2. Inadequate. We need to get to the right level of detail to avoid rework and to provide software that the business wants and can actually use. To think we can consistently jump from user story to functioning code without use cases is wishful thinking. True, experienced agile developers might be able to work with experienced product owners, but getting to the necessary level of detail is hard for most organizations. Most developers and testers benefit from the consistency of use cases to ensure a successful end-product. For more on the need for an appropriate level of detail, please see Karl Weigers’ article on how detailed to make requirements: http://bit.ly/sw7pS5.
   3. Incomplete. It takes the type of questioning and digging that business analysts are good at to uncover complete requirements. Again, use cases and their complementary modeling techniques of prototyping, data modeling, and process modeling are standard ways to ensure requirements are complete.  If teams are trying to cover all of these during a sprint, then they are not spending adequate time designing, building, and testing software.  These should be done while grooming the product backlog.
2. How do you know when you are done? One of the key concepts of Agile is knowing what “done” means before starting the development. One aspect of “done” is the boundaries of the delivered software. By using the concept of pre- and post-conditions that are inherent to use cases, we have a built-in device mechanism for knowing what the boundaries are, and helping know when the user story is complete.
3. How do you know the acceptance criteria? This is the other component of “done.” People who work with Agile and Scrum are fond of talking about the importance of acceptance criteria. I don’t disagree. What they don’t often tell you is how they come up with them. Techniques like use cases are the premier way we have found for determining and then specifying acceptance criteria. There is no better way today in the software industry. Good criteria take time, and another suggestion to convince people to spend time developing use cases is to tell them you are developing “acceptance cases.” We use that term to describe the lowest level of a use case. Instead of converting a detailed use case to an acceptance test, we recommend instead that you develop a first-level “discovery level” use case, then go straight for the acceptance case. It will be faster because you don’t have to do any conversion.

I plan to turn this into an article and show some examples based on the presentation. Check back for more on this topic!

=========

To learn more:

• Read the two links mentioned in the post.
• See our other articles on use case and requirements in http://www.watermarklearning.com/articles.php.
• Get practical training in use cases. Check out our course outline for details.

Why Spend Time on Use Cases in Agile Projects? was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog

In any interview process, the key to being successful is to be prepared. However, we often get caught up with the one thousand and one things we have going on and we do not prepare as well as we should or (cringe!) we even wing it. Besides preparing a list of questions, one of the things that I do when I go into an interview is to have my checklist that helps drive my process. I used to struggle with being prepared until I related my experience with that of the hostage negotiator. Guess what? They have to be very prepared and they have a checklist too. Let’s see what their checklist looks like and then translate into BA speak to see if we can be more successful!

The hostage negotiator arrives on the scene and goes through their checklist (Credit to “howstuffworks.com” and “Ed Grabianowski” for the hostage negotiation checklist steps):

All questions “Q” are from the Hostage Negotiator. All answers “A” are from the Business Analyst and how you might respond.

Q What has occurred?
A As a BA you need to know all about what has occurred and what has not. Make sure you dive deep and understand the reasons for the project, the issue and/or the reason for why you are interviewing. There is a reason that your interviewee is holding requirements hostage and being difficult. Get a good layout of the situation so that you can approach it from a stable point of view. A perceived unbalanced approach could enflame the situation more. You must understand the context of the problem you are trying to solve.

Q Who initiated the call?
A Stakeholder analysis – it is NOT just for PMs! Determine who is driving the project you are on and why. The sponsor is your friend and should be your biggest supporter. Know what they want and why. Do they have a relationship with your difficult stakeholder? They might be able to help.

Q Time of occurrence?
A Does time really matter? Absolutely. Why was this project pursued at this time? What are the impacts of doing this project now vs. later? When does it really need to be completed? How does the timeframe impact your difficult stakeholder? It will certainly impact the questions you might ask during your interview.

Q What is the nature of the surrounding scene?
A Do you understand the political landscape of your environment and how it impacts the project you are working on? What about how it impacts your difficult stakeholder?

Q Police injuries? Suspect injuries? Hostage injuries? Other injuries?
A What relationships have been damaged in this “hostage” crisis? Have people, processes, data or systems been impacted, cutoff or disallowed as a result of this requirements hostage crisis? Will there be future injuries?

Q What kind of contact has been made with the suspect? When?
A What contact have you made with your interviewee? Did you just email them and set up a meeting? How well do you know this person? Did you reach out to them as soon as you knew they were involved? After the kickoff? Not at all yet? How you answer this question may give you insight as to why they are being difficult.

Q Is the situation locked in?
A Rarely have I come across a situation that is truly locked in. You may feel that it is locked in but as you explore what it means to be a good Business Negotiator (or Hostage Analyst) you will find that you can affect the outcome in a positive fashion. Remember, your difficult stakeholder wants something and there is always hope of influencing them.

Q Where are the suspects located?
A Know the dynamics of team and business. Geographically dispersed? Teleconferences not working? You may need to travel to more effectively to deal with the situation.

Q Where are the hostages located?
A More than likely the requirements being held hostage are locked up in the stakeholder’s mind and are not documented anywhere. However, do not assume that this is totally true as you may have access to materials that you assumed did not exist. Ask – you just never know. Maybe they are being difficult because they expect you to do all the work of pouring through volume after volume of mind numbing facts.

Q Where are the non-hostages?
A What is the state of other requirements elicitation and documentation? Is there a bigger problem here or is it just the one person? Make sure you know what you have and what you do not. Maybe there is another crisis just around the corner.

Q Where are the suspect’s observation points?
A What powerbase does your stakeholder have? Will they only operate from their home-base (their cube/office, their floor, favorite conference room, working from home)? What are they doing when no one is talking to them? Do they only have rules for you?

Q What firearms, explosives, and chemicals could be used/located on the site?
A What could your stakeholder do to sabotage your efforts if their needs are not met? What tactics will they employ? Do they have access and power to do so?

Q What is the description/profile of the hostage taker?
A Key stakeholder analysis. Do you truly understand your stakeholder? WIIFM – what’s in it for me? Do you know what’s in it for them? Is their effort to hold these requirements hostage unintentional or a directed effort to prevent things from moving forward? Are they in favor (accepting) of what you are doing?

Q What is the offender affiliation/public support like?
A Do you know who they influence and who influences them? Do they have support or are they left on their own? If a decision is not made in their favor will it affect you?

Goodness, there is a lot to think about in interviewing difficult stakeholders and this was all from the eyes of a hostage negotiator! And this was just the prep piece – there is also the techniques of the hostage negotiator and more that we can be inspired by and innovate. I realized early on that preparing was difficult and it took a lot of work. I also learned that when I looked at things a little differently I could introduce something new into my process which is an act of innovation. The result? My innovation = better preparedness = more “hostages” (requirements) released = requirements trash turned into stakeholder treasure!

Turning Requirements Trash into Stakeholder Treasure – Part 2 was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog

The Art of War is a Chinese military treatise written by (or attributed to) Sun Tzu (not to be confused with my dog the Shih Tzu, who surprisingly is a pretty good strategist when it comes to dog treats management).  The premise of the Art of War was the importance of positioning an army based on the objective conditions in the physical environment with the subjective beliefs of the other “actors” in the environment.  Sun Tzu believed that strategy was not a series of lists that you worked through but instead making quick and appropriate responses to ever changing conditions.  Believe it or not fellow Business Analysts, we can learn a thing or two from Sun Tzu.  So is the business analysis requirements process like going to war?  Let’s take a look.

What are two things a Business Analyst must always navigate when eliciting requirements?  Stakeholders and the domain in question.  First, let’s consider our stakeholders (your “actors”) who naturally have a subjective view of the requirements.  It is all about them after all and it is their viewpoint of their specific needs (and in many cases wishes) that we must adjust to quickly in order to meet those needs.  Sounds like the Art of War so far…  Secondly, let’s consider the physical environment – the domain where we must remain objective.  We need facts.  Facts that we can use to meet the needs (not the wants).  This too is reminiscent of the Art of War.

What would Sun Tzu do in the following scenario?  Sun Tzu knew a storm was brewing and his sunny day was soon to be rained out.  The battle was looming.  Did he follow his checklist/plan without reacting to this objective change in the weather?  More likely Sun Tzu made a quick and appropriate response to the changing condition of the environment!  Now let’s say that there is dissension in the ranks because they disagree with the decision that Sun Tzu is making based on the weather.  Again, he will make a quick and appropriate response to the subjectivity that is going on with his “team”.  The result?  Victory!

Often I see BAs following a plan, checking off the tasks, cranking out the deliverables and not reacting to the conditions placed on the domain or the changes of their stakeholder’s views.  The idea that you must always follow the plan without fail can actually lose the battle for you in the long run!  So keep your eyes open.  Listen to your stakeholders, get the facts and be ready to make a quick and appropriate response.  Be flexible and adaptable.  Sun Tzu was a master strategist in the Art of War and now with some practice and maybe some training, you too can be a master strategist in the Art of the Business Analysis War.

The Art of Business Analysis War was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog

Here is one possible option you can try: notice everything. Okay, I know it sounds like a very tall order, if not downright impossible, but let me break it down for you. Early on in my business analysis career, I realized that I was not very good with details. Big picture yes, details no. When you consistently get questions like “What about this? What about that?” you know that your details are lacking and you are not achieving optimal results. Oh the shame, but I really did love being a business analyst, so I knew that I was going to have to get creative if I wanted greater success. I started to make it habit of noticing everything I could about everyone and my general environment. Why? Because I recognized that my ability to understand and manage my stakeholders actually increased my chances of not missing details.
So what kinds of things did I notice? What people wore, what they said, what they did not say, their body language, who they talked to, whom they did not talk to, new hairstyles, new cars, holidays, basically everything I could. How did I translate that into the details I needed? Take for example a very difficult stakeholder that I had to work with. They were not forthcoming with requirements, they were resistant to change, and they did not understand the role of the business analyst. Sound familiar? I started noticing who they talked to. I went and talked to those people to understand my stakeholder better. I was able to gain insight on why they were resistant to change. I noticed what the stakeholder had in their workspace. As a result I found out we had a shared interest in science fiction. It was the start of a beautiful friendship and a stakeholder relationship that over time blossomed into advocacy for the business analyst role, more thorough requirements definition, and ultimately business partners that saw greater value being delivered.
Will everything that you notice be of use? No, but you also never know when it might be useful. Do you have time to notice everything around you? I say it is foundational to your stakeholder relationship management, and you will achieve greater requirements success. So what have you noticed lately?

Notice Everything For Greater Success was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog

UC Diagram-Training Example

Since most people refer to these as use cases, that’s the name I’ll use. They are a great way to elicit, analyze, and model interaction requirements. Plus, they help generate related requirements for interfaces, data, process, and business rules.

I gave a use case training class last week, so it’s fresh in my mind. It also influenced me to put this explanation in question and answer form.

Q. What is a use case?

Use cases and scenarios describe functionality that describes how actors interact with a system. The system could theoretically be anything, but use cases most commonly are used with online or web applications. The term “use case” is often a short version of “use case narrative” or “use case flow of events” and is shown as an oval in a use case diagram as in the example above. They are written as text and divided into primary, alternate, and exception scenarios.

Q. What is an actor?

Actors interact directly with a system, and can be humans, systems, or event/time triggers. In a banking system, an actor might be a teller who enters banking transactions and a Customer Information System that supplies and maintains customer data. They are shown outside the use case diagram as stick figures or using an icon like in the example above.

Q. What are associations?

These show which use cases an actor can initiate and which actors a use case can access. The line between an actor and its associated use cases depict the associations. The BABOK® uses the term association for this concept, and another common term for this is interface.

Q. What is a scenario?

A scenario is one path or flow through a use case. Typically a use case has a primary scenario, one or more alternate scenarios, and possibly exception scenarios. For example, a bank transaction might be completed using a customer’s account number (primary path), using the Customer Information system to look up the account number (alternate), or be cancelled (perhaps due to not locating the account number). One of my favorite ways to summarize use cases to my students is they are a collection of related scenarios in the accomplishment of a goal.

Q. What is a use case model and what are its components?

A use case model contains the use case diagram and the text scenarios and flows.

Q. What does the BABOK view as the specialized relationships in use cases?

There are two specialized use case relationships described in the BABOK. There is a third (and useful) relationship that the BABOK does not describe, but I listed it below for completeness.

1. Extend- documents the place in a use case to add future extended functionality, like an alternate path in a separate use case. “Search Name Phonetically” is an example below of an extend relationship.
2. Include – provides access to shared functionality in a separate use case. The common functionality is housed in a separate use case and is “included” by one or more use cases that share the same functionality. In the banking example, looking up customers by name is a common function that would likely be in an included use case, such as “Locate Customer” below.
3. Generalization –separates the general interaction steps from specific detailed steps for use cases that have a Parent-Child sub-type structure. In the following example, there is a generic Transaction entity with a use case of “Make Transaction” that has sub-use cases of “Make Deposit,” “Make Withdrawal,” and “Make Loan Payment.” Actors can be generalized as well. (This is an accepted and useful relationship that was included in BABOK® version 1.6. I would like to see it added back to BABOK® version 3.)

To sum up, Use Cases are an important and widely used technique for capturing interaction requirements. They provide a structured means to uncover many hidden and detailed requirements, and they can lead to related interface and data requirements. Because of their importance in the industry, expect to be tested on them in the CBAP exam.

LEARN MORE: For more information, read our article on Use Cases called Demystifying Use Case Modeling. It requires a simple one-time registration for you to access it. Once registered, you can read dozens of other interesting article on business analysis and project management. A good, basic book on Use Cases I recommend is called Applying Use Cases, Second Edition, by Geri Schneider and Jason Winters, ISBN 0-201-30891-5. We also teach a practical, concise training course on Use Case Modeling to learn this technique in-depth.

Scenarios and Use Cases – Useful Techniques was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog

The impetus for this blog comes from having just taught a successful training class in Data Modeling to a mixed group of BAs, BI specialists, technical architects, and business SMEs (subject matter experts). What made it successful was not only the learning that took place, but also the students’ willingness and eagerness to apply this technique back on their jobs.

I’ve been doing and teaching data modeling for as long as any business analysis technique. Many organizations I encounter think of data modeling as being technical and not BA work. Of course I feel differently, and have long viewed logical data modeling as business analyst work. The IIBA® agrees by including this technique in the BABOK.

Regardless of how you or your organization categorize Data Modeling (DM), you need to be prepared to answer questions on it for the CBAP exam. Here is a short over view of some Dm essentials:

• Data models capture the static data requirements of an organization for its ongoing business operations and decision support. It does that by defining and structuring entities, relationships between the entities, and adding detailed attributes into the entities. There is usually ancillary documentation you need to include that doesn’t fit strictly into the model. Two major styles of data models are entity-relationship diagrams (ERDs) and class diagrams.
• Concepts. Entities are the basic building block of a data model. The BABOK goes a little abstract on us by categorizing these as “concepts.” No one I know of except a textbook refers to entities or classes as concepts. The BABOK does it because an entity could also be represented by a class if you are using UML (Unified Modeling Language). In short, a concept is an entity or class depending on the DM style employed, and the term may appear on an exam question. I’ll use the term “concept” interchangeably with entity and class.
• Entities/Classes represent the people, places, things, processes, or events within the business. They have multiple instances that turn into rows in a relational database, and attributes, which become columns or fields in a database.
• Relationships are significant business connections or associations between “concepts” (there – I used the term). Relationships can be “one-to-one,” “one-to-many,” or “many-to-many.” The BOK uses the term “cardinality” to refer to the number of entity elements that are associated, namely one or many. Relationships may also be categorized by being optional or mandatory, such as “zero or one” or “at least one.”
• Attributes are the detailed facts about the “concept.” An ERD or class diagram typically lists the attribute name, relying on ancillary documentation for specifying domain ranges, the type of data an attribute can hold, and the definition of each attribute.

Here is an example data model, illustrating the terms above, and highlighting the four types of cardinality. Don’t be surprised on the CBAP exam if you are asked to interpret a diagram such as this. That type of question demonstrates the application of a technique, not just understanding the terminology.

Data Modeling is an important requirements analysis technique, and one you are likely to be tested on. Make sure you understand this technique for the exam, and then work at applying Data Modeling on the job. I plan to blog about that in the future – after I finish all the BABOK techniques!

Data Modeling – Why is that Technique in the BABOK? was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog

I have always thought of business analysis as the most ambiguous and the most fun of the project phases. However, for many years it was my least favorite phase to estimate. I felt like I was guessing, simply pulling numbers out of the air. As a business analyst I thought it was project management work. No wonder we were so far off.

Estimating the business analysis phase(s) is not easy. It is not hard, but it takes a willingness to think about exactly what work will be produced, and many business analysts do not have the patience.  So for those of you who do not have the “stomach” to spend the required time to estimate business analysis, here are four tips.

1. Break the effort into manageable pieces. We can estimate a whole lot better when our business analysis phase(s) are small. It’s easier to estimate a user story than an epic story, or one specific business process than business process modeling in general.
2. Choose your approach. We’ll estimate differently if we’re using a plan-driven approach (Waterfall) than if we’re estimating in a change-driven (Agile) environment.
3. Use a variety of estimating techniques. On many projects we cannot be precise about our estimates when we’re first asked how long business analysis will take. We usually use analogous estimating, or experience with a previous project. If we have good history, we might be able to use parametric estimates. For example, if we know that it takes four hours to model a business process and we have five processes to model, it will take twenty hours to model business processes.
4. Brainstorm.  Talk with the people who are actually going to do the work. They usually have a more realistic idea of what needs to be done and how long it will take. I also like yellow sticky notes, since they can be easily added, taken away, and moved.
5. Identify all the deliverables/artifacts.  Make sure you know your deliverables before attempting to identify the tasks needed to produce them.  Here are a few examples of deliverables: user stories, agendas and minutes, “as-is” business process model, traceability matrix, to name a few.

Of course the real, real key is having the courage to communicate bad news. Which brings me back to the president pounding his fist. What I should have done was communicate our status regularly, rather than surprising him after months of effort. What a lesson learned!

Five Tips for Estimating Requirements was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog