-

,,_, 

. S· DEPARTMENT OF THE 

and Procedures 

1.- The purpose of this directive is to provide 

2. 

, consistent guidelines for implementation of the 

of Surface Mining Reclamation and Enforcement (OSM) , Information systems Management Program. 

NOTICE! TKIS DIRECTIVE REFERS TO THE OSM ADP SERVICES 

-OFFICE AS THE MANAGEMENT INFORMATION SYSTEMS DIVISION. 

READERS NOTE THAT UNTIL FURTHER NO'l'ICE, THIS OFFICE WILL BE 

REFERRED TO AS THE ASSISTANT DIRECTOR, INFORMATION SYSTEMS 

MANAGEMENT, 

Processing 

eguipment 

mediums. 

and Procedures Manual is a comprehensive, 2. l~~~~::~:i:T;'h e~;;a,jt,it!!a~'c::h~~ed Information Resources Management which describes the Information 

organization, defines the IRM program, 

and explains policies and procedures relative 

to ADP, telecommunications, and data administration. 

4. Policies and Procedures. The five chapters in the IRM 

Policies and Procedures Manual prescribes the goals, 

responsibilities, policies, and procedures for managing 

information systems, capabilities, services, and associated 

resources. 

5. Reporting Requirements, None. 

6. Effect on other Documents. Supersedes the following: 

a. Directive ADP-2 1 Bureau Information Resources security 

program, dated March B, 1988. 

b. Directive ADP-3 1 system Implementation standards, dated 

September 1, 1986. 

c. Directive ADP-4 1 standardization of Microcomputer 

Software, dated January 31 1 1989. 
d. Directive INF-11, Information Systems Management 

Program, dated October 26, 1982. 

7. References. Information Resources Management Policies and 

Procedures Manual, Appendix B. 

8. Effective Date. Upon issuance. 

'· Assistant Director, Information Systems Management 

or FTS 268-2915. 

10. Keywords. Information Systems, Policy, ADP, 

Telecommunications, Hardware, Software, Computer. 

11. Appendix. Information Resources Management Policies and 

Procedures Manual. 
OFFICE OF SURFACE MINING 

INFORMATION RESOURCES 

MANAGEMENT (IRM) 

POLICIES AND PROCEDURES MANUAL 

Division of Management Information Syetems 

Office of Swface Mining 

U.S. Department of the Interior 

January 1991 
OFFICE OF SURFACE MINING 

INFORMATION RESOURCES MANAGEMENT POLICIES AND PROCEDURES 

TABLE OF CONTENTS 

"•" of Last 

Page Update 

I. MIS ORGANIZATION .............................. I-1 

II, IRM PROGRAM MANAGEMENT . . . . . . . . . . . . . . . . . . . . 11-1 

A. Program Defiuition, Goals, . . . . . . . . . . . . . . . . . . . . . . . . II-1 

and Responsibilities 

B. IRM Policy and Program Coordination ............... Il-0 

C. IRM Planning .................................. Il-0 

D. IRM As.sel!llment Program ........................ II-15 

E. Economic Analysis in Support of •..••.............. II-19 

IRM DecWonmaking 

F. Information Rasources Standards Program ........... II-21 

G. Information Rasources Security Program ............ II-25 

IV. AUTOMATED DATA PROCESSING (ADP) ............ III-1 

A. ADP Acquisition ................................ III-1 

B. ADP Cost Accounting, Cost Racovery, ............... III-15 

and Sharing 

C. Life-Cycle Managl!ment of ADP ................... III-17 

fufurmationSysteDll! 

D. ADP Resouroo fuventories ....................... III-35 

E. Automated Information Systems , , .. , .. , .. , , . , , .. , . III-39 

Management Accountability 

IV. TELECOMMUNICATIONS ......................... N-1 

V. DATA ADMINISTRATION . . . . . . . . . . . . . . . . . . . . . . . . . V-1 

iii 

Jan. 1991 

Jan. 1991 

Jan. 1991 

Jan. 1991 

Jan. 1991 

Jan. 1991 

Jan. 1991 

Jan. 1991 

Jan. 1991 

Jan. 1991 

Jan. 1991 

Jan. 1991 

Jan. 1991 

OFFICE OF SURFACE MINING 

INFORMATION RESOURCES MANAGEMENT POIJ:CIES AND PROCEDURES 

LIST OF APPENDICES 

. .., 

Appendix A Office of Surl'ace Mining ADP Documentation 

Content Guidelines .................................. A-1 

Appendix B Cumulative List of References .......................... B-1 

Appendix C Office of Surface Mining Management 

Information Systems Division Contacts ................... C--1 

OFFICE OF SURFACE MINING 

INFORMATION RESOURCES MANAGEMENT POLICIES AND PROCEDURES 

"""" 

II-1 

LIST OF FIGURES 

Description Page 

Information Resources Management (IRM) Strategic Plan 

and Budget Formulation: Major Milestones .................... II-10 

II-2 Applications Portability Profile (APP) Component$ ............... II-23 

III-1 OSM Core Software for Microcomputers and Networks . . . . . . . . . . . III-4 

III-2 DOI/OSM ADP Acquisition Threshold Summary . . . . . . . . . . . . . . . . IU---6 

JII--3 Department of the Interior System Life Cycle ................. III-19 

III-4 Comparison of OSM Minimum Documentation Requirements . . . . . . III-24 

III-5 Summary of Minimum Documentation Requirements 

and Reference Numbers for OSM Level 1 . . . . . . . . . . . . . . . . . . . . . III-27 

III-6 Summary of Minimum Documentation Requirements 

and Reference Numbers for OSM Level2 ..................... III-28 

III-7 Summary of Minimum Documentation Requirements 

and Reference Numbers for OSM Level 3 . . . . . . . . . . . . . . . . . . . . . III-29 

III-8 Summary of Minimum Documentation Requirements 

and Reference Numbers for OSM Level4 . . . . . . . . . . . . . . . . . . . . . III-31 

v 

This page intentionally blank 
I 
Chapter I 

MIS ORGANIZATION 

MIS ORGANIZATION 

............ 

This section describes the organization of the U.S. Department of the Interior (DOIJ 

Of'fu:e of Surface Mining (OSM) Management Information Systems Division (MIS). 

2. Definitiml.s 

a. Terms 

Information Resources Management. Coordination and direction of the planning, 

development, acquisition, and use of ADP hardware, software, telecommunications, 

and personneVmanagement functions for the purpose of managing the data and 

information required to fulfill the mission and goals of OSM. 

b. Abbreviations 

ADP Automated Data Processing 

DOI Department of the Interior 

GSA General Services Administration 

IRM Information Resources Management 

MIS Management Information SyBtems Division 

OSM Office of Surface Mining 

3. Policy/Procedures 

I. 

a. Policy 

Coordination and management of OSM information resourees is provided by the 

MIS Division Chief, who reports to the Deputy Director for Administration and 

Fiuance. The MIS organization is described in OSM Directive OPM-11. 

b. Procedures 

Cb..anges in the responsibilities of the MIS Division Chief will be effected through 

the OSM directives system and must be approved by the Director of the Office of 

Surface Mining. 

c. Responsibilities 

The MIS Division Chief is responsible for all IRM programs and activities at OSM, 

including establishing and maintaining policies and prograiilll in the areas of IRM 

Planning, IRM Program Assessment, Economic Analysis and Life-Cycle 

DMIS Organization 1-1 January 1991 
Management, Information Standards, and Information Resources Security. Specific 

program responsibilities are detailed in Chapter II of this manual. 

4. Reporting Requirement111 

The DOl Departmental Manual specifies reporting requirements for various wmponents of the OSM IRM program. The MIS Division Chief ill the Agency IRM Coordinator and, as such, provides the IRM reports required of OSM by DOL GSA, and others. 

5. References 

Department of the Interior Departmental Manual, Oreanization of Office ofiRM, 

UODM 10. 

OSM Directive OPM-11, Information Systems Management Directorate Organization 

and Functional Statements. 

6. Effect on Other Document& 

7. Effective Date 

Upon issuance 

8. Contact 

MIS Division Chief 

I. 

DMIS Organization l-2 January 1991 
ChapterTI 

IRM PROGRAM MANAGEMENT 

1RM PROGRAM MANAGEMENT 

A. PROGRAM DEFINITION, GOAlS, AND RESPONSIBILITIES 

l.Purpooe 

Management 

Thi.s section defines the Office of Surface Mining (OSM) Information Resources 

(!RM) program and identifies associated goals and responsibilities. 

2. Definitions 

\ 

a. Terms 

Information Resources Management. Coordination and direction of the planning, 

development, acquisition, and IY!e of ADP hardware, software, telecommunications, 

and personne1'manajfement functions for the purpose of managing the data and 

information required to fulfill the mission and goals of OSM. 

b. Abbreviations 

ADP Automated Data Processing 

DOl Department of the Interior 

IRM Infonnation Resources Management 

MIS Management Information Systems Diviaion 

OSM Office of Sur:filce Mining 

3, Policy!Procedures 

a. Policy 

1) The goals of the OSM lRM program are as fullows: 

• Provide responsible analytical and systems support as required to assist 

prograzu managera in meeting the variou.s OSM missions. 

II.A 

• Coordinate systems within OSM to prevent or minimize duplication of data 

and functions and to provide compatibility where feasible. 

• Conserve resources and meet ideJ!tified support needs through the mo.st 

economical and efficient means available. 

• Ensure compliance with l"f!gulatory requirementa. 

Program Definition II-1 January 1991 
• Assiat the States in sharing technological advances in the field of information systems as related to the OSM mission in administering Public Law 

95-87, the Surface Mining Control and Reclamation Act of 1977 (SMCRA). 

2) Some IRM responsibilities may be delegated to other OSM assistant directorates. For example, in IIOlile instances ADP procurement authority has been 

delegated to the field. When IRM responsibilities are delegated, the assistant 

directorates receiving the IRM control and respou~~ibility will be required to be 

aware of and comply with pertinent polides and regulations promulgated by 

OSM, DOl, and/or other Federal authorities. The MIS Division Chief will 

provide oversight and guidance as needed. 

3) The MIS Division Chiefia responsible for maintaining a staff with a level of 

technical and management IRM skills commensurate with IRM requirements. 

b. Procedures 

Nooo 

c. Responsibilities 

IT.A 

1) The MIS Division Chief is responsible for the following: 

a) Establishing OSM polides for ADP and program informational activities 

consistent with DOl and Federal requirements. 

b) Collecting, maintaining, analyzing, and dis~inating data, statistics, and 

program information in support of the OSM miasion. 

c) Developing, in a 0011t-effeetive manner, new or enhanced management 

information syatema and romputer technologies to support new or continuing OSM miaaiona. 

d) Identifying and evaluating emerging ADP technologies to support OSM 

administrative, technical, and programmatic needs. 

e) Ensuring that existing management information systems and computer 

technologies are operated and maintained in an efficient manner in support 

of the OSM mission. 

f) Where required by OSM mission needs, providing support for the management information systems and computer technology requirements of the 

State regulatory authorities. 

2) When delegated IRM authority, Assistant Directors are responsible for: 

a) Within the assistant directorate, ensuring compliance with OSM, DOl, and 

Federal IRM policies and regulations. 

Program Definition II-2 January 1991 
" 

b) Maintaining a level ofteclurieal and management skills commensurate 

with mission requirements. To this end, Aasistant Direciors mU8t maintain 

an environment that fosters staff development. An essential part of this 

development ia training. Depending upon individual skill levels and 

professional requirements, training in the following areas may be 

bene£clal: 

• Use of commercial software packages 

• Applicatioo development using a specific package or language 

• Hardware 

• Telecommunicatiolll! 

• System development life-cycle activities, including training in system 

development and project management. 

A number of options are available fur training: vendor-supplied training 

00Ul'8es; training developed in-house; or classroom, self-study, hands-on, 

and computer-based training. 

4, Reportin&' Requirements 

No~ 

5. References 

Department of the Interior Departmental Manual, Part 375 DM 1, IRM Program 

Management-Program Definition, Goals, Responsibilities. 

OSM Directive OPM-11, Informati011 Systems Management Directorate Organization 

and Fuuctional Statements. 

Office of Management and Budget, OMB Circular A-130, Management of Federal 

Information Resour«!s. 

General Services Administration, Federal Information Resources Mana~ment 

Regulations. 

6. E:B'ect on Other Documents 

Supersedes OSM Directive INF-11, Information Syatelll$ Management Program, 

26 October 1982. 

7. Ef'feetive Date 

Upon isswmce 

II. A 

Program Definition 11-0 January 1991 
" 

8. Contact 

MIS Division Chief 

!LA 

Program Definition 11-4 January 1991 
B. IRM POLICY AND PROGRAM COORDINATION 

1. Purpose 

This section describes the development and implementation of Office of Surface 

Mining (OSM) Information Resources ManaieJnent {IRM) policies and procedures. It 

also describes the program coordination organizations available to facilitate this 

development and implementation. 

2. Definition& 

a. Terms 

IRM Coordinator. Individual appointed by an Assistant Dir<:!etor to serve as the 

focal point foc IRM communication within and across assistant dkectora.tes. This 

includes plsnning, developing, implementing, and monitoring IRM activities within 

the assistant directorate. 

b. Abbreviatione 

ADP Automated Data Processing 

DOI Department of the Interior 

GSA General Services Administration 

IRM Information Resoun:es Management 

MIS Management Information Systems Division 

OMB Office of Management and Budget 

OSM Office of Surface Mining 

S. Policy/Procedure!l 

a. Policy 

II.B. 

This OSM IRM Policies and Procedures Manual is the authority by which IRM 

program policy at OSM is established. The OSM IRM program is coordinated and 

managed by the MIS Division Chief, and all other assistant directorates actively 

participate in the program. 0SM IRM program policy is issued through the OSM 

directives system. In acoordance with the dkeetives system, eho..nges to IRM policy 

will be initially issued in draft form, will be available for review by interested 

OSM employees, and will be issued in final form after incorporation of comments. 

Through the directives system, copies of the directive will be furnished to the DOl 

Office of Information Resources Management within 30 days of issuance. 

To facilitate effective management of information resoun::es, IRM policy development and implementation will be COOJ"dinated throughout OSM and with other 

agencies. To this end, participation in Federal and industry information syatems 

organizations is encouraged. 

IRM Policy & Program Coordination Janusry 1991 
II.B. 

Primary OSM IRM coordination organizations include: 

1) Mauagement Information Systems Field Liaison Program 

To facilitate communication throughout OSM, the MIS Field Liaison Program 

has been established. Each Field Office Director and each Assistant Director is 

responsible for appointing one or more IRM Coordinatora to participate in this 

program. IRM Coordinatora will meet at least twice each year to discuss 

activities pertinent to ADP and IRM issues across OSM. The MIS Division 

Chief oversees the MIS Field Liaison Program. 

2) MIS Field Liaison Subcommittees 

Informal ADP-issue-specific subcommittees have been formed to provide input 

and comments from a user and field perspective on issues of interest to IRM 

Coordinators throughout OSM. These &roups work with the MIS Field Liaison 

Program to provide assistance W the MIS Division Chief on ADP i$8ues. 

3) OSM ADP System Usex Groups 

A user group is an organization established to communicate application-specific 

information between the user community and the application developera and/or 

maintenance personnel. The information communicated relates to the development, uee, and plWUled or potential enhancements of an application system. 

Official points of contact for OSM user groupe formed for major information 

systems developed for OSM will be established through the MIS Division. 

Chief. 

4) Other Government and Industry Organizations and AssociatiOD$ 

The MIS Division Chief will ensure that OSM obtains important information 

regarding current trends in information management and will disseminate this 

information to affected OSM organizations. The MIS Division Chief will also 

ensure appropriate OSM participation in departmental and other Government 

and industry organizations and councils. Examplee of these groups are: 

Federal and Interdepartmental-

• Departmental-Level Working Group on IRM (Policy), chaired by OMB 

• Interagency Telecommunications Committee (advisory committee to GSA) 

• Interagency Committee on Automared Data Processing 

• Subcommittee: Federal ADP Users Group 

• Information Resources Council, established by DOl 

• Integrated Software Federal User Group (ISFUG) 

Department-Wide/Inter-Bureau-

• Interior Digital Cartographic Coordinating Committee 

• Earth Science Data Standards Council 

IRM Policy & Program Coordination II-<! January 1991 
" 

• Information Resources Management Forum (principal internal DOl assembly 

for program review and advice) 

Industry-

• Product-specific user groups {for example, WordPerfect User Support Group). 

b. Procedures 

1) Any OSM employee may suggest changes to, or comment on, current and/or 

potential policies and procedures. In commenting on IRM policy and procedures changes: 

a) If the comments relate to a draft OSM directive, provide comments in 

acctll'dance with the memorandum transmitting the draft. 

b) If comments relate to an IRM policy/procedure eunently in effect or a 

sueeeated (new) policy/procedure, send them to the MIS Division Chiet: 

2) To atWnd meeting~~ or join IRM organizations and attend meeting&fworkshops, 

contact your local IRM Coordinator or the MIS Division Chief. 

c. Re8ponsibilities 

II.B. 

1) The MIS Division Chief is responsibkl for ovemil IRM policy and program 

COOl'dination, including: 

a) Keeping Deputy Directors, Assistant Directors, and Field Office Directors 

informed of relevant MIS activities t:.hrough pel'SOnal contact, periodic 

newsletters, on-site visits, and chairing ADP user group meetings. 

b) Providing a single point of contact and direct hande-on assistance for 

expeditious handling of user problems. 

c) Meeting with IRM Coordinators periodically to help plan and review 

system developn~ent activities. 

d) Coordinating field development effort.& to share development activities 

among the field officee. 

e) Evaluating proposed systems to determine if they have value at other field 

locations or throughout OSM and assuming responsibility for further 

systems development. 

:0 Working closely with IRM Coordinators to ensure compliance with configuration management processes, documentation standards, security issues, 

'"' 

IRM Policy & Program Coordination 11-7 January 1991 
g) Helping W elll!ure that all personnel receive training 011 new software 

packages, upgrades W core BOf\ware, etc. 

2) Assistant Directors are responsible fur appointing and supporting IRM Coordi· 

nators. 

3) IRM Coordinators are responsible fur: 

a) Attending IRM Coordinator meetings. 

b) Coordinating, as&isting, and informing lll!ei organi:r.atioill! with respect to 

information resour<:es management. 

4. Reporting Requirements 

The MIS Division Chief must be informed when IRM Coordinator appointments are 

made or are changed. The coordinator's name, organi:r.ation, position title, address, 

and FTS number should be Supplied upon appointment. 

5. Reference11 

Department of the Interior Departmental Manual, Part 375 DM 2, Information 

Systems Management-IRM Policy and Program Coordination. 

Paperwork Reducti011 Act (44 USC 3506(cX8)). 

6. Effect on Other Documents 

Nooo 

7. Ef&ctive Date 

Upon issuance 

8. Contact 

MIS Division Chief 

ILB. 

IRM Policy & Program Coordination 11-'l January 1991 
" 

C. IRM PLANNING 

··-

This section describes the Information Resources Management (IRM) planning process 

and provides policy and procedural guidance for planning the acquisition and use of 

information resources. It identifies the Office of Surface Mining (0SM) organizational 

element& involved in planning and sets forth their respective responsibilities. 

2. Definitions 

a. Terms 

IRM Strategic Piau. Document identifying the l011g·tenn direction to be followed 

by OSM for e011t-effeclive use of infurmation retiO\Il'CeS in support of the OSM 

mission and progrru:ns. 

b. AbbreviatiOlU! 

ADP Automated Data Processing 

DOl Department of the Interior 

IRM Information Resources Management 

MIS Management Information Systems Division 

OSM Office of Surface Mining 

3. Policy/Procedure. 

a. Policy 

IlC. 

1) The MIS Division Chief will develop, maintain, and IUlllually update an 0SM 

IRM Strategic Plan. This plan will be integrated with lllission plans and 

budget strategies and will serve as the basis for developing or acquiring 

information resources. The annual plan will be developed in accordance with 

the schedule establi8hed by the DOl Office of Information Resourees Management (see Figure II-1). 

2) The IRM Strategic Plan will identitY the OSM IRM goals for the next 5 years, 

identify progress against the objectives of the previous annual submission, and 

identifY initiatives and projects with budget requirements and timelines for 

aa:omplishing the new or revised strategic IRM objectives. 

3) The MIS Division Chief will also develop an annual ADP and Telecommunications Acquisition Plan in accordance with OSM Directive PRC-4, Advance 

Procurement Planning. The annual ADP and Telecommunications Acquisition 

Plan will be incorporated into the IRM Strategic Plan. OSM will use the 

IRM Plaruring II-9 January 1991 
Presidents 

·-""'. 

Figure 11-1 

INFORMATION RESOURCES MANAGEMENT (IRM) STRATEGIC PLAN 

AND BUDGET FORMULATION: MAJOR MILESTONES 

""- OSM 

-~ """"' - lnfonnation ··- .... """""""' , . ....., Jb:yH• Burea~ - Budget(.f3A&:B) .... ._ -·- ...... 

""- ""' """""' M••••···· initialed 

·-ReYio-

·-

1RM Review AJS Policy 

Council Management with request 

Reviews & Budget ·-

·- ,...~,-· . MPians Directorale 

OffiCeS 

-

Complete 

IRM Planning 

O

"

A

c

I January !February I Man:h I April I May I June I July I August ISepcemberfOctober fN

II.C. 

IRM Planning II-10 
" 

combined plans as the basis fOl' developing statements of work, specifications, 

and requisition:;; fur procurement action to acquire information reaources. 

b. Procedures 

II. C. 

1) Field offices and W!sietant directorates will prepare the following planning 

input and provide it to the MIS Division Chief by 31 Dec.ember of each year: 

• Description of deficiencies and problems related to IRM. 

• ldentiflCation and description of opportunities for using information resources to improve productivity. 

• A Five-Year ADP and TelecommWiications Acquisition Plan 

• Plans within the activity to acquire or develop information resources 

through {at a minimum) the next fi.8cal year. This should cover all plans for 

information oollecti.on, application systema modernization and maintenanctJ, 

data bases, ADP technology, ADP facilities, telecommunications, office 

automation, records management, support services, and information dissemination. 

The plans should be consistent with anticipated budgets and should 

include the following: 

Application/Project N wne 

Functional Description 

Anticipated Software Environment 

(for example, operating system required, programming language) 

Anticipated Hardware Requirements 

(fur example, CPU required, memory aud storage requiremeu.tll) 

Planned Installation Date 

Estimated Level of Effort/Cost 

• One-Time/Installation Costs: 

- OSM Employee Effort/Cost 

- Contractor Effort.ICost 

- Equipment/Software Cost 

-Other Coet 

• Recurring/Monthly Costs: 

- OSM Employee Effort.ICost 

- Contractor Effort/Cost 

-Equipment/Software Cost 

-Other Cost 

Anticipated Documentation Level 

(see Section III.C, Life-Cycle Management of ADP Information Systems) 

Developer(s) 

OSM Technical Project Officer {Name, Position, FTS Number) 

OSM IRM Project Coordinator {Name, Position, FI'S Number) 

IRM Planning 11-11 Jauuary 1991 
" 

2) Each year, the MIS Division Chief will revise the OSM IRM Strategic Plan and 

develop an ADP and Teleeommunieations Acquisition Plan in accordance with 

guidance set forth in the Departmental Manual (375 DM 4) and OSM Directive 

PRC-4. This proceSll will include evaluating the prior year's performance with 

respect to attainment of goals; reviewing and updating the sum!llary of current 

problems and deficiencies; and refining short- and long-term objectives and 

goal.$ based upon OSM-specific information needs, available resoUl'«ls, and 

industry-wide information management and technology trends. The draft IRM 

Strategic Plan will be prepared by the ISM Assistant Directorate in aceordanctJ 

with the schedule set l'orth in 375 DM 4. Upon DOl approval, the OSM IRM 

Strategic Plan will be available for dissemination throughout OSM. 

c. Responsibilities 

1) The MIS Division Chief is responsible for: 

a) Coordinating the development, maintenance, and updating of the annual 

OSM IRM Strategic Plan. 

b) Providing inp-ut as required for the DOl IRM Strategic Plan. 

c) Preparing an Advance Procurement Plan, as required. 

2) Field Office Directors are responsible for: 

a) Obtaining the Assistant Director's approval for the acquisition and U$(! of 

inful'IIUltion resourcea within the field office. 

b) Providing field office input to the IRM strategic planning process in acwrdan.ce with the procedures &et forth in section II.C.3.b above. 

3) Asaistant Directors are reaponaible for: 

a) Mission-related program planning for programs that may involve ADP 

technology. 

b) Providing aasiatant directorate input to the IRM strategic pl!llllling process 

in accordance with the procedures set forth in section II.C.3.b above. 

4. Reporting Requirement& 

Aa described in section II.C.3 above: 

1) Field Office DirectorB and Aasi.stant Directora will provide input to the IRM 

strategic planning proceaa by 31 December of each year. The input will be provided 

to the MIS Division Chief. 

ILC. 

IRM PlWllling II-12 January 1991 
2) The MIS Division Chief will prepaxe and maintain an IRM Strategic Plan in 

accordance with the requirements of 3715 DM 4. 

5. Reference~~ 

Department of the Interior Departmental Manual, Part 375 DM 4, IRM Program 

Man.age:ment-IRM Strategic Planning. 

Federal Manager's Financial Integrity Act. 

Federallnform.ation Reeources Management Regulation Subpart 201-19, Triennial 

Review of Agency Administration and Operation ofluform.ation Resources Mllllllgement Activities. 

Office of Management and Budget, OMB Circular A-130, Management of Federal 

Information Resources, 24 Dec 1985. 

Paperwork Reduction Act (44 USC 3506(cX8)). 

OSM Directive PRC-4, AdvB.llCe Procurement Planning. 

6. Eft'ect on Other Documents 

None 

7. Effective Date 

Upon issuance 

8. Contact 

MIS Division Chief 

ILC. 

IRM Planning II-13 January 1991 

This page intentionally blank 

II. C. 

IRM Planning IJ-14 January 1991 

D. IRM ASSESSMENT PROGRAM 

1. Purpose 

This section describes the Office of Surface Milling (OSM) Information Resources 

Management (IRM) assessment program, which is required by Federal policiee a.nd 

procedures. 

2. Definitions 

a. Terms 

Internal Controls. The steps taken to provide reasonable assurance that obliga· 

tiona and costs are in compliance with applicable law; funds, property, and other 

assets are safeguarded against waste, loss, unauthorized use, or misappropriation; 

and revenues and expenditures applicable 00 agency operations are properly 

recorded and acrounted for 00 permit the preparation of account~! and reliable 

flllJlDcial and statistical reports and to maintain accountability over the assets. 

IRM Review. Agency review of IRM activities to ensure that these are carried out 

in an efficient, effective, and economical manner. Selective reviews of agency IRM 

activities are also performed by OMB, togethe:r with GSA, at least once every 

3 years to assess their adequacy and efficiency. 

b. Abbreviations 

ADP Automated Data Processing 

DOl Department of the Interior 

GSA General Services Administration 

IRM Information Resolll'a!S Management 

MIS Management Information Systems Di.viaion 

OMB Office of Management and Budget 

OSM Office of Surface Mi.ni.ng 

3. Pollcy/Proeedures 

a. Policy 

1) OSM will prepare an Annual Review Assessment Plan for conducting periodic 

reviews ofiRM activities suclt as telecommunications, end·user computing, 

software management, information management, and electronic filing. 

II.D 

ffiM Assessment Program. II-15 January 1991 
2) OSM will periodically assess IRM activities to ensure their adequacy and 

efficiency. This assessment will include an evaluation of the ability of systems 

to meet internal control objectives fur the following:' 

Information Collection 

• Information collected is meaningful and useful. 

• Information collected is reliable. 

• Infurmation is arrauged in an orderly fashion. 

• Information is maintained on a CUITent basis. 

Correspondence Handling 

• Correspondence is channeled to the appropriate parties. 

• Replies are made promptly, accurately, and responsively. 

Records Maintenance 

• Records are readily available. 

• Records are adequately protected 

• Only necessary records are maintained. 

ADP 

• Proper authorization of transaction inputs, adequate edit checks, and 

necessary safeguards of sensitive input forms ensure accurate, proper, 

complete, and timely entry of information. 

• Adequate security measures prevent unauthorized system acceSB or improper changes to or loss of data. 

• Appropriate controls can detect unauthorized uae of the system. 

• Outputs are produced accurately, completely, and on time. 

b. Procedures 

1) The IRM Reviews will be conducted by the operations staff in accordance with 

established guidelines on IRM. 

2) The internal control objectives will be evaluated during Federal MBllRiS:t's 

Financial Integrity Act (FMFIA) reviews. 

c. Responsibilities 

The MIS Division Chief is tflsponsible for: 

1) Establishing and maintaining an internal IRM assessment program. 

2) Establishing and providing reporting mechanisms as required by the DOl 

implementation of the Federal IRM Review Program. 

1 Source: Executive Office of the President, Office of Management and Budget, futernal 

Control Guidelines, December 1982. 

II.D 

IRM Assessment Program II-16 January 1991 
3) Participating in and providing required information foc compliance assessments conducted by the DOl Office of Information Resources Management. 

4) Providing plans to the Director of the DOl Office of Information Resources 

Management for assessments to be conducted during a fiscal year WI required 

by the DOl Office of InfOrmation Resources Management WI part of the review 

process mandated by the Paperwork Reduction Act. 

5) Responding to and initiating follow-up actions relating to the findings and 

recommendatioll$ included in internal and DOl assessment reports. 

4. Reporting Requirements 

Annual schedule of assessments i.a submitted to GSA WI part of the Federal IRM 

Review Program and the triennial IRM review process required by the Paperwork 

Reduction Act. 

5. References 

Department of the Interior Departmental Manual, Part 375 DM 5, IRM Program 

Management.-IRM Assessment Program. 

General Services Administration, Federal Information Resources Managemen.t 

Regulations (FIRMR) Supplement, Federal IRM Review Handbook, 1985. See al'eo 

Appen.dix. B, Regulatory References. 

Paperwork Reduction Act of 1980 (44 USC 3501 et. seq.) 

Office of Management and Budget, OMB Circular A-130, Management of Federal 

Information Re&O\ll'OO$, 24 Dec 1985. 

Internal Control Guidelines 1982. 

6. Effect on Other Documents 

7. Effective Date 

Upon issuance 

ll.D 

IRM Assessment Program II-17 January 1991 
8. Contact 

MIS Division Chief 

Il.D 

IRM Assessmeut Program II-18 January 1991 
"" 

E. ECONOMIC ANALYSIS IN SUPPORT OF IRM DECISIONMAKING 

1. Purpose 

This section provides guidance for u~>e in conducting economic analyses in support of 

Office of Surface Mining (OSM) Information Resources Management (IRM) decisions. 

2. Definition11 

a. Terms 

Economic Wlalysis. An assessment of the llCOll.omic con&iderations, both costs Wld 

benefitll, for an ADP project; provides information for rational decisionmaking and 

establishes a common base for making comparisons of alternative methods for 

achieving the goal of the project. 

b. Abbreviations 

ADP A11tomated Data Proce9sing 

DOI Department of the Interior 

IRM Information Re&Ources Management 

MIS Management Information Systems Division 

OSM Office of Surface Mining 

3. Policy/Procedures 

a. Policy 

All ADP development projectll and procurements for hardware, software, and/or 

services will be analyzed to ensure that they are economieally feasible and 

justifiable. 

b. Procedures 

Coat.lbenefit analyses will be conductsd i.n wxordanoo with Federal, DOl, and OSM 

guidance (see references and also Appendix A, OSM ADP Documentation Requirements, outline for CosUBenefit Analysis). 

c. Respon&ibilities 

II.E 

1) The MIS Division Chief is responsible for ensuring that OSM ADP investments 

are economically feasible Wld jlll!tifiable. 

2) S11bject to delegation of ADP procurement authority from the MIS Division 

Chief, Assistant Directors and Field Office Directors are responsible for 

ensuring that coat/benefit analyses for ADP development/acquisition projects 

Economic Analysis II-19 January 1991 
" 

under their pUl"View are conducted in accordance with applicable guidance (see 

references and Appendix A). 

4. Reporting Requirement• 

Assistant DirecWn shall ensure that apptopriate coat/benefit analyses are forwarded 

to the MIS Division Chief along with other documentation supporting the request for 

approval. 

5. Referen0011 

Department of the Interio:r Departmental Manual, Part 375 DM 7, IRM Program 

Management-Economic Analysis in Support of IRM Decision Making. 

Department of the Interior, A Project Manager's Guide to Beneftt/C08t Analysis of 

Information Technology Investments, January 1989. 

Department of the Navy, Naval Data Automation Command, Publication 15, Economic 

Analysis Procedures for ADP. 

Office of Management and Budget, OMB Circular A-11, Preparation and Submission 

of Budget Estimates, Section 43.2. 

Federal Information Processing Standard Publication 64, Guideline@ for Doeumenta· 

tion of Computer Programs and Automated Data Systems for the Initiation Phase, 

August 1979. 

6. Effect on Other Documents 

7. Effective Date 

Upon issuance 

8. Contact 

MIS Division Chief 

!I.E 

Economic Analysis II-20 January 1991 
F, INFORMATION RESOURCES STANDARDS PROGRAM 

1. Purpose 

This directive describes the development, application, and maintenance of technical 

standards for Office of Surl'aoo Mining (OSM) Information Resources Management 

(!RM). 

2. Definitions 

a. Tei'Ill8 

