6.2 Data Structure Requirement Pattern


6.2 Data Structure Requirement Pattern

Basic Details

Related patterns:

Data type

Anticipated frequency:

Fewer than 10 requirements

Pattern classifications:

Pervasive: Maybe; Affects database: Yes

Applicability

Use the data structure requirement pattern to define a compound data item (one that comprises multiple individual pieces of information) that occurs in more than one place or that contains too much to define neatly in one requirement. A requirement for a data structure is used to avoid repetition (and the consequent risk of inconsistency), both in the requirements specification and to encourage the same in the implementation.

Discussion

A data structure, as far as requirements are concerned, is a logical definition of a collection of pieces of information. It does nothing useful on its own. It defines no storage or functions. It's merely a building block that other requirements can refer to, to save them having to define this structure for themselves.

Ordinarily a data structure requirement isn't the place to specify which items of information are mandatory, which are purely optional, or more complex rules (such as "either A or B must be present"). That's because the data structure might be used in multiple places, each of which needs to apply different rules.

Content

A data structure requirement needs to contain

  1. Name, to sum up what the data structure represents.

  2. A list of items of information, each of which is a textual description for one of the following:

    1. A previously defined data type-that is, one that has already been defined using a requirement (for which the data type requirement pattern can be used).

    2. A description of a data type, that defines the data type itself. See the data type requirement pattern for details of what to say here. If it runs to more than two or three lines, consider splitting it off as a separate requirement.

    3. Another data structure, either by referring to a requirement that defines it or by defining it in situ.

    4. A list of items, all of the same type, each of which is one of the previous types of item.

    The sequence in which items appear in the list is not significant. For example, there is no suggestion that this is the sequence in which they would appear in a data entry screen. You might find it worthwhile stating this explicitly in the requirement. Order the items for readability, with the most prominent items first and related items grouped together.

Don't attempt to decompose data structures into smaller pieces: that's part of the design process. If you find you need to pull part of a data structure out into its own requirement to avoid having to define it more than once, or to stop a requirement getting too big, that's fine-but only do so for those reasons.

Template(s)

Open table as spreadsheet

Summary

Definition

«Data structure name»

«Data type description» shall comprise the following items of information:

  • «Data item 1 description».

Example(s)

Open table as spreadsheet

Summary

Definition

Personal name details

The name details for a person shall comprise the following items of information:

  • Given name

  • Middle name(s)

  • Family name

  • Initials

  • Title

Personal contact details

The contact details for a person shall comprise the following items of information:

  • Personal name details (as defined in the previous requirement)

  • Address

  • Work telephone number

  • Home telephone number

  • Mobile telephone number

  • Fax number

  • Pager number (used for employees only)

  • Email address

Extra Requirements

None.

Considerations for Development

In an object-oriented programming language, a requirement for a data structure suggests the presence of an equivalent class.

Database designers can consider whether the structure deserves its own database table. Database designers also need to be aware that this requirement pattern permits lists of items to be present in a data structure-because it's a convenient way to describe them. Such structures must be normalized during the design of the database.

Considerations for Testing

A data structure cannot be tested directly, only via other requirements that refer to it. Check that all requirements that refer to a data structure are consistent with it. The system as implemented might also have additional functions not explicitly mentioned in the requirements that use a data structure. Test these functions against the data structure requirement, too.

Look for places in the system that should use the data structure but don't. For instance, are there any functions that ask for entry of values pertaining to a particular data structure but don't show all the values?




Microsoft Press - Software Requirement Patterns
Software Requirement Patterns (Best Practices)
ISBN: 0735623988
EAN: 2147483647
Year: 2007
Pages: 110

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net