Before diving into these considerations, let’s first look at the various parts of a requirement: data, metadata and relationships.

Data

Describes an object, and is relevant to the object itself. An example of data may be a summary or description of a requirement.

Metadata

This is data about the data, which aids in organizing or using the object within a process. It typically describes the current state of the object, and has the same scope as the data itself. For instance, metadata may describe the State/Stage within a requirement workflow (i.e. Approved, Rejected, Satisfied, Tested).

Relationships

This characteristic of a requirement allows you to model:

• structure (i.e. Consists Of, Includes);
  
• history (i.e. Revision Of, Derived From);
  
• conceptual links or traces (i.e. Satisfies);
  
• and/or , references (i.e. Defined By, Decomposes To);
  
• security (i.e. Authorized By, Enables).
  

Any given requirement can have information in each of the data, metadata and relationships categories and when requirements are reused, any or all of the information can also be reused.

Your requirements management tool needs to have an architecture and features which will enable it to support the level of reuse your business dictates as strategic to the organization. Since reuse can occur at a number of levels, each leveraging the various parts of a requirement listed above, flexibility is also a key to solving the reuse challenge.

For a closer look at requirements reuse and usage scenarios, click here.

Subscribe in a reader | Subscribe by Email