Why Bother With A Data Dictionary?
/
A data dictionary holds data about the fields in a database, such as field definitions, meanings and allowable values that reflect how data is used within a domain or organization. It provides a standard definition of data that can be shared across different stakeholder groups so that everyone is on the same page about what each data element means.
According to the BABOK Guide, the data dictionary can be regarded as a metadata repository used to manage data to be employed by software applications. It can be maintained using spreadsheets.
Composite data elements can be built using a combination of individual/primitive data elements, which can be used to indicate sequences and repetitions. For example, a sequence can be built for the composite data “Full name” by combining “Title + First Name + Middle Name + Last Name”. Optional elements may also be defined as part of the composite data definition. For example, “Middle name” can be defined as optional.
Other pertinent pieces of information that can be stored in a data dictionary include data type (text/integer, etc), source of data, applications that require the data, relationship(s) with other fields, default values, access restrictions, length/size of data, nullability, optionality, data validation rules, and so on.
Why Bother?
Data dictionaries are useful for communicating with users based on a common vocabulary and definitions of shared data; sharing insights into data types and controls; and mapping data fields in one system to another. The information in the data dictionary is particularly useful to those who build applications that use the data.
User story maps are an interesting and collaborative way of eliciting user requirements. One of the reasons why I find it so powerful is because it provides a unique approach for aligning discussions relating to the user, their goals, the process that supports the accomplishment of their predefined goals; and the requirements that need to be addressed to solve business problems.