Data Requirement

Definition

Data Requirement
a.k.a., Content Requirement, Informational Requirement

any requirement that specifies a mandatory data type or datum

Classification

As illustrated in the preceding figure, Functional Requirement is part of the following inheritance hierarchy:

• Type: Abstract
• Superclass: Requirement
• Subclasses:
  • Data Semantics Requirement
  • Data Type Requirement:
    • Attribute
    • Initial Default Value
    • Range (i.e., possible values)
    • Relationship
  • Invariant Requirement
  • State Requirement

Responsibilities

The typical responsibilities of a data requirement are to:

• Specify mandatory visible data types in terms of their:
  • Semantics.
  • Content in terms of attributes and component data types.
  • Relationships to other data types.
  • Invariants concerning attributes or components.
  • State models.
  • External source or destination locations (e.g., a file, database).
• Minimize the amount of redundancy in operational (i.e., functional) requirements by allowing them to refer to common data requirements.

Guidelines

The following guidelines have been found to be useful when producing data requirements:

• Data requirements can be specified in numerous forms, each of which has its own advantages and disadvantages:
  • Logical Data Models such as ERA diagrams:
    • Advantages:
      • Standard notations (e.g., ERA diagrams, UML, OMT) exist that simplify communication and understanding.
      • Logical data models can be easily transformed into physical data models during the production of the data (information) architectures.
      • Logical data models are relatively precise.
      • Logical data models are relatively easy to evaluate for completeness.
    • Disadvantages:
      • Logical data models tend to imply a relational database implementation.
      • It is easy for experts to include design information (e.g., by normalization).
      • It is not easy to identify all data types.
      • Without significant training, customer and user representatives find the models difficult to understand, especially their consequences.
  • Essential Business Object Models:
    • Advantages:
      • TBD.
    • Disadvantages:
      • TBD.
  • Data Dictionaries:
    • Advantages:
      • TBD.
    • Disadvantages:
      • TBD.
  • Data Expressions such as XML Data Type Definitions (DTDs) or Backus-Naur Form (BNF) formulas:
    • Advantages:
      • TBD.
    • Disadvantages:
      • TBD.
  • Simple User Interface Prototypes showing the visible input and output data:
    • Advantages:
      • TBD.
    • Disadvantages:
      • TBD.
  • Informal Lists of Text:
    • Advantages:
      • TBD.
    • Disadvantages:
      • TBD.
• Data requirements should not be unnecessarily specified in terms of architectural, design, or implementation constraints on the data:
  • Data requirements should neither assume nor mandate the existence of databases or of the specific types of databases (e.g., relational or object) to be used. These are either architectural decisions or architectural constraints.
  • Data requirements should only address mandatory, visible data.
  • Data requirements should only address content and semantics, not format. The format of data is either a data design decision, a constraint on a data component, or an external API requirement.