Many BAs struggle to produce ‘normalized’, function-independent data models (or don’t produce them at all). Very few business stakeholders can appreciate such models as “… a picture worth a thousand words.” This article describes an easy-to-create, simple-to-understand view data model. The view is of just those records involved in an information system capability supporting a specific business activity.
NOTE: This article uses the business-friendly terms record and field rather than the usual data modeling terms entity (or class) and attribute.
Activity-Specific View Data Model
When a business activity involves more than one type of record, an activity-specific view data model can be created quickly and easily. Its purpose is to be a visual aid representing the record types associated with a specific user interface, report, data import or export, or fully-automated function (See Keeping High-Level Requirements High Level). An activity supported by an information system will involve an initial ‘target’ record, or list of records, of a given type. From that point there can be a number of related records containing information that the activity needs to be able to access. Business users often think of this as ‘drilling down’ to additional details.
For example, the activity of receiving sale transaction data that originates in a point of sale (POS) system. Because the data is available in machine-readable form, the system receiving it would require a data import capability. The following view model represents the initial SALE transaction record along with additional records containing sale-related details:
An activity-specific view uses business-friendly terms for the records. These terms come from subject matter experts (SMEs) involved in detailed requirements elicitation for the capability. The view uses relationship lines resembling ones commonly seen in org charts – a business-friendly way to present data access paths.
A view model is intentionally kept simple - not expected to be worth a thousand words. The above example is intended to visually represent to a business or solution delivery stakeholder the following 41 words:
“The capability of importing POS transactions involves Sale, Customer, Sale Line Item, Product, Location, and Payment record data. A Sale can have associated Customer, Sale Line Item, Location, and Payment details. A given Sale Line Item can have associated Product details.”
The view purposely avoids relationship direction-specific labels, optionality, or cardinality symbols (e.g. 0..*). A SME for a given activity is only expected to be knowledgeable in the relationship’s top-down direction.
Details for the relationship’s opposite direction would be sourced from a SME knowledgeable about an activity that involves the two records in the reverse top-down order. For example – a user interface supported activity that starts with a given LOCATION and accesses SALE records from that location.
Data-Requirement Detail
An information system allows data to be captured once and used many times. So, while data-requirement details can be identified as part of eliciting an activity’s functional detailed requirements, function-independent data details, such as field size or the ability to navigate between records, should be documented separately.
Common data documentation forms are:
- A fully-attributed data model
Fully-Attributed Data Model - A fully-attributed data model includes records, fields within the context of a record, and bi-directional relationship lines with ‘verb’ labels, symbols representing optionality, and cardinality for each direction.
For example, the records from the activity-specific view model above, represented in a function-independent fully-attributed data model:
This is the type of data model commonly touted to be “… worth a thousand words.” The model itself certainly contains many more words. But what is its worth to a stakeholder that doesn’t understand the symbols or is not interested in function-independent data? Especially if the stakeholder has access to activity-specific view data models for the activities they are interested in?
Textual Statements – Textual statements containing function-independent data details are most often included amongst detailed functional requirement statements. Or they are sometimes considered ‘business rules’ and listed separately.
A data-requirement statement may address one specific detail or combine any number of details in one or more sentences. For example:
Each Customer must have a unique identifier.
A SALE record must involve at least of one but can involve many SALE LINE ITEM records.
The less content there is in a single statement the more statements are needed to cover the overall detail. The more details that are combined into a statement, the more effort is required to compose, review, and quality assure the requirements. This holds true for either functional or data requirements.
Textual statements also allow a single requirement to contain both function and data details. The following is an example of what was considered a ‘good’ requirement statement example found on the internet:
Login e-mail address must be unique and during account registration if the e-mail address provided by a customer is already used in the system the customer must be notified about it.
Data Dictionary – The objective of a data dictionary is to organize record, field, and relationship details separately from functional details. For a given entry in the dictionary, specific property values are ‘structured’ in a tabular form (e.g. mandatory or optional). Many such templates can be found on the internet. Most, however, offer a limited set of properties - intended to support physical database table implementations rather than requirements.
See Trips-R-You Case Study: Data Dictionary for an example of a template specifically designed for data requirements for an information system. Use of this template is described in the article Managing Data-Specific Business Needs Using a Data Dictionary. Each field is listed within the context of a record. A relationship single access direction is treated similarly to data fields.
The following screen shot shows SALE record data details captured using this template:
SALE is seen as the context for seven fields - three data fields and four ‘related data’ fields. The properties for a related data field represent the path from the context record to the ‘to’ record. Details for the reverse direction are captured in a field within the context of the other record (e.g. the Sale field within the context of the LOCATION record).
Highlighted in red text in the screen shot above are the same relationship details seen in the fully-attributed model (and excluded from the activity-specific view model). Other columns support additional properties graphical models do not support. Note that several of the columns in the template represent properties applicable to both data and relationship fields.
Summary
The ‘information’ aspect of an information system is as important as the functional ‘system’ aspect. Communicating data details to function-oriented stakeholders needs to be done in the most business-friendly way. This article has described a version of data modeling that is function-oriented in that it addresses data associated with a specific business activity. This makes it relevant to business and solution-delivery stakeholders interested in the system capability supporting that activity.
The business-friendly terms ‘record’ and ‘field’ are recommended. Records included in an activity-specific view model are arranged in a business-friendly org-chart-like structure. At the top of this structure is the activity’s entry-point record, further emphasizing the functional relevance of the data.
A data dictionary template was presented that is intended to support capturing and managing function-independent data-requirement details. Dictionary entries are either records found in one or more view data model, or fields within the context of one of those records. Property-based columns in the template are intended to guide a business analyst in capturing field-related details as part of activity-specific functional requirements elicitation.
Further examples of use of the data dictionary template can be found in the Trips-R-You Web-Based Flight Reservation case study. The case study also demonstrates using spreadsheet-based templates as alternative to textual requirement statements for capturing activity-based functional detailed requirements.
Author: Dan Tasker
Dan is the author of over 30 requirements-related articles and other resources. His 45+ year career in Information Technology has involved organizations in a variety of industry sectors in the United States, Canada, Australia, and New Zealand. His business analysis experience includes projects involving in-house software development, software vendor solution development, and COTS software acquisition and implementation. He continues to be passionate about quality requirements and helping business analysts produce them. He can be contacted at [email protected].