American National Standards lll$titute (ANSP. The principal organization forming 

standards in the United States. Formed in 1918, it is a nonprofit, nongovernmental organization. 

Federal Information Processing Standards (FIPS). Standards developed under the 

Federal Government's standardization program and concerned with computer 

sciences, telerommunicaticms, and information management. 

International Standards Organization (180). A non-treaty organization founded in 

1947 and currently comprised of nearly 90 member nations. Each nation assigns 

its principal standardization body to the ISO. ANSI repnsents the United States. 

Voluntary standards. Standards that are established generally by private sector 

bodies and are available for use by any person or organization, private or governmental. They are commonly referred to as "industry standards~ or "consensus 

standards~ and do not include standards of professional conduct, institutional 

codes of ethics, private standards of individual firms, or standards mandated by 

law. 

b. Abbreviations 

ADP Automated Data Processing 

DOl Department of the Interior 

IRM Information Resources Management 

MIS Management Information Systems Division 

OSM Office of Surface Mining 

3. Policy/Procedures 

a. Policy 

If cost-effective and consistent with applicable laws and regulations, standards 

used in OSM will be based 011 existing Federal, OOJ, and OSM standards-in that 

order. Where these standards are not cost-eil'ective or are DOJ!e'listent, the use of 

II.F 

IRM Standards 11-21 January 1991 
II.F 

voluntary (industry) standards is preferred in lieu or developing in-house stan-

"""''· 

b. Procedures 

1) OSM organizatiOlUI will consider Federal, DOI, and OSM standards when 

evaluating and selecting information te80UI'Cell for use at OSM (see al110 section 

III.A, ADP Aoqulllition). Specific Federal or adopted standards important to 

improving applicatiolll! portability are detailed in Figure 11-2. Should an 

organization find that a particular standard is not COI!t-effective or 

is inconsistent with applicable laws or regulatiolll!, a request to disregard the 

standard will be submitted to the MIS Division Chief. This request shall 

include specific references, cost justificatiOlUI, and other explanations as 

appropriate. 

2) OSM employees with advice regarding proposed standards, the introduction of 

new standards, revisiolll! to existing standards, or requests fur waivers should 

contact the MIS Division Chief. 

3) At least once every 3 years, OSM standards will be reviewed to determine 

their continued applicability and economic benefit. 

c. Responsibilities 

1) The MIS Division Chief is reaponsible for: 

a) Implementing and maintaining Federal and DOl IRM standards. 

b) Providing advice on proposed standards, the necessity of new standards, 

needed revisions, and :requests fur waivers. 

c) Developing and implementing an 0SM IRM standards program and 

standards to supplement Federal and DOl standards. 

d) Ensuring that 0SM IRM standards are reviewed at least once every 

3 years. 

e) Establishing liaison between DOl and OSM on matters related to the 

development and implementation ofiRM standards. 

f) Maintaining an inventory of IRM standards and standards group!i in which 

OSM participates. 

2) Assistant Directors are respollllible for ensuring that information resourcee 

leased or acquired conform with applicable Federal, DOl, and OSM standards. 

IRM Standards IT-22 January 1991 
Figure TI-2. APPLICATIONS PORTABTI.JTY PROFILE (APP) COMPONENTS 

Function ADP Element Standard 

Operating System POSIX FIPS 151-1 

rl IEEE P1003.2 

Data Base Management SQL FIPS 127 

IRDS X3.138 (Proposed FIPS) 

Data Interchange; 

Business Graphics GKS andCGM FIPS 120, 128 

Product Data IGES NBSIR 86--8359 

Document Processing SGML ISO 8879-1986 

ODA/ODIF ISO/DIS 8613 

Network Services: 

Data Communications OS! FIPS 146 (GOSIP) 

File Management NF8 IEEE P1003.X 

User Interface X Window System X3H3.6 (Proposed FIPS) 

-· 

CGM 

FIPS 

GKS 

GOSIP 

IEEE 

IGES 

IRDS 

ISO 

NFS 

ODA/ODIF 

OS! 

POSIX 

SGML 

SQL 

II.F 

COBOL 

FORTRAN 

Ada 

P~..J 

ACRONYM DEFINITIONS 

Computer Graphics Metafile 

Federal Information Processing Standard 

Graphics Kernel System 

CX3Jll draft X3.159 

FIPS 021-2 

FIPS 069-1 

FIPS 119 

FIPS 109 

Government Open Systems Interconnection Profile 

Institute of Electrical and Electronics Engineers 

Initial Graphics Exchange Specification 

Information Resource Dictionary System 

International Standards Organil<!ltion 

Network File System 

Office Document Architecture/Office Document Interchange Format 

Open Systems Interface 

Portable Operating System Interface for Computer Environments 

Standard Generalized Markup Language 

Structured Query Language 

IRM Standards II-23 January 1991 
" 

4. Reportiq Requirements 

5. References 

Department of the Interior Departmental Manual, Part 375 DM 12, lRM Program 

Management-Information Resources Standards Program. 

DOl Strategic Framework, July 1988. 

Federal Information Processing Standards (FIPS). 

American National Standards Institute (ANSI). 

Institute of Electrical and Electronics Engineers (IEEE). 

International Organization for Standardization (108). 

Electronic Industries Association (EIA). 

National Institute of Standards and Technology {NIST) (develops FIPS). 

Federal Telecommunications Standards Committee. 

Internatiov.al Telegraphic and Telephone COllllultative Committee (CCI'IT). 

6. Effect on Other Documents 

7. Effective Date 

Upon i811uance 

8. Contact 

MIS Division Chief 

II.F 

IRM Standards ll-24 January 1991 
" 

G. INFORMATION RESOURCES SECURITY PROGRAM 

l.Purpooe 

This section defines policies, assigns respoDBibilitiee, and prescribes procedures fur 

management of the Office of Surface Mining (QSM) Information Resources Security 

Program. The purpose of the program is W protect OSM's information re!Kiun:eS 

against loss, theft, natural dia.asters sueh as fire or flood, improper use, unauthorized 

act:ells or disclosure, alteration, manipulation, violations of confidentiality, physical 

abuse, or unlawful destruction. 

2. Definitions 

a. Terms 

II. G. 

Information. Any commuuication or reception of knowledge such as fact8, data, or 

opinions, including numerical, graphic, or narrative forms, whether oral or 

maintained on paper or in media such as computerized data bases, microf'orm, or 

magnetic tape. 

Information Resoun:es. The personnel, technology (hardware and software), and 

monetary allowance used to create, oollect, store, use, and disllemi.nate informa· 

tion. 

Information Resourcell Security. The management controls and safeguards 

designed to protect information resources and ensure the continued performance of 

governmental activities during emergency situations. 

Information System. The organized collection, processing, transmission, and 

dissemination of information in acrordance with defined procedures, whether 

automated or manual. 

Information TecluwloiY Facility. An area containing the technological reso1Jl"008 

used to collect, prooe!lll, store, tranBmit, disllelDinate, and/or retrieve information in 

the form or format needed. Technologi.eal resources consist of large, medium, and 

lllllall data processing systems (including mainframe, mini-, and micro- computen!); 

peripheral and storage units; office automation equipment such as word processors 

and copiers; telecommunications equipment (for e:o::ample, switches and networks); 

and the associated software for these types of equipment. 

Information Technology Installation. One or more information technology facilities 

within clo~>e physical proximity which, from a management viewpoint, are logically 

considered a single entity. 

Data. A representation of facts, concepts, or instructions in a formalized manner 

suitable for communication, interpretation, or processing by human or automated 

means. 

Information Resources Security 11-25 January 1991 
II. G. 

" 

Data Base. A colleetion of data fundamental to a system or an enterprise. 

Data Base Administrator. The individual respollllible for managing the design and 

implementation of data base structures to mmdmize efficiency and effectiveness 

with regard to processing time and sWrage requirements. 

Sensitive Information/Data. Information or data that requires protection due to 

the ri!lk and magnitude of loss or harm that would result from inadvertent or 

deliberate disclosure, alteratiou, or deatruction. The term includes information or 

data whose improper use or disclosure could adversely affect the ability of an 

agency to accompliah ita mission; proprietary data; records about individuals that 

require protection under the Privacy Act; and data not releasable under the 

Freedom of Information Act. 

Sensitive Computer Application. A computer system that processes sensitive data 

or requires a degree of protection due to the magnitude of loss, risk, or harm that 

could result from inadvertent 01' malicious manipulation of the application. 

Records. All written, machine-readable, audio-visual, and other documentary 

materials, regardless of physical form or characteriatiea, made or received by OSM 

in pursuance of Federal laws or in connection with the transaction of public 

business and preserved or appropriate for preservation as evidence of the organization and its functions, policies, decisions, procedures, operations, or other 

activities, or because of the infOrmational value of the recorded data. 

System of Records. As defined by the Privacy Act ofl974: ~A group of any reoords 

under the control of any agency from which infOrmation is retrieved by the name 

of an individual or by some identifying number, symbol, or other identifYing 

particular assigned to the individual.~ 

Vital Records. Records or information deemed necessary to ensure continuity of 

essential governmental activities during nati(II18} emergency conditions. ReemdB 

e1!8ential to the protection of the riihts and interests of OSM and of the individuals fur whose rights and interests it has n~~~ponsibility. 

System Owners. Individuala responsible fur acquisition or development and/or the 

primary user of microcomputer systems, office automation systems, application 

systems, data bases, and/or manual information systems. 

Risk Analysis. The process used to establish the value of assets, review potential 

threats to those assets, and determine the cost of reasonable safeguards to protect 

them from damage or loss. 

Continuity of Opera tiona Plan. A plan to ensure support to users of information 

systems during interruptions, emergencies, and disaatere. 

Information Resources Security II-26 January 1991 
b. Abbreviations 

ADP 

BIRSA 

COOP 

DOl 

GSA 

IIRSO 

MIS 

OSM 

Automated Data Processing 

Bureau Information Resouree~~ Security Administrator 

Continuity of Operations Plan 

Department of the Interior 

General Services Administration 

I1111tallation Information Resources Security Officer 

Management Information Systems Division 

Office of Surface Miniug 

3. Policy!Prooedu.res 

a. Policy 

II. G. 

The OSM Information Security J>ro&ram will enBure that adequate measures are 

established to provide an appropriate level of protection fOl" the information 

resources under OSM's authority. The program complies with all Federal policies, 

procedures, wtd standards governing information resourees security. The provisions of this policy shall: 

1) Combine all the requirements and responsibilities fOl" manual and automated 

information resources security into one policy aud establish responsibilities 

and procedures for the development, administration, and maintenance of an 

information resources security program for OSM. 

2) Apply to all OSM divisions and offices and their employees and to the personnel and facilities of contractors providing infonnation resources support to 

OSM. 

3) Concern information that is not related to national security. (National security 

issues are subject to more stringent security policies and procedures.) 

4) Pertain to, but are not limited to, the following: 

a) Information created, transmitted, stored, processed, 01" disseminated in any 

media Ql" form {for example, magnetic tape, microfilm, paper documents). 

b) Information in any form when used as input to or retrieved from an 

information system. 

c) Information technology facilities used in the collection, processing, storage, 

communication, and retrieval of information. 

d) Other technical systems, such as supervisory process control systems 

(except those identified in the Department ofDefen.se Authorization Act of 

1982). 

Information Resources Security 11-27 Jwtuary 1991 
e) The pi'(IOO$f!(!S, procedures, and software involved in any of the above 

activities. 

b. Procedures 

II.G. 

Successful implementation of an information resources security program is 

dependent upon accurately detennining potential risks and instituting safeguards 

to minimize them. Every OSM information BYBtem and every information technology facility operated by or on behalf of 0SM must be protect.ed System owners and 

re~ managers arn responsible fur the protection ofillfonnation systems and 

facilities under their control. The fullowing activitia will be performed ro ensure 

that all systems are protected. 

1) Risk Analysis. Conducting a risk analysis i.s the first step in establishing a 

security plan. Risk analyses mllilt be conducted fur all information technology 

facilities, all automated application systems, and all manual application 

systems covered by the Privacy Aet. The extent of the risk analysis performed 

should be commensurate with the magnitude and use of the resources to be 

protected. Guidance for performing a risk analysis can be found in the National Bureau of Standal"ds (NBS) Fedr!rallnformation Processing Standards 

(FIPS), Publications 31 and 65. 

a) InfOrmation Technology Facilities and Automated Application Systems. A 

risk analysis shall be conducted at least every 5 years if one has not been 

conducted within that timeframe under the following special circumstances: 

when planning the development of a new sysWm or facility, when significant changes are made to the nature or relative sensitivity of data being 

processed or to the system or facility, and when environmental factors 

change in such a manner as to alter the threats presented. For automaWd 

systems processing sensitive data (such as information covered by the 

Privacy Act), a risk analysis should be conducted when the configuration on 

which the information i.s operated changes so as to create the potential for 

either greater or easier access. 

b) Manual System of Records. A risk analysis shall be perlormed when a new 

system of reoord.ll is proposed un&r the Privacy Act or when a proposed 

change to an existing system significantly alters the character of the 

system by increasing or changing the number or types of individuals on 

whom records are maintained; expands the types or categories of infOrmation maintained; alters the purposes for which the infOrmation is used; or 

exempts records maintained on individuals from any provision of the 

Privacy Act. 

2) Protection. Specific safeguards should be employed to provide a reasonable way 

to counteract each threat described in the risk analysis and to detect actual or 

potential security violations. At a minimum, the following procedures must be 

considered: 

Infunnation Resources Security 11-28 January 1991 
II. G. 

a) Physical Security. Appropriate practices and safeguat'ds must be used to 

minimize the following threats to those places whe>:-e information and 

technological resources are located: theft, unauthorized or illegal BCCellll, 

accidental or intentional damage or destruction, improper use, and ilnproper disclosure of information. 

b) Personnel Security. Appropriate Federal and contractor employees shall 

receive security clearances commensurate with the seruritivity of the 

information or ADP facilities they manage or use. Supervisors are responsible for detennllring the sensitivity of positions in their areas. System 

owners are responsible for ensuring that Federal personnel and contractors 

managing or using systems in their areas have appropriate senaitivity 

clearances. The criteria for determining sensitivity levels and the procedures for initiating sensitivity clearances are contained in OSM Directive 

PER-13, Personnel Security Program. Supervisors are responsible for 

ensuring that employees who use information and technological resources 

sign statements acknowledging their responsibility for the security of these 

resources. These statements shall be retained in the employee's official 

personnel folder. 

c) Technical Security. Appropriate safeguards (such as par;.swords, eucrypti011, 

and security software) shall be used to prevent unauthorized acceas to and 

use ofinformati011, data, and software resident on peripheral devices or 

storage media or in the process of communication via technological means. 

d) Administrative Security. Procedures to ensure that all information rescmrees are properly protected and that information technology re50\ll"CeS are 

used only by authorized peraonnel and for official use only shall be establiahed and disseminated. 

3) Automated Application Safeguards. The following specific procedures must be 

followed to ensure that appropriate safeguards are incorporated into automated application sys1;eioa. 

a) Determine appropriate security safeguards prior to system development or 

acquisition. 

b) Conduct design reviews and system tests prior to system implementation to 

ensure that the system satisfies the approved security requirements. 

c) Certify before implementati011 that a new system satisfies applicable 

policies, regulations, and standards and that its security safeguards are 

adequate. 

d) Evaluate the adequacy of security safeguards for existing sensitive systems 

at least every 3 years. 

Information Resources Security 11-29 January 1991 
4) Continuity ofOperatioil!l Planning 

a) Information Technology Facilities and Automated Application Syatems. 

Facility managers and Sflltem owners are respoilllible for developing a 

Continuity of Operations Plan for each information technology facility and 

each automated application system =der their control to eil!lure that 

interruptioil!l of service of whatever type or duration are kept to a mini· 

mum. The COOP shall be evaluated periodically to determine the contin· 

ued adequacy of the established procedures. The COOP shall be reviBed 

when indicated by changes in software, equipment, or other related factors. 

At a minimum, the COOP shall address the following? 

• Procedures for backup storage and recovery of data and software 

• Processing capabilities and procedures for transfuning operations to an 

alternate site 

• Consistency between application system COOPs and the COOP of the 

infbrmation technology facility where the application is processed 

• Annual teating of the COOP at large ADP mainframe installations and 

other installations that provide essential ADP support. 

b) Manual Application Systems. A Continuity ofOperatio1111 Plan mllBt be 

developed for each manual apPlication system that contai1111 vital records to 

eusure its continll(!d protection and to eneure that essential OSM activities 

continll(! during periods of national emergency. These plans shall be 

reviewed annually and periodically tested =der emergi!Ilcy conditioos to 

ensure their adequacy. 

5) Security Awarene85 Activities. All OSM employees mUIIt be adequately trained 

to fulfill their security responeibilities. All contractor personnel mUIIt be 

advised of OSM security requirements and regulatioos. The level of security 

awareness activities in which employees participate shall depend upon their 

specific involvement with information resoun:es. Supervisors are responsible 

for eusuring that employees participate in one or more of the following levels of 

security awareness activities and that a record of this participation is retained 

in official personnel folders: 

a) Orientation, which includes an understanding of Federal regulatioil!l and 

standards and briefings, guides, and/or films designed to acquaint employees with the nature of risks information resources are subject to and the 

use of security meaaures to co\IIlteract them. 

'Federal Information Processing Standards {FIPS) Publication 31 contains guidance 

for developing contingency plans. 

II.G. 

InfOrmation Resources Security II--30 January 1991 
II.G. 

b) Education, which includes ciaBses and seminars deaigned to provide 

managers, ownen, users, and custodians of information and information 

technology reS()lllC(!S with a general undentanding of how to implement 

security me1111ures and how to determine if security breaches have occurred. 

c) Training, which includes more in-depth and formal classes designed to 

provide owners and uBenl, especially information technology professionals, 

with the ability to perform risk analyses, deaign protectioo programs, and 

evaluate the effectiveness of existing security programs. 

6) Acquisitions and Procurements. It is essential that appropriate safeguards be 

determined before procuring information technology resources, not only to 

ensure the wise ~nditure of funds, but also to eil!lure that resources are 

protected from the time of installation or implementation. To accomplish thi.a, 

all contract specificatioil!l for the acquisition of hardware, software, software 

development, equipment maintenance, facility management, and related 

services shall contain requirements for safeguards that encompllll$ technical, 

administrative, personnel, and physical security. 

7) Other Applicable Regulations. Personnel responsible for information resourees 

security must be knowledgeable of, and all activities must conform with, the 

DOl Departmental Manual, including the parts listed below. 

376 DM, Automated Data Processing 

377 DM, Telecommunications 

381 DM, Origination of Recorda and Information 

382 DM, Records Operatioilll 

383 DM, Policies and Procedures for Implementing the Privacy Act of 1974 

384 DM, Records Disposition 

385 DM, Office Automation Technology 

436 DM, Vital Recorda 

441 DM, Clearances and Suitability Investigation Requirements 

442 DM, National Security Information 

443 DM, Industrial Security Program 

444 DM, Physical Security 

8) Security Incidents. Each employee must report to the OSM officiala listed 

below at the time of discovery all sUllpecied, actual, or threatened security 

incidents involving information resources. The type of incident encountered 

will determine to whom it should be reported. The responsible OSM official 

will report the incident promptly to the appropriate management authority 

and follow up with a written report containing the location, the resources 

involved, and any corrective actions taken. If warranted, investigative action 

will be taken by the proper enforcement authority. 

a) Incidents involving physical, personnel, and national security complaints 

and violations shall be reported to the OSM Security Officer. Thill includes 

the destruction, physical abuse, or loss of technological resources. 

Information Resources Security Il--31 January 1991 
b) Incidents involving records and their unlawful removal, defacing, alteration, or destruction shall be reported to the Records Management Office 

for subsequent notification of the OSM Director and the National Axchives and Records Administration. 

c) Incidents involving Privacy Act violations shall be reported to the 08M 

Privacy Act Officer for coordination of corrective action with the pertinent program/system menag.:,r. 

d) Incidents involving technology resourees resulting in the loss of data, 

fraud, or compromise or discl011ure of sensitive material shall be reported 

at the time of discovery to the Bureau Information Resources Security 

Administrator (BIRSA). 

c. Respom;ibilities. All personnel aasociated with the transmission, handling, and 

dissemination of information or data share reeponsibility for its protection. 

II. G. 

1) The DOl Office of Information ReaoUI'088 Management is responsible for 

conducting periodic reviews and evaluations of OSM information resourees 

security programa to euaure complian.ce with Federal and DOl directives. 

2) The Director of the Office of Surface Mining is responsible for promoting an 

attitude of concern for security among OSM employees. The D.irector is 

responsible fur establiahing and implementing an effective information 

resources !leCurity program that conforms to Federal and DOI regulations. 

3) The MIS Division Chief is respoMible for; 

a) Oversight of OSM's compliarn:e with Federal and DOl policies, guidelines, and regulations pertaining to information resources security. 

b) Appointing a BIRSA and alternate to coordinate the management of 

OSM's information resources security program. Both the BIRBA and 

alternate must be knowledgeable in information technology and security 

matters and be department employees un1e&s a waiver is eranted by the 

DOl Information Resources Security Administrator. 

4) The ABsistant Director for Budget and Admtnistration is responsible for 

oversight of OSM's compliance with Federal and DOl policies, guidelines, 

and reguiatiollf! pertaining to phys:ical, personnel, and information security 

programs. The OSM Security Officer, Recorda Management Officer, and 

Privacy Act Officer have specific responsibilities for performing these functions. 

5) All ABsistant Directors and Field Office Directors are responsible fur appointing an Installation Information Resources Security Officer (llRSO) and alternate, and for designating resource managers and owners for facilities and 

systems under their jurisdiction. The IIRSO and alternate must be knowlInformation Resources Security II-32 January 1991 
ILG. 

edgeable in information technology and security matters and must be 

department employees unless a waiver iB granted by the DOl Information 

Resources Security Administrator. 

6) The BIRBA is responsible for administration of the information resources 

security program, coordinating all OSM activities designed to protect information reSOUl'Ce$, promoting security awareness, and reporting on the efl'ectivenese of these activities to OSM and departmental management. The 

BIRSA will consult with all OSM officials that have security responsibility 

(for example, the 0BM Security Officer, the Records Management Officer, 

and system owners) to ensure that information resoW'OOll are adequately 

safeguarded throughout OSM. The responsibility assigned to the BIRSA does 

not supersede or replace security responsibilities previously assigned to any 

other OSM official. 

7) The IIRSO iB responsible for coordinating all activities related to the manaaement of an installation's information resources security program and for 

providing technical aeaistance to installation management about security 

requirement!!. 

8) The OSM Security Officer is responsible for implementing departmental 

policies related to physical, per~~onnel, and information/document security for 

OSM. This involves conducting periodic reviews of sites to ensure the adequacy of their physical security, safeguarding national security information, 

investigating security incidents, ensuring appropriate sensitivity claseifications for all positions usina- ADP, and initiating appropriate personnel 

background investigations. All plans affecting physical security require the 

approval of the Security Officer. All ADP enfon:ement iBsues will be processed through the Security Officer. 

9) The Recorda Management Officer is responsible for ensuring OSM compliance with regulations iBsued by the National Arclrives and Recorda Administration and GSA governing the creation, maintenance, and diBposal of 

reoords, regardless of their physical form. Tbis responsibility includes 

automated as well as manual records. 

10) The Privacy Act Officer is responsible for developing and implementing 

programs to manage OSM records covered by the Privacy Act (that is, 

records that contain information about individuals and which are retrieved 

by the individual's name or other personal identifier) and for conducting 

periodic inspections of areas where Privacy Act records are maintained. 

11) Supervisors and Manager~~ will ensure that employee performance standards 

contain appropriate refereneee to their Beellrity responsibilities and that 

employees receive security clearances and ADP access certifications appropriate to respective positions. Supervisors and managers will ensure that 

Information Resources Security 11-33 January 1991 
appropriate operational procedures and safeguards are implemented for 

acquiring, accessing, using, maintaining, or disposing of information and 

technological resources under their control, and that lll!curity policies and 

procedures are adhered to for those resources they control. 

12) System Ownsrs are responsible for implementing safeguards to ensure the 

protection and proper use of the information re!IO\li'Cell in their areas. This 

responsibility includes automated applicati01111, manual applications, and 

associated hardware and software re90Ul(:(!B. They are responsible fOl' 

labeling all information and data with appropriate lll!nsitivity labels, must 

ensure that adequate security requirements are incorporated intc internal or 

contract speciticatio1111 before conducting risk analyses, and develop COOPs 

for systems jn their areaa. 

13) Areas designated as information technology facilities (such as computer 

centers and word processing centers) require the appointment of a Resource 

Manager. The Resource Manager is responsible fOl' the overall management 

of an information technology facility. Reeponsibilities include e1111uring that 

adequate security exists at the facility in conformance with departmental 

and system owner requirements. The Resource Manager is responsible for 

conducting a risk analysis and for developing a COOP fOl' the facility. 

14) Each Data Base Adm.iniatratcr is responsible for implementing and controlling access to a data base. 

15) Ulll!rs of information and technological resources are responsible for complying with all security requirements pertaining to the resources they use and 

are accountable for all activity performed under User IDs and passwords 

which have been assigned to them for the uae of automated systems. 

4. Reportina Requirements 

a. Each IIRSO will conduct an annual review of the installation's information 

re50\ln:es lll!curity program to assess its effectiveness and to recertify the adequacy 

of the installed security safeguards. These reviews may utilize existing reports, 

such as risk analyses, application system certifications, Privacy Act inspectio1111, 

reoorda management evaluations, the Departmental Control Evaluation Program, 

and Inspector General audits. The output of this review should lll!rve as the basis 

for ensuring the adequacy of the installation's automated infonnation system 

security. 

b. Each IIRSO will prepare an annual installation security report. This report will be 

incorporated in the BIRSA's annual security plan for transmittal to the DOl 

Information Resolll't:es Security Administrator. The annual reviews described 

above should serve as the basis fOl' this report. 

c. Other requirements as stated herein. 

II. G. 

Infonnation Resources Security JI-M January 1991 
" 

5. Referenctlll 

Department of the Interior Departmental Manual, Part 875 DM 19, IRM Program 

Management-Information Resources Security Program. 

Department of the Interior Departmental Manual, ADP Standards Handbook, 

Part 306 DM 2). 

Office of Management and Budget, Circular No. A-130, Management of Federal 

Information Resourcea. 

General Services Administration, Federal Information ResoumJs Management 

Regulations (FIRMR) on security, privacy, ADP management and acquisition, telecommunications management and acquisition, and records management. 

National Bureau of Standard8 Federal Information Processing Standards Publicatioms 

dealing with security. 

Office of Personnel Management, Federal Personnel Manual. 

National Archives and Records Administration regulatiOIIS 001 records management. 

National Security Decision Dinlctive 145. 

Department of Treasury Directive 81--80, Electronic Funds and Securities Trllllllfer 

Policy-Meee.age Authentication. 

DOl Information ResOUI'<:es Seeurity Handbook (available from Division of Printing 

and Publications, Office of Administrative Services, Department of the Interior, 

Washington, DC 20240). 

Computer Security Act of 1987 (Public Law 100-236). 

Department of Defense Authorization Act of 1982. 

6. Etrect on Othu Documents 

Incorporates ADP-2, Bureau InfOrmation Resources Security Program (8 March 1988) 

7. Effective Date 

Upon issuance 

II.G. 

Information Resources Security Il--315 January 1991 
" 

8. Contact 

MIS DivisiOII Chief or BIRSA 

II. G. 

Information Resources Security II-36 January 1991 
.. II - --- --~ - "__]_ ___ _ 

Chapter III 

AUTOMATED DATA PROCESSING 
" 
AUTOMATED DATA PROCESSING 

A. ADP ACQUISITION 

1. Purpose 

This section contains Office of Surface Mining (OSM) policies and procedures fur the 

acquisition of ADP hardware, software, ADP maintenance services, and ADP support 

services, including word-processing equipment and electronic maiVmessage systems. 

2. Definitions 

a. Terms 

COD.tracting Officer. Individual with the authority to enter into, administer, and/or 

terminate contracts and make related determinations and findings. 

COD.tracting Officer's Technical Repre!lentative. Individual designated by the 

Contracting Officer as the representative authorized to perform specific administrative functions with respect to the COlltrH£t. 

Technical Project Officer. Individual assigned technical responsibility from the 

inception of a requirement through its completion. The same individual may serve 

as both COTR and TPO. 

User. Individual (organization) requesting services through an ADP contract. In 

some instances, the TPO and/or the COTR is the user for a particular requirement. 

b. Abbreviations 

III.A 

A&F 

ADP 

COTR 

DO! 

EFO 

FAR 

IRM 

MIS 

OSM 

TPO 

WFO 

ADP Acquisition 

Accouuting and Finance Assistant Directorate 

Automated Data Processing 

Contracting Officer's Technical Representative 

Department of the Interior 

Eastero Field Operations Assistant Directorate 

Federal Acquisition Regulations 

Information Resources Management 

Management Information Systems Division 

Office of Surlace Mining 

Technical Project Officer 

Western Field Operations Assistant Directorate 

III-1 January 1991 
3. Policy/Procedures 

a. Policy 

III.A 

1) Procurement of ADP Equipment and Services- Authority 

a) Assistant Directors are granted the authority to approve requisitions to 

procure equipment and ADP services as set forth in the OSM Directive 

OPM-1, Delegation of Authority. At present, Assistant Directors may 

approve purchases up to $10,000, except that new microcomputer 

purchases must be approved by the MIS Division Chief (see Figure III-2 on 

page III--6). Equipment must conform with OSM, DOl, and Federal standards. Any procurement exceeding this threshold must be approved hy the 

MIS Division Chie£ Requirements shall not be fragmented into individual 

procurements in order to circumvent acquisition thresholds. ADP requirements should be planned for and identified in the input to the annual IRM 

Strategic Plan and ADP and Telecommunications Acquisition Plan. These 

planned plll'Cha&es also will be within budgetary requirements. Appropriat..l 

documentation that justifies selection and purchase of all ADP resourees 

selected shall be developed and maintained by the originator. 

b) Before acquisition, an evaluation of various alt..lrnatives fur satisfying the 

need should be conducted. This evaluation should include the option of 

employing existing information resources which may be available outside of 

the organization (that is, sharing resoun:es). 

c) Services to be provided by oontraclore, as well as those performed by OSM 

employees, shall oomply with life-cycle development standard$ {see 

sectiOll TII.C, Life-Cycle Management of ADP Information Systems). 

d) Maintenance fur equipment in Headquarters will be provided by the MIS 

Division Chief. Otherwise, maintenance is the responsibility of each 

assistant directorate. Maintenance contracts, when deemed economi.cally 

justifiable, may be made with local vendors. Consideration should be given 

to using blanket purchase agreements or other OSM or DOl maintenance 

agreements, when available. 

2) ADP Contract Administration 

All procedures and activities in the administration of ADP contracts will be 

consistent with the applicable contracts, Federal Acquisition Regulations 

(FAR), 001 Acquisition Regulations {DIAR), and Federal Information Resources Management Regulatione {FIRMR). All ADP contracts are limited to ADP 

support and may not be used for non-ADP activities. The MIS Division Chief is 

responsible for providing management, policy oversight, and direction fur all 

OSM ADP contracts. The Assistant Directors fur EFO, WFO, and A&F are 

responsible for providing administrative and mana.gl!ment oversight for ADP 

ADP Acquisition III-2 January 1991 
III.A 

contracts within their respective assistant directorates, including subordiuate 

offices. 

The following policies apply Wall OSM ADP oontracts: 

a) All support requested through a contract will be within the organization 

and scope of work covered by that coutract. Assistant directorate support is 

restricted to the specific assistant directorate and its subordillate offices. 

The MIS Division Chief will provide contractor support for Headquarters 

offices; these contracts may also be used to provide nationwide support. 

b) ADP support requirements involving or affectiug nationwide OSM programs or functiona will be provided by the MIS Division Chief, =less 

otherwise agreed to by the MIS Divisiou Chief. Support will be implement--

ed iu EFO, WFO, and A&F through the local assistant directorate's con· 

'""''"· 

c) All communicati.ons between contracton will be coordinated through the 

respective COTRa. Contracton may not communicate with each other 

without the coordination of designated OSM staff. 

d) Support requirements involving applicationa developed for a specific 

assistant directorate may be trausported and used within that assistant 

directorate without MIS coordination. Applications will be provided to 

offices outside of the assistant directorate only through the MIS Division 

Chief and through the coordination of the COTRs. 

e) Support for the Solicitor's office and other departmental organizations will 

be provided, where necessary, by the MIS Division Chief. As needed, 

implementation for field office 80licitors may be provided through field 

operations assistant directorate contractors. 

0 Support for State regulatory authority programs with nationwide impact, 

such ae the Technical Information Processing System (TIPS), will be 

provided through EFO and WFO. 

g) ADP contracts will not be used to provide continuing data entry or related 

clerical support. Data entry is limited to support of specific applicationa 

and for a specific period of time. 

3) Core Microcomputer Software 

To facilitate procurement, training, and interoperability, OSM has identified 

categories of BOftware for which ~core~ packages have been selected (see 

Figure III-1). For the software types included in the figure, only core packages 

may be purchased. OSM will provide applications assistance, training, and 

other support to those who use these software packages, which were selected 

after considering OSM·wide and industry-wide lli!age and standards. 

ADP Acquisition III--3 January 1991 

• ' 
" 

Firure m-1 

OSM CORE SOFTWARE FOR MICROCOMPUTERS AND NETWORKS 

Software Type Core Package Venlon 

Operating System PC-DOS 3.3 

MB-DOS 3.3 

Word Processing WordPerfect 5.0 

Data Base Management FoxBase 2.0 

dBase Ill+ 1.1 

Electronic Spreadsheet Lotusl-4-3 2.0112.2 

Telecommunications Crosstalk XVI 3.61A 

Novell Netware 2.15 

III.A 

ADP Acquisition III--4 January 1991 
4) ADP Coordination and Review 

The MIS Division Chief acts as the OSM IRM Coordinator and as such, is 

responsible for all OSM IRM and ADP activities. 

b. Procedures 

III. A 

1) Procurement of ADP Equipment and Servicell 

a) Within Threshold 

Assistant Directors may approve acquisitions of ADP resoun:es without 

prior written approval fl'Ql!l the MIS Division Chief when the costs will not 

exceed the threshold identified in the policy stated above. Appropriate 

documentation that jUBtifies selection and purchase of all IRM resoureee 

selected shall be developed and maintained and shall be submitted to the 

MIS Division Chief. All requests for procurement of microcomputers, 

minicomputers, or mainframe pn:x:essors must be approved by the MIS 

Division Chief. 

b) In Excess of Threshold 

All ADP resource acquisitions expected to exceed the OSM threshold mUBt 

have written approval from the MIS Division Chief before procurement 

documents are isaued. ADP reeouree acquisition requests shall: 

• Be Included in input to the IRM Strategic Plan end ADP and Telecommunications Acquisition Plan. The request shall include the infurmation 

specified in section II.C, IRM Pl!Ullling. 

• Be approved by the MIS Division Chief. 

All ADP resource acquisitions expected to ~d DOl thresholds (see 

Figure III-2) will be handled in accordance with procedures set forth in the 

DOl Departmental Manual, Part 376 DM 4. The MIS Division Chief is 

responsible for obtaining DOl approval. 

2) ADP Contract Administration 

Assistant Directors may contract for ADP service above the authorized threshold only with the approval of the MIS Division Chief. 

All ADP contracts will fullow the technical and administrative procedures 

stated in respective statements of work. 

Each ADP contract must include the fullowing contract administration elements. AdditionalllBBistant directorate-specific administrative requirements 

should be included when necessary. 

ADP Acquisition lll-> January 1991 
Firure m-2 

DOIJOSM ADP ACQUISITION THRESHOLD SUMMARY 

OSM AD Threshold 

Departmental Thresholda 

Full and Open Competition 

ADP Hardware- Purchase 

ADP Hardware - Lease 

(including maint.enance costs) 

Proprietary Software 

Maintenance Service 

ADP Contract Service 

Other Than Full and Open Competition 

ADP Hardware- Purchase 

ADP Hardware- Lease 

(including maintenance oostB) 

Proprietary Software 

MaintellllllCE! Service 

ADP Contract Service 

S(a) Firm 

ADP Hardware/Software 

ADP Contractor Service 

ADP Software/Contractor Service11 from 

Other Government Souroe 

Hardware Thl'ough Reutillzation Process 

CPU Cost 

Lease (including mainUlllllllCE! C09tB) 

III.A 

ADP Acquisition 

$10,000 per total procurement 

$1,000,000 total value 

$25,000/month 

$800,000 total value 

$1,000,000/annum 

$500,000/annum 

$100,000 total value 

$3,000/month 

$100,000 total value 

$100,000/annum 

$100,000/annum 

$100,000/total value 

$500,000/annum 

$500,0001annum 

$50,000 total value 

$3,000/month 

January 1991 

' 
III. A 

" 

a) Monitoring Contract Perful'Inllil(:e. The contractor's technical performance 

is monitored through a technico.l progress Ol' status report submitted at 

intervals designated by the specific contract. The Contracting Officer, 

COTR, and TPO (as applicable) review and evaluate contractor progress 

during a specific period of performance. This may alao include briefings or 

other reporting as included in specific oontracts. 

b) Inspection and Acceptance. Inspection is the examination and testing of 

services to determine whether they conform to contract requirements. 

Acceptance is the action of an authorized representative of OSM by which 

the Government approves specific delive:rables or services rendered as 

partial or complete performance of the contractor. The CCYI'R and TPO 

must inspect and then accept or reject all deliverable& submitted by 

contractors. 

c) Invoice Review and Approval. The contractor will submit invoices as 

required by the specific contract. The COTR is responsible for reviewing 

and coordinating invoice reviews with TPOs (as applicable) to ensure that 

all costs the Government pays are appropriate, reascmable for the work 

performed and comply with contract requirements and schedules. 

d) Government Property Held by Contractor. If it becomes necessary to 

provide the contractor with Government property (software, hardware, or 

other materials), the COTR, in coordination with the Contracting Officer, 

must ensure that all COil tractor-held Government property is properly 

documented and meets all property management requirements. Before 

providing Government-furnished equipment or property to a contractor, 

specific FAR clauroe8 must be added to the contract and the OOiltractor has 

very specific guidelines that he must follow to properly follow to properly 

maintain end inventory such property. 

e) Contractor Purchlll!ll. If it is necessary for the OOiltractor to purchase 

equipment or other goods, the purchased item{s) becomes the properly of 

the Government. The COTR, in coordination with the Contracting Officer, 

is responsible for ensuring that all OOiltractual requirements are met and 

followed. 

3) Core Software 

The following procedures should be followed when purchasing miCI'OComputer 

or network software. 

a) Obtaining a Copy of Con! Software 

Request a copy of the softW!Il'll from the MIS Software Inventory Coordinator. H the software is not available from inventory or other 0SM or 001 

sources, the MIS Software Inventory Coordinator will recommend the m011t 

effective and efficient way to satisfy the requestor's requirements. 

ADP Acquisition III-7 January 1991 
" 

Acl.i.vities may not use other software as a substitute for core software. 

b) Obtaining a Copy of Other Software 

Software for which no core software is designated should be plll'clw.sed 

through the requesting oflke's Procurement Ageut or Contracting Officer. 

The requeatol' will prepare a requisition in ao:otdance with established 

OSM procurement procedures and authorities. In addition, if the non-core 

software has a purchase price of $250 or greater, approval of the MIS 

Division Chief must be obtained prior to purchase. 

c) Obtaining an Update to Core Software 

Newly released versions of core software must not be purchased for routine 

use until the MIS Division Chief has approved an OSM-wide upgrade. 

However, such packages may be purchased for special projects or sna)yrris 

upon approval of the MIS Division Chief. 

d) Requesting Changes to the OSM Core Software 

Requests for changes to, additioll8 to, or deletioll8 from the OSM core 

software list should be sent to the MIS Division Chief. The requesting 

letter should include an explanation of the requested change and the 

reaaons a change/addition is needed. 

c. Responsibilities 

III.A 

1) The MIS Division Chief is responsible for: 

a) EnBuring that m!ijor systelll8 comply with life-cycle development standards 

and economic analysis standards. 

b) Developing a Five-Year ADP and Telecommunications Acquisitioo Plan and 

ensuring that acquisition requests eonfurm with the plan. 

e) Elllluring that OSM systems are rnanagsd in accordance with the authorities cited in the references listed below. 

d) Conducting periodic reviews to ensure the efficiency, eiTectiveness, and 

proper implementation of contract management controls. 

e) Coordinating OSM ADP contracting policy and procedures with the Branch 

of Contracting. 

0 Administering and overseeing all ADP delegatioll8 of authority from DOI to 

OSM. 

ADP Acquisition III-8 January 1991 
III. A 

" 

g) Providing liaison with and accountability to the DOI Office of Information 

Resource~~ Management for ADP procurement activities. 

h) Oversight of all ADP contracts supporting information reeoliiWII. 

i) Delegating administrative authority to Assiatant Directors for ADP contracts supporting the Information resourcee of the particular assistant 

~toroW. ' 

j) Conducting reviews of assistant directorate ADP contractor efforts to 

evaluate compliance with DOI and OSM ADP policies and procedures. 

k.) Approving all requests for contractor support. 

1) Providing ADP contractor support for the Office of the Solicitor and other 

departmental organizations. 

m) Providing ADP contractor support to OSM field offices and State regulatory 

authority programs where there is nationwide impact. 

n) Providing lead coordination for efforts requiring MIS and/or assistant 

directorate contracton to work with each other. 

2) For the ADP contracta for which they are accountable, Assistant Directors are 

responsible fur; 

a) Ensuring that any system development project is approved by the MIS 

Division Chief. 

b) Ensuring that projects confonn to OBM standards and follow the OSM and 

DOl life-cycle development requirements, and maintaining and forwarding 

to the MIS Division Chief for review and approval all required life-cycle 

documentation, especially documentation relating to ADP acquisition and 

project approval decisions. 

c) Conducting sitalsecurity readine88 revieWB before system installation. 

d) Administering ADP delegations of authority from the MIS Division Chief. 

e) Ensuring compliance with all OSM, DOl, and Federal policies and procedures, including enauring that the systems are managed in compliance 

with authorities listed in the references below. 

f) Establishing and administering supplemental 888istant directorate contracting policy and procedures. 

g) Administering and overseeing approved assistant directorate contracts 

supporting information resources. 

ADP Acquisition January 1991 
III.A 

h) Ensuring that all ADP contract support represents the best interests of the 

Government. 

i) Approving all requests for contractor support within the respective assis· 

tant directorate. 

j) Implementing support of nationwide efforts through assistant directorate 

contracts as requested by the MIS Division Chief. 

k) Ensuring that assistant directorate coordination ill provided for efforts 

involving contracton1 in other assistant directorates. 

1) Approving all requests for the expe~~diture of assistant directorate ADP 

contract funds. 

3) The Contracting Officer, and only the Contracting Officer, ill authorized to: 

a) Award, agree to, or execute any contract, contract modification, or notice of 

intent. 

b) Execute or agree to any changes in the specifications, delivery schedule, or 

other terms and conditions of the contract. 

c) Order work inside or outside the !!COpe of the contract. 

4) The COTR ill responsible for: 

a) Ensuring that all users and TP0s adhere to the contractual requirements 

for requesting support from the contractor. 

b) Assisting the contractor in interpreting technical requirements of the 

contract's scope of work. 

c) Coordinating written technical directions, specifications, and pl'Ocedures 

relating to contractual work requirements with the contractor. 

d) Issuing technical direction in a.ewrdance with the contract's technical 

direction contract clause. 

e) Coordinating with the MIS COTR and other assistant directorate CO'I'Rs, 

as needed. 

f) Reviewing and commenting on the contractor's request for Governmentfurnished facilities, supplies, materials, and equipment and fOrwarding the 

request to the Contraeting Ofli.cer fur disposition. 

ADP Acquisition III-10 January 1991 
III.A 

" 

g) Reviewjng and commenting on the coo. tractor's request for cOilllent to 

purehase supplies, materials, and equipment and forwanling the request to 

the Contracting Officer for disposition. 

h) Maintaining a complete and open line of communication with the Contracting Of'Eicer regarding the contractor's technical performance and progress 

and, when requested, providill.g written usessment of the contractor's 

perfonn ance for inclusion in the contractor performance :llle. 

i) ED.Buring that Govenuuent inspection and acceptance for all deliverable 

items under the contract is accomplished. 

j) Reviewing payment vouchers and concurring with respect to the percent of 

technical completi011 for items or services delivered and accepted under the 

contract. 

k) Upon ~piration of the contract, providing a written &tatement attesting to 

the contractor's completion of technical perfurmance under the contract and 

of the delivery and acceptance of all goods and servi0011 for which inspection 

and acceptance are designated. 

5) The TP0 ill respolllli.ble for: 

a) Providing the contractor with written t.eclmical requirements in coordination with the rontracting officer and user. 

b) ED.IIuring that written requkements are submitted to the COTR (where 

applicable) for issuanee to the contractor. 

c) Scheduling and organizing meetings with the user and contractor to 

initiate work. 

d) ED.IIuring that copies of written requests are submitted to the COTR (as 

applicable) and included in COTR files. 

e) Reviewing and recommending COTR approval/disapproval (aB applicable) of 

contractor proposals, management plans, and resumes. 

0 Identifying and resolving all technical discrepancies and iuues. 

g) Ensuring that all dates and deadlines are monitored effectively. 

h) Communicating effectively with the user aod the contractor. 

i) Anticipating and resolving problems as expeditiously as possible. 

j) Reviewing, evaluating, and recommending acceptance of deliverables. 

ADP Acquisition III-11 January 1991 
k) Ensuring that all documents requiring the U&lr'B review and signattll'l! are 

forwarded to the user. 

1) Documenting all user and technical comment!! 011 contractor performance, 

deliverables, and the status of work. 

m) Communicating with and keeping the COTR informed (as applicable) of 

contractol" performance, the status of deliverable&, and other matters 

involving the terms and conditions ofnt~~pective contracts. 

6) The user is responsible for: 

a) Identifying and submitting needs and requirements to the TPO or COTR. 

b) Working with the TP0 or COTR to develop written requirements. 

c) Reviewing and evaluating deliverablea and providing comments to the TP0 

or COTR and recommending acceptance or nonacceptance of deliverables. 

d) Monitoring management plan dates and deadlines with the TPO or COTR. 

e) Communicating with the TPO or COTR on wntractor performance. 

fJ Elllluring that documents requiring the user's Bignattll'l! are signed promptly and forwarded to the TP0 or COTR. 

7) The MIS Software Inventory Coordinatol" ia reBpollllible for: 

a) Maintaining the OSM wre software llilt. 

b) Coordinating acquisition of core software throughout OSM. 

c) Keeping abreast of high,Ievel OSM requirements and technological changes 

to ensure that the core software continues to support OSM needa. 

4. Reporting Requirements 

Ail required by the references below and other chapters of this OSM mM Policy and 

Procedures Manual. 

5. References 

OSM Directive OPM-1, Delegatiollll of Authority 

Department of the Interior Departmental Manual, Part 376 DM 4, Information 

Resoura!s Management-ADP Acquisition. 

III.A 

ADP Acquisition III-12 January 1991 
" 

Office of Management and Budget, OMB Cireular A-130, Management of Federal 

Information Resources, 24 Dec 1986. 

Paperwork Reduction Act (44 USC 3506(c)(B)). 

Federal InfOrmation ResOWWII Management Regulationa (FIRMR), including: 

FIRMR 201--33.003 {Reuse of ADPE) 

FIRMR 201-31 (Sharing ADP resourees) 

FIRMR 201--32.104 (Computer security) 

FIRMR 201-23.103 (Thxesholds) 

FIRMR 201--6 (Required contractual clauses for contracted operatioll8) 

FIRMR 201-.'30.007 (Requirements analysis) 

FIRMR 201--30.009 {Analysis of alternatives) 

FIRMR 201-30.007(d)(9) and 201-34.002 

(Performance evaluation for CUl'I'ent ADP system) 

FIRMR 201-30.009-3 

(Findings to support the use of compatibility-limited requirements) 

FIRMR 201-30.012-1 (Softwarl! conversion study) 

FIRMR 201-1Ul02(b) (Certified data to support sole source) 

FIRMR 201-11.002-1 (Certified data to support sole make/model) 

FIRMR 201-30.012 (Planned actions to foeter competition) 

Federal Acquisition Regulations (FAR), including: 

FAR2.1 

FAR 24.104 (Required contractual clauses for contraCWd operations) 

Federal Information Processing Standards (FIPS). 

Interior Property Management Regulations (!PMR). 

Department of the Interior Acquisition Regulations (DIAR), including; 

DIAR 1424.104 (Required contractual clau8611 for contracted opemtions). 

Privacy Act of 1974, as amended (5 USC 522a). 

6. Effect on Other Documents 

Supersedes OSM Directive ADP-4 

7. Eff'ective Date 

Upon issuance 

III.A 

ADP Acquisition III-13 January 1991 
" 

8. Contact 

MIS Division Chief 

III.A 

ADP Acquisition January 1991 

" 
B. ADP COST ACCOUNTING, COST RECOVERY, AND SHARING 

1. Purpose 

This section establishes Office of Surface Mining (OSM) policies and procedurea for 

sharing ADP equipment. As OSM does not provide reimbursable ADP services to 

external organizations, no policies have been established fur the cost accounting and 

cost recovery required when dealing with chargeback systems. 

2, DefinitiOD.ll 

a. Tenns 

No~ 

b. Abbreviations 

ADP Automated Data Processing 

MIS Management lnfonnation Systems Division 

OSM Office of Surface Mining 

3. PoHcy/Proeedures 

a. Policy 

OSM will share information technology facilities with users from other agencies to 

the maximum extent feaaible. 

In selecting information technology facilities to support new applicatiOllll, OSM 

will ensure that: 

o In the interest of efficiency and economy, alternative facilitiea are considered, 

including other Federal agencies IIIld non-Federal facilities IIIld services. 

• Policy does not require that priority be given to the use of in-house facilities. 

o Selection decisions are documented in official records. 

b. Procedures 

III.B 

When evaluating information resource requirements fur new applications (or 

modifications to existing systems), cOllllider the cost and availability of facilities 

and services of other Federal agencies and non-Federal organizations. 

ADP Resource Sharing III-15 January 1991 
" 

c. Responsibilities 

1) The MIS DivisiQll Chief is responsible for promoting OSM-wide ADP resource 

sharing and for ensuring that alternative sharing of ADP resources is evaluated 

before new procun!mente are made. 

2) Assistant Directors are responsible for promoting ADP resource sharing within 

the assistant directorate and for ensuring that alternative sharing of ADP 

resources is evaluated before new procurements are made. 

4. Reporting Requirements 

None 

5. References 

Department of the Interior Departmental Manual, Part 376 DM 6, ADP-ADP Cost 

Accounting, Cost Recovery, and Sharing. 

Office of Management and Budget, OMB Circular A-130, Mllllagement of Federal 

Information Resources, Z4 Dec 1985. 

6. Effect on Other Documents 

None 

7. Effective Date 

Upon issuance 

8. Contact 

MIS Division Chief 

III.B 

ADP Resource Sharing III-16 January 1991 
" 

C. LIFE-CYCLE MANAGEMENT OF ADP INFORMATION SYSTEMS 

l.Pmpooe 

This section provides Office of Surface Mining (OSM) policy and procedural &'Uidance 

to ensure that system development and implementation is efficient and effective. It 

does not dictate a specific development methodology to be used. III!Itead, it ooncentrates on documentation requirements over the life cycle to: 

• Ensure that all OSM ADP syateiiiB and applications are consistently documented 

in clear, high-quality documents throughout their life cycles. 

• Ensure that the proper level of documentation is developed for a proposed ADP 

system or application. 

Appendix A clearly states f=at and content for the IIlOIIt common documents 

required during th.e life cycle of 11 proposed or operating ADP system or application 

used or planned for use within OSM. 

2. Definitions 

a. Terms 

Life-Cycle Management (LCM). A management approach that provides a structured process for plruming and controlling an infbrmation resource from inception 

to replacement or termination. LCM provideB a common framework that facilitates 

coutrol of the proce811, specifies the contents of deliverables, improves communications among diverse interest groups, and manages the development aD.d acquisition of information reso=s. The effort and level of detail of the activities 

conducted by using the LCM management approach are to be commensurate with 

the size, complexity, and importance of the resource. 

Documentation.' All infonnaticm that describe& the development, operation, use, 

and maintenance of computer software. This information is in a form that can be 

reproduced, distributed, updated, and referred to when it is needed. 

b. Abbreviations 

ADP Automated Data Processing 

DOl Department of the Interior 

IRM Information ReSO\ll"«ls Management 

MIS Management Information Systems Division 

OSM Office of Surface Mining 

TPO Technical Project Officer 

1 Source: Federal Information Processing Standards, Publication 10!5, 6 June 1984. 

III.C 

Life-Cycle Management III-17 January 1991 
8. Pollcy/Prooodure 

a. Policy 

me 

In general, software documentation fulfills the following important functions 

throughout the life cycle of a system or application: 

• Assistance in defining mission needs and requirement!~. 

• Communication to keep management apprised ofrequirementa, progreaa, 

problems, and expectations while the system or application is under development. 

• Communication to keep those who are performing varioUll development, operation, and maintenance tasks aware of what other groups are doing or have done 

while the system or application is under development. 

• Instruction and reference for those using the system or application. 

o Information for maintenance, quality asslll'liilCe, and auditing per60Illl61. 

o Historical reference for future development efforts and to assist in transferring 

the system or application to new environment!~. 

A system's life cycle COilll:ista of well-defined activities that begin when a need is 

identified and continue until the resulting system or application is no longer of 

use. Figure 111-3 shows the three phases and nine stages of this life cycle as 

defined by DOl. The three phases of the application system life cycle are initiation, 

development, and operation and maintenance. These phases are divided into eight 

stages, and the documentation required over the life cycle falls into those stages. 

Initiation Phase. The documentation preptU'Sd during the initiation phase organizes andjlUitifies the subsequent development effort. Mission analysis stage documentation concentrates on the general need for a system and preliminary organizational activities. Concept development stage documentation: 

o Identifies alternatives and the costs and benefits of those alternatives. 

o Delineates responsibilities for the production team. 

0 Defines schedules and milestones for the development project. 

0 Records the history of the development effort so that the rationale for the 

system's structure is availabla for later use. 

Development Phase. Documentation prepared during the system analysis and 

system design stages of the development phase records details of discussions about 

system requirements. 

Life-Cycle Management III-18 January 1991 
" 

Figure ill-3 

DEPATMENT OF THE INTERIOR SYSTEM LIFE CYCLE 

III.C 

Life-Cycle Management 

Project 

Request 

III-19 January 1991 
III.C 

Documentation prepared during the SYBtem construction and acquisition and \ll!el' 

aoceptance stagea of the development phase describes the results of the analysis 

and design effort. It provides the information needed for effective system design 

and testing as well as the use, operation, mainterumce, and conversion and/or 

transfer of the resulting system or application. If the product is to be used by 

people other than the developera, this documentation will prevent any number of 

problems that may cause the product W fail. For example: 

o System developers and programmers use information that describes what a 

SYBtem or application is supposed to do, when it should do it, and how it should 

be tested. 

o System administrators, operators, and maintenance programmers use information that tells how to operate, support, and maintain the system or application. 

o Usei'II employ training and reference materia.ls that enable them to quickly 

learn how to use the SYBtem or application and find answers to specific questions. 

• Management uses information in the documentation to inform other managers 

and potential system users about the system's existence and capabilities. 

All ADP development projects, whether the development of a new BYBtem or the 

modernization or modification of an existing system, involve all phases of the life 

cycle: initiation, development, and operation and maintenance. The deve!Dpment or 

enhancement process will follow a systematic, structured approach that will be 

documented as set forth herein. The specific development methodology used may 

vary from project to project. When cost effective, state-of-the-art development 

approaches such as prowtyping, computer-assisted softwllrf! engineering (CASE), 

and reverse engineering (prototyped BYBI:emB) for mandatory documentation should 

be used; however, the limdamental coosideratirms will not change. These COllsiderations are established in the procedures described below. 

The degree of documentatirm required is determined by comparing the scope of the 

ADP development project to the five levels of documentation as described in the 

procedures below. This decision should be made in the early planning stages and 

should be reported in field office and assistant directorate input to the IRM 

Strategic Plan. 

To reiterate, all ADP development effurts involve all stages of the system life cycle, 

even if formal documentatioo is110t required. For example, even a system developed by one individual for his or her own UBe will involve the following system lifecycle activities: 

o Determining a need, conceptualizing the system, and determining ifbenefita 

outweigh the costs of development (project initiatioo). 

o Analyzing specific functional and data requirements (system analysis). 

Life-Cycle Management III-20 January 1991 
" 

• Designing the software Wid data base {system design). 

• Coding the prorrams, establishing the data base structure, converting or keying 

the data, testing the system, and determining acceptanee (systenl construction 

and acquisition, user acceptance). 

• Using lllld maintaining the system {operation and maintenance). 

Adhering to a structured approach of development and maintenance reduces the 

potential for overlooked requirements and inefficient or ineffective designs. The 

larger and more complex the system, the more expensive changes become in the 

later stages of the life cycle. For this reason, more stringent documentatiOil 

requirements are established and must be followed for these systems. 

b. Procedure 

As the scope of projecta varies, so do the requirements for documentation. The 

following paragraphs define five levels of documentation and provide guidance on 

how to choose the appropriate level for Elil ADP development effort. 

Level 0 

Levell 

LBvel2 

Level3 

Level4 

No documentation i.e required for microcomputer programs developed 

by an OSM staff member for individual use. However, if the programs are found to be useful to other individuals within the office---

or would be used by a succesBO:r in the position-Level 1 documentatinn i.s required at a minimum, 

Required for systeiD8 used within a single office {that ia, one Headquarters division or one field office division). 

Required for systems used throughout one OSM location (that is, in 

all Headquarters divisions or in all divisions of a field office). 

Required for systems Ulled by more than one OSM organi:Qttional 

level or more than one field office (for example, systems that communicate information from a field office to a Headquarl:en! office or 

among field offices). 

The maximum level of documentation will be prepared for major, 

service-wide systems that require oversight by the DOl Office of 

Information Resources Management. 

c. Responsibilities 

me 

1) The MIS Division Chief is responsible for: 

a) Maintaining up-to-date documentation standards and policies and communicating those standards and policies to the responsible organizational units. 

Life-Cycle Management III-21 January 1991 
b) Ensuring that MIS TPOs follow the appropriate policy Bild proeedUl'ee in 

developing pla.ns for application life-cycle docUlllelltation requ:il"ements. 

2) Assistant Direct:.ors are responsible for: 

a) Maintaining up-to-date documentation standardB in their files. 

b) Ensuring that TPOs on their staffs follow the policies and procedures with 

regard to preparing documentation plans for application systems developed 

by their offices. 

3) TPOs are responsible for: 

a) Managing projects in accordance with DOl and OSM guidance to ensUl'e 

efficient development and implementation of an effective system. 

b) Preparing project management plans for ADP development and maintenance 

pi'Qjecta. Documentation plans, which will indicate the level of and schedule 

for planned documentation, will be included therein. These plans will be 

included in each system proposal. 

4) Documentation Specialists (contractors and OSM) are responsible for following 

the detailed requirements for content and format found either in Appendix A to 

this directive or in the DOl Project Manager's Guide to Application Systems 

Life-Cycle Management (see references), as determined by the level of documentation required. 

4. Reportiq Requirement11 

At the onset of any ADP development effort, OSM project officel-s are responsible for 

using this guide to prepare a list of required documentation. All phases of the system 

life cycle (initiation, development, and operation a.nd maintenance) should be considered when preparing this list. The decision as to the documentation required should 

be made early in system planning efforts and should be reported in field office a.nd 

assistant directorate input to the IRM Strategic Plan. 

Figure III--4 is a matri:J: that shows documentation requirements for all phases and 

stages of the four levels of required documentation as defined in the policy above. 

Figures III-5 through TII-8 provide detailed listings for each documentation level and 

each life-cycle phase and stage. Content summaries and annotated outlines for 

documentation required in phases 1 through 3 can be found in Appencfu: A to this 

directive. Details on phase 4 documentation can be found in the DOl Project Manager's Guide to Application Systems Life-Cycle Management (see references). 

The I't!quiremente discussed in this section should senre as a general guide to determining the eJ<tent of documentation required, and they are intended to be flexible. 

Developers may feel that more documentation is required, less documentation is 

III.C 

Life-Cycle Management January 1991 
" 

required, or that llOllle documents can be OOlJibi.ned. Factors such as the size of the 

application system, the development methodology used, the projected number of use:rs, 

and the size of the development team will influence the documentation desired. For 

example, while all systems require analysis aD.d design before they are implemented, 

the level of detail and formality of development documentation will vary according to 

factors such as those listed above. 

While the policy for documentation to be prepared is flexible, the detailed requirements for content and format found in Appendix A and in the 001 Project Manager's 

Guide to Life-Cycle Management must be followed where they apply. 

Copies of documentation for systems which may have applicability throughout OSM 

should be forwarded to the MIS Division Chieffor review and consideration for further 

promulgation. Requirements and final products should alao be discussed at the semiannual IRM Coordinator meetings. 

III.C 

Life-Cycle Management III-23 January 1991 

I 
" 

Figunill-4 

COMPABIBON OF MINIMUM DOCUMENTATION REQUIREMEN'llJ 

U•Cy$ Phue,i81q'I'Do<:um•nt I ..... , I ..... , I Level 2 I Uwl1 

' INITIATION PHASE 

... MINion Anlllyele Stage 

1.1.1 Pl'l)j!Kll Req<.IOII """'"' 1.1.2 Mlsaio!l ~~~~ Mlllhodology 

1.1.3 """'"' 

1.1.4 

--

Prcjecl Charter """'"" 

1.1.!1 """'"' -- _,,., 

1.1.6 Mlasian Proc -Model ""'""' 1.1.7 lnformallan Model _.,., 

1.1.8 Ma.lon Need Sllllement 

u COMept Drlelopment Stage """'"" 

1.2.1 System Objectives Optional 

1.2.2 Appllcalloo Syetan Archllec1ure Optional 

1,2.3 Data Arch~9Ciure Optional 

1.2.4 Dllla Cammunlcallcrvl Ardlllec:ture Optional 

1.2.5 Feaslbllly Study ""'""" Required 

1.2.6 ~ l..Jie..Cytl9 Strategy 

m Syttem l..Jie..Cycle 0211111 ""'""" 

1.2.8 Syst.m l..Jie.Cym. Raoourwe Eltlmate ""'""' 

1.2.9 Prcjecl Mansgament Pl.., ""'""" Required Required 

1.2.10 Quaily Aa.ufanc• Plan """"' Required' 

1 .2.11 .,..,__,.. ""'""' Required """"" 1.2.12 Rsvloed Mlsak>n Neltd Statemen! """"" 1.2.13 System Oacl81on Peper 1 

1 """'"" 

1ncorpcrated In Prcjact Uariagement Plan. 

m.c 

Life-Cycle Management III-24 January 1991 
" 

Fipre ID-4 (Continued) 

COMPARISON OF MINIMUM DOCUMENTATION REQUIREMENTS 

Llfa.Cyc'- PhloMI9taglliDaaJ!Mfll I t..v.l4 1 

' DEVELOPMENT PHASE 

" Sy.Um Analyal8 Slag• 

2.1.1 Currant System Descrlpllon Oj>llonal 

2.1.2 Detaillld Functional Raquiramanlll Optional 

2.1.3 Dma Requirements Raqulred 

.., Syatam o .. ~;n Sraga 

2.2.1 Daolgn Proposal Required 

2.2.2 Datailed Ccst!EI811&1it Analysis Required 

2.2.3 Revis&<! Life-Cycle Strat<Ogy Required 

2.2.4 Syotem Daci!lion Paper 2 Roqulred 

,_, SpNm eo..-ructlon and Acqul8111on Slllga 

2.3.1 Test PIMa: 

2.3.1.1 Un~T&S!Pian 

2.3.1.2 lnteoralion Test Plan 

2.3.1.3 System T&St Plan 

2.3.1.4 Accaptanca T95t Plan 

2.3.2 ADPE Spadflcatlons 

2.3.3 A~licatlon Software Oowmenlatlon: 

2.3.3.1 System/Subsystem Specnica!lon 

2.3.3.2 Data Base Spedficallon 

2.3.3.3 Detailed Prcoeoo Design 

2.3.3.4 Program Spec~ication 

2.3.3.5 Toost Data Design 

2.3.3.6 Data Dictionary 

2.3.4 Control, Backup, and Security Study 

2.3.5 Contingency Plan 

'locorporalad In O.tailed Functional Requlraments. 

'locorporalad in Systam!SubsySivm Specification. 

Required 

Qj)tjonal 

