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 to design solutions—much more powerful, much more efficient, and certainly more 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 how to do graphical modeling with defined semantics.
- There’s more to analysis than use cases and functional decomposition. The method you’ll learn will 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.
Section 2. 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.
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 the key components of a use case and allow use cases to be organized into distinct scenarios. Done properly, process modeling identifies the 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
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.
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. Activity Tabulation
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 8. 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 9. 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 10. 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 11. Relationships: Association and 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 12. 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 object 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 13. 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 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. 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 16. 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 17. 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 18. 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 19. 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 20. Coordinated State Models
System behavior is the result of coordinated state models. A user activity sends an event to one state model which, in turn, sends events to other state models. This mechanisms and models presented in this section allow analysts to simplify and organize complex system behavior.
Section 21. The Collaboration Model
While process models show behavior in the context of a single business process and state models show behavior from the perspective of a single object, a collaboration model summarizes event communication between the various objects (state models) and external entities (actors). 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.
Section 22. 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 23. 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 24. 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 25. 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 26. Designing and 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.
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?
- From the principles presented in this section, identify
- One principle you most agree with
- One principle you most disagree with
- One principle you wish your manager / colleagues / customers knew
After a quick introduction to the five basic models, compare product requirements against these models.
Read the overview of the Expense Reporting application
Review the models presented in the overview. Can you see the elements of the basic requirements?
What requirements in the overview are missing in the models?
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 some 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?
Create basic process models.
Create process models for two of the alternate scenarios:
- Manager declines the expense report and the Employee resubmits it.
- Manager declines the expense report and the Employee cancels it.
Write descriptions for process model components.
Write descriptions for the
- Entities and their States
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.
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 in Exercises 2 & 3?
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 that the employee reimbursement does not depend upon customer billing (and vice versa)
- How would this process model be different if a Controller had to approve the billing?
- Assume that there are multiple “Controllers” but that the same person may do both activities, or they can be done by different people.
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.
Create a basic information model (classes, attributes, and associations) from the contents of a process model.
- Create a basic information model from the entities and actors on the process models.
- Create relationships between classes based upon real associations in the process models.
- Place attributes based upon the information in the process models and requirements.
Define association names and multiplicities.
Add to the model (Exercise 10, solution B, the one with the ExpenseItem):
- Association names
- Role names (if required)
- Test each of the associations to see if they make sense in the context of the problem.
Examine business documents to find base and derived attributes.
- Examine an actual expense report.
Place attributes on the information model.
- Write formulas for each derived attribute.
Make sure that the components of the formula are also on the model and accessible from the class containing the derived attribute.
Define attribute types.
Define each attribute’s type.
Write descriptions for information model components.
Write descriptions for
- Classes (class description + each attribute)
- Associations (from the perspective of each direction)
Apply specialization and subclassing to the information model.
Use role specialization to organize the various actors (Employee, Manager, Controller).
- Some managers are personnel managers who approve non-project expenses, some are project managers, some may be both.
- Use subclassing to place specific attributes on different kinds of expenses. Example: Check-In and Check-Out dates make sense for hotel expenses, but not for meals.
Use brainstorming techniques (an “object blitz”) to find classes, attributes, and relationships.
Do an object blitz as a group from the material in the Expense Reporting requirements.
- Map these concepts to find relationships between them.
(Alternatively we may use an application domain that is familiar to all participants.)
Create views atop an information model to represent the contents of specific reports, screens, and/or messages.
Create views to represent
- a complete expense report as submitted by an employee
- a reimbursement to be paid to an employee.
- How would this be different if a reimbursement can include multiple expense reports?
- a manager’s “to do” list, consisting of a list of all expense reports awaiting approval
Create an authorization model to define specific permissions.
- Create an authorization model from the process models and activity tabulations.
- Identify constraints on the actor-activity association lines.
Create a state model of a single object.
Create a state model of the Expense Report (The lifecycle should end with creating the Reimbursement)
Create a state model of a second object and coordinate that 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?
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.
Use the information model to find additional activities that may not have been presented on the original process models.
Define activities for managing the people (employees, managers, …)
Are there constraints between these activities or between the actors and activities?
Do any of these classes seem to have “interesting” lifecycles worthy of state machines?
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.
Create a navigation map to define the contents of an application’s user interface.
Create a navigation map for the expense reporting application.
- What views are required?
- What activities are present?
Review what you’ve learned in the course and compare these to your objectives from the beginning of the class.
Discuss as a group
- 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 the obstacles?
- Which steps do you feel are not worth doing?
- What would you like to learn more about?
Back to top