Like you, I have used the data dictionary as an artifact, but managed it within and as part of the the requirements.

The differentiator I’ve used in the past for glossary vs. dictionary is as follows: If it is an industry standard term (like “gross margin”), a definition or reference is included in a glossary of terms (which is explicitly informative, but not an artifact). If it is a company-specific term, calculation or reference (like “shipping costs are based on weight”), it is part of the data dictionary – as a definition of how to calculate shipping for this customer.

On the projects where I’ve used OOA in addition to structured requirements, the OOA diagrams have been reference documents for clarification and understanding. The diagrams can be so informative, but their lack of atomicity makes them almost impossible to manage in a requirements system.

If you or anyone knows a better or different way to manage the diagrams, please add a comment and let us know.

The examples in your post could have been examples for items in a glossary as well as items in a datadictionary as well as descriptions given for the UML model. In our products, we usually declare only one of them to be used as true requirements.

Could you elaborate more on the differences and when you use each of these three?

I’m used to using the datadictionary as a design artifact, do you?. Do you propose you use native (database) datatypes in your datadictionary?

BTW,
A Nice way to add documentation to a UML model is the use of OCL, Object Constraint Language, which allows a VERY precise specification of all kinds of business rules.

Harry Nieboer