Optlonal 

Op1ional 

Optional 

Optional 

Optional 

Optional 

Raquirad 

Loovel3 I t..v.l 2 1 t..vel1 

Required' Raqulrod' Opllonal' 

Required Required Oplil><1al 

Raqulf'Qd Required Optional 

Required 

Required 

Required 

Required 

Required' 

Required 

Required Roquirod Optional 

Requlr&d 

R&quirod Required Optional 

Required' Required' R&quired' 

Required R&quired 

'locorporatad in u ... rs Manual, Opara!ions Manual, and Oala Baoe Adminls!ration Proc:adul"9s Manual. 

III.C 

Life-Cycle Management III-25 January 1991 
" 

Figure DI-4 (Continued) 

COMPARISON OF MINIMUM DOCUMENTATION REQUIREMENTS 

llfe.OycJ. -~- I t..v.t 4 I ....,, I t..ver 2 I ~.ewor1 

" u- "-ptanct Stag• 

2.4.1 Current System D&scription Requ~ed 

2.4.2 Mlsoion Anattaia Mo>!hodalo;y Roqu~ed Raqutrad' 

2.4.3 Cost/Bene!~ Analysis Optional R&qulred 

2.4.4 lhlar Training Plan Optional Requlrlld Required 

2.4.5 Post-lmplamentalicn Revi- Plan Required 

2.4.6 Program Maintenance ManuaJ Required Required Required Optional 

2.4.7 Data Proc:asolng MMual Optional 

2.4.9 Use~s Manual Optional Required Raquired Required 

2.4.9 Operations Manual OpUonal Required Raqulr&d Required 

2.4.10 Data Baoa Administration 

Prooedurea Manual Required Raqu~ad Required 

2.4. 11 System Decision Paper 3 Required 

, OPERAT10N AND MAINTENANCE PHASE 

... lmple...,tl.tlon Slll!!e 

3., .1 A~licaticn sr-ardshlp Document Raqutr&d 

,_, Malnuon•nce Slllg• 

3.2.1 Post·lmpH>mantation Review Report Requ~ed 

3.2.2 System [}ecjsion Paper 4 Roqu~ed 

'lnccrpor~ In Conversion PW>. 

me 

Life-Cycle Management III-26 January 1991 
" 

Firure ID--5 

SUMMARY OF MINIMUM DOCUMENTATION REQUIREMENTS 

AND REFERENCE NUMBERS FOR OSM LEVEL 1 

Mi•sion Analysis Stage 

Concept :O.W..lopment Stage 

System Analym Stage 

8Jllltem D..sign Stage 

System Construction and 

User Acceptance Stage 

INITIATION PHASE 

None RequiNd 

None Required 

DEVELOPMENT PHASE 

Current System Deec:ripli.on' ......... , , • , , , . , ........ , 2.1.1 

Detailed Functional Requin>ti\Mitll0 •••••••••• , , , • , •• , • • • 2.1.2 

Data Requirements* ... , , , , , •.............•. , , , , . . . . 2.1.3 

None Requiud 

De.ta B""" Specification• ..•.••.•..................•.• 

Data Dictionary* .........• , •.•..•..........•.. , , , •. 

Control, Bacl<up, &nd Security Plan' ............... , , , •. 

Program Maintenance Manual• .....•..•.............•. 

Uoor's Manual ..•..•..•. , , , ••••.•..•....•. , • , , , • , •. 

Operations Manual .• , , , • , •.•.•..•..• , , , , , , , •.•..•.. 

Data B"" Admlniotration l'rocodureo Manual .... , , , , , , , .. 

2.3.3.2 

2.3.3.8 

2.8.4 

2.~.8 

2.4.11 

2.4.9 

2.UO 

OPERATION AND MAINTENANCE PHASE 

Implementation Staga 

•Optional 

None Raquli'I!d 

None Required 

1

!TICCil]>Orated in Detailed Flmotional Requirements. 

'Incorporated in Uoer'o Manual, Openotiono Manual, and Data Base Adtniniotration Procedure• Manual. 

III.C 

Life-Cycle Management January 1991 
F'i¥ure m~ 

SUMMARY OF MINIMUM DOCUMENTATION REQUIREMENTS 

AND REFERENCE NUMBERS FOR OSM LEVEL 2 

Mission Analysio Stage 

Cun""Pt Dovelopment Stage 

INITIATION PHASE 

None RequiNd 

F988ibility Study ....................•..•.•......... 

Project M.onagemant Plan ....•..•..•.•.............•. 

Quality Alllurance Plan' ...•.•..•....•..•..........•. 

Coot/Benefit Analysio •..•..•.•....•.................. 

DEVELOPMENT PHASE 

1.2.5 

1.2.9 

1.2.10 

1.2.11 

Syotem Analyoio Stege Current System Deooription' . . . . . . . . . . . . • • . • • . • . . . . . . . 2.1.1 

System Del!ign Stage 

Syotem Conotnlotion and 

Detail&<! Functional Requlrmmmt.o . • . • • . • . . . . • . . . . . . . . . . 2.1.2 

Dota Requirelllllntll . . . . . . . . . . . . . . • . . • . . • . . . . . . . . . . . . 2.1.3 

None Required 

De.ta Base Spedfioa!l.on .....•.•..•..................• 

Data Dictionary ......•......•................•.••.• 

Control, Backup, and Security Plan' .....•..•....•...... 

Contingooncy Plan ..•....•............•..•.•..•...... 

u ... Traini!ljl Plan ..•...............•..•....•...... 

Program Maintenance Manual .•..•..•..••••••.•..•..•. 

u..r. Monuo.l •...............•••••••.•..........•. 

Operation• Manual .•..•..•.•.••.•••••.•..•.•..•..•. 

Dota a ..... Adminiotration Procedure• Manual ..•.........• 

2.3.8.2 

211.3.6 

2.3.4 

2.8.5 

MA 

2.4.6 

2.4.8 

2.4..9 

2.4.10 

OPERATION AND MAINTENANCE PHASE 

lmplemente.tion Stage 

Maintenance Slap 

'I"""'l"""G.ted in Proj .. t Mllll8gement Plan. 

'Incorporated in DeWl&d :Functional Requirements. 

'l"""'l"""G.ted in Uoe<'o Manuo.l, Opera.lionB Manual, and Data Base Administration Procedures Manual. 

III.C 

Life-Cycle Management III-28 January 1991 
Fipre lli-7 

SUMMARY OF MINIMUM DOCUMENTATION REQUIREMENTS 

AND REFERENCE NVMBERS FOR OSM LEVEL 3 

Concept Developmont Stage 

System. Anolysia Stage 

System. Conotnretion and 

Aequillition Stage 

INITIATION PHASE 

None Required 

FoBBibility Study ••.•..•..•.•.•..•..•..•.•..•..•..•. 

~M-tPlan ........................... . Quality Asou....,.., Plan ......................•....•.. 

CoetiB<!nBIIt Analy&io ..•..•..•......•..•..•....••.•.. 

DEVELOPMENT PHASE 

1.2.5 

1.2.9 

1.2.10 

1.2.11 

Currmt Syatom Ileooription' • . • • . • . . • . . . . • . . • . . • . . • . . . 2.1.1 

Detailod Functional Roquiremento • • • . • • . • . . • . • . . • . . • . . • 2.1.2 

Data Requin!IPents . . • . . • . . • . . . . • . . . . . . . . . . . . . . . . . . . 2.1.3 

None RequiTBd 

Unit Test Plan ....................................• 

Integration Teot Plan ...................•..•.•..•..•. 

System. T""t Plan .................................. . 

Ao:o"Ptanca Teot Plan •..•..•..•.•.•..•..•............ 

ADPE Speclflcatlon' .....................•....•..•... 

Sysiem/Suholyotem. Spocillcation• •.••.•..•.............. 

Data Base Specification .•..•......................... 

Program Specification ..........................•..•. 

Data Dictionary •.•••••••.•.•..•..•..•.......•..•..• 

Control, Backup, and Security Plan' .............•....•. 

Contingency Plan .................................. . 

lmplomentation Plan' .............................. . 

Conversion Phm •..•..•.••.•.••.••••••••••.••.•.•.. 

User Training Plan ....•.•..•.•..•.................. 

I'roiram Mllintenanco Manual ........................ . 

User's Manual .•..•..•...................... · · · · · · · 

Operatioruo Manual .............................•..• 

Data Baoe AdminiAtratlon Prooodureo Manual •..•......... 

2.3.1.1 

2.3.1.2 

2.3.1.3 

2.3.1.4 

2.3.2 

2.3.3.1 

2.3.3.2 

2.3.3.4 

2.3.3.6 

2.8.4 

2.3.5 

'" w 

2.4.4 

2.4.6 

2.4.8 

2.4.9 

2.4.10 

'Inoorporated in DeUdled Fwx:tionol Roqui,...,.nts. 

'Incorporated in S,..tem!Suboyst:em Specification. 

'Inoorporatod in U"""• Manual, Operatlono Manual, and Data Base Administration Prooeduroo Manual. 

'Incorporated in Conversion Plan. 

III.C 

Life-Cycle Management III-29 January 1991 
Ficure m-7 (Continued) 

SUMMARY OF MINIMUM DOCUMENTATION REQUIREMENTS 

AND REFERENCE NUMBERS FOR OSM LEVEL 8 

OPERATION AND MAINTENANCE PHASE 

Implementation Stage None Required 

Mai.ntenance Stage None Required 

III.C 

Life-Cycle Management IIT-30 January 1991 
Firure DI-8 

SUMMARY OF MINIMUM DOCUMENTATION REQUIREMENTS 

AND REFERENCE NUMBERS FOR OSM LEVEL 4 

Miooion Analysis Stage 

Concept IloveJopment Stage 

System Analysia Stage 

Sy~ Dooign Stage 

System Construction and 

Acquisition Stage 

III.C 

Life-Cycle Management 

INITIATION PHASE 

PrQject RequeAt •.•..•..• , , , • • . • . . • . . • . . . . • . . • . . • • • • • 1.1.1 

Miooion Analytd5 MoothOOoJ"'IY • • . • . . • . . • . • . . . . . • . . . . • • • 1.1.2 

CootlllenefitAnalyt!lo . . . . . . . • . . • . • . . • . . . . . . . . . . . . . . . • 1.1.3 

Project Charter ....• , •. , • . • . . . . . . . . . . . . . . . • . . • . . • . . 1.1.4 

Organizational Model • , , •• , ••.•.•....•..• , , • • • • • • • . • 1.l.li 

Miooion Proceao Model •. , •............• , , •. , • . • . . . . . . 1.1.6 

Inform..tion Model .. . .. . .. . .. . . .. . .. . .. . .. .. . .. . .. . . 1.1.7 

Miosion Need Statomont . , , •. , •................• , •. , . 1.1.8 

Syotem Objectiveo~• ...... , , • . . . . • . . . . . . . . . . . . . . . • . . . 1.2.1 

Application Systom kcl!itecture• ........... , •. , • . . . . . . 1.2.2 

Dota Archlt.lctun!'" • . • . . • . . . . . . . . . . . . • • . • . . . . • . . . . . . 1.2.3 

Data CommunicatiODI! Architecture• ........... , . • . . • . . • 1.2.4 

System Life-Cycle St:rategy . . . . . . . . . . . • . . • . . • . . • . . . . . . 1.2.6 

System J.Jf\1-Cyclo! Dat.oe • . • . . . . . . . . . . . . . . . . • . . . . . . . . . 1.2.7 

System Llfe-Cycle ReiiOUroeo Eotimat.l . . . . • . . • . • . • . . . . . . . 1.2.8 

Coet!BenefltAna\ylllo ... , .•..•............. , , . , •..... 1.2.11 

Revised MiM!on Nsed Stat.lment . . . . . . . . . . • . • . . • . . . . . . . 1.2.12 

System Ilociolon Paper 1 , ...........•. , • , . • . . . . . . . . . . 1.2.18 

DEVELOPMENT PHASE 

Cunent System Iloocription• ......... , • , ••............ 

Dotailed Functional Requirements* ........•............ 

Data Requi1'mnl!nl:a , • , .•.•....•..•..••••..•.•....•.. 

Doo!gn Propoul ••...........••.•..•..........•..•.. 

Dotailed CootJBenefit Analyola ..........•.•............ 

Revioed Llfe·Cycle Strategy .•....•..•••••••.•..•..•.•• 

System n..ciolon Paper 2 ......... , .................. . 

System Thot Plan .................................. . 

ADPE Spedllcati"""• , •..•............•..•........... 

System/Sub!l)'l!tem Specification• ....... , , •.•........... 

Data Base Spocifiotltion• ........... , ... , •............ 

Detailed l'rocoBS DeoliR• •..•.. · .........•..•. · • ..... . 

Program Spo>cification• .•............• , , • , . , ........ . 

Test Data Deo;gn• •.••.........•....••.•..........•. 

Data Dictionary" .•.•.........•..•..•..•..........•. 

Contml, Backup, tu~d Security Plan ..• , , • , .• , .......... . 

2.1.1 

2.1.2 

2.1.3 

2.2.1 

2.2.2 

2.2.8 

2.2.4 

2.3.1.3 

2.3.2 

2.8.3.1 

2.3.8.2 

2.3.3.3 

2.3.3.4 

2.3.3.5 

2.3.3.8 

2.3.4 

III--31 January 1991 
Figure m~ (Continued) 

MINIMUM DOCUMENTATION REQUIREMENTS FOR OSM LEVEL 4 

u..,r Acceptance Stage System Aoceptan"" Report •..•..•..•.•.•..••.••.•.•..• 

Jmplemontation Plan .......................•.•.... · · 

Con""rlli<m Plan* •....•.......................•..•.. 

u- Training Plan* .•..•..................•.•..•..• 

P<Hrt-lmplem&nt&.tion Review Plan •..•.................. 

Program Malnt&nance Manual • • ....................• • • 

Data Prooeosing Manual* ................•..•..•.•... 

U....-'s Manual" , ... , .............................. . 

Opemti<lrul Manual* .•..•.......................•..• 

Syotom Decision Paper 3 ..............•..•..•..•..... 

2.4..1 

m 

2.411 

2.4.-1' 

2.U 

2.4.6 

2.4.7 

2.4.11 

2.4.9 

2.4.11 

OPERATION AND MAINTENANCE PHASE 

lmpJ..,..ntation Stage Application Stewardship Oooument ...............•.••.. 3.1.1 

Mointenanoe Stap Poot-Implemontation Review Report ........ , • , •.. , . . . . . 3.2.1 

Syotem Decision Paper 4 . . . . . . . . . . . • . . . . • . . . . . . . . . . . . 3.2.2 

III.C 

Life-Cycle Management III-32 January 1991 
" 

15. References 

U.S. Department of the Interior, A Project Manager's Guide to Application Systems 

Life-Cycle Management (376 DM 10), Auguat 1985. 

U.S. Department of the Interior, A Project Manaser's Guide to Benefit/Cost Analysia 

of Information Technology Investments, January 1989. 

Guidelines for Soft wan~ Documentation Management, 6 June 1984, Federal Information Processing Standards Publication 105, National Bureau of Standards. 

Guidelines for Documentation of Computer Programs and Automated Data Systems, 

30 June 1974, Federal Information ProceBI!ing Standard Publication 38, National 

Bureau of Standards. 

Guidelines for Documentation of Computer Programs and Automated Data Systems 

for the Initiation Phase, 1 August 1979, Federal Information Processing Standard 

Publication 64, National Bureau of Standard&. 

6. Ef'tect on Other Documents 

This documentation standard superBedes OSM Directive ADP-3, Systems Implementation Standards. 

7. Effective Date 

Upon issuance 

8. Contact 

MIS Division Chief 

III.C 

Life-Cycle Management III-33 January 1991 

I 

' 

This page intentionally blank 

me 

Life-Cycle Management III-34 January 1991 

.m. 

b. Procedures 

III.D 

1) When commercial ADP equipment or software is purchlllllld, the hardware/ 

software package inventory will be updated. The inventory will be maintained 

by each field office and assistant directorate and will include, at a minimum: 

Item Purchased {including Version or Release Nwuber) 

Description of Item Pun:hased 

Type ofPun:hase {indicate one of the following: Computer, Add-in Board, 

Peripheral, Software, Accessory, Other) 

Manufacturer 

Vendor 

Serial Number 

Purchase Order Nwuber 

Purchase Date 

Receipt Date 

Quantity 

Price 

Person{s} who approved pun:hase 

Distribution Infonnation; 

To whom equipment/software is assigned 

{including Name, Title, Telephone Number) 

Location of equipment/sotlware 

The hardware and software inventory will be supplied to the MIS Division 

Chief. 

2) Each organ;zation will maintain an inventory of custom-developed software 

applications. Whllll a software development effort is approved, completed, or 

terminated, the application inventory will be updated. This inventory will 

include: 

Application Name 

Functional Description 

Software Environment 

{for eltlliD.ple, operating system required, programming language) 

Hardware Requirements 

{for exam.ple, CPU required, mamm-y requirements, storage requirements) 

Development Start Date 

Installation Date 

Installation Date Projected/Actual Indicator 

Use Termination Date 

System Developer(s) 

System Owner(s} (Name, Position, Telephone Number) 

System Manager(s) (Name, Position, Telephone Number) 

Resource Inventories January 1991 
" 

c. Responsibilities 

1) The MIS Division Cbiefja responsible for compiling and maintaining an ADP 

reSOUl'C(! inventory and providin& necessary inventory data to the DOl Office of 

Information Resoun:es Management. The necessary data will be ac<:Urate and 

provided on a timely bll8is. 

2) Assistant DirectOl's and Field Office Directon are responsible for ensuring that 

ADP reaour<:e inventories are maintained. 

4, Reporting Requirements 

Updates to the hardware, software, and application inventories will be provided to the 

MIS Division Chief semiannually (at the end of the &e«~nd and fourth quarlel's) in the 

electronic format specified by the MIS Division Chief. 

!5. ReferenC(;ll!l 

Department of the Interior Departmental Manual, Part 376 DM 11, Information 

Resources Management-ADP Resource Inventories. 

Paperwork Reduction Act of 1980 (44 USC 3501). 

Geuei"al Services Administration, Federal Information Resources Management 

Regulations {FIRMR). 

6. Effect OD Other Docum.ent8 

7. Effective Date 

Upon issuance 

8. Contact 

MIS Division Chief 

III.D 

Resource Inventories III-37 January 1991 
" 
" 

Thill page intentionally blank 

III.D 

Reaource Inventories III-38 January 1991 

E. AUTOMATED INFORMATION SYSTEMS MANAGEMENT ACCOUNTABILITY 

........... 

This section Jll"((Vides Office of Surface Mining (OSM) policies and responsibilities 

concem:in& manllif!ment accountability for automated information systems. 

2. DeftnitiOD!I 

a. Terms 

III.E 

Automated Information System (AIS). An ori&Irized combination of human 

resources, ADP equipment, software, and established methods and procedures 

designed to collect, process, and/or communicate data or information for the 

purpo~~es of supporting specific administrative, mission, or program requirements. 

Major AIS. An AIS that requires special, continuing management attention 

because of its importance to the support of a mission; its high development, 

operation, or maintenance costs; or ita significant impact on the administration of 

programa, finances, property, or other resources. An AIS is determined to be major 

when it meets any one of the following criteria: 

• The system directly affects the ability of DOl or OSM to perform a mission 

designated by the President, the CCBJ.gress, the Office of Management and 

Budget, or the Secretary as being of importance. 

• The system involves a significant investment, including personnel costs, 

relating to development, operation, and/or maintenance. In this context, 

significant investment has OCCUlTed if (a) the cost of initial development from 

conception to implementation eJ~:ceeds $1 million, (b) the cost of operating and 

maintaining the system ill any one year exceeds $0.5 million, or (c) the total 

life-cycle cost exceeds $5 million. 

• The system affects national roecwity or the llllCllr:ity and safety of people, 

substantial financial resources, or oth.el' valuable assets. 

• The system is used throughout DOl. 

• The system supports a function that is multi-bureau in scope. 

• The system directly affects DOl's ability to meet a critical departmental, 

national, or international misaion. 

System Owner/Steward. The program official whOIIIl program is supported by the 

AIS and is the primary use:r of the AIS, who initiated development of the AIS, or 

who exercisea functional oversight of the AIS. The syetem OWillll" is responsible and 

accountable for the products of the system. In some cases, system ownership may 

bo """"~ 

