An extended data dictionary can provide business requirements analysts with the ability to catalog and use many more attributes and metadata than an standard data dictionary
One of the key goals of business analysis is to obtain complete solution requirements. Among the solution requirements, possibly the largest share falls to user interface requirements, since most applications have significant user interface components.
Wireframes have been used for several decades to get better user interface requirements. Requirements engineers can leverage an extended data dictionary with wireframes to discover almost all user interface requirements, with significant benefits for this approach.
The extended data dictionary goes beyond the regular or the standard data dictionary used by business analysts. The extended data dictionary has 400% more metadata attributes, compared to the standard data dictionary which usually has 5 or 6 attributes.
Standard data dictionary
Standard definitions of primitive data elements, their meanings, allowable values, how those elements combine into composite data elements. Used to manage data within a solution’s context, often used along with ER diagrams.
Primitive data elements
Name | A unique name for data element. | Example: Prefix, First Name, Middle Name, Last Name, Suffix |
Aliases | Alternate names for data element. | |
Values | List of acceptable values (domain), if this element has a domain of values associated with it. | Example for the element Prefix: Mr., Ms., Dr., Mrs. |
Meanings | If abbreviated, include explanation. | |
Description | Definition of data element in context of solution. |
Composite data elements
Composite data is assembled from primitive data elements, e.g. an intelligent ID to describe items.
Sequence | Show primitive data elements in specific order. | Name: First Name + Middle Name + Last Name |
Repetition | Shows that one or more primitive data elements occur multiple times in composite element. | |
Optional element | May or may not occur in a particular instance of data element. |
Strengths of Standard Data Dictionary
- Ensures stakeholders agreement on format and content of relevant information.
- Ensures consistent usage of data elements.
- Serves as basis for creation and maintenance of a managed metadata environment, including business data elements and their definitions.
Limitations of Standard Data Dictionary
- Becomes obsolete unless maintained; assignment of maintenance often a point of contention between IT and business areas.
- Needs regular maintenance to ensure quick and easy retrieval.
- Provides only a small set of metadata information that the developers and business analysts need.
Extended Data Dictionary
The extended data dictionary has the following metadata attributes in addition to standard data dictionary metadata attributes:
- Format (Any specific format expected for the UI element)
- Minimum Value (Allowable minimum value).
- Maximum Value (Allowable maximum value).
- Editable (Then whether it is editable or not and up to what development stage element can be edited).
- Horizontal alignment of the UI element
- Validations / Business rules applicable to a field.
- Desired order for lookup
- Default value for the UI element
- Seeded values for look ups (more detailed than domain values found in standard data dictionary)
- Likely growth of the look up
- Recommended next cursor control movement
- Value of the current UI element is dependent on another field.
- Any specific behavior to be exhibited by the UI element.
Example of an Extended Data Dictionary
This is an extended data dictionary using a simple prototype of a task tracking user interface and its metadata
Explanations and examples of the extended data dictionary developed for the sample UI:
Metadata Attribute | Explanation | Example |
Type of element | Different types of elements we use on applications. | Can be a text box, a calendar, look up value, radio button etc. For ScheduleID it is Text. |
Data type | Different types of data that the UI element intends to capture | Data types include Number, Character, Date. For ScheduleID this is Number. |
Format | Any specific format expected | For the date format we recommend is DD-MON-YY as it avoids the confusion between British and American date format. |
Size | Size of the UI element to be stored in database | For example, Description field can be up to 100 characters. |
Mandatory | Whether the UI element is mandatory | Schedule ID and Status are mandatory, others are not. |
Identifying Key | Unique value that identifies instances of the object | Schedule ID is the identifying key. Identifying Key must be completed in every record. |
Min Value | Allowable minimum value. | Allowable minimum value. |
Max Value | Allowable maximum value. | Allowable maximum value. |
Editable | Whether it is editable or not. | Plan start date is not editable after submitting but the resource name is editable. That means you can assign task to different people over time. |
H Align | Horizontal alignment of the UI element | In US, tend to number align numbers into right where as in middle eastern countries many of them prefer numbers to be Center aligned. |
Validations / Business rules | Validations applicable to a particular field. | Planned start date must be less than or equal to planned end date. Business rules should be referenced from Business Rules Dictionary wherever feasible. |
Lookup Ordering | Desired order for lookup | In an ascending manner |
Default Value | Default value for the UI element | For example default value for Schedule ID can be last ID + 1. Having default values makes the application more usable. |
Look Up Seed Values | Seeded values for look ups | For Status, it can be Open, In-progress and Closed. |
Expected data values | Likely growth of the look up | Lookups can be classified as small (Up to 5), Medium (5 to 20) and Large (More than 20) |
Next control | Recommended next cursor control movement | After Planned Start Date, go to Planned End Date. |
Linked to any other field | Value of the current UI element is dependent on another field. | For example, a state user element will be determined by Country field. |
Field Behavior | Any specific behavior to be exhibited by the UI element. | For example providing tool tip for the UI element. |
Conclusion
An extended data dictionary can be a simple yet powerful technique to develop UI intensive applications. It is also extensible for specific domain needs. By capturing additional metadata in a commonly used document, all business analysts can realize significant improvement in their requirements discovery and management.