9.6 Configuration Control for the Requirements

9.6 Configuration Control for the Requirements

In an ideal world, the operational, functional, and module requirements would be placed under configuration control in the same manner as the source code itself. That is, SCCS or RCS can be used in the same manner as for source code to maintain the various versions of each of the requirements elements. The requirements and software specification constitute a living document in exactly the same manner as the source code itself. As the requirements evolve, they must be tracked and managed in precisely the same manner as the source code. Some requirement elements will come and go. The code representing these eliminated versions will also come and go. As the source code base changes, it is extremely important to know which version of which requirement element is represented by the code base. The operational requirements are constantly changing. The functional requirements will also probably change very rapidly. The design elements for the modules representing the functionalities will change as well. The code base itself is a very dynamic document. Each code module must be linked to the specific design element that it represents. As the code changes, so too must the design element. Each design element, in turn, implements one or more functionalities. As the functionalities change, the design elements must change and the code must change. Every version of every operation must be traceable to specific functionalities that, in turn, are traceable to specific modules.

It frequently happens that a large software system is imbued with a substantial amount of dead code. This code implements operations or functionalities that have materially changed or have even been eliminated. Without complete requirements traceability at the version level, it is almost impossible to control the problem of dead code. Without complete requirements traceability at the version level, it is almost impossible to determine whether the source code actually implements the current requirements specifications.

For the operational requirements specification, there are three parts. First is the system overview. This is a text document that describes the system from an operational viewpoint. This document will evolve in the same manner as any source code module. It will have an initial version and then incremental changes to the initial version. The same is true for the second part of the operational requirements, the operational systems metaphor. Finally, each operation is a separate entity. It will be maintained as a separate element or module in the configuration control system. The mapping of operations to functionalities O × F will also be stored under version control. Each operation is a separate module or file in the configuration control system. Every version of every operation is linked specifically to specific versions of one or more functionalities. From a database perspective there are three distinct tables that we will need to represent operational requirements. These are shown in Exhibits 12 through 15.

The contents of Exhibits 12 and 13 are self-explanatory. The important thing here is that these change over time. Different builds of the software will implement different versions of the operational requirements. Changes to the source code base will be driven, in part, by changes in the operational requirements. Necessarily, each build must reflect the operations that it implements. Each system may have multiple nonoperational requirements relating to reliability, availability, security, survivability, and performance. For each of these nonoperational requirements, there will be a separate instance of the system nonoperational requirements relation. This information is reflected in Exhibit 14.

Exhibit 12: System Operational Overview

 System_Name System_Operational_Overview 

Exhibit 13: System Operational Metaphor

 System_Name System_Operational Metaphor 

Exhibit 14: System Nonoperational Requirements

 System_Name System_Non-Operational_Requirement System_Non_Operational_Requirement_Version 

Exhibit 15 is really the meat of the operational requirements code. Each operation is a separately managed requirements element and has a unique requirements number. If, at any point, any one operational requirement is deleted, the original requirement number will still index the old requirement element. Each operation is implemented by one or more functionality. These functionalities will be known by their unique numeric identifiers. Each version of each operation will be implemented by one or more functionalities. These functionalities are also dynamic. They will change and be updated. As any one of the functionalities is updated, any of the operations that it implements must also be updated to reflect the new version of the functionality. In this manner we can ensure that the latest version of each operational specification references the most recent versions of the functionalities that implement it.

Exhibit 15: System Operation Specification

 System_Name Operational_Requirement_Number Operational_Requirement_Description Functionality_Vector Functionality_Number Functionality_Version 

The case for the maintenance of the functionalities is similar to that of the operations. Exhibits 16 and 17 essentially duplicate the tables for the operations shown in Exhibits 12 and 13. Again, there may well be nonfunctional requirements that relate to specific implementation environments. These data are associated with the functional overview.

Exhibit 16: System Functional Overview

 System_Name System_Functional_Overview 

Exhibit 17: System Functional Metaphor

 System_Name System_Functional_Metaphor 

As was the case for the operational requirements, there will generally be system nonfunctional requirements as well. These nonfunctional requirements will involve such things as the operating systems environment, specific hardware requirements, and hardware/software interface requirements. For each of these requirements there will be an instance of the system nonfunctional requirements relation. This information is shown in Exhibit 18. Again, as a system evolves, it is reasonable to suspect that the nonfunctional requirements will evolve as well. Thus, it is also important to keep version information.