AIS Management Accountability III-39 January 1991 

' 
" 

System Manager/Custodian. The individual who proteci.8, operates, and/or maintains an AIS m accordance with a service agreement with the system oWllel'. In 

some instances, system manai')ment respon!lib:ilities may be ahared. 

b. Abbreviations 

ADP Automated Data Processing 

AIS Automated Information System 

DOl Department of the Interior 

MIS Management Information Systeiiill Division 

OSM Office of Surface Mi.ni.ng 

3. Policy/Procedures 

a. Policy 

Each OSM application shall be BMigned a 11ystem owner and BYBtem mana,er. In 

the case of mlijor information system applications {as defined by DOJ), the system 

owner and manager shall not be the same individual. 

b. Procedures 

Upon initiation of new application development or acquisition, system oWllel'S and 

managers shall be appointed and reported in accordance with policies and procedures found in section III.D, IRM Resoun:e Inventories, and section II.C, IRM 

Planning. 

c. Responsibilities 

III.E 

1) The MIS Division ChiefU! responsible for ensuring that syatem owners and 

managers are BSBigned responsibility fur and are held properly acro=table for 

the efficiency and effectiveness of their application systems. 

2) Assistant Directol'l! are respoll8ible fur: 

a) Ensuring that Byatem owners and managers are appointed for each application. 

b) Ensuring that system owners and managers are aware of their responsibilities and are held acrountable for meeting those responsibilities. 

c) Ensuring that system owners and managers are report.ed in accordance 

with sectiOll III.D, IRM ResoUl'Ce Inventories. 

3) The System Owner ja. responsible and accountable for the products of the AIS. 

The responsibilities of the System Owner include: 

AIS Management Accountability lll-40 January 1991 
III.E 

a) Defining the system's functional requirements. 

b) Providing functional oversight. 

c) Conducting a periodic review of system requirements W. order to determine 

whether the requirements continue to exist and the system continue~~ to 

meet, in an efficient and coat-effective manner, the purposes for which it 

was developed. 

d) Securing required information systems support for the AIS. 

e) EllSuring that a Continuity of Operations Plan ia developed for the AIS. 

f) E$tabli$hiog formal, written standards for program changes (both scheduled and emergency) and authorizing all scheduled program changes. 

g) Ensuring that W.ternal controls and operating policies that address the 

functionality of the AIS are implemented as required. 

h) CertifYing the AIS to ensure that it satisfies its defined functional and 

quality requirements. 

4) The System Manager is respoo.sible for: 

a) Assisting the system owner in defin;ng system requirements. 

b) Coordinating with OSM records managen regarding retention periodB and 

disposal standards applicable to the varioue types of data and storage 

media. 

c) E118uring that W.ternal control reviews, as outlllled in the DOl Automated 

Application System Control Evaluation Guideline, are oonducted as required. 

d) Coordinating with the MIS Information Reaources Security Adminiatratoc 

to determine appropriate IJ6Cilrity requirements before the AIS ia ~uired 

or developed and certifying before implementation that the AIS satisfies 

applicable security regulations, policies, and standards and that its security 

safeguards are adequate. 

e) Providing operations and/or maintenance support. 

0 Ensuring that all program changes meet formal, written standards and 

notifying the system owner when emergency program chaoges are made. 

g) Forecasting development, implementation, and operational coats of the AIS. 

AIS Management Accountability III-41 January 1991 
" 

4. Reporting Requirement& 

Updates to the hardware, software, and application inventories will be provided to the 

MIS Division Chief semiannually {at the end of the second and fourth quarters} in the 

electronic format specified by the MIS Divilli.on Chief. 

5. References 

Department of the Interior Departmental Manual, Part 376 DM 13, ADP-Automated 

Information Systems Management Accountability. 

Department of the Interior Departmental Manual, Part 375 DM 4, IRM Strategic 

Planning. 

Department of the Interior Departmental Manual, Part 375 DM 7, Economic Analysis 

in Support ofiRM Decision Making. 

Department of the Interior Departmental Manual, Part 375 DM 19, Information 

Resources Security Program. 

Department of the Interior Departmental Manual, Part 376 DM 10, life-Cycle 

Management of AIS. 

Department of the Interior Departmental Manual, Part 382 DM 11, Managing Reoords 

in Electronic Form. 

Department of the Interior Departmental Manual, Part 383 DM 1-12, Management 

and Safeguarding of Privacy Act Records. 

Department of the Interior, Project Manarer's Guide to Applications Systems Life. 

Cycle Management. 

Automated Application System Internal Cootrol Guideline. 

Office of Manqement and Budget, OMB Circular No. A-123, Internal Control 

Systems. 

Office of Management and Budget, OMB Circular No. A-130, Management of Federal 

Information Resoun:ee. 

Office of Management and Budget, OMB Circular No. A-127, Financial Management 

Systems. 

Federal Managers Financial Integrity Act. 

Paperwork Reduction Act of 1980 (Public Law 96-511). 

III.E 

AIS Management Accountability ITI-42 January 1991 
" 

Paperwork Reductiou Reauthorization Act of 1986 (Public Law 99--1500). 

Computer Security Act of 1987 (Public Law 100-235). 

Federal Information Processing Standards (FIPS). 

8. Effect on Other Documents 

No~ 

7. Effective Date 

Upo11. iesuance 

8. Contact 

MIS Divjsion Chief 

III.E 

AlS Management Accountability Ill-43 January 1991 
" 
Thill page intentioually blank 

III.E 

AIS Management Acaruntability ITI-44 January 1991 

" 

Chapter IV 

TELECOMMUNICATIONS 

" 

TELECOMMUNICATIONS 

1. Purpose 

This section explains Office of Surface Mining policies and procedures for identification 

and use of telecommunications systems. 

2. De:ftnitiona 

a. Tel'lll$ 

Telecommunications Facilities. Equipment used for telephone, telegraph, teletype, 

data, faceimile, telephotograph, video, and audio transmissions, and such corollary 

items as distribution systems and communications lleCilrity facilities. 

Telecommunication& Service. The tran8mi.ssion, emission, or reception of signals, 

signs, writing, images, BOUJld.s, or intelligence of any nature, by wire, radio, visual, 

or other electrical, electromagnetic, or aeoustically coupled means. 

b. Abbreviations 

ADP Automated Data Processing 

001 Department of the Interior 

FTS Federal Telephone System 

MIS Management InfOl'lllation Systems Division 

OSM Office of Surface Mining 

3. Pollcy!Pl'Ocedurea 

a. Policy 

OSM telecommunications decisions will be made in acoordance with Federal and DOI 

standards and guidance. 

b. Procedures 

1) Acquisition of telacommunieations facilities and services should be made in 

accordance with the policies outlined in section III.A, ADP Acquisition. 

2) OSM will participate in the FTS 2000 Data Communications Coordination 

Council, whiclt serves as a forum fur the exchange of illfurmation on FTS 2000 

matters. The council is involved in general planning for DOrs use of FfS 2000 

data services and ensuring that those services are used efficiently and costeffectively. The council also coordinates activities related to implementation of 

IV. 

Telecommunications IV-! January 1991 

! 
FTS 2000 data communications services and identifies opportunitiBB for the 

bureaus to share teehnical expertise, resources, and access to FTS 2000 services. 

3) Telecommunications requirements should be satisfied through equipment and 

software that meets Federal, DOl, and OSM standards. 

Detailed information regarding specific telecommunications topics may be found in 

DOl telecommunications handbooks (see references). 

c. Responsibilities 

1) The MIS Division Chief is respollBible for: 

a) Ensuring OSM-wide compliance with Federal, DOl, and OSM standards. 

b) Providing guidance to Assistant Directors and other OSM organizations 

regarding telecommunications issues. 

c) Appointing an OSM primary and alternate representative for theFTS 2000 

Data Communications Coordination Council 

2) Allsistant Directors are responsible for ensuring compliance with Federal, DOl, 

and OSM standards within the assistant directorate. 

3) OSM's FTS 2000 Data Communications Coordination Council Representative is 

responsible fur attending council meetings, presenting OSM coDCenls and issues, 

assisting in council analyses and evaluations, and keeping other OSM individuals 

informed with regard to progress and issues. 

4. Reporting Requh'enlents 

5. References 

Department of the Interior Departmental Manual, Part 877 DM 2, 

Telecommunications. 

General Services Administration, Federal Information ResoUl'Ces Management 

Regulation. 

General Services Administration, Gl011sary of Telecommunications Terms, 

FED STD 1037A. 

IV. 

Telecommunications IV-2 January 1991 

' 
Department of the Interior TelecommuniCB.tions Handbooks: 

Radio Communications Handbook 

Telecommunications Terminology Handbook 

Telephone Syatems Handbook 

Local Area Network Guide 

DOl Mainframe Strategy, May 1988 

6. Effect on Other Documents 

None 

7. Effective Date 

Upon iaauance 

8. Contact 

MIS Division Chief 

IV. 

Telerommunications IV-'! January 1991 
" 
IV. 

Telecommunications 

" 

This pap intentionally blllllk 

IV-4 January 1991 
" 
" 

ChapterV 

DATA ADMINISTRATION 
" 
" 

The Office of Sutfw:e Mining DiviBion of MruiCJIIflfMnt Information Systems 

wiU promulgak data administmti<m policies at a later date. 

Appendix A. 

OFFICE OF SURFACE MINING 

ADP DOCUMENTATION CONTENT GUIDELINES 
" 
" 

Appendix A 

OFFICE OF SURFACE MINING 

ADP DOCUMENTATION CONTENT GUIDELINES 

This appendix contains content guidelines for the ADP application documentation referenced 

in section II.C, Life Cycle Management of ADP Information Systems. Detailed explanations 

of the material that each doeunttmt should contain are alBo provided. 

Figure A-1 shows all Office of Surface Mioing (OSM) documentation requirements as sat 

forth in section II. C. The guidelines in this appendix are limited to Levels 1, 2, and 3 of that 

list, which encompass all system or application development projects except those involving 

m~or, service-wide efforts. These major development projects, which fall into Level4 of the 

OSM documentation guidelines, require oversight by the U.S. Department ofluterior Office 

of InfOrmation Resources Management. Accordingly, content guidance for Level4 docunumtation is foWld in the DOl Project Managlll"s Guide to Application Systems Life Cycle 

Management. Figures A-2, A-3, A-4, and A-5 show the requirements for eaeh documentation level. The following documentation ill included in this appendix: 

Document Title 

Reference Number from OSM 

Documentation Requirementa 

Feasibility Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.5 

P!'Qject Management Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.9 

Quality Assurance Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.10 

Coat/Benefit Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.11 

Detailed Functional Requirementa . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.2 

Data Requirementa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.3 

Unit Test Plan ........................................ 2.3.1.1 

Integration Test Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1.2 

System Test Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1.3 

Ac<:eptance Test Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1.4 

System/Subsystem Specification ........................... 2.8.8.1 

Data Base Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.3.2 

Program Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.3.4 

Data Dictionary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.3.6 

Contingency Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.8.5 

Conversion Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.3 

User Training Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.4 

Program Maintenance Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.6 

User's Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.8 

Operationa Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.9 

Data Base Administration Procedures Manual . . . . . . . . . . . . . . . . 2.4.10 

The documentation is presented in the order that it is found in the OSM documentation 

requirementa. Each document is paginated by ita title and reference number from the 

documentation requirements list (Figure A-1) for easier reference and update. Gaps in the 

number scheme are the result of Level 4 documentation, which is discussed in DOl 

documentation guidance. 

Appendix A 

Documentation Content Guidelines A-'1 January 1991 
FtgunA-1 

COMPARISON OF MINIMUM DOCUMENTATION REQUIREMENTS 

I..Jia.Cycl8 Ph•aiStllgiiiDocu....m I t-•4 I uwol3 I Lewol 2 I Levtol1 

' INllATlON PHASE 

"' Millon Analyall Sllla• 

1.1.1 Project Rsqu&St Raqulrad 

1.1.2 Mlasio~ Analysis Mathodok>gy Roqulrad 

1.1.3 Ccsi/Benam Analysis Requlrad 

1. 1.4 Project Charter Required 

1.1.5 Organizational Model Rsqu~&d 

1.1.6 M"'sion ProceSS&S Mod~ R~~qu~&d 

1.1.7 lnformlllion Modal Required 

1.1.8 Mission Naed Statement Required 

'-' ConCCipl Developm.nt Staga 

1.2.1 System Objectives Optional 

1.2.2 AppUcatO.n System An::h~acture Optional 

1.2.3 Data Arch~ectura Optional 

1.2.4 Data Communications Ar<:hllecture Op\lonal 

1.2.5 FeaslbRity Study Requlrad Required 

1.2.6 System LKe-Cyda S!rategy Required 

1.2.7 System LHe-Cycle Dates Required 

1.2.8 Syslolm l.He-Cyde Resourcas Eatlmata Required 

1.2.9 Project t.lanagement Plan Required Required 

1.2.10 Quality Assurance Plan RequirGd Raqu~ad' 

1.2.11 Costll!enam Analysis Required Required RaquirO>d 

1.2.12 Revised Mission Need Statement Requir&d 

1.2.13 System Decision Paper 1 Required 

11nocrpcralotd in Project Management Plan. 

Appendix A 

Documentation Content Guidelines January 1991 
" 

Fiture A-1 (Continued) 

COMPARISON OF MINIMUM DOCUMENTATION REQUIREMENTS 

Lll.cycl8 PhaHStageJDocument I uva14 I 

' DEVELOPMENT PHASE 

,_' System Analyala Staga 

2. 1.1 Currant S)'stem D%cfiptlon Optional 

2.1.2 o..!ai!Qd Functional Requirements Optional 

2.1.3 Data Requirements R&quir&d 

.. System O.Sign srage 

2.2.1 Design Proposal Ruquirod 

2.2.2 Datail&d Cost/Bane!~ Anal)lsls Raqulr&d 

2.2.3 Revised Ua-Cycla Strategy Required 

2.2.4 System Oedsloo Paper 2 Required 

'-' Sy&Mm Construction and Acqulaltlon Stage 

2.3.1 Test Plans: 

2.3.1.1 Un~ Test Plan 

2.3.1.2 lntagralion Ta$1 Plan 

2.3.1.3 Sys!Qm Teo! Plan 

2.:11.4 Acceptance Test Plan 

2.3.2 ADPE SpGCific:a.tions 

2.3.3 Application Softwara Dccumentation: 

2.3.3.1 System/Sut>syslam SJ>$C~Icatlon 

2.3.3.2 Data Base Spocificalion 

2.3.3.3 Detail&<! Proo&Ss Design 

2.3.3.4 Program Speclfi<;ation 

2.3.3.5 Taor Data O>'Sign 

2.3.3.6 Data Dicliono.ry 

2.3.4 Control. Backup. and Security Study 

2.3.5 Contingency Plan 

'lncorporatad In Detailed Functional Requirements. 

'lncotpOTatad In System/Subsystem Specification. 

Required 

Optional 

Optional 

Optional 

Optional 

Optional 

Opti<;naJ 

Optional 

Required 

"""'" I level 2 I Len! 1 

R&qurr&d' Required' Optional' 

Raqulr&d Required Optional 

Required Required Optional 

Required 

Required 

Required 

Required 

Required' 

Required 

Required Requif'<ld Optional 

Raqulr&d 

Re-quired Requi"'d Optional 

R&qulrod' Required' Required' 

Requir&d Requir&d 

'Incorporated in Use~s Manual, Ope<ationa Manual, 1111d Data Base Administraticn Prooedu"'s Manual. 

Appendix A 

Documentation Content Guidelines A-5 January 1991 
" 

Fipre A-1 (Continued) 

COMPARISON OF MINIMUM DOCUMENTATION REQUIREMENTS 

Llfa.Cyt:l• Ph__.$1:agll/Docu,..nt I Laval 4 I L•val 3 I level 2 I Lllval 1 

u u .. r AccepUonc. Stage 

2.4.1 Currenl System Oescriptlon Required 

2.4.2 Mission Analysis Metht>dclogy Required Required" 

2.4.3 Ccsi/Banaf~ Analysis Optional Raqu~&d 

2.4.4 UHr Traini"{{ Plan Optional Raqulr&d R&qulrad 

2.4.& Post-lmplamantation Raviuw Plan Raquir&d 

2.4.6 Program Maintenanca Manual Required Raquirad Required Optional 

2.4.7 Data Processing Manual Optional 

2.4.8 Usa~s Manual Optional Required Required Raqulr&d 

V-.9 Operations Manual Optional Required Requ~ed Required 

2.4.10 Data Base Administration 

Procedures Manual Requirad Required Required 

2.4. 11 Syatam Decision Paper 3 Required 

' OPERATION AND MAINTENANCE PHASE 

'·' 1111111emantatlan Stage 

3.1.1 Application Stewardship Dooumant Rooquirad 

, Molntenanee Stage 

3.2. 1 Post-Implementation Review Report R<oquirad 

3.2.2 System Decision Paper 4 Required 

'lnccrporatud in Conversion Ptan. 

Appendix A 

Documentation Content Guidelines A-< January 1991 
FigureA-2 

SUMMARY OF MINIMUM DOCUMENTATION REQUmEMENTS 

AND REFERENCE NUMBERS FOR OSM LEVEL 1 

Mission Analyeis Stag.. 

Concept Development Sto~ge 

INITIATION PHASE 

Nono Required 

Nono Required 

DEVELOPMENT PHASE 

Curtflllt Syatom Dei!Oription1 . . • . . • . . • . . . . . . • . . • . . • . . . . 2.1.1 

System Dooign Sto~ge 

System Cm:u.truction and 

lmpl~IIlOIIltation Stage 

Maintena.noe Sto~ge 

*Optional 

Detailed Functional Requirements• • . . • . . • . . • . . . . . . • • . • . 2.1.2 

Data Requirements• • . . • . • • . • . . . . • . . • . . • . . • . • . • • . • • . 2.1.8 

None Requi:red 

Data Base Specification• ••••••••••••••••••••••••••.•• 

Data Diotio!IBl)'• ..•.••.••.•.•..•..•.•..•.•.....•... 

Control, Backup, and Security Plan' •.....•............. 

Program. Maintenance Manual• ....................... . 

User's Manual ..•....•..•.•.•.....•..•.•..•..•..•.. 

Operation• Manual .•.•..•..•.•.•.....••.••••.••.••. 

Ds.ta a ..... Adtniniott"B.tion Ptacsdu:reo Manuol .•..•..•..•.• 

OPERATION AND MAINTENANCE PHASE 

None Required 

None Required 

2.3.8.2 

2.8.8.6 

2.3.4 

2.4.6 

2.4.8 

2.4.9 

2.4.10 

'Incorporated in Detailed Functional Requirements. 

'Incorporated in Uoer's Manual, Opero.t:i.ons Manual, and Data Base Adminiott"B.tion Prooodureo Manual. 

Appendix A 

Documentation Content Guidelines A-7 January 1991 
" 

Fi"'""MI 

SUMMARY OF MINIMUM DOCUMENTATION REQUIREMENTS 

AND REFERENCE NUMBERS FOR OSM LEVEL 2 

INITIATION PHASE 

Miooion Analyais Stag& None Required 

Concept Development Stage Feasibility Study .................................. . 

Project Ma11911'1ment Plan •............•..•..•..•.•..• 

Quality Assurance Plan' ............................ . 

Co•VBenefitAnalyma .•..•........................... 

DEVELOPMENI' PHASE 

1.2.5 

1.2.9 

1.2.10 

1.2.ll 

Cut-rent Syatem n-riplion" . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 

Detailed Functional ReqairemfmiB ..•..•..•....•.. , .••. , 2.1.2 

Data Requirementa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.3 

Implementation Stage 

Morintananoe Stage 

None Requintd 

Dllta &so Specificali.on ..•..•..•.•.•..•..•..•....•..• 

Data Dictioruuy .•.•..•..•.•........................ 

Control, Backup, and Security Plan' ................... . 

Contingency Plan •.......•....•....•..•....•..•..••. 

Uoer Training Plan .•..•....•.•..•..•..•.........•.. 

Program Maintenance Manll8.! .................•.....•. 

Uoer'l Manual ...................................•. 

Operation• Manual .•..•............................ 

Data Base Adminlotralion Pr<>a>duree Manuol ........•.... 

OPERATION AND MAINTENANCE PHASE 

None Required 

None Required 

1

lnoorporat..d ;n ~110t ~nt Plfm. 

'Incorporated in Detailed Functional Requirements. 

2.3.3.2. 

2.3.3.6 

2.3.4 

2.3.6 

2.4.4 

2.4.6 

2.4.6 

2.4.9 

2.4.10 

'Inc:orporated in Uoer'8 Manual, Operat:ioru1 Manual, and Data Base Adminiotration Procedureo Manual. 

Appendix A 

Documentation Content Guidelines A-8 January 1991 
FigureA-4 

SUMMARY OF MINIMUM DOCUMENTATION REQUIREMENTS 

AND REFERENCE NUMBERS FOR OSM LEVEL 3 

Miolion Analyslo Stage 

Concept Development Stag& 

INITIATION PHASE 

None Reqllired 

Feasibility Study . , • , .• , .• , •.•..•..•..•....•..•..•.• 

Projeot Management Plan •..•.•..•. -..•..•........... 

Quality A.OUJance Plan ............................ .. 

Cost/Benefit AnalysiB ............................... . 

DEVELOPMENT PHASE 

1.2.S 

1.2.9 

1.2.10 

1.2.ll 

System Analyli.o Stage Current System :O..ocription1 •• , , • , •• , • , • • • • • • • • • • • • • • • 2.1.1 

System Design Stage 

Syotem Ccnstruction and 

Acquioltlon Stage 

Uoer Acceptance Stage 

O..buled Functional Requirement. . . . . . . . . . . . . . . . . . . . . . . 2.1.2 

Data R.squi'l'&lnentB • • . • • . • . • • • • • • • . • • • • • . • . • . . • . . • . . 2.1.3 

None Required 

Unit Test Plan ................................. , .. , 

Integration Test Plan ............... , .. , ........... .. 

System TeAt Plan ...............•..•.••....•..•..... 

Acceptancfl Test Plan .............................. .. 

ADPE Specification' ............................... .. 

Systom/Subsyato.n Specification• •.•...................• 

Date Baa& Specification ............... , .• , .• , , •.• , .•. 

Program Specification ............. , ................ . 

Data DictionlllY ................................... . 

Control, Backup, and Security Plan' ............• , .• , .•. 

Contingency Plan .................................. . 

Implementation Plan' ....................• , .... , •..• 

Conversion Plan .................................. . 

Uoer Training Plan ............. , ..•..•..•.•..•..... 

Program Ma!ntorumce Menual ...•....•... , •..•........ 

U&er'ft Manual .................. , .• , .•.•. , •..•..... 

Operatlone Manual ....... , ........................ . 

Data Base Administretion Proc.dUNs Manuel .•..•. , ..•... 

2.3.1.1 

2.3.1.2 

2.3.1.3 

2.3.1.4 

2.3.2 

2.3.3.1 

2.3.3.2 

2.3.3.4 

2.3.3.6 

2.3.4 

2.3.5 

2.4.2 

2.4.3 

2.4.4 

2.4.6 

2.4.8 

2.4.9 

2.4.10 

'Incorporatad in Detai.led Functional Requlmmento. 

"lncorporaloed in Syotem/Suboystem Specification. 

'Incorporated in Uoer's Manual, Operatiom Manual, and Data Base Admlnlotration Proc.dur80 Manual. 

'Incorpomted in Convenion Plan. 

Appendix A 

Documentation Content Guidelines A-9 January 1991 
" 

Fipre A-4 (Continued> 

SUMMARY OF MINIMUM DOCUMENTATION REQUIREMENTS 

AND REFERENCE NUMBERS FOR OSM LEVEL 3 

OPERATION AND MAINTENANCE PHASE 

Implementation Stage None Requlr&d 

Ma!ntonanca ~ None Required 

Appendix A 

Documentation Cootent Guidelines A-10 January 1991 
" 

_.,A-5 

SUMMARY OF MINIMUM DOCUMENTATION REQUIREMENTS 

AND REFERENCE NUMBERS FOR OSM LEVEL 4 

Miooion Ana\ysie Stage 

Conoept Development Stage 

System Anal)'lrio Stage 

Syot.om O...ign Stage 

System Conotruction and 

Aoquisition Stage 

•Optional 

Appendix A 

INITIATION PHASE 

PrQjec:t Requeot .................................... . 

Minion Analyois Methodology ......•.••...•..•........ 

CO~enefitAnaly&o ..........•.•..•.•.............. 

Proj&et Chartor .. , .• , ............................. . 

Organlzatinna.l Model .. , , .. , ..•.•..•.......•....•.. , 

Miollion Proce .. Model , , , ........................... . 

Information Model •. , .• , .•....•..•....•..• , •• , •••• • . 

Mi•llion Need Statement ..............•..•. , , , . , ..... 

System Objective•* ................•..•..•.•........ 

Application System Arclrl.tecture* •.•................... 

Data Arclrl.tectuno* . , , , , . , , , ....•..•..•..•.•..•.. , , , 

Data CommunicatiOllll Arehi.tect!.m!• ••••..•..•.•..•..•.. 

System Life-Cycle Strategy .. , . , , , , , ................. , 

System Life-Cycle Datea . , , , , •.•.•.•.••..•..•..•.•••• 

System L!fe-Cyolo Roeourceo Estimate ............. , , , • , • 

Coot/Benefit Analyois ............................... . 

R&v:i .. d Miooion Need Statement .............••.•...... 

Syot&m Decision Paper l ................••.•..•.•.... 

DEVELOPMENT PHASE 

Curnmt System O..oc:ription• ..........•.•..•..•....... 

Detailed Furu:tional Reqlrirementa• .............•.••.•.. 

Data Reqlrirements .•. , ............................ . 

Ilooijrn Proposal .................................. .. 

O..talled Cost/Benefit AnalyoiA ..•..•..••••••••..•..•... 

R&v:ioed Life-Cycle Stmtogy ...... , ................... . 

System Decisinn Paper 2 ............................ . 

System Teat Plan ............. , .................... . 

ADPE Speclfioationo• ..•.••.•................. , .. , .. . 

System!Suboystem Specification• ............•. , •. , .... . 

Data Baso Sp<>cifleation• , ............... , ........... . 

Detailed Process Design• , . , ....................•.•... 

Program Speclfi.,.tion• ..•.......................•... 

Test Data Design• ....•.••. , ....................•..• 

Data Diclinnary• .................................. . 

Control, B""kup, and Security Plan .•.•• , • , , • , ••.•..•..• 

1.1.1 

1.1.2 

1.1.3 

1.1.4 

1.1.5 

1.1.6 

1.1.7 

1.1.8 

1.2.1 

1.2.2 

1.2..8 

1.2.4 

1.2.6 

1.2.7 

1.2.8 

1.2.11 

1.2.12 

1.2.13 

2.1.1 

2.1.2 

2.1.3 

2.2.1 

2.2.2 

2.2.3 

2.2.4 

2.3.1.8 

2.3.2 

2.3.3.1 

2.3.3.2 

2.8.3.3 

2.3.8.4 

2..8.8.5 

2..8.8.6 

2.8.4 

Documentation Content Guidelines A-ll JanUIIry 1991 

I 
" 

Figure A-5 (Continued) 

MINIMUM DOCUMENTATION REQUJREMENI'S FOR OSM LEVEL 4 

lmplBIIU!ntation Stage 

Maintenance Stag.. 

Appendix A 

System Aoeeptaru:e Report .•.•..•..•.•..•••• , .•••••••• 

Implementation Plan ...............•..• , .•. , .••. , .. , 

Convenlon Plan* ......•... , •.•. , .................. . 

u..,. Training Plan• • , , , . , . , ..•....•................ 

Poet-Implementation Review Plan , , , , , . , , , , , , . , , .. , . , .. 

Progmm Maintenance Manual , , , , , , , , . , . , .. , ......... . 

Data Proceoo:ing Mllllulll• .•....•..•.•........•..•••.• 

Uoer'o Manual• ................................ , . , . 

Opom.tlono Manual• ...•..• , ... , . , , , , , .•....•..•.. 

System Decision Papor 3 , .•.. , . , , , , • , , • , •.••.•....•.. 

OPERATION AND MAINTENANCE PHASE 

2.4.1 

2.4.2 

... .. 2.4.4 

w 

2.4.6 

2.4.7 

,.. 

2.4.9 

2.4.11 

Appl!Ciition Stewordsbip Document , . . • . . . . . . . . . . . . . . . . . 3.1.1 

Poet-Implementation Review RopOJt . . • . • . . • . . • . • . . • . . . . 3.2.1 

System Decll!ion Papor 4 , . , , . . . . • . • . • . . . . . . . . . . . . . . . . 3.2.2 

Documentation Content Guidelines A-12 January 1991 
P,.... 

Content 

FEASIBILITY STUDY 

(1.2.5 on OSM Documentation Requirements List) 

OSM managers and the information &ystelll8 &taf£ ll!lf! the information in the 

Feasibility Study to ensure that: 

• A number of alternatives for developing a new ey&tem or an enhancement 

to an existing system are considered 

• Requiremente for the selected alternative are clearly understood and 

thoroughly developed 

• Continued development of the system or enhancement is warranted and 

can be justified in terms of cost and benefite. 

The Feasibility Study presents a conceptual design for a new system or an 

enhancement to an existing system. The recommended design should be the 

best of a number of alternatives, each of which should be discussed in the 

study. Considerations involved in making the recommendation include: 

• A description of what the proposed system or enhancement will be 

required to do and how it will meet those requiremente 

• An analysis of the existing system or process and formulation of 

alternative systems or enhancemente which improve that system or 

process 

• Quantitative and qualitative evaluation criteria that lead to selection of 

the beet alternative. 

Figure A-6 summarizes the information required in the Feasibility Study by presenting the 

document's table of contents. Detailed explanations of the material that each section should 

contain are then found in the pages that follow. 

The CosV.Benefit Analysis can be iucluded as an appendix to the Feasibility Study or 

documented separately. Requirements for this document are di!ICUllsed later in this appendix, 

and its table of contents is shown in Figure A-9. 

January 1991 1.2.5--Feasibility Study 1 
-·" 
1. 

2. 

3. 

4. 

5. 

" 

Figure A~ 

TABLE OF CONTENTS FOR FEASIBILITY STUDY 

{1.2.5 on OSM Documentation Requirements List) 

Introduction 

1.1 Background 

1.2 Srop' 

1.3 Refenmces 

Management Summary 

2.1 Requirements 

2.2 Objectiv1111 

2.3 Assumptioilll and Constraints 

2.4 Methodology 

2.5 Evaluati011 Criteria 

2.6 Recommendation 

2.7 Other Alternatives Considered 

System Requirements and Objectives 

3.1 Requirements 

3.1.1 Output 

3.1.2 Input 

3.1.3 Data Base and Files 

8.1.4 Validation 

3.1.6 Processing and Data Flow 

3.1.6 Security 

3.1.7 Information Stmage and Retrieval 

3.1.8 "'"""~ 3.2 Objectives 

Analysis ofthe Existing System 

4.1 Processing and Data Flow 

4.2 Workload 

4.3 Costs 

4.4 Personnel 

4.5 Equipment 

4.6 Limitations 

Proposed System 

5.1 Deacriptioo of Proposed System 

5.2 Improvements 

January 1991 1.2.5-Feasibility Study 3 
" 

Figure A-6 (Continued) 

TABLE OF CONTENTS FOR FEASffiiLITY STUDY 

(lJU on OSM Documentation Requirements Ust) 

5.3 Impaeta 

5.3.1 Equipment Impacts 

5.3.2 Software Impacts 

5.8.3 Organizational Impacts 

5.3.4 Operational Impacts 

5.3.5 Developmental Impacts 

5.8.6 Site and Facility Impacts 

5.3.7 Cost Impacts 

6. Alternative Systems 

6.1 Alternative System 1 

6.1.1 Description 

6.1.2 lmpn:nrements 

6.1.3 Impacts 

6.1.3.1 Equipment Impacts 

6.1.3.2 Software Impacts 

6.1.3.8 Organizational Impacts 

6.1.3.4 Operntional Impacts 

6.1.3.5 Developmental Impacts 

6.1.3.6 Site/Facility Impacts 

6.1.3.7 Cost Impacts 

6.n Alternative System n 

7. Rationale for Recommendation 

(Optional) 

Appendix A--CosVBenefit Analysis 

4 Feasibility Study-1.2.5 January 1991 
Feasibility Study 

Section Title 

I Iutroduction 

I. I Background 

1.2 Soopo 

1.3 References 

January 1991 

" 

Content 

Provide appropriate background and summary 

information. 

Provide a brief ovel'View of the project and why it is 

being cnnducted. 

Explain why the Feasibility Study is needed, provide a 

brief overview of its organization, and indicate systemrelated topics that have been included in the document 

or e:~reluded from consideration. 

List pertinent standards, guidance, documentation, and 

any other materials used to prepare the Feasibility 

Study. Include veudor-supplied materials; project 

documentation; other in-house documentation; and 

Federal, departmental, agency, and industry standards 

and guidelines. 

1.2.5-Feasibility Study 15 
Feasibility Study 

Section 

2 

2.1 

2.2 

2.3 

Titlo 

Managemeut 

Summary 

Requll'emente 

Objectives 

Assumptions and 

Constraints 

6 Feasibility Study-1.2.5 

" 

Cnnt.nt 

Summarize material presented in the study. Present 

evidence that the propo~~ed system or enhancement 

meets requirements. 

Summarize the requirements that the new system or 

enhancement will fulfill. Possibilities include: 

• New serv:iCils 

• Increased capacity 

• Legi.alative/policy improvements 

• Privacy and security 

• Audit controls. 

Show that the new syatem or enh1111cement can be 

available by the estimated target/completion date. 

Summarize the major performance objectives for the 

new BYBtem or enhancement. Possibilities include: 

• Reduced COBts 

• Increased productivity 

• lncri:!ased proceashlg speed 

• Improved management services 

• Improved controls 

• Compliance with regulations. 

Describe any factors that affect the conclW!iona of the 

study. Possibilities include: 

• Operational life of the proposed system 

• Period of time allowed for comparison of 

alternatives 

• Interaction of the new system or enhancement 

with other systems and organizations 

• Input, processing, and output requirements 

• Financial constraints 

• Legilllativelpolicy constraints 

• Changing hardware, software, or operating 

environment 

• Availability of information and rasources. 

January 1991 
Feasibility Study 

s.ction 

2.4 

2.5 

2.6 

2.7 

Title 

Methodology 

Evaluation Criteria 

Recommendation 

Othel' Alternatives 

Considered 

January 1991 

" 

Provide a detailed description of how the study was 

conducted and how the current system or method, the 

proposed system or enhancement, and the alternatives 

were evaluated and compared. Summarize the method 

or strategy used (for example, survey, weighting, 

modeling, benchmarking, prototyping, or simulation). 

Identify the factors that were used to arrive at the 

reeommendatioii!I made in the study. Possibilities 

include cost, priority, development time, and ease of 

~. 

Present the results of the study. Include the 

consequences of not taJring action and whether delays 

can be tolerated. 

Describe each of the alternatives and explain why it 

was not selected. 

1.2.5---Feasibility Study 7 
" 

Feasibility Study 

3 

8.1 

3.1.1 

3.1.2 

3.1.3 

3.1.4 

3.1.5 

3.1.6 

Titlo 

System Requirements 

and Objectives 

Requirements 

Output 

Input 

Data Base 

and Files 

Validation 

Processing and 

Data Flow 

Security 

8 Feasibility Study---1.2.5 

Content 

Provide a high-level description of what the new system 

or enhancement will be required to do and how it will 

meet those objectives. Identify the items that are 

mandatory. 

Describe what the new system or enhancement will be 

required to do. 

Describe what the system will produce. Possibilities 

include reportll, documents, and data. For each item, 

include characteristics such 1111 how it will be used, how 

often it will be required, how it will relate to other 

products, and how it will be distributed. 

Describe the data that the new system or enhancement 

will use to generate the output. Incl-ude the source of 

the data; the type, volume, and organization of the 

data; and how often the data will be submitted. 

Describe the files that the new system or enhancement 

will use. Include the content of each file, its purpose, 

how it will be used in the new system or enhancement, 

and how often it will need to be updated. 

Describe the criteria that will be used to validate data 

in the new system or enhancement. 

