Prevention

 < Day Day Up > 



Requirement Deficiency can be prevented by collecting all the necessary requirements, but how can it be determined that all the necessary requirements have been collected? The real work in preventing the existence of unstated requirements in a project lies in using techniques that minimize the chances of an important requirement being overlooked.

Communication

Clear and efficient communication channels are of great importance to getting all the requirements for an application. Although a developer does not necessarily need to be sitting next to an end user while he works, the more effectively the desires of the end user get communicated to the developer and the limitations of development get communicated to the end user, the more efficiently development can proceed and the more usable of an end product will be generated. The major players in the chain that leads from end user to developer are end user, customer, management, and developer. Each of these players can contribute to the confusion of obtaining all the requirements; therefore, the more aware each is of his role, the better the requirements can be gathered (Figure 10.1).

click to expand
Figure 10.1: Communication and concerns of the standard parties involved in requirements and software development. Optimal communication involves all parties involved having direct communication with any other party when necessary, but it is more common and sometimes necessary to limit communication to the more standard channels.

The end user will be the final user of the product and will be very interested in the user interface and other usability issues. The chance for a developer to talk with an end user is very valuable, but even more valuable is the opportunity to observe the end user at work. This can reveal constraints and requirements of which the end user is not even consciously aware. The end user must also be encouraged by the developer to provide feedback whenever possible. One way to encourage this is to show the end user the benefit of his feedback when the next version is released. In shrink-wrapped software, a sampling of potential end users should be used during development to get an idea of the response the final end users will have when the product ships.

The customer, who might be anyone from the end user to someone at the end of a chain of managers above the end user, is most interested in getting an application that fulfills the needs of the corporation and will often ignore the issues that concern the end user. The developer must encourage the customer to obtain this information, or the developer must be allowed to interact directly with the end users. The combination of the end user and customer requirements make up the core of the requirements of which the external parties are aware.

Management on both sides might have their own useful input on the requirements, but must above all else be encouraged to pass along information in a timely and complete manner. Revealing that a requirement exists late in the game and was only unknown because it got caught up in management does more than damage the current project, it also damages the relationships of those involved and can lead to turnover or loss of business for the parties involved.

Finally, the developer who is programming and constructing the application will be most cognizant of the technical issues and limitations. The developer must be encouraged to communicate this information so that it can reach the customer and end user. This will allow the customer to make the necessary decisions about the importance of various requirements and other business-related dealings. The developer should also ensure that they have all the requirements they need, asking for more information if they feel anything is missing. This applies to individual programmers and their tasks as well as to the developer and application as a whole product.

The communication is two-way and it should be expected to last throughout the project in varying degrees. The efficiency of this communication is particularly important during the requirements phase as certain missing requirements are filled in and tradeoffs are worked out.

Paper Trail

While it is true that direct verbal communication is fastest and most efficient for working out issues, there is a need for a paper trail to exist for several reasons. Obviously, since we are talking about computers, “paper” is meant metaphorically. One of the most common methods of recording communications is through e-mail, but other forms of recording information are also useful. Documents, recordings, e-mails, and notes are all useful ways of recording the process and information transmitted during the requirements phase of development.

Perhaps the most useful aspect of recording these interactions is as a memory aid during development. Questions about the exact meaning of requirements or missing requirements might be answered in these archives without the need to revisit the entire process that occurred earlier. This can save time and ensure that the developer is clear on the exact requirements the application must meet.

Another important aspect of the paper trail is for settling disputes quickly and without undue impact on the schedule. This can range anywhere from a misunderstanding between programmers about their tasks to a disagreement between the customer and developer about what is expected for the application. This aspect of the paper trail will impact the way in which communications are recorded, requiring a more legal approach when customer and developer are involved and a less informal approach between coworkers.

Checklist

One of the symptoms of Requirement Deficiency is the lack of requirements that were there in previous projects. To facilitate this process, and therefore prevent these requirements from being overlooked, it is useful to keep a history of common requirements that have been encountered in past projects. This history can then be used as a checklist for ensuring that all the necessary requirements have been gathered for a new project.

There are several important nuances to keep in mind when creating this list. The first is that many of the useful items will appear later in development, not during the requirements collection phase. This follows from the fact that these requirements are not already on the checklist, and are therefore likely to be missed when the requirements are created. However, when these requirements are then discovered later with the associated problems, it becomes evident that they were missed and should be added to the checklist.

