10.4 Multiness Requirement Pattern

10.4 Multiness Requirement Pattern

Basic Details

Related patterns:	Unparochialness, extendability, multi-lingual, multi-currency, multi-organization unit
Anticipated frequency:	Up to three requirements, rarely more
Pattern classifications:	Pervasive: Maybe; Affects database: Yes

Applicability

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.)

Discussion

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:

• Criterion 1: Distinct user experiences, where each alternative instance has its own version of much of what the user sees, such as a separate set of Web pages for each alternative. (For multi-lingual support, for example, everything language-dependent the user sees must be duplicated in each supported language.)

• Criterion 2: Segregated data, where the data associated with one alternative instance must be presented on its own, separately from the data of the others. A user might be able to see data for one alternative only, and users who can see more mustn't see them mixed up. (For example, if we're running a multi-department system, a user might be able to see the activities of their own department.) Each alternative in effect has its own little world, which operates to a greater or lesser extent as if it had its own system. There might be people, however, who can span several or all of them. The degree of separation can vary; it's not all-or-nothing.

• Criterion 3: Unaddable data, where data is incompatible, and is meaningless if added together. This occurs in any system that has amounts in multiple different units. And that's the test for this criterion: are they like apples and oranges that can't be added together? (For example, in a multi-currency system we cannot simply add an amount denominated in U.S. Dollars to an amount in Euros.) By this test, amounts belonging to different companies can be added together, so their data can be aggregated (though, depending on how rigorously their data must be segregated, it might never actually be aggregated).

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.

Making Provision for Multiness

Implementing any kind of multiness is a lot of work, but adding it to an existing system is extra difficult (perhaps prohibitively so). However, it's more straightforward if the system was built from the outset with that kind of multiness in mind.

If there is even a slim chance of a multiness being added at any time during a system's life, consider making some kind of provision for it. Identify specific "hooks" that can be built in, and judge which ones are sufficiently cost effective (based on how easy they are to include and how much unpleasantness they might save later). The commonest types of hooks-with an indication of each one's cost of provision and potential saving later [shown in square brackets at the end]-are as follows:

1. Provision in entity definitions (in the database) Add whatever data items (columns) the multiness would need-for example, for multi-currency, the currency of monetary amounts. In particular, add them to indexes (IDs) because revamping indexes later is likely to cause disruption and risk. For example, for multi-company, add the company ID as the first data item in an index. [Cost: low; saving: high]

2. Configuration Catering for a multiness from the outset in configuration data and maintenance functions often takes little effort. One option is to grant developers the freedom to make provision for the multiness if they can do so easily. [Cost: low to moderate; saving: limited]

3. ID allocation Introducing a multiness can affect how IDs allocated by the system itself (such as order numbers or account numbers) are generated. Think about what the impact would be, and if it sounds potentially nasty take steps to avoid the problem. [Cost: moderate; saving: potentially high, if relevant]

4. Inquiries and reports A significant fraction of the effort of implementing a multiness is adding support for it to inquiries and reports-for example, segregating data or showing separate totals for unaddable values (such as for each currency). It's probably not worth building these things into individual inquiries and reports, but if you're acquiring a third-party reporting product, choose one that supports complex totaling of this kind. [Cost: high; saving: limited]

Check that whatever is done is coherent. Some of these hooks depend on others. For example, an inquiry can't cater for multiness if the data it shows doesn't. And support for the multiness in one place but not another could cause trouble.

If a multiness has been suggested (or there is any chance that someone might want it) but you've decided to make not even provision for it, state this explicitly in the requirements specification to avoid any chance of a misunderstanding.

More is said about making provision for multiness in the "Extra Requirements" subsection in this pattern and in the requirement patterns for specific types of multiness.

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):

1. Identify candidate multinesses.

2. Decide whether something is a multiness.

3. Specify a multiness requirement.

4. Investigate the implications, and specify extra requirements for them.

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:

• Place 1: Definitions of data entities (We assume these exist already, so specify their requirements before tackling multinesses.) You don't need to scour every entity: concentrate on the important living entities (such as customer and employee) and transactions (such as customer order). For each candidate entity, run through its data items. Any data item that has one of the following characteristics is potentially a multiness:

  1. The data item identifies a configuration entity. For example, in a customer entity we might unearth country and region of residence, preferred language, owning company,and club membership type.

  2. The data item could be used to determine how to treat that entity. For example, for customer we might stumble upon date of birth, and thus implicitly their age, which would let us give teenagers a different experience at our Web site if we want.

  3. The data item is an amount that has a unit of measure, whether or not the unit is explicitly present. For example, a monetary amount always has a currency as a unit of measure (even if in a parochial single-currency system the same currency is assumed everywhere).

  Pay special attention to data items used for identification (or indexing).

• Place 2: The structure of the organization Or the structure of all the organizations involved, if there are more than one. Use the multi-organization unit requirement pattern both to specify organizational structure and to decide whether any kind of organization unit needs to be segregated enough to count as a multiness.

• Place 3: Types of extendability Each type lets us plug in software for a particular purpose and often involves database tables shared by all the extensions of that type. We need a multiness if each extension's data must be segregated from that of the others or if they are mutually unaddable. For example, if our system provides an environment for multiple service providers (each able to slot in its own software), we probably need to isolate each service provider's data from the others.

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.

Figure 10-3: Identifying multinesses from 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.

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.

Content

A multiness requirement should contain the following:

1. Multiness type What kind of thing are we asking the system to support multiple of? (For example, multiple languages.)

2. Extent of support Give a summary of what level of support is expected from the system. For example, only our external Web site might need to be multi-lingual (not internal functions). Don't go into great detail; use extra requirements to spell out specific aspects.

3. Expected number of instances When we say multiple, how many are we talking about? This is only significant when a distinct user interface must be constructed for each one-for example, for each supported language-and then it's very important. Either express it as a number (or range), or describe a condition that determines how many (for example, one for each company configured in the system).

   This raises the question of whether we're just specifying a system with an inherent multiness capability (say, multi-lingual), or whether in addition we expect the system to be delivered with support for a specific set of instances (say, English, French, and German). The main multiness requirement should limit itself to the former. If you need the latter, write extra requirements for them-one for each instance, if they are small in number, so that each can be assigned its own priority.

4. Limitations What simplifications are acceptable? Don't force the developers to confront difficult aspects if they're unnecessary.

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.

Template(s)

Open table as spreadsheet

Summary	Definition
Multi-«Multiness name»	The system shall support multiple «Multiness type description». «Statement of extent». [«Number of instances statement».] [«Limitations statement».]
Provision to be multi-«Multiness name» [in future]	The system shall make provision for the future introduction of support for multiple «Multiness type description». «Statement of extent». [«Limitations statement».]

Example(s)

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).

Open table as spreadsheet

Summary	Definition
Multi-age group	The system shall allow distinct customer user interfaces to be provided for different age groups. Whenever a user interface "resource" is to be displayed, if an age-specific version is present, it shall be used; otherwise, a default (age-independent resource) shall be used. The types of "resources" to which this applies include Web pages, messages, images, audio, and video. It is anticipated that no more than three age groups will be supported. This requirement does not apply to the user interface of functions used only by employees.
Multi-marketing campaign	The marketing management system shall allow multiple independent marketing campaigns to be conducted. Information about campaigns shall be rigorously separated from each other, and no person shall be able to view or otherwise access information about a campaign with which they are not connected.
Multi-currency	The system shall be able to process transactions in multiple different currencies. This requirement does not include the ability to perform currency conversions.
Multi-fruit tree type	The fruit tree management system shall cater for multiple types of fruit tree. Whenever numbers of trees or quantity of fruit are shown, totals for different fruits shall always be shown separately (for example, no adding of apples and oranges). There shall be no artificial limit on the number of types of fruit tree.

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.

Extra Requirements

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:

1. Instances to implement Write requirements that identify specific multiness instances that are to be implemented. Avoid this if you can-because it smacks of specifying data rather than the system itself. How unclean this is depends on the nature of the multiness: naming particular languages is more acceptable than naming companies.

2. Default instance Allow one instance to be nominated as the default, the datum. This is the one to use in the absence of any guidance to the contrary. Its implementation needs to be complete, with no resources missing. It is advisable for this to be the first instance implemented, to constitute the reference instance.

3. Choosing instance If there are several instances available, how does the system decide which one to use for a particular user? Typically a user session continues to use one instance until told to change. There are four common ways to choose an instance other than the default: 1. The user visits a specific address (URL); 2. Temporary selection by the user; 3. Permanent selection by the user (as a user preference); 4. Derive from other known information (such as the customer's country). A system could use more than one of these ways.

4. Substituting if a resource is missing What happens when something is missing for a particular instance (either a piece of text or a "resource" such as a Web page)? The smart-and resilient-answer is to use instead the equivalent resource for another instance. The easiest approach is to always use the resource belonging to the default instance, but there are more sophisticated possibilities, such as nominating for each instance the substitution instance to use, which makes it relatively easy to create "dialects" that contain few resources of their own.

   If each instance's resources are owned by its own legal entity (for example, if we're supporting multiple companies), check whether it's acceptable to substitute resources belonging to someone else. The system might need to accommodate rules determining what's allowed. If there's no instance that can be used as a default of last resort, the substitution mechanism might find itself without a resource it can use.

5. Input interpretation Does the system ask the user to enter values from which it interprets meaning? If so, are any of those values tied to a particular instance of a multiness? For example, if the user typing Yes or No into a certain field conveys special meaning, a multi-lingual system should accept the equivalent words in the user's chosen language. A user interface can't be considered multi-lingual if you force the user to speak to you in a single language.

6. Customer support If you're offering a customer support service, you might want different contact addresses for each multiness instance (phone numbers or email addresses, or both), which means telling customers what they are (perhaps via an instance-specific help page). Then you need customer service operators prepared to deal with each multiness instance (for example, who speak different languages or represent different companies). It also helps if the customer service operator is able to "see what the customer sees, which means being able to display the same function for the same multiness instance (even if not the same data).

7. Resource editing function(s) Creating one set of resources is hard enough. Creating another set that's exactly equivalent but different in some respect (such as in a different language) is harder, unless you provide functions that help. For snippets of text (including error messages and so on), a function that displays one version and asks you to enter another version makes life a lot easier. It also helps if you show each one's context, because it's sometimes impossible to make an appropriate translation without it. You could keep track of a change to any resource, because it might signal that its equivalent instances need to be changed too. These are just some of the ways to help with the creation and managing of multiple sets of resources. Deciding which ones are worthwhile depends on how many user interface instances and how many different resources you have, how often they are likely to change, and how important the best possible user interface is to you-that is, how much you're willing to spend.

8. Missing resource checker It's tedious, time-consuming, and unreliable to check by hand whether all the resources needed for an instance of a multiness are present. A utility can do this job a lot more dependably.

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

Open table as spreadsheet

Summary	Definition
Default «Multiness name»	The system shall have a default «Multiness name». The user interface shall be displayed according to this «Multiness name» unless and until an alternative is chosen. Every element of the user interface shall be present in the default «Multiness name».
Substitute missing «Multiness name» resources	If a «Multiness name»-specific resource is missing (not present) for a particular «Multiness name», the equivalent resource for the default «Multiness name» shall be used instead. This shall apply for any type of "resource" displayed in a user interface, including (but not limited to): Web pages, messages, pieces of text, images, and multimedia resources. An error shall be logged (with low severity) whenever a substitution of this kind is made. The motivation for this requirement is resilience: to display the best user interface even when resources it needs are missing.

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:

Open table as spreadsheet

Summary	Definition
No hard-coding of user-visible text	No piece of text that might be displayed to a user shall reside in source code. That is, every piece of text that a user might see must be modifiable without changing source code.

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:

1. Prevent cross-instance access Don't allow a user associated with one instance to access data belonging to another. This is straightforward enough to build into specific functions, but care needs to be taken whenever flexible selection criteria are allowed. In particular, no normal user should be able to run SQL queries, nor to use any product that permits free queries (such as a report writer product).

2. Give users access to instances Each user must be granted access to the multiness instances they should be able to work with. That raises the interesting question of who is allowed to grant this access. For example, in a system supporting multiple companies, each company will want only its own employees granting authority to its precious data-but there must be some kind of overall controlling body. The answer is for each company to have users who are able to set up other users for their company only, and for a "system manager" to create each company's special users in the first place. Extra checks can be put in place to restrict what a system manager can do, especially to prevent them accessing companies' data and to prevent them creating other users. Everything's possible-but it can get fiddly.

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:

1. Cross-instance conversion Is there some way to convert an amount belonging to one instance into an equivalent amount belonging to another instance? For example, an amount in one currency can be converted to an equivalent amount in another currency. If cross-instance conversion is possible (and in some cases it isn't), specify how to perform it. Where do the conversion "rates" come from? The rates are likely to change over time. How? How frequently? Do you need different rates for different purposes? Consider specifying a "base" instance of the multiness to use as a datum for conversions-both to have a standard in which to report (for example, your local currency) and to save having to manage a "rate" for every permutation of instances.

2. Never simply add values for different instances You could write a requirement stating that two or more incompatible amounts shall never be added together, although it might sound too obvious to warrant saying and often is.

3. Distinct totals for each instance Any inquiry or report that lists data belonging to multiple instances and shows totals should show separate totals for each instance for which data is listed. For example, if an inquiry lists a number of transactions that are denominated in several currencies, totals should be shown for each currency. You could write a pervasive requirement that insists on this rule being applied across the whole system, which saves having to say it for each function to which it applies and it also covers those that might be added in future.

4. Don't sort on unaddable amounts Presenting a list of customer bank accounts in descending order of balances is meaningless if they're in several different currencies and that wasn't taken into account. That's common sense, and it's reasonable to assume a developer will come up with a sensible solution. But if a general purpose tool (perhaps a third-party product) is used, it won't understand the data and might produce silly results. If you're worried that something like this might happen, write a requirement to prevent it.

Considerations for Development

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.

Considerations for Testing

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:

• Criterion 1: Distinct user experiences First decide whether you're testing an inherent ability to support multiple user interfaces or whether you're testing support for a specific set of instances, or both. This determines how many instances you need to test: in the first case, two is probably enough. It also affects how seriously to treat the omission of specific "resources" for an instance; in the first case, this might be unimportant. If testing an inherent ability to support multiple user experiences, consider what is called pseudo-localization (or pseudo-loc) testing, in which a set of resources is created automatically for a second user experience based on a full set for the first-typically by adding a fixed character (say, X) at the start and end of each value. This saves a large amount of manual effort creating a new version of everything. It also makes it easy to spot if a value from the wrong instance is being displayed, and it's understandable by everyone on the project (unlike if the second instance were in a different language).

  If the system's smart enough to use a substitute resource when one is missing for a particular instance, test an instance for which all resources are missing. Check that the user interface for every function looks satisfactory.

  If there's a "missing resource checker" utility, run it.

• Criterion 2: Segregated data Test that a user restricted to data belonging to one instance of the multiness cannot access data (or other resources) belonging to any other. Pay special attention to any function that offers flexible selection criteria: is it possible to do a query, for example, that delves into forbidden data? Check whether there are any interfaces or other "unusual" ways to access the system. If so, verify that they enforce the same restrictions as the rest of the system. Third-party products are at particular risk of falling foul here, because they're unlikely to understand the need for segregation.

• Criterion 3: Unaddable data Test that values for multiple instances of a multiness are never simply added together: they must either be shown separately or converted as specified in the requirements (for example, currency conversion using the correct exchange rates). Look especially at totals shown in inquiries and reports. Again, watch out for functions offering flexible selection criteria and for third-party products that are unaware when data is unaddable.

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).