Back to: Four Core Models for Scoping Requirements

Lesson Overview

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

ENTITIES

Although different terminology is used, entities are a common thread among the models.

The entity rectangle symbol in the relationship map represents the business areas, roles, and systems that interact.

You may choose to make any entity on the relationship map a focal point in a use case diagram or context diagram. In the use case diagram the entity in focus is called a system domain, and the entities that interact with the system domain are primary or secondary actors. In the context diagram the entity in focus is called a system boundary, and the entities that provide inputs or receive outputs are referred to as user roles.

The number of, or how many, entities exist in the relationship map drive the number of possible use case diagrams and context diagrams. There are 7 entities in this example relationship map. Therefore, there could be up to 7 use case diagrams, and up to 7 context diagrams drawn to explore and focus on each entity.

Furthermore, entities are represented in process maps as user roles. Each entity or user role has its own swim lane. An unidentified number of process maps are needed to fully explore all the relationships that exist in a relationship map.

RELATIONSHIPS

Another aspect of traceability to consider is relationships.

The connector line in a relationship map communicates the existence of a relationship between the two entities that are connected by the line. The line label expresses the reason for the relationship.

In this example relationship map, Entity C has a relationship with Entity A, D, and G. We can explore these relationships through the other models. The use case diagram with Entity C as the system domain shows us that Entity A and G are primary actors and initiate interaction with Entity C to achieve specific goals. Moreover, it shows that Entity D is a secondary actor, which means it is called upon by Entity C to assist in accomplishing a primary actor’s goal.

In the context diagram with Entity C as the system boundary, we see another perspective of these same relationships. The line labels in the relationship map help to understand why inputs and outputs are exchanged between the entities.

Relationships are communicated in process maps as well. When we place the example relationship map next to this example process map, we can identity the existence of relationships. In the process map there is a transfer from activity 1 performed by Entity A to activity 2 performed by Entity C. I placed a red dot labeled number 1 on both models to identify the traceability of the relationship between Entity A and Entity C. The red dot labeled number 2 marks the relationship between Entity C and Entity D. Finally, the red dot labeled number 3 marks the relationship between Entity D and Entity A.

As I stated earlier, an unidentified number of process maps are necessary to fully explore all the relationships that exist in a relationship map.

DATA

Finally, data, or information, is an aspect of traceability between the four core models.

In the relationship map, the line labels communicate the reason why a relationship exists. In the example shown, the connector line between Entity A and Entity C implies that data or information are exchanged between the two entities.

Similarly, in a use case diagram the actor initiator arrow and actor connector line represent two-way communication. In the example shown, the initiator arrow implies that data or information is exchanged between Actor A and Entity C.

The identification of data is most obvious in a context diagram. The input/output flow arrows depict the direction of information and material flow in to and out of the system boundary. The input/output label identifies each specific data element or information set.

The process map is the only model among the four that gives a sense of timing for when the data is used. The timing, of course, is not a reference to the time of day. Rather, timing is a reference to order flow or sequence. The label on the transfer arrow specifically identifies the data that flows between activities in the process.

In summary, there are three aspects of traceability between the four core models: entities, relationships, and data. While each model independently can highlight important parts of a project, viewing the four models collectively is necessary to understand the whole scope of a project. The collaborative discussions that occur while building and reviewing the models, are invaluable activities that reduce missed requirements, and ultimately lead to developing better systems.