This course runs for a duration of 3 -4 Days.
The class will run daily from 12:00 pm EST to 4:30 pm EST.
Class Location: Virtual LIVE Instructor Led - Virtual Live Classroom.
Experienced analysts are all too familiar with the ambiguity and unreliability of plain text and simple sketches. The right graphical models can improve communication, understanding, and accuracy. But with dozens of different models, tools, and notations, how do you know what's right for your project?
In this course you will learn how to move beyond just gathering requirements to creating an integrated suite of models that incorporate process, data, and use case perspectives. You will learn criteria for determining which models are most appropriate for different purposes and get ample practice creating these different models through exercises based upon real-world projects.
BPMN and UML are both large notations intended to address a wide variety of problems. At first glance, these notations, and the models created using them, can seem scary and forbidding. This course defines the parts of the notations essential to building good models and gives participants guidance in building models that convey important concepts without resorting to baffling and confusing notations. You will learn a simple and compact system for collaborative model that enables you to capture the most affirmation in the smallest space with the least work in a way that is testable and highly adaptive.
Objectives
Who Should Attend
Anyone involved in requirements elicitation or business analysis will benefit from this class. This course is perfect for:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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: