A T T A C H M E N T 7

К оглавлению
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 
17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 
34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 
51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 
68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 
85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 
102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 
119 120 121 122 123 



One of the best methods of generating entries for the Requirements Traceability

Matrix (RTM) is to conduct a ‘‘shalls’’ review and use those results as requirement

entries in the RTM. If you have not accomplished this task before, don’t

worry. It is rather simple nowadays with the ‘‘find’’ function on most word

processing programs. There are, of course, applications dedicated to pulling

‘‘shalls’’ and ‘‘wills’’ from requirements documents and creating an RTM for

you. If you use one of these programs, don’t trust it completely. Although they

are quite good, they do make mistakes in judgment. It’s up to you to ensure

that the RTM is complete and accurate.

The U.S. Army defines traceability as:

The capability to track system requirements from a system

function to all elements of the system which, collectively or in-


dividually, perform the function; an element of the system to

all functions which it performs; a specific requirement of the

source analysis or contractual constraint which originated the

requirement. Traceability includes tracking allocation design

(and technical program) requirements through the work breakdown

structure between the system level and the lowest level of


Most requirements documents, including SOWs and specifications, contain

statements that follow the general convention of ‘‘The system shall . . . . . .’’

These are referred to as ‘‘shalls’’ and, in some cases, ‘‘musts’’ that constitute the

core requirements of the system. Care must be taken to evaluate the use of the

words ‘‘will’’ and ‘‘should’’ by the document creator. In some cases, ‘‘wills’’ or

even ‘‘shoulds’’ are treated the same as ‘‘shalls’’ while in other cases ‘‘shalls’’ are

mandatory and ‘‘wills’’ are optional. If the word ‘‘goal’’ shows up, try to get it

quantified. I assure you that your interpretation of a goal will be different than

the customer’s interpretation of it.

To ensure that your system or product is exactly what the customer has

specified, conduct a ‘‘shalls’’ and ‘‘wills’’ search, and place the results in an

RTM. The usual convention is to place the reference paragraph on the far left

and the requirement in the next column. Further columns trace the requirement

through your system following the way your company does business and the

nature of the output product. The concept, however, is the same regardless of

methodology or product.

You can create and print forms for this purpose or you can use a spreadsheet

application such as Excel or Lotus to accomplish the same purpose. To start the

process, use your word processing program such as MS Word or MS Works or

MacWrite or a similar program to search for the ‘‘shalls’’ __________and ‘‘wills.’’ When

you find one, simply copy and paste and include the paragraph number. If your

programs are compatible, such as MS Office, it is a simple matter to transfer

the entries from the word processing program to the spreadsheet program.

Be cautious in the construction of your RTM. Don’t necessarily limit it to

‘‘shalls’’ and ‘‘wills.’’ If you customer has some other way of stating mandatory

and lesser requirements, that is certainly the convention to follow.

The point and purpose of an RTM is to trace a requirement from its begin-

*U.S. Army Field Manual (FM), 770–778.


ning in the requirements document (contract) to its final proof, such as the

System Test. There must be enough detail in the RTM to point immediately to

the place, paragraph, table, etc., where the requirement is allocated.

You should assign each requirement to a monitor. The monitor should be

listed in a column in the RTM. You may assign more than one requirement to

a person but don’t simply assign all requirements to the chief engineer. Show

the actual person responsible for that requirement.

In general, your RTM should look similar to Table A7-1.

T a b l e A 7 - 1 — R e q u i r e m e n t s T r a c e a b i l i t y M a t r i x ( R T M )

Unit System

SOW/ WBS S/C SOW/ Test Test

Spec Para Requirement Number Spec Para Number Para Monitor


4.3.1 Security 06-03-02 N/A T-0304 4.4.1 Smith


3.2.1 System weight 02-04-03 3.4.6 T-0045 3.4.1 Jones

shall be less

than 10,000


The same concept and organization can be applied to a Subcontract Requirements

Traceability Matrix (SRTM) and used by your subcontractor.

For a small project, you can use a spreadsheet program. For a larger program

you can use a spreadsheet ‘‘workbook’’ with requirements in one sheet, WBS

information on the second sheet, etc. You can then link the cells together with

hyperlinks from a master sheet to form a thread of information for each requirement.

You can also do the same thing with a Relational Data Base (RDB). The RDB

will require more up-front time but will result in a more cohesive product.

The current industry standard is a family of products titled DOORS (for

large and enterprise wide projects) and DOORSrequireIT (for smaller projects).

Both are commonly referred to as ‘‘Doors.’’ Doors is available from:

Telelogic DOORS North America

400 Valley Road, Suite 200

Mt. Arlington, NJ 07856

Phone: 949-830-8022

Fax: 949-830-8023

To order: 877-275-4777

E-mail: doorssupport.us@telelogic.com

Web site: www.telelogic.com/doors