| <?xml version="1.0" encoding="UTF-8"?> |
| <org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-fCBrf_5JlrmuKgyrCaKGOA" name="requirement_attributes_1,_VQ268O0KEdqHTdbLTmC5IQ" guid="-fCBrf_5JlrmuKgyrCaKGOA" authors="Chris Sibbald" changeDate="2006-09-20T11:41:34.000-0700" version="0.2"> |
| <mainDescription><p>
 |
| 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&nbsp;requirement.&nbsp; 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&nbsp;all high-priority requirements from the customer in the
 |
| last 30 days. <a href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html"
 |
| guid="_9ToeIB83Edqsvps02rpOOg">[TEL06]</a>
 |
| </p>
 |
| <h4>
 |
| Examples of attributes
 |
| </h4>
 |
| <p>
 |
| 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.
 |
| </p>
 |
| <p>
 |
| <em>Source</em> - Person, document or other origin of a given requirement.&nbsp; This is&nbsp;useful&nbsp;for
 |
| determining whom to call for questions or for grouping&nbsp;requirements according to the person making the demands.
 |
| </p>
 |
| <p>
 |
| <em>Priority</em> - 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&nbsp;as an indication of how well the system will meet the greatest needs or for compliance-related metrics.
 |
| </p>
 |
| <p>
 |
| <em>Assigned to</em> - Who in the organization is responsible for making sure the requirement is met (person's name or
 |
| organizational name).
 |
| </p>
 |
| <p>
 |
| <em>Comments</em> - Reviewer's or writer's comments on a requirement.
 |
| </p>
 |
| <p>
 |
| <em>Difficulty</em> - An indication of the level of effort needed or how hard it will be to implement the requirement
 |
| (high, medium, low).
 |
| </p>
 |
| <p>
 |
| <em>Status</em> - Degree of completeness (completed, partial, not started).
 |
| </p>
 |
| <p>
 |
| <em>Risk</em> - Confidence measure on the likelihood of meeting (or not meeting) a requirement. Could be high, medium,
 |
| low or the integers one through ten.
 |
| </p>
 |
| <p>
 |
| <em>Due By</em> - Date the requirement must be provided.
 |
| </p>
 |
| <p>
 |
| <em>Method of verification</em> - Qualification type to be used to verify that a requirement has been met: analysis,
 |
| demonstration, inspection, test, and walkthrough.
 |
| </p>
 |
| <p>
 |
| <em>Level of Test</em> - Describes the verification lifecycle stage at which the requirement is determined to be met:
 |
| unit test, component, system or product.
 |
| </p>
 |
| <p>
 |
| <em>Subsystem Allocation</em> - Name of system or subsystem a requirement is to be assigned to (for instance, flight
 |
| control module, wing assembly, passenger cabin).
 |
| </p>
 |
| <p>
 |
| <em>Test Number</em> - Identification of a specific test or other method of verification.
 |
| </p><br />
 |
| <br /></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
