Re: Data Dictionary

[Michael Lewis <lewism -at- BRANDLE -dot- COM -dot- AU>]

To be effective, a data dictionary should incorporate some of the
features of a data flow diagram: it should indicate what programs /
functions create, change, or use each of the data elements. Otherwise,
spot on.

Matt Danda wrote:
>
> Michelle:
> In my experience, a data dictionary is simply a table describing
> fields. For example, one data dictionary I use only has the columns:
> Field Name, Length, Type, and Description.
>
> To me, creating a data dictionary consists mostly of the grunt-work of
> gathering multiple bits of information and cutting-and-pasting them
> into a nice table format. Sometimes this information comes straight
> from the programmers or the code, but it can also require a formal
> information-gathering process including JAD sessions and SME
> interviews.
>
> The amount of work required depends on the size of the application and
> where the information comes from. Sometimes it's merely a matter of
> assembling a Word table from a programmer's email. Other times, you'll
> need to behave like a business analyst or QA engineer in order to
> gather the data to build the table. Either way, I doubt they require
> much *writing*. Unless you count the short descriptions you put in the
> tables.
>
> Cheers,
> Matt Danda
>
> ==
> Matthew Danda
> Technical Writer in Software Development
> Orlando, Florida
>
> _________________________________________________________
> DO YOU YAHOO!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>

--
Michael Lewis
Brandle Pty Limited, Sydney, Australia
PO Box 1249, Strawberry Hills, NSW 2012
Suite 8, The Watertower, 1 Marian St, Redfern 2016
http://www.brandle.com.au/~lewism
Tel +61-2-9310-2224 ... Fax +61-2-9310-5056