Explain how the new system or enhancement processes 

data. Provide a flow chart that shows major functions, 

processes, and activities and describe each in the text. 

Provide detailed requirements for security, privacy, and 

control of the new system or enhancement. 

January 1991 
·"' 

Feasibility Study 

Section TiU. 

3.1.7 Information Storage 

and Retrieval 

3.1.8 rn.....-... 

Objectives 

January 1991 

Contont 

Explain where and how the new system or 

enhancement will store data and how and for what 

purposes the data will be retrieved. DescnDe any 

additional or special requirements for information 

storage and retrievaL 

Identify any other systems with which the new system 

or enhancement shares information or other data 

prooes8ing activities. Explain how the interaction is 

acoomplished and any possible effects on either system. 

Explain the major performance objectives for the new 

system or enhancement in terms of the requirements 

stated in the previous section. 

1.2.5--Feasibility Study 9 
Feasibility Study 

Section 

4 

4.1 

4.2 

4.3 

4.4 

4.5 

4.6 

Title 

Analysis of the 

Existing System 

Processing aud 

Data Flow 

Pereo=el 

Equipment 

LimitatioDS 

10 Feasibility Study-1.2.5 

.II ' 

Content 

Provide an objective description of the system that is to 

be replaced or enhanced. This will provide a starting 

point for determining the economic and managerial 

advantages of the new syatem or enhanCi!ment. 

Explain. how the existing system processes data. 

Provide a flow chart that shoWll major functions, 

processes, and activities and describe each in the text. 

Describe the volume of work handled by the existing 

system and explain how the volume of work affects the 

system's performance. 

Provide an itemized list that shows how much it costs 

to operate the existing system. Include manpower, 

equipment, space, suppott services, materials, and 

overhead. Detailed information can be included in the 

Cost/Benefit Analysis. H so, summarize the 

information here and refer the reader to the 

Cost/Benefit Analysis. 

Describe the skill categories and numbers of people who 

operate and maintain the existing syatem. Include both 

government and contractor employees. 

Describe the equipment the existing system uaes. 

Include system hardware, peripheral devices, and 

accessories. 

Explain the existing system's deficiencies. Possibilities 

include inadequate information or lack of timely 

information (as related to decision makers and others 

who use the information), inefficient use of resources, 

technical problems, and organizational or policy 

considerations. 

January 1991 
Feasibility Study 

Section 

5 

5.1 

5.2 

5.3 

5.3.1 

5.3.2 

5.3.3 

Title 

Proposed System 

Description of the 

Propo&ed System 

Improvements 

Impacts 

Equipment Impacts 

Software Impacts 

Organizational 

Impacts 

January 1991 

" 

Content 

Describe how the requirements and objectives disCU88ed 

in Section 3 will be met. Limit the discussion to the 

recommended system or enhancement only. Include 

any information that will enable concerned parties to 

determine how the system or enhancement will affect 

other systems. 

Explain the concept of the new system or enhancement 

in tenus ofhow it will meet the req..rirement& disCUIIsed 

in Section 3. Describe how the concept was developed, 

including any software engineering tools or 

methodologies that were uaed, also in terms of the 

requirements. 

Explain how the new system or enhancement will 

improve functions, processes, and activities in tenus of 

the objectives discussed in Section 3. 

Explain how the new system or enhancement will affect 

existing systems and operations. Include potential 

conversion problems. 

Describe any new equipment or changes to eDsting 

equipment that will be required to implement the new 

system or enhancement. 

Describe any additions or modifications that will be 

required to adapt existing applications or support 

software to the new system or enhancement. If a 

software conversion effort is required, the rationale for 

the effort and the propoeed conversion methodology 

should be discussed in a separate section. 

Describe any changes that will be required in the 

organization, the personnel in the organization, or the 

skills of the personnel. 

1.2.5--Feasibility Study 11 
Feasibility Study 

Section 

5.3.4 

5.3.5 

5.3.6 

5.3.7 

Title 

Operational Impacts 

Developmental 

Impacts 

Site Wld Facility 

Impacts 

COBt Impacts 

12 Feasibility Study-1.2.5 

Contont 

Describe how the new system or enhancement will 

affect the operations of the organi!l>ation. Possibilitie~~ 

include automation of mllllual procedures, improved 

access data, and so forth. 

Describe how the development of the new system or 

enhancement will affect the organization. Include 

specific activities to be perlormed and by whcrrn, 

resources that will be required in developmental phaset! 

and in testing the B.YBtem or enhancement, and security 

and privacy considerations. 

Describe any modifications to existing work areas that 

the new system or enhancement will require. 

Describe cost or budget c0l!Siderati011s that could affect 

the development, implementation, or operation of the 

new system or enhancement. 

January 1991 
" 

Feasibility Study 

Section TiUe 

6 Alternative Systems 

January 1991 

Content 

Describe each of the alternative systems or 

enhancements that were considered before selecting the 

final recommendation. If no altemativas were 

considered, explain why. 

Include a separate subsection fur ooch alternative, and 

follow the outline in Section 5. For example: 

6.1 Alternative Syatem 1 

6.1.1 Description 

6.1.2 Improvements 

6.1.3 Impacts 

6.1.3.1 Equipment Impacts 

6.1.3.2 Software Impacts 

6.1.3.3 Organizational Impact& 

6.1.3.4 Operational Impacts 

6.1.3.5 Developmental Impacts 

6.1.3.6 Site/Facility Impact& 

6.1.3.7 Cost Impacts 

6.n Alternative System n 

1.2.5-----Feasibility Study 13 
Feasibility Study 

Section 

7 

Tille 

Rationale for 

Recommendation 

14 Feasibility Study-1.2.5 

Content 

Provide the reasons that support development of the 

new system or enhancement over the alternatives. 

Explain the decision in terms of quantifiable and 

nonquantifiable benefits, requirements and objectives, 

resources required to develop and operate the new 

system or enhancement, possible effects of delay, and 

consequences of not taking action. 

Quantifiable benefits are those which can be described 

in terms of measurea such as dollars, time, and speed. 

Nonquantifiable benefits are those which cannot be 

measured, such as improved service and morale, 

greater efficiency, and enhanced image. 

January 1991 
PROJECT MANAGEMENT PLAN 

(1.2.9 on OSM Documentation Requirements List) 

The Project Management Plan identifies what needs to be done to implement 

a new system or an enhancement to an existing system, when it needs to be 

done, and what it will take to do it. It identifies the approach to managing the 

project, all tasks to be performed, the schedule for completing the tasks, and 

the resources required to complete the tasks. 

The Project Management Plan is intended to be a dynamic document and 

should evolve as the various milestones in the projoct's life cycle are completed. 

Each update should provide greater detail to the current and near-term tasks, 

as well WI any changes in project direction. 

The Project Management Plan defines each taBk in terms of its purpose, 

dependencies, activitiea, staffresponaibilitiea, and anticipated results. Where 

applicable, results are defined in terms of deliverable products with a formal 

review and approval process. Resource requirements are defined in terms of 

equipment and staff (both development and operations). At the project and 

task level, schedules are based on manpower loading and other dependencies. 

Cost estimates should be included for staff and operations throughout the life 

of the proposed new system or enhancement. 

Figure A-7 summarizes the information required in the Project Management Plan by 

presenting the document's table of contents. Detailed explanations of the material that each 

section should contain are then found in the pages that fbllow. 

January 1991 1.2.9--Project Management Plan 1 

FirureA-7 

TABLE OF CONTENTS FOR PROJECT MANAGEMENT PLAN 

(1.2.9 on OSM Documentation Requirements List) 

1. IntroductiOII 

1.1 Background 

1.2 Scope 

1.3 Assumptions and Constraints 

1.4 Summary of the Project Management Plan 

1.4.1 Milestones 

1.5 References 

2. Project Organization B.lld Management 

2.1 Organization 

2.2 Reporting Relationships 

2.3 Unit/Staff Responsibilities 

3. Resources 

3.1 Personnel 

3.1.1 Skill Mix 

3.1.2 Manpower Loading 

3.1.3 In-House/Contractm Support 

3.2 ADP Eqnipment 

3.3 Facilities 

3.4 Other Resources 

4. Project Execution (by Phase) 

4.1 Task Descriptions 

4.2 Task Dependencies 

4.3 Products To Be Delivered 

5. Project Costs (by Phase) 

5.1 Equipment 

5.2 In-House Staff 

5.3 Contractor Staff 

5.4 Operations 

January 1991 1.2.9--PI'(lject Management Plan 3 
Figure A-7 (Continued) 

TABLE OF CONTENTS FOR PROJECT MANAGEMENT PLAN 

(1.2.9 on OSM Documentation Requirements List) 

6. Prqject Execution Feedback 

6.1 Evaluating Project Execution 

6.2 Enbancement Evaluation Plan 

6.3 Configuration Management Transition Plan 

4 Project Mauagement Plan-1.2.9 January 1991 
Project Management Plan 

Section 

1 

1.1 

1.2 

1.3 

1.4 

1.4.1 

1.5 

Title 

Introduction 

Background 

Assumptions and 

Coll8traints 

Summary or the 

Project Management 

Plan 

Milestones 

References 

January 1991 

Content 

Provide appropriate background and eummary 

information. 

Provide a brief overview of the project and why it is 

being conducted. 

Explain why the Project Management Plan is needed, 

provide a brief overview of its organization, and 

indicate syetem-related topics that have been included 

in the document or excluded from coll8ideration. 

Ile$eribe any f~Wtors that may affect the project's 

organization, schedule, and resource requirements WI 

de~~cribed in the Project Management Plan. 

Provide a brief summary of the m011t imJX>rlant 

information in the Project Management Plan. 

List the maJor milestones in the Project Management 

Plan. Present this infurmation in a Gantt chart 

supplemented by text. 

List pertinent standards, iUidance, documentation, and 

any other materials used to prepare the Project 

Management Plan. Include vendor-supplied materials; 

project doeumentation; other in-house documentation; 

and Federal, departmental, agency, and industry 

standards and guidelines. 

1.2.9--Project Management Plan 5 

I 
Project Management Plan 

Section 

2 

2.1 

2.2 

2.3 

Title Content 

Project Organization Describe the project's structure. 

and Management 

Organization Provide a detailed description of the project's 

organization and the management approach that will 

be used. Explain why each was selected. 

Reporting 

Relationships 

UnitJStaff 

Responaibilities 

Define procedures for reporting, monitoring, and 

conb'ol. 

Define respoil!libilities for ell key poaitiollll. 

6 Project Management Plan-1.2.9 January 1991 
" 

Project Management Plan 

Section Title 

3 

Content 

For each of the categories in the subsections listed 

below, identify and describe in detail all re1!0\lrC8!1 

required to complete the project. Indicate sources, 

timing requirements, and any anticipated shortfalls. 

3.1 Personnel 

3.1.1 Skill Mix 

3.1.2 Manpower Loadmg 

3.1.3 In-House/Contractor Support 

3.2 ADP Equipment 

3.3 Facilities 

3.4 Other Resources 

January 1991 1.2.9--Project Management Plan 7 
Project Management Plan 

Section 

4 

4.1 

4.2 

4.3 

Title 

Project Execution 

(by Phase) 

Task Descriptions 

Task Dependencies 

Products To Be 

Delivered 

8 Project Management Plan-1.2.9 

Content 

Describe the key milestones fOl' the project. Include a 

detailed Gantt c:hart or similar graphic description of 

the entire project. 

Provide a detailed work breakdown fOl' eac:h task. If 

automated systems are being used to manage the 

project, system output such as charts and task liats 

may be used if they are detailed enough to be selfexplanatory. Otherwise they should be supplemented 

by additional text. 

Explain how the tasks relate to one another. Explain 

which tasks can be performed concurrently and those 

that cannot begin until another task is completed. 

Explain the effects of delays in completing tasks. 

Based on approved items from the configuration 

identification proceas, describe the products that will 

reault from eac:h task. 

January 1991 
Project Management Plan 

Section 

5 

Title 

Project Costs 

{by Phase) 

Content 

For each of the categories in the subsections listed 

below, provide a summary of costa by pnUect phase. 

5.1 Equipment 

5.2 In-House Staff 

5.3 Contractor Staff 

5.4 Operations 

January 1991 1.2.9---Project Management Plan 9 
Project Management Plan 

Section 

6 

6.1 

6.2 

6.3 

Title 

Project EJr:ecution 

F~dlmcl< 

Evaluating Project 

Execution 

Enhancement 

Evaluation Plan 

Configuration 

Management 

Transition Plan 

Content 

Provide information about activitias to take place after 

the new system or enhancement is operational. 

Describe methods and procedures for evaluating how 

well the plan accomplishes its goals. Consider 

adherence to schedules, effectiveness and availability of 

