Establish Business Rules for Contingencies and Responsibilities

" The best-laid plans of mice and men..." begins the famous saying. It has direct application to writing SRSs because even the most thought-out requirements are not immune to changes in industry, market, or government regulations. A top-quality SRS should include plans for planned and unplanned contingencies, as well as an explicit definition of the responsibilities of each party, should a contingency be implemented. Some business rules are easier to work around than others, when Plan B has to be invoked. For example, if a customer wants to change a requirement that is tied to a government regulation, it may not be ethical and/or legal to be following " the spirit of the law." Many government regulations, as business rules, simply don't allow any compromise or " wiggle room." A project manager may be responsible for ensuring that a government regulation is followed as it relates to a project requirement; however, if a contingency is required, then the responsibility for that requirement may shift from the project manager to a regulatory attorney. The SRS should anticipate such actions to the furthest extent possible.

Establish a Requirements Traceability Matrix

The business rules for contingencies and responsibilities can be defined explicitly within a Requirements Traceability Matrix (RTM), or contained in a separate document and referenced in the matrix, as the example in Table 3 illustrates. Such a practice leaves no doubt as to responsibilities and actions under certain conditions as they occur during the product-development phase.

The RTM functions as a sort of " chain of custody" document for requirements and can include pointers to links from requirements to sources, as well as pointers to business rules. For example, any given requirement must be traced back to a specified need, be it a use case, business essential, industry-recognized standard, or government regulation. As mentioned previously, linking requirements with sources minimizes or even eliminates the presence of spurious or frivolous requirements that lack any justification. The RTM is another record of mutual understanding, but also helps during the development phase.

As software design and development proceed, the design elements and the actual code must be tied back to the requirement(s) that define them. The RTM is completed as development progresses; it can't be completed beforehand (see Table 3).