Exhibit 18: System Non-Functional Requirements

 System_Name System_Non-Functional_Requirements System_Non-Functional_Requirements_Version 

As was the case for each of the operations, each of the system functional specifications is kept as a separate instance in the database. The structure of this relation is different from that of the system operational specification. For the functionalities, there is a bidirectional mapping. This can be seen in Exhibit 5. From this exhibit, we can see that Operation 1 is implemented in Functionalities 1 and 2. Functionality 2, however, is also used in the implementation of Operation 2. Thus, whenever Functionality 2 changes, it gets a new version number and the corresponding system operational specifications (for Operations 1 and 2) are updated with the new version number of Functionality 2. This, in turn, creates a new version of the operational specifications in the system functional specifications. Necessarily, to prevent cyclical updating problems, the operation version numbers must be updated simultaneously with the changes in the functionality requirement description.

There is an instance of the system functional specification for each functionality. The structure of this relation is shown in Exhibit 19. This table entry shows the precise structure of the linkage that will permit the operations to map to functionalities and the functionalities to map to operations. Similarly, this table will provide the structure for the mapping of functionalities to specific modules and modules to functionalities. If a particular functionality is used to implement three operations, then there will be three elements in the Implements_Operation_Vector for that functionality. Each element will consist of the identifying number of the operation together with the latest version of that operation. Similarly, if two modules are required to implement a functionality, then there will be two entries in the Implemented_By_Modules_Vector.

Exhibit 19: System Functional Specification

 System_Name Functionality_Requirement_Number Functionality_Requirement_Description Implements_Operations_Vector Operation_Number Operation_Version Implemented_By_Modules_Vector Module_Number Module_Version 

The contents of the Exhibit 19 embody the mapping for both the O × F and the F × M. Of greater importance from a software maintenance perspective is the M × F × O mapping that is also possible. One of the central problems in altering any low-level design element is trying to determine the scope of the change; that is, which functionalities and operations will be impacted by a change in the design at the module level. It might well be that a change in a functionality will mandate a change in one or more modules. The real question is what other functionalities (and operations) will also be impacted by this change. With the inverse mapping of modules to operations, the impact of any low-level change can easily be determined. Another real maintenance issue solved by this mapping occurs when an operation (or functionality) is removed from the requirements specification altogether. If there are modules that are uniquely associated with a particular operation and that operation is deleted, then all the modules that are unique to this operation must also be deleted. If one or more such modules are left in the build, these will essentially be dead code. There will be no functionality that will exercise them.

Each functionality is implemented by one or more design modules. The design specification for each of these modules is also kept under configuration control in the same manner as the operational requirement specifications and the functional requirements specifications. The relation for the module specification was shown earlier in Exhibit 4. The essential element of the module element pertinent to this discussion is the Call_Section. This is a very important section in that the call structure of the program can be found here. As we can see from Exhibit 20, Module 1 can call Modules 2 and 3. Module 3, on the other hand, is called by Module 1 and calls Modules 3 and 5.

Exhibit 20: Mapping of Operations to Code Modules

As can be seen in Exhibit 20, there is a one-to-one mapping of design module instances to code modules. Each code module implements exactly the design. There will be little or no need to comment the code module in any way. Anything we wish to know about the code module can be obtained from the design specification (such as domains for local data variables) or the configuration control system (such as developer name).

Just as was the case for the functional specification and the operational specification, each design module instance is kept under version control in precisely the same manner. Each time there are updates to a particular design module, the version change is back-propagated to the affected functionalities. After the design module instance has been modified, then and only then will the associated code module be changed.

Just about any large, modern software system is a maintenance nightmare. This is because there is absolutely no engineering blueprint for the code. It has been carefully crafted by a team (sometimes a hoard) of developers. No modern hardware system would be so crafted. There are elaborate design specifications for modern office buildings. There are astonishingly complex design documents on modern integrated circuits. It would be unthinkable to modify one of these two structures without first updating the blueprints or design documents. It should be equally unthinkable to do this same thing with code. We do not empower carpenters to make design decisions on the buildings we are constructing. They merely implement the design. The same discipline should be enforced on software developers as well.