Further elaborate on the information exchange scenario to understand and document the data requirements and business rules.
After planning out the scenario for the information exchange at a higher level, the next phase involves analyzing the exchange requirements at a more detailed level. This includes capturing data requirements, business rules, and other detailed requirements of the exchange.
Data requirements describe the actual data that will be shared in the exchange.
The exchange will need to capture information about a student, including the student’s first, middle, and last name and date of birth.
Business rules are specific qualifications for data that refer to how it should be structured (e.g., field length, constraints).
A student’s enrollment status is not available or is unknown. The assumption is they are not enrolled, and an information-needed flag will be added by setting X element to the value of TRUE.
Compile as much information as possible about the data requirements and business rules. This includes documenting existing field names, data types, definitions, cardinality, sample values, and code sets in current exchanges or data sources. Plans for new fields or modifications to existing ones should be documented as well.
Information about these data requirements can come from a variety of sources, including schemas or API documentation for current or related exchanges, and database fields. Sometimes a lot of details will be available; at other times, only minimal documentation will exist. Collect what’s available and fill in the blanks as much as possible.
Two common ways of capturing this kind of information are via spreadsheets and UML diagrams.
Data requirements can be captured in a spreadsheet
The following shows how a few simple data requirements might be documented in a spreadsheet:
|DOB||date||Birthday||0||1||Valid only between 1900-01-01 and current date||Check to see if this field needs to be required|
|eye color||code set||0||1|
A spreadsheet like this can be expanded as needed to add additional information. In some cases, data requirements may come from multiple sources and may sometimes overlap. Columns can be added to record the source of the requirement and to capture how they map to other requirements. If the current requirements are structured so that elements are nested in a hierarchy, columns can be added to capture the parent class or path of the field as well.
The following shows how code sets might be documented in a spreadsheet:
|eye color||OTH||other or unknown|
One benefit of using a spreadsheet is that it can be easily used in the next phase of the IEPD lifecycle when capturing mappings of data requirements to components in NIEM.
Data requirements can also be captured in Unified Modeling Language (UML) class diagrams.
The following is the major kinds of information that will appear in a class diagram:
The kinds of associations typically used in class diagrams to describe exchanges include:
The recommended steps for representing data requirements as a content model in a UML class diagram are:
The end result is a visual representation of the data objects and elements that will be included within an exchange
The following example demonstrates how to build a content model in a UML class diagram for the Customs Commercial Vehicle Tracker information exchange.
After planning out the exchange scenario, the following objects have been identified as the major categories of data requirements:
For each object, add a segmented rectangle to the class diagram with the object name in the top panel, as shown below:
After identifying the objects and drawing the objects, determine the specific characteristics of each object. For example, the Driver object can have the following elements:
Similarly, identify the elements for each of the remaining objects.
After identifying the elements of each object, fill in the element names and types in their corresponding object rectangles as shown below:
After identifying and drawing the objects and elements of an exchange in a class diagram, the relationships between the objects should be captured. In this case, we find that all the objects are associated through inheritance. After finalizing the type of association between each object, determine the cardinality of such association.
Draw the appropriate arrows for the given association type and add cardinality as shown below:
Documentation of data requirements and business rules should be included in the final IEPD package, whether specified via spreadsheet, UML class diagram, or another format. If a spreadsheet is used, that can help feed into the next phase of IEPD development, Map and Model.