Maintainability and Support Requirements: Type 14

Usually at requirements time you do not know exactly how much maintenance your product will undergo in its lifetime, nor do you always know the type of maintenance that it will need. However, we do have some products where maintenance can, to some extent, be foreseen. Consider whether any expected changes will occur in the following areas:

• Organization

• Environment

• Laws that apply to the product

• Business rules

Might other factors affect your product? If you know or strongly suspect that the product will undergo relatively heavy maintenance due to expected changes, then specify the types of expected changes and the amount of time allowed for those changes.

If you are creating a software product that should be able to run on several different types of operating system, then specify it:

Description: The product shall be readily portable to Linux.

Rationale: This has been identified as a future growth market.

Keep in mind that your requirements document is a contract to build the product. You are saying to the developer that you want to be able to port the product to another platform at some point in the future, and that you will hold him accountable for the adaptability of the product to a new machine. When you attach the fit criterion to this requirement, you specify the characteristics of the machine and the expected time or effort necessary to make the transition.

The IceBreaker product had this requirement:

The product shall be translated into various foreign languages. As yet, the languages are unknown.

This requirement had a big effect on the product's designers. They designed the interface in such a way as to make it easy to add new languages. Also, they took into account the fact that different languages sometimes mean different cultures and different ways of presenting data.

Support requirements are also covered in this section of the requirements specification. In some cases your client may indicate that the product will be supported by the existing help desk, in other cases the product must be entirely self-supporting. By making this point clear at requirements time, you ensure that the designer builds in the appropriate mechanisms for contacting the help desk or providing answers for questions likely to arise with usage.