6.5 Data Longevity Requirement Pattern


6.5 Data Longevity Requirement Pattern

Basic Details

Related patterns:

Data archiving, comply-with-standard

Anticipated frequency:

Rarely more than two or three requirements; in many systems, none at all

Pattern classifications:

Affects database: Yes

Applicability

Use the data longevity requirement pattern to specify for how long a certain type of information must be retained or for how long it must be available with a given degree of ease.

Discussion

Data longevity requirements are often needed to satisfy legal obligations, accounting rules, or other regulatory demands. For example, a company is normally obliged to keep financial records for a certain number of years. There are two ways of approaching data longevity requirements: either do what the customer tells you, or take a systematic look at the whole system. Doing what you're told is easy, and writing a longevity requirement is straightforward enough and usually arises from a clear need. Looking at the whole system isn't hard either but involves a bit more thought.

Data longevity has three distinct variants. The first covers how long data must remain online, the second how long it is to be stored somewhere, the third how long it is to be stored offline. In this context, online means stored in the main system (typically in its database) and directly accessible by it, and offline means stored somewhere else, such as on a backup tape. Although these three variants look almost identical, the first and third are very different in implementation and the second is a mixture of the other two. Use the third option only if you have a clear need for it; otherwise use the second option.

Requirements that determine when data can be deleted are rare, which is rather odd when you think about it. The result is that the timing of data disappearing is driven by technology (how much space is available, and what the database lets you do-for example, by enforcing referential integrity) and by developers' choices. Technical rather than business considerations reign, which is not ideal. A few other requirement patterns make their own suggestions, as piecemeal contributions in their own areas. Here are a couple of default rules for which requirements could be written:

  1. Retain all transactions online for a stated length of time (90 days?) after each transaction's latest date.

  2. All data must be retained offline for an indefinite period. Never throw anything away. (Why would you? Well, except if you've got something to hide, and we'll naïvely assume you haven't.)

Online longevity steadily shrinks in importance as disk capacity steadily grows and becomes cheaper. For some systems this is balanced by exploding ambition, most prevalently by launching on the Web to sell to the world. Online longevity requirements retain usefulness as an expression of for how long data is wanted, even as it loses its practical importance with the ability to retain data for far longer. Retaining all data online indefinitely is an option worthy of serious consideration. (It happens by default in many places because no one's thought of going to the trouble of deleting unwanted data.)

Content

A requirement that defines data longevity should specify

  1. The data it relates to This may be a narrow type of data or a broad category. Either way, make it clear what the requirement applies to.

  2. The manner of storage How must the data be stored, or how conveniently must it be available, until it is eligible to be removed? Normally, this should be expressed only in general terms, such as "online."

  3. The length of time to retain the data After how long does it become acceptable to remove (or lose) the data? "Indefinitely" is a valid option.

  4. The duration start trigger When does the clock start? What is the length of time measured from? It's usually from a date associated with the item itself, such as the date it was deleted. For a transaction, it might be the date it occurred.

  5. The action at deadline For online longevity, be clear about what is to happen when an item of data reaches its time limit. This affects the implementation approach to take. The common options are as follows:

    1. It can be retained for longer ad nauseam. That is, the requirement merely specifies a minimum, and it's perfectly acceptable to keep it for longer-or much longer, or forever.

    2. It can be retained for a moderate extra period-perhaps the end of the day in question or the end of the month.

    3. Once it reaches its time limit, it must become invisible to at least some users (for example, customers). It can be physically removed later.

    4. It must be promptly removed at the deadline.

    When deciding, aim to avoid users perceiving the system's behavior as arbitrary. If old transactions are sometimes gone in a day but other times stay around for a week, users are liable to become confused and lose a little faith in the system. Users are more contented if they understand what's happening.

    If data is to be copied elsewhere before removing it, use the data archiving requirement pattern to specify the copying activity.

  6. Purpose Why do we want to keep this information for this length of time? Data longevity is sometimes mandated by law, industry practice, or company policy. If so, cite that source and identify where it can be found (its location) in the manner described in the comply-with-standard requirement pattern.

Template(s)

Open table as spreadsheet

Summary

Definition

Store «Data description» «Storage form» for «Duration»

«Data description» shall be stored «Manner of storage» for «Retention duration» from «Duration start trigger». [When data is eligible for removal, «Action at deadline».]

«Storage purpose».

Example(s)

Open table as spreadsheet

Summary

Definition

Store orders for 90 days online

Customer orders shall be retained online for 90 days from the date the order was shipped.

Orders shall not be visible to customers after this date, but they may continue to be stored online.

The purpose of this is so the details of an order are easily available in the event of a problem with delivery.

Store transactions for 12 months

All transactions shall be retained for at least 12 months.

Seven years' financial data

Financial data shall be retained for at least seven years (for legal reasons).

For the purpose of this requirement, financial data is any information that pertains to the payment of money from one organization or person to another, or an obligation to pay money, including all information needed to calculate or otherwise justify such an amount of money.

(Storing tape or other offline backups of the relevant data is deemed to satisfy this requirement.)

Extra Requirements

None.

Considerations for Development

A data longevity requirement simply states for how long a particular class of data must be retained. Developers are at liberty to archive it (as per the data archiving requirement pattern), even if no data archiving requirement has been written.

Considerations for Testing

Because data longevity periods tend to be long (often years), you won't be able to wait for test data to grow that old. Two ways round this are

  1. Keep changing the system's clock so that you can simulate time passing very quickly. This is liable to annoy anyone else who's using the system or the machine(s) it's running on, so this kind of testing might need a dedicated system to itself.

  2. Devise a way to created back-dated data. This means the data is somewhat artificial, so check carefully that the tests adequate mirror real "old" data. You also need to take care that whatever means are used to create back-dated data are not available in the production system.

Test whether it's possible to delete an item of data prior to the date until which the system is obliged to retain it.

Create data items that are eligible to be deleted on a range of dates, including all likely boundary conditions: the first and last days of several months, the first and last days of several years, the February 29th on a leap year, weekend days, public holidays, days on which the system wasn't running. Then check whether each item of data is deleted when it should have been.




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