Concept: Requirement Attributes
Requirements attributes capture additional information, such as risk, planned iteration, source of requirement, about each requirement. This additional information is used to manage the project.
Relationships
Main Description

Attributes are a very important source of requirements information. Just as every person has attributes (age, hair color, gender), each requirement has a source, a relative importance, and time it was created. Attributes do more than simply clarify a requirement.  If created properly, they can yield significant information about the state of the system. Just as you can run a database query to find all men with brown hair over age 30, given our human example, you can run queries on the status of requirements to find all high-priority requirements from the customer in the last 30 days. [TEL06]

Examples of attributes

Listed below is a partial list of some common attributes and a brief description of their meaning. Some attributes are best described as a number, date, Boolean (true or false) or a text field for entering free format comments. Other attributes can be expressed as lists. For instance, priority type is a list of high, medium, and low; Weekday is a list which includes Monday, Tuesday, and so on.

Source - Person, document or other origin of a given requirement.  This is useful for determining whom to call for questions or for grouping requirements according to the person making the demands.

Priority - Statement of relative importance of the requirement, either to the system (mandatory, critical, optional) or to other requirements (high, medium, low). It is good to track the mandatory or high-priority items as an indication of how well the system will meet the greatest needs or for compliance-related metrics.

Assigned to - Who in the organization is responsible for making sure the requirement is met (person's name or organizational name).

Comments - Reviewer's or writer's comments on a requirement.

Difficulty - An indication of the level of effort needed or how hard it will be to implement the requirement (high, medium, low).

Status - Degree of completeness (completed, partial, not started).

Risk - Confidence measure on the likelihood of meeting (or not meeting) a requirement. Could be high, medium, low or the integers one through ten.

Due By - Date the requirement must be provided.

Method of verification - Qualification type to be used to verify that a requirement has been met: analysis, demonstration, inspection, test, and walkthrough.

Level of Test - Describes the verification lifecycle stage at which the requirement is determined to be met: unit test, component, system or product.

Subsystem Allocation - Name of system or subsystem a requirement is to be assigned to (for instance, flight control module, wing assembly, passenger cabin).

Test Number - Identification of a specific test or other method of verification.