Affiliated with:

Extended Data Dictionary Approach and Benefits

Extended Data Dictionary

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

NameA unique name for data element.Example: Prefix, First Name, Middle Name, Last Name, Suffix
AliasesAlternate names for data element. 
ValuesList of acceptable values (domain), if this element has a domain of values associated with it.Example for the element Prefix: Mr., Ms., Dr., Mrs.
MeaningsIf abbreviated, include explanation. 
DescriptionDefinition 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.

SequenceShow primitive data elements in specific order.Name: First Name + Middle Name + Last Name
RepetitionShows that one or more primitive data elements occur multiple times in composite element. 
Optional elementMay 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:

  1. Format (Any specific format expected for the UI element)
  2. Minimum Value (Allowable minimum value).
  3. Maximum Value (Allowable maximum value).
  4. Editable (Then whether it is editable or not and up to what development stage element can be edited).
  5. Horizontal alignment of the UI element
  6. Validations / Business rules applicable to a field.
  7. Desired order for lookup
  8. Default value for the UI element
  9. Seeded values for look ups (more detailed than domain values found in standard data dictionary)
  10. Likely growth of the look up
  11. Recommended next cursor control movement
  12. Value of the current UI element is dependent on another field.
  13. 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

Extended1
Extended2
Extended3
Extended4

Explanations and examples of the extended data dictionary developed for the sample UI:

Metadata AttributeExplanationExample
Type of elementDifferent 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 typeDifferent types of data that the UI element intends to captureData types include Number, Character, Date. For ScheduleID this is Number.
FormatAny specific format expectedFor the date format we recommend is DD-MON-YY as it avoids the confusion between British and American date format.
SizeSize of the UI element to be stored in databaseFor example, Description field can be up to 100 characters.
MandatoryWhether the UI element is mandatorySchedule ID and Status are mandatory, others are not.
Identifying KeyUnique value that identifies instances of the objectSchedule ID is the identifying key. Identifying Key must be completed in every record.
Min ValueAllowable minimum value.Allowable minimum value.
Max ValueAllowable maximum value.Allowable maximum value.
EditableWhether 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 AlignHorizontal alignment of the UI elementIn 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 rulesValidations 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 OrderingDesired order for lookupIn an ascending manner
Default ValueDefault value for the UI elementFor example default value for Schedule ID can be last ID + 1. Having default values makes the application more usable.
Look Up Seed ValuesSeeded values for look upsFor Status, it can be Open, In-progress and Closed.
Expected data valuesLikely growth of the look upLookups can be classified as small (Up to 5), Medium (5 to 20) and Large (More than 20)
Next controlRecommended next cursor control movementAfter Planned Start Date, go to Planned End Date.
Linked to any other fieldValue of the current UI element is dependent on another field.For example, a state user element will be determined by Country field.
Field BehaviorAny 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.

LinkedIn
Facebook
Twitter

LN Mishra

LN Mishra has over 25 years of professional experience in requirements analysis, business analysis, agile software development, and IT GRC. He was also involved in multiple large ERP implementation projects. LN was involved in one of the world’s largest change management program at PricewaterhouseCoopers, for a large utility agency.

LN has conducted 200+ workshops in business analysis, requirements management, agile, software project management, and Six Sigma. LN has mentored more than 400 business analysts to be professionally certified from IREB® and IIBA®. LN’s interest lies in making requirements engineering understandable to new requirements analysts and improving their work quality using appropriate techniques and templates. LN holds a Post Graduate Diploma in Management (PGDM) from IIM Ahmedabad, and BE (Honours) in Electronics.

© Since 1997 to the present – Enterprise Warehousing Solutions, Inc. (EWSolutions). All Rights Reserved

Subscribe To DMU

Be the first to hear about articles, tips, and opportunities for improving your data management career.