Information Technology Reference
In-Depth Information
n
Ensures meeting of the minds among architect, engineer, builder, tester, and
operator
Ensures project activity traces directly to a contractual requirement
Assists in tracking project progress
Aligns operational constructs with business drivers/requirements
n
n
n
The requirement ID uniquely identifies the requirement within this table and
also within the entire traceability matrix, which may be multiple tables. The prefix
“xx” in the requirement ID denotes a table reference where xx uniquely identifies
the table. Requirement source is for the specific name of the legislation, regulation,
instruction, directive, RFP, CONOPS, contract, or SOW. The requirement descrip-
tion is the verbiage from the source or otherwise a derived statement from verbiage
in the requirement source. The degree denotes the importance of the requirement.
The degree is must, should, or may (or other appropriate terms to the same intent).
A
must
requirement is a nonnegotiable imperative. A
should
requirement is a nego-
tiable imperative. A
may
requirement is no obligation, but a good idea if time and
budget permit.
The “Trace to” column aligns the current requirement with the source moti-
vating the requirement. A good heuristic is to always trace upward unless using
an automated tool that provides bidirectional traceability. To trace upward means
that more detailed requirements trace up to more general ones. For example, busi-
ness requirements trace to legislative drivers. System requirements trace to business
requirements. Subsystem requirements trace to system requirements, etc. Verifica-
tion and validation (V&V) denotes the type of test to ensure the requirement is
in the final solution. V&V options include audit, review, inspection, test, simula-
tion, and other situational-dependent methods. Verification implies a less rigorous
test, e.g., visual inspection. Validation implies a more rigorous test, e.g., hands-on
testing with formal test cases. The URL http://vva.dmso.mil/Ref_Docs/VVTech-
niques/VVtechniques.htm ofers a formal V&V taxonomy.
There are two kinds of requirement matrices, one for the project and one for the
enterprise. The project requirement matrix is a tool for the duration of the project.
The usefulness of the project matrix ends upon successful delivery, testing, and
sign-off of the solution. The enterprise matrix is a living document to maintain a
formal enterprise IA
2
LoS. The latter refers to the IA
2
Framework, where the IA
2
LoS traces business drivers through to operational constructs. This provides ongo-
ing insight into the effects of operations on business requirements, and the business
drivers behind operations. If the business drivers change, the enterprise traceability
matrix provides a way to evaluate the effects on operations and to evaluate the effect
of operational changes on the business.
For example, if the operations require a 20 percent budget cut, the too often
traditional solution is to cut 20 percent across the board. This is not by default the
Accessed July 2007.
