Functional requirements have two broad purposes. Tactically, they are necessary to describe the system that is to be constructed and tested. They provide a common, agreed upon set of features and functions that must exist in the end-state system. Strategically, the requirements for any project represent a substantial investment of intellectual capital. They provide a detailed description of the system that has been constructed, and often describe the systems on which it is dependant or to which it is attached. As such, the strategic value of requirements, once a project has been completed, are often overlooked.
Most descriptions of the software development lifecyle (SDLC) have a perspective that deployment is the endpoint. This seems like a logical goal for most system development efforts. Yet, it seems odd that these efforts are often repeated for each generation of software. A large corporation may have repeated the process for mainframe, minicomputer, client server, Windows and internet versions of their software. Each time the organization goes through the costly and time consuming process of gathering requirements and use cases - even though these change very little through each generation. The managers of these defined processes may remain the same but are they still willing to let requirements go stale, thus guaranteeing that the next iteration will involve the same process (and perhaps job security!).
Corporations accumulate a tremendous quantity of product information, including data structures, validation rules, business rules, and system interface definitions. As a system grows, this information can encompass business rules in various inter-related systems across multiple products. This product information represents a knowledge base that differentiates the corporation from it's competitors and this information is a valuable asset in and of itself. By recognizing the value of these assets and taking steps to secure and maintain them the cost of projects can be significantly reduced while greatly increasing corporate competitiveness and shareholder value.
The initial investment in writing accurate system requirements, while less than the investment in development, is substantial. A large project may take months of requirements gathering and writing. At a large bank where I consulted, requirements for one application cost well over $1,000,000.00. A rough estimate has netted a cost of $3700 per requirement. If the ancillary documents, such as database interface descriptions and test scripts are considered, the figure would be even higher. The purely tactical approach to requirements treats the requirements as a disposable commodity. Typically, requirements are actively maintained until the project goes into production, at which point attention and resources turn to the next project.
One of the most significant implications of viewing requirements as valuable corporate assets is that the change management process should be taken very seriously. The tendency for many projects is that the closer you get to production (the tactical goal), the more the change management process is likely to be circumvented. For example, it is more likely that an undocumented software change will be made in pilot than in development. The reasons are obvious - the importance of the tactical goal has all but eclipsed strategic considerations. If we consider the impact to our requirement asset, it is clear that failure to follow a disciplined change management process will result in a degradation of that asset. This is because when it comes to reuse, inaccurate requirements are considerably less valuable than accurate ones.
Change management tends to become even more suspect with regard to accurate requirements during production. Production changes are often made against change request "tickets", without regard to the underlying requirement documentation. Every time this happens, the value of the requirement specification is diminished. Ultimately, when the time comes to build the next platform, the requirements - now legacy requirements - are considerably less valuable than if they had been maintained. In fact, at a certain point, they become so unreliable as to be worthless. Even if 70% of the information is accurate, one can lose faith in the document as a whole because it is impossible to know which 70% is the correct 70%.
The value of functional requirement degrades when they are not kept current. As a result, existing requirements may not be used as the starting point to build adjunct functionality. It is common that new or related projects will start the requirement process anew. While the new requirements may borrow from previous requirement documents (when they are current enough to remain useful), typically, the new requirements are focused - tactically - against the new project. The only areas that may be updated to reflect the current/desired state of the system are those where the new project overlaps the existing system. In a worst case scenario, the requirements that related to completed projects are left to atrophy becoming suspect. As time passes, they will become so unreliable that they may need to be entirely re-written.
The failure to maintain requirements adds time and cost to every subsequent project. For projects in production, this may mean any change is time consuming and costly because a developer would need to directly inspect the code to determine the functionality. New projects are adversely impacted because of the additional time and costs involved in gathering requirements. There is also an increased chance for error when the requirement is re-written. When system information is not maintained, knowledge of it is left to the memory of individuals.
Key points:
by Richard Salit, Ken Brown and Peter Soldwedel
Copyright 2002 Application Resources, Inc. All right reserved