Modeling Techniques for Business Analysts Virtual Classroom Live December 14, 2021

Course Overview

 

Part 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.

• Reading Simple Models
• Analysis vs. Design Models
• Functional Decomposition and its Alternatives
• Improving Upon "High Level" and "Low Level"

Part 2: 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.

• Identifying Actors and Activities
• BPMN and UML Swim Lanes Activity Diagrams
• Data Flow Analysis
• Specifying Alternate Scenarios
• Systems As Actors
• Summarizing Process Models

Part 3: User Interface Modeling

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.

• Documenting UI Behavior
• Translating Use Cases and Text into Models
• UI Navigation Flows
• Compound Navigation
• Page and Report Data Modeling

Part 4: Information Modeling

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.

• Finding Information
• Information Model Basics
• Computations and Derived Attributes
• Hierarchical Data Views

Part 5: Lifecycle Modeling

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.

• Object Lifecycles
• CRUD Analysis
• State Transition Diagrams
• State Transition Tables

Part 6: Advanced Process Modeling

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. Other activities may be initiated by the actions of people, organizations or systems; initiated "by the clock" or after a certain duration. This section presents the notations used for describing concurrent activities and time-related events.

• Decisions by Business Rules
• Concurrency
• Time-Based Behavior
• Reminders and Escalations

Part 7: Complex Information Modeling Techniques

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.

• Specialization and Generalization
• Roles and Inheritance
• Data Normalization and De-Normalization

Part 8: Coordinated Modeling Techniques

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.

• Object Collaboration
• State Models and Business Process Models
• Race Conditions

Part 9: Course Summary

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.

Hands-On Exercises

Real training means real-world practice—learning by doing. Through these exercises participants learn how to put requirements into forms directly usable by software designers and testers, and to use the modeling process to identify and to elicit missing requirements. Some of the many exercises include:

• Read models and identify missing requirements: Even before learning the details of how to write models, compare simple process and information models to textual requirements in order to identify seeming discrepancies between the models.
• Combine several business scenarios into a single process model: See how a simple graphical notation can represent several alternative scenarios that would be quite difficult to express in text alone.
• Translate use case text into process and UI flow models: Separate the steps of the business problem from the details of how a user carries out steps on a particular user interface. Create "platform-independent" models that can be implemented on a number of different technologies (web, smartphone, etc.) while maintaining a common look and feel across those platforms.
• Examine process models, UI flow models, and use cases to identify data requirements: Gather data requirements by identifying messages and data flows, UI displays, and input forms. Use an "object blitz" and concept mapping to identify other data.
• Organize data requirements into a common information model: Create UML class diagrams and entity-relationship diagrams to represent the common data in a domain. Understand when to abstract properties as attributes and when to create relationships between objects.
• Identify computations and constraints on data: Define computed properties that represent simple and complex calculations. Specify constraints on and between data values.
• Add time-dependent behavior to process models: Specify processes that depend upon time for their initiation and performance. Model situations in which reminders need to be sent or activities need to be escalated to other people or groups in the business.
• Use a new take on "CRUD" analysis to find essential but often overlooked activities: Walk around the information model to ensure that all necessary activities—not just those identified in the use cases and process models—are modeled and included in the project requirements and plans.
• Examine models to identify difficult and tricky concurrency issues ("race conditions"): Some requirements may sound easy and desirable but may hide nasty surprises. Learn to identify a pattern that can signal a need for more detailed and judicious analysis.