resources, and user feedback (with respect to the 

quality of products or aceompliahments and the 

effectiveness of project direction. 

Describe methods and procedures for evaluating 

requested enhancements. Include procedures fur 

requests, evaluation, and approval. 

Describe the procedures fur updating the Project 

Management Plan based upon changes to project scope 

or schedule. Include procedures for ongoing plan 

maintenance and procedures for changes reaulting from 

significant project enhancements. Include 

approval/evaluation procedurea and identify anociated 

individuals and I'S$ponsibilities, as appropriate. 

10 Project Management Plan-1.2.9 January 1991 
Content 

QUALITY ASSURANCE PLAN 

(1,2,10 on OSM Documentation Requirements IJB) 

The Quality Assurance Plan provides the standards against which a new 

syt~tem or an enhancement to an existing sYStem will be evaluated It also 

details how these standards are to be implemented and applied both in tha 

SYBtem's development phase and when the system becomes operational. 

Standards are determined through analysis of requirements and applicable 

directives, guidelines, and policy. 

Contractors assisting in development activities must be aware that some 

quality assurance activities (fur example, reviews of deliverables) are the sole 

responsibility of the government while others {such as design reviews and 

walkthroughs) are joint activities. Thus the Quality Assurance Plan needs to 

be prepared in corijunction with the OSM QA staff assigned to the project, and 

it mUBt be approved and incorporated into OSM management activities. 

A preliminary Quality Assurance Plan and schedule of activities is prepared 

during the project initiation phase. It is updated in succeeding phases as more 

infOrmation becomes available. 

The Quality Assurance Plan outlines specific quality assurance activities that 

will verify the integrity of software products during each phase of the life cycle 

of a new system or an enhancement to an existing system. Specific quality 

assurance review activities to be accomplished during the mission analysis, 

system design, system construction and acquisition, and usel" ae<:eptance stages 

of the project are outlined. These include preliminary design reviews, software 

design walkthroughs, final design reviews, and syt~tem plan reviews. Review 

of documentation is also incorporated into the plan. 

The plan also identifies the Quality Assurance Coordinator for the project, as 

well as the ad hoc quality assurance team. The QA team is responsible for 

enauring that the quality assurance activities are accomplished. 

Figure A-8 summarizes the information required in the Quality Assurance Plan by 

presenting the document's table of contents. Detailed explanations of the material that each 

section should contain are then found in the pages that follow. 

January 1991 1.2.10--Qnality Assurance Plan 1 
" 
1. 

2. 

3. 

4. 

FipreA--8 

TABLE OF CONTENTS FOR QUALITY ASSURANCE PLAN 

(1,2,10 on OSM Documentation Requirements Ustl 

Introduction 

1.1 Background 

12 ,.,,, 

1.3 Assumptions and Constraints 

1.4 Summary of the Quality Assurance Plan 

1.5 References 

Quality AssurftllCe Reviews 

2.1 Deliverablea 

2.1.1 Deliverable 1 

2.l.n Deliverable u 

2.2 Milestones 

2.2.1 Milestone 1 

2.2.n Milestone n 

2.3 Structured Walkthroughs 

2.3.1 Structured Walkthrough 1 

2.3.n Structured Walkthrough n 

2.4 Testing 

2.4.1 Unit Tests 

2.4.2 System Tests 

2.4.3 Integration Tests 

2.4.4 Acceptance Tests 

,. Inspections 

2.5.1 Inspection 1 

2.5.n Inspection n 

Quality Assurance Review Schedule 

Summary of Results 

January 1991 1.2.10--Quality Assurance Plan 3 
Quality AssiU'ance Plan 

Section 

1 

1.1 

1.2 

1.3 

1.4 

1.5 

Title 

Introduction 

Background 

Soope 

Assumptions and 

Constraints 

Summary of 

the Quality 

Assurance Plan 

References 

January 1991 

Content 

Provide appropriate background and summary 

information. 

Provide a brief overview of the system development 

project and why it is being conducted. 

Explain why the Quality Assurance Plan is needed, 

provide a brief overview of its organization, and 

indicate system-related topics that have been included 

in the document Ol' excluded from oonsidel'ation. 

Describe any factors that may affect the activitie9 and 

schedules described in the Quality Assurance Plan. 

Provide a brief summary of the most important 

information in the Quality Assurance Plan. 

List pertinent project documentation and any other 

materials used to prepare the Quality AssiU'ance Plan. 

1.2.10----Quality Assurance Plan 5 
Quality Assurance Plan 

Section 

2 

2.1 

22 

2.3 

Title 

Quality Assurance 

Reviews 

Deliverable& 

Milestones 

Structured 

Walkthroughs 

" 

6 Quality Assurance Plan-1.2.10 

Content 

Describe the various quality assurance activities that 

will take place throughout the life cycle of the new 

system or enhancement. 

Describe the stepe W be taken to transmit, review, 

COIIUilent on, and revise all project documentation in a 

separate subooetion for each deliverable. For example: 

2.1.1 Deliverable 1 

2.1.n Deliverable n 

Include the material to be reviewed, the person(s) 

responsible, the anticipated schedule, and evaluation 

criteria. 

Describe the Btep!l to be taken W prepare for, conduct, 

and respond to all milestone reviews in a separate 

subsection for each milestone. For eJI:ample: 

2.2.1 Milestone 1 

2.2.n Milestone n 

Include the person(s) respoil!lible fur conducting the 

review, attendees, materials to be reviewed, material 

that should be read prior to the review, the anticipated 

schedule, 1111d evaluation criteria. 

Describe the steps to be taken to prepare for, conduct, 

and respond to all structured walkthroughs in a 

separate subsection for each walkthrough, For 

a::ample: 

2.3.1 Structured Walkthrough 1 

2.3.n Structured Walkthrough n 

Include the person(s) responsible for conducting the 

review, attendees, materials to be reviewed, material 

that should be read prior to the review, the anticipated 

schedule, and evaluation criteria. 

January 1991 

I 
Quality Assurance Plan 

Section Title 

2.4 Testing 

2.0 

January 1991 

Conlon! 

Because detailed information on testin( activities ie 

provided in other documentation, the Quality 

Assurance Plan needsonlyto identify the teats and the 

anticipated schedules. Include a separate subsection 

for each test. For example: 

2.4.1 Unit Tests 

2.4.2 System Tests 

2.4.3 Integration Tests 

2.4.4 Acceptance Teste 

Identify all the steps involved in conducting and 

responding to quality Wll!urance inspeetiOll.B in a 

separate subsection for each inspection. For example: 

2.5.1 lru!pection 1 

2.5.n Inspection n 

Include the person(s) responsible for the inspection, the 

anticipated schedule, and evaluatiOll criteria. 

1.2.1(}-....Quality Assurance Plan 7 
Quality Assurance Plan 

3 

Title 

Quality Assurance 

Review Schedule 

8 Quality Assurance Phm-1.2.10 

Content 

Provide a complete schedule of all quality assurance 

activities. 

January 1991 
" 

Quality Assurance Plan 

Title 

4 Summary of Results 

January 1991 

Content 

Aa each quality assurance activity is completed, provide 

a summary of the nnults of the test and responsibilitiea 

for any required actions. 

1.2.10--Quality Assurance Plan 9 
Content 

" 

COST/BENEFIT ANALYSIS 

(1.2.11 on OSM Documentation Requirements Li&t) 

OSM managers and the information systems staff use the Cost/Benefit 

Analysis to analyze and evaluate alternative approaches to developini and 

implementing a new system or an enhancement to an existing system. In 

conjunction with the Feasibility Study, it provides information needed to 

ensure that the proper alternative has been selected and that continued 

development of the new system or enhancement is warranted. 

The Cost/Benefit Analysis can be included as B.D. appendix to the Feasibility 

Study or documented sepaxately. It details the costs required to develop and 

operate each alternative as well as the costs of continued operation of the 

existing system. It SUlllmwizes the benefits, both quantifiable and 

nonquantifiable, of each alternative. A comparison of the coats and benefits 

and an analysis of their sensitivity to key factors lead to a recommendation. 

Figure A-9 summarizes the infonnation required in ths Cost/Benefit Analysis by presenting 

the document's table of oon.tents. Detailed explanations of the material that each section 

should contain are then fo=d in the pages that follow. 

January 1991 1.2.11--Cost/Benefit Analysis 1 
·" 
Cost/Benefit Analysis 

Section 

I 

1.1 

1.2 

1.3 

1.4 

1.5 

1.6 

Title 

Introduction 

Background 

Performance and 

Characteristics 

Assumptions and 

Constraints 

Methodology 

Evaluation Criteria 

January 1991 

Content 

Provide appropriate background and summary 

information. 

Provide a brief overview of the project and why it is 

being conducted. 

Explain why the analysis was conducted and provide a 

summary of the document's orgauization. Include a 

brief description of the alternatives that were evaluated 

the m(\jor cost factors that were conaidered, as well a 

system-related topics that were excluded from 

consideration. 

Briefly describe the requirements and objectives fur the 

new system or enhancement. Include operational 

requirements, system life expectancy, and workload. 

Describe any factors that affect the conclusions of the 

analysis. Possibilities include; 

• Operational life of the proposed system 

• Period of time allowed for comparison 

of alternatives 

• Financial constraints 

• Legislative/policy constraints 

• Availability of information and resources. 

Provide a detailed description of how the analysia was 

conducted. Include the techniques uaed to estimate and 

compute costa. 

IdentifY the factors that were used to evaluate the 

alternatives. Possibilities include organizational 

objectives, operational efficiency, and reduced operating 

=~. 

1.2.11--Cost!BenefitAnalysis 5 
Cost/Benefit Analysis 

Section 

1.7 

1.8 

Title 

Summary of 

Recommendatious 

References 

'" 

6 Coat/Benefit Analysill--1.2.11 

Coutent 

Summarize the results of the analyeis, including the 

recommended alternative. The summary can be 

supplemented by a table aa &hown in Figure A-10. 

List pertinent standards, guidance, documentation, and 

any other materials used to prepare the Cost/Benefit 

Analysis. Include vendor-supplied materials: project 

documentation; other in·house documentation; and 

Federal, departmental, agency, and induatry standards 

and guidelines. 

January 1991 
" 

Figure A-10 

COMPARATIVE COST/BENEFIT ANALYSIS SUMMARY 

(Alternatives 1 Through n) 

Comparatln CostJBenefl.t Ana.Jy.IB Summary 

Alternative l Alternative 2 

8jlllt:em Life Coot 

Present Value Cost 

Rosidual Value 

Discounted Ro.sidU<ll 

v•~ 

Ad,jlll!t&d Coot 

System Life &ne:fit 

PreMnt Value Benefit 

Net Present Valllil 

BenefitiCmrt Ratio 

Payback Peri<Jd 

Not:eo: 

Alt.orno.ti\le n 

January 1991 1.2.11-CostiBenefit Analysis 7 
Coatmenefit Analysis 

Section 

2 

Title 

Description of 

Alternatives 

" 

8 COBUBenefit Analysis-1.2.11 

Content 

Provide a brief description of the technical and 

operational characteriatics of the proposed new system 

or enhancement, the alternative.s that were considered, 

and the existing system. If no alternatives were 

considered, explain why. 

The section should be organized with a subsection for 

each alternative. For example: 

2.1 Existing System 

2.2 Proposed System 

2.3 Alternative System 1 

2.n Alternative System n 

January 1991 

I 
" 

Cost/Benefit Analysis 

Section 

3 

3.1 

3.1.1 

3.1.2 

Title 

Costs 

Nonrecurring Costs 

Capital Invea.tmeut 

Other N onreeurring 

Costs 

January 1991 

Content 

Detail the coats of developing and operating each of the 

alternatives. Include the coats of operating the existing 

system. Where applicable, compare the costs of a 

system developed, operated, or maintained in-house 

with those developed, operated, or maintained by 

contractors. 

Formats for a cost analysis and a cost analysis 

workaheet are shown in Figures A-ll and A-12. 

Present the nonrecurring costa for each alternative over 

the life of the system, broken down into capital 

investment and other nonrecurring coats. 

Capital investment includes acquisition, development, 

and installation costs for any of the following: 

o Site and facility 

o Data processing 

o Data communications 

o Environmental conditioning 

o Security and privacy 

o Software 

o Data base. 

Examples of other nonrecurring costs include 

o Requirements and design studies 

o Procurement activities 

o Data base preparation 

o Software conversion 

o Reviews and testing 

o Technical/management overhead 

o Personnel (training and travel, but not salary 

and benefits) 

o Involuntary retirement, severance, relocation, etc. 

o Contractual, interagency, or other direct 

support services 

o Incremental or additional overhead costs. 

1.2.11-CostJBenefit Analysis 9 

• 
No!ll'l!<urring Casto: 

Capital: 

Site/Facility Equipl!li!nt 

AD>'E 

Thieoommunioationo 

Softw....., ""~ 

""""" Studio• 

-"' 

Conversion/Parallel 

OperatiOJll! 

Trainin~vel 

Recurring Cost.: 

Equipment 

.... ~ 

Data Communi<atione 

""'""'"' 

Support &rvi.oe• 

Tra""l and Training 

Space Occupancy 

Supplies and Utilitieo 

Security and Privacy 

Semcoo 

"-""' 

" 

Figu.re A-ll 

COST ANALYSIS (Alternative x) 

10 Cost/Benefit Analysis--1.2.11 January 1991 
" 

~ 

~ 

• ] . 

d ~ • 

~ 

~ 

! 

~ • 

~ ~ ~ 

' IJ ~ 

! ~ " I ! 1 ' 

1 • • s 

ii ] 

I ' ~~ ' 

f 0 

~ 

~ " ~ l ~ ~ 1 ~ 0 • 0 

~ ' 

• 

•• 

0. 

~~ 

l il 

j .,~ ~ 

~ .~ .s ~ I I I ·B .! ~ 

l z ·~ 
CosUBenefit Analysis 

Section Title 

32 Recurring Costa 

12 CosUBenefit Analysis-1.2.11 

Content 

Present the monthly and/or quarterly recurring rost.s of 

operating and maintaining each alternative over the 

life of the system. Include the following; 

• Equipment lease, rental, and in-house maintenance 

• Software liiB.f!e, rental, and in-house maintenance 

• Data oommunicatio011lease, rental, and in-house 

maintenance 

• Personnel salaries and benefits 

• Direct support servictlll (intra-agency servictlll) 

• Travel and training 

• Space occupancy 

• Supplies and utilities 

• Security and privacy 

• Contractual and interagency services (for e:>~:ample, 

ADP services, data oomrnunications, software, 

technical support, other support) 

• Overhead that represents additional or incremental 

expenses attributable to the alternative. 

January 1991 
Cost/Benefit Analysis 

s""""' 

4 

4.1 

4.1.1 

4.1.2 

4.1.3 

TiUe 

Benefits 

Nonrecurring 

Benefits 

Cost Reduction 

Value Enhancement 

Other Nonrecurring 

""""'" 

January 1991 

Content 

Describe the benefits that can be attained by 

developing and implementing each alternative, in terms 

of quantifiable (recurring and nonrecurring) and 

nonquantifiable benefits that relate to organizational 

objectives, goals, missions, functions, and operating 

environments. 

Formats for a benefits analysis and a benefits analysis 

worksheet are shown in Figures A-13 and 

A-14. 

Present the nonrecurring benefits in tel"ll18 of data 

procesaing, users, administration, and support, broken 

down into three categories. 

Include cost reductions that are a result of improved 

system operations. Possibilities include: 

• Reduced resource requirements 

• Improved operating efficiency 

• Improved entry, storage, and retrieval of data 

• System performance monitoring 

• Software conversion or optimizati001 

• Data compression techniques 

• Centralized or decentralized processing. 

Include benefits that enhance the value of the syelem. 

Possibilities include: 

• Improved use of resourceB 

• More effective operations and administrati001 

• Fewer errors 

Include any additional benefits. Possibilities include: 

• Offsetting receipts 

• Costs avoided 

• Value of excess equipment. 

1.2.11......Cost1Bene.fit Analysis 13 
NOII!"~Cuning Benefits: 

-~ Cast Reduction 

Value Enhancement 

-

(Including Cast AV<lidance) 

Recuning Bonl!fits:: 

Cost Reduct:ion: 

Equipment 

.,._ 

Data Cammunkalions 

Perocmnel 

Support Serv:!Cf!e 

TraVIll and Training 

Spac& Oooupancy 

Suppl!0<1 and Utilitieo 

Security and Privacy 

Services 

Overhl!ad 

""'" 

(Including Coot Avoidance) 

Subtotal 

~t Value Coot 

" 

FfMure A-13 

BENEFIT ANALYSIS (Altentative :~:) 

y...,. (I Year 1 y....,. 2 Year 3 YOB>" 4 Yaar 5 

14 Cost/Benefit Analysis---1.2.11 January 1991 
" 

• 

" 

• ]• 

~i 

l 

] 

~ 

~ 

.. ~ ~ ~ " 

" " ~ ~ " 

~ 

~ 

• • 

1 

J ] 

• ~~ j <; • j~ ! 

~ 

~ 

00 1 

I • ! 

.! j 

i: .. •• 

• ~ 

~ ~ ' 

' 

h 

i ·•J 

} I I ' 

• '" 1 ~~ • ~ ~ ~ " 

~~ • 

I • 

r " 

I l 

-

- ·• ~ 

l 1 ?~ 

z ~ i • ~ 
Cost/Benefit Analysis 

Section 

4.2 

4.3 

Tltlo 

Recurring Benefits 

Nonquantifiable 

Benefits 

" 

16 CosUBenefit Analysis-1.2.11 

Content 

Preaent the monthly and/or quarterly recurring benefits 

of operating and maintaining each alternative over the 

lite of the sysUlm. Include the following: 

• Equipment lease, rental, and in-house maintenance 

• Software lease, rental, and in-house maintenance 

• Data communications lease, rental, and in-house 

maintenance 

• Personnel salaries and benefits 

• Direct support services (intra-agency services) 

• Travel and training 

• Space occupancy 

• Supplies and utilities 

• Security and privacy 

• Contractual and interagency services (for example, 

ADP services, data communications, software, 

technical support, other support 

• Overhead that represents additional or incremental 

expellBeS attributable to ths alternative 

• Coate avoided through impl'(lvements in operational 

flexibility, information handling, and response to 

requirements. 

Describe benefits which cannot be quantified in terms 

of diNct dollar values. Possibilities include; 

• Improved service 

• Reduced risk of error 

• Improved information handling 

• Enhanced organizational image. 

Intangible benefits can sometimes be assigned values 

in terms of estimates and tradeoft's. Ifposaible, include 

boundary (best case and worst case) estimates to justify 

the alternative or cite tradtloffs where intangible 

benefits are gained at the expense of reduced potential 

for tangible benefita. 

January 1991 
Cost/Benefit Analysjs 

5 

5.1 

Title 

Comparative 

Cost/Benefit 

Summary 

Sensitivity 

Coosideratimu! 

January 1991 

·" 

Content 

Based oo the data presented in Sectioll8 3 and 4, 

compare the costs and benefits of each alternative. 

Provide supporting documentation Wi required for 

validation and management review. 

A format and ill8trnctioos for preparing a cost/benefit 

summary can be found in Figure A-Ui. 

Sensitivity analysill is a tool used to a.saeaa the extent 

to which costs and benefits can be affected by factors 

such as 

• Length of system life, either shorter or longer 

• Varia.tioll8 in the estimated volume, mix, or pattern 

of workload 

• Changss in requirements resulting from either 

legislative mandate or changes in functional or 

organizational structure 

• Changes in the configuration of hardware, software, 

data communicatiol1ll, or other facilities 

• Changes in objectives, requirements, or operatio!1ll 

• Changes in inflation rate or residual value of 

equipment, facilities, and software 

• Delays in completion of the project. 

Conducted on different configurations of the 

alternatives, the sensitivity analysis provides a range 

of costs and benefits that are likely to be a better guide 

than a single estimate. 

Explain the approach used to conduct the slllll!itivity 

analysis and explain the factors used and how they 

ware selected. Present the results in a table as shown 

in Figure A-16, then conclude with a summary of key 

points and an evaluation of the validity and 

implicationa of the analysis. 

1.2.11-Cost/Benefit Analys:i!l 17 
·" 

Figure A-Hi 

COST/BENEFIT ANALYSIS OVER SYSTEM LIFE (Altel'Jllltive x:) 

'llomaining """"""""" voluo of ownorob!p of 1\DP ~ !n tho laol month of oyl!loml!f<>, 

'DUI'o1'0""" bo-on preoo.nt voluo mot ""d di11001>olod I'Oo!dual value in \he lul ""'""' of oyote.m IU'o. 

'Point ot whloh total henofilo e=oed total mot., exclu.dlng pmoont 'fllluoo. 

18 Cost.IBenefit Analysis-1.2.11 January 1991 

I 
Alternative 1 

(name) 

Alternative 2 

(nmn&) 

AlternativeS 

(name) 

AlternatiVJO n ,_, 

January 1991 

Figure A-16 

SENSITIVITY ANALYSIS 

(Alternatives 1 Throul(h n, Factors 1 Through n) 

Comp,.....live Coot!Bmuotit Summaey 

Factor 2, 

Factor 1, Volume 

U"""'l Llle of Work 

Rang..: Range: 

3, 5, 7 Yearo 3, 5, 7 Years 

Facto-r __ n, ,

Range: 

,_, 

1.2.1l-C011t.IBenefitAualysis 19 
Cost/Benefit Analysis 

Section Title 

6 Recommendation 

20 Cost/Benefit Analysis--1.2.11 

Content 

Select the most deairable alternative in terms of costs 

and benefits and justify the selection. 

January 1991 
Content 

DETAILED FUNCTIONAL REQUIREMENTS 

(2.1.2 on OSM Documentation Requirement& List) 

The Detailed Functional Requirements document provides e beeia of 

understanding ee to the function(a) to be perfOrmed by a new system or an 

enhancement to an existing system; specific hardware/software and 

performance requirements fur the new system or enhancement; and additional 

C<:lnsiderations related to the operating environment of the new system or 

enhanooment (interfaces, facilities, personnel, security, etc.). It is wmally 

developed after an analysis of existing procedures and the needs ofproopectiw 

-~. 

The Detailed Functional Requirements document describes the existing system 

and the deficiencie.s and limitations that led to the request for a new system 

or enhancement. It explains what the use:rs require of the new system or 

enhancement from their perspective; thus it contains quantitative processing 

requirements in terms of work and data flow and deadlines and constraints. 

Interlaces with other systems, security and privacy, and audits and ooutrols 

are also described. 

Figure A-17 s\l1tl.l:IUirlze the infurnultion required in the Detailed Functional Requirements 

by preaenting the document's table of contents. Detailed explanations of the material that 

each sectitm should ooutain are then presented in the pages that follow. 

January 1991 2.1.2--Detailed Functional Requirements 1 
FigureA-17 

TABLE OF CONTENTS FOR DETAILED FUNCTIONAL REQUIREMENTS 

(2..1.2 on OSM Documentation Requirements List) 

1. Introduction 

1.1 Background 

1.2 Scope 

1.3 Methodology 

1.4 Allsumptions and Constraints 

1.5 Summary of the Detailed Functional Requirements 

1.6 References 

2. Overview of Existing Methods and Procedures 

2.1 Orgsnization!Pel"BOD.Ilel 

2.2 Equipment 

2.3 Inputs and Outputs 

2.4 Deficiencies and Limitations 

2.5 Pertinent Cost Considerations 

3. Requirements 

3.1 Overview of Functions 

3.2 Relationships Among FWlctions 

3.3 Funetional Requirements 

3.3.1 Function 1 

3.3.n FWlction n 

4. External Considerations 

4.1 Organization/Personnel 

4.2 Design Staudards and Constraints 

4.2.1 Facilities 

4.2.2 Hardware 

4.2.3 Software 

4.3 Interface Requirements 

4.3.1 Internal 

4.3.2 External 

4.4 Audits and Controls 

4.5 Security and Privacy 

4.6 Cost 

January 1991 2.1.2--Detailed Functional Requirements 3 
" 

FilfUI'e A-17 (Continued) 

TABLE OF CONTENTS FOR DETAILED FUNCTIONAL REQUIREMENTS 

(2.1,2 on OSM Documentation Requirements Ust) 

5. Improvements and Impacts 

5.1 Improvements 

5.2 Impacts 

4 Detailed Fuuctional Requirements-2.1.2 January 1991 

'7 
" 

Detailed Functioual Requirements 

Section 

1 

1.2 

1.3 

1.4 

1.5 

1.6 

Title 

Jutroduction 

""'' 

Methodology 

Assumptions and 

Constraints 

Summary of the 

Detailed Fnnctioual 

Requirements 

January 1991 

Content 

Provide appropriate background and summary 

information. 

Provide a brief overview of the system. development 

project and why it is being conducted. 

Explain why the Functional Requirflments document is 

needed, provide a brief overview of its organization, and 

indicate system-related topics that have been included 

in the document or excluded from consideration. 

Provide a detailed description of how the functional 

requirements analysis was conducted. 

Describe any factors that may aifect the requirements 

diseuased in the document. 

Provide a brief summary of the most important 

information in the document. 

List pertinent standards, guidance, documentation, and 

any other materia18 used to prepare the document. 

Include vendor-supplied materials; project 

documentation; other in-hoUl!e documentation; and 

Federal, departmental, ag~~ncy, and industry standards 

and guidelines. 

2.1.2-Detailed Functional Requirements 5 
.. IL 

Detailed Functional Requirements 

Section 

2 

2.1 

2.2 

2.3 

2.4 

2 .• 

Title 

Overview of 

Existing Methods 

and Procedures 

Organization! 

PersOllllel 

Equipment 

Inputs and 

Outputs 

Deficiencies 

and Limitations 

Pertinent Cost 

Considerations 

Content 

Describe the system that ia to be replaced flr enhanced. 

Illustrate the data flow from. data acquisition through 

proca81iing and output and include interfaces with other 

syatems. Explain how users perform operational 

functions. 

Describe the organi~ation and responsibilities of the 

people who work with the existing sysWm.. 

Describe all hardware used with the existing system. 

Explain the type of data Ulied aa input to Wld the data 

output from the existing system. Include the media 

(diskette, tape, etc.), format, range of values, accuracy, 

volume and frequency, and other pertinent infOrmation. 

Describe and show examples of any hard·copy reports 

flr graphics. 

Explain the deficiencies and limitations that have led 

to the proposed new syatem or enhancement. 

Provide an overview of the cost of operating the 

existing system. 

6 Detailed Functional Requirements-2.1.2 January 1991 
" 

Detailed FunctiOI18l Requirements 

Section 

3 

3.1 

3.2 

3.3 

Title 

Requll'ements 

Overview of 

F=ctions 

Relationships 

Among Functions 

Functional 

Requirements 

January 1991 

Content 

Describe the requirements for the new system or 

enhancement. 

Describe the new system or enhancement, including an 

overview of the information processing requirements, 

performance requirements, inputs, and outputs of each 

m~or function. Identify techniques and procedures 

that will be incorporated from other systems or 

applications. 

Describe the structure of the new system or 

enhancement and the relationships between each m!ijoc 

function. This section should combine hierarchy charts 

with text. 

Describe in detail the functional and performance 

requirements fur each major function to be supported 

by the new system or enhancement. 

Inclu<le a separate subsection for each major function. 

For example: 

8.3.1 Function 1 

3.3.n Function n 

Describe functiOJls in quantitative and qualitative 

terms. Describe how they satisfy performance 

objectives. 

Describe performance requirements in terms of the 

followini criteria: 

• Aorurncy - Describe data accuracy, including 

mathematical, logical, legal, and tranl!mission 

requirements. 

• Validation- Describe data validation requirements. 

• Timing- Describe timing requirements for system 

responae, update processing, data transfer and 

transmission, and throughput. 

2.1.2-Detailed Functional Requirements 7 
Detailed Functional Requirements 

Section Title Content 

• Flexibility - Describe the new system or 

enh!lllcement's capability for adapting to changes in 

requirements such as modes of operation, operating 

environment, interfacea with other systems and 

applicatiolll!, aocuracy and validation timing, and 

planned changes or improvements. 

Describe and show examples of data input. Specify the 

media, format, range of values, accuracy, etc. 

Describe and show examples of data output. 

Describe the eharaeteristics of individual and composite 

data elements. 

DiscuBs size and scheduling considerations. 

Specify possible failures, the colll!equences, and actions 

that can minimize impact. Include baclrup, fallback, 

and recovery capabilities. 

U11e visual representations of data flow where 

appropriate. 

8 Detailed Functional Requirements-2.1.2 January 1991 
Detailed Functional Requirements 

4 

4.1 

4.2 

4.2.1 

4.2.2 

4.2.3 

Title 

E""""'" Considerations 

Organi~ation/ 

P~rmru 

Design Standard!~ 

and COIU!traints 

Facilities 

Software 

January 1991 

Content 

Describe the operating environment of the new system 

or enhancement. Include any constraints imposed by 

the operating envirorunent. 

Describe the organization and responsibilities of the 

people who will work with the new system or 

enhancement. 

Describe facility, equipment, and support software 

requirements. Include constraints that any of these 

may impose. 

Describe the facilities required for the new system or 

enhancement. Include WlY new facilities required Wld 

relate them to specific functions or requirements. 

Identify the equipment required for the new system or 

enhancement. Include any new equipment required 

and relate it to specific functiOIU! 01' requirements. At 

a minimum, the following should be diseussed; 

• Processor and size of internal storage 

• Online and offiine storage, including media, format, 

and devices 

• Input and output devices, online and ofiline 

• Data communications and transmission devices. 

Identify the support software and describe any test or 

commercial software that will be used with the new 

system or enhancement. If the operation of the 

software depends on changes to exiating support 

software, identify the nature of these changes and when 

they will take effect, end relate the changes to specific 

functions or requirements. 

2.1.2-Det.ailed Functional Requirements 9 
" 

Detailed Functional Requirements 

Secti= 

4.3 

4.5 

4.6 

Title 

Interface 

Requirements 

Audits and 

Controls 

Security and 

Privacy 

C~t 

Content 

Describe interfaces with other systems and software. 

Include a separate subsection for internal and external 

interfaces: 

4.3.1 Internal- Interfaces between functions 

4.3.2 External- Interfaces between syateDll! 

Describe operational audits and controls imposed on the 

new system or enhancement. Identify the sources of 

these controls. 

Describe the overalllll!curity and privacy requirements 

for the new system or enhancement. 

Provide an overview of the cost of operating the new 

system or enhancement. 

10 Detailed Functional Requirements--2.1.2 January 1991 
Detailed Functional Requirements 

Section 

5 

5.1 

5.2 

Title 

Improvements 

and Impacts 

Improvements 

January 1991 

Content 

Summarize the improvements to be obtained and the 

anticipated impact of the new system or enhancement. 

Dea.crihe new capabilities, upgraded capabilities, 

deficiencies eliminated, improved response time and 

processing time, and capabilities eliminated or reduced 

Describe impacts as they n~late to the following; 

• Equipment - Changes to current equipment, new 

equipment, building requirements 

• Software - Additions or modifications required for 

exiating applications or support eoftware 

• Organization - Reorganization of functions and 

responsibilities, increase or decrease in staff level, 

upgrade or downgrade of staff skills 

• Operations 

- Staff and operations procedures 

- Relationship between operatiOlls center and 

~~ 

- OperatiOlls center procedures 

- Data SOUl'Ce& and media; volume and time 

considerations 

- Data retention and retrieval procedures 

- Reporting methods 

- Consequences of system failure; recovery 

procedures 

- Computer procea.sing time requhements 

• Development 

- Specific activities to be conducted by users in 

support of the development activity 

- Resources required to develop the data base 

- Computer processing resources required to 

develop and test the new system or 

enhancement. 

2.1.2--Detailed Functional Requirements 11 
Content 

DATA REQUIREMENTS 

(2.1.3 on OSM Documentation Requirements List) 

The Data Requirements document provides a description of and technical 

information about the data base used by a new system or an enhancement to 

an existing system. It is used during the analysis stage of a software 

development project as a starti.ng point in determining how the data base 

should be structured and how it will be used. 

The Data Requirements document COlltains detailed information about data 

relationships, the system environment, security, data volume considerations, 

and expected usage patterns. • 

Figure A-18 summarizes the information required in the Data Requirements by presenting 

the docum.enfs table of contents. Detailed explanations of the material that each section 

should contain are then found in the pages that follow. 

January 1991 2.1.3--Data Requirements 1 
Figure A-18 

TABLE OF CONTENTS FOR DATA REQUIREMENTS 

(2.1.3 on OSM Doewnentation Requirements List) 

1. Introduction 

1.1 Background 

1.2 Scope 

1.3 Assumptions and Constraints 

1.4 Summary of the Data Requirements 

1.5 References 

2. Logical Data Model 

2.1 Entity Relationships 

2.2 Data Definitions 

2.2.1 Entity Relationships 

2.2.2 Entity Attribute Lists 

2.2.3 Attribute Descriptions 

2.2.4 Other Definitions 

3. Environment 

4. Data Se<:Urity Requirements 

5. Data Volume aud Usage Patterns 

January 1991 2.1.3---Data Requirements 3 
" 

Data Requirements 

Section 

1 

1.1 

1.2 

1.3 

1.4 

1.5 

Title 

Introduction 

Background 

8001>' 

Assumptions and 

Constraint& 

Summary of the 

Data Requirement& 

Document 

References 

January 1991 

Content 

Provide appropriate background information. 

Provide a brief overview of the new system or 

enhana~ment and why it is being implemented. 

Explain why the Data Requirements document is 

needed, provide a brief overview ofits organization, and 

indicate system-related topics that have been included 

in the document or excluded from consideration. 

Describe factors which may impact the accuracy or 

applicability of the Data Requirements document. 

Summarize the most significant information included in 

the Data Requirements document. 

List pertinent standards, guidance, documentation, and 

any other materials used W prepare the Data 

Requirements document. Include vendor-supplied 

materialB~ projoct documentation~ other in-house 

documentation; and Federal, departmental, agency, and 

industry standards and guidance. 

2.1.3--Data Requirements 5 
Data Requirements 

Section 

2 

2.1 

2.2 

2.2.1 

2.2.2 

2.2.3 

2.2.4 

Title Content 

Logical Data Model Provide a detailed description of the logical data model. 

Entity Relationships Include diagrams and/or descriptions which identify 

logical data groups (entities) and the relatiOD!ihips 

among the groups (that is, entity-relationship 

diagrams). 

Data Definitions 

Entity Definitions 

Entity Attrib-ute 

"'" 

Attrib-ute 

Descriptions 

Other Definitions 

Provide a detailed description of the data. Include, or 

provide reference to, the Data Dictionary. 

Define and describe the logical data groups. 

List the attributes (data elements) 11880ciated with each 

entity or logical data group. For each entity, identify 

candidate keys and the relationship of the attribute to 

the entity (for example, each Permit entity hllB one and 

only one Permit Number; each Violation entity haa zero 

or one Abatement-Date attribute). 

Describe each attribute and identify characteristics 

(type, length, allowable range, critical values, scale of 

me!lBurement, conversion factors). 

Depending upon the methodology used, other 

definitions may be required; for example, data flow 

definitions, report definitions, input document 

defmitions, data store definitions, and businesa 

function/entity relationships. 

6 Data Requirements--2.1.3 January 1991 
Data Requirements 

Section Title 

3 Environment 

January 1991 

Content 

Describe the operating environment of data base, if 

known. Include any pertinent iD.fonnation that may 

affect the operating environment; fOl' example, 

hardware, sof\ware, data collection procedures, timing 

fOl' required reports, backup requirements, ete. 

2.1.3--Data Requirements 7 
Data Requirements 

Section 

4 

Title 

Data Security 

Requirements 

8 Data Requirem.ents-2.1.3 

Content 

Identify security and privacy requirements. Highlight 

any vulnerabilities or other considerations and identify 

particularly sensitive information and required Privacy 

Act precautions. 

January 1991 
Data Requirements 

Section 

5 

Title 

Data Volume and 

Usage Patterns 

January 1991 

Content 

Provide data volume estimates and aeeociated backup 

volume estimates (both aasumptions and ealculations). 

Identify transaction frequencies and data update 

authorities. 

2.1.3--Data Requirements 9 
UNIT TEST PLAN 

(2,3.1.1 on OSM Documentation Requirements List) 

Unit, or module, testing is the proce88 of testing the individual subroutines, 

routines, or procedures that make up a laxger program. It is aimed at the 

smallest component of the software product so that a "building block" approach 

can be used in developing a new system or an enhancement to an existing 

system. 

Because it OCCU!"B first in the overall process of testing, unit testing is critical 

in terms of detecting errors. When designing test cases for a unit test, the 

specification for the module, which describes its input and output param.etera 

and its processing logic, must be taken into oonsideratioo. It is also necessary 

to have the source code. 

Unit testing is centered on techniques that will unoovererrors in the program's 

logic. This testing quickly becomes more difficult as the size of the test 

increases; therefore, unit testing provides the best opportunity to focus on the 

program's internal validity and efficiency. 

The Unit Test Plan must be reviewed and approved before the actual testing 

can begin. 

Content Because the development of each system is unique, the outline of the Unit Test 

Plan should be customized to reflect the components of the specific entities 

being tested. It should contain detailed testing procedures for each unit or 

module, as well as a propo11ed schedule for each test. Each test plan should 

contain as Section 1 an overview that provides background infonnatioo, the 

scope of the plan, any assumptions or constraints tha£ affected test plan 

development, a brief summary of the proposed testing, and applicable 

references. 

January 1991 2.3.1.1-Unit Test Plan 1 
" 

INTEGRATION TEST PLAN 

(2.3.1.2 on 0SM Documentation Requirements I..blt) 

Purpotie The purpose of integration testing is to ensure that all related units or modules 

in a new system or an enhancement to an exiating system work together as 

specified in development plans. Testing in this area is aimed at data 

compatibility, module interlace problems, and functional performance 

requirements. Its scope includes all programs thatwmprise a discrete function 

within the new system or enhancement. Normally, integration teating is 

conducted in an incremented manner. 

Content The Integration Test Plan expands upon the Unit Test Plan in defining testing 

procedures for the system. Because the development of each system is unique, 

its outline should be customi.red to reflect the components of the specific 

entities being tested. It should contain detBi.J.ed testing procedures for each 

unit or module, as well as a propoaed schedule fDl' each test. Each test plan 

should contain as Section 1 an overview that provides background information, 

the scope of the plan, any assumptions or constraints that affected test plan 

development, an explanation of how the intep-ation testing builds on the unit 

testing, a brief summary of the proposed testing, and applicable references. 

January 1991 2.3.1.2--lntegration Test Plan 1 
Purpose 

Contomt 

" 

SYSI'EM TEST PLAN 

(2.3.1.3 on OSM Doemnentation Requirements List) 

The System Test is actually a final integration test, ensuring that a new 

sysWm or an enhancement to an existing sysWm meets the requirements 

stated at the beginning of the development process. It will prove that all of the 

components of the new system or enhancement work together and work 

properly, and it provides a way to evaluate system performance and 

documentation and to ensure that both are up to standard. 

The System Test Plan describes a methodology for ensuring that the system 

is incrementally tested and that the tests to be conducted will completely 

exercise all system functions against all stated requirements. It alerts 

managers to the test schedule as well as staff time and other resources the test 

will require, provides detailed descriptions and procedures for each test, 

provides evaluation criteria, and describes how results will be recorded. When 

the plan is implemented, the recorded results should be documented in 

working papers. 

Figure A-19 summarizes the information required in the System Test Plan by presenting the 

document's table of contents. Detailed explanations of the material that each section should 

contain are then found in the pages that follow. 

January 1991 2.3.1.3-System Test Plan 1 

1. 

2. 

3. 

4. 

5. 

6. 

" 

Figure A-19 

TABLE OF CONTENTS FOR SYSTEM TEST PLAN 

{2,3.1.3 on OSM Documentation Requirements List) 

Introduction 

1.1 BackgroWld 

1.2 Sropo 

1.3 Assumptions and Constraints 

1.4 Summary of the System Test Plan 

1.5 References 

System Test Requirements 

2.1 &hedule 

2.2 Personnel 

2.3 Training 

2.4 Computer Resources 

2.5 Test Materials 

2.6 Facilities 

System Test Specifications 

3.1 Scope of Testing 

3.2 Perfoi'Illance Requirements 

3.3 Tests To Be Conducted 

3.4 Methodology 

3.5 Constraints 

System Test Descriptions 

4.1 Test Package 1 

4.1.1 Objectives 

4.1.2 Description 

4.1.3 Controls 

4.n Test Package n 

System Test Procedures 

5.1 Test Package 1 

5.n Test Package n 

Evaluation Criteria 

January 1991 2.3.1.3--System Test Plan 3 
System Test Plan 

Section 

1 

1.1 

1.2 

1.3 

1.4 

1.5 

Title 

Introduction 

Backgrowtd 

Soope 

Assumptious aud 

Constraints 

Summary of 

the System 

Test Plan 

References 

January 1991 

" 

Content 

Provide appropriate background and summary 

information. 

Provide a brief overview of the system development 

project and why it is being conducted 

Explain why the System Test Plan is needed, provide 

a brief overview of its organization, and indicate 

sy~~tem-related topics that have been included in the 

document or excluded from consideration. 

Describe any factors that may affect the test 

requirements, specifications, and plii.D.l! described in the 

System Test Plan. 

Provide a brief summary of the most important 

information in the System Test Plan. 

List pertinent etau.d.ard&, guidance, documentation, and 

any other materials used to prepare the System Test 

Plan. Include vendor-supplied materials; project 

documentation; other in-house documentation; and 

Federal, departmental, agency, and industry standards 

and guidan«!. 

2.3.1.3--System Test Plan 5 
System Test Plan 

Section 

2 

2.1 

2.2 

2.3 

2.4 

2.5 

2.6 

Title 

System Test 

Requiremente 

Schedule 

Personnel 

Training 

Computer 

... ~ 

Test Materials 

Facilities 

6 System Test Plan-2.3.1.3 

Content 

Provide system teat logistics information and 

requiremente. 

Describe each system test milestone. Include the 

location(s), participating orgllllization(s), and a 

tentative schedule that includes time to become 

familiar with the system and for training, test setup, 

distribution of materials, and so forth. 

ldentifystaffrequiremente for the system test. Include 

names or functions and amount of time needed. 

Describe respon.sibilities of government and contractor 

personnel, and those of developer and user personuel. 

Include special requiremente such as multishift 

operation aD.d key personnel. 

Describe the type of training that will be required 

before the system test can be conducted. Include 

personnel and computer or other resources required as 

well as the names or functions of the training staff and 

the personnel to be trained. 

Describe the computer resOlll"t'es that will be needed for 

the system test. Include terminals, modems, telephone 

lines, software, and so forth. 

List materials needed for the test; for example, 

documentation, software (aD.d on what media), test 

inpute and sample output, test control software, and 

worksheete. 

Describe the location of the system test and any 

materials (furniture, audiovisual equipment, office 

supplies, and so forth) needed at that site. 

January 1991 
System Test Plan 

Section 

3 

3.1 

3.2 

3.3 

3.4 

TiUe 

System Test 

Specifications 

Scope of Testing 

p,_ 

Requiremente 

Teats To Be 

Cnnd.-d 

Methodology 

January 1991 

Conlon! 

Provide general information about the syatem test. 

Explain the objectives of the teet. List the functional 

requirem!lllts. Describe the software modules and 

hardware, detailed application functions, system and 

support software, manual processes, and any other 

components of the system to be te&ted. 

Deeeribe the expected resulte of the system test as 

related to each item to be te&ted (described in the 

previous subsection). 

Identify the different kinds of teBts that will be used; 

for example, functionality, workload perfonnanee, stress 

performance, and support materials (training, 

documentation). Other types or different groupings of 

test!! may be appropriate for a specific system. 

Deeeribe the general order in which the teste will be 

conducted, the progression from one test to another, 

which tests depend upon the successful outcome of prior 

tests, and the procedures for re-testing in the event a 

test fails. 

Deeeribe the general method or strategy of the testing. 

Describe how development of test packages will be 

controlled. Describe the methodology for developing the 

test packages, associated input data, and {if used) the 

test data base. Specify the type of input to be used 

{live or test) as well as its volume and frequency. 

Indicate the extent of the testing and include the 

rationale for partial testing. Discuss the method to be 

used for recording test results and other information 

about the testing, for effecting appropriate system 

changes determined to be necessary as a result of the 

testing, and for determining that test results are 

satisfactory. 

2.3.1.3---System Test Plan 7 
System Test Plan 

Section Tille 

3.5 Constraints 

8 System Test Plan--2.3.1.3 

Conteut 

Indicate any anticipated limitatiOW! on the test that 

may result from conditions such as interfaces, 

equipment, personnel, and data. 

January 1991 
System Teat Plan 

Section 

4 

4.1.1 

4.1.2 

4.1.3 

Title 

System Test 

DescriptioilB 

Objectives 

Description 

Controls 

January 1991 

Content 

Provide a detailed explanation of the individual tests 

involved in the HYBtem test. Include a separate 

subsectioo for each test. For euunple; 

4.1 Test Package 1 

4.n Test Package n 

Include the following informatioo far each test. 

Describe the objective(s) of the test and ita relationship 

to specific BYBtem functioilB. 

Describe the test. Include preparatiOII, input, 

proceBI!ing, output, and recording of results. 

Describe the test control {for example, manual, semiautomatic, or automatic). 

2.3.1.3---System Test Plan 9 
System Test Plan 

Section 

5 

Title 

SyBtem Test 

ProcedUl'eB 

10 System Test Plan~2.3.1.3 

Content 

Provide step-by-step procedures fill' conducting each 

test. Include a separate subsection £01' each teat. Fill' 

example: 

5.1 Test Package 1 

5.n Test Package n 

January 1991 
System Test Plan 

SeetiQll 

6 

Title 

Evaluation 

Criteria 

January 1991 

C011tent 

Describe the criteria to be Ulled to evaluate the results 

of the system test. Include information on pa1111, fail, 

and restart thresholds. 

Describe the methods to be used to summarize the 

results (summary statistics, graphs, charts, and so 

forth). 

Describe ths procedures that will be used to record the 

progress and results of the test, to report failure, and to 

prepare a final test report. 

IdentifY the person(s) responsible and the procedures to 

be followed for approving the test results. 

2.3.1.3-System Test Plan 11 
Purpose 

Content 

ACCEPI'ANCE TEST PLAN 

(2.3.1.4 on OSM Documentation Requirements List) 

The Acceptnnce Test detennines whether a new system or an enhsncement to 

an existing system is ready for operational use. It is the final measure of 

whether the new system or enhancement performs according to the 

requirements and specifications stated at the beginning of the development 

process. 

The Acceptance Test Plan establishes criteria to use in determining whether 

the new system or enhancement will be accepted by the user. It defines the 

nature and scope of the testing activity, identifies the testing methodology, 

outlines organizational requirements and responsibilities for conducting the 

test, and addresses recording and evaluation of test results. When the plan is 

implemented, results shonld be documented in working papers. 

The test methodology identifies specific functions and proc(!$$(!8 that need to 

be tested and describes the specific test case& that will be used to thoroughly 

verify and validate those functions and processes. Depending on the situation, 

multiple te~>t cases may be required to verify a single function or process, or a 

single test case can verilY multiple functions and processes. To expedite 

acceptance testing, the test cases are grouped into packages. Each package 

should contain forms that summarize the test steps and provide space to record 

results. 

Before acceptance testing can be completed, the test results should be 

compared with predetermined or "expected~ results. The expscted results for 

each test case should be determined when the test data is encoded. 

Figure A-20 summarizes the infOrmation required in the Acceptance Test Plan by presenting 

the document's table of contents. Detailed explanations of the material that each section 

should contain are then found in the pages that follow. 

January 1991 2.3.1.4-Acceptance Test Plan 1 

Figure A-20 

TABLE OF CONTENTS FOR ACCEPTANCE TEST PLAN 

(l!.a.1.4 on OSM Documentation Requirements List) 

1. Introduction 

1.1 Background 

1.2 Scope 

1.3 Assumptions and Constraints 

1.4 Summary of the Acceptance Test Plan 

1.5 References 

2. Acceptance Test Overview 

2.1 System Inputs, Processing, and Outputs 

2.2 Schedule 

2.3 Requirements 

2.3.1 Personnel 

2.3.2 Training 

2.3.3 Computer Resources 

2.3.4 Test Materials 

2.3.5 Facilities 

3. Acceptance Test Specifications, Methodology, and Evaluation 

3.1 Test Specifications 

3.1.1 Functions To Be Tested 

3.1.2 Software To Be Tested 

3.1.3 Manual Processes To Be Tested 

3.1.4 Tests To Be Conducted 

3.1.5 Relationship of Tests to Functions 

3.1.6 Test Progression 

3.2 Test Methodology 

3.2.1 System Control Methods 

3.2.2 Test Data Base Development 

3.2.3 Test Data Development 

3.2.4 Test Execution 

3.2.5 Test Conditions 

3.2.6 Constraints 

January 1991 2.3.1.4-Acceptauoo Test Plan 3 
Figure A-20 (Continued) 

TABLE OF CONTENTS FOR ACCEPI'ANCE TEST PLAN 

(2.8.1.4 on OSM Documentation Requirements List) 

3.3 Test Evaluation 

3.3.1 Criteria for Evaluation 

3.3.2 Data Reduction 

3.3.3 Recording and Reporting 

3.3.4 Final Release Authority 

4. Acreptance Test Descriptions 

4.1 Test 1 (Function) 

4.1.1 Objectives 

4.1.2 Input and Parameters 

4.1.3 Expected Results 

4.1.4 Procedures for Execution and Evaluation 

4.1.5 Controls 

4.n Test n (Function) 

4 Acceptance Test Plan-2.3.1.4 January 1991 
A.:ceptance Test Plan 

Section 

1 

1.1 

1.2 

1.3 

1.4 

1.5 

TiUe 

Introduction 

Background 

Assumptione and 

Constraints 

Summary of 

the Ac<:eptance 

Test Plan 

References 

January 1991 

COlltent 

Provide appropriate background and summary 

information. 

Provide a brief overview of the system development 

project and why it is being conducted. 

Explain why the Acceptance Tsst Plan is needed, 

provide a brief overview of its organization, and 

indicate system-related topics that have been included 

in the document Ol" excluded from consideration. 

Describe any factors that may affect the test 

requirements, specifications, and plans described in the 

Acceptance Test Plan. 

Provide a brief summary of the most important 

infOrmation in the Acceptance Test Plan. 

List pertinent standards, guidance, documentation, and 

any othar materials used to prepare the Acceptance 

Test Plan. Include vendor-supplied materiall!; project 

documentation; other in-houae documentation; and 

Federal, departmental, agency, and industry standards 

and guidance. 

2.3.1.4--Atteptance Test Plan 5 
Acceptance Test Plan 

Section 

2 

2.1 

2.2 

2.3 

2.3.1 

2.3.3 

2.8.4 

Title 

System Inputs, 

Processing, 

and Outputs 

Schedule 

Requirements 

P"""""'" 

Training 

Computer 

-~· 

Test Materials 

6 Acceptance Test Plan-2.3.1.4 

Content 

Provide acceptance test background information and 

requirements. 

Provide a narrative description of the new system or 

enhancement to be trulted. Include details of 

:i.n.fonnation processing, inputs, and outputs. 

Describe each acceptance test milestone. Include the 

location(s), participating organizatiOll(s), and a 

tentative schedule that include$ time to become 

familiar with the system and for training, test setup, 

distribution of materials, and so forth. 

Provide acceptance test logistics information and 

requirements. 

Identify staff requirements for the acceptance test. 

Include nameB or functions and amount of time needed. 

Describe responsibilities of government and contractor 

personnel, and those of developer and user personnel 

Include special requirements such as multiahif't 

operation and key personnel. 

Describe the type of training that will be reqWred 

before the acceptance test can be conducted. Include 

personnel and computer or other resources required as 

well as the names or functions of the training staff and 

the personnel to be trained. 

Describe the computer resolll'ce$ that will be needed fur 

the acceptance test. Include terminals, modems, 

telephone lines, software, and so furlh. 

List materials needed for the test; for example, 

documentation, software (and on what media), test 

inputs and sample output, test control software, and 

worksheets. 

January 1991 
Acceptance Test Plan 

Section Title 

2.3.5 Facilities 

January 1991 

Content 

Describe the location of the acceptance test and any 

materials (furniture, audiovisual equipment, office 

supplies, and eo forth) needed at that site. 

2.3.1.4-Acceptance Test Plan 7 
Acceptance Teet Plan 

Section 

3 

3.1 

3.1.1 

3.1.2 

3.1.3 

3.1.4 

3.1.15 

3.1.6 

3.2 

Title 

Acceptance Test 

Specificatioos, 

Methodology, and 

Evaluation 

T~t 

Specifications 

Functi~ 

To Be Tested 

Softw~ 

To Be Tested 

Manual Proeesses 

To Be Tested 

Tests To Be 

Cooducted 

Relationship of 

Tests to Functions 

Tll!lt Progression 

Test Methodology 

8 Aoceptance Test Plan-2.3.1.4 

Content 

Provide gt~neral information about the system test. 

Provide information about the functions, processes, and 

software to be tested. 

Provide a brief description of the application functiollB 

that will be tested and the performance requirements 

for thQBe functi.ons. 

Provide a brief deiiCription of the system and/or support 

software that will be tested. 

Provide a brief description of any manual processes 

that will be tested. 

Identify the different kinda of teats that will be used; 

for axample, functionality, workload perlormance, stress 

performance, and support material8 (training, 

documentation). Other types or diffel'ent groupings of 

teats may be appropriate for a specifie system. 

Explain how the tests to be conducted will demoDl!trate 

system functions and processes and prove that 

requirements have been satisfied. 

Describe the general order in which the tests will be 

conducted, the progression from one test to another, 

which teats depend upon the successfuloutcomeofprior 

tests, and the procedures for retesting in the event a 

test fails. 

Describe the general method or strategy of the testing. 

January 1991 
Aeceptwu:e Test Plan 

Section 

3.2.1 

3.2.2 

3.2.3 

3.2.4 

3.2.5 

3.2.6 

3.3 

3.3.1 

3.3.2 

3.3.3 

Title 

System Control 

Methods 

Test Data Base 

Development 

Test Data 

Development 

Test Execution 

Test ConditioiUI 

Constraints 

Test Evaluation 

Criteria for 

Evaluatiou 

Data Reduction 

Recording and 

Reporting 

January 1991 

Con rent 

Describe how development of test packages will be 

controlled. 

Describe how the data base for the test will be 

developed. 

Describe how the data used in the teet will be 

developed. Specify the type of input to be used (live or 

teet) and its volume and frequency. 

Describe the strategy for conducting the test. 

Describe the conditiOIUI under which the teet will be 

conducted, and explain how these conditions relate to 

the actual operating envin:m.ment of the new system or 

enhancement. 

Indicate any anticipated limitations on the test that 

may result from conditions such as interfaces, 

equipment, pel'SOllllel, and data. 

Describe how teat results will be record&d and 

evaluated. 

Describe the criteria to be used to evaluate the results 

of the acceptance test. Include information on p&Bs, 

fail, and restart thresholds. 

Describe the methods to be used to summarize the 

results (summary statistics, graph8, charts, and so 

forth). 

Describe the procedures that will be used to .record the 

progress andresuits of the teet, to report failure, and to 

prepare a final test report. 

2.3.1.4-Acceptanoo Test Plan 9 
Acceptance Test Plan 

Section 

3.3.4 

Title 

Final Release 

Authority 

10 Acceptance Test Plan-2.3.1.4 

Content 

Identify the person(s) responsible and the procedures to 

be followed for approving the test results and 

authorizing final release. 

January 1991 
Acceptance Test Plan 

Section 

4 

4.1.1 

4.1.2 

4.1.3 

4.1.4 

4.1.5 

Title 

Aoxeptance Test 

Descripti0118 

Objectives 

Input and 

Parametem 

Expected Results 

Procedures for 

Execution and 

Evaluation 

Controls 

January 1991 

Content 

Provide a detailed explanation of the individual testa 

involved in the acceptance test. Include a separate 

subsection for each test llild relate that test to a specific 

function. For example: 

4.1 Test 1 (Function) 

4.n Test n (Function) 

Include the following information for each test. 

Describe the objective(s) of the test (that is, what it 

should accomplish) and its relationship to specific 

system functiol18. 

List the input data, parametel'll, and test data base 

records to be used in the test. 

Describe the e%pf!Cted results of the test. 

Describe the test and the roopon&bilities of the 

personnel involved. Discuss preparation, input, 

processing, and output, as well as recording of results, 

plll!SI'fail criteria, retesting procedures, and how any 

system changes determined to be necessary as a result 

of the testing will be effected. Include forms that 

summarize the test steps and provide space to record 

results. 

Deeeribe the test control methods (for example, manual, 

semi-automatic, or automatic). 

2.3.1.4----Acceptance Test Plan 11 
Purpose 

Content 

SYSTEM/SUBSYSTEM SPECIFICATION 

(2,3.3.1 on OSM Documentation Requb'ements List) 

The System/Subsystem Specification provides analysts and programmers with 

information needed to develop application software for a new system or an 

enhancement to an existing system. 

The System/Subsystem Specification describes requirements for software 

(system, application, and special purpose); the system's operating environment; 

design considerations such aa program logic, users, and facilities; and, if 

available, specific functions to be satisfied by the program. 

Figure A-21 summarizes the information required in the System/Subsystem Specification by 

presenting the document's table of contents. Detailed explanations of the material that each 

section should contain are then found in the pages that follow. 

January 1991 2.3.3.1---System/Subsystem Specification 1 
FigureA-21 

TABLE OF CONTENTS FOR SYSTEM/SUBSYSTEM SPECIFICATION 

(2,3.3.1 on OSM Documentation Requirements IJst) 

1. Introduction 

2. 

3. 

4. 

5. 

1.1 Background 

1.2 Scope 

1.3 Assumptions and Constraints 

1.4 Summary of the System/Subsystem Specification 

1.5 References 

Requirements 

2.1 System Overview 

2.2 Functions 

2.3 Performance 

2.3.1 Accuracy 

2.3.2 Validation 

2.3.3 Timing 

2.3.4 Flexibility 

Operating Environment 

3.1 Equipment 

3.2 Support Software 

3.3 Interfaces 

3.4 Security and Privacy 

3.5 Controls 

Design Characteristics 

4.1 Operations 

4.2 Logic 

Program Specifications 

5.1 Program 1 

5.n Program n 

January 1991 2.3.3.1-System/Subsystem Specification 3 
System/Subsystem Specification 

Section 

1 

1.1 

1.3 

1.4 

1.5 

Title 

Introduction 

Background 

Assumptions and 

Constrainta 

Summary of the 

System/Subsystem 

Specification 

References 

January 1991 

Content 

Provide appropriate background and summary 

information. 

Provide a brief overview of the system development 

project and why it is being conducted. 

Explain why the System/Subsystem Specification is 

needed, provide a brief overview ofite organizatioo, and 

indicate system-related topics that have been included 

in the document or excluded from consideration. 

Describe any factors that may affect the test 

requirement& and specifications described in the 

System/Subsystem Specification. 

Provide a brief summary of the most important 

information in the System/Subsystem Specification. 

List pertinent standard&, guidance, documentation, and 

any other materials used to prepare the 

System/Subsystem Specification. Include vendorsupplied materials; project documentation; other inhouse documentation; and Federal, departmental, 

agency, and industry standards. and guidance. 

2.3.3.1--8ystem/Subsystem Specification 5 
System/Subsystem Specification 

Section Title 

2 Requirements 

2.1 System Overview 

2.2 Functions 

2.3 

Content 

Describe the system, its functions, and perfOrmance 

requirements. 

Provide a general description of the system or 

subsystem to establish a frame of reference for the 

remainder of the document: 

• Summarize the functional requirements the system 

will satiafy. Emphasize any unique requirements. 

• Show the general interrelationship of the system's 

components and provide a general description of their 

size. 

• Briefly summarize the system COilcept of operations, 

automated procedures, manual procedures, and 

staffing requirements. 

Describe system functions in both quantitative and 

qualitative terms. Explain how the functioDB satisfy 

the functional requirements and explain the 

relationahip between functions and applications. 

List performance requirements in the following 

subsectiona: 

2.3.1 Accuracy 

2.3.2 Validation 

2.3.3 Timing 

2.3.4 Flexibility 

Accuracy- Describe mathematical, logical, legal, and 

transmission requirements. 

Validation- Describe data validation requirements 

Timing- Describe timing requirements under various 

conditions. Include response time, update processing 

time, data transfer and transmission time, and 

throughput time. 

6 System!Subsystem Specification-2.3.3.1 January 1991 
System/Subsystem Specification 

Section Title 

January 1991 

Content 

Flexibility- Describe the capability for adapting the 

system to changes in requirements; for example, 

changes in modes of operation, operating environment, 

interfaces with other software, aCC'Ul'8.cy and validation 

timing, and planned changes or improvements. 

Identify the system/subsystem components that are 

specifically designed W provide this flexibility. 

2.3.3.1-System/Subsystem Specification 7 
System/Subsystem SpecificatiOD. 

Section 

3 

3.1 

3.2 

3.3 

3.4 

3.5 

Title 

Operating 

Environment 

Equipment 

Support Software 

Interfaces 

Security and 

Privacy 

C<mtrob 

C011tent 

Describe the planned logical and physical oonfigurati011 

of equipment, support software, and interfaces. Discuss 

security and privacy and operational rontrols. 

Identify the equipment required for operation of the 

system. Point out new equipment and relate it to 

specific functional requirements. Include infonnati011 

such as: 

o Processor and size of internal sWage 

o Online and offline storage {media, form, and 

devices) 

o Online and oflline input/output devices 

o Data transmission devices 

o Miscellaneous equipment 

Identify the support software (operating system, 

software utilities, etc.) and any test software. If the 

operation of the system depends on changes to support 

software, identify the nature of these changes and the 

proposed implementation schedule. 

Describs interfaces with other software and/or systems. 

Describe the ovarall security and privacy requiremente 

imposed on the system. 

Describe the operational controls imposed on the 

system. IdentifY the SOlll"CE!S of these controls. 

8 System/Subsystem Specification-2.3.3.1 January 1991 
System/Subsystem Specification 

Section 

4 

4.1 

4.2 

Tille 

Design 

Characteristial 

Operations 

January 1991 

Content 

Describe the system's logic and operating 

characteristics. 

Describe the operating characteristics of the user 

workstations and computer operations centers where 

the system will be operational. 

Describe the logical flow of the entire system. Include 

a flow chart supplemented by test. The flow should 

provide an integrated presentation of the system's 

dynamics, of Em trances and exits, computer programs, 

support software, controls, and data flow. 

2.3.3.1--Systew/Subsystem Specification 9 
System/Subsystem Specification 

Section 

5 

Title 

Pro.,.. 

Specifications 

Content 

Deseribe the system functions to be sati!lfied by 

computer programs. Include a separate subsection for 

each program. For example: 

15.1 Program 1 (Name) 

5.n Program n (Name) 

In.clude descriptions of requirements that the program 

muat meet, the program's operating envirorunent, and 

the program's design charact.eri&tica (inputs, progmm. 

lo!Pc, outputs, and data base). 

10 System/Subsystem Specification-2.3.3.1 January 1991 
Content 

DATA BASE SPECIFICATION 

(2.3.3.2 on OSM Documentation Requirements List) 

The Data Base Specification provides the detailed design approach for the data 

base that supports a new system or an enhancement to an existing system. It 

identifies and defines relationship~~ among file in the data base and, if it has 

not already been established, identifies the proposed data base support 

software. 

The Data Base Specification contains a detailed description of the data base 

and its file structure. The format of this information will depend on the 

language of the data base management system being used. 

Figure A-22 summarizes the information required in the Data Base Specification by 

presenting the document's table of contents. Detailed explanations of the material that each 

section should contain are then found in the pages that follow. 

January 1991 2.3.3.2-Data Base Specification 1 
Figure A-22 

TABLE OF CONTENTS FOR DATA BASE SPECIFICATION 

(2.3.3.2 on OSM Documentation Requirements List) 

1. Iutroduction 

1.1 Background 

1.2 Scope 

1.3 Assumptions and ConstraiDts 

1.4 Summary of the Data Base Specification 

1.5 References 

2. Data Base Description 

2.1 Identification 

2.2 Using Software 

2.3 Conventions 

2.4 Special Instructions 

2.5 Support Software 

3. Data Base Logical Organization 

4. Data Base Physical Organization 

4.1 Storage 

4.2 Access 

4.3 Design Considerations 

January 1991 2.3.3.2--Data Base Specification 3 
Data Base Specification 

Section 

1 

1.1 

1.2 

1.3 

1.4 

.. , 

Title 

Introduction 

Background 

Assumptions and 

Coll!ltraints 

Summary of 

the Data Base 

Specification 

Reference& 

January 1991 

·" 

Content 

Provide appropriate background and summary 

information. 

Provide a brief overview of the system development 

project and why it is being conducted. 

Explain why the Data Base Specification is needed, 

provide a brief overview of its organization, and 

indicate system-related topics that have been included 

in the document or excluded from consideration. 

Describe any factors that may affect the program 

characteristics described in the Data Base Specification. 

Provide a brief summary of the most important 

information in the Data Base Specification. 

List pertinent Btandards, guidance, documentation, and 

anY other materials U8Bd to prepare the Data Base 

Specification. Include vendor-supplied materials; 

project documentation; other in-hoU8B documentation; 

aw:l Federal, departmental, agency, and industry 

standards and guidance. 

2.3.3.2-Data Base Specification 5 
Data Base Specification 

Section 

2 

2.1 

2.2 

2.3 

2.4 

2.5 

TitJo 

Data Base 

Description 

Identification 

Using Software 

Conventions 

s~ 

InstructioW! 

Support Software 

" 

6 Data Base Specification-2.3.3.2 

Content 

Provide ba~~ic information about the data base and its 

operating environment. 

Specify the oode name, tag, or label along with any 

other identification. Identify data bases designated for 

experimental, test, or temporary use and provide the 

timeframes in which they will be used. 

Identify all software that will use or acaas the data 

base. Provide the software name, code name, and any 

release or version number. 

Describe all labeling or t.agging conventions that data 

base developers may need in order to use the data baae 

specification. 

Provide any special instructions that data base 

developers or thoae testing or using the data base may 

nesd; for example, criteria, procedures, and furm.ats for 

submitting data for entry into the data base, 

identification of data control organization, and entering 

data into the data base. Where these instructions are 

extensive, reference appropriate sections of other 

documents. 

Provide brief descriptions of all support software 

directly related to the data base(for example, data base 

management, storage allocation, data base loading, file 

proceas:ing, and other generating, modifying, or 

updating software). Th:lscriptions should include name, 

function, m(\jor operating characteristiC!!, and machine 

run instructions. RefBrellce all applicable support 

software documentation. 

January 1991 
Data Base Specification 

Section 

3 

Title 

Data Base Logical 

Organization 

January 1991 

Content 

Present the detailed specifieationll for the data base. 

Include diagrams and the Data Dictionary (or referenre 

the Data Dictionary) describing the physical etructure 

of the data. This should include definitions, 

characteristics, relationships, keys, access method!l, and 

security. 

The precise information included will depend on the 

data base management system and data definition 

language used. For example: 

• Hierarehical - Schemas will describe fields, 

segment$, data base records, and data bases 

o Network - &:hemas will describe data items, 

records, seta, and subschemas (user views) 

0 Relational - Scbemas will describe attributes, 

domains, relations, and views. 

Depending on the data base mauagement system, a 

number of facilities or utilities may be used to define 

data organization, access, and control. Supporting 

documentation regarding the use and contenta of these 

utilities should also be included. 

2.3.3.2-Data Base Specification 7 
Data Base Specification 

Section 

4 

4.1 

4.2 

4.3 

TiUe 

Phyaical 

Characteristics 

Storage 

Access 

Design 

Considerations 

8 Data Base Specification-2.8.3.2 

Content 

DeBCribe the physical design of the data base. 

Specify storage requirements for the data base. Include 

the following: 

Internal- Describe and illustrate areas set aside for 

data, including indexing and working areas. Include 

equipment oonstraints and design considerations that 

affect the use of internal storage. 

Device - List by device type all peripheral storage 

required for the data base. Iru:lude any COIIStraints 

impoaed on storage requirements by each storage 

device, as well as requirements for permanent data 

storage and temporary data stol'age (including 

overlays). 

Offiine - Describe the fonn, media, and storage 

requirements for all offline data storage. 

Describe the acc11111:1 method and specify the physical 

relationships of access (index, device, area). Describe 

all physical access security mechanisms (encryption., for 

example). 

List design considerations as they relate to handling 

this data base (for example, blocking factors). 

Emphasize those physical relationships important to 

efficient use of the data base. 

January 1991 
Purpose 

Content 

" 

PROGRAM SPECIFICATION 

(2,3,3.4 on OSM Documentation Requirements List) 

The Program Specification provides programmers with basic information 

needed to develop a new system or an enhancement to an existing system. It 

deBcribes the programs that must be developed, as well as the software 

products that have been 01' will be acquired, in sufficient detail to allow the 

development of code to begin. 

The Program Specification explaillB the requirements, operational environment, 

and design characteristics for each program in the new system or 

enhancement. It provides details on data flow, interfaces, input, processing, 

and output. 

Documentation for software products that have been acquired must be at a 

level that allows system testing and use in an operational environment. While 

it is not possible to define an exact format for such documentation, these 

minimum standards must be observed. 

Figure A-23 summarizea the information required in the Program Specification by presenting 

the document's table of contents. Detailed explanations of the material that each section 

should contain are then found in the pages that follow. 

January 1991 2.3.3.4-Progrsm Specification 1 
1. 

2. 

3. 

Figure A-23 

TABLE OF CONTENTS FOR PROGRAM SPECIFICATION 

(2.3.3.4 on OSM Documentation Requirements List) 

Introduction 

1.1 Background 

1.2 Scope 

1.3 Assumptions and Constraints 

1.4 Summary of the Program Specification 

1.5 Refen~nces 

Application Overview 

2.1 Description 

2.2 Operating Environment 

2.2.1 Equipment 

2.2.2 Support Software 

2.2.3 External Interfaces 

2.2.4 Storage 

2.2.5 Security and Privacy 

2.2.6 Controls 

2.3 Fl~ 

2.4 List of Programs 

2.5 Program Interfaces 

Program Characteristics 

3.1 Program 1 

3.1.1 Overview 

3.1.1.1 Description 

3.1.1.2 FIDw 

3.1.1.3 Modules 

3.1.1.4 Interfaces 

3.1.1.5 Special Requirements 

3.1.2 Detailed Specification 

3.1.2.1 Program Module Detail 

3.1.2.2 InpuWOutputs 

3.1.2.3 PerfOl'mance Requirements 

3.n Program n 

January 1991 2.3.3.4-Program Specification 3 
Program Specification 

Section 

1 

1.1 

1.2 

1.3 

1.4 

1.5 

Title 

Introduction 

Background 

Soopo 

Assumptions and 

Conetraints 

Summary of 

""'"""""" Specification 

References 

January 1991 

Content 

Provide appropriate background and summary 

infOrmation. 

Provide a brief overview of the system development 

project and why it i.a being conducted. 

Explain why the Program Specification is needed, 

provide a brief overview of ita organization, and 

indicate system-related topics that have been included 

in the document or excluded from considerati011. 

Describe any factors that may affect the program 

characteristics described in the Program Specification. 

Provide a brief summary of the most important 

information in the Program Specification. 

List pertinent standards, guidance, documentation, and 

any other materials used to prepare the Program 

Specification. Include vendor-supplied materials; 

project documentation; other in-house documentation; 

and Federal, departmental, agency, and industry 

standards and guidance. 

2.3.3.4---Program Specification 5 
Program Specification 

Section 

2 

2.1 

2.2 

2.2.1 

2.2.2 

2.2.3 

Title 

Application 

Overview 

Description 

Operating 

Environment 

Equipment 

Support Software 

External Interfaces 

6 Program Specifi.cation-2.3.3.4 

Content 

Describe the new system or enhancement. This section 

provides a frame of reference for the remainder of the 

document. 

Explain the purpose of the new system or 

enhancement. Include a summary description of the 

system/subsystem functions it has been designed to 

perform, or show its relationship to other programs 

that satisfy specific functions. 

Provide brief descriptions of the various components of 

the operating environment of the new BYl!tem or 

enhancement. 

Identify the equipment required to operate the 

program. Include at a minimum the fullowing: 

• Processor and amount ofintern.al. storage 

• Online and oilline storage, including media, format, 

and devices 

• Online and offline input and output devices, 

including capacities 

• Data transmission devices. 

Identify the support software and describe any test 

programs. If the operation of the program depends on 

changes to the support software, identify the nature of 

these changas and when they will be implemented. 

Describe all interactions with other systems or 

software, including sequence or procedure relationships 

and data interfaces. 

January 1991 

I 
Program Specification 

Section 

2.2.4 

2.2.5 

2.2.6 

2.3 

2.4 

2.5 

Title Content 

Storage Identify storage requirements, constraints, and 

conditions. Describe interilll.l storage, including 

indexing and working areas; device storage (all 

peripheral storage, permanent and temporary, 

including overlays); and offiine l!'torage, including 

format and media. 

Security and Privacy Describe security and privacy considerations for the 

program, including input, output, and data bases. 

Controls Describe program control!~ such as record counts, 

accumulated counts, and batch control!~. Identify the 

souroes of these controls. 

Flow Provide a brief snmmsry of the logical flow of 

information in the new system or enhancement. 

Include flow charts as appropriate. 

List of Programs Identify all of the programs used in the new system or 

enhancement snd provide a brief deacription of their 

'"""""'· 

Program Interfaces Provide a brief description ofhow the programs interact 

with oue wtother wtd with other systems and 

pro&rams. 

January 1991 2.3.3.4-Program Specification 7 
Program Specification 

Section 

3 

3.1.1 

3.1.1.1 

3.1.1.2 

3.1.1.3 

3.1.1.4 

3.1.1.5 

3.1.2 

TiUe 

Overview 

Description 

Flow 

Modules 

Interfaces 

Special Requirements 

Detailed 

Specification 

8 Program Specification-2.3.3.4 

Provide detailed information about each program in the 

new system or enhancement. Include a separate 

subsection for each program. For example: 

3.1 Program 1 

3.n Program n 

Include at a minimum the following information for 

each program. 

Provide a high-level overview of the program and its 

functional components (that is, modules). Include the 

following information. 

Describe in detail the processing activities to be 

accomplished by the program 1111 well 1111 operating 

procedures. Describe loading, start, stop, recovery, and 

restart. Include any special program functiOD$ or 

requirements needed for implementation. 

Provide a detailed program flow chart depicting the 

program flow and processUJ.g logic. Supplement the 

flow chart with text. 

Use a table, chart, or list to show each pfOil'am module 

by name. 

Describe any interlaces between this program and other 

internal or external programs. 

Describe any additional considerations related to the 

•"""""'· 

Provide detailed specifications for the program and its 

functional components (modules). Include the following 

information. 

Jailuary 1991 
Program Specification 

Section 

3.1,2.1 

3.1.2.2 

Title 

Program Module 

Detail 

Inputs/Outputs 

January 1991 

·" 

Content 

IdentifY the complete set of components of the program 

and theil' relatiOil!lhips. Use tables and diagrams as 

appropriate. Include a separate subsection for each 

module. For example: 

(a) Module 1 

(n) Module n 

The description of each COOOpolleJlt should include the 

following details: 

• Description 

o Logic Flow 

o Function(s) 

o Data Requirements 

o Interfaces 

• Special Requirements 

Provide information about the characteristics of the 

data input to the program. Possibilities include: 

• Title and tag 

• Relational data view 

• Fonnat specificatiOil!l such as a report format 

o Validation criteria 

• Volume and frequency 

• Means of entry 

• Source document or specific interface source and 

ita disposition 

o Access procedures and security mechan:i.sma 

o Index, device, and area access 

• Security and privacy considerationa. 

2.3.3.4-Program Specification 9 
Program Specification 

Section 

3.1.2.3 

Title 

Performance 

Requirements 

10 Program Speci.fication-2.3.3.4 

Content 

Provide information about program output. 

Possibilities include: 

• Title and tag 

• F=at specifications such B.S a report format 

• Selection criteria for display, output, or trllmlfer 

• Volume and frequency 

• Output media 

• Description of graphic displays and symbols 

• Security and privacy considerationa 

• Disposition ofproducta 

• Description of the sequence of displays, display 

contents, fi>red and variable formats, and display 

of srror conditions. 

Specify performance requirements. 

following: 

Include the 

• Accuracy requirements- mathematical, logical, 

legal, and transmission 

• Validation requirements 

• Timing requirements - response time, update 

processing time, data transfer and transmillsion 

time, and throughput and internal processing 

• Flexibility- '""' the program's capability to adapt to 

changes in mode of operation; operating 

environment; interlaces; accuracy, validation, and 

timing requirements; and planned changes or 

improvements. 

January 1991 
p._., 

DATA DICTIONARY 

(2.3.3.6 on OSM Documentation Requirements List) 

The Data Dictionary provides a central repository of information about the key 

components of applicatiOllS. It is used by analysts, designers, programmers, 

and users to ensure a common understanding and use of application 

components, and also facilitates complete and precise application software and 

data documentation. The DataDictionary should meet the fOllowing objecli.ves: 

• Establish a glossary of terms 

• Provide standard terminology 

• Define all terms associated with a system or subsystem 

• Identify the modules available to a system 

• Provide system-wide cross-reference cape.hility 

• Resolve problems associated with aliases and acronyms 

• Provide centralized control fur changes to data elements, programs, 

files, and reports 

• Provide a listing of all data elements and their sour<::es. 

The Data Dictionary is a dynamic document which is expanded and revised 

through system development and maintenance. The content of the Data 

Dictionary will vary depending upon the life cycle phase. It is used to support 

data base and file designs, as well as process d.:.velopment. Hence, the 

development methodology used will dictate the information included in the 

dictionary. Common to all methodologies is the definition of data elements and 

their characteristics; however, other components should be defined as 

appropriate. For nample, when the Yourdon methodology is followed, the 

dictionary should identity data .flows and define the associated data elements. 

Other application components to be defined include report files and other files, 

data records, and data bases. 

The format of the dictionary also may vary, depending on the medium used to 

develop it. A number of automated tools are available to support data 

dictionary production, some of them integrated with data base or software 

design and development, and these tools should be used whenever possible. 

Figure A-24 summarizes the information required in the Data Dictionary by presenting the 

document's table of oontents. Detailed explanations of the material that each section should 

contain are then found in the pages that follow. 

January 1991 2.3.3.6--Data Dictionary 1 
Figure A-24 

TABLE OF CONTENTS FOR DATA DICTIONARY 

(2.3.3.6 on OSM Documentation Requirements List) 

1. Introduction 

1.1 Background 

1.2 Scope 

1.3 Assumptions and Constraints 

1.4 Summary of the Data Dictionary 

1.5 References 

2. Data Dictionary 

Definition 

Format 

Syuonym.s 

Source 

Where Used 

Critical Values 

Editing Criteria 

Conversion Factors 

Volumes 

Frequency 

Responsibility 

Calculatioill! 

Controls 

January 1991 2.3.3.6---Data Dictionary 3 
Data Dictionary 

1 

1.1 

1.2 

1.3 

1.4 

1.5 

Title 

Introduction 

Background 

Soopo 

Allsumptiona and 

Constraints 

Summary of the 

Data Dictionary 

References 

January 1991 

Content 

Provide appropriate background information. 

Provide a brief overview of the new system or 

enhancement and why it ia being implemented. 

Explain why the Data Dictionary is needed, provide a 

brief overview of its organization, and indicate systemrelated topics that have been included in the document 

or e~relu.ded from consideration. 

Describe factors which may impact the accuracy or 

applicability of the Data Dictionary. 

Summarize the m011t significant information included in 

the Data Dictionary. Identify conventions used. 

List pertinent standards, guidance, documentation, and 

any other materials used to p:repare the Data 

Dictionary. Include vendor-supplied materiaLs; project 

documentation; other in-house documentation; and 

Federal, departmental, and industry standard& and 

guidance. 

2.3.3.6--Data Dictionary 15 
Data DictiOilal'y 

Section 

2 

Title 

DictiOilal'y Entries 

Defurition 

Format 

Synonyms 

Whern Used 

Critical Values 

Editing Criteria 

Conversion 

Factors 

6 Data Di.ctionary-2.3.3.6 

Content 

Include the followingjnfurmation for each entry, when 

appropriate (depending upon the entry type, 

development methodology, and life-cycle phase). 

Alphanumeric name of the entry as used in the system. 

Type of entry: for example, data element, report file, or 

data base; required or not required; initial or update. 

Narrative description of the entry. 

Alphanumeric, numeric, alphabetic; length; decimal 

places; and other attributes (such as display format, 

storage format). 

Synonyma and aliases employed by users and in 

technical documentation. 

Origin of entry, such as outside organization external 

media (for example, tape &om another agency), 

calculation in program, keyed by operator. 

Cross-reference to each report, file, data base, program, 

online screen, etc., that utilizes the entry. Include 

jndication of how used: jnput, output, or calculated 

output (including formula). 

Range, scale, unit of measure, etc. 

Valid values, relational and/or cons:iatency edits, 

reasonableness checks (range). 

Algorithm or factor required to convert input for 

storage and/or to convert stored values for output. 

January 1991 
Data Dictionary 

SectiOII Title 

Volumes 

Frequency 

Respoilllibility 

Calculations 

Controls 

January 1991 

" 

Content 

Volume estimate per time period (or other measlll'f!). 

Update/processing frequency. 

Organization and/or name of contact responaible for 

input, maintenance, and output. 

Algorithm used to calculate value. 

Controls required for sensitive data. 

2.3.3.6-Data Dictionary 7 
Purpose 

Content 

·" 

CONTINGENCY PLAN 

(2.3.5 on OSM Documentation Requirements List) 

The Contingency Plan provides procedures to ensure that interruptions in the 

normal operations of an ADP site or system are effectively managed and have 

minimal impact on operations, regardless of their abruptness or magnitude. 

The Contingency Plan describes the major risks associated with system 

operations-those that could result in operational failure--and other 

catastrophic events. It provides detailed procedures for system backup and for 

recovery from these situations. 

Figure A-25 summarizes the information required in the Contingency Plan by presenting the 

document's table of contents. Detailed explanations of the material that each section should 

contain are then found in the pages that follow. 

January 1991 2.3.5--Contingency Plan 1 
" 
" 

Figure A-25 

TABLE OF CONTENTS FOR CONTINGENCY PLAN 

(2.8.5 on OSM Documentation Requirements List) 

L Introduction 

1.1 Background 

1.2 Scope 

1.3 Assumptions and Coru~traints 

1.4 Summary of the Contingency Plan 

1.5 References 

2. Contingencies 

2.1 Events Included 

2.2 Events Excluded 

2.3 Priorities 

2.4 Support Commitments 

3. Responsibilities 

3.1 Plan Preparation and Maintenance 

3.2 Emergency Chain of Command 

3.3 Operati011s Supervisor(s) 

3.4 Shift Supervisor(s) 

4. Respolllle Strategies 

4.1 Emergency Proeedurea 

4.2 Continuity of Operations 

4.3 Recovery Procedures 

5. Resources 

5.1 Staff 

5.2 Inventory 

5.3 Procurement 

5.4 Facilities 

5.5 Transportation 

5.6 Communications 

5.7 Other 

6. Action Plans 

6.1 Contingency 1 

6.n Contingency n 

January 1991 2.3.5----ContingencY Plan 3 
Contingency Plan 

Section 

1 

1.1 

1.2 

1.3 

1.4 

15 

Title 

Introduction 

Background 

Assumptions and 

Constraints 

Summary of the 

Contingency Plan 

References 

January 1991 

Contont 

Provide appropriate background and summary 

information. 

Provide a brief overview of the system development 

project and why it is being conducted. 

Explain why the Contingency Plan ill needed, provide 

a brief overview of ita organization, and indicate 

system-related topics that have been included in the 

document or excluded from consideration. 

Describe any factors that may affect the contingencies, 

responsibilities, strategi1111, resource requirements, and 

action plans described in the Contingency Plan. 

Provide a brief summary of the most important infOrmation in the Contingency Plan. 

List pertinent standal"ds, guidance, documentation, and 

any other materials used to prepare the Contingency 

Plan. Include vendor-supplied materials; project 

documentation; other in-house documentation; and 

Federal, departmental, agency, and industry st.andal"ds 

and guidance. 

2.3.5----Contingency Plan 5 
Contingency Plan 

Section 

2 

2.1 

2.3 

2.4 

Title 

Contingllncies 

Events Included 

Events Excluded 

PrioritieB 

Support 

Commitments 

6 Conti11gency Plan-2.3.5 

Content 

Determine the situations for which contingency plans 

should be developed and the organWation's priorities 

and commitments in the evant that one of those 

situations occur. 

Contingencies should be i.deutified through a rigorous 

risk analysis exercise which should be described in this 

section. 

Describe each situation for which a contingency plan 

will be developed. Explain why each was selected. 

Describe each situation that was not included in the 

contingency plan and explain why it waa not included. 

Describe the organi:u~tion's priorities should any of the 

situatioll8 described above occur. 

Describe the organization's commitments to support its 

own goals or other organizatiOil!l should any of the 

situations described above occur. 

January 1991 
Contingency Plan 

Section 

3 

3.1 

3.2 

3.3 

8.4 

Title 

Responaibilities 

Plan Prep!U'ation 

and Maintenance 

Emergency Chain 

of Command 

Operations 

SupenUor(s) 

Shift Supervisor(&) 

January 1991 

'" 

Coo tent 

Identify key management and staff pei'IIOWlel and 

define their roles and reapons:ibilitie!l should any of the 

s:ituatioil!l described above occur. 

Include at a minimum the personnel listed below. 

Those respoil!lible for preparing and maintaining this 

Contingency Plan. 

Those responsible for the organization's 8(!tiviti911. 

Person(s) responsible for ADP equipment and software. 

P&SOII(s) responsible for day-to-day operations of ADP 

equipment and software. 

2.3.5--Contingency Plan 7 
Contingency Plan 

Section 

4 

4.1 

4.2 

4.3 

Title 

Response Strategies 

Continuity of 

Operations 

"""""" 

Procedures 

8 Contingency Plan-2.3.!5 

Content 

Determine a preferred strategy for the way 

continaencies will be handled at the site or activity. 

The strategy should be based on an evaluation of 

options for response to the emergency itself, providing 

continuity of operations after an emergency, and 

resuming normal opel'ations. The preferred strategy 

should be approved by management. 

Describe the strategy for responding to an emergency. 

Include at a minimum the following: 

• Initial notification 

• Evacuation procedure~~ 

• Activating the emergency response center 

• Damage asslllll!ment 

• Securing the romputer center 

• Notifying vendors 

• Notifying users 

~scribe the strategy for establishing backup 

opel'ations. Include at a minimum the following: 

• Notifying the backup site 

• Transportation W the backup site (personnel, 

tapes, documentation, etc.) 

• Establishing a production schedule 

Describe the strategy for resuming normal operations. 

Include at a minimum the following; 

• Preliminary planning 

• Site selection criteria 

• Facility planning 

• Selecting/procuring hardware 

• Salvaging equipment 

• Restoring utilities 

• ResWring communications 

• Procuring supplies 

• Activating the recovery site and 

closing the backup site 

January 1991 
Contingency Plan 

Section Title 

5 

5.1 Stoff 

5.2 Inventory 

January 1991 

Conteut 

To be prepared in the event of a contingency, develop a 

directory of personnel, an inventol'y of critical 

resources, and a listing of other procedures and 

requirements. 

This section at a minimum should contain the 

infbnnation below. It should be updated 11.8 necessary. 

Include a complete liBt ofllllsiined pen~onnel, including 

address, phone number, and other desired information. 

Include rosten of those to be notified in the eveJJ.t of an 

emergency. 

Assign members to and include ro~~ten for recovery 

....... 

Include all critical items, including at a minimum. the 

following: 

Date- Onsite inventory, offsite inventory, and critical 

files needed for processing at the backup site. Describe 

how and when these files are updated. 

Software-System software and applications software. 

Include onsite and offsite inventory and how and when 

updates take place. 

Hardware - List should include vendor's name, 

address, etc. Include emergency acquisition 

agreement(s), sample order forms, documentation, etc. 

Supplies - List should include critical supply items 

and infOrmation such as part number and vendor. 

Provide a list of supplies needed for processing at the 

backup site and their location. 

Documentation- Include onaite and offilite inventory 

and how and when updates take place. Provide e liBt, 

including location, of documentation needed for 

proeei!Sing at the backup site. 

2.3.5--Contingeney Plan 9 
Contingency Plan 

Seclion TiU. 

5.3 Procurement 

5.4 Facilities 

5.5 Transportation 

5.6 Communications 

5.7 Other 

10 Contingency Plan-2.3.5 

" 

Cnnt.nt 

Include lists of supplimos, order forme, emergency 

acquisition agreements, and other agreements. 

Include current site !'llquirements and the layout of the 

facility, backup space available (by site), power 

requirements, and any other facility/environment 

requirements at the current site or backup site(s). 

Include current transportation needs and 

transportation required to implement backup and 

recovery operations. Consider added requirements due 

to emergency conditions and include procedures for 

obtaining emergency transportation. 

Include current communications !Weds and 

communications requirements at backup site(s). 

Include any other issues that should be addressed, 

including alternate site agreements, vendOI' 

performance, liability, contracts, and so forth. 

January 1991 
Contingency Plan 

Section Title 

6 Action Plans 

January 1991 

Content 

For each contingency identified in Seetion 2, provide a 

step-by-step plan for response, backup, and recovery. 

Include the person(s) responsible fur implementing the 

procedure, how it should be implemented, how 

operations will be monitored, and how operations will 

return to nonnal. 

Include a separate subsection for each contingency. For 

example: 

6.1 Contingency 1 

6.n Contingency n 

2.3.5---Contingency Plan 11 
Content 

" 

CONVERSION PLAN 

(2.4.3 on OSM Documentation Requirements List) 

The Conversion Plan outlines the schedule and strategy for implementing a 

new system or an enhancement to an existing system, Implementation usually 

involves one-time activities that include data base conversion, parallel 

operations, user training, and organizational restructuring. 

The Conversion Plan describes all required taaks necessary to accomplish the 

transition to the new system or enhancement. It contains procedures for 

• Collecting and converting data and files, including purging the data and 

files of obsolete information 

• Developing and testing computer programa to support data and file 

conversion 

• Developing the sequence of events and schedule for the phased 

implementation of new data bases and data processing procedures 

• Defining any necessary organizational realignment, including activities 

and a schedule for implementing those changes 

• Defining training required for conversion activities 

• Developing any special forms, procedures, or controls required for the 

COllversion. 

Figure A-26 summarizes the infOI"l!lation required in the Conversion Plan by presentini: the 

document's table of contents. Detailed explanations of the material that each sectiou should 

contain are then fuund in the pages that follow. 

January 1991 2.4.3---Conversion Plan 1 
Figure A-26 

TABLE OF CONTENTS FOR CONVERSION PLAN 

(2.4.3 on OSM Documentation Requirements List) 

1. Overview 

1.1 Background 

1.2 Scope 

1.3 Assumptions and Constraints 

1.4 Summary of the Conversion Plan 

1.5 References 

2. CUITent Environment 

2.1 CUITent System Inventory 

2.1.1 Hardware 

2.1.2 System Software 

2.1.3 Applicatiol18 Software 

2.1.4 Files and Data Bases 

2.1.5 Overall System Complexities 

2.1.6 Security/Privacy Requirements 

2.1.7 Documentation 

2.1.8 Manual Procedures 

2.2 Operating Environment 

2.2.1 Facilities 

2.2.2 Processing Modes 

2.2.3 Agency Conventiol1B and Standards 

2.2.4 Communications 

22.5 Personnel 

3. New Environment 

3.1 System 

3.1.1 Hardware 

3.1.2 System Software 

3.1.3 Applications Software 

3.1.4 Files and Data Bases 

3.1.5 Overall System Complexities 

3.1.6 Security/Privacy Requirements 

3.1.7 Documentation 

3.1.8 Manual Procedures 

January 1991 2.4.3-Conversion Plan 3 
Figure A-28 (Continued) 

TABLE OF CONTENTS FOR CONVERSION PLAN 

(2.4.3 on OSM Documentation Requirements List) 

3.2 Opernting Environment 

3.2.1 Facilities 

3.2.2 ProcessingModes 

3.2.3 Agency Conventions and Standards 

3.2.4 Communications 

3.2.5 Personnel 

4. Convereion Activities 

4.1 Methodology 

4.2 Task Plan 

4.3 Schedule 

4.4 Resoun:e Requiremente 

4.5 Interim/Fallback Operating Capability 

4 Conversion Plan-2.4.3 January 1991 
Conversion Plan 

Section 

1 

1.1 

1.2 

1.3 

1.4 

1.5 

Title 

Introduction 

Background 

Assumptions and 

Constraints 

Summary of the 

Convei'Si.on Plan 

References 

January 1991 

.li 

Content 

Provide appropriate background and eumll18.I'y 

information. 

Provide a brief overview of the new system or 

enhancement and why the project Wall undertaken. 

Explain why the Converaion Plan is needed, provide a 

brief overview of ita organization, and indicate system· 

related topics that have been included in the document 

or excluded from consideration. 

Describe any factors that may affect the activities 

described in the Convei'IIion Plan. DiscU88 any 

problems associated with converting the Ctll'l'ent system 

to the new system or enhancement. 

Provide a brief summary of the most important 

information in the Conversion Plan. 

List pertinent standards, guidance, documentation, and 

any other materials used to prepare the Conversion 

Plan. Include vendor-11upplied materials; project 

documentation; other in-house documentation; and 

Federal, departmental, agency, and industry standards 

and guidance. 

2.4.3--Conversion Plan 5 
Conversion Plan 

Section 

2 

2.1 

2.2 

Title 

c~t 

Environment 

Current System 

Inventory 

Operating 

Environment 

6 Cm~.version Plan~2.4.3 

" 

Content 

Describe the existing hardware, software, and operating 

environment. 

Provide brief summaries and the statu& of the existing 

system in the following subsections: 

2.1.1 Hardware 

2.1.2 System Software 

2.1.3 ApplicatiOn$ Software 

2.1.4 Files and Data Bases 

2.1.5 Overall System Complexities 

2.1.6 Security/Privacy Requirements 

2.1.7 Documentation 

2.1.8 Manual Procedures 

Provide brief summaries of the current operating 

environment in the following subsectioll8: 

2.2.1 Facilities 

2.2.2 Proeeasini Modes (batch, timesharing, etc.) 

2.2.3 OSM Conventions and Standards 

2.2.4 Comm=ieatioo Modes 

2.2.5 Personnel 

January 1991 
Conversion Plan 

Seetion 

3 

3.1 

3.2 

Title 

New Environment 

System 

Opru-ating 

Environment 

" 

Content 

Describe the hardware, software, and operating 

environment requin!d for the new system or 

enhancement. 

Provide brief summaries of hardware and software 

requirements in the following subsectioD.B: 

3.1.1 Hardware 

3.1.2 System Software 

3.1.3 Applications Software 

3.1.4 Files and Data Bases 

3.1.5 Overall System Complexities 

3.1.6 Security/Privacy Requirements 

3.1.7 Documentation 

3.1.8 Manual Procedures 

Provide brief summaries of the proposed operating 

lilllvironment in the following subsectio1111: 

3.2.1 Facilities 

3.2.2 Processing Modaa (batch, timesharing, etc.) 

3.2.3 OSM Conventi(Dlfj and Standards 

3.2.4 Communication Modes 

3.2.5 Personnel 

January 1991 2.4.3--Conversion Plan 7 
Conversion Plan 

Section 

4 

4.1 

4.2 

4.3 

4.4 

Title 

Conversion 

Activities 

Methodology 

Task Plan 

Schedule 

Interim/Fallback 

Operating 

Capability 

8 Conversion Plan-2.4.3 

" 

Content 

Provide a detailed description of the conversion eifurt. 

Describe the specific methodology to be used in the 

conversion process (for example, parallel conversion, 

cutover, or phased implementation). Relate that 

methodology to the conversian effort propo111ed. 

Provide a detailed conversion task description for each 

component of the new syetem or enhancement that will 

be implemented. Include the purpose of the task, how 

the task will be accomplished, resources required, and 

expected results. 

Using the target completion date WI a :fixed milestone, 

schedule each of the taaks described in the previo\UI 

section in tenns of dependencies and known 

cOllstraints. The schedule should be updated as 

resource levels are determined. 

Describe any temporary pl'OC8!!sing procedures that may 

be required during the conversion. 

Describe procedures to cover all reasonable 

contingencies that could occur during the conversion. 

January 1991 
P,..., 

Content 

USER TRAINING PLAN 

(2.4.4 on OSM Documentation Requirements List) 

The User Training Plan outlines requirements for instructing management, 

operations, and clerical persounel in the use of a new system or an 

enhancement to an existing system. It identifies those who will receive the 

training, the materials to be used, the staff who will conduct the training, 

curriculum development activities, and the training schedule. Each of these 

components must be comprehensively designed and carefully implemented if 

the training effort is to be a success. The plan also alerts management as to 

the impact of the training program on system implementation and operation 

as well as day-to-day activities. 

The User Training Plan provides detailed information on users to be trained, 

materials to be used in the training, the staff who will conduct the training, 

the curriculum (both content and development), and the training schedule, 

including its impact on normal operations. It includes details on training 

facility aud resource requirements and organizational responsibilities. 

The final User Training Piau includes the complete course curriculum, all 

materials, including teaching guides and class handouts, and the evaluation 

report. 

Figure A-27 summarizes the information rt!quired in the User Training Plan by presenting 

the document's table of contents. Detailed explanations of the material that each section 

should contain are then found in the psges that follow. 

Jauuary 1991 2.4.4---User Training Piau 1 
Figure A-27 

TABLE OF CONTENTS FOR USER TRAINING PLAN 

(2.4.4 on OSM Documentation Requirements List) 

1. Introduction 

1.1 Background 

1.2 Scope 

1.3 Assumptions and Colll!traints 

1.4 Summary of Training Activities 

1.5 References 

2. Training Requirements 

2.1 Schedule 

2.2 Computer Resources 

2.3 Training Materinl.s 

2.4 Facilities 

3. Training Responsibilities 

3.1 Development of Training 

3.2 Conducting Training 

3.3 Attending Training 

3.4 Evaluation of Training 

4. Resource Requirements 

4.1 IJ(!velopment of Training 

4.2 Conducting Training 

5. Training Curriculum 

5.1 Course 1 

5.1.1 Objective 

5.1.2 Prerequisites 

5.1.3 Cuniculum 

5.1.4 Details 

5.1.5 Materials 

6. Evaluation of Training 

6.1 Ways to Obtain Feedback 

6.2 Evaluation of Training 

6.3 Evaluation Report 

January 1991 2.4.4-User Training Plan 3 
User Training Plan 

Section 

1 

1.1 

1.2 

1.3 

1.4 

1.5 

Title 

Introduction 

Background 

Assumptions and 

Constraints 

Summary of 

Training Activities 

References 

January 1991 

Content 

Provide appropriate background and summary 

in!onnation. 

Provide a brief overview of the system development 

prqject and why it is being conducted. 

Explain why ths User Training Plan is needed, provide 

a brief overview of its organization, and indicate 

system-related topics that have been included in the 

document or excluded from consideration. 

Describe any factors that may afl'ect the training 

requirements, responsibilities, and plans described in 

the User Training Plan. 

Provide an overview of the trainin& required to install, 

implement, operate and maintain the new system or 

enhanooment. Identify specific COW"!Ies. 

List pertinent standards, guidance, documentation, and 

any other materials used to prepare the User Trainin& 

Plan. Include vendor-supplied materiale; pl"Qject 

documentation; other in-house documentation; and 

Federal, departmentaL agency, and industry standards 

and guidance. 

2.4.4--User Training Plan 5 
User Training Plan 

Section 

2 

2.1 

2.3 

2.4 

Titlo 

Training 

Requirementll 

Schedule 

Computer 

""'~ 

Training 

Materials 

Facilities 

6 User Training Plan--2.4.4 

Content 

Provide training logistics 

requirements, including their 

operations. 

information and 

impact on normal 

Describe each training milestone, including course 

development activities. Include the location(s), 

participating organization(s), and a tentative schedule 

for each course. 

Describe the computer reBOillWS that will be needed for 

the training. Include terminals, modems, telephone 

lines, software, and so forth. 

List materials needed for the training; for example, 

documentation, software (and on what media), video 

cassettes, example input and output. 

Describe the location. of the training and any materials 

(furniture, audiovisual equipment, office supplies, and 

so forth) needed at that site. 

January 1991 
User Training Plan 

Section 

3 

3.1 

Title 

Training 

Responsibilities 

Development of 

-

Content 

IdentifY staff requirements for the training. Include 

names or functions and the amount of time that will be 

needed, plus the impact on normal operations. Discuss 

responsibilities of government and contractor personnel, 

and those of developer and user personnel. Include 

special requirements as necessary. 

Identify staff responsibilities for development of the 

training curriculum. 

3.2 Conducting Training Identify staff responsibilities for conducting the 

training sessions. 

3.3 

3.4 

Attending Training 

Evaluation of 

Training 

January 1991 

Identify the staff members who will attend the training 

sessi<IDs. 

Identify the stafi' members who will evaluate the 

training sessions. 

2.4.4--User Training Plan 7 
User Training Plan 

Section 

4 

4.1 

4.2 

Title 

Development 

of Training 

Conducting Training 

8 User Training Plan-2.4.4 ' 

Content 

Describe resources needed fur the training sessiona. 

Include staff and equipment. 

Identify the resourees needed to develop the training 

curricula 

Identify the reso\ll'CeS needed to conduct the training 

sessions. 

January 1991 
User Training Plan 

Section 

5 

5.1.1 

5.1.2 

5.1.3 

5.1.4 

5.1.5 

Title 

-

Curriculum 

Objective 

Prerequisites 

January 1991 

Content 

Provide a detailed description of and outline for each 

training session. Include a separate subsection for each 

course. For example: 

5.1 Course 1 

5.n Coursen 

Include at a minimum the following infunnation. 

Describe the objective(s) of the eouree. 

Identify the knowledge base required for the course. 

Describe each eouree Wld the media or materials 

needed to present it. Include a CO\ll"!l8 outline. 

Provide information on characteristics of the course, 

including the number of instruction hours, maximum 

and minimum number of students, the type of training 

{for example, formal classroom, hands-on, self-study), 

the type of instruction {for example, lecture, video, 

demonstration), and qualifications of the insb-uctor{s). 

Liat specific materials necessary for the course (for 

example, publications, reference materials, films). 

2.4.4-User Training Plan 9 
User Training Plan 

6 

6.1 

6.2 

6.3 

Title 

Evaluation 

of Training 

Ways to Obtain 

Feedback 

Evaluation 

of Training 

Evaluation Report 

10 User Training Plan-2.4.4 

Content 

Describe training evaluation methods and 

reapoDSi.bilities. 

Present specific descriptions of training-related 

feedback methodologies to be employed. 

Describe the evaluation forms that will be employed 

and the units of measure that will be used to evaluate 

the training feedback. 

Describe the formal evaluation report that will be 

inclnded in the final Ussr Training Plan at the 

conclusion of the training activity. Include a summary 

analylli.s of evaluation forms completed during each 

training session. 

January 1991 
Cont.nt 

PROGRAM MAINTENANCE MANUAL 

(2.4.6 on OSM Documentation Requirements List) 

The Program Maintenance Manual is used by analysts and programmers who 

are maintaining or developing improvements to a new system or an 

enhancement to an existing system. It provides the information they need to 

understand the coded programs, the system's operating environment, and 

maintenance procedures. 

The Program Maintenance Manual contains detailed descriptions of programs 

and their operating environments. It explains maintenance procedures and, 

in an appendix, includes all program source code. 

Figure A-28 summarizes the information required in the Program Maintenance Manual by 

presenting the document's table of contents. Detailed explanations of the material that each 

section should contain are then found in the pages that fullow. 

January 1991 2.4.6--Program Maintenance Manual 1 
Figure A-28 

TABLE OF CONTENTS FOR PROGRAM MAINTENANCE MANUAL 

(2.4.6 on OSM Documentation Requirements llst) 

1, Introduction 

1.1 Background 

1.2 Scope 

1.3 Assumptions and Constraints 

1.4 Summary of the Program Maintenance Manual 

1.5 References 

2. Operating Environment 

2.1 Hardwal"il 

2.2 Support Software 

2.2.1 Operating System 

2.2,2 Compiler/Assembler 

2.2.3 Other Software 

2.3 Data Base 

3. Description of Programs 

3.1 Program 1 

3.1.1 Description 

3.1.2 Input 

3.1.3 Processing 

3.1.4 Output 

3.1.5 Interfaces 

3.1.6 Tables 

3.1.7 Run Description 

3.1.8 Sour<:e Code 

3.n Program n 

4. Program Maintenance 

4.1 Programming Conventions 

4.2 Verification Procedures 

4.3 Error Correction Procedures 

4.4 Special Maintenance Procedures 

4.5 Listings and Structul"il Charts 

Appendix A--Sonr<:e Code 

January 1991 2.4.6--Program Maintenance Manual 3 
Program Maintenan011 Manual 

Section 

1 

1.1 

1.2 

1.3 

Title 

Introduction 

Background 

Assumptions and 

ConstruiD.ts 

Content 

Provide appropriate baekground and summary 

information. 

Provide a brief overview of the new system or 

enhancement and why it is being implemented. 

Explain why the Program Maintenance Manual is 

lllleded, provide a brief overview of its organization, and 

indicate system-related topics that have been included 

in the manual or excluded from consideration. 

Describe any factors that may affect the applicability of 

the procedures described in the manual. 

1.4 Summary of the Provide a brief summary of the moat important 

Program Maintenance information in the manual. 

Manual 

1.5 References 

January 1991 

List pertinent standards, guidance, documentation, and 

any other materials used to prepare the m!lllual. 

Include vendor-supplied manuals; project 

documentation; other in-house documentation; and 

Federal, departmental, agency and industry standards 

and guidance. 

2.4.6--Program. Maintenance Manual 5 
Program Maintenance Manual 

Sectiou 

2 

2.1 

2.2 

2.2.1 

2.2.2 

2.2.3 

2.3 

Title 

Operating 

Envkonment 

Support Software 

Operating System 

Compiler/Asaembl.el' 

Other Software 

Data BIIBB 

Content 

Provide brief descriptions of the verious components of 

the operating environment of the new system or 

enhancement. 

Identify the equipment required to operate the new 

system or enhancement. Describe any unusual features 

that are implemented. Relate the hardware to the 

requirements for each program. Include the following 

information: 

• Processor and amount ofintemalatorage 

• Online and offiine storage, including media, form, 

and devices 

• Online and offline input and output devices 

• Data transmission devices. 

Identify the support software employed by each 

program. 

Identify and describe the operating system, including 

the version or release number and any unusual 

features implemented. 

Identify and describe the compiler/assembler, including 

the ver~~ion or release number and any unusual 

features implemented. 

Identify and describe any other software used (for 

example, data management systems, report generators, 

and so forth). 

Describe the data base, including file/record layouts, 

codes, units of measurement, format, and range of 

values. Reference the Data Dictionary for more 

complete information. 

6 Program Maintenance Manual--2.4.6 January 1991 
Program Maintenance Manual 

SectiOll 

3 

3.1.1 

.3.1.2 

3.1.3 

Title 

Description 

of Programs 

Description 

Input 

Processing 

January 1991 

Content 

Describe each program uaed by the new system or 

enhancement from the maintenance programmer's 

perspoctive. If describing a complex system, group the 

programs by application, describe the application, and 

relate each program and its function 00 the application. 

Use tables and matrices as needed 00 indicate ci'OBsreferences and relati001ships. Include separate 

subsections for each program or group of programs. 

For example: 

3.1 Program 1 

3.n Program n 

Include at a minimum the following information for 

each program or group of prograJrul. 

Identify the program by title, tag or label, and 

programming language. Identify all modules in the 

program and indicate the relationships among them. 

Describe the problems to be solved or the functions to 

be executed by the program and how the solution or 

execution ia acwmplished. 

Describe the data input to the program and provide a 

layout. Include information such as media, codes, units 

of measurement, format, and range of values. Provide 

CI'OBB-references to the Data Dictionary and Data BIIBe 

Specification. 

Describe proce~~sing characteristics relevBllt to the 

maintenance prograuuuer. For example: 

• Processing logic 

• Linkages 

• Variables and constants 

•Formulas 

• Error handling 

• Restrictiolll! and limitations 

• Locations, settings, internal switches, and flags 

• Shared storage. 

2.4.6----Program Maintenance Manual 7 
Program Mainl-mlance Manual 

Title 

3.1.4 Output 

3.1.5 Interfaces 

3.1.6 Tables 

3.1.7 Run Description 

3.1.8 Source Code 

Content 

Describe the output of the program and provide a 

layout. Identify the media used and all modulee 

employed. Provide ci"Oiis-refereru:es to the Data 

Dictionary and Data Base Specification. 

Describe interfaces with other BOftware. Include 

information such as data formats, messages, 

parameters, conversion requirements, i:uterface 

procedures, and media. 

Identify each table and its items. Deacribe the location, 

purpose, and structure of each. 

Describe the procedures used to run the program. 

Include loading, operating, temllnating, and l!lTPl' 

handling. 

Reference the Source Code in Appendix A. 

8 Program Maintenance Manual-2.4.6 January 1991 
Program Maintenance Manual 

Section 

4 

4.1 

4.3 

4.4 

4.5 

Title 

Maintenance 

Procedures 

Programmlni 

Conventions 

Error Correction 

Prooodu~ 

Special 

Maintell8Ilce 

Procedures 

Listings and 

Structure Chart.s 

January 1991 

Content 

Describe program maintell8Ilce activities. These 

activities can be grouped into one lll!ction or broken out 

by individual prograiDll or groups of programs, 

depending on their oonsisteucy from program to 

program. The fullowing information should be 

included. 

Identify and descn'be the programming conventions 

uaed to develop the new system or enhancement. 

Describe the procedures uaed to check the performance 

of the programs, both in general and following 

modifu:atiollf!. Include a reference to test data and 

testing procedures. 

Describe all error conditions, their causes, and 

procedures for correction. 

Describe any special procedures required to maintain 

the programs. Include information such as periodic 

purges of the data bases, temporacy modificatiOil!l fur 

leap years or century changes, and so forth. 

Reference, append, or describe how to obtain copies of 

program listings and flowcharts. 

2.4.6----Program Mainteuance Manual 9 
Purpose 

Content 

USER'S MANUAL 

(2.4.8 on OSM Documentation Requirements List) 

The User's Manual explains how to exocute the various functions of a new 

system or an enhancement to an existing system. It may be limited to one 

application or a series of applications. It serves as a reference document for 

use in preparing input data and explains how to interpret the results. 

Several factors determine whether a User's Manual is required and, if 

required, how much detail it should contain. The major consideration is the 

extent of user involvement with the new system or enhancement. 

The User's Manual addresses direct user involvement with a new system or an 

enhancement to an existing system; thus it should be written with a nontechnical rnader in mind. It explains how to prepare inputs to and interpret 

outputs from a particular application or aeries of applications. The manual 

covers three areas; general information about the system, an overview of the 

system, and detailed instructions for using the system. 

Because the best format for the user's manual depends on the application design as well as 

the target audience, the outline for the manual can be revised as necessary. 

Figure A-29 summarizes the information required in the User's Manual by presenting the 

document's table of contents. Detailed ro<planations of the material that each section should 

contain are then found in the pages that follow. 

January 1991 2.4.8--User's Manual 1 
FigureA-29 

TABLE OF CONTENTS FOR USER'S MANUAL 

(2,4,8 on OSM Docuntentatlon Requireroents List) 

1. Introduction 

1.1 Background 

1.2 Scope 

1.3 Assumptions and Constraints 

1.4 Summary of the User's Manual 

1.5 References 

2. System Overview 

3. Applications 

4. 

5. 

3.1 Application 1 

3.1.1 Operation 

3.1.2 Equipment 

3.1.3 Structure 

3.n 

3.1.4 Performance Characteristics 

3.1.5 Inputs, Data Preparation, and Outputs 

3.1.6 Data Base 

3.1.7 Interfaces 

Application n 

Procedures 

4.1 Application 1 

4.1.1 System Access 

4.1.2 Initiation 

4.1.3 Input 

4.1.4 Output 

4.1.5 Backup 

4.1.6 Error and Recovery 

4.1.7 File Query 

4.1.8 Audits and Controls 

4.n Application n 

Non-Routine Procedures 

January 1991 2.4.8--User's Manual 3 
User's Manual 

Section 

1 

1.1 

12 

1.3 

1.4 

1.5 

Title 

Introduction 

Background 

Assumptions and 

COilBtraints 

Summary of the 

User's Manual 

References 

January 1991 

Content 

Provide appropriate background and summary 

information. 

Provide a brief overview of the new system or 

enhancement and why the project was undertaken. 

Explain why the User's Manual is needed, provide a 

brief overview of its organi~tion, and indicate systemrelated topics that have been includad in the document 

or excluded from consideration. 

Describe any factors that may affect the procedures 

described in the User's Manual. 

Provide a brief summary of the moat important 

information in the User's Manual. 

List pertinent standards, guidance, doc:umentatian, and 

any other materials used to prepare the User's Manual. 

Include vendor-supplied materials; project 

documentation; other in-house documentation; and 

Federal, departmental, agency, and industry standards 

and guidance. 

2.4.S-User's Manual 5 
User's Manual 

Section Title 

2 System Overview 

6 User's Manual-2.4.8 

Content 

Discuss when and how the new system or enhancement 

is used and what advantages it provides to the 

organization. 

Identify and briefly describe the hardware and (if 

applicable) teleoommunications systems used by the 

new system or enhancement. 

Identify and briefly describe the software used by the 

new system or enhancement. Provide a Wagram 

showing the inputs, outputs, data :files, and sequence of 

operations. 

Identify and briefly de&cribe each prognun executed by 

the new system or enhancement. 

Identify each permanent file or data base that is a part 

of the new system or enhancement. 

January 1991 
User's Manual 

Section 

3 

3.1.1 

3.1.2 

3.1.3 

3.1.4 

3.1.5 

Title 

Operati= 

Equipment 

Structure 

Performance 

Characteristics 

Inputs, Data 

Preparation, 

and Outputs 

January 1991 

Content 

Describe the applications that make up the new system 

or enhancement from the functional perspective. 

Include a separate subsection for each application. For 

example: 

3.1 Application 1 

3.n Application n 

Include the following introductory information: 

• Purpose 

• Capabilities 

• Functions performed 

• When and how the application is used 

• Advantages provided to the organization. 

The remainder of the subsection should contain the 

following information. 

Show how the application relates to the functions of the 

organiz.ation that provides input to and receives outpnt 

from the new system or enhancement. Describe 

security and privacy considerations. 

Describe equipment related to use of the application. 

Describe the components that make up the application 

and describe their logical role in the application's 

operation. 

Provide quantitative infurmation on inputs, outputs, 

response times, processing times, and error rates. 

Provide qualitative information about flexibility and 

reliability. 

Describe data input to the application, the flow of data 

through the processing cycle, and the resulting output. 

Include any applicable ralationshipe among the inputs 

and outputs. 

2.4.8--User's Manual 7 
User's Manual 

Section Title 

3.1.6 Data Baae 

3.1.7 Interfaces 

8 Usel"s Manual-2.4.8 

Content 

Describe the files in the data ba!ie(s) supported, 

updated, or referenced by the application. Include the 

reasons why each file i.s maintained. 

Describe auy interfaces between this application aud 

other applications, as well8.ll applications to which this 

application may send data or from which it may receive 

W.ta. 

January 1991 
User's Manual 

Section Title 

4 Procedures 

4.1.1 System Access 

4.1.2 Initiation 

.u.s Input 

January 1991 

Content 

Provide the atep-by-atep procedures required to run 

each application. Include a separate subll8Ction for 

each application. For 8ll:ample: 

4.1 Application 1 

4.n Application n 

Include at a minimum the following information. 

Deecribe how to access system resources. Explain 

security and privacy procedures. 

Describe how to start the application. 

Define the requirements for preparing input data and 

parameters. The following considerations may apply; 

o Reasons for input 

• Frequency of input 

• Origin of the input data 

• Media used for the input data 

• Restrictions such as priority, security, and access 

limitations 

• Quality control actions such as checking to see if 

the data is reasonable, taking action when data 

appears to be in error, and documenting errors 

o Retaining or releasing data files that have 

been input. 

Describe the input fOrmat. Provide the layout forms 

used in initial preparation of program data and 

parameters. Explain each entry on the fonns. Describe 

input rules and conventions such as characters per line 

or per item, labels, sequence, punctuation, allowable 

and forbidden combinations, optional items, and 

controls. 

Provide examples of each complete input fonn. Include 

control or header, text, trailer, omissions, and repeats. 

2.4.8-User's Manual 9 
User's Manual 

Section Title 

4.1.4 Output 

4.1.5 Backup 

4.1.6 Error and Recovery 

4.1.7 File Query 

10 User's Manual-2.4.8 

Content 

Dsscribe requirements related to output. 

The following oonsiderations may apply: 

• Use (by whom and for what) 

• Frequency (daily, weekly, on demand, etc.) 

• Variations that may be available 

• Destination (for example, computer area, 

remote terminal) 

• Media (print, diskette, screen, etc.) 

• Quality control actions such as identification, 

checking for reasonable data, editing, and 

error correction 

• Disposition actiol1l! (retaining, releasing, 

distributing, or tral1llnlitting, with regard 

to priority and security). 

Provide the layout of each type of output. Include the 

layout forms and explain each entry such as header, 

body (text, columns, record layouts, etc.), and trailers or 

summaries. 

Provide examples of each complete input form. Define 

each infonnation variable and explain its use. Include 

its source and characteristics such as conditions under 

which it appears, range of values, unit of measure, etc. 

Describe any backup procedures that are executed by 

-~. 

Lillt error codes or conditions generated by the 

application. Include corrective actions that can be 

taken by the user. Indicate procedures to be followed 

to ensure that restart and recovery capability can be 

~d. 

Provide inBtructions necessary to initiate, prepare, and 

process data base queries. Describe query capabilities, 

fonilll, commands, and control instructions. Reference 

related materials that provide detailed information 

such as query capabilities, languages, conventions, and 

procedures. 

January 1991 
User's Manual 

Section Title 

4.1.8 Audits and Controls 

January 1991 

Content 

Deacribe system audit and eontrol procedures that are 

exeeuted by users. 

2.4.8-User's Manual 11 
User's Manual 

Title 

5 

12 User's Manual---2.4.8 

Content 

Provide detailed procedures to follow when emergency 

or non-routine situations occur while the new system or 

enhancement is operating. Include at a mjnjmum the 

per110nnel to contact in such situations. 

January 1991 
Purpose 

Content 

OPERATIONS MANUAL 

(2.4.9 on OSM Documentation Requirements IJst) 

The Operations Manual is gt~ared toward the ADP persounel who will actually 

run a new system or an enhancement to an existing system. It contains 

informatiou and procedures needed to efficiently operate the system once it 

enters the operations and maintenance phase of its life cycle. 

The Operations Manual describes job setup procedures, production schedules, 

control procedures, and job output distribution requirements specific to 

applications. It explains quality"control requirements and procedures such as 

verification of output, and it defines job streams for on-demand and 

predetermined processing cycles. Computer equipment, special software, and 

other processing requirements are specified. 

Figure A-30 summarizes the information required in the Operations Manual by presenting 

the document's table of contents. Detailed explanations of the material that each section 

should contain are then found in the pages that follow. 

January 1991 2.4.9--0perations Manual 1 

Figure A-30 

TABLE OF CONTENTS FOR OPERATIONS MANUAL 

{2,4.9 on OSM Documentation Requirements List) 

1. Introduction 

1.1 Background 

1.2 &:ope 

1.3 Assumptions and Constraints 

1.4 Summary of the Operations Manual 

1.5 References 

2. System Overview 

2.1 Hardware 

2.2 Software 

2.3 Programs 

2.4 Files and Data Bases 

3. Description of Runs 

3.1 Run Inventory 

3.2 Run Progression 

3.3 Run Descriptious 

3.3.1 Run 1 

3.3.1.1 Control Inputs 

3.3.1.2 Operating Procedures 

3.3.1.3 Input/Output Files 

3.3.1.4 Output Reporta 

3.3.1.5 Reproduced Output Reports 

3.3.1.6 Backup Procedures 

3.3.1.7 Restart/Recovery Procedures 

3.3.n Run n 

4. Non-Routine Procedures 

January 1991 2.4.9-0peratious Manual 3 
OperatiOI!B Manual 

Section 

1 

1.1 

1.2 

1.3 

1.4 

1.5 

Introduction 

Baekgrowtd 

Assumptions and 

Constraint!! 

Summary of the 

Operations Manual 

References 

January 1991 

Content 

Provide appropriate background and summary 

information. 

Provide a brief overview of the new system or 

enhancement and why the project was Wldertaken. 

Explain why the Operations Manual is needed, provide 

a brief overview of its organization, and indicate 

system-related topics that have been included in the 

document or excluded from consideration. 

Describe any factors that may affect the procedures 

described in the Operations Manual. 

Provide a brief summary of the most important 

information in the Operations Manual. 

List pertinent standard!!, guidance, doeumei~tation, and 

any other materials used to prepare the Operations 

Manual. Include vendor-supplied materials; project 

documentation; other in-house dooumentation; and 

Federal, departmental, agency, and industry standards 

and guidance. 

2.4.9---0perations Manual 5 
Operations Manual 

Section 

2 

2.1 

2.2 

2.3 

2.4 

Title 

System Overview 

Hardware 

Files and 

Databases 

6 Operations Manual-2.4.9 

Describe the hardware, software, proil'ams, files, and 

data bases used by the system. 

Identify and briefly describe the hardware and (if 

applicable) telecommunications systems used by the 

system. Reference additional documentation as 

appropriate. 

Identify and briefly deseribe the software used by the 

new system or enhancement. Provide a diagram 

showing the inputs, outputs, data files, and sequence of 

operations. Runs may be grouped by time cycles, 

organizational level, or other criteria. 

Identify and briefly describe each program executed by 

the new system or enhancement. Include title, number, 

and mnemwric reference. 

Identify each file or data base that is referenced, 

created, or updated by the system. Include the ti.Ue, 

mnemonic reference, storage medium, required storage, 

and other pertinent characteristiCII such as whether the 

file or data base ia temporary or permanent, index fi11111 

associated with the file or data base, and so forth. 

Jauuary 1991 
Operatioos Manual 

Section 

3 

3.1 

3.2 

3.3 

3.3.1.1 

3.3.1,2 

Title 

Description 

of Runs 

Run Inventory 

Run Progression 

Run Descriptions 

Control Inputs 

Operating 

Procedures 

January 1991 

Content 

Describe the functions executed by the system as it 

processes information. 

List all runs poasible, summarize the purpose of each, 

and identify schedules. Show the programs that are 

executed in each run. 

Describe how the runs progress from one to another so 

that the entire run cycle is completed. 

Organize tbe information on each run into the most 

lll!llful presentation for the operations center and 

operations personnel involved. Include a separate 

subsection for each run. For example; 

3.3.1 Run 1 

3.3.n Run n 

Include at a minimum the fullowing information. 

List the run stream control statements needed fur the 

=· 

Provide information for the operations center persannel 

and management. For example; 

• Run identificstion 

• Operating requirements 

• Initiation method {on request, predetermined 

cycle, etc.) 

• Estimated run time and turnaround time 

• Step-by-step procedures, including operator 

commands and messages 

• Procedures to be followed and individuals to be 

contacted in the event ofprobleme with the run. 

2.4.9--0peration.a Manual 7 
Operations Manual 

Section 

3.3.1.3 

3.3.1.4 

3.3.1.5 

3.3.1.6 

3.3.1.7 

TiU. 

Inp-ut/Output Files 

Outp-ut Reports 

Reproduced 

Output Reports 

Backup 

Procedures 

RestartJRecovery 

Procedures 

8 Operations Manual-2.4.9 

Content 

Provide information about files created or updated by 

the run. For Wl:ample: 

• File name or label 

• Recording media 

• Retention schedule 

• Disposition of file. 

Provide information on aach output report or each type 

of report. For example: 

• Report identification 

• Media 

• Volume of report 

• Number of copies 

• Distribution. 

Provide infOrmation on outp-ut reports that are 

computer-generated, then reproduced by other means. 

For example: 

• Report identification 

• Reproduction technique 

• Dimensione of paper or other media 

• Binding method 

• Distribution. 

Describe any procedures that may be ~uired to back 

up the system, programs, files, or data bases. 

Describe in detail procedures used to restart the run or 

recover from a failure. 

Januaey 1991 
Operations Manual 

Section 

4 

Title 

Non-Routine 

Prooodu~ 

January 1991 

Content 

Provide any necessary information about emergency or 

non-routine operations (for example, switching over to 

a backup system, turning the system over to 

maintenance programmers). Identify relevant 

documentation that describes the procedures to be 

followed under non-standard circumstances. 

2.4.9---0peratious Manual 9 
Content 

DATA BASE ADMINISTRATION PROCEDURES MANUAL 

(2.4.10 on OSM Documentation Requirement8 List) 

The Data Base Administration Procedure@ Manual provides guidelines and 

prooodllnls for managing and maintaining system·specific data bases. It is 

used by personnel at the data processing facility, where it may be kept 

separate or incorporated into a facility procedures manual that may cover 

multiple systems with data bases of their own. 

The Data Base Administration Procedures Manual contains the organization 

of data base administration functiol1!l; procedures related to data base 

performance, sizing, socurity, backup, and recovery; and descriptions of the 

user's view of the data base with cross-references to more detailed information 

in the Data Dictionary. 

Figure A-31 summarizes the information required in the Data Base Administration 

Procedures Manual by presenting the document's table of contents. Detailed explanatiol1!l 

of the material that each section should contain are then found in the page.s that follow. 

January 1991 2.4.10--Data Base Administration 1 

Figure A-31 

TABLE OF CONTENTS FOR 

DATA BASE ADMINISTRATION PROCEDURES MANUAL 

(2.4.10 on OSM Documentation Requirements List) 

L Introduction 

1.1 Backgrowtd 

1.2 Scope 

1.3 AssumptiOILI! and CoMtraints 

1.4 Summary of the Data Base Administration Proeedures Manual 

1.5 References 

2. Organizational Environment 

3. General Maintenance Procedures 

3.1 Design for Enhancements 

3.2 Coordination of Changes 

3.3 Scheduling 

4. Performance Proeedures 

4.1 System Utilities 

4.2 Problem Tracking and Reporting 

4.3 Monitoring and Control 

4.4 Space Utilization 

5. Sizing Procedures 

6. Security Procedures 

6.1 Controls 

6.2 Access 

6.3 Data Protection 

7. Backup and Recovery 

7.1 Overview 

7.2 Procedures 

7.3 Scheduling 

7.4 Problem Logging 

8. Data Dictionary 

8.1 Description 

8.2 Automated Procedures 

8.3 Manual Procedures 

January 1991 2.4.1Q.......Data Base Administration 3 
Figure A-81 (Continued) 

TABLE OF CONTENTS FOR 

DATA BASE ADMINISTRATION PROCEDURES MANUAL 

(2.4.10 on OSM Documentation Requirements List) 

9. Data Base and Record Structure 

9.1 Deaeription 

9.2 Standards and Requirements 

4 Data Base Administration-2.4.10 January 1991 
Data Base Administration Procedures Manual 

1 

1.1 

1.2 

1.3 

1.4 

1.5 

Title 

Introduction 

Backgrollll.d 

Assumptions and 

Constraiuta 

Summary of the 

Data Base 

Administration 

Procedures Manual 

References 

January 1991 

Conteut 

Provide appropriate background and summary 

infunnation. 

Provide a brief overview of the new system or 

enhancemant and why it is being implemented. 

Explain why the Database Administration Procedures 

Manual is needed, provide a brief overview of ita 

organization, and indicate aystem-related topics that 

have been included in the manual or excluded from 

consideration. 

Describe any factors that may affect the applicability of 

the procedures described in the manual. 

Provide a brief summary of the moat important 

information in the manual. 

List pertinentstandards, guidance, documentation, and 

any other materials used to prepare the manual. 

Include vendor-supplied materials; project 

documentation; other in-house documentation; and 

Federal, departmental, agency and industry standards 

and guidance. 

2.4.10---Data Base Administration 5 
" 

Data Base Administration Procedures Manual 

Section 

2 

Title 

Organizational 

Environment 

Content 

Describe the organizational hierarchy for the new 

system or enhanCflment. Identify key organizational 

units and personnel and describe their functions and 

responsibilities. 

6 Data Base Administration-2.4.10 January 1991 
Data Base Administration Procedures Manual 

Section 

3 

3.1 

3.2 

3.3 

Title 

General 

Maintenance 

"""''-

Design for 

Enhancements 

Coordination of 

c"""-

Scheduling 

January 1991 

Content 

Dei!Cribe general data base administration and 

maintenance procedures. 

Identify where the responsibility for data base 

administration lies in the design, review, and approval 

of enhancement!! to the new S)'11tem. 

Discuss the review and approval process for pl"Op(l@e() 

changes to the data base, the file layout, and the 

location of files. Discuss the change and eonfigumtion 

management controls. Describe change procedures, 

including each step in the process and individual and 

organizational responsibilities at each step. 

Identify the schedules associated with data baae 

maintenance activities. 

2.4.10--Data Base Administration 7 
Data Base Administration Procedures Manual 

Section. 

4 

4.1 

4.2 

4.3 

4.4 

Title 

PerfOrmance 

Procedures 

System Utilities 

... 

Problem 

_ 

Tracking 

Monitoring and 

Control 

Space Utilization 

Content 

Describe pl'CII:edures for evaluating the perf'Ol'mance of 

the data base and associated procedures for fine· tuning 

the data base. 

List the inventory of data base management and file 

management utilities used in the system. Describe 

their function and under what circumstances or at what 

regularly scheduled times they are used. 

Describe problem trackinz and reporting procedures. 

Identify the logs to be kept and the procedures for 

review and resolution of problems. 

Explain how data base performance will be monitored 

Describe the prooi!BII for analyzing space utilization. 

Identify associated procedures; for example. running 

and analyzing data base management system space 

utilization reports, allocating additional space, and 

reorganizing the data base. Describe utilities available 

for thia function along with respoDBibilities, 8CCell8 

procedures, and security controls. 

8 Data Base Administration-2,4.10 January 1991 
Data Basa Admicistration Procedures Manual 

Section TiUe 

5 Sizing Procedures 

January 1991 

Content 

Describe procedures and responsibilities for capacity 

planning and estimating n~quirements for space needed 

by the application in the future. 

2.4,10-Data Base Administration 9 
Data Base Administration Procedures Manual 

Section 

6 

6.1 

6.2 

6.3 

TiUe 

Security Procedures 

Controls 

Data Protection 

Content 

Describe procedures for controlling user aocess and 

ensuring the integrity or data. 

Describe the control mechanisms to enBure the integrity 

or the data base. 

Describe the procedures to prevent unwarranted llCOO!IS 

to the data base. 

Describe the methods used to protect the data from 

intentional or accidental misuse. 

10 Data Base Administration-2.4.10 January 1991 
Data Base Administratio.n Procedures Manual 

Sectio.n 

7 

7.1 

7.2 

7.3 

7.4 

Title Content 

Backup ll!ld Recovery Describe backup and recovery procedures. 

Overview Provide a summary of the procedures to be fullowed to 

back up the data base and to subsequently restore the 

data following an emergency situation. 

Procedures Describe the step-by-step :recovery process to be 

followed in backing up ll!ld restoring the data base. 

Backing up should be a routine ~~Drciae and covered in 

the run descriptions. If back-up procedures are 

included in the Operations Manual, that seetio.n can be 

referenced here as well. Restore/recovery procedUI"eS 

should also be described here, to the extent that they 

differ from program restart procedures. Where 

procedures are described, it is important that they are 

described in detail, for they will serve as instructions to 

operators and must be precise to ensure proper backup 

and recovery of the data base. 

Scheduling Detail the schedule for backup and recovery procedures. 

Determine the schedule of events to be fullowed in an 

emergency situation. 

Problem Logging Discuss the tracking mechanism for logging probleiilll 

during the recovery process. 

January 1991 2.4.10---Data Base Administration 11 
Data Base Administration ProcedUl'ea Manual 

Section 

8 

8.1 

8.2 

8.3 

Title 

Data Dictionary 

Description 

Automated 

"""""u~ 

Manual Procedures 

Content 

Describe the Data Dictionary and explBin how it relates 

to data base administration. 

Provide a description of and reference to the Data 

Dictionary. 

Identify the specific software utilized. 

access and reaponaibilitieB and 

administration respon.sibilities. 

Deflne user 

data base 

Describe tha method by which the documentation is 

maintained manually. Describe user or syatem 

developer requirements and responsibilities as well as 

data base administration responsibilities. 

12 Data Base Adm.inistratian-2.4.10 January 1991 
Data Base Adm.inistratioo Procedures Manual 

Sectioo 

9 

9.1 

9.2 

Title 

Data Base and 

Record Structure 

Descriptioo 

Standards and 

Requirements 

January 1991 

Cootent 

Describe the data b1.111e and file structures. 

Provide an 

Reference 

documents. 

overview of 

appropriate 

the data base structure. 

data base specification 

Describe the design structure and related requirements. 

Include any supplementruy information that will help 

data base technicians understand the structure and 

relationship of data bases and files and will make 

structure modification. 

2.4.10-Data Base Administration 13 

Appendix B. 

CUMULATIVE LIST OF REFERENCES 

AppendiJ< B 

CUMULATIVE LIST OF REFERENCES 

Department of the Interior 

Department of the Interior Departmental Manual. All current parts of the 

Department of the Interior Departmental manual are hereby incorporated into this 

manual as OSM policy. Individual parts specifically referenced herein are: 

Appendix B 

Part 110 DM 10, Organization of the Office of IRM. JWle 1981. 

Part 306 DM 2, ADP Standards H=dbook. 

Part 375 DM 1, IRM Program Management-Program Definition, Goals, 

Responsibilities. December 1982. 

Part 375 DM 2, Information Systems Management-IRM Policy and Program 

Coordination. 

Part 375 DM 4, IRM Program Management-IRM Strategic Planning. 

Part 375 DM 5, IRM Program Management-IRM Assessroent Program. 

Part 375 DM 7, IRM Program Management-Economic Analysis in Support of 

IRM Decision Making. 

Part 375 DM 12, IRNI Program Management-Information Resources 

Standards Program. 

Part 375 DM 19, IRM Program Management-Information Resources Security 

Program. 

Part 376 DM 4, Information Resourees Management-ADP Acquisition. J=e 

1988. 

Part 376 DM 6, ADP--ADP Cost AccoWlting, Cost Rerovery, and Sharing. 

Part 376 DM 10, We Cycle Management of AIS. 

Part 376 DM 11, Information Resources Management-ADP Resource 

Inventories. 

Part 376 DM 13, ADP-Automated Information Systems Management 

AWlWltability. 

Part 377 DM 2, Telecommunications. October 1983. 

Part 382 DM 11, Managing Records in Eledronic Form. 

Cumulative List of References B-3 January 1991 
" 

Part 383 DM 1-12, Management and Safeguarding of Privacy Act Records. 

Department of the Interior Property Management Regulations (IPMR). 

Department of the Interior Acquisition Regulations (DIAR), including: 

DIAR 1424.104 (Required contractual clauses for contracted operations) 

Department of the Interior Departmental Handbooks {available from Division of 

Printing and Publieations, Olfloo ri Administrative Services, Department of the 

Interior, Washington, DC 20240), including: 

DOl InfOTination Resources Security Handbook. 

Telecommunications Handbooks: 

Radio Communications Handbook. April 1986. 

Data Communications Handbook 

Telecommunications Terminology Handbook. Docember 1983. 

Telephone Systems Handbook. 4 January 1985. 

Local Area Network Guide. 2 October 1988. 

Department of the Interior, A Project Manager's Guide to BenefiUCost Analysis 

of Information Technology Investments, January 1989. 

Department of the Interior, A Project Manager's Guide to Application Systems 

Life Cycle Management {376 DM 10), August 1985. 

DOl Mainframe Strategy, May 1988. 

DOl Strategic Framewill"k for Information Resources Management, July 1988. 

Office of Surface Mining Reclamation and Enforcement 

Office of Surface Mining Directives. (Available from the Chief, Division of 

Management Services), including; 

Appendix B 

OSMRE Directive I:t\'F-11, Information Systems Management Program. 

October 1982. 

OSMRE Directive OPM-11, Information Systems Management Directorate 

Organization and Functional Statements. June 1987. 

Cumulative List of References January 1991 
Executive Office of the President, Office of Management and Budget 

Internal Control Guidelines, December 1982. 

Office of Personnel Management's Federal Personnel Manual. 

OMB Circular No. A-123, Internal Control Systems 

OMB Circular No. A-130, Management of Federal Information Resources 

OMB Circular No. A-127, Financial Management Systems 

OMB Circular A-130, Management of Federal Information Resources. 

December 1985. 

OMB Circular A-11, Preparation and Submission of Budget Estimates, Section 

43.2. 

Federal Laws/Regulations 

Computer Security Act of 1987 (PL 100-235). 

Department of Defense Authorization Act of 1982. 

Federal Managers Financial Integrity Act 

National Archives and Records Administration's regulations on records 

management. 

Paperwork Reduction Act of(44 USC 3506(cX8)) (PL 96-!511). 

Paperwork Reduction Reauthori7.ation Act of 1986 (PL 99-500) 

Privacy Act of 1974, as amended (5 USC 522a) 

General Services Administration 

General Services Administration's Federal Information Resources Management 

Regulations {FIRMR) on security, privacy, Automated Data Proeessing (ADP) and 

acquisition, telecommunications management and acquisition, and records 

management including: 

Appendix B 

FIRMR 201-33.003 (Reuse of ADPE) 

FIRMR 201-31 (Sharing ADP resourceB) 

FIRMR 201-32.104 (Computer security) 

FIRMR 201-23.103 (Thresholds) 

FIRMR 201-6 (Required contractual clauses for contracted operations) 

Cumulative List of References January 1991 
FIRMR 201·30.007 {Requirements analysis) 

FIRMR 201·30.009 (Analysis of alternatives) 

FIRMR 201·30.007(d)(9) and 201.34.002 (Performance Evaluation for 

current ADP system) 

FIRMR 201·30.009-3 (Findings to support the use of compatibility 

limited requirements) 

FIRMR 201·30.012·1 (Software conversion study) 

FIRMR 201·1L002(b) (Certified data to support sole source} 

FIRMR 201·11.002-1 (Certified data to support sole make/model) 

FffiMR 201·30.012 (Planned actions to foster competition) 

Federal Information Reoources Management Regulations (FIRMR) 

Supplement, Federal IRM Review Handbook, 1985. 

Federal Acquisition Regulations (FAR), including: 

FAR2.1 

FAR 24.104 (Required contractual clauses for contracted operations) 

Department of Commeree, National Bureau of Standards 

Federal Information Processing Standards (FIPS). FIPS PUBS are oold by the 

National Technical Information Service (NTIS), U.S. Department of Commerce. A 

FIPS PUBS Index summarizing each FIPS PUB is available from: 

Appendix B 

Standards Processing Coordinator (ADP) 

Institute for Computer Sciences and Technology 

Building 225, Room B·64 

National Bureau of Standards 

Gaithersburg, MD 20899 

Phone: (301) 975·2816 

All current FIPS PUBS are ineorporated in OSM policy by reference. FIPS 

PUBS specifically cited herein include: 

Guidelines for Documentation of Computer Programs and Automated 

Data Syatems, 30 June 30 1974, Federal Information Processing 

Standard Publication 38. 

Federal Information Processing Standard Publication 64, Gnidelines for 

Documentation of Computer Programs and Automated Data Syatems 

for the Initiation Phase, August 1979. 

Guidelines for Software Documentation Management, 6 June 6 1984, 

Federal Information Processing Standards Publication 105. 

Cumulative List of References January 1991 
Other Governmental OrllB.Jlizations 

Automated Application System Internal Control Guideline 

Department of the Navy, Naval Data Automation Command, Publication 15, Economic 

Analysis Procedures for ADP. 

Department of Treasury Directive 81-80, Electronic Funds and Securities Transfer 

Policy-Message Authentication. 

Federal Telecommunications Standards Committee. 

National Security Decision Directive 145. 

Other Non-Governmental Organizations 

American National Standards Institute (ANSI). 

Electronic Industries Association (EIA). 

Institute of Electrical and Electronics Engineers (IEEE) 

International Organization for Standardization (lOS). 

International Telegraphic and Telephone Consultative Committee (CCITI). 

AppendU. B 

Cumulative List of References B-7 January 1991 
'" 
" 

Appendix C. 

OFFICE OF SURFACE MINING 

MANAGEMENT INFORMATION SYSTEMS 

CONTACTS 
" 
Appendix C 

AppendixC 

OFFICE OF SURFACE MINING 

MANAGEMENT INFORMATION SYSTEMS CONTACTS 

Office of Surface Mining 

Chief, Divisiou of Management Information Systems 

1951 Constitution Avenue, N.W., Room 142 

Washington, D.C. 20240 

FTS 268-2916 

Commercial 202-208-2916 

Chief, SysWm DevelopmeDt OperatioDs and Mai.:o.Wnance Branch 

1951 Constitution Avenue, N.W. 

Washington, D.C. 20240 

Chief, Information Resource Management Branch 

1951 Constitution Avenue, NW, Room 125 

Washington, D.C. 20240 

OSM MIS Contacts C-'l January 1991