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
Related Elements | Detail Requirements
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 not only extend the meaning of each requirement; if created properly, they can yield significant information about the state of the system. Just as a query can be made on all men with brown hair over age 30 given our human example, queries on the status of requirements can be made such as 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, useful in determining whom to call for questions or whether the requirement needs to be grouped by persons 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 as an indication of how well the system will meet the greatest needs or for metrics concerning compliance. 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 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 (flight control module, wing assembly, passenger cabin). Test Number—Identification of a test or other method of verification.
This program and the accompanying materials are made available under the Eclipse Public License v1.0 which accompanies this distribution. View copyright information here: OpenUP Copyright