Chapter 10: Flexibility Requirement Patterns


Overview

A flexible system is one that can adapt to suit changing circumstances. What sort of circumstances might they be? That's for you to decide: you need to write a specific requirement for each kind of flexibility you want. It's meaningless to try saying, "The system shall be flexible." Building flexibility into a system is done for longer term benefits; it usually doesn't make much (if any) difference to the system when it's first delivered, though it makes it easy to react to changes in requirements in the areas that are built flexibly. Flexibility requirements generally contribute to a "good," robust system, in addition to satisfying specific goals. But some kinds of flexibility are expensive to implement, so ask for them only if they're necessary.

The requirement patterns in this chapter cover those types of flexibility most commonly needed in commercial systems, as shown in Figure 10-1. Observe that multi-lingual is a specific kind of multiness, and so is multi-organization unit in the commercial domain. Also, installability isn't exactly flexibility in the same sense, but this is the most convenient place for it.

image from book
Figure 10-1: Requirement patterns in the flexibility domain

Software grows old. A new system is as pure as a newborn baby, but alterations accumulated during its life leave scars and cause its joints to creak. Each modification places a little extra stress on the system's architecture. Steadily they become harder to make, until eventually every tweak risks nasty side effects. Building flexibility into a system from the outset means it takes many kinds of changes in its stride, leaving less cause to interfere with its vital workings-so it grows older more slowly. Refactoring, a conscious effort to tidy up software, can be viewed as an attempt to remove symptoms of the aging process. It's more effective and less effort to lessen the deterioration in the first place. Flexible means agile in the dictionary sense of the word: supple and healthy. Extendability is perhaps the type of flexibility that contributes most to software longevity.

Always give flexibility requirements a high priority, because flexibility is not something that can just be bolted on afterwards: it's fundamental to the system design. Adding it later could involve so much effort you might as well not bother trying.

There's a complex relationship between flexibility requirements and performance requirements. Flexibility requirements primarily influence the nature of the software; performance requirements primarily affect the hardware needed. Used together, performance requirements can tell us just what sort of numbers we're talking about when contemplating scalability. Recognize that there's often a trade-off between flexibility and software efficiency (which translates into lower performance, assuming the same hardware), because flexibility prevents streamlining and tuning the software for just one thing. Pay serious attention to the short-term and long-term trade-offs between flexibility and performance. Unless squeezing the last smidgen of speed from the software is critical, opt for flexibility.

Flexibility is often difficult to test. One option is to talk to the development team: ask them what one would do to modify the system in a way specified in a flexibility requirement. Use their response to get a feel for whether they've actually thought about it properly and are ready for it. This theme is revisited in several of the flexibility requirement patterns in this chapter.

Regardless of whether you choose to use any of these flexibility requirement patterns, you can include the following requirement (or one like it) to spur developers to avoid one type of limitation that could lead to trouble in later life:

Open table as spreadsheet

Summary

Definition

No artificial quantity limitations

The system shall impose no artificial limitations on how many entities of any particular type can exist (regardless of the quantity and power of the hardware). For example, it would be unacceptable if a maximum of 20 suppliers were allowed, or 100 types of product.

This requirement does not apply to genuine limitations imposed for sound reasons (such as the biggest integer allowed by a programming language or the database, or the number of countries a 3-character code permits)-which are usually much larger than are ever likely to be needed in practice.

This requirement also does not apply to external systems that are outside the company's control. (But encourage external suppliers to avoid or remove such limitations where possible.)




Microsoft Press - Software Requirement Patterns
Software Requirement Patterns (Best Practices)
ISBN: 0735623988
EAN: 2147483647
Year: 2007
Pages: 110

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net