In a previous article we listed the benefits of reusing standard requirements. This time we concentrate on some more practical hints and tips for creating the standard requirement asset for your company.

Deriving requirements from standards

When you derive requirements based on standards into a database of requirements, make sure the whole standard document is covered. You may for example create one requirement based on each numbered section of the standard. Requirements should also contain a reference to the original source, stating clearly the standard name and version number. Good practice is to create one requirement specification document and corresponding test case specification document against one standard document.

Standard requirements are typically requirements for the system, instructions, internal processes, testing methods or organization. Tagging the requirements accordingly helps addressing them to the correct responsible in the organization and enables creation of metrics for follow-up and auditing needs.

Central requirement database for standards

Instead of copying standard requirements between individual projects, you should establish a common centralized database with named data owners to serve all projects. Requirements in the database should form a complete, high-quality set that represents all the standard documentation relevant for your projects and has been reviewed with relevant parties.

Rather than individual requirements, the database should contain specifications, and one requirement specification should always have corresponding test specification present with at least one test case linked to every requirement as shown in the picture below.

When a new project is started, it reuses the central database content. Typically, it is more useful to reuse the whole requirement specification document or set of documents rather than individual requirements. Projects can further refine standard requirements and test cases, reject those which are not valid for the project and add project specific requirements when needed.

Requirements in the database should also contain a reference to the original source.

Options for reuse

There are a few options for the method of reuse (depending also on the capabilities of  your requirements management tool):

    • Reuse by copying – Independent copy of the specifications. There is no connection to the original specifications nor requirements or test cases, and it is not possible to propagate changes in the originals to the copied ones. The whole specification and all requirements or test cases in it are fully managed in the project after the copying.
    • Reuse with linking – Copy of the specifications, with links to the original specifications. The copies will not automatically change if the originals do, but it is possible to indicate a change in the original specifications to the reused ones. The whole specification and all requirements or test cases in it are fully managed in the project after the reuse.
  • Reuse with inheritance – Linked (or even a “live”) reused instances of the specifications. It is possible to automatically propagate any changes in the original specifications to reused ones. Reused specifications and the requirements and test cases in them may be edited with certain restrictions in the project.

In all of the approaches above the traces between requirements and test cases must be preserved. It can be argued whether pure copying is actually reuse at all, but even with such a simple mechanism you can gain some of the benefits of reuse. It saves time and ensures good quality requirement base to start with.

Our recommendation is to use a linked live copy with inheritance as it saves the trouble of manual updates in the projects, when the requirements in the central database change. This is especially beneficial in projects that last for years and the probability of  standards changing is high.

When a company selects a solution for reuse, first thing is to understand how the projects work: Can the version of the standard they follow change during the project or will the project always stick with the version that was valid when the project was started? Is there a need to edit the content of the reused requirements and test cases, or just their status per project? By finding and answering questions like these before implementing a solution for managing standard requirements it is possible to avoid unnecessary complexity. Also note that possible mechanism for reuse are limited by your choice of  requirements management tool. Especially reuse of whole specification and managing traceability may prove problematic with some tools.

What happens when standards change?

Central database of standard requirements should be regarded as an asset, which must be kept up-to-date or it loses its value. This means that whenever standards change, changes shall be reflected to the database content and communicated to the projects that need to fulfill them.

When the reuse is done with a linked live copy with inheritance, changes can be easily propagated to the copies in the projects. When the specifications in the central database are updated it is automatically indicated to the reused copies. Projects can then decide if they take the new version into use and propagate the change into their copies of the specifications. Again, it depends on the selected tool whether the changes can be actually propagated to the copies.

How to get started?

Rather than trying to create a complete central database for standard requirements at once, try it out with one standard document and with one or two different kinds of projects. This helps you to find ways of working that best suit your company. Standard requirements are an easy target for reuse because they are exactly the same for any product, but nothing prevents you from using the methods of reuse also to other types of requirements, if they apply to several projects or products.

Interested in learning more?

Let’s have a 1-hour online demo where we can show you a solution how to do this in practice!
Just send us your email address and we’ll get back to you.

Website Design: Bermuda