Defining Data Items Conrad Weisert (2003)

Size: px

Start display at page:

Download "Defining Data Items Conrad Weisert (2003)"

Phoebe Briggs
5 years ago
Views:

1 Defining Data Items Conrad Weisert (2003) Background -- one more missing component The failed-project documentation I described last month 2 lacked not only output specifications, but, worse, any data dictionary, i.e. a repository containing rigorous definitions of the data items referred to throughout the rest of the documentation. Some, but far from all, of the data items were defined within the body of a use case that referred to the data item. A project team member explained that this is fine, because their methodology (he meant specifically the life-cycle) is "use-case driven". He assured me that this is the natural place for such information, just where a reader would be likely to look for a given data definition. I later found a number of instances where the same data item was defined inside multiple use cases, in slightly different language. Even if no two of them are now in conflict, the perils of future change should be obvious. Why is rigorous data definition so important? Experience shows that misunderstandings about the meanings of data items account for many instances of failed projects, i.e. massive cost overruns, schedule slippages, or worse. Some of those misunderstandings become obvious only in the late stages of system testing and can be extremely expensive to correct. For example: a year-to-date total requires one field in a database, while a 12- month rolling cumulative total requires twelve. The difference may have an impact on processing logic in many parts of a system. a pro-rated insurance premium payment for a policy that starts in the middle of a period, may or may not depend upon holidays during that period. The difference, while small, might lead to a lawsuit when a claim is made. a space probe crashed on the surface of Mars because of conflicting interpretations of the unit of measure of a quantity. Used by permission. Page 1 of 5

2 What kinds of data? In his classic Structured Analysis and System Specification DeMarco 1 calls for rigorous definition of composite data items, but, surprisingly, he ignored the equally vital definition of elementary data items. (Data Item Taxonomy 3 explains the difference.) Every data item referred to anywhere in the documentation must be defined in a data dictionary, unless its name is so self-documenting that its meaning is obvious to every reader with no chance of differing interpretations. Experience shows that surprisingly few data names meet that criterion. Where do we find and identify data items? The system output specifications 4 are an excellent starting point. Once we know what information the system must produce, we can infer what data items are needed to produce that information. The systems analyst should make sure that every field listed in the content of any system output is either rigorously defined in the data dictionary or a simple function of other defined data items. Defining data items is an ongoing process, however. By the end of the requirements definition phase we must have defined every data item of interest to the sponsoring users. Later, during design and programming, project team members will continue to identify and define data items. What data dictionary? If your organization maintains a corporate or global repository of data definitions then you'll probably find some of the data items you need already defined, and your project will contribute some new ones. But if your organization has no such central data dictionary, you'll need to establish a data dictionary for your project. A number of C.A.S.E. tools support (or claim to support) a data dictionary, but even if you can't find a suitable affordable one, you still need a project data dictionary. A simple spreadsheet or even index cards, crude as they are, are far better than no data-dictionary at all. The criterion is understandability, not ease of maintenance. Used by permission. Page 2 of 5

3 Defining a composite data item A composite data item is fully defined by listing its components. DeMarco proposed a notation that some systems analysts continue to use, but any equivalent is acceptable as long as the user-audience can understand it with minimal instruction. DeMarco's notation supported conditional inclusion, alternative fields, and repeating groups. Note that we're concerned here with defining the meaning of data items, not yet with normalizing a relational data model. Here's an example: order = order_number + customer_id + shipping_address + billing_address + 1{order_item}maxItems + [discount coupon] + (credit_card_id cash_payment_record) Based on this definition we can answer a number of questions, such as: Can the system split a single order and ship it to multiple destinations? (No.) How many distinct items can be ordered at a time? (Depends on the value of maxitems, defined elsewhere in the data dictionary.) Will the system support in-house charge accounts? (No.) If those answers are unacceptable, now is the time to find out, not five weeks before the final delivery target date. With the possible exception of credit_card_id, none the component data items has a self-defining name. Further data-dictionary entries are mandatory. Defining an elementary data item While a composite data item is defined in terms of its components, an elementary data item is defined in terms of its exact real-world meaning. That can be expressed in carefully worded text: Used by permission. Page 3 of 5

4 Date Hired: The most recent date upon which the employee reported for work; i.e. the date from which the current or former employee was continuously on our staff. or as a simple formula vacation_days_due = current_vacation_days_earned + carryover_vacation_days - current_vacation_days_used Attributes of numeric data items. If the elementary data item is numeric, then the definition should specify these attributes: unit of measure (Note that the developers are not constrained to use this for the internal representation.) range -- minimum and maximum permitted values in the stated unit of measure (Some old fashioned representation-based tools ask for "number of positions".) precision (or accuracy) -- the smallest significant magnitude in the stated unit of measure scale (float or fixed) Defining a data type -- object-orientation Even if our project doesn't plan to exploit object-oriented technology, we can greatly simplify the data dictionary by "factoring out" common properties and defining new data types in the data dictionary. This eliminates a lot of repetitious redefinition and relieves the systems analysts of the need to make (possibly inconsistent) choices for each data item. For example, when we define streetaddress as a type, we settle once and for all questions about how many lines should be provided, or whether to include the (redundant) state code. We can then define the composite data item shipping_address as simply an instance of streetaddress, and billing_address as either a streetaddress or a P.O._box_address. Used by permission. Page 4 of 5

5 New data types can themselves be defined in terms of other previously defined data types. UML 5 class diagrams can help the audience to visualize the relationships. Further guidance The foregoing is barely a shallow introduction to this complex topic. IDI offers a course 6 that explores data definition in depth. Notes and Links 1 -- Tom DeMarco: Structured Analysis and System Specification, 1978, Yourdon Press, ISBN Used by permission. Page 5 of 5

Ways of documenting Session 5: detailed requirements The Data Dictionary one any The Project A data dictionary Data Dictionary may be maintained

Ways of documenting Session 5: detailed requirements The Data Dictionary one any The Project A data dictionary Data Dictionary may be maintained Session 5: The Data Dictionary relationship to systems analysis methodologies relationship to project management data definition vs. data representation taxonomy of data types COMP 477 /377, Fall, 2018