Diagramming for Business Analysts
According to the Business Analysis Body of Knowledge (BABOK), there are essentially six major categories of Business Analysis Diagrams that directly relate to requirements:
|Business Analysis Diagrams|
|Data Models||Data models are about DATA only. They do not try to represent processes or interactions with users so much as they emphasize really only the data itself. There are three major types of data models:
1. Entity Relationship Diagrams: These diagrams are used to represent the data requirements for a system. They include entities, attributes, relationships (based on business rules and cardinality), and (usually) metadata (or data about that data).
2. Class Diagrams: These are often UML Diagrams that are also used to represent the data requirements for a system. Instead of entities, they include classes; however, they also include relationships and metadata.
3. Data Flow Diagrams: These diagrams show the ways in which data flow through a system (Inputs, Outputs, Processes, and Storage). There are two (competing) models for data flow diagrams: the Gane-Sarson Notation and the Yourdon Notation. While these two models differ slightly, you really shouldn’t worry too much about it. They both include external entities (which typically represent the inputs and outputs), the actual process itself (e.g., receive order), and storage (where the data is located). These things are all connected together to show the flow of the data through a system, hence the name. (Please note that in the BABOK Guide, this is listed as a separate general technique. I have grouped it here because it still relates to DATA.)
|Process Models||Process models are used to visually document how work is done. They are somewhat like data flow diagrams except they do not focus on data, they focus on work. (Think of work as a process.) Basically, process models show how work flows and how activities get done. There are three major types of process models:
1. Flowcharts: A common type of process models, flowcharts typically have starting and ending points with activities and how they flow along the way. They are good at showing decision points, and they can easily be combined with swimlanes to show process handoffs to different roles.
2. Activity Diagram: These are often UML Diagrams that contain five components: activity steps (processes), control flows (or transitions), forks and joins, decision points, and guard conditions.
3. Business Process Modeling Notation (BPMN): While not all that popular, they have been gaining ground recently. It is a lot like flowcharting; however, it has its own notation. One of the key advantages of BPMN is the use of pools. Pools enable multiple swimlanes to be grouped together.
|Scenarios and Use Cases||Scenarios and Use Cases are very commonly used techniques to graphically represent requirements in UML Diagrams. Although the terms are sometimes used interchangeably, they are different: a scenario is a specific instance (like a path) of a use case. Use cases are typically written in two parts: a narrative, which is used to describe the requirement; and a diagram, which is used to visually represent the requirement. The diagram includes actors (which look like little stick figures) that interact with a system through the use of relationships (or associations). Those relationships can also include two special stereotypes: extend and include. These allow you to extend or share functionality within a use case. Use cases are good at showing primary and alternate paths as well as pre- and post-conditions.|
|Scope Models||Scope models are used to show solution boundaries or “scope.” I tend to think of scope models as sub-techniques because they really include other types of diagrams. (Of course, the BABOK guide lists it as its own general technique, so I have broken it out here for you.) You can really use data flow diagrams, use case diagrams, or process models to show scope. One of the most common types of scope models is a Context Diagram. A context diagram is a top-level data flow diagram. In other words, it shows a visual depiction of a solution scope with external agents who interact with it.|
|Sequence Diagrams||Sequence diagrams are UML Diagrams that show interactions in a logical sequence. They typically show sequence from left to right. They can show both procedural flows (like an activity diagram) and asynchronous flows (or signals, which allow for the continuation of processing following a signal). Many times, sequence diagrams validate class diagrams (which are data models) against use cases. In this regard, they can be thought of as a spot check to ensure that nothing was missed. Although it is useful for you to be familiar with these types of diagrams, they are mainly used by application designers and developers.|
|State Diagrams||Finally, state diagrams are UML Diagrams that depict the states that an entity or a class goes through in response to an event. You can kind of think of this as a lifecycle diagram for data. A state is a discreet condition (which means it can only be one thing at a time), and a state diagram captures the transitions from one state to another.|
Note: There are arguably many, many other types of diagrams or sub-diagrams. For example, organization diagrams are frequently used by Business Analysts to represent stakeholders. (Moreover, some people believe that functional decompositions are types of organization diagrams–I won’t argue.) It is not my intention here to list every possible diagram; instead, I believe these six categories demonstrate a good way to group the major diagrams as they relate to business analysis and requirements.
In the end, modeling is done for two reason: readability and reusability. As such, it is important to consider which diagram best meets your needs as a Business Analyst. The following modeling concepts affect requirements analysis, and BAs should choose models and take all the concepts into account for complete requirements. Consider the PUREE method:
- Processes – Steps performed to accomplish a goal or achieve a result for an organization. They transform inputs to outputs and should be repeatable. Processes include the roles or people involved in carrying them out, including any cross-functional collaboration. Process models, organization models, use case models, and state diagrams are used.
- User Classes, Profiles, or Roles – In general, these are the people who interact with a proposed or existing solution. Roles are groups of stakeholders with similar needs and objectives. User classes are identified when you “Conduct Stakeholder Analysis” and used with a number of models and techniques. Organization models, process models, and use case models are used.
- Rules – Rules, commonly called business rules, are organization-wide operating principles or constraints for how the organization should function. They are true across all projects that support them and might apply to process, data, events, or other concepts. They affect decision-making and the sequences of certain actions and reflect the organization’s priorities. Process models, state diagrams, data models, and use case models are used.
- Concepts and Relationships (Entities) – Concepts are entities or other related things in the organization, like people, places, things, etc. They are the source of facts and other data and tend to have relationships to other concepts. For example, a “Customer” is a “people” concept that may have one or more “Accounts.” Data models are used.
- Events – A trigger or other request of the organization to do something, such as a customer withdrawing money from his or her bank account. One or more business processes are triggered as a result, which can come from outside the system, inside it, or at certain times. Scope models, process models, state diagrams, and use case models are used.
So, what’s the deal with UML Diagrams? Why is that highlighted in the previous table?
UML is the Unified Modeling Language. As you can see above, it is NOT a diagram type; it is the format (or “modeling language”) used by many different types of diagrams. It is actually quite massive. (There are really nine UML Diagram types, and you can even get certified in UML!) From a Business Analyst’s perspective, you need to know how to apply UML to the specific business analysis diagrams listed above. Other types of UML diagrams, like component and deployment diagrams, are used more frequently by solution designers and developers.
In the upcoming weeks, I will be adding more to this blog about the individual diagram types.