I. 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 to design solutions—much more powerful and precise than words alone.
In this course we'll be addressing five major ideas:
- The job of the BA is more than just gathering requirements—it involves creating solutions.
- Plain text is notoriously imprecise. You'll learn to do graphical modeling with defined semantics.
- There's more to analysis than use cases and functional decomposition. We'll cover many facets of system development, including information, permissions, and subject matter partitioning.
- Good business analysis is platform-independent.
- Working systems beat documents. Models can be developed incrementally, and are formal and precise enough to be validated by simulation.
II. Method Overview
This section provides a roadmap of the five basic models (Process Model, Information Model, State Models, Collaboration Model, Authorization Model, three derived supplementary models (Context Diagram, Sequence Diagrams, and Views), and the relationships between them.
III. Use Cases and Scenarios
One way to approach a system is to model its functional behavior. 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 conditions and steps of each 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.
IV. Process Modeling Basics
Process models (sometimes called "business process models") graphically represent the key components of a use case and allow use cases to be organized into distinct scenarios. Done properly, process modeling identifies key business entities, their lifecycles, and activities that progress these entities through their lifecycles. Because they are graphical models with defined semantics, process models can be more precise and accurate than text alone.
V. Process Descriptions
While graphical models provide the structure for the concepts in a domain, each element requires 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.
VI. Decisions and Alternatives
Simple process models present a straightforward flow of control from beginning to end. But real business processes often involve several points at which decisions are made and alternatives can be taken. We present methods for describing alternative flows and how different scenarios of the same use case may illustrate several diagrams or one single diagram.
VII. Activity Tabulation
A large domain often involves a number of different business processes 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.
VIII. Concurrency
Real business processes usually involve several things happening at once. Process models should describe real-world concurrency and exploit opportunities for parallel behavior. Here we present notations for describing concurrent activities, how an activity or condition may start parallel flows, and how to ensure that several parallel activities have all completed.
IX. Time
Some activities are initiated by the actions of people, organizations, or systems. Others are initiated "by the clock" either at specific times (such as a monthly payroll) or after a certain duration. We show how to include and coordinate time-related events.
X. Authorization Models
Process Models describe what happens in a business process and Information Models describe the facts in a problem. Although process models say which actors perform which activities, they do not necessarily enumerate all activities, nor do they describe important constraints. Authorization Models augment standard use case diagrams with permission constraints specifying the exact conditions under which different actors can perform activities.
XI. Lifecycle Basics
Every object defined on the Information Model has a lifecycle: stages through which they progress over time. Some are trivial—"created" and "deleted," for instance, but others are more sophisticated. State models represent these more interesting lifecycles. Explore the lifecycle concept and learn to construct state models representing an object's states and the events that cause their progression. It also powerfully shows the interconnections between the elements in the various analysis models.
XII. Coordinated State Models
System behavior is the result of coordinated state models. User activity sends an event to one state model which sends events to other models. Mechanisms and models presented in this section allow analysts to simplify complex behavior.
XIII. The Collaboration Model
While process models show behavior in the context of single business processes and state models show behavior from a single object, a collaboration model summarizes event communication between various objects (state models) and external entities (actors). Learn to create collaboration models summarizing existing state models as well as how to use collaboration models to plan system dynamics in advance.
XIV. Model Verification by Simulation
The models presented in this course are formal and precise enough to be tested. You will learn how to create test cases based on process models, run these tests against other models, and use these test cases to create the actual system test cases.
XV. The Process of Analysis
Any modeling activity exists within the context of larger processes. While this course is emphatically not intended to prescribe a particular process, there are important factors to modeling and analysis success. Learn important success factors 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.
XVI. Designing/Implementing from Models
How do models become systems? How do enterprises use them to manage consistency across projects? Learn approaches to system architecture that take advantage of many distinct architectural views, show how views can also be modeled, and how architectural models are used to translate the analysts' business models into working systems.
Exercise Summary
Exercise 1 — Share your goals for the class. Identify principles that you agree with and others that you disagree with.
- What are your goals for the course?
- Using this section's principles, identify
- One principle you most agree with
- One principle you most disagree with
- One principle you wish your manager/colleagues/customers knew
Exercise 2 — After a quick introduction to the five basic models, compare product requirements against these models.
- Overview of the Expense Reporting application
- Review the models presented in the overview. Can you see the basic requirements elements?
- What requirements are missing in the models?
Exercise 3 — Identify use cases, define different scenarios of those use cases, and trace use cases back to requirements.
- We've seen the use case for "Employee Submits Expenses" and a single "happy day" scenario.
- What are other scenarios of that use case?
- What are some other use cases that are necessary to create a complete application?
- Which of these other use cases can be traced to the requirements?
- Which of these other use cases are not in the requirements?
Exercise 4 — Create basic process models. Create process models for two alternate scenarios:
- Manager declines the expense report and the Employee resubmits it.
- Manager declines the expense report and the Employee cancels it.
Exercise 5 — Write descriptions for process model components. Write descriptions for the
- Actors
- Activities
- Scenarios
- Entities and their States
Exercise 6 — Use decision and alternative structures to create single process models that combine the behavior from multiple simple models. Combine these three alternative scenarios into a single process model:
- Manager accepts the expense report and the Employee is reimbursed.
- Manager declines the expense report and the Employee resubmits it.
- Manager declines the expense report and the Employee cancels it.
Exercise 7 — Tabulate the contents of process models and use these tabulations to determine additional process models and additional requirements.
- Tabulate the actors and activities in the process models built so far.
- Can you identify additional process models / scenarios by extending these tables?
- Add the additional elements based upon the missing requirements identified previously?
Exercise 8 — Add concurrency to process models so that several activities may occur at the same time.
- Extend the basic flow to incorporate billing the customer once the expense report has been approved.
- Use concurrency structures so reimbursement doesn't depend upon customer billing (and vice versa)
- How would this process model be different if a Controller had to approve the billing?
- Assume that multiple "Controllers" may do both activities, or they can be done by different people.
Exercise 9 — Create process models that incorporate time-based activities and events.
- Add a mechanism to send reimbursement payments semimonthly.
- Add a mechanism to cancel rejected expense reports after ten days.
- Add a notification to the manager / controller if pending expense reports are not acted upon.
Exercise 10 — Create single object state models.Create a state model of the Expense Report (The lifecycle should end with creating the Reimbursement) Exercise 11 — Create a state model of a second object and coordinate behavior with another object Create the state model of the Reimbursement.
- If the Controller selected several Expense Reports to reimburse at once in one payment, what would the creation event look like?
Exercise 12 — Create a collaboration model to summarize event communication into, out of, and within a domain. Create a collaboration model from the two existing state models (Expense Report + Reimbursement)
- Add the Payment Cycle to the Collaboration model; define a layering of responsibility.
Exercise 13 — Simulate one or more of the process models by playing through the state models and IM tables. Simulate the following scenarios:
- An employee submits an expense report, a manager approves it, and a controller pays the reimbursement right away.
- An employee submits an expense report, a manager declines it, but the employee resubmits it. The Manager approves and the Controller pays that revised expense report.
Exercise 14 — Review what you've learned in the course and compare these to your objectives from the beginning of the class.
Group Discussion
- Which steps of the process can you take away and do right away?
- Which steps would you like to do but feel stymied in doing? How can you reduce obstacles?
- Which steps do you feel are not worth doing?
- What would you like to learn more about?