Next, note that you are compiling a general type of requirement that should be collected and not specific requirements. Therefore, you do not have a checklist that says:

  • The application must perform at 60 frames per second.

Instead, you are looking for the more general:

  • Performance requirements

It is also important not to add, or remove if discovered, items that are not common and therefore not often missed from the checklist. Part of this process is deciding what type of project is generally associated with a particular requirement. Some requirements appear in almost every project, while others are numerous within a particular project type but unheard of in other types. What follows are some requirements that are common in many different types of projects.

Performance

Almost every application is concerned with performance to one degree or another. It is therefore important to obtain the performance requirements of the application. This can then be used as a guideline for generating a performance budget for different parts of the application, allowing for intelligent design decisions relating to performance. Be careful, however, that these requirements do not lead to Premature Optimization.

Memory Usage

There are still a large number of memory limited devices that are being developed for, and it is imperative that these limitations be included in the requirements. If an application becomes substantially larger than the target memory allows, missing this requirement can lead to a final implementation that will never be able to make it onto the device.

Even if the device is not severely memory limited, it is still important to know the memory of the target systems in order to avoid phenomena such as disk thrashing because of numerous page faults.

File Storage

File storage decreases in cost and increases in size every year, but file sizes also continue to increase in size and seem to keep pace with available storage space. Be sure to consider file sizes, particularly if the application is meant for limited resource devices or has files that will be commonly transferred over the Internet.

Stability

Every customer wants a bug-free application, but there is cost involved in testing and verification that cannot be overlooked. Be sure to get the requirements for what tests the application must pass to be acceptable, or you might find yourself with a lot of extra debugging that you did not anticipate. Requirements can range anywhere from provably bug free, a time-consuming effort that should only be used for life critical applications, to running for a reasonable amount of time without crashing and preserving data in the event of a crash.

Backward Compatibility

Many applications need to work with old data or communicate with legacy systems. Be sure the customer has given information on all the legacy products with which the application should be able to operate.

Extensibility

Customers would love a product that could be extended to meet any new demands they require, but reality limits the flexibility that can be added to an application and remain cost effective. Obtain requirements from the customer about the areas in which the application is most likely to require extensibility. This is also a useful time to determine what areas are likely to change even before the project is finished.

Internal Technical Requirements

Customers are generally not knowledgeable about the technical information and limitations involved in implementing the application. Therefore, it is up to the developer to ask the right questions to obtain the information necessary for creating their own technical requirements. Obtaining these requirements is all part of the give-and-take process that was mentioned when we talked about communication.

First, the developer must acquire the general requirements the customer would like the application to fulfill. These should then be evaluated by the developer in order to generate the technical requirements. As this process occurs, some of the initial requirements might not be possible to meet, for technical, time, or budgetary reasons. These issues should be brought back to the customer after options have been outlined for alternatives or tradeoffs. This process might occur before the requirements are sufficiently refined.

A final step in the process should be to ensure that the individual developers agree that their part of the requirement can be accomplished. This feedback can help to further clarify vague requirements and add missing requirements. On the customer side, it might be useful to have the end user make any final suggestions concerning the tradeoffs and alternatives that were made to the requirements. As with so many parts of software development, a balance must be struck between the time taken to refine the requirements and the cost of the performing this refinement.

Flexibility

It is always important to maintain a certain amount of flexibility when developing software, but flexibility adds to development time and code complexity. This is where requirements can help focus effort, providing a guideline for when to provide extra flexibility. The best guide for adding flexibility comes from understanding the likely areas of change based on experience and customer concerns, but sometimes these are missing or poorly collected. Actually, it is where requirements are missing that demands the most flexibility. This is where the customer is most likely to decide later in development that the application must meet certain requirements.

Thus, by providing flexibility when the requirements are missing or vague, requests by the customer to impose these requirements later can be handled easily. This is of course assuming that you cannot get the customer to choose a stricter set of requirements early on. Since you cannot always choose who collects and provides the requirements, it is beneficial to leave flexibility where you are unable to obtain stricter requirements.



 < Day Day Up > 



Preventative Programming Techniques. Avoid and Correct Common Mistakes
Preventative Programming Techniques: Avoid and Correct Common Mistakes (Charles River Media Programming)
ISBN: 1584502576
EAN: 2147483647
Year: 2002
Pages: 121
Authors: Brian Hawkins

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