System Requirements
Performance and footprint issues obviously play a large role in both the implementation phase and the design phase of a software project. However, this is not where the whole process starts. The requirements phase is the first factor. The following sections discuss why and how the requirements impact performance and footprint.
Setting Performance Targets
The requirements specification should describe in clear and measurable terms what is expected from the final product. It is in essence the blueprint of what the design and implementation results need to achieve. So in addition to containing all that needs to be tested in the final product, a good and representative requirement specification can also be used as a basis for making initial cost calculations. Consequently, the requirements are where to factor in expectations concerning the speed of a program and the hardware necessary for execution.
The requirements are determined with help from the client—often through a series of interactive sessions. When a replacement system is to be built, it is necessary to get a feel for the existing system being used and the problems it suffers from. You should examine the old system and how and when it interacts with those using it. This helps in ascertaining which parts of the system really need to be lean and fast and which parts are less time-critical.
For example, consider a company whose services cause it to have a large client database. It could be important for such a company to have a database setup that allows fast storage and retrieval of client information because it needs to be used during phone conversations with clients. Because all the data processing is done after hours, it's far less important how quickly this system processes data.
However, it's not enough to merely examine the old system and identify its problem areas. The requirements for the old system are bound to be very different from those to be satisfied by the new one. People have higher expectations of a new system when an old system is automated (or an automated system is updated or replaced) because more time and money is invested. In practice, it happens all too often that the lack of hard performance requirements causes a shift in design focus. So specific targets need to be set. With only functional requirements to guide them, designers tend to focus on elegant solutions for items, such as framework setup or reusability of components. But all that amounts to nothing if the final product is just too slow. And the same holds true where footprints are concerned. A program might be flexible and expandable, but if it does not fit on the target hardware in the first place, nobody will ever consider expanding it. So it's important to get a feel for how much space is actually necessary. It's even better to know how much space will be needed in future. If you can, you should tell the client exactly how much extra hard drive space he needs for every 1,000 new users.
The following sections focus on unexpected requirements areas that impact performance and footprint expectations.
Stability and Availability
Stability and availability are very important requirements not only for software, but also for entire systems (software plus hardware) because they impact the reliability of the system.
A system is unreliable when it crashes every few hours, produces unpredictable results (in accuracy or even response speed), or when its level of reliability depends on the amount of time it has been active (uptime). A client expects the system to be reliable around the clock. It is certainly undesirable for the design team to have to make clear that certain situations can cause actual data loss because of a hardware or software problem. This means the requirements must specify the goal level of stability and availability. The reason here is twofold: first, to make sure proper assessments and adjustments can be made during design and implementation to insure a sufficiently high reliability level; second, to make the client aware of the necessary tradeoffs. Stability and availability come at a certain cost. They influence performance and footprint size, development time, hardware costs, and so on. This cost curve is not linear either. It may be relatively easy to build a system with an 80% level of reliability. Costs are higher for the next 15%, but the following 4% might cost as much as the whole system together, and the final 1% may be unmentionably high. The client needs to decide how much the last few percentages are actually worth investing in.
The following sections examine the impact of stability and availability requirements on performance and footprint.
Impact of Stability and Availability on Performance
Characteristics of the data stream a system should be able to handle continuously are an important part of its requirements. Although a system can be equipped with buffers to capture and store certain bursts of information, the implication is that there must be, at some point before the buffers overflow, some extra time to catch up and clear the buffers. Few application areas are generous toward any data loss, so it's important to know what kind of data rate a program can handle continuously. The specific task the system is designed to carry out determines how this data rate is actually specified (the rate of input data to handle, the number of database addresses to store or process per minute, and so on). Consultations with the client should determine this data rate. Alpha and beta versions of the system should be put through stress tests. During these tests, you find out how taxing it is for the system to comply with the requirements. The system is clearly on the verge of maxing out if a simple extra task, such as moving the mouse pointer or manipulating parts of the user interface, causes difficulties. The continuous data stream it can handle is thus lower than the one it is being fed.
Enabling the use of buffers to protect against sudden or unexpected bursts of data can be specified within the requirements document, but as a maximum or "burst" data rate. It is important to note also the length of time the system is able to keep up with this maximum rate (before its performance declines or becomes unreliable) and how much time the system needs (at the normal data rate) to recover and be ready for a following burst.
A closely related issue is the responsiveness of a system. What happens when input suddenly starts pouring in after a long period of drought? Does the system respond in due time or does it experience difficulties? It seems more than logical that this should normally not be a problem, but even a household PC in everyday use can experience this. Background processes (such as screensavers, registry updates, virus checkers) ensure that the PC does not respond instantaneously after a period of low interaction. The hardware also plays an important role in responsiveness, such as green PC options, power savers, the suspend mode, and so on. When a system has to guarantee a certain response time, these options most likely need to be kept in check or maybe even turned off. It might also be possible to set specific parts of the system in some kind of standby mode and keep the input channel monitoring active. This highlights the next area of consideration; the communication channels. If a system communicates with its environment via a modem connection, for example, it might be necessary to keep a continuous connection rather than to allow the modem to log off, after which a costly reconnect would be needed before more data can be down- or uploaded. The analysis and design phases of a project should determine how best to proceed—that is, which operating mode to allow for each part of the system.
Impact of Stability and Availability on Footprint
The data burst example given earlier demonstrates clearly the tradeoff between stability and availability on one hand and the footprint on the other. The longer the system should be able to handle higher data rates, the larger its buffers need to be.
Another area to consider is the space needed for stored data. To guarantee a high level of reliability, it may be prudent to duplicate key sets of data. Think, for example, of the DOS/Windows OS where the FAT (containing information on where and how files are stored) is kept in duplicate. Also, the storage medium itself can dictate a necessary cautious approach. You might have to take into account the number of times a medium can be written to and the average number of corrupted memory units that occur during usage. For instance, corrupted sectors on hard disks must be considered beforehand. Extra space may be needed to allow extensive error correction (Hamming codes) and so on.
For more details on optimizing input and output of data, see Chapter 12, "Optimizing IO."
Concurrency
When you set up the requirements for a software project or a system, it's important to take into account the environment in which it needs to function. Part of the requirements include assessments of usage of resources not only by the system, but also by tools and tasks likely to be used simultaneously. It's wise to determine answers to these questions:
Are there more applications running on the system simultaneously?
If so, identify them and find out about their resource usage. For example, a calculator program using large parts of system resources is not going to be very functional as it is most likely to be used as a second or third application to aid in subsets of a larger task. Also, certain resources have to be claimed and shared: serial and parallel ports, interrupts, DMA channels, input devices (such as a keyboard or mouse) and so on.
Will a number of users be working with the system simultaneously?
A scenario like this is of course possible with a multi-user OS, like UNIX, but has an impact on the resources available for each user. It might even influence implementation decisions as used strategies (client/server strategies, COM, CORBA), locking mechanisms, and private copies of data for processing.
Investigating the resulting availability of storage and computing power will result in a requirement of the constrained context in which the program should be able to run.
Choosing the Target System
Based on the information from the previous sections, it should be apparent what is expected from the program or system. It should also be clear that decisions have to be made which will affect the overall cost of the project. Higher reliability means more expensive hardware and longer development and implementation times. Often, you even have to choose between using hardware and using software to solve a problem. The obvious pros here are the speed of hardware solutions and the flexibility of software solutions; the obvious cons are the extra cost and inflexibility of hardware development. But there are more-involved considerations; when the software is able to do a lot of error recovery, for example, the hardware can be less fault- tolerant. The cost of being fault tolerant will sometimes be higher in software, other times in hardware, so comparisons really need to be made on a case-by-case basis. There are natural limits to the available choices, of course. For example, software will never be tolerant enough to compensate for a broken power supply.
After you determine which (if any) parts of the project have to be done in with (dedicated) hardware, take a closer look at the software to use: What kind of OS is needed? The level of reliability decided on may very well influence the choice of OS. Will a cheaper or standard OS suffice, or is a proven, industrial OS warranted? Before this question can be answered, it's necessary to look at performance, footprint, and price tradeoffs:
What kind of impact does the OS have on available CPU cycles? (Consider this for different activities, such as memory allocation, file storage, and so on.)
What is the footprint of the OS? (Sometimes different versions of an OS can be chosen, each with its own subset of functionality and footprint size.)
How much overhead does the OS create? (How much memory or performance is lost when spawning a task, opening a file, creating a file on disk, and so on.)
What is the minimal guaranteed response time? (And to what extent is this influenced by background tasks like updating registry information, doing page swapping, and so on.)
Is it a real-time OS? (And is one really needed? See requirements.)
The hardware and software choices affect performance and footprint. This is something which will be reflected again in the design. The following sections address this.