The Business Data Diagram is a powerful, high-level RML model that can help bound the scope of data for your project. It can also be used to visually convey a sophisticated strategy for bounding your requirements objects and their traceability.
I was recently working on a project where we had huge sets of requirements data stored in separate locations: one was a set of thousands of business rules, based on user eligibility around system “events.” Events rolled up into larger groups of system “processes,” which were listed in another large requirements matrix with user stories mapped to features and process steps. A third set included detailed functional requirements around user data entry and field displays, which mapped to process steps. Combining all three documents into one would have been impossible, but we wanted to ensure we had complete traceability across all three sets of requirements data and we had adequate requirements coverage for every product feature and process.
In order to model how each requirement object related to one another, we created a Business Data Diagram showing the relationships, cardinality, and stored location of each requirement object. A link to a similar BDD is included below for reference, followed by some tips and tricks for using this model on your projects.
Color Coding
You can use “skittles” to denote object location (or other object attributes, as necessary for your project). Be sure to use a consistent schema for where each colored skittle is placed on a box so that colorblind stakeholders can still digest the model and it’s still meaningful if you print in black and white.
Modeling Attributes
Whenever you include a 1 to 1 relationship in your BDD, be sure to ask yourself whether each object is truly an object or if one is an attribute of the other. In some cases, you CAN model attributes as business objects in a BDD when it is either important to display for clarity or it is the primary or secondary key linking to another business object. A common attribute you might model as an object in a BDD would be Customer ID (attribute of Customer), if it’s the primary key linking Customer to a variety of other objects.
Consider Effects of Change
When determining the relationship between objects, think carefully about the effect that change on one object would have on objects it’s related to, both directly and indirectly. This is particularly effective for validating a 1 to N/N to 1 relationship.
Track Requirements Coverage
Once you’ve modeled how your requirements objects relate, you should map all of the relationships in your requirements sets. The best way to do this is to refer to unique identifiers of requirements objects stored in other locations. This way, if you have 60 business rules that map to one user requirement in a Requirements Mapping Matrix, you can simply list all of the business rule IDs for developers to reference in a single cell in a single row, instead of duplicating the row for each business rule.
If you are managing your requirements in Excel and need to ensure complete mapping to a process, feature, or any other requirements object, you can add adjacent tabs to your spreadsheet to track this. Let’s say we want to ensure we have enough requirements for all of our features. In a matrix where requirements are mapped to features, add a tab and list all of the features’ unique identifiers you’re mapping in column A. In column B, use a formula COUNTIF to track how many times they’re mapped in your matrix [=COUNTIF(select column where your Feature IDs are mapped in your RMM; select cell in column A in sheet 2)]. You can then filter by values with a 0 to determine which objects still need to be mapped.
Ultimately, if you want to get to a complete requirements set with each requirement object mapped to all other relevant objects for your developers, the BDD can provide a roadmap to get you there.
