9.4 Static Capacity Requirement Pattern


9.4 Static Capacity Requirement Pattern

Basic Details

Related patterns:

Data longevity, data archiving, scalability

Anticipated frequency:

Between zero and two requirements, rarely more

Pattern classifications:

Affects database: Yes

Applicability

Use the static capacity requirement pattern to specify the quantity of a particular type of entity that the system must be able to store permanently (typically in a database).

Do not use the static capacity requirement pattern to specify for how long information must be retained; use the data longevity requirement pattern for that. Also do not use it to specify how much disk space the system needs.

Discussion

With storage being so cheap and databases able to handle vast quantities of data, static capacity itself isn't a critical issue per se: we're unlikely to have trouble finding enough disk space for whatever we need to store. The importance of a static capacity requirement is indirect: that all aspects of the system be designed and built so as to be practical and work well when the target number of entities are present. For example, an inquiry or report that shows every individual entity is impractical if we have more than a few hundred.

Most business systems have one type of entity that determines the quantity of most or all other high volume entities-one that drives everything else of note. Customer is typically the best type of entity to use. It determines the number of derivative entities-its extended family-such as (customer-initiated) transactions, a history of customer details changes, customer preferences, and so on. A system could have more than one type of driving entity that are independent of one another volumewise; if so, write (or consider writing) a static capacity requirement for each one.

A sizing model can be used to roughly estimate the disk space needed for a system's database, based on a target number of driving entities and the logical structure of this type of entity (see the data structure requirement pattern in Chapter 6, "Information Requirement Patterns") and its derivative entities, such as transactions. Add a large contingency (50 percent?) for extra overhead and columns added during the database design stage, plus a fixed chunk for configuration data (say, 20 Mb?) and space for chronicle data (which could itself be very large). Also add space for any multimedia resources (such as a picture of each customer, if you have them). But regard any such estimate as indicative only.

Content

A static capacity requirement should contain

  1. Type of entity What sort of thing are we guaranteeing enough room for (for example, customer)?

  2. Number of entities What's the minimum number the system must be able to store, and still work well?

  3. Entity inclusion criteria Which entities count for capacity purposes? If this item is omitted, all entities of the stated type are included. The purpose of this is to permit excluded entities to be removed (or moved somewhere else, where they have less impact on performance). For example, if we include only active customers-and we need to state precisely what that means-we are at liberty to take out all inactive ones, if that will help keep the system running smoothly. That's not to say excluded entities must be removed; if the system runs fine with them present, there's no performance reason why they can't stay. However, there must be a requirement for a function to remove the excluded entities (see the data longevity and data archiving requirement patterns in Chapter 6). This item has the effect of granting the development team a degree of leeway.

  4. Achievement timeframe By when must the system be ready for this capacity level? If omitted, the system must always support this capacity.

Template(s)

Open table as spreadsheet

Summary

Definition

Total «Entity type» capacity

The system shall be able to handle a minimum of «Entity count» «Entity type»s. «Entity inclusion criteria». [«Achievement timeframe statement».]

Example(s)

Open table as spreadsheet

Summary

Definition

Initial customer capacity

The system shall be able to handle a minimum of 50,000 customers upon initial installation.

Eventual customer capacity

The system shall eventually be able to handle a minimum of 1,000,000 customers. This figure covers only those customers who have accessed the Web site in the past three months or placed an order within the past twelve months. It is not expected that this level of business will be reached earlier than two years after initial implementation.

Extra Requirements

A static capacity requirement can prompt extra requirements for the following kind of functions:

  1. Remove inactive information, to stop the system getting clogged up with data. (See the data longevity and data archiving requirement patterns.)

  2. Statistical inquiries or reports to show changes in the number of entities over time. This reporting could be linked to changes in other performance measures over time (for example, how growth in business volume has affected average response times).

  3. Raise an alarm if the number of entities reaches beyond a set number (or within a set limit of an actual capacity estimated by the system itself, perhaps based on available disk space).

Considerations for Development

Check that every specified function that accesses any type of entity whose volume is affected by a static capacity requirement will be practical to use and can be implemented with acceptable response time.

Considerations for Testing

A way is needed to generate a sufficient quantity of data. This involves either invoking the system's software or writing something to emulate what it does.

You can't simply extrapolate performance at one capacity level to deduce performance at a higher capacity. Or, rather, the greater the difference (ratio) between the two levels, the greater the risk the extrapolation will be wrong (due to performance degrading). A factor of two or maybe four isn't a risk; a factor of ten is just about tolerable; twenty or more isn't good enough. To test that a system caters for a stated capacity, you need to generate that many (or a number smaller by a factor whose risk you consider acceptable). And you need to generate a representative quantity of every other type of dependent entity: transactions, chronicle entries, and so on. To do this, you need software to manufacture artificial data.




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