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

When I joined the BABOK committee about a year later and raised these concerns, I was asked an insightful question: “Elizabeth,” one of the committee members asked, “as a PM did you come up with all the deliverables, tasks, and estimates for everyone on the project?” Ah, BAs sure do ask good questions! I remembered that as a PM I had gone to many team members, in particular technical SMEs, the developers, our full-time business SME on the project, and others to get their deliverables, tasks, estimates, and availability. But it had never occurred to me to involve the BA. With that one question the light bulb came on. The image of locked horns disappeared. In its place I saw a PM (me) with the weight of too much project planning on her shoulders suddenly stand up straight and unencumbered. How much easier my life as a PM would have been if for the business analysis work, I had taken the information from the BA and rolled it into the overall project. What a relief it would have been to get the business analysis input from the person who knew the most about business analysis!

With the light bulb came a few related insights:

1. Planning doesn’t mean doing all the work yourself, so PMs don’t have to complete all the planning processes listed in the PMBOK® Guide themselves. PMs need to ensure that all the work appropriate to the project is done, but that does not mean that the work in Section 5.1, Collect Requirements, for example, must be completed by the PM. 
2. BAs are closer to the business analysis effort, so input from BAs is apt to be more complete and correct. When competent BAs are on the project, PMs do not need to micromanage business analysis. There’s enough for PMs to do, so getting out of the way during business analysis will likely reduce the PM’s stress. PMs, so focused on delivering on time and within budget, need to realize that PMs and BAs working collaboratively get more done, so the project has a better chance of completing sooner. 
3. On large projects, both the PM and BA have full-time work doing project management and business analysis respectively. If either is saddled with doing the work of the other, both will be overburdened, increasing everyone’s pressure and stress levels. Under such circumstances, resolving the inevitable territorial conflict will be that much more difficult and take that much more time, delaying the project even further.

So my advice, PMs, is to let the BAs do business analysis work, which includes business analysis planning. My advice, BAs, if confronted with a PM who wants to plan for the entire project, is to keep asking those insightful questions!

Who Should Plan the Business Analysis Work? was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog

Many times a problem we’re trying to solve or something we are analyzing is like that.

• How often do you forget the name of something when you try to recall it, only to remember it later while walking outside, or when you are in the shower?
• Or, the solution to a nagging problem suddenly pops into your head when you are working on something else?

These mental phenomena are very similar to the parallax effect. I’m sure there is a scientific name for it, but my psychology classes are only distant memories. I’ve noticed this same experience in business analysis countless times and informally call this the “parallax effect on requirements.”

The main way I’ve observed the parallax effect on projects is by focusing on too few methods to elicit and analyze requirements. For countless reasons, overworked business analysts may rely on one main method for eliciting requirements – such as interviews or requirements workshops. Then, to keep on schedule, BAs will use one primary method to analyze and document the discovered requirements. Swim lane diagrams and use case models come to mind here.

That is when the parallax effect strikes. Bam! You get stuck on a thorny issue like resolving an alternate path of a use case. You may resort to more interviews to solve it, but both struggling with the use case and re-interviewing are like staring at that star. The solution starts fading and disappearing.

So, what is the equivalent to diverting your gaze from the star so you can see it? How can you keep the problem in focus without over-focusing on it? The most practical way I’ve learned is to use a coordinated set of models to view the problem from multiple angles. You don’t need to use 27 models to do this – four categories will do. All software applications have the following four types of functional requirements in varying degrees:

1. Business Process – current and future states of the business processes affected by the solution being built. Business Process models set the context for and are the foundation for every other type of requirement.
2. Interaction – show how users will interact with a new system, and include scenarios, use cases and user stories as primary methods.
3. User Interface – an extension of the interaction requirements, these requirements uncover additional data that is input to or output from a system. Prototypes are excellent ways of drawing out user interface requirements.
4. Data – the data needed to support a business process and/or is input or output during the interaction with a system, and/ or appears on user interfaces. Data models, such as Entity-Relationship Diagrams and Class models are typical types of models that help here.

Concurrent Requirements Modeling is what we call the use of complementary modeling techniques to quickly and completely analyze functional requirements. Using these four categories of models provides a complete, well-rounded set of functional requirements. That’s a huge benefit in and of itself, and it also saves time and frustration by combating the parallax effect.

Let me give you a quick example. During a workshop a student team was working on a use case and got stuck on what happened during an error situation. Their first reaction was to ask the “customer” (me, during a role-play) what they wanted. When that didn’t work, they sketched out an activity diagram of the process and a rough prototype. The team got out of their use case rut, and were able to ask pointed questions about the business process and interface. They got most of what they needed to complete their use case alternate path. The data model would have supplied a few more missing pieces. But, by moving their analysis to other models, the team looked away from the “star” and were able to “see” the problem and solution more clearly.

So, the next time you stare too long at a problem and lose sight of it, maybe the parallax effect is at work. Try looking away by utilizing complementary techniques, and the problem may well come into focus.

The Parallax Effect on Requirements Analysis was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog