5.3 Technology Requirement Pattern

5.3 Technology Requirement Pattern

Basic Details

Related patterns:	Comply-with-standard, inter-system interface, accessibility
Anticipated frequency:	Usually no more than six requirements
Pattern classifications:	Pervasive: Maybe

Applicability

Use the technology requirement pattern to specify technology that must (or must not) be used to build or run the system, or with which the system must be capable of interacting or otherwise compatible.

Do not use the technology requirement pattern to make technology choices.

Discussion

Technology is any externally-produced hardware or software that is used in building, installing, and running a system. That's what it means here, at any rate. Requirements must not make decisions about which technology to use; they must describe whatever is known about the technology landscape into which the system must fit-to constrain in some way the technology that can be used in the system. We can conveniently divide that landscape into the following three areas:

• Area 1: To use in production Hardware, operating system, database, Web server, firewall, uninterruptible power supply, and any other paraphernalia needed to provide life support for our application software.

• Area 2: To interact with in production Such as a Web browser. This includes indirect interaction, such as exporting files or data that are to be read by some other application (and vice versa, importing files).

  All inter-system interfaces should be specified according to the inter-system interface requirement pattern. Each inter-system interface requirement must state the technology to be used for the interface, insofar as it is mandated.

  Sometimes you need to make a judgment call about whether to regard something as technology or as a standard; some things can be regarded as both. For example, if our system needs to produce HTML pages to be displayed in a Web browser, are we complying with the HTML standard, or are we interacting (indirectly) with a browser? The best way to decide is to look at the underlying purpose: why are we doing this? If the purpose is to allow use of a Web browser, no one will care whether we use HTML (nor what version of HTML) providing the browser is able to present our output satisfactorily. In this case, specify the technology rather than the standard.

• Area 3: To use in development Such as a programming language. Documenting, testing, and installing are regarded as falling within this area too. Common motivations for development technology requirements are

  1. For the skills needed to build the new system to match those that the organization already has.

  2. To be compatible with existing software (so we can reuse as much as possible).

  3. To fit in with existing development practices.

  4. To allow use of development tools already purchased and familiar.

Specifying development technology is most important when outsourcing development, especially if maintenance and ongoing development will be done in-house: constrain the external developers so the system suits our existing environment and skills. When developing in-house, we can usually rely on the development team to pick technology that is compatible with other systems and their skills, but not always. A developer might have their pet programming language or might just want the chance to learn a popular new skill-and you might have good reasons for keeping them to tried and true old ways. Carelessly introducing a hotchpotch of technologies contributes-invisibly, and probably significantly-to incompatibilities between systems-and thus inflexibility as well as extra development cost.

All requirements for technology to be used in development must have the highest priority; it's not practical to change these things after development starts.

It's not necessary to specify all this stuff-or, indeed, any of it. Just specify whatever is a given. The less we specify, the more freedom the development team has to pick whatever technology best fits the constraints placed upon it plus the goals of the system.

Where do technology requirements come from? We can expect demands for the technology that must be used (or not used) and interacted with in production to become apparent during the requirements process: someone's likely to mention them. On the other hand, we're likely to discover development environment matters only if we go looking for them-by talking to the development team. But that doesn't mean we should mechanically record such information: only specify it in requirements if there is a good reason to.

Content

A technology requirement should contain:

1. Description of technology What technology are we talking about? This can be as specific or as general as appropriate. It doesn't have to name specific products. It can embody a formula for determining one product or more, in a similar fashion for working the version(s) of technology that must be supported, in point 3(c) below (though formulae of this kind can become intricate).

2. Usage of the technology What role must this technology play in our system? At a minimum, convey which of the preceding three areas it relates to (use in production, interact with, use in development). Usage can be negative as well as positive: "the system must not use such-and-such technology."

3. Version(s) of the technology (if relevant) Mentioning versions in a requirements specification is always problematic, because we don't want to tie the system just to specific versions that are liable to become out of date; neither do we want to make an open-ended commitment to each and every new version that might come along in the future. We also don't want to be unnecessarily specific or restrictive. There are three possible approaches:

   1. Don't mention versions at all. Sometimes there's no point in making a fuss. If everyone's likely to understand what's needed and what is customarily involved when a new version of this particular technology is released, or if there won't be a problem whenever a new version comes along, there's little to be gained by talking about versions.

   2. Mandate one or more specific versions. This is likely to be fine in the short term, but it conflicts with the goal of a timeless specification. What happens when a new version is released? Taken literally, the requirement says that any new version needn't be supported. But if that's what we mean, say so explicitly-because the average reader won't see it that way. If we expect the system to work with future versions, it's better to express the versions in a formula-which is approach (c).

   3. Devise a formula, based around the most recently released version, that is expressed in terms that don't mention that version explicitly and that identifies one or more versions that must be supported. For example, we could describe the most recent version and the two previous versions, or all versions that have been, at any time in the past two years, the most recent version. Do your best to minimize the number of versions that must be supported at once. For example, you could add a caveat to rule out any version that was soon superseded (and thus not widely used).

      Bear in mind that accommodating a new version might involve significant extra development effort. This, in turn, means there might be a delay between when that new version is released and when our system begins supporting it. If so, it's worth having the technology requirement grant the system some leeway, in case anyone expects instantaneous conformance.

   Always give at least a little thought to the matter of versions, even if you end up deciding not to mention them in the requirement itself.

4. Motivation Why are we mandating this technology? The reasons for some technology requirements can be far from obvious; in fact, they are all liable to appear arbitrary if not justified in some way. People can have strong opinions on particular technologies (even stronger when they're negative opinions), so stating good reasons why one technology is essential can prevent a potentially vehement argument before it raises its head.

If the system must work with a range of technologies (for example, a couple of popular Web browsers), write a separate requirement for each one. This makes it harder for any one of them to be neglected (that is, it's easier to trace that each technology is supported), and it allows each one to be assigned its own priority.

Template(s)

Open table as spreadsheet

Summary	Definition
«Technology summary»	«Technology description» shall be used for «Technology usage». [«Technology version statement».] «Motivation statement».
«Technology summary»	The system shall use «Technology description» for «Technology usage». [«Technology version statement».] «Motivation statement».

Use one of these templates as a starting point only. As the examples that follow demonstrate, the most suitable phraseology varies considerably depending on what an individual requirement says.

Example(s)

The following examples should not be regarded as advocating (or deprecating) any of the technologies they mention. This is not a coherent set of requirements that apply to one system: a few contradict one another. The second example demonstrates how expressing technology and versions in terms of a "formula" can be tortuous to specify precisely.

Open table as spreadsheet

Summary	Definition
User access via Web browser	All user functions shall be accessible via a Web browser.
Popular Web browsers	The user interface shall be Web-based, and all functions shall operate fully with all popular Web browser/operating system family combinations (up to a maximum of eight such combinations) as nominated by a designated person (who is expected to be the marketing manager). All versions of any such Web browser that have been the latest version at any time in the past two years shall be supported, except for any version that was superseded within a month of its release. The list of popular browser/operating system family combinations can be modified periodically, but not more than four times per year. When a browser/operating system family is added to the list, support for it shall be provided within two months of that time.
Internet Explorer Web browser	The user interface shall be Web-based and all functions shall operate fully with the Microsoft Internet Explorer Web browser. All versions that have been the latest version at any time in the past two years shall be supported, except for any version that was superseded within a month of its release.
Widely used database	The system shall store its data in a widely used, well respected relational database product.
Oracle database	The system shall use the Oracle database. For each installation, data shall reside in the same Oracle instance used by the company's other systems. A noteworthy consequence of this clause is that the system does not need to concern itself with database transactions spanning multiple databases.
Programmed in widely used high level language	Software shall be written in a widely used, high-level programming language. A scripting language is not acceptable. The company has a preference for software written in C#.
Java programming language	The primary programming language for the server-side software shall be Java. The "primary programming language" is that in which the main application software is written. This requirement does not preclude the use of other programming languages in special situations (such as database stored procedures), but it does demand that other languages not be used for the development of any part of the core software. All tasks and processes that must be run regularly or frequently in order to keep the system operating shall be regarded as part of the main application software.
Widely used operating system	The server components of the system shall run on a widely used operating system that has proven dependability and scalability.
Windows operating system	The software shall be written to run on hardware running a version of the Microsoft Windows operating system.
No development facilities in production	There shall be no means to write software on the production system and no programming tools (including compilers, editors, linkers, and debuggers). The motivation for this requirement is to prevent unscrutinized, untested software from being run in a live environment.
No PERL scripts in production	No PERL scripts shall be used on a production machine (further to the previous requirement).
All scripts in PERL	All scripts shall be written in the PERL language.
Apache Web server	The system shall interact with the current corporate approved version of the Apache Web server.
Documentation in Word	All documentation that is written as proper documents (as opposed to Web pages) shall be written using Microsoft Word.

Observe that these examples are not divided into the three areas discussed (use in production, interact with, and use in development), yet mixing them up does not confuse the role of each requirement.

Extra Requirements

Some nonfunctional requirements that we wish to impose on our system also need to apply to technology that we use. In this case, write extra requirements for the purpose. One example is accessibility: our system can't be regarded as satisfying its accessibility requirements if some of its functions are implemented using a third-party product that doesn't satisfy them. (See the accessibility requirement pattern in Chapter 8, "User Interface Requirement Patterns.") Write extra nonfunctional requirements for each of the technologies used. That's usually preferable to attempting to broaden the original nonfunctional requirements so they also apply to the technology used. The latter is certainly easier to specify, but it isn't helpful to developers because the work involved in building a feature into our own software is of a different nature than that of choosing a compliant product. It's equally unhelpful to testers for similar reasons.

Considerations for Development

Technology is too varied to be able to make suggestions here on how to tackle particular types. But it is possible to say a little about how to react to the two main kinds of technology requirement, because they are very different as far as development is concerned:

1. Technology the system uses (or must not use). This kind of requirement influences (often in profound ways) the process of building the system, including who will build it. For example, once you mandate the programming language, you need a development team competent in that language. But a technology use requirement typically has less effect upon the design of the system. For example, a given design could be implemented in many different programming languages.

   When reviewing this kind of requirement, development representatives should check that adequate technology that satisfies the requirement can be found. Also check that the prospective development team has suitable skills to use this technology.

2. Technology with which the system must be compatible. This kind of requirement directly affects the software that needs to be built. It might mean that at least one developer must be (or must become) an expert in this particular technology. For example, if our system must interact with a particular credit card clearing service, someone will have to get to know it in detail and develop software for it.

   When reviewing this kind of requirement, developers should scrutinize it and contemplate its implications. Try to get an early feel for how difficult it will be to implement.

Considerations for Testing

As with development, the two main kinds of technology requirements place very different demands on testing:

1. Technology the system uses (or must not use). This is generally straightforward to test: for each technology requirement, find out what technology was used in that area, and verify that it's in accordance with the requirement.

2. Technology with which the system must be compatible. There are no shortcuts here: it must be tested in detail-occasionally in excruciating detail. For example, if the system must be accessible via a particular Web browser, then every type of page delivered by the system must work.

For both kinds of requirement, pay special attention to any requirement that insists that the system work with multiple different technologies (and/or multiple versions of each one), especially if the number of permutations looks impractically large. Be alarmed if two or more technology requirements have impact on each other, yielding vastly more permutations. This situation is likely to be hard to test-because you have to acquire, configure, and run all the technologies to test them. Then tests must be repeated for each one. It's tolerable for client technologies with which the system must interact (such as several Web browsers and browser versions). But it's a major headache when it relates to the system's own environment, such as testing that server applications run on several different operating systems or types of hardware.