Business Analysis Modeling Boot-Camp Training Course

3 days.

20 Immediate Benefits of Participating in this Workshop:

1. Learn the essential core features of UML (Unified Modeling Language) and BPMN (Business Process Modeling Notation) useful for expressing business problems
2. Use models to develop a consistent vocabulary for a project or enterprise
3. Create models in multiple dimensions in order to identify a complete set of activities
4. Make sure a solution fits into a larger business context
5. Design a consistent user interface based upon models
6. Create system designs that can be implemented in various technologies and heterogeneous architectures
7. Model the lifecycles of objects that participate in several business processes
8. Use state models to exploit the natural concurrency in a problem—essential for today's web and cloud-based architectures
9. Create accurate business process models that unambiguously convey the details of a business process
10. See how business process models are connected to each other in the same domain and different domains
11. Learn how to use overview models to summarize and provide "big picture" views
12. Learn a technique for partitioning a problem by distinct subject matters (domains) that eliminates the ambiguity and arbitrariness of traditional decomposition approaches
13. See how there is not one single system "architecture" but that a system comprises several distinct architectural views
14. Understand the value of developing platform-independent models
15. Learn how to develop models incrementally in a way that facilitates agile development
16. Express properties of a business entity as attributes and relationships to other entities
17. Formalize business rules in models
18. Trace requirements to model elements
19. Learn simulation techniques for testing models against requirements
20. See how modeling results in more comprehensive analysis that enables you to develop a deep, balanced, and complete understanding of your problem

Anyone involved in requirements elicitation or business analysis will benefit from this class. This course is perfect for:

• Business or Systems Analysts
• Architects or Developers
• QA Testers or QA Engineers
• Business Customer or Partners
• Product Managers or Customer Representatives
• Project Managers or Team Leaders
• IT Managers/Directors

IIBA 21 CDUs | PMI 21 PDUs

Section 1. Why Model?

There's more to a BA's job than just gathering requirements. This section presents the purpose of the course and introduces the idea that succinct graphical models with defined semantics can be a powerful and efficient way to represent requirements and design solutions—much more powerful, much more efficient, and certainly more precise than words alone.

Section 2. Method Overview

This section provides a roadmap of the five basic models – Process Model, Information Model, State Model, Collaboration Model, Authorization Model, three derived supplementary models (Context Diagram, Sequence Diagrams, and Views), and the relationships between them. Each model represents certain specific concepts, and the concepts in one model are related to concepts in other models. The roadmap introduced in this section will be followed throughout the course to present each of the models and the relationships between them.

Section 3. Use Cases and Scenarios

One way to approach a system is to model the functional behavior of that system. Use cases provide a way to organize and to present system behavior from the perspective of the various participants and stakeholders. This section reviews the key components of a use case, how to create scenarios for different alternative flows, and how to define the pre-and post-conditions of a use case and each of the steps in that use case. Business, system, and implementation behavior are defined in terms of different use case "levels." Far from being an arbitrary organization, each of the different levels represents specific purposes. This section addresses how different use case "levels" represent specific kinds of analysis. 

Section 4. Process Modeling Basics

Process models (sometimes called business process models) graphically represent key components of use cases and allow them to be organized into distinct scenarios. Done properly, process modeling identifies key business entities, the different stages in their lifecycles, and the activities that progress these entities through their lifecycles. Because they are graphical models with defined semantics, process models can be more precise than text alone, thereby enabling modelers to create more accurate and more complete use cases.

Section 5. Process Descriptions & Activity Tabulation

While graphical models provide the structure for the concepts in a domain, each of the elements in the models require additional information beyond what appears on the diagrams. In this chapter, participants learn how to describe process models and each of the elements in the models. A large domain often involves a number of different business processes, each with their own process models. Often the same activities appear on several different models. While these different process models provide different contexts, the activities are the same activities regardless of where they appear. This section presents some techniques for organizing and classifying activities by who performs the activity and the contexts under which the activity occurs.

Section 6. Decisions and Alternatives

Simple process models present a straightforward flow of control from beginning to end. Real business processes, however, often involve several points in which decisions are made and alternatives can be taken. This section presents the method for describing alternative flows in a process model and how different scenarios of the same use case may be illustrated using several different diagrams or one single diagram.

Section 7. Concurrency

Real business processes often involve several things happening at once. Process models can and should describe real-world concurrency and exploit opportunities for parallel behavior. This section presents the notations used for describing concurrent activities; how a single activity or condition may start parallel flows, and how to ensure that several parallel activities have all completed.

Section 8. Time

In business processes, some activities may be initiated by the actions of people, organizations or systems. Others, however, are initiated "by the clock," either at specific times (such as a monthly payroll) or after a certain duration. This section shows how to include time-related events and to coordinate activities based on time.

Section 9. Introducing Information Models

Another way to approach a system is to model the business entities, their properties, and the relationships between these entities. An information model, represented as a UML class diagram, provides a unified view of a domain where each term and concept is precisely defined. This section presents how to construct a platform-independent information model that not only grounds the entire set of domain models, but is also a useful basis for the creation of relational and hierarchical data models, object-oriented class structures, user interface designs, and messaging schemas.

Section 10. Relationships: Association & Composition

Just as the things in the real world are related to each other, the classes in an Information Model are connected by several different kinds of relationships. This section explores two of the most basic kinds of relationships: composition, in which one thing is a part of another, and association, in which two things share some other kind of meaningful connection.

Section 11. Attribute Rules

Attributes represent the individual characteristics of a business object. In creating an information model, the analyst should create a set of attributes that are complete, independent, and distinct facts. Finding a good set of attributes is similar to the data modeling concept of "normalization," but is focused upon describing the business problem. Often real-world objects include "derived" characteristics that are based upon other characteristics. This section presents some rules for how to find a good set of attributes, how to find "derived attributes," and how to test attributes for correctness and completeness.

Section 12. Attribute Types

Every attribute has a set of legal values known as the attribute's type. Describing attributes' types can be one of the most valuable detailed analysis activities, as this information is required to correctly create many different implementation artifacts, from database and message schemas to user interface controls. This section presents a scheme for describing various kinds of attribute types: numeric values, symbolic values, and structured values among others.

Section 13. Specialization

In an information model, a class represents a set of things that share common characteristics and common behavior. Real-world problems often involve situations in which some things are common and some things are different. This section presents techniques for dealing with these problems: role specialization, in which one group of objects shares common properties with a larger group, and subclassing, in which a group can be divided into different subsets, each with different properties.

Section 14. Information Descriptions

Just as the elements of a process model require descriptions, classes, attributes, and associations must also be described in detail in order for the readers of a model to clearly understand the concepts presented in the model. The process of writing good descriptions also helps to expose issues in the models and to clarify thinking among the analysts and other stakeholders in the analysis process.

Section 15. Finding Classes

The process of building an Information Model—whether it happens before, during or after use case analysis—involves identifying, classifying, and organizing the conceptual entities in a domain. This section describes different kinds of classes and how to find examples of each kind in a domain, and presents the "object blitz"—a simple yet powerful brainstorming technique for finding classes and starting to build an information model. 

Section 16. Views

While an Information Model organizes the facts in a domain into a series of normalized classes and relationships, real presentation forms (such as messages, user interface screens and reports) often involve information that spans several related classes. This section introduces a technique for describing such distinct views in a way that relates the contents of each view to the Information Model, thereby ensuring great consistency among all views and the core Information Model.

Section 17. Authorization Models

Process Models describe what happens in a business process and information models describe the facts in a problem. Although the process models say which actors perform which activities, they do not necessarily enumerate all system activities, nor do they describe important constraints on the performance of those activities. Authorization Models augment the standard use case diagrams with permission constraints that specify exactly the conditions under which different actors can perform different activities.

Section 18. Lifecycle Basics

Every object defined on the Information Model has a lifecycle: a series of stages through which the object progresses over time. Some lifecycles are trivial—"created" and "deleted," for instance, but others are significantly more sophisticated. State models are used to represent these more interesting lifecycles. This section presents the concept of a lifecycle and shows how to construct state models that represent an object's states and the events that cause progression from one state to another. It also powerfully shows the interconnections between the elements in the various analysis models.

Section 19. Coordinated State Models

Complex system behavior can be modeled simply as coordinated state models. This section shows how to create a collaboration model to summarize existing state models as well as how to use the collaboration model to plan system dynamics prior to building state models. Such models and techniques allow analysts to simplify and organize complex system behavior.

Section 20. Finding More Activities

Not all of the activities in a domain are necessarily found by building process models. There are many activities that involve simple creating, updating, and deleting of various business entities, and not all of these activities appear on process models. This section shows how to read an information model to discover these additional activities, how to represent them on authorization models, and how these activities may be clues to additional process models.

Section 21. Model Verification by Simulation

The models presented in this course are formal and precise enough that they can be tested. In this section, analysts learn how to create test cases based upon the process models, to run these tests against the other models, and to use these test cases to create the actual system test cases.

Section 22. User Interfaces and Other Domains

Partitioning by subject matter yields platform-independent application models. For most business analysts, that means separating the "how" of the user interface design from the "what" of the application domain. So where do you put the UI steps that are typically presented as lower-level use cases? In this section, you'll learn how the same modeling techniques used for the application domain can be used to model a basic design for a consistent and robust user interface, and that by bridging the application to the user interface you can create the actual screen layout and flow in a manner that remains consistent with the application models.

Section 23. The Process of Analysis

Any modeling activity exists within the context of a larger process. While this course is emphatically not intended to prescribe a particular process, there are certain factors that are important to modeling and analysis success. This section describes several factors important to the success of a modeling effort. Participants are encouraged to discuss what they have learned so far and which activities are most important for them to achieve success.

Section 24. Designing & Implementing from Models

Models are great, but how do models become systems? How do enterprises use models to manage consistency across multiple projects? This section presents approaches to software and system architectures that take advantage of the many distinct architectural views, shows how those views can also be modeled, and how those architectural models can be used to translate the analysts' business models into working systems.