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 | Develop Technical Vision Manage Changing Requirements Requirements Attributes
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.
This program and the accompanying materials are made available under the Eclipse Public License V1.0, which accompanies this distribution. OpenUP Copyright