Subscribe to DMU

Search DMU Library


Extended Data Dictionary Approach and Benefits

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. This article examines how 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 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:

  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.

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

Metadata Attribute



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.


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 of the UI element to be stored in database

For example, Description field can be up to 100 characters.


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.


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 Busienss Rules Dictionary whereever 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.


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.

Share on linkedin
Share on facebook
Share on 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.

Subscribe To DMU

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