ML19323J314
| ML19323J314 | |
| Person / Time | |
|---|---|
| Issue date: | 10/24/1979 |
| From: | NRC OFFICE OF ADMINISTRATION (ADM) |
| To: | |
| Shared Package | |
| ML19323J310 | List: |
| References | |
| CON-NRC-10-80-390 NUDOCS 8006200005 | |
| Download: ML19323J314 (91) | |
Text
.
ATTACHMENT #4 m;ayWmggu%@WAM sTW25' 3 E
^
NRC Appendix 0903 Office of Administration Automatic Data Processing Standards Automated Systems i.
Documentation Handbook i
!o l
b l]
United States Nuclear Regulatory Commission l
8006100008
form NRC489 (1 76)
N U. S. NUCLEAR REGULATORY COMMISSION NRC MANUAL TRANSMITTAL NOTICE i
CHAPTER NRC-0903 AUTOMATIC DATA PROCESSING STANDARDS SUPERSEDED:
TRANSMITTED:
Number Date Number Date TN 0900-1 Chapter Chapter NRC-0401 10/24/79 Page page NRC-0903 10/24/79 Appendix Appendix I
REMARKS:
This chapter establishes NRC policy for the implementation of Government-wide ADP standards, and for the development and implementation of NRC ADP standards.
The appendix defines standards and procedures for the development, docu-mentation, operation and control of NRC computer software and systems, and for the operation and control of ADP equipment and environments.
h
- l s
U
\\
O
\\.
/
U.S. NUCLEAR REGULATORY COMMISSION NRC MANUAL Volume:
0000 General Part ;
0900 Automatic Data P.rocessing Management and Services ADM CHAPTER 0903 AUTOMATIC DATA PROCESSING STANDARDS 0903-01 COVERAGE I
This chapter establishes Nuclear Regulatory Commission (NRC) policy for the implementation of Government-wide automatic data processing (ADP) standards 4
and establishes policy for the development and implementation of NRC ADP standards.
0903-02 OBJECTIVES i
-021 To facilitate information interchange among automatic data proces-sing systems and applications within the NRC, and between the NRC and Federal agencies, departments, the private and other public sectors and n
across various manufacturer's ADP product lines.
fD) 022 To facilitate the economic and efficient use of automatic data proces-sing equipment through the implementation of hardware, software, systems, and documentation standards.
023 To assure compliance with pertinent Federal automatic data proces-sing standards, regulations, guides, policies and procedures.
024 To implement techniques and procedures to assure the integrity, privacy and security of data and information; and the integrity and security of software and hardware systems, operating equipment and environments.
0903-03 RESPONSIBILITIES AND AUTHORITIES f
031
.The Director, Office of Administration:
a.
periodically surveys ADP standards activities throughout NRC to ascertain that the provisions of this chapter are adequate and are being implemented; makes any changes needed.
b.
approves or disapproves requests for waivers from compliance with ADP standards.
'\\_.
l Approved: October 24, 1979
AUTOMATIC DATA PROCESSING STANDARDS -
NRC-0903-032 AUTOMATED SYSTEMS DOCUMENTATION 032 The Director, Division of Automatic Data Processing Support
( ADPS):
the development and implementation of and compliance with a.
assures NRC automatic data processing standards, policies and procedures for scientific / analytical computing and administrative, business and management information systems.
b.
disseminates and assures compliance with Federal automatic data
~
processing standards.
issues NRC automatic data processing standards in the appendix to c.
this chapter.
d.
serves as the NRC point of contact with the National Bureau of Standards for Federal Information Processing Standards (FIPS PUBS); and maintains liaison with the International Standards Organization (ISO),
the American National Standards Institute
( ANSI), and with other Federal agencies and non-Federal organiza-tions concerned with ADP standardization efforts.
e.
approves or disapproves requests for exemption or waiver from compliance with standards.
If disapproved, and requestor appeals decision, forwards the request to the Director, Office of Adminis-tration, for review and final decision.
f.
advises and assists NRC offices in ADP standardization efforts relating to scientific / technical and management information systems.
g.
coordinates the development of automatic data processing and tele-communications standards which have applicability in both areas.
h.
designates representatives from ADPS or other NRC offices, as appropriate to their area of responsibility to serve on task forces and committees pertaining to ADP standards.
i.
reviews and provides information and comments on proposed ADP standards that are being considered for Federal adoption.
j.
evaluates and assesses the impact of compliance with ADP standards.
k.
prepares and maintains an inventory of NRC, Federal, and industry automatic data processing standards implemented by NRC.
1.
identifies for use or develops and implements software standards for such as compilers, assemblers, languages for processing, codes, data formats,
interfaces,
and data base management systems configurations.
O Approved: October 24, 1979
AUTOMATIC DATA PROCESSING STANDARDS -
AUTOMATED SYSTEMS DOCUMENTATION NRC-0903-033 (m) m.
identifies and acquires or develops and implements documentation V'
standards for such as formats, flowchart symbols and flowcharting, feasibility and requirements analysis, system / subsystem specifica-tions, user / operations manuals, system maintenance manuals, and test plans.
develops and implements ADP standards, guides and procedures for n.
NRC use of computer systems of other Federal agencies and com-mercial vendors.
establishes procedures for the documentation, maintenance, access o.
and retrieval of ADP standards.
033 Director, Division of Security:
develops automatic data processing security policies and evaluates a.
standards and procedures developed by ADPS for compliance with those policies to assure the integrity, privacy and security of sensitive data and information and the integrity and security of software and hardware ' systems,
operating equipment and environments.
b.
reviews, periodically, operating ADP systems designated as contain-ing sensitive data, and evaluates compliance with established ADP security policies.
i O[
034 Director, Division of Contracts, assures that acquisition of ADP
(
l equipment, software and services conforms with the procedures and standards v'
contained in Federal Information Processing Standards Publications (FIBS PUBS), Federal Property Management Regulation (FPMR) 101-36.13, which implements FIPS PUBS into solicitation documents of Federal agencies, and NRC related ADP standards.
\\
035 Directors of Offices and Divisions:
j participate in the formation and development of NRC automatic data a.
processing standards.
b.
recommend changes in automatic data processing standards.
c.
assure compliance with automatic data processing standards as 4
appropriate to their area of responsibility.
d.
submit to the Director, Division of Automatic Data Processing Support, for approval, requests for exemption or waiver from compliance with standards and, if such request is denied, may appeal this decision to the Director, Office of Administration, with the approval of the Director, ADPS, appoint representatives, e.
who participate under guidance of the Director, ADPS, in inter-agency, intra-agency, and non-Federal Agency automatic data pro-
, []
cessing standardization efforts.
i
\\
l
(
Approved: October 24,.1979 I
l
AUTOMATIC DATA PROCESSING STANDARDS -
NRC-0903-04 AUTOMATED SYSTEMS DOCUMENTATION 0903-04 DEFINITIONS (FOR PURPOSES OF TIIIS CHAPTER)
Standard.
A prescribed set of rules, conditions or requirements concerned with the definition of terms; classification of components; delinea-tion of procedures; specification of materials, performance, design, or opera-tions; or measurement of quality and quantity in describing materials,
products, systems, services or practices.
0903-05 BASIC REQUIREMENTS 051 Applicability.
This chapter and its appendix are applicable to and mandatory for use by Headquarters Offices, Regional Offices, and, to extent consistent with contract provisions, NRC contractors and work performed under Interagency Agreements.
052 Appendix 0903.
This appendix provides standards, policies and procedures for the development, documentation, operation and control of NRC computer software and systems and for the operation and control of ADP equipment and environments.
053 References.
a.
P.L.89-306, " Brooks Bill," related to the establishment of uniform Federal automatic data processing standards.
b.
Federal Information Processing Standards Publication (FIPS PUB) published by the National Bureau of Standards.
c.
Federal Property Management Regulation (FPMR) 101-36.13, Implementation of Federal Information Processing Standards Publications (FIPS PUBS) into Solicitation Documents.
d.
ANSI
( American National Standards Institute) Standard N-413,
" Guidance for the Documentation of Digital Computer Programs."
e.
FORTRAN ANSI Standard, X3.9 - 1978.
f.
PL/1 ANSI Standard, X3.53 - 1976.
g.
FPMR 101-36.1303 - 1, 2, 3, 4 and 5; definitions of standard termi-nology, hardware, software, applications, and data standards.
h.
Chapter NRC-0133,
" Organization and Functions,
Office of Administration. "
i.
Chapter NRC-2101, "NRC Security Program."
j.
NRC Bulletin 0850-2, "bianagement of ADP Activities."
O Approved: October 24, 1979
AUTOMATIC DATA PROCESSING STANDARDS -
AUTOMATED SYSTEMS DOCUMENTATION NRC Appendix 0903
\\
/
O CONTENTS Page Part 1 DOCUMENTATION WITHIN THE SOFTWARE LIFE CYCLE A.
Scope.........................................................
1 B.
Phases........................................................
1 t
C.
Document Types..........
2 Part 2 DOCUMENTATION CONSIDERATIONS 1
A.
Responsibilities..............................................
5 B.
Document Audiences............................................
5 i-C.
Flexibility...................................................
6 D.
Document Format...............................................
7 l
E.
Flowchart Symbols and Flowcharting............................
8 I
Part 3 CONTENT GUIDELINES FOR DOCUMENT TYPES 1
A.
Automated System Feasibility and Requirements
]!
Analysis...............................
11 B.
Automated System / Subsystem Specifications.....................
27 j
C.
Automated System User / Operations Manual.......................
43 i
D.
Automated System Maintenance Manual...........................
53 t
E.
Automated System Test Plan....................................
55
~
F.
Automated System Test Analys.s Report..........
63 EXHIBITS 1
Standard Title Page.............................................
71 2
Amendment Page.....................................................
72 3
Cost and Cost Comparison Estimates.................................
73 3
4 Questionnaire for System Controls and Audit Trails.................
81 5
Description of System Controls and Audit Trails....................
87 6
Cross Reference Chart Format.......................................
91 4
I n v
i Approved:
October 24, 1979 i
4 y
.wm p-e--
p
AUTOMATIC DATA PROCESSING STANDARDS -
AUTOMATED SYSTEMS DOCUMENTATION NRC Appendix 0903 PART 1 DOCUMENTATION WITHIN THE SOFTWARE LIFE CYCLE A.
Scope.
Computer programs and automated data systems evolve in phases from the time that an idea to create the software occurs through the time that the software producss the required output.
It is recognized that there are in current usage many different terminologies to identify the phases and the stages within the phases. The phases applicable to the software life cycle are:
problem analysis, system development, and operation. The development phase is further sub-divided into three stages (Design, Programming, and Testing).
This publication provides content guidelines for the document types generally prepared during the problem analysis and development phases.
Figure 1 relates the preparation of the document types to the stages within these two phases. Content guidelines for the document types are provided
~
in Part 3.
B.
Phases. While the terminology used to describe the phases is arbitrary, it provides a convenient framework within which the development of software may be discussed.
(/
FIGURE 1.
Documentation Within the Software Life Cycle l
INITIATION OPERATION PHASE DEVELOPMENT PHASE PHASE l
Design Programming Test Stage Stage Stage FEASIBILITY SYSTEM /
USER /
TEST FOLLOW UP AND SUBSYSTEM OPERATIONS ANALYSIS REVIEWS REQUIREMENTS SPECIFI-MANUAL REPORT ANALYSIS CATIONS AUDITS SYSTEM MAINTENANCE PERFORMANCE MANUAL EVALUATION TEST PLAN
\\
iv/
1 Approved: October 24, 1979
NRC App:ndix 0903 AUTOMATIC DATA PROCESSING STANDARDS -
P;rt 1 AUTOMATED SYSTEMS DOCUMENTATION 1.
Problem Analysis Phase.
During this
- phase, the detailed requirements, alternative solutions,
recommended hardware and software, costs, benefits, and feasibility of the proposed system are determined.
The results of this analysis are set forth in the " Feasibility and Requirements Analysis" document.
2.
Development. During the Development Phase, the detailed specifica-tions for the system are determined and the software is then defined, programmed, and tested.
Documentation is prepared during this phase to provide an adequate record of the technical information developed.
Development Stages.
While the terminology used to describe the stages is arbitrary, it provides a convenient framework within which the development of the document types may be discussed.
a.
Design.
During the design stage, the design alternatives, specific requirements, and functions to be performed are analyzed and a design is specified.
b.
Programming.
During the programming stage, the software is coded and debugged.
Documents to be prepared during this stage include the Users / Operations Manual, System Maintenance Manual, and Test Plan.
c.
Test. During the test stage, the software is tested and related documentation reviewed.
The software and documentation are evaluated in terms of readiness for implementation.
The test analysis report is also prepared.
3.
Operation.
During the Operation Phase, the software is maintained, evaluated, shortcomings are detected, and enhancements are made as additional requirements are identified.
C.
Document Types. The purpose of each of the document types, described in further detail in Part 3, is defined in the following paragraphs.
1.
Feasibility and Requirements Analysis.
Provides a basis for the mutual understanding between users ard designers of the initial definition of the sof tware, including the requirements, operating environment, data requirements and technical information about data I
collection, communications requirements, and the development plan.
2.
System / Subsystem Specification.
Specifies for analysts and p ro-grammers the requirements, operating environment, design characteristics, data base and program specifications for a system or subsystem.
O Approv'ed: October 24, 1979 2
AUTOMATIC DATA PROCESSING STANDARDS -
NRC Appendix 0903 AUTOMATED SYSTEMS DOCUMENTATION Part 1 p
4 A--)
i 3.
User / Operations Manual.
Describes the functions performed by the system such that the user organization can determine its applica-bility and when and how to use it. It serves as a reference docu-ment to define the services available from the system to include input data and parameter preparation, output products, editing criteria, error detection, and operational characteristics.
4.
System Maintenance Manual.
Provides the system maintenance staff-with the information necessary to understand the programs, their operating environment, and their maintenance procedures.
5.
Test Plan.
Provides a plan for acceptance testing of the system; detailed specifications, descriptions, and procedures for all tests; and test data reduction and evaluation criteria.
6.
Test Analysis Report.
Document the test analysis results and findings, prcsent the demonstrated capabilities and deficiencies for review, and provide a basis for preparing a statement of software readiness for implementation.
v b
l O).
.(%s i
3 Approved: October 24, 1979 i
-r
AUTOMATIC DATA PROCESSING STANDARDS -
AUTOMATED SYSTEMS DOCUMENTATION NRC Appendix 0903 g
(
)
ws PART 2 DOCUMENTATION CONSIDERATIONS Documentation preparation should be treated as a continuing effort, evolving from preliminary drafts, through changes and reviews, to the documentation and software delivered.
The ' extent of documentation to be prepared is a function of agency management practices and the size, cost complexity and risk of the project.
A.
Responsibilities. The ADP project manager is responsible for determining the following regarding documentation.
1.
What document types apply, should be prepared, and why.
Also should justify reasons for not preparing certain documents.
2.
The formality, extent, and detail of the documentation.
3.
Responsibilities and a schedule of preparation for the documentation.
4.
Procedures and schedule of review, approval, and distribution and the distribution list.
p) 5.
Responsibilities. for documentation maintenance and change control
(
through the development phase.
6.
Accomplishment of documentation in accordance with Chapter NRC-2101 for systems possessing classified, personal, proprietary or sensitive data.
The formality, extent and level of detail, and other determinations are made by the ADP project manager.
In general, as the size, complexity, cost and risk of a project increase, so does the need for formality, extent, and level of detail of the documentation. The Users / Operations and System Maintenance Manual should be formal since they support the use of the software, particularly if the software will be used outside of the developing organization or if extensive changes are expected during the life of the sof tware.
B.
Document Audiences.
Each document type is written for a particular
" audience. " The audience may be an individual or a group of individuals who are expected to use the document contents to perform a function, e.g.,
operation, maintenance, design, programming.
The information should be presented using the terminology and level of detail appropriate to the audience.
~
)
v 5
Approved:
October 24, 1979
NRC Appendix 0903 AUTOMATIC DATA PROCESSING STANDARDS -
Part 2 AUTOMATED SYSTEMS DOCUMENTATION C.
Flexibility.
Flexibility in the use of the document content guidelines is provided by the basic organization of contents. An attempt has been made to provide an internally consistent organization scheme.
The following paragraphs describe various options which should be considered.
1.
" Sizing" of Document Types.
Each document type outline may be used to prepare documents that range from a few to several hundred pages in length. The size depends on the size and complexity of the project and the judgment of the project manager as to the level of detail necessary for the environment in which the software will be developed or run.
2.
Combining or Expanding Documents.
When a system is extremely large or is to be documented in a modular fashion, a document may be prepared for each module. In some cases, the size of a document may necessitate that it be issued in multiple volumes to allow ease of user reference.
In such cases, the document should be separated at a section division. The contents of the Test Plan document type, for example,
may be separated between the sections of plan,
specifications and evaluation, and specific test descriptions.
3.
Format. The content guidelines in Part 3 have been prepared using a generally consistent format.
Use of this particular format is encouraged but is not essential, if adequate justification can be presented.
4.
Sequencing
_ mts.
In general, the order of the sections and paragraphs _ a particular document type must be the same as shown in the content guidelines in Part 3.
5.
Documenting Multiple Programs or Multiple Files.
Many of the document type content outlines anticipate and are adaptable to documenting system and its subsystems, multiple programs, or multiple files.
All of these outlines can, of course, be used for a single system, subsystem, program, data base, or file.
6.
Section/ Paragraph Titles.
In general, the titles of sections and paragraphs should be the same as shown in the content guidelines.
~
The titles may be modified to reflect terminology unique to the software being documented if the change significantly enhances the presentation.
7.
Expansion of Paragraphs. Many of the document types have a para-graph with a general title and a list of factors that migl't be discussed within that paragraph. The intent of the content guidelines is not to prescribe a discussion of each of these items, but to suggest that these items be considercd in writing that paragraph. These and all other paragraphs may be expanded and further subdivided to enhance the presentation.
O Approved: October 24. 1979 6
= _ _ - -.
AUTOMATIC DATA PROCESSING STANDARDS -
NRC Appendix 0303 AUTOMATED SYSTEMS DOCUMENTATION Part 2 8.
Flowcharts / Decision Tables.
The graphic representations of some problem solutions ara treated best in the form of flowcharts, others in the form of decision tables. Either may be included in or appended to the documents produced.
9.
Forms.
Some of the information specified in a paragraph in the i
content guidelines may be recorded on forms. If so, the form can be referenced from the appropriate paragraph.
The use of standard forms is encouraged. Various forms are available; however, none of these forms are mandatory and have not. been included in the documentation Guidelines.
4 D.
Document Format 1.
General. The format and physical standards for system documenta-I tion shall, in general, be in accordance with the instructions for preparation of appendix handbooks contained in NRC Appendi:: 0201.
a.
All documents are to be printed on 8-\\" x 11" paper.
b.
A 3/4-inch margin shall be allowed at the top of the page and the right and left margins. A minimum of 1 inch shall be allowed at the bottom of the page, All text shall be typed within the prescribed margins.
c.
Each document shall contain the title page, amendme c page, and i
a table of contents.
l t
d.
Each page shall be identified with the system name in the inner top corner and document numlM r in the outer top.:orner; and in the outer bottom corner:
" Approved:
(Date"; or " Revised:
i (Da te). "
e.
Section, paragraph, and m;bparagraph identification within each document shall be:
A.
1.
l a.
(1)
(a) 1 a
hi (G
7 Approved: October 24, 1979
NRC App:ndix 0903 AUTOMATIC DATA PROCESSING STANDARDS Part 2 AUTOMATED SYSTEMS DOCUMENTATION.
f.
The page number shall be centered at the bottom of each page.
2.
Standard Title Page. (See Exhibit 1) a.
System Name.
The name assigned to the system shall be entered.
b.
Document Name. Each document shall be identified by the " type document" name as noted in Part 1.D, followed by the System and Module name.
c.
Date. Each document will be dated after the necessary approval signatures have been affixed.
d.
Contract Number.
Each document shall contain the number of the contract which authorized the work, if applicable.
e.
Author.
The author or principle contributing authors shall sign,
f.
Approved. The designated reviewers or supervisor shall sign to indicate approval.
3.
Amendment Page.
When modifications are made to any system,
regardless of the phase or stage which it is in, the project manager must make the determination of whether existing documents should be amended (see Exhibit 2).
As each arendment to the document is prepared, it shall be reviewed and approved by the person who approved the original document or by his designated representative.
The amendment page shall be completed with the date, amendment number (sequential number beginning with 1), the work order number or project number, the name of the author, the name of the approval personnel, and a list of the pages affected by the amendment.
E.
Flowchart Symbols and Flowcharting 1.
Flowchart Symbols. The flowchart symbols adopted as an American Standard in FIPS PUB 24 are prescribed for manually prepared flowcharts.
2.
Types of Flowchart Representation. The following terms identify the
~
types of flowchart representations for ADP documentation:
a.
System Data Flowchart.
A symbolic representation of the process through which dan will flow. The flowchart illustrates input and output for each major step in the system, whether or not equipment processing is required. A narrative description, to enhance the understanding of the flow, should accompany the system data flowchart.
The description should O
Approved: October 24, 1979 8
i AUTOMATIC DATA PROCESSING STANDARDS -
NRC Appendix 0903
~ AUTOM/3TED SYSTEMS DOCUMENTATION Part 2 O
\\
be cross-referenced to the symbols on the flowchart. Flowchart will reflect the interrelationships of programs and data (Files / Records) and identify the data input and output media (CRT, CARD, etc).
b.
Function Flowchart.
A symbolic representation of the major operational processing functions contained within the system.
This flowchart shows the major Functions in structured Top-Down or Modular Form.
c.
Detailed Logic Flowchart and Dec.ston Tables.
A symbolic representation of the more detailed logic of a function for which the program will be written.
The use of decir ion tables is encouraged and they may replace the detailed logic flowchart.
3.
Rules for Flowchart Preparation.
a.
All flowcharts shall be drawn on
- Form,
" Flowcharting Worksheet. " (NRC Form 107) b.
The identification block on the Form 107 must be completed.
c.
Draw flowcharts using the standard ANS symbols as defined in FIPS Pub. 24.
d.
Each symbol identification shall be unique within the' flowchart of the system package.
4 l
i b'
l DG 9
Approved: October 24, 1979
--_4
-aq s_.w,.
--9 g-e..w--
AUTOMATIC DATA PROCESSING STANDARDS -
AUTOMATED SYSTEMS DOCUMENTATION NRC Appendix 0903
( N.
O PART 3 CONTENT GUIDELINES FOR DOCUMENT TYPES Part 3 provides content guidelines for the following document types discussed in Parts 1 and 2.
A.
Automated System Feasibility and Requirements Analysis B.
Automated System / Subsystem Specification l
C.
Automated System User / Operations Manual D.
Automated System Maintenance Manual 4
E.
Automated System Test Plan F.
Automated System Test Analysis Report The document. types are presented in the order of development within the system life cycle. Included for each document type are a table of contents and a description of the contents of that document type.
A.
AUTOMATED SYSTEM FEASIBILITY AND REQUIREMENTS ANALYSIS The purpose of the Automated System Feasibility and Requirements -
Analysis Document is to provide a basis for the mutual understanding between users and designers of the initial definition of the system m
including the purpose, objectives, requirements, operating environment, information products, cost, benefits, and development plan.
i i
i t
i V.
11 Approved: October.24,1979
AUTOMATIC DATA PROCESSING STANDARDS --
NRC Appendix 0903 AUTOMATED SYSTEMS DOCUMENTATION Part 3 p
5is AUTOMATED SYSTEM FEASIBILITY AND REQUIREMENTS ANALYSIS CONTENTS Page
~
SECTION 1.
GENERAL INFORMATION........................................
15 1
15 a.
S u mm a ry......................................................
b.
Environment..................................................
15 c.
References."..................................................
15 SECTION 2.
0VERVIEW...................................................
15 15 a.
Background...................................................
15 b.
Objectives...................................................
c.
Existing Methods and Procedures..............................
15 d.
Proposed Methods and Procedures..............................
15 e.
Summary of Benefits..........................................
16 16 f.
Summary of Impacts...........................................
(1) Equipment Impacts.......................................
16 (2) Software Impacts........................................
16 s
(3) Organizational Impacts..................................
16 (4) Operational Impacts.....................................
17 (5) Development Impacts.....................................
17 (6) Information Impacts.....................................
18 g.
Cost Considerations..........................................
18 i
h.
Alternative Proposals........................................
19 19 1.
System Reliability...........................................
20 j.
Privacy / Security............................................
21 SECTION 3.
REQUIREMENTS...............................................
21 t
a.
Description..................................................
b.
Functions....................................................
21 c.
Performance..................................................
21 21 (1)
Accuracy................................................
i (2)
Validation..............................................
21 21 (3)
Timing;.................................................
21 (4)
Flexibility.............................................
\\
\\
13 Approved: October 24, 1979
t l
1 l
NRC App:ndix 0903 AUTOMATIC DATA PROCESSING STANDARDS -
l Part 3 AUTOMATED SYSTEM DOCUMENTATION CONTENTS (Continued)
Page d.
Inputs /0utputs Data Requirements...........................
22 e.
Data Collection...............................
22 f.
Fail ure C: ntingencies...................
23 SECTION 4.
OPERATING ENVIRONMENT....................
24 a.
Equipment....
24 b.
Support Software.............................................
24 c.
Interfaces........................................
24 d.
Security and Privacy..........
24 e.
Controls...................
24 SECTION 5.
DATA COMMUNICATIONS REQUIREMENTS....................
24 a.
Overview.....................................................
25 b.
Network Requirements......................................
25 SECTION 6.
DEVELOPMENT PLAN...............
26 0
N O
Approved: October 24, 1979 14
l AUTOMATIC DATA PROCESSING STANDARDS -
NRC Apptndix 0903 AUTOMATED SYSTEMS DOCUMENTATION Part 3 bl
'1.
GENERAL INFORMATION a.
' Summary.
Briefly summarize the problem to be resolved by the intended system, proposed solution (s), and any recommendations of the author (s) of this document.
b.
Environment.
Identify the project sponsor, developer, user, and computer center of network where the system is to be implemented.
This should be demonstrated by the citation of specific legislation, federal regulation, NRC manual chapters or other sources of authorization.
c.
References. List applicable references, such as:
(1) Project request (authorizations).
(2) Previously published documents on the project.
(3) Documentation concerning related projects.
(4) FIPS publication and other referenced documents.
2.
OVERVIEW a.
Background.
Present the purpose and scope of the software, and
! [m) any background information that would orient the reader.
Explain l
U/
relationship with other software.
l b.
Objectives.
State the major performance objectives of the software, 1
including examples. Identify anticipated operational changes that will affect the software and its use, c.
Existing Methods and Procedures. Describe the current methods and procedures that attempt to satisfy the existing objectives.
Include information on:
(1) Organizational and personnel responsibilities.
(2) Equipment available and required.
(3) Volume and frequency of inputs and outputs.
(4) Deficiencies and limitations.
(5) Pertinent cost considerations.
Illustrate the existing date flow ' from data acqu'sition through its processing and eventual output.
Explain the sequence in which operational functions are performed by the user.
d.
Proposed Methods and Procedures.
Describe the propased software and its capabilities.
Identify techniques and procedures from its capabilities.
Identify techniques and procedures from other
/
}
(
w/
15 Approved: October 24, 1979 l
NRC Appendix 0903 AUTOMATIC DATA PROCESSING STANDARDS -
Part 3 AUTOMATED SYSTEMS DOCUMENTATIOt{
software that will be used or that will become part of the proposed sof tware.
Identify the requirements that will 'oe satisfied by the proposed software. Include information on:
(1) Organizational and personnel responsibilities.
(2) Equipment available and required.
(3) Volume and frequency of inputs and outputs.
(4) Deficiencies and limitations.
Illustrate the proposed data flow to present an overall view of the planned capabilities.
Describe any capabilities in the existing software that may be changed by the proposed software. State the reasons for these changes. Explain the sequence in which operational functions are to be performed by the user.
e.
Summary of Benefits.
Itemize benefits to be obtained from the proposed software, such as:
(1) New capabilities.
(2) Upgraded existing capabilities.
(3) Elimination of existing deficiencies.
(4) Improved timeliness, e.g., decreased response time or process-ing time.
(5) Elimination or reduction of existing capabilities that are no longer needed.
f.
Summary of Impacts.
Summarize the anticipated impacts of the proposed softy'ere on the present system, in the following categories:
(1) Equipment Impacts.
Summarize changes to currently available equipment, as well as new equipment requirements and building modifications.
(2) Software Impacts.
Summarize any additions or modifications needed to existing applications and support software in order to adapt them to the proposed software.
(3) Organization Impacts.
Summarize organizational impacts such as:
(a) Functioual reorganization.
O Approved: October 24, 1979 16
6 AUTOMATIC DATA PROCESSING STANDARDS -
NRC ~ Appendix 0905
' AUTOMATED SYSTEMS DOCUMENTATION Part 3
,9 h
(b) Increase / decrease in staff level.
(c) Upgrade / downgrade of staff skills.
(4) Operational Impacts.
Summarize operational impacts, such as modifications to:
.(a) Staff and operational procedures.
(b) Relationships between the operating center and the users.
(c) Procedures of the operating center.
i (d) Data (sources, volume, medium, timeliness).
(e) Data retention and retrieval procedures.
(f)
Reporting methods.
(g) System failure consequences and recovery procedures.
(h) Data input procedures.
(i)
Computer processing time requirements.
\\
(5) Developmental Impacts.
Summarize developmental impacts, such g
as:
.. a) Specific activities to be performed by the user in support
(
of development of the proposed software.
(b) Resources required to develop the data base.
(c) Computer processing resources required to develop and test the new software.
(d) Address the technical feasibility of the proposed solution.
The proposed solution must be technically faasible both in terms of tested, established ADP technology and also' in terms of an organizatiorfs own resources. These resources include in-house resources and those to which the organization has access. The level of technical expertise of an organization's personnel and the resources and the time required to adequately train them should both be viewed as technical feasibility considerations.
n
(%/
-)
17
. Approved: October 24, 1979.
NRC App:ndix 0903 AUTOMATIC DATA PROCESSING STANDARDS -
Part 3 AUTOMATED SYSTEMS DOCUMENTATION (6) Information Impacts.
Summarize major changes in information flow to and from the user organization that will be caused by or is a prerequisite to operation of the proposed system.
g.
Cost Considerations.
Describe resource and cost factors that may influence the development, design, and continued operation of the proposed system (see Exhibit 3).
Discuss other factors which may determine requirements, such as interfaces with other automated systems, telecommunication facilities, and security costs such as devices,
guard services, personal clearance, and construction,
existng and under development. In terms of cost considerations, the system proposed must be economically feasible.
Requirements must reflect adequate management evaluation of the cost vs. benefits of the proposed system and the alternate solutions considered. The most economically feasible solution is that one which costs least but still satisfies the stated requirements.
In determining the costs of the proposed system and the alternatives, all costs throughout the entire life of the system (from system conception through development through operation and maintenance) must be considered. The costs include, but are not limited to, the following:
(1) Training of in-house personnel.
(2) Gathering of the necessary data for developing the ADP System Plan.
(3) Cost of money as specified in OMB Circular A-94.
(4) Cost of any hardware and special software required.
(5) Cost of design up to the point of programming.
(6) Cost of programming.
(7) Cost of testing and debugging.
(8) Cost of documentation and the training of user and support personnel.
(9). Cost of operations, including data entry, supplies data control, computer operators personnel, data transmission, and data gathering and' editing.
(10) Cost of post implementation audit.
(11) Cost of any site development.
(12) Cost of consultants or contracts.
O Approved: October 24, 1979 18
AUTOMATIC DATA PROCESSING STANDARDS -
NRC Appendix 0903 AUTOMATED SYSTEMS DOCUMENTATION Part 3
-~
l(j (13) Cost of managing the development of the system.
(14) Cost of data reduction / conversion from existing automated system and/or manual process.
(15) Cost of system maintenance (hardware and software).
(16) Cost of computer use (development and continued production).
h.
Alternative Proposals.
If alternative systems have been examined to satisfy the requirements, describe each alternative.
Compare and contrast the alternatives. Explain the selection reasoning.
(1) It is necessary to document all reasonable alternative solutions to the prob!em rad demonstrate why each was less satisfactory than the proposed system.
The alternatives considered and documen%d may be either very general in nature, very specific in nature, or somewhere in between. On the very general level, the alternatives such as maintain the " status quo" or totally redesigning a
batch application system into an on-line transaction processing system would fall into this category. An example of more specific selection among alternatives might involve a choice of one type of intermediate storage device over another.
g]
(2) Again, on the very general level, some alternatives to be
[tj considered might involve solution to the problem by changing the way of doing business or by eliminating a function rather than automating it.
Such types of alternatives should be considered and documented.
i.
System Reliability.
As an organization's dependency on automatic data processing increases, a point is reached where serious con-sequences are suffered if the system fails to perform at a planned level of availability.
The percentage of total up time is usually a meaningless criterion unless it can be tied to other data.
Some of these parameters are the median and mean time between failures, the number and distribution of those failures, the median and mean time to repair and most important of all, the availability of the system to the user.
The frequency and distribution of down time is usually more important (within limits) than the duration of the down time. When a user has been processing a 3-hour job for 2 hours2.314815e-5 days <br />5.555556e-4 hours <br />3.306878e-6 weeks <br />7.61e-7 months <br /> and the system goes down for 10 minutes, the user may have to recubmit the whole job. To the data center, they " lost" 10 minutes but the usar lost 2 hours2.314815e-5 days <br />5.555556e-4 hours <br />3.306878e-6 weeks <br />7.61e-7 months <br /> plus his resubmission time plus his time waiting in the job queue.
(1) Management must decide the level of service that the ADP system will provide. They can only do this if the study team preparing this document considers it in its investigation and responds appropriately.
All too of ten,
management will pursue l
i C/
19 Approved: October 24, 1979
~
NRC App;ndix 0903 AUTOMATIC DATA PROCESSING STANDARDS -
Part 3 AUTOMATED SYSTEMS DOCUMENTATION a long-range plan toward an integrated on-line data base system without adequate planning for the reliability factors.
This usually happens because management does not have any experience with being without certain information and finds it difficult to visualize the consequences throughout the organization should this occur.
(2) Reliability can be obtained in several ways.
Such things as uninterruptible power supply, redundancy, sensors, etc., all have a cost both in direct dollars for hardware and software and
^
in overhead for design, controls, procedures, and increased system complexity.
Management must set the bounds for the system designers who can then respond with cost estimates for the proposed reliability level.
(3) In considering design criteria to increase reliability, attention should be given to avoiding, where possible, serial dependent processes and to configuring ADP systems where subsystems can become self-organizing for at least some period of time with slow systems degradation.
For example, a hardware minicomputer communications processor can continue to send and receive messages when the central CPU is down.
(4) ADP system interruptions will vary from unit to unit, however, some generalizations can be made.
(5) The current technology is such that hardware errors are declining and software and personnel errors are increasing. In an average ADP System the largest source of error is probably personnel followed by software.
ADP System designers should consider these aspects.
j.
Privacy / Security.
The Privacy Act of 1974 imposes numerous requirements upon Federal agencies to prevent the misuse of infor-mation about individuals and assure its integrity and security. These requirements can be met by the application of selected managerial, administrative and technical procedures which, in combination, can be used to achieve the objectives of the Act.
(1) There are three categories of technical safeguards which can be used to maintain the integrity of personal information and protect it from unauthorized use.
These categories are (a) physical security procedures, (b) information management practices, and (c) computer system / network security controls.
Neither category by itself is likely to offer protection against all risks of privacy violations.
However, by carefully selecting appropriate components from among all three categories and packaging them into a well-balanced set of safeguards according to specific needs, the level of protection can usually be improved significantly at a reasonable cost.
O Approved: October 24, 1979 20
AUTOMATIC DATA PROCESSING STANDARDS -
NRC Appendix 0903 AUTOMATED SYSTEMS DOCUMENTATION Part 3
'[N i
(2) Aside from the requirement to safeguard personal data, there is also the concern to protect all data from disaster, natural or man made. Simply because a proposed system will not process data subject to the Privacy Act, does not imply that physical security measures need not be addressed. It may be that the institution of key safeguards in the system design will be. more cost effective than a retrofit at some future time to meet an unforeseen requirement.
(3) The whole issue of privacy and security has not fully coalesced into a set of fixed, predetermined actions. Guidelines have been issued by responsible agencies. (See Chapter NRC-2101.)
3.
' REQUIREMENTS I
a.
Description. Provide a general description of the system / subsystem to establish a frame of reference.
Include a summary of functional requirements to. be sctisfied by this system / subsystem.
Show the general interrelationship of the system / subsystem components by flow charting with narrative inclusion where appropriate.
This is a function level flowchart that identifies the system / subsystem capabilities, data, and their interrelationships.
b.
Functions. State the functions required of the software in quantita-g tive and qualitative terms, and how these functions will satisfy the 1
i performance objectives.
V F
c.
Performance.
(1) Accuracy. Describe and justify the data accuracy requirements 4
j imposed on the. software, such as mathematical, logical, legal, and transmission.
J l
(2) Validation.
Describe and justify the data validation require-ments imposed upon the system.
(3) Timing.
Describe and justify timing requirements imposed on the system, such as, under varying conditions:
(1) Response time.
(2) Update processing time.
(3). Data transfer and transmission time.
(4) Throughout time.
(5) Other.
(4) Flexibility. Describe (a) the capability for adapting to changes in requirements, and (b) projection of system growth.
o l-l l
21 Approved: October 24, 1979 I
c
~,.
r
NRC Appendix 0903 AUTOMATIC DATA PROCESSING STANDARDS -
Part 3 AUTOMATED SYSTEM DOCUMENTATION d.
Input / Output Data Requirements.
Describe data elements by name, their related coded representations, as well as relevent dictionaries, tables, and reference files.
Estimate total volume requirements for the data and related components based on expected growth.
Include a table or chart to reflect each data element, its source document and all outputs on which it is to be contained.
Where existing FIPS or NRC data element standard exists, it should be adopted or a cost / benefit justification given for any deviation.
Separate the data description into two categories, static data and dynamic data.
Static data is defined as that data which is used mainly for reference during operation and is usually generated or updated in widely separated time frames independent of normal runs.
Dynamic data includes all data which is input during a normal run or is output.
Arrange the data elements in each category in logical groupings, such as functions, subjects, or other groupings which are most relevant to their use.
(1) Static Data.
List of static. data elements used for either control or reference purposes.
(2) Dynamic Input Data.
List the dynamic input data elements which constitute the data intended to be changed by a normal run or during online operation.
(3) Dynamic Output Data.
List the dynamic output data elements which constitute the data intended to be changed by a normal run or during online operation.
(4) Internally Generated Data.
List the internally generated data of informational value to the user or developer.
(5) Retention.
State the retention record for each data element, or by logical group of data elements.
c.
Data Collection.
(1) Requirements and Scope.
Describe the type of information required to document the characteristics of each data element.
It should be logically grouped and presented. Include:
l (a) Source of Input.
Identify the source from which the data will be
- entered, e.g.,
an
- operator, station,
organizational unit, or its component group.
(b) Input Medium and Device.
Identify the medium and hard-ware device intended for entering the data into the system.
In those cases where only certain special stations are to be legitimate entry points, they should be specified.
O Approved: October 24, 1979 22
AUTOMATIC DATA PROCESSING STANDARDS -
NRC Appendix 0903 AUTOMATED SYSTEMS DOCUMENTATION Part 3 7
1
(
(c) Recipients.
Identify the intended recipients of the output data.
(d) Output Medium and Device.
Identify the medium and hardware device intended for presenting output data to the recipient.
Specify whether the recipient is to receive the data as part of a hard copy printout, a symbol in a CRT display, a line on a drawing, a colored light, an alarm bell, etc.
If the output is to be passed to some other automated system, the medium should be described, such as magnetic tape, punched cards, or an electronic signal to a solenoid switch.
~
(e) Critical Value. One value from a range of values of data may have particular significance to a recipient.
(f)
Scales of Measurement.
Specify for numeric scales, units of measurement, increments, scale zero-point, and range of values.
For non-numeric scales, any relationships indicated by the legal values should be stated.
(g) Conversion Factors.
Specify the conversion factors of measured quantities that must go through analog or digital conversion processes.
7m lV)
(h) Frequency of Update and Processing.
Specify the expected frequency of data change and the expected frequency of processing input data.
If the input arrives in a random or in an "as occurred" manner, both the average frequency and some measure of the variance must be specified.
(2) Input Responsibilities.
Provide recommendations as to respon-sibilities for preparing specific data inputs.
Include any recommendations regarding the establishment of a data input group.
Specify by source those data inputs dependent on interfacing software or unrelated organizations.
(3) Procedures.
Provide recommendations for data collection procedures.
Include detailed formats where applicable, and identify expected data communications media and timing of inputs.
f.
Failure Contingencies.
Specify the possible failures of the hard-ware or software, the consequences (in terms of performance and the alternative courses of action that may be taken to satisfy the 3
information requirements). Include (1) Back-up.
Specify back-up techniques, i.e.,
the redundancy available in the event the primary system element goes down.
\\
For example, a back-up technique for a disk medium would be j
to record periodically the contents of the disk to a tape.
23 Approved: October 24, 1979
NRC Appendix 0903 AUTOMATIC DATA PROCESSING STANDARDS -
Part 3 AUTOMATED SYSTEMS DOCUMENTATION (2) Fallback.
Explain the fallback techniques, i.e., the use of another system or other means to accomplish some portion of requirements.
For example, the fallback technique for an automated system might be manual manipulation and recording of data.
(3) Recovery and Restart.
Discuss the recovery and restart techniques, i.e., the capability to resume execution of software from a point in the software subsequent to which a hardware or software problem occurred, or the re-running of the software from the beginning.
4.
OPERATING ENVIRONMENT a.
Equipment.. Identify the equipment required for the operation of the
_sof tware.
Identify any new equipment required and relate it to specific functions and requirements to be supported.
Include information such as:
(1) Processor and size of internal storage.
(2) Storage, online and offline, media, form and devices.
(3) Input / output devices, online and offline.
(4) Data transmission devices.
b.
Support Sof tware.
Identify the support software and describe any test software. If the operation of the software depends on changes to support sof tware, identify the nature and planned date of these changes.
c.
Interfaces. Describe the interfaces with other application systems.
Include description of the interface technique, media, frequency and any alternatives.
d.
Security and Privacy.
Describe the overall security and privacy requirements imposed on the software.
If no specific requirements are imposed, state this fact. (See Chapter NRC-2101.)
e.
Controls. Describe the operational controls imposed on the software.
Identify the sources of these controls.
5.
DATA COMMUNICATION REQUIREMENTS Data communications is playing an increasingly significant role in ADP systems. Special care must be applied when considering systems that will incorporate data communications. The portion that concerns itself with the data communications aspect of the proposed system should address, but is not limited to, the below listed items.
This information is in conformance with FPMR 101-36.11, Data Communi-cations Support for ADP Systems.
O Approved: October 24, 1979 24
AUTOMATIC DATA PROCESSING STANDARDS -
NRC Appendix 0903 AUTOMATED SYSTEMS DOCUMENTATION Part 3 a.
Overview.
(1) Network architecture.
Summary description of total system.
(2) Type of Communications Systems.
(a) Remote job entry..
(b) Transaction oriented.
(c) Resource sharing " interactive."
(d) Message switching.
(e) Process control.
(f)
Combinations.
(3) System Considerations.
(a) Security requirements.
(b) System redundancy and backup requirements.
(c) Effect on other system data transmission requirements.
(d) Description of application programs against which the messages will be processed.
(e) Data storage requirements.
(f)
List of terminal types to be utilized on the system.
n (g) Availability of supporting software such as CICS, BTAM, (V)
QTAM, IMS, etc.
(h) Personnel requirements such as training; special skills to operate and maintain the network.
(k) Line speeds.
(1)
Reliability of system components; host computer-network terminals.
b.
Network Requirements.
(1) Medium of transmitting and receiving services, e.g., magnetic l
tape, punched paper tape, etc.
.(2) Types of transmission codes such as number of data bits per character, check
- bits, start-stop bits,
synchronization characters and character representations ( ASCII, EBCDIC, etc.)
(3) Types of line control signals such as nature of polling che c-ters, use of EOB, EOT, check characters, message heauers and trailers.
(4) Retransmission requirements.
(5) Requirements of the communication monitor including interrupt, answering, timer functions, program scheduling, and loading.
i O
25 Approved: October 24, 1979
r NRC Appendix 0903 AUTOMATIC DATA PROCESSING STANDARDS -
Part 3 AUTOMATED SYSTEMS DOCUMENTATION (6) Types and costs of communications links such as:
(a) Switened public.
(b) Leased.
(c) Leased with private switching.
(d) Non common carrier.
(e) Microwave.
(f)
Optical or infrared links.
(7) Speed of links including subvoice grade, voice grade and wideband.
(8) Mode of operation such as simplex, half duplex, full duplex.
(9) Use of special links such as data-phone, TELX, TWX, WATS, TELPAK Packet Switching.
(10) Requirements of the communication I/O handler to perform line management, error checking, statistical recording, terminal and user I.D. validation, etc.
(11) Requirements of the message handler for queuing, priorities editing, routing, etc.
(12) Requirements of network management such as system regenera-tion and recovery, on-line terminal testing, system check pointing.
(13) Existence of proper electronic, mechanical and logical inter-faces between network components and the host computer.
6.
DEVELOPMENT PLAN Discuss in this section the overall management approach to the develop-ment and implementation of the proposed software.
Include a list of the documentation to be produced,
time frames and milestones for the development of the software, and necessary participation by other organi-zations to assure successful development.
Include GANTT charts to reflect major tasks on one page and subordinate activities on separate pag.s.
O Approved: October 24, 1979 26
AUTOMATIC DATA PROCESSING STANDARDS -
NRC Appendix 0903 AUTOMATED SYSTEMS DOCUMENTATION Part 3 (V)
B.
AUTOMATED SYSTEM / SUBSYSTEM SPECIFICATION The purpose of the System / Subsystem Specification is to specify for Analysts, programmers, and users the detailed characteristics of the data, operating environment and program specifications for the system or subsystem.
Decisions are typically made, during the design of a system, which are based upon combinations of conditions which prevail at that time. During subsequent phases of a System Development process and most often when the system becomes operational, the reasons for those earlier decisions are not quite as obvious. The reasons (why) certain design characteristics are determined should be documented in the Automated System / Subsystem Specifications and subsequently in the Automated System Maintenance Manual.
(~')
V l
[
N O
27 Approved: October 24, 1979
AUTOMATIC DATA PROCESSING STANDARDS -
NRC App:ndix 0903 AUTOMATED SYSTEMS DOCUMENTATION Part 3-
-(3 4
AUTOMATED SYSTEM / SUBSYSTEM SPECIFICATION CONTENTS P,ag
.SECTION 1.
G E N E R A L I N F O RMAT I O N...................................
31 4
a.
Summary.................................................
31 b.
Environment.............................................
31 i
c.
References..............................................
31
~
SECTION 2. REQUIREMENTS..........................................
31 a.
Description......................................
31 b.
Functions...............................................
31 c.
Performance.............................................
31 (1)
Timing.............................................
31
{
(2)
Flexibility........................................
31 i
a d.
Organizational and Personnel Responsibilities...........
32 1
<-'s SECTION 3.
OPERATING ENVIRONMENT.................................
32 I
k a.
Equipment...............................................
32 b.
S upp o rt S o f twa re........................................
32 c.
Interfaces..............................................
33 d.
S e c u r i ty a nd P r i v acy....................................
33 e.
System Control s and Audit Trail s........................
33 i
f.
Da ta Commu n i ca ti on s.....................................
33 1
SECTION 4.
DESIGN CHARACTERISTICS.................................
35 r
d a.
Sy s tem /S ub sys tem Logi c...................................
35 b.
Cro s s Re fe rence Chart....................................
35 SECTION 5.
DATA BASE..............................................
35 a.
Description..............................................
35 4
i b.
Logical Characteristics..................................
36 c.
P hys i cal Characte ri s tics.................................
36 SECTION 6.
CONVERSION.............................................
38 a.
Genera 1..................................................
38 b.
Files....................................................
38 c.
Conve rs i on Procedure.....................................
38 d.
Conversion Program' Speci fication.........................
38
\\
%.s l
29 Approved: October 24, 1979 l
I s
.--n,,---.w,-
NRC Appendix 0903 AUTOMATIC DATA PROCESSING STANDARDS -
Part 3 AUTOMATED SYSTEMS DOCUMENTATION CONTENTS (Continued)
Page SEC'.' ION 7.
PROGRAM SPECIFICATION................................
38 a.
P ro g ram De s c r i p t i o n.....................................
8 b.
Functions...............................................
38 c.
Performance..........................................
39 d.
Ope ra ti ng Env i ronment...................................
40 e.
De s i gn Cha rac te ri s ti c...................................
40 f.
Linkages............
41 SECTION 8.
FLOWCHARTS.....................................
41 a.
Detailed Logic Flowcharts.............................
41 b.
F u nc t i o n F l owc h a rt s..................................
41 c.
Sy s tem Da ta F l owc ha rt s..................................
41 SECTION 9.
MAINTENANCE PROCEDURES...........................
42 a.
P rogrammi ng Co nve nti o n s................................
42 b.
Libraries.................
42 c.
Special Maintenance........................
42 d.
System Backup and Recovery Contingencies.............
42 e.
Inventories............................
42 1
O Approved: October 24, 1979 30
AUTOMATIC DATA PROCESSING STANDARDS. -
NRC Appendix.0903 AUTOMATED SYSTEMS DOCUMENTATION Part 3
[;
1.
-GENERAL INFORMATION a.
Summary. Summarize the specifications and functions of the system /
subsystem to be developed.
b.
. Environment.
Identify the project sponsor, developer, user, and computer center or network on which the system is to be 4
implemented.
c.
References. Lists applicable documents, which become incorporated by reference, such as:
(1) Project request (authorizations).
(2) Previously published documents on the subject.
(3) Documentation concerning related projects.
(4) FIPS publications and other reference documents.
(5) Functional and Data Requirements document.
2.
REQUIREMENTS a.
Description.
Provide a general description of the system / subsystem to establish a frame of reference for the remainder of the document.
Include a summary of functional requirements to be satisfied by this system / subsystem.
Show the general interrelationship of the system / subsystem components.
OQ b.
Functions.
Specify the system / subsystem functions in quantitative and qualitative terms and how the functions will satisfy the func-tional requirements.
c.
Performance. Specify the performance requirements.
(1) Timing.
Describe the timing requirements imposed on the j
software, such as, under varying conditions:
(a) Response time.
(b) Update processing time.
1 (c) Data transfer and transmission time.
a
-(d). Throughput time.
4 (2) Flexibility. Describe the capability for adapting the program to char.ges in requirements, such as:
(a) Changes in modes of opera + ion.
(b) Operating environment.
(c) Interface.with other software.
(d) Accuracy and validation and timing.
(e) Planned changes or improvements.
4 i
r<
31 Approved: October 24, 1979
NRC Appsndix 0303 AUTOMATIC DATA PROCESSING STANDARDS -
Part 3 AUTOMATED SYSTEMS DOCUMENTATION Identify the system / subsystem components which are specifical-ly designed to provide this flexibility.
d.
Organizational and personnel responsibilities.
Identify by organiza-tion, all personnel functional responsibilities associated with the operation of the system, to include but not limited to:
(1) Data collection, transcription, entry keypunch, verification,
and auditing.
(2) Control of production such as job submissions, report verifica-
~
tion, output distribution, maintenance of run schedules and log books.
(3) Equipment monitoring such as acquisition, use, cleaning, and repair.
(4) System software acquisition,
development, maintenance and support.
(5) System (application) manager (by functional title, not individ-ual employee name).
3.
OPERATING ENVIRONMENT a.
Equipment.
Identify the equipment required for the operation of the system / subsystem.
Identify any new equipment required and relate it to specific functional requirements to be supported.
Include information, such as:
(1) Processor and size of internal storage.
(2) Storage, online and offline, media, form, and devices.
(3) Input / output devices, online and offline.
(4) Data transmission devices.
b.
Support Software.
Describe briefly all support software directly related to the data base.
Descriptions should include name, func-tion, major operating characteristics, and machine run instructions for using the support software.
Cite the support software docu-mentation by title, number, appropriate section, code names, and i
any release version number.
If the operation depends on changes to support sof tware, identify the nature and planned date of the changes. Examples of support software are:
(1) Data base management systems.
(2) Storage allocation software.
(3) Date base loading software programs.
(4) File processing programs.
(5) Other generating, modifying, or updating software.
O Approved: October 24, 1979 32
a AUTOMATIC DATA PROCESSING STANDARDS -
NRC Appendix 0903 AUTOMATED SYSTEMS DOCUMENTATION Part 3 j
('")
c.
Interfaces.. Describe the interfaces with other applications. Identify the method, media, and frequency of interface.
d.
Security and Privacy.
Describe the overall security and privacy requirements imposed on the system / subsystem.
If no specific requirements are imposed, state this fact.
e.
System Controls and Audit Trails.
Describe the methods of system controls and audit trails contained in the system, following the guidelines contained in Exhibit 5.
f.
Data Communication. Describe the data communication aspect of the system in consonance with FPMR 101-36.11, " Data Communication Support for ADP System." Include information where applicable on:
(1) Network Architecture.
(2) Type of Communication System.
(a) Remote job entry.
(b) Transaction oriented.
(c) Resource sharing " interactive."
(d) Message switching.
(e) Process control.
(f)
Combination.
/
(,/
(3) System Considerations.
(a) Security requirements.
(b) System redundancy and backup requirements.
(c) Effect on other system data transmission requirements.
(d) Description of application programs against which the messages will be processed.
(e) Data storage requirements.
(f) List terminal types to be utilized on the system.
(g) Availability of supporting software such as CICS,BTAM, QTAM, IMS, etc.
(h) Personnel special skills to operate and maintain the network.'
(i)
Management controls.
(j)
Conversion problems.
(k) Line speeds.
(1)
Reliability of system components; host computer-network terminals.
(4) Network Capabilities.
(a) Medium of transmitting and receiving services, e.g.,
magnetic tape, punched paper tape, etc.
\\p) x_/
33 Approved: October 24, 1979 4
NRC App::ndix 0903 AUTOMATIC DATA PROCESSING STANDARDS -
Part 3 AUTOMATED SYSTEMS DOCUMENTATION (b) Types of transmission codes such as number of data bits per character, check bits, start-stop bits, synchronization characters and character representations (ASCII, EBCDIC, etc.)
(c) Types of line control signals such as nature of polling characters, use of EOB, EOT, check characters, message headers, and trailers.
(d) Retransmission capabilities.
(c) Capabilities of the communication monitor including inter-rupt, answering, timer functions, program scheduling and loading.
(f)
Types and costs of communication links such as:
1 Switched public.
2 Leased.
3 Leased with private switching.
4 Non common carrier.
5 Microwave.
5 Optical or infrared links.
(g) Speed of links including subvoice grade, voice grade and wideband.
(h) Mode of operation such as simplex, half duplex, full duplex.
(i)
Use of special links such as data phone, TELEX, TWX, WATS, TELPAK Pack Switching.
(j)
Capabilities of the communication I/O handler to perform line management, error checking, statistical recording, terminal and user I.E., validation, etc.
(k) Capabilities of the message handler for queuing, priorities editing, routing, etc.
(1)
Capabilities of nemark management such as system regeneration and recovery, on-line terminal testing, system check pointing.
(m) Existence of proper elect ronic, mechanical and logical interfaces between network components and the host computer.
O Approved: October 24, 1979 34
AUTOMATIC DATA PROCESSING STANDARDS -
NRC Appendix 0903 AUTOMATED SYSTEMS DOCUMENTATION Part 3
,r (v) 4.
DESIGN CIIARACTERISTICS a.
System / Subsystem Logic.
Describe the logic flow of the entire system / subsystem in the form of a system data flowchart. The flow should provide an integrated presentation of the system / subsystem dynamics, of entrances and exits, computer programs, support software, controls, and data flow, b.
Cross Reference Chart.
Describe in chart form, the relationship of all source documents, screen formats, transcription forms, files /
records, data elements, programs, and outputs (see Exhibit G).
5.
DATA BASE a.
Dercription.
(1) Identification.
Specify the code name, tag, or label by which the data base is to be identified If the data base is to be experimental, test, or temporary, specify this characteristic and effective dates or period.
Any additional identification information should also be given.
(2) Accuracy. Describe the data accuracy requirements imposed on the system or subsystem, such as:
(~';
(a) Mathematical.
(")
(b) Logical.
(c) Legal.
(d) Transmission.
(3) Validation.
Describe the data validation requirements imposed on the system / subsystem.
(4) Conventions.
Describe all labeling or tagging conventions essential for a programmer or analyst to use this data base specification.
(5) Special Instructions.
Provide any special instructions to personnel who will contribute to the generation of the data base, or who may use it for testing or operational purposes.
Such inetructions include criteria, procedures, and formats for:
(a) Submitting data for entry into the data base and identifi-cation of a data control organization.
(b) Entering data into the data base.
Q.))
t 35 Approved:
October 24, 1979
NRC App:ndix 0903 AUTOMATIC DATA "ROCESSING STANDARDS -
P rt 3 AUTOMATED o TEMS DOCUMENTATION b.
Logical Characteristics.
A data base is a logical arrangement of data.
Sets (aggregates),
files, records, elements, and items of data may vary in their logical arrangement and relationships.
The organization of the content of this section should provide a meaningful presentation of the logical organization of the data base.
Define each unique data element in the form of a Data Base Dictionary.
(Include all tables and reference files.) Within this definition, include the following:
(1) Identification:Name and Tag or Label.
(2) Data Bases, Files, and/or Records in which it exists.
(3) Source document or program in which it is generated.
(4) Definition.
Standard or unique; purpose in data base; using sof tware; media; form; format and size; update criteria and conditions ; security and privacy restrictions, limitations, or conditions (update or access); integrity and validity charac-teristics ;
controlling data elements or items; graphics representation, and whether it is static, dynamic or internally generated.
Describe the formula or means for internally generated data to include identification of data elements upon which it is dependent.
(5) Scales of Measurement.
Specify for numeric scales, units of measurement, increments, scale zero-point, and range of values.
For non-numeric scales, any relationships indicated by the legal values should be stated.
(6) Conversion Factors, Specify the conversion factors of measured quantities that must go through analog or digital conversion processes.
c.
Physical Characteristics.
(1) Storage. Specify the storage requirements for the data base and any constraints, conditions, and growth factors.
(a) Internal.
If known, describe and illustrate the use of internal storage areas set aside for data including indexing and working areas. Briefly state the equipment constraints and design considerations that affect the use of internal storage.
O Approved: October 24, 1979 36 P
AUTOMATIC DATA PROCESSING GTANDARDS -
NRC App:ndix 0903 AUTOMATED SYSTEMS DOCUMENTATION Part 3 1/
i
'd (b) Device.
List by device type all peripheral storage required for the data base.
State any constraints imposed on storage requirements for permanent data storage and temporary data storage, including overlays.
Identify device dependent versus device independent aspects of the data base.
(c) Offline.
Describe the form, media and storage require-ments of all off-line data storage.
(2) Access.
Describe the access method and specify the physical relationships of access (index, device, area).
Describe all physical access security mechanisms.
(3) Design Considerations. State the design considerations for the handling of this data base, such as blocking factors.
Emphasize those physical relationships important to the efficient utilization of the data base.
(4) Data Collection.
(a) Source of Input. Identify the source from which the data will be entered, e.g., an operator, station, organizational unit, or its component group.
D.
(b) Innut Resoonsibilities.
Identify organizational responsi-bilities for preparing specific data inputs.
Specify by source those data inputs dependent on interfacing soft-ware or unrelated organizations.
(c) Input Medium and Device.
Identify the medium and hardware device intended for entering the data into the system.
In those cases where only certain special stations are to be legitimate entry points, they should be specified.
j (d) Recipients. Identify the intended recipients of the output data.
(e) Output Medium and Device.
Identify the medium and hardware device intended for presenting output data to the recipient.
Specify whether the recipient is to receive the data as part of a hard copy printout, a symbol in a CRT display, a line on a drawing, a colored light, an alarm bell, etc.
If the output is to be passed to some other automated
- system, the medium should be described, such as mmgnetic tape,
punched cards, or an electronic signal to a solenoid switch.
/m (V
1 i
1 l
37 Approved: October 24, 1979
NRC App:ndix 0903 AUTOMATIC DATA PROCESSING STANDARDS -
Part 3 AUTOMATED SYSTEMS DOCUMENTATION i
(f)
Frequency of Update and Precessing.
Specify the expected frequency of data change and the expected frequency of processing input data.
If the input arrives in a random or in an "as occurred" manner, both the average frequency and some measure of the variance must be specified.
6.
CONVERSION a.
General.
Provide a narrative explaining, in general terms, the intended conversion approach including complete justification and any problems associated with the process.
b.
Files.
Identify each File / Record / Data element to be converted, to include:
(1) File Name, Record Name/ Data element Name.
(2) Data element characteristics such as size, values, occurrences for both original and new version.
(3) Explain data validation and editing requirements.
(4) Identify new data elements (and their source) which must be obtained, which do not exist in current data base.
Explain how these new data elements will be obtained.
c.
Conversion Procedure.
Explain, in detail, when conversion will take place (in relationship to overall development tasks), whether conversion is necessary for initial program debug tests; any expected conversion specification changes between initial and final conversion processes.
d.
Conversion Program Specification.
Include in Section 7, " Program Specification," complete specification for conversion programs.
7.
PROGRAM SPECIFICATIONS (Separate description for each Program) a.
Program Description.
Provide a general description of the program to establish a frame of reference for the remainder of the document.
Include a summary description of the system / subsystem functions to be satisfied by the program.
b.
Functions.
Specify the functions of the program to be developed.
If the program in itself does not fully satisfy a system / subsystem function,
show the relationship to other programs which in aggregate satisfy that function.
I O
Approved: October 24, 1979 38 i
_.s
- AUTOMATIC DATA PROCESSING STANDARDS --
NRC Appendix 0903 AUTOMATED SYSTEMS DOCUMENTATION Part 3
- /%
.-(V, i
c.
Performance. Specify the performance requirements.
(1) Accuracy. Describe data accuracy requirements imposed on the program, such as:
-(a). Mathematical, (b) Logical.
. (c) ~ Legal.
(d) Transmission.
'(2) Validation.
Describe = the data validation requirements imposed -
. on the program.
i (3) Timing.
Describe the timing requirements imposed on the
' progam, such as, under varying conditions:
(a) Response time.
(b) Update processing time.
(c) Data' transfer and transmission time.
(d) Throughput and internal processing time.
(4) Flexibility. Describe the capability for adapting the program to changes in requirements, such as:
(a) -Modes of operation.
b (b) Operating environment.
i V
(c) Interface with other programs.
i (d) Accuracy, validation, and timing.
(e). Planned changes or improvements.
t identify the components of the program which are designed to provide this flexibility.
(5) Processing.
Describe processing features and purposes such as:
(a) Processing logic.
(b) ' Linkages.
j
.(c) Significant variables and constants.
1 (d) Formulas.
l
. e) ~ -Error handling provisions.
{
(
(f)
Restrictions and limitations.
l (g) Significant internal switches and flags.
(h) - Shared' storage.
l
~
i (6) Tables. ' Identify each table and its items.
Describe the
. location,. _ structure, and purpose of 'each.
There must be a corresponding program or function for the creation and/or
.: updating of each table plus a means for listing or querying the tables.
I
\\
f-
~
October 24, 1979 39 Approved:.
I
NRC App:ndix 0903 AUTOMATIC DATA PROCESSING STANDARDS -
Part 3 AUTOMATED SYSTEMS DOCUMENTATION d.
Operating Environment.
(1) Equipment. Identify the equipment required for the operation of the program.
Include information on equipment required, such as:
(a) Processor and size of internal storage.
(b) Storage, online and offline, media, form, and devices.
(c) Input / output devices, online and offline, and capabilities.
(e) Data transmission devices.
(2) Interfaces.
Describe all interactions with the operator.
Describe all interactions with other software, including sequence or procedure relationships, data interfaces, messages, and parameters.
(3) Internal Storage.
Specify storage requirement, any constraints and conditions.
Describe and illustrate the use of internal storage areas, including indexing and work areas.
State the equipment constraints and design considerations that affect the use of internal storage.
(4) External Storage Devices.
List by device type, all peripheral storage required. State any constraints imposed on storage by each device. State permanent and temporary storage, including overlays, indexes, saved space, and work areas.
(5) Security and Privacy.
Describe the security and privacy requirements imposed on the program, the inputs, the outputs and the data' bases.
If no specific requirements are imposed, state this fact.
(6) Controls. Describe the program controls such as record counts, accumulated counts, and batch controls. Identify the sources of these controls.
e.
Design Characteristics.
(1) Operating Procedures. Describe the operating procedures and any special program functions or requirements necessary for its implementation.
Describe all other interactions of the program with the operator.
l (2) Inputs.
Provide information about the characteristics of each input to the program, such as:
{
(a) Title and tag.
(b) Format and type of data, such as a record layout.
(c) Validation criteria.
O Approved: October 24, 1979 40
AUTOMATIC DATA PROCESSING STANDARDS -
NRC Appendix 0903
. AUTOMATED SYSTEMS DOCUMENTATION Part - 3 (d) Volume and frequency.
(e) 'Means of entry.
(f) Source document and its disposition, or specific interface
-soucce.
(g) Security and privacy conditons.
(3) Program Logic.
Describe the program logic. The logical flow should be supplemented by decision tables when applicable.
(4) Outputs. Provide information about the characteristics of each j
output from the program, such as:
(a) Title and tag.
(b) Format specifications, such as a report format.
(c) Selection criteria for display, output, 'or transfer.
1 (d) Volume and frequency.
(e) Means of entry.
,I
- (f) Description of graphic displays and symbols.
(g) Security and privacy conditions.
(h) Disposition of products.
1 (i)
Description of sequence of displays, display contents, fixed and variable formats, and display of error conditions.
(5) Data Base. Identify each Data Base / file / record accessed by the 3
program. (Refer to Section 5, " Data Base").
.i j
f.
Linkages.
Identify and explain all program links to this program or from this program. Identify applicable keys or data linkages, how they're used, set and reset upon return.
8.
FLOWCHARTS a.
Detailed Logic Flowchart.
Except in unusually complex programs i
detailed program logic flowcharts are not necessary, but may be included at discretion of the system designs.
A
$2 b.
Function Flowcharts. Functional flowcharts should be drawn following the TOP-DOWN approach to s.rstems design.
These charts should reflect processing logic, not input and output.
c.
System Data Flowcharts.
Separate flowcharts should be drawn to
~
reflect the interrelationship between all programs and files / records
]
contained in the system. The media (card, disk, CRT) on which the data exist should be reflected along with all output media (printer, j
CRT, com).
Flowcharting symbols adopted by FIPS PUB 24 are prescribed when manually proposing the Data Flowcharts.
i O
v
.41 Approved: October 24, 1979 t'
yy
-y gi
'-em
,g 9
- - +
y.,-g y-uy-9-y-...ey.
yyy a
m.----
,,wg m
.y v.i.
-9y y y.
NRC App:ndix 0903 AUTOMATIC DATA PROCESSLG STANDARDS -
Part 3 AUTOMATED SYSTEMS DOCUMENTATION 9.
MAINTENANCE PROCEDURES a.
Programming Conventions.
Identify all programming languages, utilities, or special software packages used plus all programming conventions applied.
b.
Libraries.
Identify the name, location, usage, and any special access or updating techniques for all libraries such as source, load, procedure, test, macro, etc.
c.
Special Maintenance.
Describe any special procedures required for maintenance of the system.
Include information such as periodic data purges temporary modifications needed, special assistance by computer center personnel or systems personnel.
d.
System Backup and Recovery Contingencies.
Describe in detail all procedures necessary to be accomplished for system back up, off-site storage of software and data, recovery techniques for application, operating system, or hardware failures. Identify name, location of backup facilities, and all tasks necessary for recovery at that facility.
e.
Inventories.
The data base dictionary and cross reference charts provide a control mechanism for tracking of data elements and their usage through the entire system. Additional system inventories are also necessary for future maintenance of the various parts of the system. This can be accomplished by an inventory of all programs, jobs, procedures, and reports.
(1) Program Inventory.
Identify each prograia in ascending sequence along with the title and programming language used.
(2) Job Inventory.
Identify each job in ascending sequence along with primary purpose of the job and the intended frequency of use.
(3) Procedure Inventory.
Identify each procedure in ascending sequence along with a brief description of the purpose for the procedure.
(4) Report Inventory.
Identify each report in ascending sequence along with the title of the report.
(5) File Inventory.
Identify every file in ascending sequence along with the title of the file.
O Approved: October 24, 1979 42
U
~
- AUTOMATIC. DATA PROCESSING ' STANDARDS -.
.NRC Appendix 0903 AUTOMATED SYSTEMS DOCUMENTATION Part 3
?
'l t
C,
~ AUTOMATED SYSTEM USER /G /ERATIONS MANUAL j
The purpose of the Automated System User / Operations Manual is to i
j sufficiently describe the-functions performed by the system so that the user organization can determine its applicability, when, and how to use j
'it.
It should serve as a reference document for preparation of input, l
operating procedures, and interpretation of results.
i i
i l
I i
1 I
i i
I i
1 i
f f
I t
I i
I l
l i
t
]
i l
~
1 i
i t
i i
i 43 Approved: October 24,-1979
- -j'..
- - -. -. - -.. = -.
' AUTOMATIC DATA PROCESSING STANDARDS -
NRC Appendix 0903 AUTOMATED SYSTEMS DOCUMENTATION Part 3 L
V AUTOMATED. SYSTEM USER /0PERATIONS MANUAL CONTENTS Page SECTION 1.
GENERAL INFORMATION...................................
47 a.
Summary.................................................
47
'b.
Environment.............................................
47 c.
References..............................................
47 SECTION 2.
APPLICATION...........................................
47 a.
Description.............................................
47 b.
0peration...............................................
47 c.
Equipment.~..............................................
47 d.
Structure...............................................
47 e.
Performance.............................................
47 SECTION 3.
PROCEDURES AND REQUIREMENTS...........................
47 a.
Initiation..............................................
48
- O b.
Input...................................................
48
\\
c.
0utput..................................................
49 d.
Error and Recovery......................................
50 1
SECTION 4.
FUNCTION DESCRIPTION..................................
50 a.
General.................................................
50 b.
Function Inventory......................................
50 c.
Progression.............................................
50 i
d.
Function Description....................................
51 2
SECTION 5.
NON-ROUTINE PROCEDURES................................
52 SECTION 6.
REMOTE OPERATIONS.....................................
52 SECTION 7.
FILE QUERY............................................
52 J
l J
2 1
45 Approved: October 24, 1979 f
w
.n.-
..--,.w
.--..nr
,e e
AUTOMATIC DATA PROCESSING STANDARDS -
NRC Appendix 0903 i
AUTOMATED SYSTEMS DOCUMENTATION Part 3
[')
I 1
I V'
1.
GENERAL INFORMATION a.
Summary.
Summarize the application and general functions of the sof tware.
b.
Environment.
Identify -the user organization and computer where the software is instaHed.
c.
References. List applicable references, such as:
(1) Project request (authorization).
(2) Previously published documents on the project.
(3) Documentation concerning related projects and software.
t
- (4) FIPS publication and other reference documents.
2.
APPLICATION t
a.
Description. Describe when and how the software is used and the unique support provided to the user organization. The description should include:
(1) Purpose of the software.
(2) Capabilities and operating improvements provided.
(3) Functions performed.
A b.
Operation.
Show the operating relationships of the functions per-Vl r
formed to the organization that provides input to and receives output from the software. Describe security and private considera-tions.
Include general charts and a description of the inputs and outputs shown on the charts.
c.
Equipment.
Describe the equipment on which the software can be run.
d.
Structure.
Show the structure of the software by operating func-tion and describe the role of each component in the operation of the system.
e.
Performance.
Describe the performance capabilities of the software including where appropriate:
^
(1) Quantitative information on inputs, outputs, response time,
processing times, and error rates.
(2) Qualitative information about flexibility and reliability.
3.
PROCEDURES AND REQUIREMENTS This section should provide information about initiation procedures, and preparation of data and parameter inputs for the software.
The scope, quality, and logical arrangement of the information should enable the p) user to prepare required inputs and should explain in detail the 6NJ l
47 Approved:
October 24, 1979 T
NRC Appendix 0903 AUTOMATIC DATA PROCESSING STANDARDS -
Part 3 AUTOMATED SYSTEMS DOCUMENTATION characteristics and meaning of the outputs.
It should also describe error recovery, and file query procedures and requirements.
a.
Initiation.
Describe step-by-step procedures required to initiate processing, b.
Input.
Define the rey.rements of preparing input data and parameters. Typical considerations are:
(1) Conditions-e.g., personnel, transfer, out of stock.
(2) Frequency-e.g., periodically, 1 andomly, as a function of an operational situation.
(3) Origin-e.g., Personnel Section, Inventory Control.
(4) Medium-e. g., keyboard, punched card, magnetic or paper tape.
(5) Restrictions-e.g., priority a.d security handling, limitations on what files may be accessed by this type of transaction.
(6) Quality control-e.g., instrations for checking reasonableness of input data, action to be taken when data appears to be in error, documentation of errors.
(7) Disposition-e. g.,
instructions necessary for retention or release of all data files received, other recipients of the inputs.
(a) Input Formats.
Provide the layout forms used in the initial preparation program data and parameter inputs.
Explain each entry, and reference it to the sample form.
Include a description of the grammatical rules and con-ventions used to prepare input, such as:
1 Length-e.g., character /line, character / item.
2 Format-c.g., lef t justified.
3 Labels-e.g., tags or identifiers.
4 Sequence-c.g., the order and placement of items in the input.
5 Punctuation-e. g.,
spacing and use of symbols (virgule, asterisk, character combinations, etc.) to denote start and end of input, of Unes, of data groups, etc.
6 Combination-e.g., rules forbidding use of the groups of particular characters, or combinations of param-eters in an input.
O Approved: October 24, 1979 48
a-J AUTOMATIC DATA PROCESSING STANDARDS -
NRC Appendix 0903 AUTOMATED SYSTEMS DOCUMENTATION Part 3 V-7.
Vocabulary-e. g., an appendix which lists the allow-able character combinations or codes that must be used to identify or compose input items.
8 Omissions and Repeats-e.g., indicate those elements of input that are optional or may be repeated.
9-Controls-e.g., header or trailer controls data.
(b) Sample Inputs.
Provide specimens of each complete input form. Include:
1
- Control ' or header-e.g., entries that denote the input class or type, date/ time, origin, and instruc-tion codes to the software.
2 Text-e.g., subsections of the input representing data for operational files, request parameters for an information retrieval program.
3 Trailer-e.g., control data denoting the end of input and any additional control data.
4 Omissions-e.g., indicate those classes or types of p
-input that may be omitted or are optional.
v)
(
5 Repeats-e.g., indicate those positions ' of the input that may be repeated.
c.
Output.
Describe the requirements relevant to each output.
Typical considerations are:
(1)
Use-e.g., by whom and for what.
I (2) Frequency-e.g., weekly, periodically, or on demand.
(3) Variations-e. g., modifications that are available to the basic output.
(4) Destination-e.g., computer area, remote terminal.
1, 4
(5) Medium-e.g., printout, CRT, tape, cards.
(6) Quality control-e.g., instructions for identification, reasonable-
=
ness checks, editing, and error correction.
t (7) Disposition-e.g.,
instructions necessary for retention or
- release, distribution, transmission, priority,
and security handling.
f%
)
v 49 Approved: October 24, 1979
NRC Appendix 0903 AUTOMATIC DATA PROCESSING STANDARDS -
Part 3 AUTOMATED SYSTEMS DOCUMENTATION (a) Output Formats.
Provide a
layout of each output.
Explanations should be keyed to particular parts of the format illustrated. Included:
1 Header-e. g., title, identification, date, number of output parts.
2 Body-e.g., information that appears in the body or text of the output, columnar headings in tabular displays, and record layouts in machine readable outputs.
Note which items may be omitted or repeated.
3 Trailer-e.g., summary totals, trailer labels.
~
(b) Sample Outputs. Provide a sample of each type of, output.
For each item on a sample, include:
1 Definition-e.g., the meaning and use of each informa-tion variable.
2 Source-e.g., the item extracted from a specific input, from a data base file, or calculated by software.
3 Characteristics-e.g., the presence or absence of the item under certain conditions of the output genera-tion, range of values, unit of measure.
d.
Error and Recovery.
List error codes, messages, or conditions generated by software and corrective action to be taken by the user.
Indicate any action or steps to be followed by the user to ensure that any restart and recovery capability can be used.
Each error code should be unique in order to pinpoint exact location or cause of the associated problem. (See Section 4d(6).)
4.
FUNCTION DESCRIPTION a.
General. Functions differ from one cystem to another depending upon facilities, system design computer access, etc.
Functions may be "ON-LINE," B ATCH JOBS, or manual procedures.
b.
Function Inventory.
List the various functions possible and sum-marize the purpose of each function.
Name the programs that are executed during each process.
c.
Progression.
Describe the manner in which progression advances from the function to another so that the entire process is completed.
O Approved: October 24, 1979 50
AUTOMATIC DATA PROCESSING STANDARDS NRC Appendix 0303 AUTOMATED SYSTEMS DOCUMENTATION Part 3 A
i.\\g)
- d.
_ Function Description (Identity).
Organize the information on each i
function into the most useful presentation for the operating environ-ment and personnel involved.
Sufficient information should be contained in the section for the user to understand what is being accomplished by the function.
(1) - On Line System. List and explain all instructions, parameters and procedures for equipment utilization, communications initia-tions, - ' PASSWORDS, user identification procedures,- menus selections, prompts, etc.~
(2) Batch System. _ Provide information for job identification and initiation such as:
i (a) Run/ job identification.
1 (b) Operating requirements.
(c) Initiation methods.
(d) Estimated run and turnaround time.
(e) Contacts for problems with the run.
(3) Input-Output Files.
Provide information for files created or updated by the run, such as:
(a) File name or label.
(b) Recording medium.
(c) Retention schedule.
j d (d) Disposition of file.
(e) Tape number procedures.
(4) Output Reports.
For each output report or type of report, provide information such as:
(a) Report identification.
-(b) Medium.
(c) Volume of report.
(d) Number of copies.
(e) Distribution.
(f).Special carriage control requirements.
(g). Security / Privacy / Proprietary data restrictions.
(h) Tape to COM procedures.
(5) Reproduced Output Reports.
For those reports that are
~
computer-generated and then reproduced by other ' means,
_ provide information such as:
(a) Report identification.
(b) Reproduction technique.
(c) Dimensions of paper or other medium.
4 (d) Binding method.
(e). Distribution.
h>
4 sv 51 Approved:
October 24, 1979
NRC Appendix 0903 AUTOMATIC DATA PROCESSING STANDARDS -
Part 3 AUTOMATED SYSTEMS DOCUMENTATION (6) Restart / Recovery Procedures.
Describe procedures to restart the run or recover from a failure. Include references to error message outlined in Section 3.d (error and rec.svery).
5.
NON-ROUTINE PROCEDURES Provide any information necessary concerning emergency or nonroutine operations, such as:
a.
Switchover to a back-up system.
b.
Procedures for turnover to maintenance programmers in event of system problems.
6.
REMOTE OPERATIONS Describe the procedures for running the programs through remote terminals. This is only applicable if Remote Operations are considered as a separate function not described under Section 3.
An example of this may be a system run by the primary office in NRC IIeadquarters with some capability at a Regional Office (such as data input or query capability).
7.
FILE QUERY Prepare this paragraph for software with a file query retrieval capability.
Include detailed instructions necessary for initiation, preparation, and processing of a query applicable to the data base.
Describe the query capabilities, forms, commando used, and control instructions required.
If the software is queried through a terminal, provide instructions for terminal operators. Describe terminal setup to connect procedures, data or parameter input procedures, and control instructions.
Reference related materials describing query capabilities, languages, installation conventions, and prccedures program aids, etc.
O Appro'ved: October 24, 1979 52
l AUTOMATIC DATA PROCESSING STANDARDS -
NRC Appendix 0903 AUTOMATED SYSTEMS DOCUMENTATION Part 3 c
( )m x.
D.
AUTOMATED SYSTEM MAINTENANCE MANUAL The purpose of the system maintenance manual is to provide the mainte-nance programmers with information necessary to understand the system, programs, and data base structure.
The format and content for the System / Subsystem Specifications docu-ment should be followed for writing system maintenance manuals.
(See Part 3.B).
The more precise and complete the design specifications, the less work it will take to write a system maintenance manual.
IIowever, all too frequently, the final product of a system development does not always resemble the original design. This is usually caused by (1) poor system specifications, (2) inadequate user requirements, or rarely, (3) massive unforeseen requirement changes.
The conversion section of the system specification should be rewritten in order to document the results of the conversion and tests.
V)
I
,l
'L) 53 Approved: October 24, 1979 l
i i AUTOMATIC DATA-PROCESSING STANDARDS -
' NRC Appendix 0903 l-AUTOMATED SYSTEMS DOCUMENT Part 3 p
' E.
' AUTOMATED TEST PLAN I
The purpose of-the Test Plan is to provide a plan for the testing of software; detailed. specifications, descriptions, and procedures for all l
tests; and test data ' reduction and evaluation criteria.
i j
i i
t i
i i
i l
j.
,i i
d i
t i
i i
i i
i s
f 55 Approved: October 24, 1979
.\\
- AUTOMATIC DATA PROCESSING STANDARDS -
NRC Appendix 0903 AUTOMATED SYSTEMS DOCUMENTATION Part 3 OJ AUTOMATED SYSTEM TEST PLAN CONTENTS Page SECTION 1.
GENERAL INFORMATION...................................
59 a.
Summary.................................................
59 b.
Environment and Pretest Background......................
59 c.
Iaferences..............................................
59 SECTION 2.
PLAN...................................................
59 a.
Software Description.....................................
59 b.
Milestones...............................................
59 c.
Testing (Identify Location)..............................
59 (1)
Schedule.............................................
59 (2)
Requirements.........................................
59 (3) Testing Materials....................................
59 (4) Test Training........................................
60 d.
Testing (Identify-Location)........................
60 s
n SECTION 3.
SPECIFICATIONS AND EVALUATION.........................
66 a.
Specifications............................................
60 (1)
Requirements.........................................
60 (2) Software Functions...................................
60 (3) _ Test / Function Relationships..........................
60
)
(4) Test Progression.....................................
60
)
b.
Methods and Constraints...................................
60 (1)
Methodology..........................................
60 (2)
Conditions...........................................
60 (3)
Extent...............................................
60 (4) Data Recording.......................................
60 (5)
Constraints..........................................
60 c.
Evaluation................................................
61 J
4 I
(1)
Criteria.............................................
61 (2) Data Reduction.......................................
61 h
G 57 Approved: October 24, 1979
1 NRC Appendix 0903 AUTOMATIC DATA PROCESSING STANDARDS -
Part 3 AUTOMATED SYSTEMS DOCUMENTATION
)
O CONTENTS (Continued)
P. age SECTION 4.
TEST DESCRIPTIONS......................................
61 a.
Test (Identify)..........................................
61 (1)
Control...........................................
61 (2)
Inputs...........................
61 (3) 0utputs...........................................
61 (4)
Procedures.......................................
61 b.
Test (Identify)..........................................
61 O
I i
i l
1 O'
Approv'ed:
October 24, 1979 58
AUTOMATIC DATA PROCESSING STANDARDS -
NRC Appendix 0903 AUTOMATED SYSTEMS DOCUMENTATION Part 3 O) iAj 1.
GENERAL INFORMA' PION a.
Summary. Summarize the functions of the software and the tests to be performed.
b.
Environment and Pretest Background.
Summarize the history of the project. Identify the user organization and computer center where the testing will be performed. Describe any prior testing and note results that may affect this testing.
c.
Reference. List applicable references, such as:
(1) Project request (authorization).
.(2) Previously published documents on the project.
(3) Documentation concerning related projects.
(4) FIPS publications and other reference documents.
2.
PLAN a.
Software Description.
Provide a chart and briefly describe the inpu ts, outputs, and functions of the software being tested as a frame of reference for the test descriptions.
b.
Milestones.
List the locations, milestones events, and dates for the testing.
c.
Testing (Identify Location).
Identify the participating organizations and the location where the software will be tested.
1 (1) Schedule. Show the detailed schedule of dates and events for the testing at this location. Such events may include familiari-zation, training, data, as well as the volume and frequency of the input.
(2) Requirements. State the resource requirements, including:
(a) Equipment.
Show the expected period of use, types, and quantities of the equipment needed.
(b) Sof tware.
List other software that will be needed to support the testing that is not part of the software to be tested.
(c) Personnel.
List the numbers and skill types of personnel that are expected to be available during the test from both the user and development groups.
Include any special requirements such as multishift operation or key personnel.
(3) - Testing Materials.
List the materials needed for the test, such as:
p
\\
]
-n-59 Approved: October 24, 1979,
NRC Appendix 0903 AUTOMATIC DATA PROCESSING STANDARDS -
Part 3 AUTOMATED SYSTEMS DOCUMENTATION (a) Documentation.
(b) Software to be tested and its medium.
(c) Test inputs and sample outputs.
(d) Test control software and worksheets.
(4) Test Training.
Describe or reference the plan for providing
' raining in the use of the software being tested.
Specify the
- ypes of training, person.nel to be trained, and the training staff.
4 d.
Testing (Identify Location).
Describe the plan for the second and subsequent locations where the software will be tested in a manner similar to paragraph 2.c.
3.
SPECIFICATIONS AND EVALUATION a.
Specifications.
(1) Requirements. List the functional requirements established by earlier documentation.
(2) Software functions.
List the detailed software functions to be exercised during the overall test.
(3) Test / Function Relationships.
List the tests to be performed on the software and relate them to the functions in paragraph 3.a(2).
(4) Test Progression. Describe the menner in which progression is made from one test to another so that the entire test cycle is completed.
b.
Method and Constraints.
(1) Methodology.
Describe the general method or strategy of the testing.
(2 ', Conditions. Specify the type of input to be used, such as live or test data, as well as the volume and frequency of the input.
(3) Extent.
Indicate the extent of the testing, such as total or partial. Include any rationale for partial testing.
(4) Data Recording. Discuss the method to be used for recording the test results and other information about the testing.
(5) Constraints.
Indicate anticipated limitations on the test due to test conditions, such as interfaces, equipment, personnel, data bases.
O Approved: October 24, 1979 60
AUTOMATIC DATA PROCESSING STANDARDS -
NRC App:ndix 0903 AUTOMATED SYSTEMS ~ DOCUMENTATION Part 3 t, 3 f
J c.
- Evaluation.
v (1) Criteria. Describe the rules to be used to evaluate test results, such as range of data values used, combinations of input types used, maximum number of allowable interrupts or halts.
(2) Data Reduction.
Describe the techniques to be used for manipulating the test data into a form suitable for evaluation, such as manual or automated methods, to allow comparison of the results that should be produced to those that are produced.
4.
TEST. DESCRIPTIONS a.
Test (Identify). Describe the ted to be performed.
(1) Control.
Describe the test control, such as manual, semi-automatic, or automatic insertion of inputs, sequencing of operations, and recording of results.
(2) Inputs.
Describe the input data and input commands used during the test.
(3) Outputs.
Describe the output data expected as a result of the test and any intermediate messages that may be produced.
{N (4) Procedures. Specify the step-by-step procedures to accomplish g's) the test.
Include test setup,
initialization, steps,
and termination.
i b.
Test (Identify).
Describe the second and subsequent tests in a manner similar to that used in paragraph 4.3.
i
(' M
(
)
wJ 61 Approved: October 24, 1979 y
i AUTOMATIC DATA PROCESSING STANDARDS -
NRC Appendix 0903 AUTOMATED. SYSTEMS DOCUMENTATION Part 3 l-F.
AUTOMATED SYSTEM TEST ANALYSIS REPORT The purpose of the Test Analysis Report is to document the test analysis results and findings; present the demonstrated capabilities and deficiencies for review; and provide a basis for preparing a statement of software readiness for implementation.
1 i
<l 4
J j
e
- l l,
l 63 Approved: October 24, 1979 l'
I
~
- AUTOMATIC DATA PROCESSING STANDARDS -
NRC Appendix 0903 AUTOMATED SYSTEMS DOCUMENTATION Part 3 AUTOMATED SYSTEM TEST ANALYSIS REPORT CONIENTS 4
Page SECTION 1.
GENERAL INFORMATION..................................
67
~
a.
Summary.................................................
67 b.
Environment...............
67 c.
References..............................................
67 e'
SECTION 2.
TEST RESULTS AND FINDINGS.............................
67 I
a.
Test (Identify).........................................
67 l
(1) Dynamic Data Performance...........................
67.
(2) Static Data Performance............................
67 b.
. Test (Identify).........................................
67 SECTION 3.
SOFTWARE FUNCTION FINDINGS............................
67
[
I a.
Function (Identify)...................................
67
- (
(1)
Performance........................................
67 (2)
Limits.............................................
68 b.
Function (Identify).....................................
68 i
SECTION 4.
ANALYSIS
SUMMARY
68 a.
Capabilities............................................
68 b.
Deficiencies............................................
68 c.
Recommendations and Estimates...........................
68 4
i 4
a 0\\
65 Approved: October 24, 1979
~
AUTOMATIC DATA PROCESSING STANDARDS -
NRC Appendix 0903 AUTOMATED SYSTEMS DOCUMENTATION Part 3 O'V!
1.
GENERAL INFORMATION a.
Summary.
Summarize both the general functions of the software tested and the test analysis 1 erformed.
b.
Environment.
Identify the software sponsor, developer, user organization, and the computer center where the software is to be installed.
Assess the manner in which the test environment may be
. different from the operational environment and the effects of this difference on the tests, c.
References. List applicable references, such as:
(1) Project request (authorization).
(2) Previously published documents on the project.
-(3) Documentation concerning related projects.
(4) FIPS publications and other reference documents.
2.
TEST RESULTS AND FINDINGS Identify and present the results and findings of each test separately in paragraphs 2.1 through 2.n.
a.
Test (Identify).
O)
(1) Dynamic Data Performance.
Compare the dynamic data input I
(
and output results, including the output of internally generated data, of this test with the dynamic data input and output i
}
requirements. State the findings.
l (2) Static Data Performance.
Compare the static data input and output results, including the output of internally generated
- data, of this test with static data input and output requirements. State the findings.
b.
Test (Identify). Present the results and findings of the second and succeeding tests in a
manner similar to that of paragraph 2.1.
3.
SOFTWARE FUNCTION FINDINGS Identify and describe the findings on each function separately in paragraphs 3.1 through 3.n.
a.
Function (Identify).
(1) Performance.
Describe briefly the function.
Describe the software capabilities that were designed to satisfy this function.
State the findings as to the demonstrated capabilities from one or more tests.
4
(.
67 Approved: October 24, 1979
?
r-er r
NRC App:ndix 0903 AUTOMATIC DATA PROCESSING STANDARDS -
Part 3 AUTOMATED SYSTEMS DOCUMENTATION (2) Limits.
Describe the range of data values tested, including both dynamic and static data. Identify the deficiencies, limita-tions, and constraints detected in the software during the testing with respect to this function.
b.
Function (Identify).
Present the findings on the second and succeeding functions in a manner similar to that of paragraph 3.1.
4.
ANALYSIS
SUMMARY
a.
Capabilities.
Describe the capabilities of the software as demon-strated by the tests.
Where tests were to demonstrate fulfillment of one or more specific performance requirements, prepare findings showing the comparison of the results with these requirements.
Assess the effects any difference in the test environment, as compared to the operational environment,may have had on this test demonstration of capabilities.
b.
Deficiencies.
Describe the deficiencies of the software as demon-strated by the tests.
Describe the impact of each deficiency on the performance of the sof tware.
Describe the cumulative or overall impact on performance of all detected deficiencies.
c.
Recommendations and Estimates.
For each deficiency, provide any estimates of time and effort required for its correction and any recommendations as to:
(1) The urgency of each correction.
(2) Parties responsible for corrections.
(3) How the corrections should be made.
State the readiness for implementations of the software.
O Approved: October 24, 1979 68
AUTOMATIC. DATA PROCESSING STANDARDS -
AUTOMATED SYSTEMS DOCUMENTATION NRC Appendix 0903 m
i 1
i EXHIBITS The following exhibits are presented for guidance only.
It is not necessary that the forms be used provided all applicable information is presented in the i
document.
Additional ADP forms are also available (in stock) which are not included as exhibits. Copies are available from the Division of ADP Support.
l 1
1 4
i 1
69 Approved: October 24, 1979
,,,-,y
,-,--r,
,--...,--e,-
i i
i AUTOMATIC DATA PROCESSING STANDARDS -
NRC Appendix 0903 l'
AUTOMATED SYSTEMS DOCUMENTATION Exhibit 1-f-
l l
EXHIBIT 1 i
STANDARD TITLE PAGE i
SYSTEM NAME DOCUMENT NUMBER-4 1
i i.
i I
Contract Number:
l (If Applicable) i Author I
Approved 4
1 o
i I
4 j
Approved:
(Date) i i
i i
l I
i i
l i
i i
i i
71
. Approved: October 24, 1979-
7 c.
' ~
i
\\
\\
\\
IMAGE' EVALUATION M
TEST TARGET (MT-3) i
\\
r i
A a
'l
/
l.0 d fM EE I
2 E M g =2.2
& laa 2 m g =2A Is 11
?.:
\\
.8 i
\\
'I.25 1.4
- .6
'N
\\j!
f.
4 6"
I MICROCOPY RESOLUTION TEST CHART
./
i..
- \\
i e
s 1
_e o v.
_s.._., _ }e' ' ? -
s n
ft7 '
'l '
c{
ll s.
- c. a.
c i4
.; w L
s L, 1 _
x,p -
U'. 1-e' a
(
\\
s i
\\\\
\\\\\\\\/ g j,I gk k ie
////j/c
(
/
M.
N
\\
IMAGE' EVALUATION TEST TARGET (MT-3)
-l l
l.0 dEnBL4 a su E =2.2 5: tu l.1 b* EN
, ('
.8 i
s s
1.25 1.4 1.6
'N
\\s t I
6"
=
MICROCOPY RESOLUTION TEST C. i/ 9
/
~/
\\
\\l l
\\'
/
o e
gp D 4%
{
g
,g4
/4N' 3
Akhs nnn8{><>+w Q
A e/ n :x w..
a J
o tl-m s
L.
'(
-e
>\\
? l. 2' - ~.
]
t y
1
NRC Appendix 0903 AUTOMATIC DATA PROCESSING STANDARDS -
Exhibit 2 AUTOMATED SYSTEMS DOCUMENTATION EXHIBIT 2 AMENDMENT PAGE 1
SYSTEM NAME DOCUMENT NUMBER- **
AMENDMENT PAGE DATE AMEND NO.
WORK ORDER AUTHOR APPROVAL PAGES AFFECTED OR PROJECT NO.
O APPROVED:
(Date)
O Approved: October 24, 1979 72
AUTOMATIC DATA PROCESSING STANDARDS -
NRC Appendix 0903 AUTOMATED ~ SYSTEMS DOCUMENTATION Exhibit 3 i.
E5HIBIT 3 l
i COST AND COST COMPARISON ESTIMATES I
1
. SYSTEM NAME DOCUMENT NUMBER:
' COSTS AND COST COMPARISON ESTIMATES By Fiscal Year for the Life of the Proposed System (not less than five years) f Total j
j 1.
Present System Number Cost Costs l
i-l a.
Non-ADP:
.t i
Personnel i
l
.(Indicate by type; i.e.,
j clerks, typists, etc..)
j Total Personnel Costs s
i Forms Quantity Cost Total Forms Equipment Hours Cost (Indicate by type of machine)
Total Equipment Cost Other Cost j
(Itemize)
Total Other 4
Total Non-ADP Costs 1
l 1
,k j~
73-Approved: October 24, 1979
O NitC Appendix 0903 AUTOMATIC DATA PROCESSING STANDARDS -
Exhibit 3 AUTOMATED SYSTEMS DOCUMENTATION By Fiscal Year for the Life of the Proposed System (not less than five years)
Total Number Cost Costs b.
ADP:
Personnel (Indicate by type; i.e.,
Data Entry Computer Operations, Systems Analysis / Programming, Clerical, etc.)
Total Personnel Cost Cards and Forms Quantity Cost Total Cards and Forms Equipment Cost Hours Cost (Indicate by type of machine)
Total Equipment Cost Other Costs Cost (Iter.ize)
Total Cost Present System Travel Total ADP Cost l
TOTAL COST PRESENT SYSTEM l
O' Approved:
October 24, 1979 74
i
~
~ AUTOMATIC' DATA PROCESSING STANDARDS -
NRC Appendix 0903 AUTOMATED SYSTEMS DOCUMENTATION Exhibit 3 i
~
By Fiscal Year,for the Life of the Proposed System (not less than five years)
Total 2.
' Proposed System Operational Costs Number Cost Costs l
- a.
Non-ADP:
l Personnel (Indicate by.ype; i.e.,
j clerks, typists, etc.)
i j
Total Personnel Costs I-
{
Forms Quantity Cost i
i I
Total Forms i
^
Equipment Hours Cost (Indicate by type of machine)
Total Equipment Cost t
l Other Cost (Itemize)
Total'Other
~ cal Non-ADP Costs 1
I I
i i
l '-
~
i 75 Approved: October 24, 1979
= - -.
--,-_...m.m.<,,
m.,..,
._-,_m-
NRC Appendix 0903 AUTOMATIC DATA PROCESSING STANDARDS -
Exhibit 3 AUTOMATED SYSTEMS DOCUMENTATION By Fiscal Year for the Life of the Proposed System (not less than five years)
Total Number Cost Costs b.
ADP:
Personnel (Indicate by type; i.e.,
Data Entry, Computer Operations,5ystems Analysis / Programming, Clerical, etc.)
Total Personnel Cost Supplies Quantity Cost (paper, cards, etc.)
Total Supplies Equipment Cost Hours Cost (Indicate by type of machine)
(Include rent and maintenance)
Total Equipment Cost Computer Utilization Costs Cost (time sharing)
(Itemize)
Total Other Travel Total ADP Cost TOTAL COST PROPOSED SYSTEM O
Approved: October 24, 1979 76
AUTOMATIC DATA PROCESSING STANDARDS -
NRC Appendix 0903 AUTOMATED SYSTEMS DOCUMENTATION Exhibit 3 By Fiscal Year Total 3.
One-Time Costs Number Period Cost Costs a.
Non-ADF:
Personnel 4
(Indicate by type, i.e.,
clerks, typists, etc.)
Total Direct Personnel Costs Travel i
Total
. Supplies Quantity Cost Costs Total Supplies Equipment / Site Preparation Hours Cjst i
\\
Total Equipment / Site
}
Preparation Cost Other Cost (Itemize)
Total Other Total Non-ADP Costs-
~
i k
77 Approved: October 24, 1979 4
t
NRC App::ndix 0903 AUTOMATIC DATA PROCESSING STANDARDS -
Exhibit 3 AUTOMATED SYSTEMS DOCUMENTATION Total Number Period Cost Costs b.
ADP:
Personnel Systems Analysts Programmers Data Entry Computer Operators Clerical Total Direct Personnel Cost Total Equipment and Service Time Hours Cost Costs Data Entry and Transcription Equipment Acquisition Total Equipment and Service Costs Travel Supplies Quantity Cost Total Supplies Computer Utilization Costs System Development System testing System Implementation 1
O Approved October 24, 1979 78
AUTOMATIC _ DATA PROCESSING STANDARDS -
- NRC Appendix 0903 AUTOMATED SYSTEMS DOCUMENTATION Exhibit 3 Og
'\\ j
.4.
Other Costs Cost Costs i --
Total i
Total ADP One-Time Costs Total One-Time Costs 5.
Cost Comparison By, Fiscal Year - from one to five years of Proposed Systera Operation
]
~
System System Difference Present Proposed Non-ADP Operations i
ADP Operations Total Non-ADP One-Time Costs ADP One-Time Costs
. Total v
6.
Budget Plan By Fiscal Year for five years Non-ADP Onerations (FY)
(FY)
(FY)
(FY)
(FY)
Phase dowr, current system One-time cost Phase up proposed system ADP Costs Phase down current system One-time cost-Phase.up proposed system T0T'AL COST
- O 79 Approved: October 24, 1979
AUTOMATIC DATA PROCESSING STANDARDS -
AUTOMATED SYSTEMS DOCUMENTATION NRC Appendix 0903
/ m)
'%.J EXIIIBIT 4 QUESTIONNAIRE FOR SYSTEM CONTROLS AND AUDIT TRAILS The following items should be reviewed from the viewpoint of system controls.
The questions are pertinent to developing sound systems.
1.
Data Collection, a.
IIow many types of data are collected?
b.
From how many collection points?
c.
Are there differences in the quality or completeness of data collected from various locations?
d.
Must data be assembled or consolidated at intermediate points prior to entering the system?
e.
Must information be converted to coded representation prior to processing?
O f.
Are standard codes used instead of nonstandard abbreviations and variable long hand expressions?
1 g.
Is the coding scheme uniformly applied in alllocations?
h.
Is the source document medium or format changed during collection?
i.
What is the volume of the data collected?
j.
Are there critical collection deadlines beyond which the system must proceed without the latest data?
k.
Are standard or common codes used to facilitate data interchange between systems?
2.
Data Editing Control.
a.
Does editing include data cross-correlation?
b.
Must master files be used during editing?
c.
Must master tables be used during editing?
'd.
Is editing completed in a single process?
/D
- kv/
81.
Approved: October 24, 1979
~
NRC Appendix 0903 AUTOMATIC DATA PROCESSING STANDARDS -
Exhibit 4 AUTOMATED SYSTEMS DOCUMENTATION c.
Does the editing procedure vary due to external conditions such as season? Peak period? Location?
3.
Error Correction.
a.
Does error correction require rewriting the source document?
b.
Is error correction performed throughout the processing cycle?
c.
Is error correction performed completely prior to release of the data?
d.
Are there procedures for identifying and purging erroneous data?
e.
Can the corrections be made before the data has been processed through the system?
f.
Is it necessary to correct other data in the source document containing the error (interactions with other systems)?
g.
Are procedures to correct data simple for the user?
4.
Data Sequencing.
a.
Is the sequencing code or key available in the source document?
b.
Can processing be accomplished efficiently without sequencing the source documents?
c.
Is data presented on multiple documents which require correlation?
d.
Is editing sequence the same as processing sequence? Reporting sequence? Are input / output files sequence checked?
c.
How many sequences are required during processing? Are sequence checks performed in each case?
f.
Are record counts maintained to guard against lost or gained records during sequencing? Are record counts made on all files?
g.
Are all input sequences sorted?
~
5.
Collating.
a.
Against how many master files (and which) must transaction records be compared during processing?
b.
Is resequencing required between comparisons?
c.
Is the key or code for collating available on both the master file and the source document?
O Approved: October 24, 1979 82
-' AUTOMATIC DATA PROCESSING STANDARDS -
NRC Appendix 0903 AUTOMATED' SYSTEMS DOCUMENTATION-Exhibit 4
(/
-d.
Must each transaction record have a matching mastar record?
4 6.
Calculation and Data Transfer.
a.
Are factors from sources other than the source document required for
[
necessary calculations?
b.
Are there additional sources; master files, tables, or other source documents?
3 -,
i c,
Are mechanical devices (adding machines, desk calculators, etc.)
required in performing the calculations?
7.
File Updating.
a.
What is the frequency of master file update?
j
}-
b.
.Must all transactions for a processing period be available during the updating process?
c.
Are partial updates made?
Are the transactions separated by transaction type? Time, period? Master record classification?
l d.
Must all source data be corrected prior to updating the master file?
Is the master file purged of inactive records periodically?
e.
G f.
Must new master records be added or be deleted prior to updating the i
file with transactions?
g.
Is the updating process continuously performed during a cycle or is batch processing used?
h.
. Are purged records transferred to a history file? Condensed?
i.
In case ' of equipment failure during the processing cycle, can processing be re-started in mid-job, at/or near the point of failure?
8.
Inquiry Response.
i a.
With what frequency are special requests received for data?
b.
Will special requests for data be classified by type? For example:
i Whose records? Selected fields? Summaries?
c.
Are references to several master files required to answer inquiries?
d.
What '.is the actual, not desired, normal response time to request?
Minimum? Maximum?
Okv.l 83 Approved:. October 24, 1979 y
e
-r'
- -, +
yp w
=r- - - --,
r-
-e--
- ~ -
y e.-
gw--
F,g-r
--*,yw ryw
NRC Appendix 0903 AUTOMATIC DATA PROCESSING STANDARDS -
Exhibit 4 AUTOMATED SYSTEMS DOCUMENTATION e.
Is inquiry processing allowed to interrupt file updating?
Is file updating allowed to interrupt inquiries?
f.
What is the volume of inquiries?
As a percentage of master records? As a percentage of all transaction records?
g.
Are requests for inactive historical information received?
h.
Whe v.kes the request?
i.
Are terminals in a secure area? Do transmission lines go outside a secure area? Who will have access to terminals and how controlled?
~
9.
Data Summarization.
a.
Are summaries prepared routinely?
b.
Are summaries prepared on demand?
Are summaries based upon classification coded in the source data?
c.
Master files?
10.
Report Preparation.
How many reports are prepared by the system on a regular basis a.
and how many on demand?
b.
How many reports are abstracted exclusively from source documents?
How many reports are abstracted exclusively from master files?
c.
d.
Are the report sequence keys available in the source data?
e.
Do the reports contain intermediate summaries?
f.
In how many cases is the same data presented in varying sequences or fonnats?
g.
Disposition of reports:
Further processing?
Correlation with others? Reviewed by whom?
11.
Programming Controls, a.
What accounting and recc.
count controls are necessary?
b.
What action should be taken when controls are not balanced?
What record editing, verification, and validation are required?
c.
i O
Approved: October 24, 1979 84
i AUTOMATIC DATA PROCESSING STANDARDS -
NRC Appendix 0903
~ AUTOMATED SYSTEMS DOCUMETATION Exhibit 4
]AU)
-d.
What actica should be taken for records which fail to satisfy verifi-cation and validation requirements?
What audit trail information is required for all phases of processing?
e.
f.
Are master or. transaction data records checked for sequence after being read for processing?
g.
Are limit checks (amounts or quantities developed or taken directly from the data or transactions records) compared with specified limits or quantities?
h.
Does crossfooting balance check the accuracy of postings or updates?
l i.
What checkpoint and restart procedures are necessary?
j.
Are header, label, and trailer checks made?
k.
Are. procedures required to record all manual interferences in running the program?
1.
Does program include procedures to set condition codes when errors are detected? Will subsequent related programs in the job stream include procedures ' to ~ test the condition code in order to prevent i
further processing?
g N._ /
12.
Security - Classification.
a.
Is the source data classified? If so, is it properly identified (e.g.,
headers) and safeguarded (e.g., placed in security containers)?
b.
Is the output classified?
If so, is it properly identified (e.g.,
security classification markings and other markings) and safeguarded (e.g., accountability maintained and access controlled)?
c.
IIas data control been notified that a classified job is being run or a classified file is being accessed so as to assure that the proper access codes have been assigned to the programmer or the user?
d.
IIas the programmer or user been appraised of the general ADP security measures and features applicable to the system?
e.
IIave all classified files been " set-up" as classified and have procedures been established for file protection?
13.
General Controls, a.
IIave controls been reviewed by. internal auditors?
b.
What controls should be exercised by Data Control personnel?
.O)
I j
(x_/
l 85 Approved: October 24, 1979
NRC Appendix 0903 AUTOMATIC DATA PROCESSING STANDARDS -
j Exhibit 4 AUTOMATED SYSTEMS DOCUMENTATION c.
IIave retantion schedules been established?
d.
What files and documentation should be located off-site for protection in the event of a disturbance or national emergency?
O l
l l
l 1
i l
Approved: October 24, 1979 86 i
l
' AUTOMATIC DATA PROCESSING STANDARDS '-
.~ AUTOMATED SYSTEMS DOCUMENTATION NRC Appendix 0903 1
f%
\\
]
v' EXHIBIT 5 SYSTEM CONTPOLS AND AUDIT TRAILS A.
System Development.
1.
The systems analyst, the user representative, privacy and security officers (where appropriate), and the internal audit representative (where appropriate), each has a direct. responsibility in the estab-lishment, justification, and verification of minimum cc ntrols and trails necessary to ensure:
o a.
that valid data is processed completely, and that the system produces needed information, records, and reports for the data system user and for the auditor.
b.
that invalid data is rejected.
c.
that questionable data, if allowed to enter the system, is flagged for review by the user.
d.
that the controls and audit trails imposed are reasonable, efficient, and economical.
/n
(
e.
that the controls and audit trails satisfy privacy, security and internal audit requirements.
f.
that adequate data-conversion controls, where required, are established.
g.
that retention schedules are provided to control the disposition of magnetic files and output reports (see Chapter 0230).
h.
that privacy, security and security-classification are satisfied.
i.
that the machine editing is used where possible.
e 2.
Establishment of controls and audit trails shall be given equal consideration with other parts of the system during system development.
The Questionnaire for System Controls and Audit Trails (see Exhibit 4) shall be reviewed by the system analyst, the user representative, the internal audit representative
()vhere appropriate), to ensure that sufficient weight - is given to system controls, edit routines, and audit trails.
O
\\
1 x.-
87 Approved: October 24, 1979
NRC App ndix 0903 AUTOMATIC DATA PROCESSING STANDARDS -
Exhibit 5 AUTOMATED SYSTEMS DOCUMENTATION B.
System Operations, 1.
Data Originator. The data originator must review and edit the user input form, the source document, and other source information to ensure accurate conversion of input dcta for machine processing.
l Data appropriately checked would include identification or descriptive information, such as controlling codes, customer names, extensions, control totals, and security classification and other markings. The appropriate data may be entered on keypunch coding or transcription sheets, into punched cards or punched paper tape, magnetic recording device, or directly into the computar via a remote device.
2.
Data Control Section. The Data Control Section shall ensure that all input data is received, prepared for processing, and processed on a timcly basis, and that output is received, controlled, and distributed as directed.
When a production job fails to run to completion, appropriate documentation shall be made of the cause for the failure and the corrective action taken.
C.
Types of System Controls and Audit Trails.
The following paragraphs contain types of controls by function, e.g.,
input and output.
The controls are not all inclusive.
One or more controls may be applicable depending on the function ind the objective of the system. Since an audit trail is a means of tracing the movement of data from computer output back to the original data source, the controls listed may be equally applicable for audit trail.
1.
Input Controls.
These controls are normally associated with data input to the system:
a.
document count or numeric control such as:
hours, rates, dollars, units, quantities, and serial numbers.
b.
cource documents with printed numbers, registers or logs, and transmittal forms.
c.
manually or mechanically prepared batch summary totals--daily, weekly, or other cycle.
d.
manually or mechanically prepared summary totals to control various document batches.
This may involve a total system, such as payroll.
c.
references to source documents submitted for processing and to pertinent keypunch worksheets.
O Approved: October 24, 1979 88
AUTOMATIC DATA PROCESSING STANDARDS -
NRC Appendix 0903 AUTOMATED SYSTEMS DOCUMENTATION Exhibit 5
[)
V 2.
Transmittal Controls. These controls are normally associated with the movement of source documents and the distribution of output. See NRC Appendix
- 2101, Part XII, for instructions regarding transmission of classified documents.
a.
Receipt from or return to source.
b.
Maintenance of logs or other records.
c.
Issuance of or return to Computer Operations.
d.
Record of distribution of output.
3.
Output Controls. These controls are normally associated with output either in punched cards, printed copy, or recorded on magnetic tape, disk or card. Their purpose is to prove that the required processing took place.
a.
Hash control totals, like totals of order numbers in a batch of documents.
b.
Count of records corresponding to the number of records for a transaction, an account balance, or total system balance.
.A c.
Columnar totals and crossfootings to check columnar totals.
)
V d.
Zero balancing, to prove accuracy of compuMtions within known totals.
e.
Listing of file contents, if appropriate.
4.
Data Controls.
The Data Control Section shall develop and maintain essential controls to monitor the flow of jobs and to ensure that data is processed adequately and efficiently on a timely basis, that output is as required by system documentation, and that output medium is
. appropriately safeguarded.
The minimum controls outlined in the following paragraphs are for guidance in the development of internal procedures. These controls shall be automated where feasible.
a.
Data Input.
Data Control personnel shall maintain a log or record of the receipt and movement of data and documents. A job requestor shall initiate a work request or, if necessary, an input checklist form developed by the system analyst for each system with assistance from Data Control personnel.
This checklist form should include items such as-.itle and number of document, date received, security c' aification and other markings, system number, procedure number, program number, processing date,
"as-of"
- date,
date to and from A
(
)
m./
89 Approved: October 24, 1979
NRC Appendix 0903 AUTOMATIC DATA PROCESSING STANDARDS -
Exhibit 5 AUTOMATED SYSTEMS DOCUMENTATION keypunch, key verification requirements, header-trailer batch card requirements. number of cards prepared, and date and disposition of source documents; and it should be designed with check boxes, where possible.
b.
Data Entry Keypunch. Personnel shall maintain a record or log containing entries of the number of source documents received, date received,, date keypunched and by whom, date key-verified and by whom, number of records punched and verified, and date of disposition.
S.
Data Library. Data Control personnel shall maintain a record or log of:
3 a.
each magnetic file created that positively identifies the file, to ensure that the correct file is sent to the Computer Operator for processing.
b.
the files which leave the Computer Center, showing data and person to whom issued a date returned.
c.
the location and disposition of file copies kept offsite for backup purposes.
6.
Data Output.
Data Control personnel shall maintain a record for output of production processing showing date distributed, recipients, and classification of job.
3 9
O Approved: October 24, 1979 90
m8 CROSS REFERENCE CHARTS R*
6 t
1.
M E
Input Transaction u
Data Element Source Document Record / File or Screen Format Output Report
,8 S
O If data element is o
y system generated, identify the y
formula and o
corresponding o
data elements uscu.
c.
2.
r$
e Record / File Program Procedure Job Q
b A:
<Z CQ m
QO C
g-
<P M
p<
N mbZ U d Ze mD mO NO OQ Oc:6 As
m
<Q@
O O
-m bb EE OO HH pp O
O O
-