Requirements for specific sorts of information define both the data needed to operate the business and any associated functionality. But there are several areas, common to all types of information, for which extra requirements are sometimes appropriate or for which it is worthwhile to specify supporting functionality once rather than each time. Some areas to consider are:

The subsections that follow deal with each of these areas in turn—except Areas 5 and 6, which are covered in the approval requirement pattern in Chapter 11 and the inquiry requirement pattern in Chapter 8. Areas 1 and 6 are likely to be relevant in all commercial systems; ask yourself whether the other areas apply to your system.

Information Integrity, Including Database Back-Ups and Restore/Recovery First of all, what do we mean by "information integrity"? It can be summed up by the ACID properties possessed by any reliable database, which are: atomic—any change is made either completely or not at all; consistent—whichever way you look at the data, you get the same picture; isolated—no change is affected by any other change that's in progress but not yet completed; and durable—any completed change stays there. Backing up the information can be regarded as providing durability even when a storage disk is lost. Restoring is the act of copying from a back-up when the main data is lost, and then recovery is the act of bringing the restored data up to date using an update log of changes made since the back-up was taken.

Strictly speaking, if we want information integrity at all, we should define requirements for it. But if we're storing our data in a proper database, it's reasonable to assume that it will take good care of our data and guarantee its integrity. (If you're not happy with that, then by all means specify requirements you expect your database product to satisfy.) This isn't true for other places where information is stored: flat files provide no protection against data loss, for example. Developers like using flat files for such things as configuration parameters and imported/exported data, and they often forget about the integrity of this data—so it's a good idea to add a requirement to demand the integrity of all data, and emphasize that this includes flat files. Such a requirement can also demand (implicitly or explicitly) that any online directory (such as LDAP) or similar product that you use must store its data in a proper database.

You could draw up a list of all the types of information in your system (taking a broad interpretation of "information" for this purpose), including:

Then go through the list asking what would happen if you lost the disk on which those files live. Bear in mind that even if you have back-up copies of these files, you will lose all changes made since the last back-up copy. If some of the possibilities scare you, take steps to protect against them—for which you need to define some requirements. The more of this information you can store in a database, the better.

Here are some suggested pervasive requirements for this area. The first one is uncompromising, and is impractical for some systems and over-the-top for others. The second one is a gentler alternative—but its laxness still means that a disk failure could leave an unpleasant mess (though you will at least know how big a mess). It's possible to specify a compromise in between these two.

Multi-Part Information Entry Have you ever bought anything from a Web site that involved a longer succession of Web pages than you expected, and just when you thought you'd entered everything, they hit you with yet another page? Then you quit because one little piece of information isn't at hand, and when you returned later, you had to start from the beginning again? Or you couldn't tell whether your order was in there somewhere, and if so, what state it was in? Systems abound that give an unpleasant experience through lack of consideration for their users—for example, by not accommodating users who deviate from the expected path. The main reason is neglect that can be avoided by specifying suitable requirements. (One could argue that use cases that emphasize the primary path can be partly to blame. Also, having to write a second use case to cover the completion of a half-finished process is somewhat tedious, and hard to in an easy-to-follow way without repetition.)

Things that can be done to improve multi-part information entry include:

If you want the system to do any of these things, write requirements for them. Here are a few sample extra requirements that apply to all multi-stage data entry functions:

You could write a version of any or all of these requirements to cover a specific function instead of all of them.

Co-ordination of Multiple Data Stores This means co-ordinating your system with one or more other systems, when each system stores data for itself. Imagine you're specifying a system for a Web-based retail site (a Web shop). You subcontract some products to a supplier, by passing a suborder to them. What happens if either your system or the supplier's system fails while in the middle of processing an order? Systems can be built to deal with situations like this—but if all the possible failures aren't recognized and handled, you could be in trouble when one that you don't accommodate occurs.

Requirements shouldn't worry about how to co-ordinate the updating of data in multiple systems. But they should identify what each system involved must be able to do to play its part, especially in the area of resilience. This is particularly important for each system to which we're interfacing, for various reasons. First, any external system is outside our control. Second, it might already exist. Third, it might require modification, even if it otherwise has all the functionality we need of it—it might already handle a "here is an order" message, but not "did you get this order?" or "delete this order" messages. Fourth, it might not be modified quickly enough. Fifth, it might be expensive to modify. Sixth, it might not be within our power to have it modified at all. In short, the implications could be significant, and they need to be brought to light as early as possible.

For each type of action that involves two or more systems, nominate one system—usually the first one in which data storage occurs—as being in charge. This system is responsible for three things in addition to its own processing:

If the system we're specifying is the one in charge, specify requirements to cover these three things to our satisfaction. If our system isn't in charge, write requirements to cover what the system in charge expects of us. (But don't be surprised if it expects nothing, because systems poorly built in this respect are abundant.) Usually, one system is in charge for all types of actions, but it is possible for one system to be in charge for some actions and another system to be in charge for others.

Let's reiterate that the steps described in the previous paragraph must be performed for each type of action that involves two or more systems—although in practice, the number of types of action is usually very small—perhaps only one. While completing incomplete actions must be done in action-specific ways, the initiation of them can be grouped together. So, when we know that an external system that failed is now back, we could have a single function that initiates completion of all types of incomplete actions involving that system.

One way to provide integrity for transactions that span multiple databases—and one that avoids having to figure out all this messy co-ordination for ourselves—is to use a transaction processing monitor product (usually called a TP Monitor), but this can be impractical for technical, performance, cost, or business reasons.

A couple of further subjects you might want to consider are:

Here are a couple of sample extra requirements for a Web shop customer order transaction:

Timed and Co-ordinated Changes A timed changeis a change to information that needs to occur at a precise, predetermined moment in time. For example, switching to or from summer time might need to happen at precisely 2 a.m. on a designated Sunday morning. And moving the Ruthenian Dinar across to the Euro might need to be done at midnight on a published date.

Co-ordinated changesare a collection of related changes to information that all need to be applied at exactly the same time. When a retailer changes its pricing schedule—raising some prices, lower others, modifying discount rates, introducing a range of special offers—it won't want them to be done in dribs and drabs; it'll want them all to happen at once.

Timed changes and co-ordinated changes have much in common with each other (including the possibility that a set of co-ordinated changes could happen at a specified time), which is why they're dealt with together in this section. Both also have much in common with the approval of actions (the subject of the approval requirement pattern)—first, because all involve the need to store the details of actions before acting on them, and second, because we might want to approvetimed or co-ordinated changes before accepting them.

Innumerable systems have managed to get away without proper provision for timed and co-ordinated changes. After all, making changes manually at the right time, and a set of individual changes one after the other offers only a tiny window during which the system doesn't behave exactly as it should. The hope is that no one will notice. In the main, that's true—and if something should go askew, it might not be tracked to its actual cause. Also, if your system doesn't need 24-hour-a-day availability, you can make these changes when nothing else is happening. But if you need to make such changes while users are active, and you don't want to risk something like this going wrong, take the trouble to see that these changes are made properly. While there is a tendency for more systems to be available at all times, the mentality of system builders has lagged behind: nearly all seem unaware of all the implications—and the extra functionality that such systems need.

A further reason for allowing timed changes and co-ordinated changes to be entered beforehand is so they can be reviewed and checked, and any mistakes can be corrected—that is, to reduce human error. (This is also a reason for having them approved, too.) In any case, changes made in the wee small hours by whoever's working that shift, based on scribbled notes left by someone else, sound more at risk of human error than most.

Even if you manually make a timed change at the right time, you're still likely to need to know what the previous value was and when it was changed. For example, if a sales tax rate is changed at midnight on a certain date, we still should be able to calculate sales tax amounts on orders placed before this date. Again, systems have managed to survive without being able to do this—by performing calculations immediately—but it's untidy: it's hard to justify (say, for audit purposes) what the system did, and if any mistake was made, it's difficult to rectify. (You'll probably have to go, cap in hand, to the developers whose omission led to the problem in the first place.)

Timed and co-ordinated changes most commonly apply to changes in configuration, but they can happen to other types of information. Indeed, they could conceivably apply to any type of function. But worry about that eventuality only if and when you encounter it.

Timed and co-ordinated changes are another area in which lurk all sorts of easily forgotten things, including:

Once you've discovered one thing for which approval, a timed change, or a co-ordinated change is needed, your eyes are open to spotting more. As soon as you have more than one of these things (or if you see prospects for introducing more in the future), it can become worthwhile to introduce a general mechanism for storing actions that aren't ready to happen. Such a mechanism can be used as the basis for approvals, timed changes, and co-ordinated changes, as well as combinations of them. This involves creating a place where you can store any kind of pending action you wish and a range of functions for updating and viewing it—for which you need to specify requirements. But ask for a general mechanism of this kind only if it's worthwhile, because it's a big and complicated undertaking.

Here are a few requirements for timed and co-ordinated changes:

Use the living entity requirement pattern to define a type of entity for which information is stored and which has a lifespan (that is, is created, can be modified any number of times, and eventually terminated).

Do not use the living entity requirement pattern for any entity that is part of the system's configuration; use the configuration requirement pattern instead.

A requirement for a living entity is primarily to define the information that needs to be stored for it (field by field), as well as related details such as how each entity can be uniquely identified (using IDs or other keys). Secondarily, a requirement for a living entity can also cover functions for editing (adding, modifying, and removing) and viewing an entity; these can be achieved either explicitly, or implicitly by the use of pervasive requirements that mandate such functions for all living entities. However, if there's anything particular to be said about any one of these functions, write a separate requirement for that function.

A requirement for a living entity must define at least:

See also the Extra Requirements section in the introduction to this chapter.

There are several kinds of pervasive requirements that can be written to apply to all living entities, to avoid having to specify them repeatedly for each type of entity. These are:

Here are sample pervasive requirements for some of these things:

Follow-on requirements (for a specific living entity) can also be written for any of the first three kinds of pervasive requirement, regardless of whether a pervasive requirement has been written on the same subject. A requirement can override any of the pervasive requirements by stating which of them does not apply to a particular living entity or class of living entities. Similarly, for any of these standard functions, a requirement can be written to describe features needed by a particular type of living entity (or class of living entities). This requirement would then override the standard function as specified in the pervasive requirement. If you do this, check that it's clear that only one function of each type is needed for each type of entity: you wouldn't want developers to build one to satisfy the pervasive requirement and another for the specific requirement.

Even if no pervasive requirements have been specified for the topics discussed in the previous Extra Requirements section, you might regard some of them worth acting upon—simply as good practice.

Check that add, modify, remove, and inquire functions exist for every living entity. There might be more than one function for each of these four things. A suitable range of tests needs to be prepared for each of these functions.

Use the transaction requirement pattern to define a type of event in the life of a living entity, and/or a function for entering such a transaction.

Transactions are the lifeblood of any commercial system: they're usually where the money comes from. So handling them well is critical to a system's success. A system might have only a small number of types of transaction, and it might take surprisingly few requirements to specify them; even so, it's important to get these few right. Examples of transactions: a purchase from a Web retail site, renewing a magazine subscription, making a successful bid at an auction.

A transaction is a representation of something that happens at a point in time. For most kinds of transactions, this is clear and straightforward. A bank customer requests a cash withdrawal, which is deemed to take place the moment the cash is handed over. The transaction's details are fixed at the moment it is deemed to happen. This is an important rule: systems that break it are asking for trouble sooner or later. After the bank customer has walked off with their cash, the bank can't play around with the amount withdrawn or pretend it was paid from someone else's account: changing any of the transaction's details would be incorrect. If a genuine mistake was made (such as the wrong customer's account being debited), the only way to fix it is by means of one or more further transactions. Who'd trust a bank that did otherwise? (The purpose of the first pervasive requirement in the Extra Requirements section is to enforce this rule.)

A simple after-the-fact record that some event occurred (for example, an entry in a log or in a change history of a living entity) is not a transaction for the purposes of this requirement pattern; it is categorized as chronicle information (as defined in the introduction to this chapter).

Now for another subtlety to worry about! If a transaction doesn't happen immediately, and its processing uses one or more configuration values, consider what to do if one of those values changes after the transaction was entered but before it happened. For example, if our Web shop's mailing charges change after receiving an order but before shipping it, should we levy the old charge (which is what we told the customer) or the new one (which is what it'll actually cost us—if we're merely passing this on)? Neither way is ideal. We could do better if the mailing charge changes were entered in advance, but even then we probably won't know beforehand whether shipping will occur before or after the change. A simple solution usually suffices once a situation like this has been spotted, but it's still worth recognizing it in the requirement. A picky, intricate answer is rarely necessary and is a sign that your solution is too complicated—which means potentially fragile and unsatisfactory software.

A requirement for a transaction needs to define at least the following:

See also the Extra Requirements in the introduction to this chapter.

If you're going to specify performance requirements for anything in your system, it's most likely to be for the processing of transactions—because they're usually the highest volume, most visible, most financially significant part of a commercial system. It's illuminating to try calculating daily or monthly volumes for each type of transaction—even if only in a cursory manner, and even if it only serves to point out that you have little idea how busy your system's likely to be. Refer to all the requirement patterns in Chapter 9 for types of performance for which you could consider specifying requirements.

Here's a pervasive requirement to enforce the rule stated previously:

Always adhere to the rule of never modifying any transaction after the fact. And take care processing transactions, because they're important.

Testing that transactions are handled well is perhaps the most important testing of all, because the functions to process transactions tend to be the most heavily used and are highly visible. So testers should prepare a large number of test cases that cover all eventualities. Identify all the relevant permutations that a complex transaction can have, including states, transitions between states, and error conditions. Then build test cases for them all.

Pay special attention to the statement in a transaction requirement about when a transaction is deemed to happen. Test that a transaction cannot be changed after this point. When testing a complex transaction, ask yourself at each stage whether it's clear where you stand: is it obvious whether the transaction has been accepted? Can you tell what you're allowed to change? Are the financial implications spelled out? For example, is it clear to a customer how much they must pay? And are the actual computed consequences what you expected?

Use the configuration requirement pattern to define parameter values that control how the system behaves.

Configuration values are either systemwide or they are associated with configuration entities that behave very much like living entities—but the emphasis is on the values rather than the entities, and configuration requirements tend to reflect this. A systemwide configuration value is one for which there is only one instance: the same value is used everywhere in the system; other configuration values have multiple instances, each one used in a different circumstance. A bank might set a different cash withdrawal limit for each currency; in this case the currency is the configuration entity, and each instance of a currency has its own withdrawal limit configuration value.

A configuration value can exist at one of several degrees of flexibility, which run as follows (from least to most flexible):

A couple of other recurring subjects have special considerations when applied to configuration:

There are two ways of structuring a configuration requirement:

A requirement for a configuration value needs to contain:

A requirement for a configuration entity contains:

Every value in a configurable entity is regarded as a configurable value (we don't count its ID and supporting information such as last-changed-date as "values" in this sense), and configurable values live only in configurable entities. So none of the values in any living entity (say, a customer) constitutes part of the system's configuration.

The first template here is for specifying a single configuration value; the second is for a whole configuration entity.

See also the Extra Requirements in the introduction to this chapter.

Here is a pervasive requirement to enforce a "no hard-coding" rule:

Here are a few basic requirements to facilitate preventing configuration values from being edited at the wrong time:

These requirements do not pretend to be adequate for proper system management.

Consider the effect of changing each configuration value while the system is running. If this might cause problems, take steps to prevent damaging changes from being made. Also publicize the potential danger, so everyone who ought to know does know and so that it is properly documented.

Introduce extra configuration values if you need to; it's perfectly natural for extra ways to control the system to arise during development. Don't hard-code values. Again, publicize any new value and have it properly documented.

The testing of the basics of configuration—adding, modifying, removing, and viewing values—is essentially the same as for living entities. But once that's been done, test the effect of changes of configuration upon the functions that use it. As has been noted previously, changing certain configuration values can have profound effects—possibly very negative effects. Many of these sensitive things are systemwide variables, so take a look through all the systemwide variables for ones that look dangerous to modify.

Bear in mind that extra configuration values, over and above those specified in the requirements, might have been introduced during design and development.

Use the chronicle requirement pattern to specify that a certain type or range of types of event (occurrence) in the life of the system must be recorded.

Do not use the chronicle requirement pattern to record anything that has a financial role of any kind; use the transaction requirement pattern for them.

One dictionary defines a chronicle as "a record or register of events in chronological order." As a verb, it means "to record in or as if in a chronicle." These match perfectly this requirement pattern's uses of the word: a chronicle is a place where events are permanently stored. You can avoid using the word "chronicle" in requirements, though, so you don't have to explain it to your readers. The aim of chronicling is to build up a picture of anything that happens in the day-to-day life of the system and might be of future interest: like built-in closed-circuit television cameras. Its primary use is to assist investigation when something goes wrong—whether it be a software problem, employee fraud, attack by hackers, or hardware or other kind of failure. Chronicles can also yield a wide range of statistics, based on the volumes of different types of events.

This requirement pattern uses the terms event and occurrence interchangeably to mean anything that occurs within the system while it's running and which the system is aware of and is able to act upon. We can chronicle any event (occurrence)—which means pretty much whatever we choose to; it's not restricted to events that trigger some kind of system action. Events can include database updates, errors detected by the system, user actions, milestones in system processes (such as starting up and shutting down), and passing preset thresholds (such as when free disk space goes below a certain level). We also use the verbs to record and to store when talking about what we do with an event; it means the permanent storage of information about the event, which is to remain unmodified and unmodifiable (a faithful snapshot of the event).

Anything that's recorded in a transaction (in the sense used by the transaction requirement pattern) needn't be recorded in a chronicle as well. Conversely, a chronicle requirement merely states that an event must be recorded, not how—so it's quite acceptable to record it in the form of a transaction (provided it is never subsequently modified).

The key features of a chronicle are that it must be:

This requirement pattern makes no judgment about how many distinct chronicles a system has: it might put everything in one, or it might use different chronicles for different things (or separate them for other reasons, such as per company in a multi-company system); that's an implementation matter. Chronicle requirements should do likewise. Nor do we stipulate in what form chronicles are to be stored (such database tables or flat files), though the Extra Requirements section suggests demands that may render some forms unacceptable. That's one reason why we don't use the terms "log" or "logging" here, because it might lead your readers (especially developers) to make inappropriate assumptions—both about what does and doesn't belong in a log and about the implied use of a logging product (which might in fact not satisfy our requirements). Use the words "log" and "logging" in requirements if you choose, but bear in mind that this could influence the implementation by implying a particular kind of solution. For similar reasons, we don't talk about "audit trails," because readers might interpret that in different ways.

It's useful to recognize the difference between occurrences that are related to a living entity and those that aren't, because of their relative volumes. (We'll have a lot more of the former.) Think about how many occurrences of each type are likely to occur.

It's possible (and often convenient) to incorporate the need to record each use of a function in the requirement for that function, but strictly speaking, they are separate requirements (as demonstrated by the fact that verifying the resulting records is a separate testing step). Writing a separate requirement also prompts you to give proper thought to what information should be recorded. You can also write a chronicle requirement that applies to a set of functions. (This, too, sounds like lumping separate requirements together, but they are all of the same nature. It's better to add several apples together than an apple and an orange.) Make a conscious decision at the start of the requirements specification process about which approach you wish to take. Being consistent throughout has the benefit of reducing the chances of some kinds of chronicle entries being neglected.

Individual chronicle requirements concern what events are recorded and what information is recorded about each one. (Functions that enable us to make use of this information are covered in the Extra Requirements section later in this pattern.)

A chronicle requirement should contain:

A relatively extensive list of example requirements is given here to identify a number of types of events that a typical commercial system might want to chronicle and to demonstrate a few variations in approach. As a result, there is a degree of overlap and consequently repetition in these requirements.

There are various types of extra requirements that can be specified for chronicling. They are all easier to apply across the board to all chronicling in the system (or selected parts of it), rather than following on from an individual chronicle requirement. These types of extra requirements are:

The first four of these topics are covered in more detail in the following subsections.

Chronicle Access Control If we control which information each user can access, the same restrictions should apply when that information finds its way into chronicles. After all, we're wasting our time if a user can bypass access control restrictions by examining events recorded in chronicles. (This is in addition to control over who can access the chronicle view functions themselves.) Strangely, this loophole is common in systems, though rarely recognized as such (often because systems administrators keep chronicles to themselves, and chronicles commonly lack detailed information). Here's a requirement for plugging the gap:

The explicit reference to "logs" is just so there can be no misunderstandings on this point. This requirement might look innocuous, but it's likely to have a major impact on the implementation of chronicling: it makes it appreciably more complex and rules out many off-the-shelf products. So don't ask for "proper" access control of this sort unless you really need it—because it won't endear you to whoever has to implement it.

Common Chronicle Features We can only expect chronicles to be chronological, faithful, complete, and reliable if we ask for these things in requirements, as these examples do:

Chronicle View Functions Chronicles that store a wide variety of events are a rich resource that can tell you much about what the system—and consequently the business—has been doing. Functions for viewing chronicles can be divided into the detailed—which show individual events (and can be used for investigative purposes)—and the statistical, which summarize them into totals (for various purposes—including management, marketing, and system load analysis).

The number of chronicles a system has, and what events are recorded in which one, is an implementation matter that doesn't concern the requirements. Consequently, requirements for chronicle view functions cannot distinguish separate chronicles; they must limit themselves to the types of events that are to be shown. However, it is possible for chronicle view functions to include chronological-based information—especially transactions—from elsewhere in the database to give a more complete picture of what was going at the time. The case for doing this is strong if it's a close call whether to regard something as a transaction or a chronicle event.

Severity Levels Should a requirements specification define event severity levels? Defining a complete set constrains the implementation, but defining none makes it hard to describe the severity of a type of event in the requirements. A middle course is best: define a few fundamental severity levels, but allow the implementation to have more. The bare minimum severity levels are "normal" and "severe." Normal is for something that can be expected to happen during the normal running of the system, which is not an error. Severe is for a problem that warrants attention by a person. But you should include at least one level in between these two. Choose different names for the levels if you wish. When devising severity levels, consider differentiating between errors that affect just a single entity (such as one customer) and those that affect the system as a whole—and have separate severity levels for the two types. (The example requirement that follows doesn't do this.) Write a requirement that identifies the severity levels you want. Every definition of a severity level must include a readable description of its meaning.

Take care when assigning the severity level of a type of event. Don't let severe events be neglected, but don't "cry wolf," either. The volume of severe events must be kept small, or their impact will be lost.

Chronicle requirements can specify the severity of particular types of events, but their severities can be defined in other ways—in particular, by making them configurable. This adds a degree of flexibility, but changing severity levels once the system is in production is potentially dangerous and can lead to confusion.

Performance is a major consideration. It's straightforward enough to develop chronicle capabilities but much harder without having an appreciable impact on the processing time of the occurrence being recorded. If possible, use chronicle software already written for this purpose—provided you can find such software that satisfies all the requirements laid down.

Estimate the likely volume of each class of events. Base it on the sizing model, if there is one (and perhaps extend the model). Consider keeping high-volume and low-volume chronicles separate from each other.

Record all occurrences using a timestamp generated by the system itself—because if it came from elsewhere, we shouldn't trust it.

Having as many as possible of a system's activities recorded is of great assistance during testing, because these records provide invaluable information about what happened in the system. So, when reviewing requirements, testers should press for as many types of events as possible to be recorded.

You should cause all the types of events for which chronicle requirements are specified. This can be difficult, especially for obscure error conditions. Insisting that every conceivable condition must be tested is rather picky in typical commercial systems; if you insist upon it, one option is to ask developers to modify the software to allow it to simulate them.

Separate broad-scope chronicle requirements (those that ask for a range of occurrences to be chronicled—according to specified criteria) from specific chronicle requirements; it's clear what to test for the latter. But the former are open-ended; to test such a requirement properly, identify within the delivered system all the functions and occurrences that satisfy the criteria, and then test each one in turn. Both the identifying and the testing could be very onerous.

An information storage infrastructure lets us store information persistently—that is, it's still there when we switch the machine off—and retrieve it later. Information infrastructures vary significantly in their characteristics, and for this reason, a system might use more than one of them, and sometimes more than one of the same type (such as a heavyweight server database plus a lightweight database on client PCs).

The most prevalent kind of storage mechanism for commercial systems is a database. Other kinds are a file system for reading and writing flat files (though there's usually—but not always—little point in saying anything about this as an infrastructure, because it's built in to every operating system and programming language, so it's there anyway); a transaction monitor (if we need to co-ordinate changes made to more than one database); and a document management system (if our system accesses the contents of "documents"). You can also regard information retrieval mechanisms as information infrastructures that make use of information stored elsewhere; these include a directory service (such as one adhering to LDAP) and a search engine (to provide powerful means of finding things). This is a very diverse range of types of products, and we can expect requirements for them to vary accordingly.

What will a calling system expect to be able to ask this information infrastructure to do for it? What kinds of requests will it make? If we're asking for a database, a system will invoke it using standard database operations (of which the most important are the so-called CRUD ones: create, read, update and delete). It's reasonable to assume that any database product will supply these operations, so there's little to be gained by spelling them out. Similarly, we can expect any file system to let us read and write the raw content of any flat file and to read the file system to see what files are present.

We might want the ability to easily replace one product with another. In this case, it might be helpful to go into a bit more detail about how we talk to it—perhaps by mentioning a standard (such as SQL or ODBC, for a database), which will, in theory, let us use any product that adheres to that standard.

One way to look at implementation requirements is to see them as specifying the criteria by which to choose the most suitable information storage (or retrieval) product.

Some behind-the-scenes capabilities that we might want an information storage infrastructure to have are the ability to create back-ups of data and to recover data in the event of a failure (such as losing a disk drive). We might also want to ask for all changes to be atomic (all or nothing), to maintain data in a consistent state, and for each change to be isolated from other changes being made at the same time. (These are three of the ACID properties: atomic, consistent, isolated, and durable—the last of which is implicit in an information storage infrastructure.) Other considerations that might be important include capacity (especially if you need to be able to store huge quantities of data) and security features (such as being able to encrypt data, and access control).

Requirements for any kind of storage infrastructure other than databases must take into account its special characteristics.