Use the scalability requirement pattern to specify a way in which a system must be able to expand without undue pain, typically to accommodate growth in business volume.

Do not use the scalability requirement pattern to demand a particular level of performance; use one of the performance requirement patterns for that.

Scalability means never having to say you're sorry that the system can't cope with more. Scalability means being prepared when the load on the system increases, having ways to react without resorting to drastic changes or redevelopment. Scalability doesn't happen by accident, and if you don't ask for this ability, don't be surprised if you don't get it. Scalability can be expensive, so if you want it, you'd better be prepared to pay for it. And if don't need it, don't ask for it; when you're building a system for a small environment and the chances of using it elsewhere are low, think twice about whether it's worth it.

A scalability requirement is an instruction to developers to design the system such that it can grow in a particular direction, with no obstacles in its way. It is a signal that the system must not be restricted to any stated business volume.

Scaling is often driven by an increase in a single factor only. In a commercial system, it's usually the number of customers (or, more generally, the number of users). Rarely are there are more factors whose growth independently causes a proportionate increase in load on the system (and, consequently, a need for a separate scalability requirement). For example, doubling the number of products a retail business offers for sale is unlikely to double the load directly. A single scalability requirement usually suffices.

Scaling a system's overall performance is of two main types. First is scaling out, the ability to spread the processing load across as more machines. Second is scaling up, by increasing the power of individual machines. Generally, requirements should be concerned only that the system can scale, without caring how. But an ability to scale out is sometimes worth demanding in requirements because it influences a system's basic software architecture and cannot be retrofitted, whereas scaling up typically doesn't affect the software at all. A system can accommodate a growing load only if the quantity and/or power of its hardware are increased accordingly, in proportion. A system isn't scalable if the hardware needed grows at a faster rate than the load; for instance, if doubling the load demands four times the hardware, we'd soon be unable to keep up with increasing load.

Performance requirements implicitly apply regardless of the extent to which the system has been scaled, unless otherwise stated in either the scalability or performance requirements. This is especially relevant to response time and availability requirements (because we can expect overall throughput and capacity to grow as the system grows): they must not become progressively worse as the system scales. In practice, performance measures are likely to change marginally with the system's load. This is acceptable if it's barely perceptible to users. Nevertheless, if you sense there's a risk that the importance of maintaining performance levels could be forgotten as the system grows, you could strengthen the relevant requirements to make it clear.

Consider flow-on scalability demands upon third parties—that is, all systems you interface to and all third-party products you use. Investigate whether they are all suitably scalable; if they're not, you're in trouble. This applies to products you are forced to use and any the project is at liberty to choose for itself. For the latter, impose our scalability requirements on them too, when evaluating their suitability.

A scalability requirement should contain the following:

Making a system scalable can (and usually does) have significant implications that go beyond simply being able to handle a bigger load. Consider the following topics, and write extra requirements as necessary:

Characteristics That Must Not Degrade with Growth It's sometimes useful to specify that a particular characteristic of how the system behaves must not noticeably degrade as the system scales—that is, as the factor identified in the main scalability requirement increases. For example, regular downtime for housekeeping must not increase in proportion to volume. Do this if you're worried that this area is at risk of being left behind—of performing badly as business volume grows. Explicitly identifying things that shouldn't degrade as the system scales spells out the implications of a scalability requirement. These things can themselves then be examined to see if there are specific steps we can take to help achieve them, as described in the "Steps That Contribute to Scalability" subsection that follows.

Here are a few examples of requirements for this purpose:

Observe that the first three are hard to test. They're intended mainly factors for developers to take into account.

Steps That Contribute to Scalability When thinking about scalability, the emphasis is on performance factors: having enough sheer horsepower to cope with an increasing load, being able to process more transactions, being able to store more data, and so on. But that's not the whole story. All the system's functions must continue to be practical to use as the system scales. Scan all the specified functions to see which ones might involve more work for users as the system grows. Pay special attention to the following areas:

Scaling the Number of Sites A system that scales by being installed in more sites has an extra kind of complexity: how to co-ordinate those sites, both technically and businesswise. A head office and a number of satellites is the most common situation (and the simplest, except for the case of no co-ordination at all). Investigate the relationships between sites and the extra functionality needed: functions used by head office only, data to be sent to head office, dissemination of data to satellites (for example, configuration information that embodies aspects of business rules or corporate policy), and possibly numerous other things.

Then, what kinds of corporate restructuring might happen (such as merging two satellites)? Does the system need to be ready for such eventualities? If no provision at all is made, achieving them later might be very difficult indeed—if, for example, different sites allocate the same customer number to different customers.

Complexity of this kind could go unnoticed if you concentrate on an initial implementation in a single site, so ask yourself whether you need to worry about it. It is important, is bound to have a major impact on how the system is implemented, and must be properly specified.

Scalability can be achieved by choosing underlying technology built to help spread processing load across multiple machines, or it can be achieved by our own software, or by a mixture of both. Distributing loads across machines is a lot more complicated to implement than it at first appears, so use a third-party product to do the hard work for you whenever possible.

Consider whether the scalability being asked for can be achieved by a single database. If not, work through the implications of having multiple databases. How closely do they need to work together? What would need to be done to co-ordinate them? Can the overall system be divided into a number of islands that work largely independently of one another?

Take special care with the design of database tables that are directly or indirectly affected by the kind of scalability being demanded and with the design of functions that maintain this data. Avoid duplicating data for which many entities could share the same values, to save having to modify a value many times (a number of times that increases as the system scales up).

Scalability is difficult to test at all. One exercise is to get the system running and verify that adding extra resources is as easy as it should be. Then test that the new configuration can cope with a proportionately increased load. Measure the actual performance gain as the resources scale. If you get that far, you've done well. But it doesn't prove that you can keep on adding hardware with the same effect. It's unrealistic to test that the system possesses "unrestricted" scalability.

You can probably get a subjective feel for how scalable the system is by talking to the developers about it. What steps have they taken? How did they approach the subject? Are there any design documents that deal with scalability? Have they discovered any potential problems? The depth to which they can answer these questions should give you an insight into how much faith you can place in the scalability of their work.

Scalability is an infinite area. You must determine when you have done enough and are satisfied with the results. Performance requirements can give you a feel for what is a reasonable point at which to stop.

Use the extendability requirement pattern to mandate that a specific aspect of the system be built to make it easy to extend by "plugging in" extra software. In particular, use it in situations where there are (or might be in the future) several different ways of doing things and we want to be able to add more without major disruption.

Do not use the extendability requirement pattern for alternatives that cannot be achieved by slotting in extra software. Common examples are differences achievable solely by configuration, including some multinesses (such as multi-lingual and multi-currency), and variations that affect the system as a whole, such as being able to run on multiple named operating systems (you can't just "plug in" the ability to run on Unix).

An extendability requirement acts as a way to tell developers to build a particular part of the system in a flexible manner so that we can extend it by simply slotting in new software without revamping the underlying architecture each time. Some kinds of flexibility aren't amenable to being treated in this way—including anything that can be regarded as a multiness (according the multiness requirement pattern) and anything that can't be achieved simply by adding software to support it. If you have a fixed list of alternatives that cannot grow, you don't need extendability but it can still be good practice to apply it, because extendability promotes modularity: it's a subtle way of encouraging good design in one area. In any case, it's rash to assume something will never, ever change.

This requirement pattern calls a piece of software that is plugged in a driver, as in a device driver or a printer driver. This term is used only to make this discussion easier to read; requirements themselves don't need to use it. An extendability requirement is invariably followed by at least one requirement for a driver, because without it the ability to extend serves no immediate purpose.

An extendability requirement usually sits amid a sequence of requirements: first a requirement that defines an aspect of the system; second the requirement that this aspect be extendable; and finally one or more requirements for drivers and possibly other requirements (all of which are covered in the Extra Requirements section later in this pattern). The extendability of an aspect of the system can be combined with its definition, but separating them gives the need for extendability added weight and allows it to be given a different priority. This sequence is shown in Figure 10-2.

Figure 10-2. The sequence of extendability-related requirements

Here are a few typical examples of extendability:

Extendability is much more important and valuable when building a software product to be sold to multiple organizations than when building for one organization only. It makes it easier to tailor each installation, without affecting the core product.

Sometimes building in the ability to easily extend in a certain way turns out to be harder than it appeared at requirements time. For example, the things on your list of alternatives might have less in common than they appear; they might vary a lot more. This might not become clear until design time. So there are limits to how much we can expect from extendability.

An extendability requirement needs to cover:

Perhaps surprisingly, extendability requirements tend to be remarkably straightforward, simple even. The main reason is that they should ignore technical details. They merely need to state what we want; how it's achieved is the developers' responsibility.

An extendability requirement can be followed by several extra requirements. There is usually at least one of first type from the list that follows; the others are topics you should give at least cursory thought to, although they're not often relevant:

Driver Type RequirementsHaving a separate requirement for each type of unit to plug in lets us prioritize them individually and gives us space to say whatever's useful about each one. It also reduces the temptation to gloss over each one, which a simple list within another requirement encourages—and it denies us the opportunity to end such a list with an insidiously nasty and unacceptable "etc."

A requirement for a type of driver needs to contain these items:

These requirements tend to be as straightforward as extendability requirements (although the responsibility part can be awkward to express and can end up looking like picky legalese). It's easy to see why: we're interested in only the extendability aspect here; everything needed to deliver it is omitted. That's why further requirements must be written—somewhere—if some kind of supporting infrastructure is needed. Implementing each infrastructure deserves to be a project (or subproject) in its own right, or it might not receive the attention it deserves. In any situation where a large amount of work hides behind one innocuous requirement, it's likely to be given an inadequate budget and to be rushed. Developers are apt to dash out and find the first open source product they lay their eyes on. An infrastructure could be used for other purposes, too.

Any driver whose real work is done by a separate component (such as a third-party product or an external system) acts as an adapter. See the inter-system interface requirement pattern's "Interface Adapters" sidebar (in Chapter 5) for a description of what adapters are all about.

Here are a few example follow-on requirements that specify drivers for notification methods (and notice the stressing of the infrastructures that are needed):

Driver Installation Requirements Installing a driver takes two steps, both of which can be influenced by requirements if you want to:

Here are a couple of example requirements related to the installation and control of drivers:

Third-Party Driver Development Requirements Is anyone outside your development team likely to be developing software to slot in? If so, they'll need to know how to do it. At the very least we have to publish a definition of the interface they must build to, but it's better to insist that a "Driver Developer's Guide" be written for this type of driver. Here's an example of such a requirement:

Requirements very similar to this are also used to allow third-party development of inter-system interfaces, as described in the inter-system interface requirement pattern in Chapter 5. See also the documentation requirement pattern, also in Chapter 5, for more about what to say.

You also need to be alert to the security implications of adding software written by a third party into your system. How much do you trust them? What steps can you take to protect your system? Here are a few suggestions [which indicate, within square brackets, who the work is to be done by]:

Requirements aren't necessarily the best place to state these things, but you could write a requirement saying that precautions along these lines be taken.

An extendability requirement is in effect an instruction to the development team saying, "Build this part in a flexible way; don't hard-code it." Development depends on the type of extendability and the technology being used, so little more can be said here. A few things to bear in mind are as follows:

Treat the testing of a driver the same as the testing of any other software. Much depends on the nature of the driver: testing the saving of data in a pluggable file format is a different matter from testing credit card payments.

If there are multiple drivers, test that the results obtained from each one is compatible with the others. For example, if all drivers are expected to deliver identical results, do they? This doesn't apply to all types of driver. For instance, drivers for saving data in different formats will be expected to produce difference results.

Test adding a new driver. Is it as easy as it should be? When testing the initial system, begin with at least one driver of each type missing and then watch closely as they are installed. Because an extendability requirement is basically a message to developers, talk to the developers about what they've done about it; ask them what they'd have to do to add a new driver.

Test different versions of the same driver. Test upgrading from one version of a driver to the next version. These kinds of tests might not be possible if only one version of each driver exists, which is often true for a new system. If not, quiz the development team about the provisions they have made for upgrading drivers.

Use the unparochialness requirement pattern to specify a particular way in which the system must not be limited to one business environment. The unparochialness requirement pattern says how a single installation of the system needs to be able to adapt to the organization and the place where it is installed.

Do not use the unparochialness requirement pattern to specify that the system must support multiple instances of anything simultaneously (such as multiple currencies); use the multiness requirement pattern, the next pattern in this chapter, for that.

Parochial: narrow in outlook or scope, merely local. So says the dictionary. If you build a system for one organization, that's what you'll get—no more, no less. Don't assume it'll suit any other organization, even one down the road that's in the same business. It's unreasonable to expect otherwise, unless you expressly insist. Yet companies sometimes do: executives impressed by their new system have the bright idea of making money by selling it. But they're probably in for an unpleasant surprise if suitable provisions weren't made in the first place—which is where unparochialness requirements come in.

When building a product or a system for multiple sites, it must suit each of the environments in which it will be installed—or, at least, the system will be much better received (and, for a product, more competitive) if it's not obviously been built for someone else, somewhere else, or for a different market. But also take sensible steps to make a system amenable to installation in other environments it might encounter, without lots of rework, because adding it all later is invariably much harder than incorporating it from the outset.

Look beyond the narrow confines of a single target environment. It's natural for analysts and developers to specify and build systems that they, the customer, and the people they know would like to use—systems for us—and in the main it makes systems more friendly, more complete, and more sensible. But we can't allow this inclination to be our only guide, because we'll then get a system built just for us. People aren't intentionally parochial; when they're parochial, they are without thinking about it. Requirements to make systems less parochial are scarcer than they should be, which probably contributes significantly to systems being harder to implement successfully outside their home environment. This requirement pattern aims to prompt analysts to write requirements on this topic when they otherwise wouldn't.

Specifying unparochialness is a two-stage process. First, identify everywhere the system might be installed—not as a detailed list of installations, but in broad terms. Second, figure out what sorts of variation from one installation to another is needed to accommodate them all. The rest of this section covers the first stage, and the second stage is dealt with in the Extra Requirements subsection coming up.

Write an unparochialness requirement to sum up the scope of prospective installations—a statement of what we have in mind (such as selling to other companies in the same business in the same country). Then, write more detailed requirements to spell out what that really means in terms of specific ways in which the system shouldn't be tied down. But once we have the detailed requirements, the original requirement can be dropped—or demoted to being an introductory statement rather than a formal requirement. In a two-level hierarchy of requirements, the original unparochialness requirement equates to a high-level business requirement, and the rest are detailed requirements.

The first step, then, is to consider where the system might be installed. The most common possibilities are these:

It's worth repeating that we're just talking about tailoring the whole system to suit its local environment—not catering for multiple variations at the same time, which is what the multiness requirement pattern is for. For example, one installation being able to support users from multiple countries at the same time—in multiple languages, multiple currencies, and so on—involves a lot more than just avoiding a parochial outlook. Variable single-thing is not the same as multi-thing. A system that allows its base currency to be configured is definitely not automatically multi-currency.

Don't go overboard, though. Don't demand things that are likely to be expensive to implement but have a low chance of being needed (because they're speculative or no more than a gleam in someone's eye). Also, some things. such as data types, are so fundamental that allowing them to vary from one installation to another is just too hard.

An unparochialness requirement should convey:

The following requirement aims to be a guard against temporal parochialness for all time:

Assuming we've identified (as in the preceding sections) the range of environments in which our system is liable to be installed, we now come to stage two: specifying the implications, in the form of all the possible types of variation from one installation to another. How can we work out in which ways other places do things differently? This can involve considerable investigation. This general purpose requirement pattern can't delve into matters that are specific to a particular organization or industry. But it can mention a number of things that can vary from country to country and common ways in which organizations vary—and it does so in the following two subsections.

One last extra requirement that might be worthwhile is to demand that the system's documentation not be parochial. Here's an example of such a requirement:

Differences between Countries Here is a range of things that vary from one country to another, with some resulting complications mentioned:

This isn't a comprehensive list. It ignores areas that differ functionally from one place to another, such as tax, regulatory, and legal regimes. (Some of these differences can be dealt with by using the extendability requirement pattern we saw earlier in this chapter.) Ways of doing calculations could also vary—for example, bank interest calculations. (See the fee/tax requirement pattern in Chapter 12 and the calculation formula requirement pattern in Chapter 6.) It also ignores variations that are usually of no concern to systems but that just might affect yours, such as national flag, continent, and hemisphere.

You're unlikely to need to worry about all of these things, but run through this list asking yourself whether each one is relevant.

Differences between Organizations Organizations differ from one another in numerous ways, even in the same industry, and it's impossible to do more than scratch the surface here. But you might want to consider these few common topics:

Treat an unparochialness requirement like an instruction not to hard-code this area. That advice doesn't apply in every case: some things need different code to be called in different installations, which means allowing code to be plugged in (as described in the extendability requirement pattern covered earlier).

Properly testing that a system is suitable for installation in the range of places demanded is a major undertaking. A reasonable simplification is to envisage two installations that differ from each other in every possible way. If we have a primary installation, it will be one; make the other as different as you can. This simplification still means we need two full test implementations of the system. If you don't want to go that far, perhaps because secondary installations are a low priority, perform one full pass plus a targeted set of spot checks for selected alternative values. Or try "anecdotal" checking: ask developers what they've done to satisfy the unparochialness requirements, read the documentation for signs that variations are catered for, and run configuration functions to see whether they allow the relevant base values to be changed.

Use the multiness requirement pattern to specify that the system must accommodate multiple something-or-others at the same time, each of which has its own fundamentally distinct user interface or whose data must be kept rigorously apart from that of the others. (See the sections that follow for more detailed explanation of the suitability criteria.)

Do not use the multiness requirement pattern when the system need support only one from a range of alternatives; use the unparochialness requirement pattern in that case. The difference is that unparochialness allows an aspect to vary but the same variant is used systemwide; multiness allows multiple instances of an aspect to coexist at once. Also, do not use the multiness requirement pattern when support for multiple things is natural or built-in.

(Relative simplicity is the reason "multiness" was coined for this pattern's name. "Multiplicability" might be a more logical word to use, but what a mouthful it is.)

A multi-lingual user interface, for instance, is obviously a major undertaking and one that deserves to be dealt with seriously in the requirements (if you need it). It adds an extra dimension to the system, and it is for adding this kind of richness that the multiness requirement pattern is intended. We could say our system is multi-customer, multi-product and so on (multi-anything-with-a-database-table, in fact)—but nothing is gained by doing so, and the multiness requirement pattern is not for them. There are other cases that are less clear-cut. How, then, can we decide whether something is significant enough to warrant a multiness requirement? It must satisfy one or more of the following criteria:

It is possible for something to satisfy more than one of these criteria. For example, a system that supports multiple companies could fall into both of the first two: each company might have its own Web pages, and their data must be segregated. If something satisfies none of these criteria, it's not a multiness. What do we do then? The system still needs to support multiple of them in some way or another—but don't apply this requirement pattern to it. Examine its characteristics and define requirements for them. I suggest reserving the prefix "multi" in a requirements specification for things that are multinesses.

A multiness requirement is not necessary if an extendability requirement will suffice (which it will if we're able to support multiple things by plugging in extra software for them). Sometimes multiness goes hand in hand with extendability and you might need both—for example, in a system that supports multiple companies, each of which can slot in its own special software in certain areas.

No kind of multiness is trivial to implement. You can never say "The system shall be multi-whatsit" and leave it at that. You must spell out precisely what you mean: how much multi-whatsit support you need, and how far you want to take it. Different systems might treat multi-whatsit in very different ways—and quite right too, if they have different circumstances. Sometimes we have just a façade of multiness, not the real thing. That's good, because it means there's less work to do. For example, if a Web retail site wants to display indicative prices in a customer's currency of choice, that could be merely a little candy on the user interface that doesn't affect the main processing or the database—so it doesn't count as multi-currency because the difficult bits are missing (even though we need a few of the easier bits, such as knowing exchange rates).

This book contains specific requirement patterns for two types of multiness that are commonly encountered: multi-lingual and multi-organization unit (for multi-company, multi-office, multi-department, and such like). The latter resides in the commercial domain (that is, in Chapter 12). These requirement patterns make it easier to specify these topics without the distractions of the broader discussions in this base multiness requirement pattern itself.

The multinesses in a system can be found and specified using the following process (each step of which is spelled out in its own subsection immediately following):

Perform Steps 2 to 4 for each multiness you identify in Step 1. If you're using this requirement pattern to help specify a kind of multiness you've already identified, skip the first two steps.

Step 1: Identify Candidate Multinesses There are three places to fish for possible multinesses:

This exercise isn't as daunting as it looks, and it can, in fact, be conducted quickly. Discard as many candidate multinesses as you can the moment they come to light. Drop without further ado any multiness that's clearly not needed. If in doubt, leave it out.

Figure 10-3 is a magical representation of how several candidate multinesses might be discovered in a few important logical entities.

The three examples on the left all use the multi-organization unit requirement pattern. Multi-lingual has its own requirement pattern, too.

Looking for candidate multinesses can be a creative activity. It can unearth possibilities you never thought of (such as separate user interfaces for different age groups, I imagine). But don't get carried away. Don't include some wild capability just because you can: make sure you can justify the cost it will surely add.

Figure 10-3. Identifying multinesses from logical entities

Be alarmed if your system has more than one multiness that has a need for multiple user experiences—multi-multinesses—because they lead to a multiplicative explosion. For example, if you need a set of Web pages for each of five companies and also for each of three languages, you need fifteen sets of Web pages altogether. This sounds like a nightmare in the making. Each multiness truly does behave like an independent dimension in this respect.

Step 2: Decide Whether Something Is a Multiness Having identified a candidate multiness, work out how much support the system must provide for it. Do you need rich functionality, or will a superficial façade suffice? Consider what variations there might be in how we handle each of these things. We need multiness if there is sufficient difference between the possibilities—if they need different processing, or if they must be kept separate (for example, if they can't be added together, which applies to amounts in different currencies). Then test what's needed against the three criteria stated previously: distinct user experiences, segregated data, and unaddable data. If it matches any of these three, it is a multiness.

Asking whether putting "multi-" as a prefix in front of the name can sometimes give you a sense of whether it's suitable. If the result sounds over the top, maybe it's not important enough to be a multiness. If it sounds right and it deserves such grandeur, it's a vote in favor of treating it as a multiness.

Step 3: Specify a Multiness Requirement Write a requirement that defines the extent of support you need for a particular type of multiness, as per the Content section coming up.

Step 4: Investigate Implications and Specify Extra Requirements What must the system do to deliver this kind of multiness? Look at the effects it has on entity definitions and then on user functions such as inquiries and reports. Refer to the Extra Requirements subsection for the details. If the type of multiness in question has its own requirement pattern, refer to its Extra Requirements section too.

A multiness requirement should contain the following:

A requirement demanding that provision be made to implement this multiness in the future is similar but can be less detailed. The extent and limitations clauses should describe how much provision to make (and not to make), rather than how much multiness support. The expected number of instances can be omitted.

If most of the examples here look somewhat obscure, it's because the more obvious subjects reside in their respective requirement patterns (multi-lingual in this chapter and multi-organization unit in Chapter 12).

Each of these four requirements matches one of the three criteria for multiness: the first requirement involves multiple user interfaces, the second has segregated data, and the third and fourth have unaddable data.

A multiness requirement tells us the system must cater for multiple whatever-they-are. But that's not enough. We need to spell out how much support the system must provide, for which we need extra requirements. The topics to cover depend on which of the three multiness criteria are satisfied. These are discussed in the following three subsections.

Distinct User Experiences Providing multiple distinct user interfaces (such as one for each of several languages) takes more than creating multiple sets of Web pages. Other kinds of resources vary from one instance to another: snippets of text (such as error messages), images, audio, video, animations, and bundles to download, among others. Some of these could themselves contain text, or their content could vary in its own right (for example, company logos, legal terms, and conditions). Examine every kind of resource the system uses, and for each one ask whether it could vary from one multiness instance to another.

Other things might vary from one instance to another too, including the visual space needed to display a piece of text and the order in which words and clauses should be presented (especially if you're assembling text containing variables). The size (and shape) of an image might vary from one instance to another. If you want developers to take these variations properly into account, you have to write requirements for them.

Extra requirements might be needed for the following:

Here are sample requirements for a couple of these kinds of extra requirements:

For good measure here's a universal requirement to prevent developers burying text in code where it can't be modified and isn't amenable to multiple user interfaces:

Segregated Data The purpose of segregated data is to divide a single system into a number of distinct compartments so that a user who works in one compartment cannot access other compartments. This can be summed up like so: inaccessible instances of a multiness shall be invisible. The primary aim of extra requirements is to prevent a few likely kinds of holes in the compartments, but that's not all:

Don't let the brevity of this subsection fool you: this subject is not to be taken lightly. It deserves serious investigation, or you might find your system doesn't properly segregate its data.

Unaddable Data When we have multiple kinds of data that can't be added together, extra requirements could be needed for the following:

Check that the extent of the multiness is clear. Can you tell how much the system must do?

Verify that third-party products are capable of satisfying the multiness requirements—both products you already have and those you need to acquire.

Testing a multiness involves testing every function that might be affected, which is often many of them. First prepare a full range of representative data for more than one instance of the multiness. Then execute each of these functions, and visually scrutinize the results according to each of the multiness criteria this type of multiness satisfies. Each of the three multiness criteria that's satisfied has its own considerations:

The multiness requirement pattern assumes that each instance is handled in exactly the same way by the software, so there is no need to test variations in logic. If there is a need for different software for a particular instance, see the extendability requirement (covered earlier).

Provision for something in the future can't be tested directly, because it hasn't been implemented yet. To tell whether some provision has actually been made, first look at the structure of database tables: are the necessary columns there? Second, look at configuration to see if this area is at least handled in an unparochial way. Third, look at inquiries and reports to see if their total lines look like they are amenable to separate totals for each multiness entity (for example, each currency).

Use the multi-lingual requirement pattern to specify that the system is capable of displaying its user interface in more than one alternative natural language (for at least one class of user, though not necessarily all). Also use it to specify that the system can produce output (for example, printing letters or generating stock emails) or accept input in more than one language.

Most of what's involved in specifying multi-lingualness is said in general terms in the multiness requirement pattern, which this pattern extends. This pattern is here to make specifying multi-lingual requirements easier and to point out some specific considerations.

Decent support for more than one language is a lot of work; it's not just a matter of creating an extra set of Web pages for each language. Don't ask for it just because it sounds impressive. Only require it if it's essential.

Other variations often go hand in hand with language differences, such as date and number formats. Some of these differences have a geographical element rather being than simply language dependent, and the word locale is used for a geographical region for which specific characteristics of this kind can be defined. Multi-locale is therefore perhaps a more accurate name for this requirement pattern, but multi-lingual makes more sense because this meaning of "locale" is unfamiliar to nontechnical readers and because the multi-lingual aspect is usually by far the most complicated. See the unparochialness requirement pattern earlier in this chapter for a list of factors that vary geographically in this way.

Multi-lingualness can be used for "dialects" as well as distinct languages—for example, American/British English and phraseology for different age groups. Having the system use substitutes for missing resources is especially effective in such cases, because for a dialect you need create only those resources you genuinely want to be different. Everything else works fine and can be expected to make sense to the user.

Consider cultural differences and national sensitivities, too. Is each language version simply a direct translation of another, or should we do more? What's acceptable in the home culture of people who speak one language can differ from what's acceptable somewhere else. This applies to text and images and other kinds of resources.

The international standard that defines codes to use for languages is ISO 639.

A multi-lingual requirement should contain:

(This is a tailoring of the content described in the multiness requirement pattern just described.)

All the types of extra requirements in the "Distinct User Experiences" subsection of the multiness requirement pattern apply to multi-lingualness.

Here are a couple of specific examples:

Take inherent multi-lingual capabilities into account when deciding which technologies to use, especially if you must support languages that use multi-byte character sets.

There are also a small number of considerations in the multiness requirement pattern.

Involve someone who can speak each language being tested. For proper independent testing, don't use a person who participated in translating or otherwise producing the resources for that language.

See also the considerations in the multiness requirement pattern.

Use the installability requirement pattern to specify how easy it must be to install or upgrade the system (or a part of the system).

Whenever you go to the trouble of building a system, it's handy to be able to install it. You can always rely on the developers to install it ad hoc somehow, and that can be acceptable if you're installing it in only one or two places. Something better is called for if (a) you want other people to be able to install it, (b) you'll have more than a handful of installations, (c) you can't afford an installation to go wrong, or (d) you don't want to give developers unfettered access to production machines. That's where installability requirements come in—to impose order on installation, to indicate how important installation is and how much trouble we're prepared to take, and as a reminder to allocate adequate resources to it.

The subject of installation is rarely mentioned in requirements. When it isn't, it's as if there were an implicit requirement that says "There shall be a way to install the system. It doesn't matter how unpleasant, time-consuming, unreliable, or insecure it is." Installation is often considered at all only when the (first) installation date draws near, but it deserves to be "on the radar" from the beginning. A common sentiment is, let's worry about installation when we've got a system to install. But that's not good enough. It often involves developing installation software and instructions, which should be treated just like any other software and documentation—and as an integral part of the system. Otherwise they'll be uncontrolled and under-scrutinized—and probably unbudgeted too.

The importance of good installability depends on how many installations there'll be (both discrete sites and number of machines in each site), which organization(s) will be doing them (yours or, if it's a product, a customer), the skills possessed by the installer, the complexity of the system, and the cost if it goes wrong. Installation is often the first a customer sees of a system in the flesh, and if it's awkward or frustrating it can create a negative impression that's very difficult to correct. They might even give up and decide not to install your system at all.

Write an installability requirement for each part of the system that will be installed independently—for example, server software and client software separately.

If you like, you can omit a requirement of this kind and specify only those specific installation features you want, as covered in the Extra Requirements subsection coming up.

An installability requirement should contain:

Installing a system is a complex business, especially if we don't want it to look complex. Consider the following additional aspects, and ask yourself whether they deserve their own requirements:

Upgrading We can expect a system to have several upgrades in its lifetime. (It better had—or it'll have a short life expectancy!) When specifying requirements for upgrading, we're not dealing with a particular upgrade but setting rules to be followed by all future upgrades.

The biggest question, when releasing a new version of a system, is: from which previous versions we must be able to upgrade to it? The answer depends on which versions are out there being used. Make sure the system is ready for every likely eventuality but don't go to the trouble of making provision for situations that, while conceivable, will never occur in practice in your environment. If you can, operationally, arrange for every site to upgrade whenever a new version is released; life will be simpler for everyone. Here's an example requirement to let us upgrade from any previous version:

Instructions and software for upgrading are likely to be different from installing from scratch. They could be so different as to warrant separate instructions and software.

If an upgrade fails, do your utmost to allow the previous release to be still usable. Insist that the system be backed up before starting an upgrade.

It can be irritating when you've gone to a lot of trouble to tweak a system to suit you, only for an upgrade to set them all back to their defaults. If you want to avoid upsetting your users in this way, write a requirement to prevent it, such as this one:

Treat installation software as seriously as any other software, and treat it as a proper part of the system. Even if it's unsexy, it's still important. Automate as much as is cost-effective.

Create one or more utilities to check if a machine is ready to have the system installed: is there enough space, does it have the right operating system, are all required third-party products installed already, and are any other prerequisites met? Clearly explain every problem discovered.

Provide a reliable way of determining which version of the system is installed on each machine.

If you need to be able to upgrade to the latest version from any previous version, this can be achieved by a series of upgrades. For example, upgrading from version 1 to version 4 can be achieved by upgrading to 2 then 3 then 4. It's not necessary to properly install the software for in-between versions. We're talking mainly about information-related steps: creating database tables, converting data, and such like. This might be the easiest way to achieve upgrades from old versions, but it does mean that no installation software is ever short-lived; it's needed until every site has upgraded to a later version. But beware that upgrading via intermediate versions isn't always ideal. For example, if version 2 simplified some data (say, for performance) and version 3 restored the original complexity (because too much functionality was lost), upgrading from 1 to 3 via might cause loss of data that can be avoided if we go directly from 1 to 3. This might seem like a trivial matter to you, but it won't to users of the system.

If the system is installed on multiple machines, consider what might happen if some run one version of the system and some run another. If they reside in different locations, it might be impractical to upgrade them all at the same time, so you must arrange for old and new versions to run smoothly together.

If installability is important enough to deserve requirements, it deserves to be tested properly, and that means going to the trouble of installing it from scratch purely to test how easy it is.

Test upgrades separately. Test the upgrading to a new version of the system from each previous version that is likely to happen in practice.

Ask the development team for a list of all the files that are loaded or created during the installation process and all the changes that are made to the environment of each machine by the installation. Check that installation makes the expected changes. See if you can detect any additional changes beyond those expected.

Beware of combinatorial explosion if you have several old versions, several machine environments (say, operating systems and/or databases), and several software components installed separately. Do all combinations work together? Does installation of the system work equally well in all cases? It's impossible to test all permutations, but you should prepare several different installation scenarios that together span every individual product and version that must be supported.

Test installation instructions at the same time as performing an installation—if there are instructions. If not, expect the installation to be self-explanatory. Do the same for an upgrade. Check that the instructions do this:

Comprehensively testing installation also involves making mistakes. Draw a flow chart of the steps in the installation process and possible missteps. Consider things that could go wrong. What happens if an installation is abandoned before it finishes? Is it possible to restart it or to remove everything and try again? What happens if you try to install the system in an incorrect environment (for example, trying to use an unsupported version of the database, or with an essential third-party product missing)? Is the installation software smart enough to spot problems?

Test uninstalling the system. If there are requirements that cover uninstallation, test that it works to the degree and level of convenience demanded. If there are no such requirements, test whether uninstallation is practical. After uninstalling the system, verify that no traces of it remain (such as odd configuration files). Then reinstall the system as an extra check that the uninstall didn't leave anything behind.