They are useful in generating “yes, but” conversations and eliciting information stakeholders don’t think of until they see what an application might look like.
Visual Model #3 – User Interface WireframesĪ User Interface (UI) Wireframe is a visual rendering of how a specific screen to be implemented as part of a software solution will be laid out. Later on you can get deeper into the complex relationships that exist within physical databases. If this is a new skill set, focus on keeping your domain models simple and business-driven. However, they tend to be less complex than data models and focus only on the information concepts critical to understanding how the business works. The Customer concept might have a 1-to-many relationship to the concept of “Order” which has attributes for Order Date and Total Amount.īusiness Domain Models can be created using the same notation as an Entity Relationship Diagram (or ERD)and they tend to look a lot like logical or physical data models. Lines connecting the boxes show the relationships between concepts.įor example, a Business Domain Model might contain a box for the concept of “Customer” and attributes for Customer Name, Customer Address, and Customer Contact. Important attributes for each concept are listed within each box. In a Business Domain Model, each key concept gets a box. This way, you can show not only what terms mean but how the relate together. Creating and walking through a model like this can often clear up misunderstandings and get everyone speaking the same language.Įssentially, a business domain model visually presents information that might be included in a glossary or data dictionary.
Then, as your situation warrants, explore a more complex notation like BPMN.īusiness Domain Models clarify the information created and managed by an organization without diving deep into the database structures.
If you are new to this skill set, focus first on learning how to create workflow diagrams and visually model processes. Otherwise the notation can make it more difficult for stakeholders to comprehend and approve your process models. The complexity can be useful if your process requires it. However, the BPMN notation contains a much larger number of formal elements and so the BPMN diagrams tend to be more visually complex. Conceptually, BPMN diagrams are similar to workflow diagrams. Swim lanes may be used to show who or what is responsible for each step in the process.Ī smaller subset of BAs use BPMN (Business Process Modeling Notation) to create more formalized diagrams.
These diagrams contain boxes for each activity step, diamonds for any decisions or variations in the process, and a series of arrows to clarify the sequence of steps in the process. Most BAs create simple workflow diagrams that show the end-to-end business process. Process Flow Diagrams exist in multiple forms. For example, a business process diagram can help facilitate more effective use case reviews by providing context for how the system functionality will support the business process. They also put other requirements activities in context. Process Flow Diagrams are an intuitive way for stakeholders to understand the organization’s fundamental processes, get clarity on how work gets done, and appreciate how value is delivered.
Then we’ll look at how you can begin using more visual models in your projects right away.
In this article, we’ll explore 3 simple visual models that a new business analyst should be skilled in creating because they add a lot of value to projects and generally improve your requirements documentation.
Unless your organization uses formal UML or BPMN standards, focus on learning to create simple visual models. Visual models don’t have to be complicated. Requirements specifications ideally include both types of information, as different stakeholders learn in different ways. Most BAs tend to have a natural preference for either textual or visual models. In a recent article on the Top 10 Skills a New Business Analyst Should Shore Up On, #6 was identified as creating visual models.