Business Analysis: Four Core Models for Scoping Requirements

In this lesson I will address five questions pertaining to a relationship map:

· What is it?

· Why is it used?

· How does it help?

· When is it used?

· Who should use it?

In this lesson, we will look at the four symbols used in a relationship map:

· Entity Rectangle

· Connector Line

· Line Label

· Boundary Box

In this lesson, I’m going to walk you through the recommended workshop activities or steps to building a relationship map. The objective of this lesson is to provide guidance for you to facilitate the creation of a relationship map in collaboration with a group of stakeholders. In order to focus specifically on the steps to building the relationship map, the details in the workshop start and workshop finish are excluded from this discussion. An overview of a workshop charter is presented in module 1.

In this lesson, I will show you an example of a flawed relationship map that incorporates some of the incorrect usage of the symbols that I covered in the second lesson of this module.

When the relationship map is displayed, pause the video to analyze the relationship map and identify the flaws in it. Also, I encourage you to consider what could be done to correct those flaws.

In this lesson I will address five questions pertaining to a use case diagram:

· What is it?

· Why is it used?

· How does it help?

· When is it used?

· Who should use it?

In this lesson, we will look at five symbols used in a use case diagram:

· System Domain Box

· Actor Figure

· Goal Oval

· Actor Initiator Arrow

· Actor Connector Line

In this lesson, I’m going to walk you through the recommended workshop activities or steps to building a use case diagram. I assume that you have already viewed the workshop charter overview presented in module 2, or you are familiar with a workshop charter. Therefore, I won’t reiterate or take the time to explain terminology related to a workshop charter.

In this lesson, I will show you an example of a flawed use case diagram that incorporates some of the incorrect usage of the symbols that I covered in the second lesson of this module.

In this lesson I will address five questions pertaining to a context diagram:

· What is it?

· Why is it used?

· How does it help?

· When is it used?

· Who should use it?

In this lesson, we will look at four symbols used in a context diagram:

· System Boundary Circle

· Role Rectangle

· Input/Output Flow Arrow

· Input/Output Label

In this lesson, I’m going to walk you through the recommended workshop activities or steps to building a context diagram. I assume that you have already viewed the workshop charter overview presented in module 2, or you are familiar with a workshop charter. Therefore, I won’t reiterate or take the time to explain terminology related to a workshop charter.

In this lesson, I will show you an example of a flawed context diagram that incorporates some of the incorrect usage of the symbols that I presented in the second lesson of this module.

In this lesson I will address five questions pertaining to a process map:

· What is it?

· Why is it used?

· How does it help?

· When is it used?

· Who should use it?

In this lesson, we will look at the five symbols used in a process map:

· Swim Lane

· Activity Rectangle

· Decision Diamond

· Transfer Arrow

· Start and End Circles

In this lesson, I’m going to walk you through the recommended workshop activities or steps to building a process map. I assume that you have already viewed the workshop charter overview presented in module 2, or you are familiar with a workshop charter. Therefore, I won’t reiterate or take the time to explain terminology related to a workshop charter.

In this lesson, I will show you an example of a flawed process map that incorporates some of the incorrect usage of the symbols that I covered in the second lesson of this module.

The objective of this training module is to illustrate how the models link together and help you reduce the risk of missed requirements. I deliberately presented the models separately in modules 2 through 5. I wanted you to learn each model independent of the others as much as possible. In this way, you would gain an appreciation for the unique strengths and benefits of each model. Now, you’ll step back so to speak, and compare the models side by side to better understand the benefits they offer when viewed as a collection.

As mentioned in module 1, each model is like an interlocking puzzle piece. When you connect the individual pieces, you see the big picture. While each model is effective in highlighting specific aspects of a project, there are significant benefits to using all four models.

Similar to home plans that include elevation drawings, and do-it-yourself plans that show different views, the four models collectively communicate the whole. You wouldn’t want to build a home with a plan that shows only one elevation. So why would you build a system with only a partial view of the scope of requirements?

My recommendation is to create and review multiple views of the project. The four core models presented in this course are models that I use on all of my projects and recommend that my clients use. Of course, there are additional models that you can use to supplement your project. Consider these four core models as your foundation. Using the four core models increases communication effectiveness among stakeholders and this equates to fewer missed requirements.

There are aspects of traceability in the four core models. That is, the accuracy of a model can reinforce and confirm the accuracy of another. Likewise, inaccuracies in a model can highlight inaccuracies in another model. Inaccuracies in the models translate to incorrect or missed requirements.

Let’s look at three Aspects of Traceability:

· Entities

· Relationships

· Data

In this lesson I will share some general recommendations and perspectives on how the four models compare on simple scales.

Apply a facilitation strategy ("be nice") to manage dysfunctional behavior in your requirements workshops.