Modeling is for Everyone

On this page:

• What is a Model?
• Benefits of Modeling
• Types of Models
• The Iterative Nature of Elicitation and Modeling
• Modeling and the Project Professional

Modeling is one of the most important practices for any project professional. As the adage states, “A picture is worth 1000 words.” Models allow us to better understand the stakeholder needs and provide a venue for any project professional to elicit and capture solution requirements. They reduce ambiguity by providing a visual for stakeholders to see and effectively translate requirements in a way the stakeholders understand and the development team is able to implement.

Research suggests most people are visual learners, so a model can go a long way in communicating requirements and making sure everyone is on the same page. We often think that modeling is only for and done by business analysts. However, everyone, including project managers, product owners, team members and others, can learn to model and harness the benefits of modeling.

What is a Model?

A model is an abstraction for part or all of a solution. It represents reality, but because it is a simplification of a solution, it may still need additional supporting text. Models capture requirements as well as help us elicit additional requirements by prompting us to ask clarifying questions needed to uncover hidden and tacit requirements.

Models can be developed using a variety of techniques such as brainstorming, facilitated workshops, interviews, or prototyping. Many of these techniques are interdependent and can be used together. Models are completed iteratively throughout the project or change initiative.

Benefits of Modeling

Models are extremely flexible and benefit organizations in a multitude of ways. They can be used to:

• Improve or reengineer processes
• Describe different views of a solution
• Uncover requirements and capture the features, characteristics, and functions of a solution
• Create training and client documentation
• Determine best practices
• Identify stakeholders
• Elicit, capture, and confirm requirements
• Provide context for clear understanding by all stakeholders
• Reducing ambiguity by ensuring all aspects of a problem are understood
• Gain consensus on business processes, data, user interface needs, interaction expectations
• Minimize the risks associated with not getting good requirements

Types of Models

You can almost model anything – analysis work, processes, interfaces, data, etc. Here are five common categories of models that can help you model a solution.

Scope Models. Scope models visually depict which processes, features/functions, stakeholders, departments, or data are in and out of scope. The diagram may be a rectangle or circle showing everything inside the rectangle or circle as “in scope” and everything outside that rectangle or circle as “out of scope”. It may also capture pre & post conditions

Scope may also be captured by creating very high-level models that show context. A variety of models can be used to show scope, including context diagrams, features in/out lists, use case diagrams, high-level data flow diagrams, and business processes.

Data models. Once thought to be solely the domain of technical developers and database administrators, data models help us understand our stakeholders’ information (data) needs, including business rules (e.g., policies, calculations, sequence of events, limits, and business decisions).

The most frequently used data models are an entity relationship model and class diagram which shows data entities (objects or concepts that can have data stored about them), attributes (describe and provide detail about the entity), and the relationship between entities (cardinality – how many and optionality – required or not). The relationship also graphically captures data business rules.

Process models. Typically, our projects result in changed processes. Sometimes it is a big change and sometimes a small one, but projects change how people do their jobs. In order for us to understand what those changes mean to our stakeholders, we need to know what they are doing today (current state) and how that will be different when our project is completed (future state). Process models include process maps, swimlanes, value stream maps, activity diagrams and data flow diagrams.

Use case models. Use case models are regaining favor with BAs and others, particularly in the Agile world, because they are a great way to model and capture functional requirements from a stakeholder viewpoint. Use cases help us answer very important questions about the actor’s (person, other system, event) interaction with software. It provides the structure needed to ask the right questions relating to what the stakeholder expects that interaction to be. Use case models include use case diagrams, use case narratives, sequence diagrams, and activity diagrams.

User Interface models (prototypes). User interface models or prototypes might be done using sophisticated software, the proverbial back of a napkin, or something in-between. However created, these prototypes help stakeholders see a picture of the end product, enabling them to provide feedback and suggest changes long before it is developed. User interface models may include prototypes, mock-ups, or wireframes.

The Iterative Nature of Elicitation and Modeling

We can’t start out modeling requirements without some understanding of the end-product. We need to ask enough questions to be able to develop an initial model of the requirements. Once we have a picture, or model, we can start to see the gaps in the requirements, gaps that will generally lead to additional questions. This becomes the iterative nature of elicitation and modeling. Modeling helps us to ask the right questions, questions we most likely would not think to ask if we didn’t have a visual model for reference. Asking questions, then, enables us to model the requirements. Modeling requirements, in turn, allows us to ask further questions and ultimately deliver the product that our stakeholders are expecting.

Modeling and the Project Professional

Modeling can be done by any role – including project manager, business analyst, designer, developer, or others regardless of the project approach (Waterfall or Agile). It might get done by the development team during each iteration on an Agile project, or it might get done during the business analysis phase(s) on a more traditional project.

Because modeling takes time, it is critical to recognize how modeling can help our initiatives and then to determine which models will provide the most value so we can make time to collaborate with others in their creation and analysis. We also should consider how ad-hoc use of modeling can benefit our efforts so that we are open to using them when we are stuck and need those 1,000 words to help us move forward. Either way, details of the end product are necessary in order to provide a product stakeholders will want to use and that meets their expectations. Modeling is an indispensable technique for identifying those details.

So, whether you are the one who does the modeling on your initiatives, or you are someone who needs to support the effort to do modeling, it is essential for all project professionals to recognize its value. Failure to model is a missed opportunity to collaborate in meaningful way and it increases the risk of not asking the right questions. And if someone doesn’t do that, we can’t hope to identify or solve the right problem, get everyone on the same page, or elicit the right requirements.

For more information on modeling, go to www.watermarklearning.com. Check out Business Analysis modeling essentials and business process modeling courses.