EPA
United States
Environmental Protection
Agency
Office of Information
Resources Management
Washington DC 20460
OIRM 87.02
10,87
EPA SYSTEM DESIGN &
DEVELOPMENT GUIDANCE:
-------
United States Office of Information OIRM 87.Q2A
TT1 ¥3 A Environmental Protection Resources Management 10/87
Fv j f\ Agency Washington DC 20460
EPA SYSTEM DESIGN &
DEVELOPMENT GUIDANCE:
VOLUME A:
MISSION
NEEDS ANALYSIS
-------
Volume A
Executive Summary
This document constructs a framework around which Agency pro-
gram managers and contracting officers can document a problem and
justify the need for an information processing solution. The ob-
jective of this document is to provide guidance towards satisfying
requirements specified in EPA's IRM Policy Manual for the acquisi-
tion and management of information technology.
The guidelines within this document are designed to provide
program managers and their staff with a suggested methodology for
assessing and evaluating the need for information processing. Ap-
plying the methodology in this volume will result in two outputs:
1) a preliminary specification of a management requii .merit for in-
formation or information processing; and the outputs and benefits
tied to the user's organization mission and operation, and 2) an
"Initial System Concept" which provides an initial depiction of
the inputs, outputs, and processes.
Completion of the steps outlined in this document will pro-
vide management with the information required to make a decision
whether or not to proceed to the Preliminary Design and Options
Analysis task defined in Volume B. The following exhibit de-
scribes the complete software life cycle. Each process in the
software life cycle is represented by a circle with its corre-'
spending title on the inside of the circle. Inputs to the Mission
Needs Analysis or factors that influence the process are shown
surrounding the circle. As indicated, influencing factors are:
new legislation, changes to regulations, program growth and the
preceding process Software Obsolescence.
-------
Complete Software
Life Cycle
Volume A
New
Legislation
\
Volume B
Mission
Needs
Analysis
Software
Obsolescence
Preliminary
Design &
Options
Analysis
\
Program
Growth
Changes
to
Regulations
Software
Improvement
Increment
System
Design
System
Development
Software
Improvement
Increment
System
Implementation
System
Improvement
Plan
Volume C
-------
EPA System Design & Development
Guidance: Volume A
TABLE OF CONTENTS
Tltlft Page
1. Introduction 1-1
1.1 Background 1-1
1.2 Objectives of the System Design and
Development Guidance 1-1
1.3 Authority 1-5
1.4 Applicability of the Guidance 1-5
1.5 Documentation Requirements 1-5
1.6 Assistance and Support Available 1-9
2. Conducting the Mission Needs Analysis and
Developing the Initial System Concept 2-1
2.1 Step 1 - Review of System Need Background
and the Mission and Organizational
Needs 2-3
2.2 Step 2 - Identification and Preliminary
Specification of System Inputs,
Processes, and Outputs and Development
of the "Initial System Concept" 2-4
2.3 Step 3 - Evaluation and Testing, of the
Initial System Concept Through User
Review 2-8
2.4 Step 4 - Final Specification and
Documentation of Results in the
Mission Needs Statement 2-9
2.5 Step 5 - Initiation of the Project
Management Plan 2-9
3. Summary 3-1
3~"! 1 'Mission Needs Analysis Outputs 3-1
3.2 Next Steps 3-1
Appendix A Essential Elements of Information A-l
LIST OF EXHIBITS
1-1 EPA System Development Life Cycle
and Decision Process 1-3
1-2 EPA System Development Life Cycle
Documentation 1-6
1-3 System Category/EEI Matrix 1-10
2-1 Process Flow of Site Information 2-6
2-2 Initial System Concept - Site
Management System 2-7
111
-------
EPA System Design & Development
Guidance: Volume A
1. INTRODUCTION
Pursuant to the Environmental Protection Agency's IRM Policy
Manual, this volume is the first of three volumes which provide
guidance for Agency system design and development efforts. This
volume provides guidance for the first phase of the EPA system
development process The Mission Needs Analysis.
Volume A is intended for use by Agency Program and Management
Officials and responsible staff when making a determination
regarding an information or information processing need and
whether to commit resources to identify, develop, and implement an
appropriate solution to satisfy that need.
1.1 BACKGROUND
The Environmental Protection Agency expends millions of
dollars each year on the design, development, implementation and
maintenance of major environmental and administrative systems
vital to EPA's programs and administrative functioning.
Management of these system resources is becoming increasingly
complex, since the rapid development of information technology in
the 1980's has dramatically increased computer capacity and user
accessibility. The result has been two-fold:
. An increasing number of system development efforts by
managers and staff at all organizational levels who,
because of access to their own equipment, develop their own
systems independently of Agency systems staff
. A wide range of hardware/software options for
implementation of any specific system concept or design.
Therefore, there has been a proliferation of system development
efforts by a broad range of users with varying levels of
sophistication in making system development decisions and
conducting system development efforts.
1.2 OBJECTIVES OF THE SYSTEM DESIGN AND DEVELOPMENT GUIDANCE
Within EPA's Office of Administration and Resources
Management (OARM), the Office of Information Resources Management
(OIRM) is responsible for ensuring the effective and efficient use
of EPA's information resources including automated system design,
development and maintenance. OIRM's objective in this endeavor is
to provide guidance, assistance, and only when necessary,
controls, to assure that the Agency's considerable information
resources are utilized cost-effectively for the overall benefit of
the Agency. To this end, OIRM has developed umbrella policies
guiding information system development and acquisition (see
Information Resources Management Policy Manual) and has also
1-1
-------
EPA System Design & Development
Guidance: Volume A
developed this three-volume set of guidelines and standards to
assist with EPA's system development efforts. These three volumes
provide sequential guidance for:
. Defining the system requirement (or need) and related
operating concept
. Developing feasible system options and selecting the most
cost-effective option
. Designing, developing and implementing the selected system
option.
Exhibit 1-1, following this page, graphically depicts the three
major phases of the system development life cycle and the
decisions and results expected of each phase. However, EPA's
system development life cycle discussed in these volumes
represents little more than fifty-five percent of the total life
cycle of a software application. Typical cost allocations for
each major component of the total system life cycle are
represented in the graph below.
Life Cycle Costs 1
Mission Needs Analysis /
Preliminary Design &
Options Analysis 5.0%
Detailed Design
15.0%
Software Operations & / I^^SffflTfll S°nw*re
MainJLr™ A* no/. ^mT \\ Development 5.0%
Maintenance 45.0%
'o
Software Testing,
Integration, Verification, &
Validation 30.0%
1 These figures are based on a graphic illustration in Controlling
Software Products by Tom DeMarco, 1982, which purports to
represent industry averages.
1-2
-------
EPA System Design & Development
Guidance: Volume A
EXHIBIT 1-1
EPA SYSTEM DEVELOPMENT LIFE CYCLE
& DECISION PROCESS
DEVELOPMENT STAGE
DECISION/RESULT
REAL WORLD
MISSION NEED
VOLUME A
-»
I
MISSION NEEDS
ANALYSIS
SYSTEM REQUIREMENT
AND OPERATIONAL
CONCEPT DEFINITION
VOLUME B
PRELIMINARY DESIGN
& OPTIONS ANALYSIS
SYSTEM OPTION DESIGN,
BENEFIT/COST ANALYSIS,
AND OPTION SELECTION
SYSTEM DESIGN,
DEVELOPMENT
A IMPLEMENTATION
FULLY IUPLEUENTED
SYSTEM
1-3
-------
EPA System Design & Development
Guidance: Volume A
This document is the first of the three-volume set. The
volumes cover the following:
• Volume A - Mission Needs Analysis — is designed to provide
program managers and staff with a suggested methodology for
assessing and evaluating the need (requirement) for an
information system. Applying the methodology in this
volume will result in two outputs: 1) a preliminary
specification of the management requirement for information
or information processing and the outputs and benefits tied
to the user organization's mission and operations, and 2)
an "Initial System Concept" which provides an initial
depiction of the system's input, processes and outputs.
These results: 1) confirm that a need (retirement) exists
and 2) provide a preliminary operational specification of
the retirement.
. Volume B - Preliminary Design and Options Analysis — is
directed towards program managers and staff. It provides
guidance and a methodology for structuring design options
for meeting the retirement defined in Volume A and
provides guidance for selecting the most cost-effective
option. The steps described in this volume result in the
selection of the most mission/cost-effective option (manual
or automated) based upon life cycle concepts.
. Volume C. - System Design. Development: And Implementation --
is intended for use primarily by system developers and
provides specific guidance and standards which must be
adhered to when undertaking automated system design and
development efforts.
Together these three volumes provide comprehensive guidance and
standards for the orderly and cost-effective development of
automated systems.
It should be noted that the EPA has established a
comprehensive information security program through Chapter 8 of
the IRM Policy Manual. Because retrofitting security measures
into software under development is complex, expensive and risky,
security considerations need to be an integral part of the system
development life cycle. Consequently, security issues and factors
are identified at appropriate points throughout these volumes. A
detailed discussion of security design and development
considerations is beyond the scope of this guidance. Additional
security guidance will be provided in the forthcoming EPA
Information Security Manual.
1-4
-------
EPA System Design & Development
Guidance: Volume A
1.3 AUTHORITY
The EPA System Design and Development Guidance derives its
authority from Chapter 4 of the IRM Policy Manual, entitled
"Software Management," which establishes the Agency Software
Management Program. The guidance serves as the primary guidance
for Agency system design and development efforts.
1.4 APPLICABILITY OF THE CJIITnANrP".
Senior Agency managers and responsible staff should read the
guidance and become familiar with the decision-making process
involved with system design and development efforts. They are
responsible for ensuring adequate analysis and documentation to
support the critical decisions/results illustrated in Exhibit 1-1.
The full documentation requirements for automated system
development efforts, which must be followed to conform to OARM
policy, are fully discussed in Volume C.
In general, Volumes A and B are intended to assist program
offices and/or users in conducting their own initial studies of
system requirements, needs, option feasibility and cost-
effectiveness. In this context, the term "system" in Volumes A
and B refers to a systematic set of processes and/or procedures
which can be used to meet the information needs of a user. It
does not imply that the "system'1 will be an automated system.
Volume C, however, presumes that an automated or partially
automated solution has been selected as a result of the Volume B
options analysis. Volume C provides guidance and standards for
automated system development efforts. If the automated system is
a relatively small application on a microcomputer targeted for use
within a single office (a "user owned information system"), Volume
C provides simplified requirements for system design, development
and implementation. If the proposed system is a larger
application (mainframe or minicomputer), which is mission-critical
or invcflvee multiple offices and organizations, Volume C provides
the full set of guidance and standards which must be followed by
system developers. This will assure uniform, cost-effective
system development in accordance with EPA policies, guidelines and
standards.
1.5 DOCUMENTATION REQUIREMENTS
In general, the intent of the three-volume System Design and
Development Guidance is to provide a consistent focus for system
development efforts which will allow both EPA program managers and
OARM managers to cost-effectively develop and maintain the
Agency's systems. To achieve this goal, certain documentation
requirements (termed "Essential Elements of Information" (EEI)
documents) must be met. Exhibit 1-2, following this page,
summarizes the EEI documentation requirements. As shown,
1-5
-------
EPA System Design & Development
Guidance: Volume A
EXHIBIT 1-2
EPA SYSTEM DEVELOPMENT LIFE CYCLE
DOCUMENTATION
DEVELOPMENT PHASE
DOCUMENTATION
REAL WORLD
MISSION NEED
VOLUME A
MISSION NEEDS
ANALYSIS
££/-;. MISSION
STATEMENT /INCLUDING
INITIAL SYSTEM CONCEPT}
VOLUME B
PRELIMINARY
DESIGN & OPTIONS
ANALYSIS
££1-2. PaELIMINAPY DESIGN
AND OPTIONS ANALYSIS
EEI-3. PROJECT
MANAGEMENT PLAN
VOLUME C
SYSTEM DESIGN,
DEVELOPMENT
IMPLEMENTATION
\
EEI-S 4-13. DETAILED
SYSTEMS DOCUMENTATION
[LISTED
DETAIL
1-6
-------
EPA System Design & Development
Guidance: Volume A
documentation required for the first two phases of the process —
Mission Needs Analysis and the Preliminary Design and Options
Analysis -- are limited to one and two documents, respectively.
All system development efforts are subject to the documentation
requirements of these first two phases as set out in Volumes A and
B.
If a full information system development effort is
anticipated after the first two phases, then a traditional series
of system design and development documents must be developed and
submitted as shown in Exhibit 1-2.
For certain system development efforts OIRM and office Senior
Information Resources Management Officials (SIRMOs) must be
involved in a review capacity to fulfill EPA's IRM Policy Manual
requirements. Systems falling into one or more of the following
categories must have OIRM/SIRMO review involvement:
. EPA mission critical
States, local governments or other Federal agencies
involved
. Interorganizational involvement (e.g., between Assistant
Administratorships or including Regional Office
involvement)
. Costs for system development/enhancement are projected to
exceed 3250K (excluding costs associated with long-term
system operation and maintenance)
. Information security issues involving the three general
security areas: applications security, installation
security and personnel security. In total, information
security involves the precautions taken to protect the
confidentiality, integrity and availability of information
•
j
. Privacy Act or confidential business information involved.
For system development efforts falling into any one of these
categories, OIRM and office SIRMOs must be involved beginning with
a review of EEI-1, generated at the conclusion of the Mission
Needs Analysis, as described in this volume of the EPA System
Design and Development Guidance. OIRM/SIRMO review involvement
will continue through the development life cycle of these systems
and will include all EEI documentation requirements for such
systems.
For systems not falling into one of the above categories,
EEIs may be forwarded to OIRM/SIRMOs for information and review as
they are developed.
1-7
-------
EPA System Design & Development
Guidance: Volume A
Automated systems involving information security will be
subject to one additional documentation requirement — completion
of a certification form (certification of sensitive systems is an
OMB requirement). The form, which is under development and will
be issued as part of the forthcoming EPA Information Security
Manual, will capture basic information on system sensitivity,
security requirements, security design, reviews, test scenarios,
results and safeguards. Information needed to complete the form
will be readily available in the EEI documentation. Prior to the
system being placed into use or production, the cognizant SIRMO
(or other senior official in the AA/RA's office) will need to
certify that the automated system is adequately safeguarded based
on the information in the form.
It is not OIRM's intent to burden EPA managers with a host of
documentation requirements for each system development effort.
The EEIs simply stress typical documentation requirements and
their outlines highlight major topics that need to be considered
for any system development effort. Managers may use their
professional judgment in substituting, combining, or down-scaling
the content of the EEIs to meet the unique requirements of their
project. Additionally, the EEIs set out in this volume are not
meant to conflict with or add more burden to documentation
requirements set out in other manuals (e.g., EPA/NCC ADABAS
Application Development Procedures Manual). Documentation
produced according to such other procedures will invariably
satisfy, either partially or fully, some EEI requirements.
Criteria for determining the minimum EEI documentation for a
specific system during the design, development and implementation
phase is based on the nature and scope of the information system
and its importance to EPA's mission. Four types of systems with
differing levels of EEI documentation requirements are identified
as follows:
Major Agency Information System: An information system
'" thfet requires special attention because of its importance
to an Agency mission; its high development, operating, or
maintenance costs or its significant impact on
administration of Agency programs.
Widely Accessed Information System: An information system
that is not a Major Agency Information System (although it
significantly supports accepted program goals and missions)
but is widely accessed by a combination of EPA
Headquarters, Regional Offices and/or state and local users
and other Federal agencies.
Localized Information System: An information system that
is not a Major Agency Information System but significantly
supports accepted program goals and missions and is
1-8
-------
EPA System Design & Development
Guidance: Volume A
accessed primarily by users in one major area, e.g., EPA
Headquarters, a single Agency program, or a Region.
• User Owned Information System; Unique, stand-alone system
developed to improve the efficiency or effectiveness of
operations for a single user or a small group of users.
Documentation requirements for each of these system
categories are projected in Exhibit 1-3 on the next page and in
Chapter 4 of Volume C. Policies and procedures covering the
submission, review and approval of EEIs by OIRM will be issued
under separate guidance.
1 . 6 ASSISTANCE AND SUPPORT AVAILABLE
Agency Program Management officials' embarking on a system
development effort should be aware that there are at least-two
sources available to them for assistance and support during the
system development life cycle:
. Within each AA/RA's office SIRMOs are available for
assistance, support and guidance relative to the EPA
Systems Design and Development Guidance and other OIRM
guidance and standards (e.g., Core Systems, Structured
Programming, etc.)
. OIRM, with its general IRM management oversight role and
requirements to exercise procurement approval authority,
has a staff organized to support EPA's administrative,
program and research communities.
It is appropriate to involve these support sources as early as is
feasible in the system development life cycle for most system
development efforts.
The primary reasons for early involvement of SIRMOs and OIRM
staff fre:,
. Fulfilling EPA's IRM policy for system development review
requirements
. Providing a value-added service role involving
consultation, assistance, technical standards, guidance and
interpretation of requirements
. Expediting procurement for system development efforts which
proceed to the system design, development and
implementation phase
. Providing assistance in determining user needs as early as
possible in the life cycle.
1-9
-------
EPA System Design & Development
Guidance: Volume A
EXHIBIT 1-3
EEI-13
System Integration
Test Report
EEI-12
Software User's
Reference Guide
EEI-11
Software Operations
Document
EEI-10
Software Maintenance
Document
EEI-9
Software Detailed
Design Document
EH-8
Software Preliminary
Design Document
EH-7
Software Test
and Acceptance Plan
EO-6
Software
Management Plan
EH-5
System Detailed
Requirements Document
EEU
System
Implementation Plan
EEI-3
Project Management
Plan
EQ-2
Preliminary Design
and Options Analysis
EH-1
Mission Needs
Analysis
i /
1 /
^ ^" / r^
U°/ l§
•
•
•
•
•
•
•
•
•
•
•
•
•
Systems That
Require OIRM
Involvement l
•
•
•
•
•
•
•
•
•
0
•
•
•
Major Agency
Information
Systems
•
«
•
•
•
•
•
•
•
•
•
•
•
Widely Accessed
Information
Systems
0
0
O
•
O
•
•
9
•
•
Localized
Information
Systems
©
9
9
9
9
9
User Owned
Information
Systems
X
DC
LU
LU
>
oc
O
O
LU
O
III
0
As detailed on page 1-7
1-10
-------
EPA System Design & Development
Guidance: Volume A
Achieving these objectives will strengthen EPA's system
development efforts and avoid major pitfalls that have beset
system development efforts in other government agencies (e.g.,
project stalls due to outyear funding shortages stemming from
under-projected planning or project disruptions due to failure to
get hardware/software acquisitions into the procurement cycle
expeditiously and when required).
The remainder of Volume A provides requirements for
conducting the first phase of the system development process --
the Missions Needs Analysis, including development of the Initial
System Concept.
1-11
-------
EPA System Design & Development
Guidance: Volume A
2. CONDUCTING THE MISSION NEEDS ANALYSIS
AND DEVELOPING THE INITIAL SYSTEM CONCEPT
This chapter provides guidance for the first and most
critical stage in initiating any system development effort --
the Mission Needs Analysis.
The decision to initiate system development efforts should be
based on a perceived or existing mission-based information or
information processing need. This need may be prompted by any
number of factors such as new legislation, changes in regulations,
or program growth which may create needs for additional data,
changes in practices or additional demands on existing functions
and resources.
As a result of the Mission Needs Analysis, the manager should
have a complete understanding of the problem and be able to
demonstrate that the problem and solution are within the manager's
organizational mission. This will provide the manager with the
necessary information to justify.the need for the project which is
then used to obtain procurement authority for the required
resources. The manager should be aware of the fact that once the
definition of the needs has started, adequate in-house or
contractor resources must be available to complete it.
Successful development and implementation of any system
requires careful review, understanding, and documentation of the
need for information and the functioning of the information
processes in the context of the user organization's mission and
operational framework. It is, therefore, critical that the
"mission-based need" be reviewed as the first step towards
establishing and defining the requirements for the system.
Project managers should be aware of the types of activities
involved in software development efforts and allow for slippage in
schedules due to uncertainties and unknowns. Planning for these
activities and making estimates is a difficult task for any
manager that does not do this full time. Cost and time factors
associated with implementing and managing a software development
effort are dependent on such factors as size of the project,
levels of complexity and the skill level, experience and length of
time the project team has been together.
However, it is vital that managers begin making and recording
their estimates early in the project life cycle so they can
compare them with actual recorded program costs and hours. It is
this iterative effort of comparing planned versus actual
performance that allows the manager to develop more accurate
estimation skills for future planning efforts.
2-1
-------
EPA System Design & Development
Guidance: Volume A
Information collected during the Mission Needs Analysis:
. Specifies the nature of the program mission, problem,
functions, processes and information flows
. Validates the need for information or information
processing in the context of the organizational mission
. Provides the basis for developing and evaluating an
"Initial System Concept" which will meet the need.
The five steps retired to conduct a complete Mission Needs
Analysis and develop an Initial System Concept are as follows:
. Step 1 - Background review of the evolution of the system
need, a concise statement of the problem and a review of
the user's mission, organizational structure and
operational processes. The analysis focuses on the
positions and functions of those individuals who will be
the users of the completed system. The result of this
review should be a preliminary list of potential users of
the system.
Step 2 - Identification and specification of the
information flow',, transactions and outputs the system must
or potentially could produce. The result of this step is
the development of a concise (perhaps one page) Initial
System Concept.
Step 3 - Testing and/or evaluation of the system concept bv
reviewing the concept and preliminary output "designs" wich
potential users to test their usefulness and identify
actual or potential constraints.
•* . jStep 4 - Final specification and documentation of the
results of the previous steps through development of a
Mission Needs Statement.
Step 5 - Initiation of the Project Management Plan as a
preliminary document to facilitate the planning and
scheduling of resources for the activities that follow the
Mission Needs Analysis.
The actual approach to conducting the Mission Needs Analysis
involves conducting the first four steps, and requires continual
review, revision and recycling of steps as the analysis proceeds.
The suggested approaches for conducting each of these steps are
oresented below.
2-2
-------
EPA System Design & Development
Guidance: Volume A
2-1 STEP 1 - REVIEW OF SYSTEM NEED BACKGROUND AND THE MISSION AN";
ORGANIZATIONAL NEEDS
The Mission Needs Analysis should begin with a careful review
of the organizational and operational context from which the need
evolved and the specific users which the system or systematic
solution is intended to assist. The first task is to determine
the genesis of the initially identified and/or defined need. Some
possibilities include:
. A new program or set of mission functions have been
mandated by the President, Congress or senior officials,
requiring the performance of new tasks, processes and/or
systems
. A manager has decided to perform a new function or an
existing function using different procedures in support of
the Agency's mission, goals and objectives
. An existing process or system has been evaluated and is
suspected of being inefficient, ineffective or obsolete.
In each of these cases it is important to review the
evolution of the system need to determine which of these possible
causes was principally responsible for the system development
effort. Clearly identifying which of these causes is the basis
for the system requirement is important to future development
efforts since knowing the reason for the need helps:
. Define the problem in concise terms including any
quantifiable facts or conditions related to the problem.
For example, "The program office is unable to respond to
Freedom of Information Act (FOIA) requests for data due
partly to a fifty percent increase in FOIA requests and a
five percent effective reduction in force."
•" . £>efine the specific set of users and uses
. Establish the likely priority accorded the effort by senior
Agency officials and responsible staff
. Determine whether the problem is really one requiring a
system solution or has some other underlying cause.
In conducting this background review, two primary data
collection methods may be used:
Interviews with key officials, managers and staff involved
or potentially involved in the processes to be systematized
and those who will be the end users of the system results.
These user interviews should focus on what specific outputs
2-3
-------
EPA System Design & Development
Guidance: Volume A
are required of the system and what benefits users
anticipate.
Collection and review of key documents such as relevant
legislation, agency policies or operational plans,
organizational mission/function statements or previous
studies of the function or process.
The results of the data collection efforts should be reviewed to
provide those conducting the Mission Needs Analysis with a clear
picture of the operational context within which the system will
operate.
Perhaps the critical output of this initial review is a
preliminary identification of users and potential benefits of
system outputs. A summary format for displaying this information
in a matrix format is provided below:
Potential System User/ Position/ System User
Organization Function Output Benefit
It is important that to the extent practical, this type of
matrix be completed for all major users to ensure adequate
consideration of user needs and system benefits.
2.2 STEP 2 - IDENTIFICATION AND PRELIMINARY SPECIFICATION OF
SYSTEM INPUTS, PROCESSES AND OUTPUTS AND DEVELOPMENT OF THE
"INITIAL SYSTEM CONCEPT"
Conducting Step 1 will result in the identification of the
potential system users, uses, outputs and benefits. During this
second task, the "flow" of information and work processes of the
potential system application are developed and documented. The
purpose of this step is to develop an overall understanding and
preliminary design for the flow of information and information
procfbcte. At the conclusion of this step, a brief (perhaps one
page) Initial System Concept is developed. In addition, the
documentation of the information flow ultimately provides the
basis for:
. Determining the manual processes and procedures which will
become a part of the ultimate "system solution" for the
need or problem (any and all automated systems have a set
of manual processes and procedures which support the
automated portion of the "system" and distribute its
output)
Identifying and specifying the procedures and functions
which may be automated and therefore may become the
"automated system" which will be designed.
2-4
-------
EPA System Design & Development
Guidance: Volume A
The flow of information or work processes that are candidates
to be systematized can be examined through overall flow charting
processes that depict, on a macro level, the:
. Organizations and key individuals involved in the
information flow and information products
. The input processes and documents which feed and support
the system
. The specific output products.
Exhibit 2-1 illustrates a format for a sample flow chart
which can usefully depict such information. As shown, the flow
chart contains these important elements:
. A stub (vertical axis), containing the major organizations
and/or individuals involved in the process including those
involved in:
- Input processes
- Information process flow
- System operation
- System output and use.
. The flow and interrelationships of information among the
various involved organizations
. Specifically identified outputs of the system.
The creation of a flow chart similar to, and at the
approximate level of detail as, that shown is highly recommended.
It is a systematic methodology for identifying the specific
inputs, information flow and system outputs. This flow chart can
usually be constructed from a combination of existing
documentation and limited interviews with affected organizations
and staff.
Based upon the flow chart, a higher level (ideally one page)
Initial System Concept document should be developed as in Exhibit
2-2. The concept should illustrate:
. Major system input documents/sources on the left side
. A very brief description of key "processes" and/or data
files in the center
. Graphic depictions of system "outputs" on the right sice.
In most cases it should be possible to construct the "Initial
System Concept" on one page.
2-5
-------
PROCESS FLOW OF SITE INFORMATION
ORGANIZATION
H
E
A
0
O
u
A
R
T
E
n
I
CT>
EPA
R
E
G
I
O
N
S
PROGRAM
MANAGEMENT
PROGRAM
STAFF
PROGRAM
MANAGEMENT
PROGRAM
STAFF
STATE
CONTRACTOR
PROCESS FLOW
o tn
c >v
H- >
a
ft> CO
D ^
O (/>
(0 rt
•• n>
<3
o o
f— 0)
a>
a
(D
<
0)
0)
D
rt
-------
INITIAL SYSTEM CONCEPT -
SITE MANAGEMENT SYSTEM
INPUT
PROCESS
SFTE PLAN
ACTIVITY
SCHEDULE
_
___
—
$
. M ^
' ~
. —
• .
-
.-
——— —•— IV- Z^^^
1
1
INITIATION
FORMS
_
MONTHLY UPDATE
ACTIVITY
CHOGHLSS
men
COST
HEV
SCM
MAJOR CHANGES
1
1
MAINTENANCE FORMS
CURRENT
DATA
NEW
DAIA
Site tiles (1,000)
- Project files
(1,000)
- Activity Rles
(30,000)
- Task Rles
(200,000)
OUTPUT
UPDATED SITE PLAN
SITE SUMMARY REPORT
ACTIVITY PROGRESS
REGIONAL/NATIONAL
SUMMARY
$ BY ACTIVITY
PI
X
00
M
H
MANAGEMENT ASSISTANCE
REPORTS
START LAG
ACTIVITY COMPLETION
TASK START
O PI
C TO
H->
JD in
3 •<
O w
n> rt
.. a)
O O
I— 0)
§(/)
(-••
(D i£l
O
(D
0)
(D
D
rr
-------
EPA System Design & Development
Guidance: Volume A
2.3 STEP 3 - EVALUATION AND TESTING OF THE INITIAL SYSTEM CONCEPT
THROUGH USER REVIEW
Documentation of processes and functions as outlined in Steps
1 and 2 will result in a high level Initial System Concept
depicting system inputs, processes and outputs. During this step,
the system concept is evaluated in terms of output usefulness,
input feasibility and possible constraints. A methodology which
should be employed for evaluating system usefulness is to review
the system concept as well as "mock-ups" of system outputs (hard
copy or screens) with users or potential users. The "mock-ups"
allow potential users to visualize the output of the system with
three results:
. The user is able to "relate" to the output and indicate the
benefit (or lack of benefit) of the output
. The discussion surrounding the reports can often identify
other types of needs or report designs which can be
incorporated into the Initial System Concept
. A preliminary estimate of the benefit to the user or
potential user can be made by the user.
During the review of the system concept and outputs with
users, an exploration of possible constraints to the system design
should also be conducted. Constraints and/or implementation
problems may include:
. Resistance by managers or staff to changes in operations
. Organizational impediments
. Input data compilation/collection problems
. . ^Lack of hardware accessible to the organizational units
Lack of staff and/or funds to develop and/or operate a
system
Information security needs and considerations based on the
sensitivity of the system
Limited development time.
Also, during the system concept review, the proposed output
reports can be expected to be partially redesigned in response to
suggestions and reactions to individual reports by the users.
Finally, it is at this point that system options or process
designs for achieving similar outputs can be explored with the
user. Although the options analysis is not fully conducted until
2-8
-------
EPA System Design & Development
Guidance: Volume A
a later phase of the system development life cycle (described in
Volume B), it is useful to begin identifying alternatives with the
user during this phase.
Two results should emerge from this step of the Mission Needs
Analysis:
. A refined Initial System Concept incorporating the results
of user evaluations of both the concept and proposed
outputs
. An initial assessment of the system feasibility, priorities
and constraints.
These and the results from the previous step provide the basis for
documenting each section in the Mission Needs Statement (EEI-1).
2.4 STEP 4 - FINAL SPECIFICATION AND DOCUMENTATION OF RESULTS IN
THE MISSION NEEDS STATEMENT
The next step in conducting the Mission Needs Analysis is the
formal documentation of the work performed in Steps 1 through 3 in
a Mission Needs Statement. This document need not be long. An
outline for this document is attached in Appendix A. As shown,
primary chapters in the statement include:
. A background section, with a concise statement of the
problem. It should also relate the problem and its
solution to the agency organizational unit's missions and
functions.
. An Information Flow/Initial System Concept section which
contains the Initial System Concept and also identifies:
Input data sources
- Macro information flow and functions
* - System outputs including "mock up" format
. A discussion of potential system development constraints.
The actual length of the Mission Needs Analysis document is
dependent on various factors such as: complexity of the problem or
the organizational functions and mission, the size or scope of the
Initial System Concept, the impact of any known elements of risk,
and the number and effect of potential constraints to development
and implementation.
2.5 STEP 5 - INITIATION OF THE PROJECT MANAGEMENT PLAN
The final step in conducting the Mission Needs Analysis is to
initiate a preliminary Project Management Plan. The format of the
Project Management Plan is contained in Volume B, Preliminary
2-9
-------
EPA System Design & Development
Guidance: Volume A
Design and Options Analysis. It is important to start this
planning effort as early as possible in order to plan and schedule
the resources required for the activities that follow. This
preliminary document should include the following:
. Steps and tasks associated.with Preliminary Design and
Options Analysis
. Assignment of roles and responsibilities for the purpose of
accountability
Resource allocations to accomplish the Preliminary Design
and Options Analysis
. Project costs and time frames associated with Preliminary
Design and Options Analysis.
At this stage of the system development process, there should
also be little, if any, thought given to the specific hardware or
software that is to be used to support the system. Options in
these areas will be considered as part of the options analysis
which is discussed in Volume B.
2-10
-------
EPA System Design & Development
Guidance: Volume A
3 . SUMMARY
3.1 MISSION NEEDS ANALYSTS
The outputs, documents and results of the Mission Needs
Analysis are as follows:
. EEI-1, Mission Needs Analysis, is a concise document that
describes the problem and the need to perform the process
or function in support of the organization's mission.
. An "Initial System Concept" indicating the flow of
information required to support the function, as well as
the preliminary input documents and output reports.
. An initial Project Management Plan that outlines the tasks,
resources and deliverables of the next phase of the project
effort .
3 . 2 NEXT STEPS
Once the Mission Needs Statement is complete, it should be
understood that it will continue to evolve and change as the
"Initial System Concept" proceeds through the development life
cycle. The next major step is to prepare the Preliminary Design
and Option Analysis as described in detail in Volume B. Both of
these tasks are based on information collected during the Mission
Needs Analysis and embodied in the "Initial System Concept."
3-1
-------
EPA System Design & Development
Guidance: Volume A
APPENDIX A
ESSENTIAL ELEMENTS OF INFORMATION
-------
EPA System Design & Development
Guidance: Volume A
APPENDIX A
ESSENTIAL ELEMENTS OF INFORMATION
A. ESSENTIAL ELEMENTS OF INFORMATION
This appendix provides a representative outline of the
document that will be developed during the Mission Needs Analysis
phase.
A.I INTRODUCTION
The documentation requirements contained in this appendix
apply to all software development projects, regardless of size,
complexity or origin. At a minimum, these standards apply to all
new software development projects. Maintenance and/or
enhancements to existing information systems must comply with the
requirements set out in Chapter 1, section 1.5 of Volume A,
Mission Needs Analysis.
Compliance with the standards and conventions provided in
this appendix will ensure that adequate documentation is produced
for all system development projects.
The document defined in this appendix is:
EEI-1 • • Mission Needs Statement
The following milestone chart illustrates the relative
initiation and completion of each document with respect to the
software development life cycle, its major phases, and the span
and scope of Volumes A, B, and C.
A-l
-------
DOCUMENTATION VERSUS LIFE CYCLE
Mission Needs Analysis
EEI-1
Preliminary Design/
Options Analysis
EEI-2
EEI-3
System Detailed
Requirements Analysis
EEI-4
EEI-5
EEI-6
Preliminary Design
EEI-7
EEI-8
Detailed Design
EEI-9
System Production
and Programming
EEI-10
EEI-11
EEI-12
System Integration
Testing & Evaluation
EEI-13
System Installation
System Operations &
sintenance
Volume A
Volume B
Volume C
Review
Preliminary Critical
Design Design
Review Review
Review
OT&E
Review
O M
C *0
H->
o.
CD CO
D»<
o w
0) ft
O D
M rt>
C co
3 H-
n> in
D
(D
0)
-------
EPA System Design & Development
Guidance: Volume A
EEI-1. MISSION NEEDS
1. BACKGROUND
Agency and organizational mission requiring system support
- Mission/function statement (s)
- Organizational chart with key functions/users
identified
- Operational environment
- Current system description, including manual
procedures
Evolution of system need
- New program or functions, or
- Current performance mode and limitations/problems
2 . INFORMATION FT.OW AND TNITTAL SYSTEM
. Description/documentation of information flow including:
- Organizational process flow charts
- Key input processes/documents
- Primary data integration/data base functions and
processes
- Key output report types and distribution
. "Mock-ups" of key output reports and discussion of their
benefits to users
. Initial System Concept (ideally one page) and related
description
(*
3 . DEVELOPMENT/OPERATIONAL CONSTRAINTS
. User commitment, priority, discipline and budgetary
limitations
. Policy or organizational constraints
Information security needs based on system sensitivity
Timing of need
Interface needs
Stability/flexibility of need
A-3
-------
United States
Office of Information OffiM 87-0'
-m-m » on
T? P A ? nvironn«nul Protection Resources Management
Hi I A Ag«ncy
Washington DC 20460
EPA SYSTEM DESIGN &
DEVELOPMENT GUIDANCE:
VOLUME B:
PRELIMINARY
DESIGN AND
OPTIONS ANALYSIS
-------
Volume B
Executive Summary
This document establishes the criteria that 'Agency program
managers and their staff should follow to develop a preliminary
design and analysis of all the alternative options that satisfy
the "Initial System Concept" developed during the Mission Needs
Analysis. The objective of this document is to provide guidance
towards satisfying requirements specified in EPA's IRM Policy Man-
ual for the acquisition and management of information technology.
The guidelines within this document are designed to provide
program managers and their staff with guidance and a methodology
for developing design options that satisfy the "Initial System
Concept" developed as a result of the processes in Volume A. This
document also provides guidance for selecting the most cost-effec-
tive solution for the defined problem. The steps described in
this volume will result in the selection of the most cost-effec-
tive mission based option (manual or automated) based on life
cycle concepts and an initial project management plan that out-
lines how the selected option will be defined, developed and im-
plemented.
Completion of the steps and subsequent analysis outlined in
this document will result in a list of two or more feasible solu-
tions for the problem and related documentation concerning their
descriptions, life cycle benefits and costs, a formal life cycle
benefit-cost analysis, and a summary of the risks and contingen-
cies associated with each option. After selecting an alternative,
the project management plan will be updated to reflect how the
system development effort will be accomplished. The revised pro-
ject management plan will focus on resources, scheduling and ac-
countability as well as other pertinent factors. The following
exhibit describes the complete software life cycle. Each phase in
the software life cycle is represented by a circle with its
corresponding title on the inside of the circle. Inputs to the
Preliminary Design and Options Analysis or factors that influence
the phase are shown surrounding the circle. As indicated, in-
fluencing factors are: agency budget constraints, GSA and OMB re-
quirements, available resources, and the preceding phase, the
Mission Needs Analysis.
-------
Complete Software
Life Cycle
Volume A
Volume B
Agency Budget
Contraints
\
Mission
Needs
Analysis
Software
Obsolescence
Preliminary
Design &
Options
Analysis
Available
Resources
GSA&
OMB Requirements
Software
Improvement
Increment
System.
= Design =
System
Development
Software
Improvement
Increment
System
Implementation
System
Fmproyejnent
Plan
Volume C
-------
EPA System Design and Development
Guidance: Volume B
TABLE OF CONTENTS
TiUe Page
1. Introduction 1-1
1.1 Background 1-1
1.2 Objectives of the System Design
And Development Guidance 1-1
1.3 Authority 1-5
1.4 Applicability of the Guidance 1-5
1.5 Documentation Requirements 1-5
1.6 Assistance And Support Available 1-9
2. Preliminary Options Design 2-1
2.1 Translating Management and Functional
Requirements Into Operational
Specifications 2-1
2.1.1 System Inputs 2-2
2.1.2 System Functions/Processes 2-2
2.1.3 System Outputs 2-2
2.1.4 General System Requirements 2-2
2.2 Developing Feasible System Options 2-3
2.2.1 Determining the Flexibility and Relative
Priority of Each of the Operational
Specifications 2-4
2.2.2 Reviewing the Range of Hardware and
Software Potentially Available to
Satisfy the Initial System Concept
(Management and Functional Requirements)
and Operational Specifications 2-4
2.2.3 Developing Options by Structuring
and Adjusting the Operational
Specifications and Varying Manual/
Automated Functions 2-9
3. Options Analysis 3-1
3.1 Operational and Technical Feasibility
Analysis 3-1
3.2 Life Cycle Benefit-Cost Analysis 3-1
3.2.1 Determining and Valuing Benefits 3-3
3.2.1.1 Non-recurring Cost-Reduction Benefits 3-4
3.2.1.2 Recurring Cost-Reduction Benefits 3-4
3.2.1.3 Qualitative Benefits 3-5
3.2.1.4 Determining Total Benefits 3-5
3.2.2 Determining and Valuing Costs 3-5
3.2.2.1 Non-recurring Costs 3-7
3.2.2.2 Recurring Costs 3-8
111
-------
EPA System Design and Development
Guidance: Volume B
3.2.2.3 Qualitative Costs 3-8
3.2.2.4 Determining Total Costs 3-9
3.2.3 Benefit-Cost Comparison 3-9
3.2.3.1 Benefit-Cost Ratio 3-12
3.2.3.2 Payback Period 3-12
3.2.4 OMB Benefit-Cost Approval Criteria 3-12
4. Option Selection and Documentation 4-1
4.1 Option Selection Criteria 4-1
4.2 Documentation Requirements 4-2
5. Summary 5-1
5.1 Preliminary Design and Options Analysis
Outputs 5-1
5.2 Next Steps • 5-1
Appendix A Essential Elements of Information A-l
LIST OF EXHIBITS
1-1 EPA System Development Life Cycle and
Decision Process 1-3
1-2 EPA System Development Life Cycle
Documentation 1-6
1-3 System Category/EEI Matrix 1-10
2-1 Typical Functional Requirements Analysis
Worksheet, Input/Output Flexibility of
Grants Payment Process 2-5
2-2 EPA - Agency Standard
Hardware/Software 2-6
2-3 Software Support Tool Selection Matrix
Small Systems 2-10
2-4 Software Support Tool Selection Matrix
Medium Systems 2-11
2-5 Software Support Tool Selection Matrix
Large Systems 2-12
3-1 Operational and Technical Feasibility
Analysis 3-2
3-2 Sample Summary of Time-Phased Costs and
Benefits for Option A 3-10
3-3 Sample Summary of Option
Benefits and Costs 3-11
IV
-------
EPA System Design & Development
Guidance: Volume B
1. INTRODUCTION
Pursuant to the Environmental Protection Agency's IRM Policy
Manual, this volume is the second of three volumes which provide
guidance for Agency system design and development efforts. This
volume provides guidance for the second phase of the EPA system
development process — Preliminary Design and Options Analysis.
Volume B is to be used by Agency Program and Management
Officials and responsible staff to identify alternative manual and
system solutions to problems identified in the Mission Needs
Analysis, and to select the best solution based upon life cycle
benefit-cost analysis principals.
1.1 BACKGROUND
The Environmental Procection Agency expends millions of
dollars each year on the design, development, implementation and
maintenance of major environmental and administrative systems
vital to EPA's programs and administrative functioning.
Management of these system resources is becoming increasingly
complex, since the rapid development of information technology in
the 1980's has dramatically increased computer capacity and user
accessibility. The result has been two-fold:
. An increasing number of system development efforts by
managers and staff at all organizational levels who,
because of access to their own equipment, develop their own
systems independently of Agency systems staff
. A wide range of hardware/software options for
implementation of any specific system concept or design.
Therefore, there has been a proliferation of system development
efforts by a broad range of users with varying levels of
sophistication in making system development decisions and
conducting system development efforts/
1.2 OBJECTIVES OF THE SYSTEM DESIGN AND DEVELOPMENT GUIDANCE
Within EPA's Office of Administration and Resources
Management (OARM), the Office of Information Resources Management
(OIRM) is responsible for ensuring the effective and efficient use
of EPA's information resources including automated system design,
development and maintenance. OIRM's objective in this endeavor is
to provide guidance, assistance, and only when necessary,
controls, to assure that the Agency's considerable information
resources are utilized cost-effectively for the overall benefit of
the Agency. To this end, OIRM has developed umbrella policies
guiding information system development and acquisition (see
Information Resources Management Policy Manual) and has also
1-1
-------
EPA System Design & Development
Guidance: Volume B
developed a three-volume set of guidelines and standards to assist
with EPA's system development efforts. These three volumes
provide sequential guidance for:
. Defining the system requirement (or need) and related
operating concept
. Developing feasible system options and selecting the most
cost-effective option
. Designing, developing and implementing the selected system
option.
Exhibit 1-1, following this page, graphically depicts the three
major phases of the system development life cycle and the
decisions and results expected of each phase. However, EPA's
system development life cycle discussed in these volumes
represents little more than fifty-five percent of the total life
cycle of a software application. Typical cost allocations for
each major component of the total system life cycle are
represented in the graph below.
Life Cycle Costs 1
Software Operations &
Maintenance 45.0%
Mission Needs Analysis /
Preliminary Design &
Options Analysis 5.0%
Detailed Design
15.0%
Software
Development 5.0%
Software Testing,
Integration, Verification, &
Validation 30.0%
1 These figures are based on a graphic illustration in Controlling
Software Products by Tom DeMarco, 1982, which purports to
represent industry averages.
1-2
-------
EPA System Design & Development
Guidance: Volume B
EXHIBIT 1-1
EPA SYSTEM DEVELOPMENT LIFE CYCLE
& DECISION PROCESS
DEVELOPMENT STAGE
DECISION/RESULT
I
REAL WORLD
MISSION NEED
J
'VOLUME A
MISSION NEEDS
ANALYSIS
SYSTEM REQUIREMENT
AND OPERATIONAL
CONCEPT DEFINITION
VOLUME B
PRELIMINARY DESIGN
& OPTIONS ANALYSIS
SYSTEM OPTION DESIGN.
BENEFIT/COST ANALYSIS,
AND OPTION SELECTION
VOLUME C
SYSTEM DESIGN,
DEVELOPMENT
& IMPLEMENTATION
FULLY IMPLEMENTED
SYSTEM
1-3
-------
EPA System Design & Development
Guidance: Volume B
This document is the second of the three-volume set. The
three volumes cover the following:
• Volume A - Mission Needs Analysis — is designed to provide
program managers and staff with a suggested methodology for
assessing and evaluating the need (requirement) for an
information system. Applying the methodology in this
volume will result in two outputs: 1) a preliminary
specification of the management requirement-, for information
or information processing and the outputs and benefits tied
to the user organization's mission and operations, and 2)
an "Initial System Concept" which provides an initial
depiction of the system's input, processes and outputs.
These results: 1) confirm that a need (requirement) exists
and 2) provide a preliminary operational specification of
the requirement.
. Volume B - Preliminary Design and Potions Analysis — is
directed towards program managers and staff. It provides
guidance and a methodology for structuring design options
for meeting the requirement defined in Volume A and
provides guidance for selecting the most cost-effective
option. The steps described in this volume result in the
selection of the most mission/cost-effective option (manual
or automated) based upon life cycle concepts.
• Volume C - System Design. Development And Implementation —
is intended for use primarily by system developers and
provides specific guidance and standards which must be
adhered to when undertaking automated system design and
development efforts.
Together these three volumes provide comprehensive guidance and
standards for the orderly and cost-effective development of
automated systems.
It should be noted that the EPA has established a
comprehensive information security program through Chapter 8 of
the IRM Policy Manual. Because retrofitting security measures
into software under development is complex, expensive and risky,
security considerations need to be an integral part of the system
development life cycle. Consequently, security issues and factors
are identified at appropriate points throughout these volumes. A
detailed discussion of security design and development
considerations is beyond the scope of this guidance. Additional
security guidance will be provided in the forthcoming EPA
Information Security Manual.
1-4
-------
EPA System Design & Development
Guidance: Volume B
1.3 AUTHORITY
The EPA System Design and Development Guidance derives its
authority from Chapter 4 of the IRM Policy Manual, entitled
"Software Management," which establishes the Agency Software
Management Program. The guidance serves as the primary guidance
for Agency system design and development efforts.
1.4 APPLICABILITY OF THE GUIDANCE
Senior Agency managers and responsible staff should read the
guidance and become familiar with the decision-making process
involved with system design and development efforts. They are
responsible for ensuring adequate analysis and documentation to
support the critical decisions/results illustrated in Exhibit 1-1.
The full documentation requirements for automated system
development efforts, which must be followed to conform to OARM
policy, are fully discussed in Volume C.
In general, Volumes A and B are intended to assist program
offices and/or users in conducting their own initial studies of
management requirements, needs, option feasibility and cost-
effectiveness. In this context, the term "system" in Volumes A
and B refers to a systematic set of processes and/or procedures
which can be used to meet the information needs of a user. It
does not imply that the "system" will be an automated system.
Volume C, however, presumes that an automated or partially
automated solution has been selected as a result of the Volume B
options analysis. Volume C provides both guidance and standards
for automated system development efforts. If the automated system
is a relatively small application on a microcomputer targeted for
use within a single office (a "user owned information system"),
Volume C provides simplified requirements for system design,
development, and implementation. If the proposed system is a
larger application (mainframe or minicomputer), which is mission-
critical or involves multiple offices and organizations, Volume C
provides the full set of guidance and standards which must be
followed by system developers. This will assure uniform, cost-
effective system development in accordance with EPA policies,
guidelines and standards.
1 .5 DOCUMENTATION REQUIREMENTS
In general, the intent of the three vo.lume System Design and
Development Guidance is to provide a consistent focus for system
development efforts which will allow both EPA program managers and
OARM managers to cost-effectively develop and maintain the
Agency's systems. To achieve this goal, certain documentation
requirements must be met. Exhibit 1-2, following this page,
summarizes the EEI (termed "Essential Elements of Information"
(EEI) documents) documentation requirements. As shown,
1-5
-------
EPA System Design & Development
Guidance: Volume B
EXHIBIT 1-2
EPA SYSTEM DEVELOPMENT LIFE CYCLE
DOCUMENTATION
DEVELOPMENT PHASE
DOCUMENTATION
C
REAL WORLD
MISSION NEED
'VOLUME A
MISSION NEEDS
ANALYSIS
EEI-1. MISSION NEEDS
STATEMENT (INCLUDING
INITIAL SYSTEM
U CONCEPp I
VOLUME B
PRELIMINARY
DESIGN & OPTIONS
ANALYSIS
EEI-!. PRELIMINARY DESIGN
AND OPTIONS ANALYSIS
EEI-3. PROJECT
MANAGEMENT PLAN
VOLUME C
SYSTEM DESIGN,
DEVELOPMENT
IMPLEMENTATION
EEfS 4-13. DETAILED
SYSTEMS DOCUMENTATION
(LISTED IN DETAIL
IN VOLUME C)
1-6
-------
EPA System Design & Development
Guidance: Volume B
documentation required for the first two phases of the process —
Mission Needs Analysis and the Preliminary Design and Options
Analysis — are limited to one and two documents, respectively.
All system development efforts are subject to the documentation
requirements of these first two phases as set out in Volumes A and
B.
If a full information system development effort is
anticipated after the first two phases, then a traditional series
of system design and development documents must be developed and
submitted as shown in Exhibit 1-2.
For certain system development efforts OIRM and office Senior
Information Resources Management Officials (SIRMOs) must be
involved in a review capacity to fulfill EPA's IRM Policy Manual
requirements. Systems falling into one or more of the following
categories must have OIRM/SIRMO review involvement:
. EPA mission critical
. States, local governments or other Federal agencies
involved
Interorganizational involvement (e.g., between Assistant
Administratorships or including Regional Office
involvement)
. Costs for system development/enhancement are projected to
exceed S250K (excluding costs associated with long-term
system operation and maintenance)
Information security issues involving the three general
security areas: applications security, installation
security and personnel security. In total, information
security involves the precautions taken to protect the
confidentiality, integrity and availability of information
. Privacy Act or confidential business information involved.
For system development efforts falling into any one of these
categories, OIRM and office SIRMOs must be involved beginning with
a review of EEI-1, generated at the conclusion of the Mission
Needs Analysis, as described in Volume A of the EPA System Design
and Development Guidance. OIRM/SIRMO review involvement will
continue through the development life cycle of these systems and
will include all EEI documentation requirements for such systems.
For systems not falling into one of the above categories,
EEIs may be forwarded to OIRM/SIRMOs for information and review as
they are developed.
1-7
-------
EPA System Design & Development
Guidance: Volume B
Automated systems involving information security will be
subject to one additional documentation requirement -- completion
of a certification form (certification of sensitive systems is an
OMB requirement). The form, which is under development and will
be issued as part of the forthcoming EPA Information Security
Manual, will capture basic information on system sensitivity,
security requirements, security design, reviews, test scenarios,
results and safeguards. Information needed to complete the form
will be readily available in the EEI documentation. Prior to the
system being placed into use or production, the cognizant SIRMO
(or other senior official in the AA/RA's office) will need to
certify that the automated system is adequately safeguarded based
on the information in the form.
It is not OIRM's intent to burden EPA managers with a host of
documentation requirements for each system development effort.
The EEIs simply stress typical documentation requirements and
their outlines highlight major topics that need to be considered
for any system development effort. Managers may use their
professional judgment in substituting, combining, or down-scaling
the content of the EEIs to meet the unique requirements of their
project. Additionally, the EEIs set out in this volume are not
meant to conflict with or add more burden to documentation
requirements set out in other manuals (e.g., EPA/NCC ADABAS
Application Development Procedures Manual). Documentation
produced according to such other procedures will invariably
satisfy, either partially or fully, some EEI requirements.
Criteria for determining the minimum EEI documentation for a
specific system during the design, development and implementation
phase is based on the nature and scope of the information system
and its importance to EPA's mission. Four types of systems with
differing levels of EEI documentation requirements are identified
as follows:
Major Agency Information System; An information system
that requires special continuing management attention
because of its importance to an Agency mission; its high
development, operating, or maintenance costs or its
significant impact on administration of Agency programs.
Widely Accessed Information System: An information system
that is not a Major Agency Information System (although it
significantly supports accepted program goals and missions)
but is widely accessed by a combination of EPA
Headquarters, Regional Offices and/or State and local users
and other Federal agencies.
. Localized Information System: An information system that
is not a Major Agency Information System but significantly
supports accepted program goals and missions and is
1-8
-------
EPA System Design & Development
Guidance: Volume B
accessed primarily by users in one major area, e.g., EPA
Headquarters, a single Agency program, or a Region.
• User Owned Information Svstem: Unique, stand-alone system
developed to improve the efficiency or effectiveness of
operations for a single user or a small group of users.
Documentation requirements for each of these system categories are
projected in Exhibit 1-3 on the next page and in Chapter 4 of
Volume C. Policies and procedures covering the submission, review
and approval of EEIs by OIRM will be issued under separate
guidance.
1.6 ASSISTANCE AND SUPPORT AVAILABLE
Agency Program and Management officials embarking on a system
development effort should be aware that there are at least two
sources available to them for assistance and support during the
system development life cycle:
. Within each AA/RA's office SIRMOs are available for
assistance, support and guidance relative to the EPA
Systems Design and Development Guidance and other OIRM
guidance and standards (e.g., Core Systems, Structured
Programming, etc.)
. OIRM, with its general IRM management oversight role and
requirement to exercise procurement approval authority, has
a staff organized to support EPA's administrative, program
and research communities.
It is appropriate to involve these support sources as early as is
feasible in the system development life cycle for most system
development efforts.
The primary reasons for early involvement 'of SIRMOs and OIRM
staff are:
. Fulfilling EPA's IRM policy for system development review
requirements
. Providing a value-added service role involving
consultation, assistance, technical standards, guidance and
interpretation of requirements
. Expediting procurement for system development efforts which
proceed to the system design, development and
implementation phase
. Providing assistance in determining user needs as early as
possible in the life cycle.
1-9
-------
EPA System Design & Development
Guidance: Volume B
DC
LU
LJJ
CC
o
o
LU
O
LU
EXHIBIT 1-3
EEI-13
System Integration
Test Report
EEI-12
Software User's
Reference Guide
EEI-11
Software Operations
Document
EEI-10
Software Maintenance
Document
EEI-9
Software Detailed
Design Document
EEI-8
Software Preliminary
Design Document
EEI-7
Software Test
and Acceptance Plan
EEI-6
Software
Management Plan
EEI-5
System Detailed
Requirements Document
EEI-4
System
Implementation Plan
EH-3
Project Management
Plan
EO-2
Preliminary Design
and Options Analysis
EEI-1
Mission Needs
Analysis
1 /
'B /
S S" / .
CU IX / c ^
/ 1 §>
©
o
©
©
©
o
0
©
•
©
©
•
©
Systems That
Require OIRM
Involvement l
®
©
0
0
©
©
©
©
©
0
0
©
Major Agency
Information
Systems
0
©
0
©
©
©
Q
O
©
0
©
©
Widely Accessed
Information
Systems
©
©
©
©
•
©
0
©
©
Localized
Information
Systems
©
®
©
©
®
User Owned
Information
Systems
1 As detailed on page 1-7
1-10
-------
EPA System Design & Development
Guidance: Volume B
Achieving these objectives will strengthen EPA's system
development efforts and avoid major pitfalls that have beset
system development efforts in other government agencies (e.g.,
project stalls due to outyear funding shortages stemming from
under-projected planning or project disruptions due to failure to
get hardware/software acquisitions into the procurement cycle
expeditiously and when required).
The remainder of Volume B provides guidance for conducting
the second phase of the system development process — the
Preliminary Design and Options Analysis phase.
1-11
-------
EPA System Design and Development
Guidance: Volume B
2. PRELIMINARY OPTIONS DESIGN
Completion of the Mission Needs Analysis phase of the system
development process will have resulted in development of an
Initial System Concept (operational concept) meeting the
identified management and functional requirements of the
organization. The purpose of Volume B is to translate these
requirements into operational specifications, to identify and
develop feasible options meeting the requirements and to analyze
the overall feasibility and cost-effectiveness of the various
options. This chapter presents the methodologies for:
Translation of the management and functional requirements
identified during the Mis.sion Needs Analysis into
operational specifications
. Identifying and developing procedural and system options
satisfying the defined management and functional
requirements and operational specifications.
It should be noted that requirements refinement and system
option definition is an iterative process in that management and
functional requirements are first translated into operational
specifications. System options are then developed to satisfy
(insofar as possible) the management requirements and then the
operational specifications are refined. The result of this
iterative analytic process is a set of two to four feasible design
options, which to varying degrees may meet the basic defined
management and functional requirements identified in the Mission
Needs Analysis.
2.1 TRANSLATING MANAGEMENT AND FUNCTIONAL REQUIREMENTS INTO
OPERATIONAL SPECIFICATIONS
The Mission Needs Analysis of Volume A broadly defines the
system management and functional requirements and results in
development of the macro-level Initial System Concept. The
purpose of this stage is to further examine and define the current
system environment and user needs, then to translate these needs
into a specific set of operational specifications. The result of
this step is a set of operational specifications which provide a
basis for structuring combined automated/manual options meeting
the management and functional requirements defined in Volume A.
The objective is to develop the operational specifications only in
sufficient detail to allow defining of options for a proposed
system, but not to complete a detailed system requirements
analysis. The operational specifications form the baseline for
what a proposed system must do. The detailed system requirement
analysis is conducted in Phase III (only if an automated system
solution is selected) and is discussed in Volume C.
2-1
-------
EPA System Design and Development
Guidance: Volume B
The operational specification process focuses first on
defining and providing details about specific operational
parameters which are retired to meet the management requirement.
These include:
2.1.1 System Inputs
. Origin/type of input (indirect data entry from forms,
interface with other automated systems, etc.)
. Frequency/rate of input (hourly, daily, weekly, monthly,
etc.)
. Volume of data/text
2.1.2 System Functions/Processes
. Process and flow of each input into the "system"
. Data processing/manipulation/tabulation functions
. Types and sizes of major data files
. Update/purging requirements
. Statistical or scientific analysis requirements
Special functions such as project management/critical path,
etc.
2.1.3 System Outputs
. Hard copy report formats
. Screen display
Special presentations/graphics
. Frequency (daily, weekly, monthly, on demand) and ongoing
output rate
. Other system interfaces
. View locally and/or transmit to remote locations
2.1.4 General System Requirements
. Required system/user interface
Information security requirements, including:
- Accuracy and validity requirements
- Criticality of key outputs
- Failure contingency
- Access controls
- Response time
- Flexibility
2-2
-------
EPA System Design and Development
Guidance: Volume B
- Failure contingency
In general, these specific operational specifications involve
an elaboration and quantification of the Initial System Concept
developed during the Mission Needs Analysis. All operational
specifications should be designed to meet the management and
functional requirements identified in the Mission Needs Analysis.
Concentration at this point of the study should be on creating a
detailed picture of the way in which inputs/processes/outputs are
generated and used. Detailed formats and information field
structuring will be established in the System Design stage
described in Volume C.
2.2 DEVELOPING FEASIBLE SYSTEM OPTIONS
The operational specifications defined above provide the
foundation for structuring two to four feasible system options
which largely (but probably not exactly) meet the management and
functional requirements. In general, there are almost always a
number of potential options for meeting the management and
functional requirements varying from manual processes through
sophisticated automated system designs. It is generally true
that, if only one way to solve a problem is apparent, the
management problem has not been adequately defined and analyzed.
Options should include feasible approaches to solving the
management problem and should not be limited to alternatives
involving automation (see FIRMR 201-30.009, "Analysis of
Alternatives for Satisfying a Requirement.")
Structuring and developing possible options to satisfy the
mission need (management requirement) and operational
specifications is a process which involves several activities
performed simultaneously and iteratively. They include:
. Determining the flexibility and relative priority of each
of the operational specifications
. Reviewing the range of available hardware and software
options available to meet the specifications
. Constructing alternatives by structuring/adjusting the
operational specifications and related procedures to meet
available hardware and software options
. Option refinement through balancing'overall management
requirements with development costs and timing
considerations.
These four steps are pursued iteratively to first structure
and then specify in some detail the system options.
2-3
-------
EPA System Design and Development
Guidance: Volume B
2.2.1 Determining the Flexibility and Relative Priority of Each
of the Operational Specifications
At this stage, the operational specifications identified
earlier are treated as somewhat flexible and not a rigid set of
specifications that every systematic solution must meet. Instead,
the management and functional requirements should be considered as
the overall goal but determinations must be made regarding the
relative priority of various requirements and specifications. To
assist the system developer with this process, a flexibility/
priority analysis of each of the requirements and specifications
should be performed in order to define the ranges of associated
parameters. This analysis represents just another step in the
iterative process of structuring system options. The
flexibility/priority analysis is conducted based upon the overall
management and functional requirements and the operational
specifications defined in Section 2.1. Exhibit 2-1 provides an
example of an analysis of the flexibility of inputs/outputs for a
grants payment process. The analysis provides a "flexibility
assessment" on key components of the requirements and operational
specifications developed earlier. Conducting this analysis
provides the system developers with a sense of the way in which
the requirements and specifications must be satisfied including
which things are mandatory, and which are desirable. The results
of this "feel" of relative priorities is used both for the
development of options and for the options selection process.
2.2.2 Reviewing the Range of Hardware and Software Potentially
Available to Satisfy f.he Initial System Concept
And Functional Requirements) and Operational Specifications
During this step of the system development process, a
preliminary review of the hardware and software potentially
available for the application should be conducted. The past
several years have seen a major expansion in the range of hardware
and software available to potential users. Thus, this step of the
system development process has become more critical as the range
of options has increased. In conducting this review it is
strongly urged that EPA's Office of Information Resources
Management and/or the Senior Information Resource Management
Officer (SIRMO) for the program area be contacted for assistance.
The range of hardware and software currently available in EPA
is briefly summarized in Exhibit 2-2. This, list provides an
initial basis for determining available options within the
Agency environment. In addition, however, the system developer,
in conjunction with OIRM or SIRMO staff, might want to review and
consider other kinds of specialized hardware/software for
particular systems.
2-4
-------
EPA System Design and Development
Guidance: Volume B
EXHIBIT 2-1
TYPICAL FUNCTIONAL REQUIREMENTS ANALYSIS WORKSHEET,
INPUT/OUTPUT FLEXIBILITY OF GRANTS PAYMENT PROCESS
COMPONENT
COMMENTS ON FLEXIBILITY
INPUT
4
5
Grant authorization form 1.
Invoice
Form must have entries in all
blocks conforming to pre-
defined ranges with 100% edit
check.
Must have date, amount,
grantee name, address, and
grant authorization number and
must be 100% edited and
verified.
PROCESS/FUNCTION
Ledger
Check Printing
Must be accurate, be backed
up, and all incoming
transactions must have been
100% edited and verified
Must be accurate, be backed
up, provide for safeguards and
anti-counterfeit procedures,
and allow 100% edit and
verification.
OUTPUT
Funding check for each 1.
program operation
Updated ledger 2.
Management Report A 3.
Management Report B 4.
Queries via on-line 5.
access
Checks issued must be 100%
accurate and delivered to
grantees by 15th of each month
Must be 100% accurate and be
completed by 13th of month so
that checks can be run by 15th
User would like by 15th but
indicates not a big problem if
slips as late as 25th of month
Nice to have but not essential
Nice to have but on-line not
essential
2-5
-------
EPA System Design and Development
Guidance: Volume B
EXHIBIT 2-2
EPA - Agency Standard Hardware/Software
TOOLS
3rd Generation:
COBOL
FORTRAN
PL/1
PASCAL
4th Generation:
INFO
FOCUS
NATURAL
SAS
dBASE III Plus
Easytrieve Plus
Data Base Management
ADABAS
Graphics Facilities
TELL-A-GRAPH/ Cuechart
VERSAGRAPH
SASGRAPH
Spreadsheet
LOTUS 1-2-3
20/20
MEGACALC
SAS/FSP
Geo-graphlcs
ARC/INFO (Pilot)
UNIRAS (Pilot)
TARGET HARDWARE ENVIRONMENT
IBM 3090
IBM 43XX DEC/VAX
PRIME IBM/PC
• »
0
O ft
0 «
ft
:
• • • :
• • • •
• :
• • • •
I • <
• i i i
'
o i ; i
9
•
•
0
0 9
0
0
0
0
* ~ ~ -
• i • {
« i
2-6
-------
EPA System Design and Development
Guidance: Volume B
EXHIBIT 2-2 (Continued)
EPA- Agency Standard Hardware/Software
TOOLS
Word and Text Software
LEXJTRON WP DEVICE
LEXrTYPE
WORDSTAR
MULTI-MATE
WORD PERFECT
WORDMARC
Displaywrile 4
BASIS
TEXTWP
INFO-TEXT
Project Management
Tell-A-Plan
Microsoft Project
Telecom Capabilities
SNA
ASYNCH ASCII
HASP
X25
PRIMENET
DECNET
CROSSTALK
KERMfT
GNETII
PRIMELINK
NATURAL/CONNECTION
SAS/RBnk Rterm
3270 PC File Transfer
Electronic Mall
DIALCOM SERVICE
Local Capability
Programmmer Productivity
Aids/Facilities
ISPF
LIBRARIAN
EMACS
COBOL DEBUGGER
Fortran/ DEBUGGER
EVE/TPU
TARGET HARDWARE ENVIRONMENT 1
IBM 3090
IBM 43XX DEC/VAX PRIME IBM/PC |
«
• :;
• ;
• i
. * 1
"""•" i
9 ! i i
i \ i •
•
«
•
«
•
«
•
• • • j.
• • i
• • •;
•
}
• • i
• I
• •" • i
• 1
• • 1
• ^
• ;s
• • 1 • I
j
i ' ^
• i • |
1
• ; • |
• i
1
« 3
• ; •
2-7
-------
EPA System Design and Development
Guidance: Volume B
In reviewing the available hardware/software, the system
developer should consider such factors as the following:
. What specific hardware is available or can be made
available in physical proximity to the user(s)? What is its
accessibility?
. What similar software or data bases already exist, either
within EPA or elsewhere, which perform similar functions or
contain similar data? For example, EPA's personnel and
payroll systems already contain much personnel data, and
the Agency's Financial Management System (FMS) contains
comprehensive (and accessible) financial files.
. Is the application/system concept one for which software
has already been developed and is available either within
EPA or through service bureaus? For example, LEXIS/NEXIS,
a commercially available software package, provides a means
for storage and retrieval of abstracted data bases.
. Has EPA already developed "Core System" applications which
can be readily modified? (Consult OIRM/SIRMOs for
currently available Core Systems and Standards.)
. How complex are the basic functions which must or could be
performed by the automated system, and what software exists
to perform these functions (e.g., numerous project
management software packages exist which include critical
path analysis, as do statistical packages to perform
regression analysis etc.)?
. What is the desirable form of the output (hard copy tables,
text, graphs and charts, screen display, color graphics
etc.), and what hardware/software is available or can be
procured to produce this output?
. How long will the hardware/software be available within EPA
and when will it be replaced?
. What security arrangements are available for given hardware
or software, and are they adequate for the application?
The review of available hardware/software needs to include
examination of all of these areas.
Beyond the availability of specific hardware and software
applications, option designers should examine the potential
hardware and software based upon defined size and flexibility
requirements identified in the management and functional
requirements and operational specifications analyses.
2-8
-------
EPA System Design and Development
Guidance: Volume B
Exhibits 2-3, 2-4 and 2-5, following this page, present guidelines
for the type of software required for an application of a given
size and complexity.
Based upon the above reviews, the option designer should have
a relatively good feel for the potentially feasible hardware and
software options available to meet some or all of the management,
functional and operational specifications.
2.2.3 Developing Options by Structuring and Adjusting the
Operational Specifications and Varying Manual/Automated
Functions
In this step the analyses conducted to date are used to
construct manual/automated system options.
In constructing system options, a number of factors must be
considered simultaneously. Some of these factors include the
following:
Specific functions which are candidates for automation.
All automated systems have a manual component, and the only
question is what portion of the process or function will be
automated and what will be left as manual processing.
Often the feasible alternatives differ in the proportions
of the processes and functions that are to be automated.
The amount of effort (and hence cost) of automating certain
functions. For example, full text automation involving
voluminous files is usually not a desirable option because
of the almost prohibitive effort and cost associated with
inputting large amounts of data or text.
. User sophistication and discipline. Automated systems, but
particularly sophisticated systems, require considerable
effort and discipline to maintain accurate data. If these
are not present in the user organization, then a manual or
simple system is more highly preferred to a more
sophisticated design, and thus the options analysis should
include at least one "unsophisticated" option.
. Timing of the management requirement. If a system must be
in place quickly, a manual or less sophisticated design
will probably be required.
. Availability of the appropriate hardware/software at the
time of implementation. Procurement of new hardware or
software may take prohibitively long, and/or existing
hardware or software may be replaced while the system is
being designed.
2-9
-------
EPA System Design and Development
Guidance: Volume B
EXHIBIT 2-3
SOFTWARE SUPPORT TOOL SELECTION MATRIX
SMALL SYSTEMS
SMALL SYSTEMS - # RECORDS < 10K OR TOTAL SIZE < 10 MEGABYTES
Number of Simultaneous Users
Complex Random Retrievals?
Location
of Related
Data
None
Main-
Frame
Mini-
Computer
PC
1
YES
2,3,6.7
2.3
6
7.8,9
NO
2,3,4.6,7
2.3,4
S
7,8,9
1 X'
>15
YES
'
2
2
2
MJMfX-&*'f&»-M*
NO
2,3,4
2.3.4
2,3.4
2,3,4 [
v^MM-XKMMOW-Xw^
NOTES:
1 - Mainframe
2 - Mainframe
3 - Mainframe
4 - Mainframe
3GL/DBMS (COBOL, PM. FORTRAN)
4GL/OBMS (Natural/ADABAS)
4GL (FOCUS)
4GL (Natural/VSAM)
5 - Minicomputer 3GL
6 - Minicomputer 4GL
(COBOL. FORTRAN. Pascal)
(FOCUS, INFO)
7 - Microcomputer 4GL (INFO, FOCUS. dBASE III)
8 - Microcomputer 4GL/08MS (dBASE III)
9 - Microcomputer 3GL (FORTRAN. Pascal)
2-10
-------
EPA System Design and Development
Guidance: Volume B
EXHIBIT 2-4
SOFTWARE SUPPORT TOOL SELECTION MATRIX
MEDIUM SYSTEMS
MEDIUM SYSTEMS -1 OK < t RECORDS < 100K OR 10 MEGABYTES « TOTAL SIZE < 100 MEGABYTES j
Volatility
Number of
Simultaneous Users
Complex Random
Retrievals?
Location
of Related
Data
None
Mini-
Computer
Main-
Frame
Moderate Amount
of Change per Day
...
YES NO
2.3.6 2.3.
4.6
6 6
2.3 2,3,4
<*^.-t^^*^^~^r<.m,~^.<.,m^.^,,^<.^x«<^»a,.
...
YES NO
2 2.4
2 2.4
2 2.4
Volatile
S15 >15
YES NO YES NO
Highly '•.
Volatile
S15 >15
YES
2.6 2.3. 2,3 2.4 I 1.2.
4,6 I 5.6
i
5.6 5.6 2,3 2.4 5.6
2 2.3.4 2.3 2.4 1.2
NO YES NO !
1.2, 1.2, 1,2
5,6 5,6 :
5,6 1.2 1,2
1.2 1,2 1.2 !
wo^-^vs*i<^^«^«<^y;^v«.xi~a™o^^^
NOTES:
1 - Mainframe
2 - Mainframe
3 - Mainframe
4 - Mainframe
5 - Minicomputer
6 - Minicomputer
3GL/DBMS (COBOL PL/I. FORTRAN)
4GL/DBMS (Natural/ADABAS)
4GL (FOCUS)
4GL (Natural/VSAM)
3GL (COBOL FORTRAN, Pascal)
4GL (FOCUS, INFO)
2-11
-------
EPA System Design and Development
Guidance: Volume B
EXHIBIT 2-5
SOFTWARE SUPPORT TOOL SELECTION MATRIX
LARGE SYSTEMS
LARGE SYSTEMS - » RECORDS
Volatility
Number of
Simultaneous Users
Complex Random
Retrievals?
File
Pass
Frequency
n- 1
per day
1 40
per day
> 100K OR TOTAL SIZE
Almost Static
(Update Weekly or Less)
•
YES
2.3
2
Hybrid
1.2
5
NO
2.3,4
2.4
4
>'
YES
2
2
Hybrid
1.2
5
NO
2.4
2.4
4
> 100 MEGABYTES
Moderate Amount of
Change or Volatile
$15
YES
2
2
Hybrid
1.2
.»
NO
2,4
2.4
4
Highly
Volatile
...
YES
1,2
1,2
Hybrid
1.2
„•
NO
1.2
1.2
Hybrid
1.2
NOTES:
1 - Mainframe
2 - Mainframe
3 - Mainframe
4 - Mainframe
3GL/08MS (COBOL, PL/1. FORTRAN)
4GL/OBMS (Natural/ADABAS)
4GL (FOCUS)
4GL (Natural/VSAM)
2-12
-------
EPA System Design and Development
Guidance: Volume B
Based upon these and other considerations, a set of system
options for performing the defined functions should be structured.
In general, these options should range from manual processes or
procedures, through the most highly automated alternative which is
potentially feasible.
In displaying the options, it is highly desirable — in fact
virtually mandatory — that all the manual and automated functions
associated with the option be defined and displayed. In fact
these manual/automated differences along with the
hardware/software differences are the primary factors which
differentiate the options and which will form the basis for the
benefit-cost analysis and subsequent option selection.
A recommended analytical technique for defining and
specifying the manual/automated alternatives and differences by
alternative, is to rely upon the flow charts and the Initial
System Concept developed during the Mission Needs Analysis.
Beginning with these flow charts (see Exhibits 2-1 and 2-2 of
Volume A), updated system concepts can be constructed for each
alternative identifying:
The specific manual functions which must be performed
. The specifi-c system functions which must be performed
Changes from the current mode of operation.
This clear specification of which functions are to-be performed
manually and which are to be automated is critical to the
development of benefit and cost estimates for each option.
As a final step of this analysis, the defined options should
be reviewed with the users to determine their acceptability. This
review should include a discussion of the advantages/disadvantages
as well as the operational implications (additional staff, new
procedures, information security factors, etc.) of each option.
The result of this last review with the users is a potential set
of options which appear to satisfy to an acceptable degree the
management requirements and mission need.
2-13
-------
EPA System Design and Development
Guidance: Volume B
3. OPTIONS ANALYSTS
Selecting an appropriate solution to satisfy the mission need
and operational specifications involves evaluating identified
options against the identified requirements to determine which
alternative most cost-effectively satisfies the requirements.
Thus, two analyses must be conducted:
. Operational and technical feasibility analysis
. Life cycle benefit-cost analysis.
Guidance for performing these analyses is provided below.
3.1 OPERATIONAL AND TECHNICAL FEASIBILITY ANALYSIS
For an option to be viable it should be technically,
operationally, and economically feasible. The purpose of the
operational and technical feasibility analysis is not only to
evaluate how well each option meets the requirements identified to
date but also to determine how operationally and technically
feasible each option is. The primary result of this task is a
ranking of the various options in accordance with their capacity
to meet the requirements.
Exhibit 3-1, following this page, presents an example of the
parameters and a matrix format for conducting an operational and
technical feasibility analysis.
Completion of a matrix such as the one shown in Exhibit 3-1
should indicate the extent to which each option is operationally
and technically feasible. The matrix can be used, if desired, as
a means of ranking options by desirability. This can be done
either informally through a joint review of the information by
management, users and the system developers, or formally through
the development of specific weights to be applied to each criteria
and the "scoring" of each option. The total score then becomes
the relative desirability of the option.
The results of this analysis will indicate the relative
desirability and effectiveness of each option. Before a final
determination of an option can be made, however, a life cycle
benefit-cost analysis must be conducted.
3.2 LIFE CYCLE BENEFIT-COST ANALYSIS
To ensure that the most cost-effective option is selected,
the benefits and costs of each option over the anticipated life of
the system must be carefully reviewed. The benefit-cost analysis
3-1
-------
EPA System Design and Development
Guidance: Volume B
EXHIBIT 3-1
OPERATIONAL AND TECHNICAL
FEASIBILITY ANALYSIS
OPERATIONAL/TECHNICAL AREA
1 . CAPABILITY OF PRODUCING KEY
PRODUCTS (MEET MANAGEMENT
REQUIREMENT)
• 'A'
. -C-
2. DEVELOPMENTAL TIME COMPARED
TO NEED
3. FLEXIBILITY/EXPANDABILITY
4. ACCEPTABILITY TO MANAGEMENT
AND USERS
5. EXTENSIVENESS OF MANAGEMENT/
OPERATIONAL CHANGES REQUIRED (IF ANY)
6. RESOURCE AVAILABILITY
(STAFF AND DOLLARS)
7. MANAGEMENT COMMITMENT
8. RISKS OF DEVELOPMENT/
IMPLEMENTATION (Security, etc.)
• Management Risks
• System Hardware/Software Risks
• Security Risks
9. AVAILABILITY/ACCESSIBILITY OF
HARDWARE AND SOFTWARE
10. AUTOMATED SYSTEM CHARACTERISTICS
Capability to Interface with
Other Systems
• User-friendly Interface
• Failure and Backup Provisions
Hardware/Software Obsolescence
Site/Physical Plant Requirements
SCORE
DEGREE EACH OPTION MEETS
REQUIREMENT
OPTION 1
OPTION B
OPTION UI
3-2
-------
EPA System Design and Development
Guidance: Volume B
is a methodology for conducting this analysis. The objective of
the analysis is to identify and compare the benefits and costs of
feasible options to provide a sound basis for selecting the
preferred alternative.
The benefit-cost methodology consists of three tasks:
. Determining and valuing benefits
. Determining and valuing costs
. Comparing total benefits and costs.
The result of the benefit-cost-analysis is the determination of
the most cost-effective option. Detailed guidelines for
completing the benefit-cost analysis are presented below.
3.2.1 Determining and Valuing Benefits
The purpose of this task is to identify and value the
potential benefits of each system option. Benefits usually are
expressed in terms of the mission, goals or operating program
accomplishments over the expected system operational life-span.
These benefits must be identified for each year of system
operation. In general, benefits- are those accruing when compared
to the current situation including a projection of the "base"
situation to the future.
Generally, there are three types of potential benefits from
automated systems:
Cost reduction benefits which are a direct result of an
automated process being more efficient than a manual
process. In general these benefits accrue only when a
system is an operational system producing a product, such
as payment checks, mailing lists, etc. The methodology for
valuing these benefits is a relatively straightforward
efficiency analysis.
Additional capability benefits such as conducting
statistical (regression) analyses which cannot be dene
manually because of the immense number of calculations
required. It is often difficult to quantify these
benefits.
Management effectiveness benefits which result from
improved management due to improved information from
management information systems. In general, it is
impossible to directly measure these benefits
quantitatively since they stem from the presumed actions of
managers who will make better and more informed decisions.
The approximate magnitude of these benefits may, however,
be inferred by estimating the total cost of the
3-3
-------
EPA System Design and Development
Guidance: Volume B
organization being managed and presuming a small increase
(2%-10%) in organizational effectiveness or efficiency.
For example, if a 1,000 person organization is expending
$50 million/year, then a 2% increase in management
effectiveness translates into an inferred benefit of $1
million (.02 x $50 million).
Every reasonable effort should be made to identify and
quantify benefits in units and dollars with supporting rationale.
When benefits cannot be quantified in dollars, they should be
expressed in measurable units. Non-quantifiable benefits may be
identified if pertinent to the decision. The discussion below
presents categories of benefits which may result from a system
project.
3.2.1.1 Non-recurring Cost-Reduction Benefits
These are one-time benefits that have a dollar value. The
benefits may occur at any point in the life cycle, but they are
not continuing benefits.
1) Cost reduction - The value of eliminating owned
equipment, excess equipment and inventory, or any other
one-time source of quantifiable benefit.
2) Value enhancement - The value of additional tangible
procurements (depreciable, not consumable) and
improvements to owned facilities and equipment.
3.2.1.2 Recurring Cost-Reduction Benefits
This includes benefits accrued throughout, or during most of,
the system life cycle. These cost-reduction benefits should be
quantifiable and may include such categories as:
1) Maintenance and Lease of ADP Equipment - The savings for
ongoing lease and/or maintenance contracts for ADP
equipment.
2) Communications - The savings on rental, lease or
maintenance of data communication equipment, services,
and facilities.
3) Software Maintenance - The projected savings on the
maintenance of application software.
4) Personnel - The salaries and fringe benefits saved (net
savings) for operations, data entry, and other personnel.
5) Training and Travel - Savings due to reduced training and
travel.
3-4
-------
EPA System Design and Development
Guidance: Volume B
6) Space Occupancy - Savings on equipment space, personnel
and support facilities, and administrative offices.
7) Supplies and utilities - Reduction of both technical and
administrative supplies.
8) Security - Savings on security guards, devices, etc.
3.2.1.3 Qualitative Benefits
Many important benefits can result from a system without
being able to easily quantify them. Examples include:
. Faster processing and/or lower error rate
. Enhanced organizational image
Improved morale
. Standardization
It may not be possible to precisely quantify these benefits in
dollar terms, but they nevertheless should be examined and
retained as part of the analysis.
3.2.1.4 Determining Total Benefits
Total benefits are determined by summing annual tangible
benefits over the life of the system and adding non-recurring
benefits. To determine present value benefits, adjust the
benefits over the system life cycle to their present value. The
net present value is calculated by subtracting the adjusted cost
from the total present value of benefits. FIPS PUB 64 and OMB
Circular A-94 provide guidance for calculating the present value
of benefits.
3.2.2 Determining and Valuing Costs
The purpose of this task is to determine for each system
option all costs and required resources, e.g., personnel,
equipment, etc. Costs must be analyzed for each alternative over
its life cycle.
The system life cycle includes both the research and
developmental, and operational and maintenance phases of the
system's life. For example, the costs for conducting the system
development process discussed in Volume C must be included in the
system life cycle costs. The end of the system life cycle is the
projected final year in the useful life of the system, or the last
year in which either costs or benefits are incurred.
3-5
-------
EPA System Design and Development
Guidance: Volume B
Only relevant costs must be addressed in the economic
analysis. A cost is relevant if the implementation of an
alternative would cause currently occurring costs to change. For
example, site costs are relevant if the current facilities must be
modified or expanded to accommodate the system. Costs which are
not impacted by any alternative are the same for all alternatives
and, therefore, they are irrelevant to the economic analysis.
Sunk costs are not relevant to the economic analysis. Sunk
costs are costs which have already been incurred or are
irrevocable due to a prior commitment. Sunk costs are irrelevant
to the economic analysis because they will be incurred at the same
level regardless of the outcome of the analysis.
Relevant non-informational system costs must be included in
the analysis. For example, if workload increases would require
future increases to non-information system staff to perform a
program mission, goal or operating function, the additional costs
must be shown as increased costs of the present system.
Cost estimates must be supported by a reasonably accurate
projection of workload and capacity requirements. Specific
workload data and associated capacity requirements for each year
in the system life must be provided.
The effects of inflation, or anticipated changes in the
general price level, are not required in the analysis of costs.
If inflation is used in the analysis, the resulting costs must be
presented in both present (constant) and future (discounted)
dollars.
Although inflation, or an unanticipated increase in the
general price level, is not required for the analysis, a known or
expected price increase in a specific cost item should be included
when the magnitude of the price change may affect the decision
(for example: an increase in personnel costs projected due to a
planned general Federal pay raise). Note that costs for all years
of the system life must be presented in both present and future
dollars.
Developmental (non-recurring) and operational (recurring)
costs must be separately identified. Developmental costs are one-
time costs to acquire hardware, software, telecommunications,
facilities, capitalized equipment, training and travel.
Operational costs may be incurred over the life of the system and
include maintenance, facilities, non-capitalized equipment,
supplies, training and travel. Specific types of costs which
should be considered in the analysis are identified below.
3-6
-------
EPA System Design and Development
Guidance: Volume B
3.2.2.1 Non-recurrina Costs
Non-recurring costs are costs associated with the acquisition
of equipment, real property, non-recurring services, non-recurring
operations and maintenance (start-up) costs, and other one-time
costs. Non-recurring costs need not all occur in a single year.
They include costs for:
1) Site Modifications - The cost of erecting or modifying a
site and surrounding facilities to meet the needs of the
proposed system, e.g., costs to enlarge a computer room
and additional space required for personnel involved in
this process, etc.
2} ADP Equipment - The cost for hardware, e.g., CPUs, disk
drives, security devices, etc.
3) Data Communications - The cost for data communications
hardware, communication lines and dedicated data
communications software.
4) Software purchase - The cost for system software packages
procured for the direct support of the proposed system.
5) Database development - The cost of implementing database
system software and database applications software.
6) Software development - The cost of implementing
application programs.
7) Studies - The cost of studies associated with the
requirements, design development, or implementation of
the proposed system.
8) Data Conversion - The cost of converting present data and
program logic.
9) Prorurornoni- - The cost of procuring hardware, software
and data communications such as RF? preparation, vendor
evaluation, and contract preparation.
10) Training - The cost of training, including user,
operations, and management training.
11) System Test - The cost of evaluating the system, «
including tests of information security safeguards.
12) Management Overhead - The cost of management interface in
the development process defined in terms of hours
required for meetings, reviews and administrative
3-7
-------
EPA System Design and Development
Guidance: Volume B
functions associated with continued system operation,
etc.
3.2.2.2 Recurring Costs
Recurring (operations) costs are costs of operating the
system on an annual basis that continue throughout the system
life. They include costs for:
1) Personnel - The salaries and fringe benefits for
operations, data entry, and other personnel assigned to
the system. Part-time activities should be prorated
accordingly.
2) Maintenance and Lease of ADP Equipment - The cost for
lease and/or maintenance contracts for ADP equipment.
3) Space Occupancy - The cost of equipment space, personnel
and administrative offices.
4) Supplies and Utilities - The cost of both technical and
administrative supplies.
5) Timesharing - The cost of buying computer time from a
commercial source.
6) Communications - The cost for the rental, lease or
maintenance of data communications equipment, services
and facilities.
7) Software Maintenance - The cost of maintaining
application software.
8) Training - The cost of training and travel for new
employees and upgrades.
9) Security - The cost of security guards, security devices,
etc.
3.2.2.3 Qualitative Costs
Costs may or may not be measured in quantitative terms.
Although the primary emphasis of the benefit-cost analysis is to
evaluate measurable impacts, the overall objective is to clarify
all of the important effects of any decision. Since this is the
case, the identification and consideration of qualitative or
intangible effects which usually defy accurate calculation
nevertheless play a part in the analysis. Some qualitative costs
include, but are not limited to:
3-8
-------
EPA System Design and Development
Guidance: Volume B
. Operational disruptions
. Reduced employee morale
. Degraded organizational image
3.2.2.4 Determining Total Costs
To calculate total costs, the total non-recurring and
recurring cost subtotals for each year of the system life are
added together. The total annual cost can be converted to present
value cost for each year of the system life. The present value
will give a more equitable base when alternatives have a wide
dispersion in the funding years. A percentage rate must be
applied to each year's cost to calculate the present value and
aggregate the total system cost. FIPS PUB 64 and OMB Circular A-
94 (revised March 27, 1982) provide more detailed guidance for
calculating present value costs. The total cost over the system
life is derived by summing the total costs for all years of the
system life.
3.2.3 Benefit-Cost Comparison
The final step of the benefit-cost analysis is the summation
of all benefits and costs, selection of the benefit-cost measure,
and arrangement of the benefit-cost display.
The summation of benefits and costs is a straightforward
addition which permits total benefits to be compared to costs. If
all benefits and costs are measured in dollar terms, then one
number will be obtained for each. However, qualitative benefits
or costs frequently will be included and in these cases no single
number can be obtained and a number of measures may have to be
included in the final summation. However, just because a cost or
benefit cannot be measured in dollar terms does not mean it can be
dropped from the final summation or downrated. If it is a major
effect, it must be considered.
The actual quantitative benefit-cost comparison involves
three primary calculations:
1) Determination of the benefit-cost ratio
2) Determination of payback period
3) Determination of rate-of-return on investment
Exhibit 3-2 provides a sample format for summarizing both benefits
and costs of an option (e.g., Option "A") over the system life
cycle period. Exhibit 3-3 provides a sample format for displaying
quantitative benefits for all options evaluated in order to allow
easier comparison.
3-9
-------
EPA System Design and Development
Guidance: Volume B
EXHIBIT 3-2
SAMPLE SUMMARY OF TIME-PHASED COSTS
AND BENEFITS FOR OPTION A
CATEGORY
SYSTEM DESIGN 8, DEVELOPMENT
COSTS
ACQUIRE/MAINTAIN HARDWARE
ACQUIRE/MAINTAIN SOFTWARE
IMPACT COSTS
TRAINING
DATA ENTRY
TOTAL COSTS
CUMULATIVE COSTS
OPTION A
RSCAL YEAR
1987
1988
1989
1990
1991
1992
1993
1994
TOTAL BENEFITS
CUMULATIVE BENEFITS
NET BENEFITS
CUMULATIVE BENEFITS
3-10
-------
EPA System Design and Development
Guidance: Volume B
EXHIBIT 3-3
SAMPLE SUMMARY OF OPTION
BENEFITS AND COSTS
CATEGORY
SYSTEM DESIGN & DEVELOPMENT
ACQUIRE/MAINTAIN HARDWARE
ACQUIRE/MAINTAIN SOFTWARE
IMPACT COSTS
TRAINING
DATA ENTRY
TOTAL COSTS
TIME SAVINGS TO USERS
NET BENEFITS (BENEFITS - COSTS)
PAYBACK
(ONE-TIME COSTS/NETBENEFITS)
OPTION A
ONE-T1ME
ANNUAL
OPTION B
ONE-TIME
ANNUAL
OPTION C
ONE-TIME
ANNUAL
3-11
-------
EPA System Design and Development
Guidance: Volume B
3.2.3.1 Benefit-Cost Ratio
There are several benefit-cost measures which can be used for
comparison purposes. The benefit-cost ratio (B/C) is one measure
which gives an approximate multiple of return on the investment
costs of a project. Obviously, for a project to be economically
viable, benefits should outweigh costs so that the B/C ratio
should be greater than 1. Another measure is the
ratio of net benefits (benefits minus costs) to costs. This gives
an approximate rate of return on investment. A third measure, net
benefits (B-C) may be used if the size of benefits is important.
3.2.3.2 Payback Period
The payback period is calculated by determining the year and
month in which the sum (in current dollars) of benefits first
exceeds the sum of the costs.
3.2.4 OMB Benefit-Cost Approval Criteria
Benefit-cost submissions to OMB for external review and
approval must show at least a 10% return on investment or provide
substantial additional justification for funding based on
satisfying non-financial criteria. OMB has also indicated that
particular attention will be paid to narrative amplification of
system benefits and costs, including assumptions made, options
considered, and the use of sensitivity analysis as a hedge against
uncertainty.
3-12
-------
EPA System Design and Development
Guidance: Volume B
4.0 OPTION SELECTION AND DOCUMENTATION
When the procedural steps outlined above have been performed,
the options analysis and the life cycle benefit-cost analysis are
complete. The results of these analyses provide decision makers
with a range of valued alternatives. However, the results must be
carefully examined to ensure the accuracy of the analysis, and
other factors that may be relevant to option selection must be
considered.
4.1 OPTION SELECTION CRITERIA
The results of the operational and technical feasibility
analysis and the benefit-cost analysis support decision makers by
providing them with required information to make an informed
selection. These analyses do not make automatic the decision of
which option to select. The selection process, while guided by
these analyses, still involves a moderate amount of subjectivity.
One factor which may play an important role in any decision
is risk. With any project there is a certain element of risk
involved, risk that costs may exceed expectations, that benefits
will not materialize as expected, etc. A benefit-cost analysis
and the operational and technical feasibility analysis helps
minimize risk since they require explicit definition of expected
benefits, costs and risks. However, some risk always remains. If
there is a high possibility that benefits may not materialize from
a project, the project's benefits should be much greater than its
costs if a decision to continue is to be made. Similarly, if
costs and benefits are almost assuredly known, the project may be
viable even at a lower benefit-cost ratio or lower rate-of-return.
The risk factor should be evaluated in any decision concerning a
project.
Another element of the option selection process which must be
taken into account, especially for larger systems, is OMB's
requirements governing major system development. As previously
noted, OMB requires a 10% return on investment or substantial
additional justification if it is to approve such development
efforts. In addition, OMB requires (OMB Circular A-ll) that
budget estimates must be prepared for all "major information
system initiatives" which are defined as:
System design or development costs exceeding $1 million
System operation and maintenance costs exceeding
$500,000/year.
4-1
-------
EPA System Design and Development
Guidance: Volume B
This approval requirement can affect the timing of a system
development project and potentially even help decide which option
is selected.
Of particular importance in the final decision is the value
judgment placed upon qualitative considerations, either those
identified in the analysis or others. Frequently, the
desirability of the project will hinge on these factors. It is
the job of the decision maker to evaluate intangibles in light of
his/her knowledge of the project, the people affected by it, and
the conditions surrounding it. A final decision must be based
upon these factors as well as the results of the benefit-cost
analysis.
4.2 DOCUMENTATION REQUIREMENTS
Completion of the-analyses described in this volume should be
documented in a report outlining the analyses conducted and the
results obtained. Appendix A, EEI-2, presents a suggested outline
for this report. The report -- EEI-2, Preliminary Design and
Options Analysis — or an equivalent report, must be completed for
all system development efforts as described in Chapter 1, section
1.5. If the selected option is a manual solution, it is not
strictly necessary to complete the report shown, since
justification for a manual system is not required. Nevertheless,
it is recommended that basic elements of the documentation be
retained for future reference.
It should be remembered that the benefits-cost analysis is an
evolving document and that benefits/costs will change as the
project progresses and becomes better defined. Therefore, for
those system efforts which proceed to the design, development and
implementation phase the benefit-cost analysis will require
updating.
Additionally, at the conclusion of this phase, if the system
development effort appears to be viable and proceeding to design,
development and implementation there are certain management
actions which must be taken, including:
. Appointment of a project manager and team
. Consideration of establishment of configuration
management and quality assurance/control mechanisms
. Development of a Project Management Plan (EEI-3) .
The Project Management Plan is an extremely important
document and will set out how the system development effort will
be accomplished, especially focusing on resources and scheduling
4-2
-------
EPA System Design and Development
Guidance: Volume B
as well as other factors. Appendix A, EEI-3, provides a
representative outline for a Project Management Plan.
4-3
-------
EPA System Design & Development
Guidance: Volume B
5. SUMMARY
5.1 PRELIMINARY DESTGM AMD OPTIONS ANALYSTS
The outputs, documents and results of the Preliminary
Design and Options Analysis are:
. EEI-2, Preliminary Design and Options Analysis
. EEI-3, Updated Project Management Plan
. Detailed supporting documentation and work papers
. Summaries of available options, benefits and costs
. Operational and technical feasibility analysis
. Functional requirements analysis worksheets
5.2 NEXT STEPS
If the option analysis and subsequent Project Management Plan
indicate that an automated system should be developed, either
wholly or in part, then the next steps would be System Design,
System Development, and System Implementation as outlined in
Volume C. Otherwise, the program manager should develop the
written guidelines and procedures that outline the recommended
approach for conducting the process using non-automated methods.
5-1
-------
EPA System Design & Development
Guidance: Volume B
APPENDIX A
ESSENTIAL ELEMENTS OF INFORMATION
-------
EPA System Design and Development
Guidance: . Volume B
APPENDIX A
ESSENTIAL ELEMENTS OF INFORMATION
A. ESSENTIAL ELEMENTS OF INFORMATION
This appendix provides a representative outline of documents
that will be developed during the Preliminary Design and Options
Analysis phase.
A.I INTRODUCTION
The documentation requirements contained in this appendix
apply to all software development projects, regardless of size,
complexity or origin. At a minimum, these standards apply to all
new software development projects. Maintenance and/or
enhancements to existing information systems must comply with the
requirements set out in Chapter 1, section 1.5 of Volume B,
Preliminary Design and Options Analysis.
Compliance with the standards and conventions provided in
this appendix will ensure that adequate documentation is produced
for all system development projects.
The documents defined in this aooendix are:
EEI-2 • • Preliminary Design And Options Analysis
EEI-3 • • Project Management Plan
When an asterisk appears within a section number in the
outlines, it represents a repetition of the element as many times
as necessary to define multiple iterations of the element.
The following milestone chart illustrates the relative
initiation and completion of each document with respect to the
software development life cycle, its major phases, and the span
and scope of Volumes A, B, and C.
A-l
-------
DOCUMENTATION VERSUS LIFE CYCLE
Mission Needs Analysis
EEI-1
Preliminary Design/
Options Analysis
EEI-2
EEI-3
System Detailed
Requirements Analysis
EEI-4
EEI-5
EEI-6
Preliminary Design
EEI-7
EEI-8
Detailed Design
EEI-9
System Production
and Programming
EEI-10
EEI-11
EEI-12
System Integration
Testing & Evaluation
EEI-13
System Installation
tem Operations &
intenance
Volume A
Volume B
Volume C
System Preliminary Critical
Requirement Design ; Design DT&E OT&E
Review TV-Review--::v^i:s:.RevlewVt:S 'Review Review
U
;eptapca
O W
C *0
H->
C" C/l
3 ^<
O to
fl> ft
.. fD
3
< a
o n>
M W
C H-
3lQ
0) D
tt) fiJ
o
0)
fD
h-1
O
13
fD
-------
EPA System Design and Development
Guidance: Volume B
EEI-2 PRELIMINARY DESIGN AND OPTIONS
EXECUTIVE SUMMARY
. Background
. System Concept
. Option Summary
. Results of Options Analysis
1. INTRODUCTION
1.1 Background
1.2 Current System Description
1.3 Results of Mission Needs Analysis
1.4 Scope and Purpose
2. OPTION DESIGNS
2.1 System Concept, Management Requirements and Functional
Requirements Summary
2.2 Operational Requirements Summary (General system
requirements like security, etc.)
2.3 Option Descriptions
2.3.1 Option 1 •
2.3.2 Option 2
2.3.* Option 3 etc.
3. OPTIONS ANALYSIS
3.1 Summary of Option Life Cycle Benefits
3.2 Summary of Option Life Cycle Costs
3.3 Life Cycle Benefit-Cost Analysis
3.4 Summary of Risks and Contingencies by Option
4. OPTION RECOMMENDATION (WITH RATIONALE)
A-3
-------
EPA System Design and Development
Guidance: Volume's
EEI-3 PROJECT MANAGEMENT PLAN
EXECUTIVE SUMMARY
. Background
System Description
. Funding/scheduling
. Accomplishment Plan (including Procurement)
. Risk
1. INTRODUCTION
1.1 Background
1.2 Current System Overview
2. System Description
3. Project Team and Support
3.1 Roles and Responsibilities
3.2 Configuration Management
3.3 Quality Assurance/Control
3.4 Procurement Plan
4. Project Schedule and Task Description
5. Project Budget and Funding
6. Facilities
7. Test Plan Requirements/Constraints
8. Risk Summary/Project Constraints
8.1 Policy Events
8.2 Forms and Clearances
A-4
-------
United States
Environmental Protection
Agency
Office of Information
Resources Management
Washington DC 20460
OIRM 87-02C
10/87
EPA SYSTEM DESIGN &
DEVELOPMENT GUIDANCE:
VOLUME C:
SYSTEM DESIGN,
DEVELOPMENT
AND
IMPLEMENTATION
-------
Volume C
Executive Summary
This document defines the process and documentation that
system developers prepare during the System Design and Develop-
ment phase of the system life cycle. The objective of this doc-
ument is to provide guidance towards satisfying requirements
specified in EPA's IRM Policy Manual for the acquisition and
management of information technology.
The guidance within this document is intended to provide
system developers with specifics concerning software program
management, design and related documentation. The objective of
the Software Management Plan, outlined in this document, is to
ensure the quality of EPA software design, development, imple-
mentation and maintenance efforts. The EPA Software Management
Program is based on six software engineering elements that in-
clude policies, standard software tools, procedures/ methods,
guidelines, planning, and oversight and compliance.
Completion of the steps and documentation outlined in this
document will result in an automated system that solves a spe-
cific problem as outlined in EEI-1, the Mission Needs Statement.
Accompanying the automated system will be a sufficient quantity
of documentation that detail inputs, outputs and processes
within the system. The rationale behind all the documentation
requirements is to assure program managers and OIRM staff that
the delivered system fulfills its user's requirements, utilizes
EPA accepted standards and procedures, and is within the guid-
ance, limitations and constraints imposed on the Agency by OM3,
GSA and the Congress of the United States.
The following exhibit describes the complete software life
cycle. Each phase in the software life cycle is represented by
a bubble with its corresponding title on the inside of the cir-
cle. Factors that influence each phase are shown surrounding
each circle. The scope of this document covers three separate
phases, System Design, System Development and System Implementa-
tion. As indicated, factors that influence the System Desigr.
phase are programming language constraints, detailed user re-
quirements, data requirements, and the physical environment ar.d
the preceding bubble, the Preliminary Design and Options
Analysis. The next phase discussed in this volume, System De-
velopment, is influenced by the output from the System Design
phase and the external influences of development resources, pro-
gramming standards and development tools. The final phase de-
tailed in this document is System Implementation. As indicated,
factors that influence this phase are the outputs from the
System Development Process, and external factors such as OMB
certification, operations constraints and user acceptance of the
delivered product.
-------
Complete Software
Life Cycle
Volume A
Lack of
Maintenances^
Resources
Improved
Tools —
Radical
Changes in
/ Requirements
Volume B
Physical
/ Environment
Mission
Needs
Analysis
Software
Obsolescence
Preliminary
Desin
Options
Analysis
Hardware
Environment
\
Improved
Hardware
High Quality
Government
Owned or
Commercial
Alternative
Software?
Iroprovcmcni
Increment
System
Design
Programming
Language —
Conuaints
Detailed
User
Requirements
Enchancement
/
Development
Resources
User
Acceptance
Operations
Contrainis —f
System
Implementation
System
Development
Software
Improvement
Incremeni
Programming
Standards \
Programming
Slandards
\
System
Improvement
Plan
Requirements
Software
Design/
Implementation
Constraints
I
Software
Bugs
Volume C
Software
Engineering
Technology
OMB /
Certification
-------
EPA System Design & Development
Guidance: Volume C
TABLE OF CONTENTS
Title Pace
1. Introduction 1-1
1.1 Background 1-1
1.2 Objectives of the System Design and
Development Guidance 1-1
1.3 Authority 1-5
1.4 Applicability of the Guidance 1-5
1.5 Documentation Requirements 1-5
1.6 Assistance And Support Available 1-9
2. Software Management Program 2-1
2.1 Applicability to Small and Large
Projects 2-1
2.2 Quality Software 2-1
2.3 Software Management Program Overview 2-2
3. System Design, Development and Implementation
Overview 3-1
3.1 System Design Stage 3-1
3.1.1 System Detailed Requirements Analysis 3-1
3.1.1.1 Activities 3-3
3.1.1.2 Documentation 3-4
3.1.1.3 System Requirements Review 3-4
3.1.1.4 Functional Baseline 3-4
3.1.2 Preliminary Design 3-4
3.1.2.1 Activities 3-4
3.1.2.2 Documentation 3-6
3.1.2.3 Preliminary Design Review 3-6
3.1.2.4 Preliminary Design Baseline 3-7
3.1.3 Detailed Design 3-7
3.1.3.1 Activities 3-7
3.1.3.2 Documentation 3-8
3.1.3.3 Critical Design Review 3-9
3.1.3.4 Design Baseline 3-9
3.2 System Development Stage 3-9
3.2.1 System Production and Programming 3-9
3.2.1.1 Activities ' - 3-10
3.2.1.2 Documentation 3-11
3.2.1.3 System Production and Programming
Reviews 3-11
3.2.1.4 Development Test and Evaluation Review 3-11
3.2.1.5 Product Baseline 3-11
3.2.2 System Integration, Test and Evaluation 3-12
-------
EPA System Design & Development
Guidance: Volume C
3.2.2.1 Activities 3-12
3.2.2.2 Documentation 3-12
3.2.2.3 System Integration, Test and Evaluation
Reviews 3-13
3.2.2.4 Operational Test and Evaluation Review 3-13
3.2.2.5 Operational Baseline 3-13
3.3 System Implementation Stage 3-14
3.3.1 System Installation 3-14
3.3.1.1 Activities 3-14
3.3.1.2 Major Products 3-14
3.3.2 System Operation, Maintenance and
Evaluation 3-14
3.3.2.1 Activities 3-15
3.3.2.2 Documentation 3-15
4. Software Engineering Components . 4-1
4.1 Software Engineering Components 4-1
4.1.1 Standards 4-1
4.1.2 Procedures/Methodologies 4-1
4.1.3 Software Development Support Tools 4-2
4.1.4 Quality Assurance 4-2
4.2 Software Engineering Principles 4-2
4.2.1 Determining Documentation Retirements 4-4
4.2.2 Software Life Cycle Reviews 4-6
5. Software Development Standards 5-1
5.1 Standard Programming Languages 5-1
5.1.1 Programming Language Selection
Guidelines 5-1
5.1.2 Source Program Design and Coding
Conventions 5-4
5.2 Core System Standards 5-8
5.3 EPA Standard Specialized Software Tools 5-9
5.4 EPA - Agency Standard Hardware/Software 5-9
6. Summary 6-1
6.1 System Design, Development and
Implementation Outputs 6-1
6.2 Next Steps 6-1
Appendix A Essential Elements of Information A-l
LIST OF EXHIBITS
1-1 EPA System Development Life Cycle
and Decision Process 1-3
1-2 EPA System Development Life Cycle
Documentation 1-7
IV
-------
EPA System Design & Development
Guidance: Volume C
1-3 System Category/EEI Matrix 1-10
3-1 System Design, Development and
Implementation Life Cycle Phase 3-2
3-2 Software Maintenance Life Cycle 3-16
4-1 EEI Requirements for Major Agency and
Widely Accessed Information Systems 4-5
4-2 EEI Requirements for Localized
Information Systems 4-7
4-3 EEI Requirements for User Owned
Information Systems " 4-8
5-1 EPA Standard Application Programming
Languages 5-2
5-2 Software Support Tool Selection Matrix
Small Systems 5-5
5-3 Software Support Tool Selection Matrix
Medium Systems 5-6
5-4 Software Support Tool Selection Matrix
Large Systems 5-7
5-5 EPA Standard Specialized Software Tools 5-10
5-6 EPA Hardware/Software Environmental
Standards 5-11
-------
EPA System Design & Development
Guidance: Volume C
1. INTRODUCTION
Pursuant to the Environmental Protection Agency's IRM Policy
Manual, this volume is the third of three volumes which provide
guidance for Agency system design and development efforts. This
volume provides detailed guidance for the final phase of the EPA
system development life cycle process — the Design, Development
and Implementation phase.
Volume C is intended for use by system developers,' including
Agency staff and contractors, who are actually responsible for
system development. It therefore provides detailed guidance for
conducting automated system development activities to help insure
compatibility and uniformity EPA-wide.
1.1 BACKGROUND
The Environmental Protection Agency expends millions of
dollars each year on the design, development, implementation and
maintenance of major environmental and administrative systems
vital to EPA's programs and administrative functioning.
Management of these system resources is becoming increasingly
complex, since the rapid development of information technology in
the 1980's has dramatically increased computer capacity and user
accessibility. The result has been two-fold:
. An increasing number of system development efforts by
managers and staff at all organizational levels who,
because of access to their own equipment, develop their own
systems independently of Agency systems staff
. A wide range of hardware/software options for
implementation of any specific system concept or design.
Therefore, there has been a proliferation of system development
efforts by a broad range of users with varying levels of
sophistication in making system development decisions and
conducting system development efforts.
1.2 OBJECTIVES OF THE SYSTEM DESIGN AND DEVKT.OPMF.NT GUIDANCE
Within EPA's Office of Administration and Resources
Management (OARM), the Office of Information Resources Management
(OIRM) is responsible for ensuring the effective and efficient use
of EPA's information resources including automated system design,
development and maintenance. OIRM's objective in this endeavor is
to provide guidance, assistance, and only when necessary,
controls, to assure that the Agency's considerable information
resources are utilized cost-effectively for the overall benefit of
the Agency. To this end, OIRM has developed umbrella policies
1-1
-------
EPA System Design & Development
Guidance: Volume C
guiding information system development and acquisition (see
Information Resources Management Policy Manual) and has also
developed this three-volume set of guidelines and standards to
assist with EPA's system development efforts. These three volumes
provide sequential guidance for:
. Defining the system requirement (or need) and related
operating concept
. Developing feasible system options and selecting the most
cost-effective option
. Designing, developing and implementing the selected system
option.
Exhibit 1-1, following this page, graphically depicts the three
major phases of the system development life cycle and the
decisions and results expected of each phase. However, EPA's
system development life cycle discussed in these volumes
represents little more than fifty-five percent of the total life
cycle of a software application. Typical cost allocations for
each major component of the total system life cycle are
represented in the graph below.
Life Cvcle Costs 1
Mission Needs Analysis /
Preliminary Design &
Options Analysis 5.0%
Detailed Design
15.0%
Software Testing,
Integration, Verification, &
Validation 30.0%
1 These figures are based on a graphic illustration in Coni-mi i
Software Products by Tom DeMarco, 1982, which purports to
represent industry averages .
1-2
-------
EPA System Design & Development
Guidance: Volume C
EXHIBIT 1-1
EPA SYSTEM DEVELOPMENT LIFE CYCLE
& DECISION PROCESS
PEVELOPMENT STAGE
DECISION/RESULT
REAL WORLD
MISSION NEED
VOLUME A
MISSION NEEDS
ANALYSIS
SYSTEM REQUIREMENT
AND OPERATIONAL
CONCEPT DEFINITION
VQLUMg •
PRELIMINARY DESIGN
OPTIONS ANALYSIS
SYSTEM OPTION DESIGN.
BENEFIT/COST ANALYSIS,
AND OPTION SELECTION
VOLUME C
SYSTEM DESIGN,
DEVELOPMENT
A IMPLEMENTATION
FULLY IMPLEMENTED
SYSTEM
1-3
-------
EPA System Design & Development
Guidance: Volume C
This document is the third of the three-volume set. The
volumes cover the following:
• Volume A - Mission Needs Analysis — is designed to provide
program managers and staff with a suggested methodology for
assessing and evaluating the need (requirement) for an
information system. Applying the methodology in this
volume will result in two outputs: 1) a preliminary
specification of the management requirement for information
or information processing and the outputs and benefits tied
to the user organization's mission and operationsr and 2)
an "Initial System Concept-" which provides an initial
depiction of the system's input, processes and output-*.
These results: 1) confirm that a need (requirement) exists
and 2) provide a preliminary operational specification of
the requirement.
• Volume B - Preliminary 'Design and Options Analysis ~ is
directed towards program managers and staff. It provides
guidance and a methodology for structuring- design options
for meeting the requirement defined in Volume A and
provides guidance for selecting the most cost-effective
opt inn. The steps described in this volume result in the
selection of the most mission/cost-effective option (manual
or automated) based upon life cycle concepts.
• Volume C - System Design. Development And Implementation —
is intended for use primarily by system developers and
provides specific guidance and standards which must be
adhered to when undertaking automated system design and
development efforts.
Together these three volumes provide comprehensive guidance and
standards for the orderly and cost-effective development of
automated systems.
It should be noted that the EPA has established a
comprehensive information security program through Chapter 8 of
the IRM Policy Manual. Because retrofitting security measures
into software under development is complex, expensive and risky,
security considerations need to be an integral part of the system
development life cycle. Consequently, security issues and factors
are identified at appropriate points throughout these volumes. A
detailed discussion of security design and development
considerations is beyond the scope of this guidance. Additional
security guidance will be provided in the forthcoming EPA
Information Security Manual.
1-4
-------
EPA System Design & Development
Guidance: volume C
1.3 AUTHORITY
The EPA System Design and Development Guidance derives its
authority from Chapter 4 of the IRM Policy Manual, entitled
"Software Management," which establishes the Agency Software
Management Program. The guidance serves as the primary guidance
for Agency system design and development efforts.
1.4 APPLICABILITY OF THE GUIDANCE
Senior Agency managers and responsible staff should read the
guidance and become familiar with the standard decision-making
process involved with system design and development efforts. They
are responsible for ensuring adequate analysis and documentation
to support the critical decisions/results illustrated in Exhibit
1-1.
In general, Volumes A and B are intended to assist program
offices and/or users in conducting their own initial studies of
management requirements, needs, option feasibility and cost-
effectiveness. In this context, the term "system" in Volumes A
and B refers to a systematic set of processes and/or procedures
which can be used to meet the information needs of a user. It
does not imply that the "system" will be an automated system.
The full requirements for documentation for automated system
development efforts which must be followed to conform to OARM
policy are fully discussed in Volume C. Volume C, however,
presumes that an automated or partially automated solution has
been selected as a result of the Volume B options analysis.
Volume C provides both guidance and standards for automated
system development efforts. If the automated system is a
relatively small application on a microcomputer targeted for use
within a single office (a "user owned information system"), Volume
C provides simplified requirements for system design, development
and implementation. If the proposed system is a larger
application (mainframe or minicomputer), which is mission-critical
or involves multiple offices and organizations, Volume C provides
both guidance and standards which must be followed by system
developers. This will assure uniform, cost-effective system
development in accordance with EPA policies, guidelines and
standards.
1.5 DOCUMENTATION REQUIREMENTS
In general, the intent of the three-volume System Design and
Development Guidance is to provide a consistent focus for system
development efforts which will allow both EPA program managers and
OARM managers to cost-effectively develop and maintain the
Agency's systems. To achieve this goal, certain documentation
1-5
-------
EPA System Design & Development
Guidance: Volume C
requirements (termed "Essential Elements of Information" (EEI)
documents) must be met. Exhibit 1-2, following this page,
summarizes the EEI documentation requirements. As shown,
documentation required for the first two phases of the process —
Mission Needs Analysis and the Preliminary Design and Options
Analysis — are limited to one and two documents each,
respectively. All system development efforts are subject to the
documentation requirements of these first two phases as set out in
Volumes A and B.
If a full information system development effort is
anticipated after these first two phases, then a traditional
series of system design and development documents must be
developed and submitted as shown in Exhibit 1-2. For certain
system development efforts OIRM and office Senior Information
Resources Management Officials (SIRMOs) must be involved in a
review capacity to fulfill EPA's IRM Policy Manual requirements.
Systems falling into one or more of the following categories must
have OIRM/SIRMO review involvement:
. EPA mission critical
. States, local governments or other Federal agencies
involved
. Interorganizational involvement (e.g., between Assistant
Administratorships or including Regional Office
involvement)
. Costs for system'development/enhancement are projected to
exceed 3250K (excluding costs associated with long-term
system operation and maintenance)
. Information security issues involving the three general
security areas: applications security, installation
security and personnel security. In total, information
security involves the precautions taken to protect the
confidentiality, integrity and availability of information
. Privacy Act or confidential business information involved.
For system development efforts falling into any one of these
categories, OIRM and office SIRMOs must be involved beginning with
a review of EEI-1, generated at the conclusion of the Mission
Needs Analysis, as described in Volume A of the EPA System Design
and Development Guidance. OIRM/SIRMO review involvement will
continue through the. development life cycle of these systems and
will include all EEI documentation requirements for such systems.
1-6
-------
SPA System Design & Development
Guidance: Volume C
EXHIBIT 1-2
EPA SYSTEM DEVELOPMENT LIFE
CYCLE DOCUMENTATION
DEVELOPMENT PHASE
DOCUMENTATION
REAL WORLD
MISSION NEED
YO.LMA
MISSION NEEDS
ANALYSIS
I '
J
llt-1. MISSION MHOS
STATIUINT (INCIUOINO INITIAL
1TSTIH CONCIFT)
VCUACB
PRELIMINARY DESIGN
t OPTIONS ANALYSIS
IIM. MfUMINAIIV OISION 4
OPTIONS ANALYSIS
III-*. MOJICT HANAQIUINT
PLAM
VOUACC
SYSTEM DESIGN
SYSTEM
DEVELOPMENT
SYSTEM
IMPLEMENTATION
IIM. »0»TWABI PHILIMINAflT
Oman OOCUMINT
Ill-l. SOrrWARI OITAILIO
OISION
[llt-10. lOTWABI HAINTINANCI
OOCUMINT
sorrwAHi OPIRATION*
OOCUMINT
UI-12. SOPTWAMI USIM'S
RVIRINCI OWOI
Ill-ll. STSTIM INTIORATION
HIT KIPOHT1
ID UVOAT1S AS MOUIHID
1-7
-------
EPA System Design & Development
Guidance: Volume C
For systems not falling into one of the above categories,
EEIs may be forwarded to OIRM/SIRMOs for information and review as
they are developed.
Automated systems involving information security will be
subject to one additional documentation requirement — completion
of a certification form (certification of sensitive systems is an
OMB requirement). The form, which is under development and will
be issued as part of the forthcoming EPA Information Security
Manual, will capture basic information on system sensitivity,
security requirements, security design, reviews, test scenarios,
results and safeguards. Information needed to complete the form
will be readily available in the EEI documentation. Prior to the
system being placed into use or production, the cognizant SIRMO
(or other senior official in the AA/RA's office) will need to
certify that the automated system is adequately safeguarded based
on the information in the form.
It is not OIRM's intent to burden EPA managers with a host of
documentation requirements for each system development effort.
The EEIs simply stress typical documentation requirements and
their outlines highlight major topics that need to be considered
for any system development effort. Managers may use their
professional judgment in substituting, combining, or down-scaling
the content of the EEIs to meet the unique requirements of their
project. Additionally, the EEIs set out in this volume are not
meant to conflict with or add more burden to documentation
requirements set out in other manuals (e.g., EPA/NCC ADABAS
Application Development Procedures Manual). Documentation
produced according to such other procedures will invariably
satisfy, either partially or fully, some EEI requirements.
Criteria for determining the minimum EEI documentation for a
specific system is based on the nature and scope of the
information system and its importance to EPA's mission. Four
types of systems with differing levels of EEI documentation
requirements are identified as follows:
. Major Agency Information System: An information system
that requires special continuing management attention
because of its importance to an agency mission, its high
development, operating, or maintenance costs or its
significant impact on administration of Agency programs.
. Widely Accessed Information System; An information system
that is not a Major Agency Information System (although it
significantly supports accepted program goals and missions)
but is widely accessed by a combination of EPA
Headquarters, Regional Offices and/or State and local users
and other Federal agencies.
1-8
-------
EPA System Design & Development
Guidance: Volume C
. Localized Information System; An information system that
is not a Major Agency Information System but significantly
supports accepted program goals and missions and is
accessed primarily by users in one major area, e.g., EPA
Headquarters, a single Agency program, or a Region.
. User Owned Information System; Unique, stand-alone system
developed to improve the efficiency or effectiveness of
operations for a single user or a small group of users.
Documentation requirements for each of these system
categories are projected in Exhibit 1-3 on the next page and in
Chapter 4 of Volume C. Policies and procedures covering the
submission, review and approval of EEIs by OIRM will be issued
under separate guidance.
1 . 6 ASSISTANCE AND SUPPORT AVAILABLE
Agency Program and Management officials embarking on a system
development effort should be aware that there are at least two
sources available to them for assistance and support during the
system development life cycle:
. Within each AA/RA's office SIRMOs are available for
assistance, support and guidance relative to the EPA System
Design and Development Guidance and other OIRM guidance and
standards (e.g., Core Systems, Structured Programming,
etc.)
. OIRM, with its general IRM management oversight role and
requirement to exercise procurement approval authority, has
a staff organized to support EPA's administrative, program
and research communities.
It is appropriate to involve these support sources as early as is
feasible in the system development life cycle for most system
development efforts.
The primary reasons for early involvement of SIRMOs and OIRM
staff are:
. Fulfilling EPA's IRM policy for system development review
requirements
1-9
-------
EPA System Design & Development
Guidance: Volume C
X
DC
LU
^
DC
O
o
LU
<
O
CO
EXHIBIT 1-3
EEI-13
System Integration
Test Report
EEI-12
Software User's
Reference Guide
EEI-11
Software Operations
Document
EEI-10
Software Maintenance
Document
EEI-9
Software Detailed
Design Document
EH-8
Software Preliminary
Design Document
EO-7
Software Test
and Acceptance Plan
EE3-6
Software
Management Plan
EEL5
System Detailed
Requirements Document
EEM
System
Implementation Plan
EEI-3
Project Management
Plan
EEI-2
Preliminary Design
and Options Analysis
EH-l
Mission Needs
Analysis
s
c /
'3 /
S 8" /
/ !§>
•
•
•
•
•
•
•
•
•
•
•
•
•
Systems That
Require OIRM
Involvement *
•
•
•
•
•
•
•
•
•
•
•
•
•
Major Agency
Information
Systems
•
•
•
•
•
•
•
•
•
•
•
•
•
Wide3y Accessed
Information
Systems
•
•
•
•
•
•
•
•
•
•
Localized
Information
Systems
•
•
•
•
•
•
User Owned
Information
Systems
1 As detailed on page 1-6.
1-10
-------
EPA System Design & Development
Guidance: Volume C
. Providing a value-added service role involving
consultation, assistance, technical standards, guidance and
interpretation of requirements
. Expediting procurement for system development efforts which
proceed to the system design, development and
implementation phase
. Providing assistance in determining user needs as early as
possible in the life cycle.
Achieving these objectives will strengthen EPA's system
development efforts and avoid major pitfalls that have beset
system development efforts in other government agencies (e.g.,
project stalls due to outyear funding shortages stemming from
under-projected planning or project disruptions due to failure to
get hardware/software acquisitions into the procurement cycle
expeditiously and when required).
The remainder of Volume C provides guidance and standards for
conducting the third phase of the system development process —
the System Design, Development and Implementation phase.
1-11
-------
£PA System Design & Development
Guidance: Volume C
2 . SOFTWARE MANAGEMENT PROGRAM
Implementation of the EPA Software Management Program draws
on the experience of software professionals within EPA and on the
experience of the Federal Government through both the Office of
Information Resources Management, the General Services
Administration and the Institute for Computer Sciences and
Technology of the National Bureau of Standards.
The objective of the Software Management Program is to ensure
the quality with which EPA designs, develops, implements and
maintains software. The EPA Software Management Program consists
of the following Software Engineering Elements:
. Policies
. Standard Software Tools
. Procedures/Methods
. Guidelines
. Planning, and
. Oversight and Compliance.
This volume specifically addresses standard software tools,
procedures/methods, guidelines, planning and oversight and
compliance.
2 . 1 APPLICABILITY TO SMALL AND LARGE PROJECTS
The Software Management Program is designed to be applicable
to both large and small projects. Managers of specific projects
must use their professional judgment (aided by the guidelines
provided in this methodology) on how to apply the Software
Management Program. For larger projects, the Software Management
Program should be used in its entirety. For smaller software
projects, the Software Management Program should be adjusted to
meet the needs of the specific project. For example, a judgment
might be made that the documentation requirements are excessive
for a particular project, so parts of different documents could be
combined or eliminated to reduce the number of documents and level
of documentation required.
2 .2 QUALTTY SOFTWARE
The Software Management Program will produce significant
results, including:
Improved inter-organizational relationships
- Demonstrated software engineering expertise
- Improved user acceptance of final products
- Improved ability to react to changes
2-1
-------
EPA System Design & Development
Guidance: Volume C
- Increased reliability of the software
- Improved maintainability of the software
. Institutionalization of the software development process
• - Enhanced technology transfer between projects
- Better utilization of personnel resources
- Reduced dependency on specific individuals
- Improved ability to measure and control software
development for project scheduling and cost purposes
- A production line approach to software development and
maintenance
. Reduced cost of developing and maintaining software
- Increased programmer productivity
- Fewer problems (errors) with delivered products
- More easily enhanced software
. Improved software portability
- Isolation of computer architecture dependencies
- Elimination of non-standard source code
- Development of reusable source code
The Software Management Program has been developed to assist
personnel directly involved in software development projects,
including:
. Program Managers — It provides assurance that EPA will
apply uniform, cost-effective methods throughout its
software life cycle projects. New projects need not
produce their own unique software management and
development procedures, but, through the Software
Management Program, can benefit from the experience of
successful software development projects.
. Project Managers — It includes the "what, why and how"
of software life cycle management.
. Programmers and Analysts — It describes specific tools
and techniques for the software development life cycle.
2.3 SOFTWARE MANAGEMENT PROGRAM OVERVIEW
The EPA Software Management Program includes a system
development life cycle model, and for each phase of the life cycle
2-2
-------
EPA System Design & Development
Guidance: Volume C
process, the software engineering components related to
controlling and regulating that phase. The Software Management
Program has major inputs from Volumes A and B of the System Design
and Development Guidance series. These inputs are:
. Phase 1 - Mission Needs Analysis
Mission Needs Statement (including Initial System Concept)
is produced during the Mission Needs Analysis phase.
. Phase 2 - Preliminary Design and Options Analysis
Preliminary Design and Options Analysis Document and a
Project Management Plan are produced during the Preliminary
Design and Options Analysis phase.
The Software Management Program defines the following additional
phase of the system development life cycle:
. Phase 3 - System Design, Development and Implementation
Detailed discussions of this phase are contained in Chapter 3 of
this document.
2-3
-------
SPA System Design & Development
Guidance: Volume C
3. SYSTEM DESTKN. DEVELOPMENT. AND IMPLEMENTATION OVERVIEW
This chapter addresses the third phase of the system
development life cycle — the System Design, Development and
Implementation phase and provides amplifying details on the three
stages which comprise this phase:
. System Design Stage - which comprises tasks and activities
associated with System Detailed Requirements Analysis,
Preliminary Design and Detailed Design;
. System Development Stage - which comprises tasks and
activities associated with System Production and
Programming and System Integration, Test and Evaluation;
and
. System Implementation Stage - which comprises tasks and
activities associated with System Installation, and System
Operation, Maintenance and Evaluation.
For each stage it discusses the associated tasks and activities,
reviews, baselines and documentation requirements. Exhibit 3-1,
on the following page, overviews the process.
There are EEI documentation requirements during the System
Design, Development and Implementation phase. While each' is
generally discussed in this chapter, detailed representative
outlines for each EEI (numbers 4-13) are contained in Appendix A.
EEIs 1-3 were detailed previously in Volumes A and B.
3.1 SYSTEM DF.STGN STAGE
Associated tasks and activities include System Detailed
Requirements Analysis, Preliminary Design and Detailed Design.
3.1.1 System Detailed Reemiremer'.r.fi Analysis
The major inputs to this task are the:
. Mission Needs Statement document produced during the
Mission Needs Analysis phase — defined in Volume A
. Preliminary Design and Options Analysis Document and
Project Management Plan produced during the Preliminary
Design and Options Analysis phase — defined in Volume 3.
These documents are used in performing the detailed
requirements analysis for the software system. The conclusions
3-1
-------
System Design, Development and Implementation Life Cycle Phase
Uto-Cyd*
**•••
•i*e*«
Tuh« Kn4
AcllvllU*
D
•
•
u
•
n
1
•
1
1
•
a
R
•
^
w
1
i
•
•
n
1
•
(EEI9)
«•*»•
M*|M»
System Design, Development and Implementation
8y*teniDMlgn
»r»imn*+,i
Sl*tm tmflinutiitin
Pten(EEI-4)
SfUtm OMMhJ
n*<*j>*nMr« Oocumm
CEEI*)
T!fi*win MiMq«atrt
Ptan(EEM)
•yowl R»q>4renMnl>
H^4n»
• •••JIM* Function-
^^BL B«~lki»
Hiii >nnn»i
SolMw«T*«l
*n4 Aco>^unc*
PUn(E£in
0»iyi
Oocuiwi* (CEI «)
Pratntwiy
(teilgn ftmlra
Prallnikt«T
D»iQn Ibxlm
OiMMOM^i
^ SC*M« O«*ted
(EEia)
CfUnd
Dnl^iHntm
O.l«lli>
B«xUn>
System OcwIopnMnt
&BAMM Pi rik
Mi-^x^a
6(rfMW9 II^IWIMM
OocwmMI (tEHOJ
6a*ni»ClMMlJM«
OamiDmi|EE»-lt) :-
Gotau»UM(»
M*<«nc«Gi«M(CEM])
Functaml Cortgtnten
HMM>«|
Ptiyiical Conliguiuan
RMMTil
OvMtoyiMn T«M Anrf
t««lu^lnn^»tn.
T««.«n4E«alu«lMl
SMICM b^MreiloA
T«M ftaporu (EEt-13|
Funcioml C««gmtM
HMM>«
Phyilul COTligmfen
HM«v«2
C^MIanriT^Anrf
EnlutflMRMtm
6««Un, ^^U. Bwilkv
System tmplamantation
%»«-•
U**f Ac««f«MM
•irMMOp.ntfMX
ttakMMKM,
ft*im OHiH»d
(EEI^S)
Sak«M» UUHOMBWI
Phn|EEM)
&*>«raOM*fcd
Oocuawn (EEt-IO)
BQ||I»«I» OpxMJpm
ODOUMX(EEI-II)
So»MraUMO
fWw*no* Quito (EEM2)
ST«MI kwgnuan
T«ti Ripott* (EEM ft
tn
H
ui
(ii in
n *<
n u
a> rt
•• (D
3
< a
o a
I-1 W
c. t--
3 uj
n> 3
o «^
a
(D
rt>
§
a
rr
-------
EPA System Design & Development
Guidance: Volume C
of these documents are confirmed by the software development staff
that will ultimately produce the software system.
This task entails further analysis of the problem, the
definition of the functional components of the major software and
hardware elements of the system and association of functional
components to requirements. The scope of the software development
project is revised, if necessary, and further defined.
3.1.1.1 Activities
The activities associated with the System Detailed
Requirements Analysis are:
. Confirm the analysis of current systems that have been
reviewed and their adequacy/inadequacy for use in solving
the problem
. Confirm the alternative solutions that have been proposed
and ensure.that the selected alternative is the one that
should be used
. Prepare the System Implementation Plan
- Identify events, actions and milestones
- Identify resource requirements
- Review schedules and work plans
- Produce integrated project plan
. Prepare the System Detailed Requirements Document
- Define major system functions
- Define physical requirements
- Define security requirements
- Define quality requirements
- Define life cycle resource requirements
- Define testing and verification requirements
- Define project work schedule(s) and work plan(s)
. Prepare the Software Management Plan
- Identify project resources
- Define review responsibilities
- Identify organizational structure and required resources
- Establish project schedules, reviews and reporting
controls
- Implement risk management
- Implement software product assurance procedures
- Implement software development procedures for the
project
3-3
-------
EPA System Design & Development
Guidance: Volume C
While defining the System Detailed Requirements, a separate
data dictionary document should be prepared that lists and
describes each data element to be referenced by the system.
[Guidance on the content and format of the Data Dictionary
Document will be provided at a future date by OIRM.]
3.1.1.2 Documentation
Documentation associated with the System Detailed
Requirements Analysis includes:
. System Implementation Plan EEI-4 (Final)
. System Detailed Requirements
Document EEI-5 (Preliminary)
. Software Management Plan EEI-6 (Preliminary)
3.1.1.3 System Requirements Review
The System Requirements Review is performed to ensure the
adequacy of the system requirements and approve formally the
definition of the user's requirements. The System Detailed
Requirements Document is the primary subject of the review. The
Software Management Plan and the System Implementation Plan are
also input to the review process.
The System Requirements Review takes place at the end of the
System Detailed Requirements Analysis task. A successful System
Requirements Review results in the establishment of the Functional
Baseline. OIRM/SIRMO representation should be ensured at the
System Requirements Review.
3.1.1.4 Functional Baseline
The Functional Baseline is established as the original
baseline configuration and consists of the functional system
specifications contained in the System Detailed Requirements
Document (EEI-5). Once the System Detailed Requirements Document
is baselined, any changes to that document represent a change in
the scope of the project and must have management approval. The
Functional Baseline is established after a successful System
Requirements Review.
3.1.2 Preliminary Design
The Preliminary Design task represents the initial effort in
producing a design that can be used in producing an operational
software product.
3.1.2.1 Activities
The activities associated with Preliminary Design are:
3-4
-------
EPA System Design & Development
Guidance: Volume C
Confirm that candidate packages/existing software can be
used or integrated into the new system
Prepare Software Design Document
- Identify each software design requirement
- Identify the functional flow of the system, address each
design requirement and describe each requirement and
associated software design-functions (SDFs)
- Detail each SDF by defining:
Inputs
Local Data
Initiation, Timing and Sequencing
Interrupts
Processing
Outputs
Adaptation
- Define Data Base and File Structures
Data Base Management System
Logical Design of the Data Structures
Data Interrelationships
Characteristic/Requirements Traceability
Update Software Management Plan
Prepare preliminary Software Test and Acceptance Plan
- Software Unit Test Plans
Test Requirements
Test Management
Test Schedule
Tests and Results
- Integration Testing of Software Units, Modules and
Software Functions - Test Plans
Integration Test Requirements
Integration Test Management'
Integration Test Categories
Integration Test Methods
Integration Test Schedules
Integration Tests and Results
- Required Resources for Unit and Integration Testing
3-5
-------
EPA System Design & Development
Guidance: Volume C
Facilities
Hardware Environment
Interface/Support Software
Personnel
- System Test Plans
System Test Requirements
System Test Management
System Test Categories
System Test Methods
System Test Schedules
System Tests and Results
- User Acceptance Test Plans
Test Team
Pretest Procedures
Acceptance Test Procedures
Formal Acceptance
. Address:
- Initial design of user procedures
- Conversion software and appropriate procedures
- Operations procedures.
3.1.2.2 Documentation
Documentation associated with the Preliminary Design task
includes:
. Software Management Plan EEI-6 (Updated)
. Software Test and
Acceptance Plan EEI-7 (Preliminary)
Software Preliminary Design
Document EEI-8 (Final)
3.1.2.3 Preliminary Design Review
The Preliminary Design Review is performed for each system
element to ensure the adequacy of the preliminary design and the
test plans for verifying the accuracy of the software system. The
Software Preliminary Design Document and the Software Test and
Acceptance Plan are the primary subject of the review. The
updated Software Management Plan is also input to the review
process.
3-6
-------
EPA System Design & Development
Guidance: Volume C
The purpose of the Preliminary Design Review is to:
. Evaluate the progress, technical adequacy and risk
resolution (on a technical, cost and schedule basis) of the
selected design approach
. Determine the compatibility of the selected design approach
with the requirements and performance of the System
Detailed Requirements Document
. Establish the existence and compatibility of the physical
and functional interfaces among the other elements
(equipment, facilities, computer programs and personnel)
. Determine the adequacy of the test plans in accurately
verifying the software system against the design criteria.
The Preliminary Design Review takes place at the end of the
Preliminary Design task. A successful Preliminary Design Review
results in the establishment of the Preliminary Design Baseline.
OIRM/SIRMO representation should be ensured at the Preliminary
Design Review.
3.1.2.4 Preliminary Design Baseline
The Preliminary Design Baseline is established after a
successful Preliminary Design Review. It consists of the initial
design specifications — including data base specifications. The
Preliminary Design Baseline is made up of the Software Preliminary
Design Document (EEI-8) and the Software Test and Acceptance Plan
(EEI-7). Once these documents are baselined, any changes to
those documents represent a change in the scope of the project and
must have management approval.
3.1.3 Detailed Design
The Detailed Design task represents the final effort in
producing a detailed design that will be used in producing an
operational software product. The Software Detailed Design
Document is prepared using the information in the Software
Preliminary Design Document prepared during Preliminary Design.
It is refined, and additional detail is added to produce a
detailed design adequate for code production. The first draft of
the Software User's Reference Guide may be prepared. The Software
Management Plan and Software Test and Acceptance Plan are updated
as necessary. The Project Management Plan and Benefit-Cost
Analysis should be updated during this task.
3.1.3.1 Art-ivit ies
The activities associated with Detailed Design include:
3-7
-------
EPA System Design & Development
Guidance: Volume C
. Prepare Software Detailed Design Document
- Update/refine preliminary design information
- Decompose each Software Design Function
Software Unit Formal Parameters
Software Unit Inputs
Software Unit Local Data
Software Unit Processing
Software Unit Outputs
Software Unit Limitations
Use of other software elements
- Data Base Physical Design
File
Record
Field
Item
. Prepare initial draft of EEI-12, Software User's Reference
Guide with at least sections one through three completed
and a detailed outline of the remainder of the document
- Description of the system
- System access techniques
- User analysis/reporting options
- Data entry and update process
- User support and training program/sources
- Security requirements
. Update Software Management Plan
. Update Software Test and Acceptance Plan.
3.1.3.2 Documentat ion
Documentation associated with the Detailed Design includes:
. Preliminary Design and Options
Analysis EEI-2 (Updated)
. Project Management Plan EEI-3 (Updated)
. Software Management Plan EEI-6 (Updated)
. Software Test and
Acceptance Plan EEI-7 (Final)
. Software Detailed Design
Document EEI-9 (Final)
3-8
-------
EPA System Design & Development
Guidance: Volume C
Software User's
Reference Guide
EEI-12 (Preliminary)
3.1.3.3
Critical Design Review
The Critical Design Review is conducted for each system
element when the detailed design is complete. The Software
Detailed Design Document and the updated Software Test and
Acceptance Plan are the primary subject of the review. The
Software Management Plan and the Software User's Reference Guide
are also input to the review as necessary. The purpose is to
accomplish the following:
. Determine that the detailed design of the software system
element under review satisfies the performance requirements
of the System Detailed Requirements Document
. Establish compatibility among system elements in the
detailed design
. Assess the producibility and risk areas (on a technical,
cost and schedule basis) .
. Review the preliminary product specifications.
A successful Critical Design Review establishes or updates the
Design Baseline. The Design Baseline is then used as the basis
for the production and coding of the software system. OIRM/ SIRMO
representation should be ensured at the Critical Design Review.
3.1.3.4
Desion Baseline
The Design Baseline is established after a successful
Critical Design Review. It consists of the final design
specifications — including data base specifications and the test
plans associated with the software product. The Detailed Design
Baseline is made up of the Software Detailed Design Document (EEI-
9) and the final Software Test and Acceptance Plan (EEI-7). Once
these documents are baselined, any changes to the documents
represent a change in the scope of the project and must have
management approval.
3.2 SYSTEM DEVELOPMENT STAGZ
Associated tasks include System Production and Programming,
and System Integration, Test and Evaluation.
3.2.1
System Product ion ar.d Programming
The specifications developed during the System Design stage
are used to develop a system that functions correctly in a
3-9
-------
EPA System Design & Development
Guidance: Volume C
controlled environment. At the completion of the System
Production and Programming task, all programs, job streams, data
bases, security controls, user procedures and operations
procedures will have been developed and thoroughly tested by the
development team.
3.2.1.1 Activities
The activities associated with System Production and
Programming are:
. Develop Software System
- Code software units
- Review software unit code
- Unit test software unit code
- Produce unit test reports
- Perform subsystem integration testing
- Prepare subsystem integration test reports
. Prepare Software Maintenance Document
- Maintenance Procedures including:
Source Code Standards
Documentation Update Procedures
Coding and'Review Process
Change Control Process
Testing Standards and Procedures
Change Implementation Methods
- Maintenance Tools
Technical tools
Management tools
- Source code
Source listings or equivalent
. Prepare Software Operations Document
- System Initialization
- System Restart by Functional Element
- System Manager functions
- System Backup/Recovery Provisions and other Information
Security Provisions.
3-10
-------
EPA System Design & Development
Guidance: Volume C
3.2.1.2 Doeumentation
Documentation associated with the System Production and
Programming task includes:
. Software Maintenance Document EEI-10 (Preliminary)
. Software Operations Document EEI-11 (Preliminary)
. Software User's Reference
Guide EEI-12 (Updated)
. Unit Tested Source Code
. Unit Test Data.
3.2.1.3 System Production and Programming Review^
Preliminary Functional Configuration and Physical
Configuration reviews are performed as each piece of software is
delivered for inclusion into the product baseline. They confirm
that the software product or component of the software product
performs according to the requirements and design specifications
that have been prepared and baselined during System Design.
The results of the review are input to the Development Test
and Evaluation Review.
3.2.1.4 Development Test and Evaluation Review
The Development Test and Evaluation Review ensures that the
developmental testing of the software is successful and that the
system requirements are satisfied. The Software Maintenance
Document, the Software Operations Document, the updated User's
Guide, the results of the Functional Configuration Review and the
results of the Physical Configuration Review are also reviewed for
completeness and accuracy. Upon completion of a successful
review, these documents are placed in the Product Baseline.
The Development Test and Evaluation Review is performed at
the end of the System Production and Programming task. A
successful Development Test and Evaluation Review establishes or
updates the Product Baseline. OIRM/SIRMO representation should be
ensured at the Development Test and Evaluation Review.
3.2.1.5 Product: Baseline
The Product Baseline establishes a tes.ted, operable version
of the software system in its operating environment. As each
subsystem is successfully tested, the product baseline is updated.
The baseline of the completed and tested version of the software
product ensures that any changes or enhancements take place
against a stable, controlled set of functional and technical
components. The Product Baseline will include the completed
3-11
-------
EPA System Design & Development
Guidance: Volume C
product specifications, the operation/maintenance documents and
the user's guide.
The Product Baseline is established/updated after a
successful Development Test and Evaluation Review at the end of
the System Production and Programming task.
3.2.2 System Integration. Test and Evaluation
The System Integration, Test and Evaluation task includes the
testing of the fully integrated software product in its
operational environment. This task is performed by a test team
that does not include any of the software development team
members. The purpose is to provide a test and evaluation
environment that is independent of the development effort.
The Software Maintenance Document, the Software Operations
Document and the Software User's Reference Guide are updated as
necessary based on the testing process. The software product and
its related documents may have to be sent back to the development
team if rework is retired based on the results of system
integration testing.
3.2.2.1 Activities
The activities associated with the System Integration, Test
and Evaluation task are:
. Install the working system using the installation
procedures
. Execute the System Test portion of the Software Test and
Acceptance Plan
. Document any discrepancies noted during testing for
resolution with the development team and user
. Verify that discrepancies that require software
modification have been modified correctly
. Prepare System Integration Test Report
. Recommend disposition of the software and documentation.
3.2.2.2 Documentation
Documentation associated with the System Integration, Test
and Evaluation task includes:
. Software Maintenance Document EEI-10 (Updated)
. Software Operations Document EEI-11 (Updated)
3-12
-------
EPA System Design & Development
Guidance: Volume C
. Software User's Reference
Guide EEI-12 (Updated)
. System Integration Test Reports EEI-13 (Final)
. System Integration Tested Software
. System Integration Test Data
3.2.2.3 System Integration. Test and Evaluation Reviewc,
The final Functional Configuration and the Physical
Configuration reviews are performed when all the subsystems are
delivered and integrated into the Product Baseline. They confirm
that the software product or component of the software product
performs according to the requirements and design specifications
baselined in the Product Baseline.
The results of the review are input to the Operational Test
and Evaluation Review!
3.2.2.4 Operational Test and Evaluation Review
The Operational Test and Evaluation Review ensures that the
software system is viable in its intended environment. The
Operational Test and Evaluation Review is performed at the end of
the System Integration, Test and Evaluation task.
The Software Maintenance Document, Software Operations
Document and the User's Guide are the major inputs to the review.
The System Integration Test Reports drive the review in that they
contain the results of testing the software product. All errors
or incidents that were encountered during formal testing are
identified. The resolution of each incident is noted. Those
incidents that were determined to be errors are presented in two
categories — corrected and unresolved. This information is used
in determining if the software product is ready for formal use. A
successful Operational Test and Evaluation Review establishes or
updates the Operational Baseline. OIRM/SIRMO representation
should be ensured at the Operational Test and Evaluation Review.
3.2.2.5 Operational Baseline
The Operational Baseline represents the completely
implemented and tested software system. It is the basis for
future maintenance changes and enhancements. All documentation is
modified as required, validation and acceptance testing is
completed and the system is placed in production and/or turned
over to the user. The Operational Baseline is established and/or
updated after a successful Operational Test and Evaluation Review.
3-13
-------
EPA System Design & Development
Guidance: Volume C
3.3 SYSTEM IMPLEMENTATION STAGE
This stage comprises System Installation and System
Operation, Maintenance and Evaluation.
3.3.1 System Installation
The System Installation task is primarily for formal user
acceptance of the software product. The software product is
installed in a production environment, and the user exercises the
product to determine if it meets his/her needs and requirements.
3.3.1.1 Activities
The activities associated with System Installation are:
. Installation of the software product in a production
environment
. User acceptance of the software product
. User training.
3.3.1.2 Major Products
The major products associated with System Installation are:
. Operational software installed
. Training completed
. User agreement to accept the software and documentation.
In addition, the final version of the following system
documentation is delivered:
. System Detailed Requirements EEI-5
Document
. Software Management Plan EEI-6
. Software Detailed Design Document EEI-9
. Software Maintenance Document EEI-10'
. Software Operations Document EEI-11
. Software User's Reference Guide EEI-12
. System Integration Test Reports EEI-13
3.3.2 System Operation. Maintenance and Evaluation
The System Operation, Maintenance and Evaluation task begins
after the user has formally accepted the software system and its
supporting documentation at the end of System Installation. The
software product is placed in operation and made available for
use.. Formal user support and maintenance procedures are
established and implemented.
3-14
-------
EPA System Design & Development
Guidance: Volume C
While this is the last task in the system development life
cycle, it in itself represents the beginning of the software
maintenance life cycle. As the software product matures and
changes must be made to it, this process will replicate the
previous phases of the EPA system development life cycle — from
the Mission Needs Analysis through System Installation. Exhibit
3-2 presents the software maintenance life cycle concept.
3.3.2.1 Activities
The activities for this task include:
. Operate the system to the degree necessary
. Provide user support for questions, training, etc.
. Log and categorize software problems as they are identified
. Log software enhancement requests
. Perform periodic reviews of the software product and its
related documentation to ensure that the product is meeting
user/Agency needs
. Determine when identified problems/enhancement requests
• justify a new release/version of the system product.
When the nature of the problems/enhancement requests justify
a new release or new version of the software product, the
changes/modifications will be subject to the system development
life cycle. While the effort and duration of the 'maintenance1
life cycle process might not be as rigorous and lengthy as the
initial development effort — all of the steps and procedures must
be followed to ensure that:
. The EPA mission is properly supported
. The quality of the maintained software product and its
related documentation is not compromised.
The nature, complexity and cost of the modifications will
dictate the degree to which the 'maintenance' life cycle is
followed. Simple 'bug' fixes may not require the scrutiny and
analysis that a major enhancement must undergo.
3.3.2.2 Documentation
Documentation maintained or updated during the System
Operation, Maintenance and Evaluation task includes the
3-15
-------
EPA System Design & Development
Guidance: Volume C
EXHIBIT 3-2
SOFTWARE MAINTENANCE LIFE CYCLE
PRODUCT
LIFECYCLE
DEVELOPMENT LIFECYCLE
3-16
-------
EPA System Design & Development
Guidance: Volume C
documentation that is delivered with the operational system
including versions of the:
. System Detailed Requirements EEI-5
Document
. Software Management Plan EEI-6
'. Software Detailed Design Document EEI-9
. Software Maintenance Document EEI-10
. Software Operations Document EEI-11
. Software User's Reference Guide • EEI-12
. System Integration Test Reports EEI-13
3-17
-------
EPA System Design & Development
Guidance: Volume C
4. SOFTWARE ENGINEERING COMPONENTS
This chapter addresses the software engineering components
necessary to successfully implement the EPA Software Management
Program during the EPA software development life cycle phases
and the quality assurance considerations for successful software
development.
4 .1 SOFTWARE ENGINEERING COMPONENTS
There are four software engineering components that direct,
control or support each of the life cycle phases and are essential
to the successful execution of each phase. These software
engineering components are:
. Standards
. Procedures/methodologies
. Software Development Support Tools
. Quality Assurance.
Each life cycle phase is supported, in different degrees, by
the four software engineering components. These components
provide the necessary technology and discipline to create a
software engineering environment.
4.1.1 Standards
Standards are grouped in two major categories: methodology
standards (uniform procedures for accomplishing a function) and
performance standards (metrics to evaluate performance).
Methodology standards allow work to be accomplished
systematically. They facilitate the turnover of work whether it
is from personnel working in one life cycle phase to those working
in another life cycle phase or among personnel working on the
project. Personnel trained in the Software Engineering Program
should be able to join a project at any time and become productive
soon thereafter.
Performance standards deal with the quantifiable aspect of a
task, for example, the amount of time it should take to perform a
task and the expected quality of the task's end product.
Performance standards depend on methodology standards being in
place and enforced so that performance can be measured accurately.
4.1.2 Procedures/Methodologies
Procedures/methodologies define the processes that are
followed in each of the particular phases of the system
development life cycle.
4-1
-------
EPA System Design & Development
Guidance: Volume C
The two classes of procedures"are manual and automated.
Manual procedures, which programmers and analysts follow when
performing a task, direct the flow of activities. For example, a
programming procedures manual provides the direction for achieving
progress using the proper programming language elements,
associated structured techniques and source code formatting.
Automated procedures, on the other hand, direct the execution of
computer programs and software development support tools.
4.1.3 Software Development Support Tools
Software Development Support Tools are computer programs used
to automate some of the labor intensive activities involved in the
management, design, coding, testing, validation and maintenance of
application programs. Software development support tools are used
in support of standards and procedures/methodologies by EPA and
its contractors in the software development and maintenance
process.
4.1.4 Quality Assurance
Quality Assurance is the formal process of measuring or
evaluating the degree to which a product meets the standards by
which it was developed and the specifications upon which it was
based. Each product (both software and documentation) produced
within each life cycle phase should be subjected to a Quality
Assurance process.
4.2 SOFTWARE ENGINEERING PRINCIPLES
Effective system development requires a thorough
understanding of the user's requirements coupled with a
development process capable of fulfilling those requirements with
a responsive system. A clear understanding must be established of
the user's requirements, their relationship to the overall system
and the functional elements constituting the system. The EPA
Software Management Program provides an approach to software
development that divides the life cycle into well defined phases.
The Software Management Program indicates the activities and
tasks that should be performed for each phase of the life cycle
and the resulting deliverables. It also identifies what has to be
done, when it should be done and how it should be done.
The Software Engineering Program defines the Essential
Elements of Information (EEIs) or documentation that should be
produced and/or updated. The baselines for each phase and reviews
necessary to approve the documentation are also defined in the
Software Engineering Program.
4-2
-------
EPA System Design & Development
Guidance: Volume C
The characteristics of an evolving system are defined and
documented in increasing detail at logical transition points, or
baselines, of the software development life cycle. Approved
documentation and/or software products constitute a baseline. At
any time in the system life cycle, all previously established
baselines, together with any approved changes to these baselines,
constitute the formal identification of the system and its
components.
The type of system being developed will dictate the level of
documentation necessary to support that system. The diligent use
of EEIs will resolve the conflicts that arise between the:
Cost of documentation
. Classical life cycle for system development
. Changes in computing capabilities and system development
techniques.
The use of Fourth Generation Languages (4GL) have, in many
instances, provided:
. Significant gains in productivity
. Shortened life cycle development time, and
. Products that better reflect user requirements.
The use of new software production techniques which include the
use of 4GLs in software development, while possibly changing the
order and timing of the production of system documentation, has
not eliminated or reduced the need for adequate system
documentation.
The use of the EEIs defined in this volume represent a
flexible approach to system documentation. All systems require
some form of documentation. However, the degree of documentation
needed is dependent on the nature of the system, constituency (who
will use it), and life cycle costs. Software systems that are
used nationwide, Agencywide and support major program initiatives
require complete documentation and thoughtful consideration of
options, life cycle costs and mission needs.
Key points to consider are:
. A mission needs analysis and a requirements analysis which
includes feasibility and benefit-cost analyses must be
conducted prior to embarking on a major agency information
system development effort.
4-3
-------
EPA System Design & Development
Guidance: Volume C
EEIs are required for both' new sysi-prr^ and existin
. The EEI outlines contained in Appendix A of this volume
represent the basic EEI requirements (see section 4.2 1 for
the minimum EEI requirements for the different sizes and
types of systems) . Information managers may want to
increase the depth and breadth of these EEIs based on the
circumstances of the project. For example:
- Elements not included in a particular EEI outline that
are considered necessary within a specific project may
be added, thus tailoring the EEI for that specific
project.
- Additional EEIs may have to be developed to meet the
specific needs of a given software system or project.
4-2.1 Determining Dnrumentaf i on RgqnrrPtnpnl-g
Criteria for determining the minimum EEI documentation for a
specific software system are based on the nature and scope of the
information system and its importance to EPA's mission. Four
types of systems are presented below along with guidance for
determining the minimum level of EEI documentation for each:
a- Ma-ior Aaencv Information Syst-.Ptn; An information system
that requires special continuing management attention
because of its importance to an agency mission, its high
development, operating, or maintenance costs or its
significant impact on administration of agency programs.
In this context, a system which requires obligations of
more than $500,000 per year to maintain or whose software
component contains more than 500,000 lines of 3GL source
code or 100,000 lines of 4GL source code is considered a
Major Agency Information System.
Exhibit 4-1 presents the EEIs required for a Major Agency
Information System.
b- Widely Accessed Information System; An information systen
that is not a Major Agency Information System, (but
significantly supports accepted program goals and
missions) . It is widely accessed by a combination of EPA
Headquarters, Regional Offices and/or State and local
users and other Federal agencies.
Exhibit 4-1 also presents the EEIs required for a Widely
Accessed Information System.
4-4
-------
M
EEI REQUIREMENTS FOR MAJOR AGENCY AND WIDELY ACCESSED
INFORMATION SYSTEMS
UI*-Cyd«
BUgco
T««k* And
Activities
D •
o
u
n
1
1
1
n
R
S
V
1
r
en
n
1
(CEI3)
AwHU
«.„...
...-,...
System Design, Development and Implementation
System OMlgn
c^nx-.
Ptan(EtM)
Stfvl4*t) DtUultd
RWBUCMIMAto OodMWft
(EEISI
Ptan(EEI«)
"^"^"•"^
Funcdanri
pm»* Hrvtra
Pntknh^)
C— P^
' Dmgn Oocutwm
(EEltt
C>Uu<
B^T
Syatom Development
_ _ ^
AndtS^nnxkv
Oacuimnl(EEMO}
0««p«,EEM,,
B-^.rc.G^WMI,
Ftfictonftl Corrfi0ureMn
Ptiytic*! C«nl«uiiKn
R*MMf I
"T^r^r
Product
TMI. And ExhMlMi
&ftum Hcgmiaa
T*« Ftapau (EEHJ)
FuntteMl Con)«>»»on
Ptiyikil Canl«u»>on
l^zil:^
O^ndenl
System ImpUnnnteUon
jrn.
U»M Atopunc*
"^i.si^r'
Syttwn OMvbd
R*cjui*mnli Oacunvrt
(EEIS)
Satva* Mamgtnwn
PUn (EEI-4)
Sottov* Ocakd
OMQO Oocuiwrt (EEI-0)
Sattmti* Ualn*n*n»
Docunwrt (EEHO)
-.._ _^ .
Oocun*n](EEI-H)
FM*»n» Qub* (E E ^ 1 2)
Syiun Mvgmiien
T.M Hiponi (EEl-ll)
tn
g
n
td
n
H
a
(U (/>
t3 K
O W
(0 rt
< O
O (D
»-• W
c: H-
3 «0
0) D
n
o
(D
<
(D
H*
O
t)
(D
-------
EPA System Design & Development
Guidance: Volume C
c. Localized Information System: An information system that
is not a Major Agency Information System, but
significantly supports accepted program goals and
missions. It is accessed primarily by users in one major
area, e.g., EPA Headquarters, a single agency program, or
a Region.
Exhibit 4-2 presents the EEIs required for a Localized
Information System.
d. User Owned Information System: Unique, stand-alone
system developed to improve the efficiency or
effectiveness of operations for a single user or a small
group of users.
Exhibit 4-3 presents the EEIs required for a User Owned
Information System.
4.2.2 Software Life Cycle Reviews
Formal reviews are carried out at key points in the life cycle to
ensure that the software development activities are progressing
.consistent with user requirements and EPA standards. The reviews
used in the EPA System Development life cycle are described in
detail in Chapter 3.
4-6
-------
EEI REQUIREMENTS FOR LOCALIZED INFORMATION SYSTEMS
"S2T
a
Tutu And
AcllvllU*
O
•
c
u
n
1
1
1
n
H
q
u
i
i
n
1
(EEIS)
Av«lt
Navtaaa
...-,...
System Design, Development and Implementation
SyttMnDMlgn
_ n^^tod
MMp*M.M.AntflHb
Pun (E EM)
RwyjfMMOli OocuOKX
(EEl S|
8,— IJUj*— .
fundland
n>ltal* •l>r"ton
0.^X1
B.sr^L.
D^O^
SotlMM D«m»rt
«^x»
EE,
Sy.tWnDMtopnMnl
•.MM Pm*rrOnn
A^fSovwnmkv
DouMMrt lEEI-iq
SS^ST
Ritoiwic* Oud* (EEMfl
Fuwttxwl Cort«u»*an
s::r*""
itiii-n' — "--' —
Pratfud
Tm. And EraluMlaa
8yM..kMV.t«>«
Fuictewl Cortigmton
ct±ST^T'
Opcndonl
SyttMn ImptomsntotJon
^TL,
O-.A.-f^nc.
Ifckttunc*,
AndE»h*Uim
(EEISI
&<*>«>• OlUted
OM«I< Oocuiwit (EEI4)
S^lw0 U^rtwncc
OocuawnKEEMO)
6a*vu* Opvabn*
OocuiMrt(EEI-ll)
GaftMicUM^
IWw*raa QUKU (EE»- 12)
Syiun M*g»uon
CD
H
I '
o tn
c »u
cu in
3K
O w
(I) rt
• • fl)
3
< O
O 0)
I— W
c: H-
3 iQ
o> D
O
O
0)
n>
(D
-------
EEI REQUIREMENTS FOR USER OWNED INFORMATION SYSTEMS
I
OQ
Uto-Cyd*
Sl.0..
Ttak. And
AcllvllU.
0
u
o
l
1
1
n
R
y
I
m
a
1
(GEI8)
...
System Design. Development and Implementation
System D*«10n
^rr^u
nM^MMntfita Oocunwrt
!££)•&)
"^^T"*
^*- ^^
oXr^L
Pratfenkwy
OvUgn ffciMtn*
0—0^
OMign OocuiMnl
(EEII)
Oklut
Bo« Acctptwic*
TS^r
S^«.0-^d
(EEIS)
SaMnra OitaiMt
Owen Oacvnwi* (EEW)
Dacumn(EEt-n)
SJ^.'^.ffEMfl
I
U)
O PI
C 13
H->
O.
(U (^
3 *<
O W
(I> rt
< O
O (D
H- W
C H-
3 «£!
01 3
O
O
(D
o
•d
3
fl>
D
rt
-------
SPA System Design & Development
Guidance: Volume C
5. SOFTWARE DEVELOPMENT STANDARDS
This chapter addresses the software development standards
that have been approved for use in the development of EPA
information systems. They include standard 3rd and 4th generation
programming languages, data base management systems, core system
standards, specialized software tools, graphics packages and
telecommunications support software.
5.1 STANDARD PROGRAMMING LANGUAGES
EPA standard programming languages have been established for
use in developing software systems for use within EPA. These
include the 3rd generation programming languages that have been
standardized by the American National Standards Institute as
national standards and by the Institute for Computer Science and
Technology of the National Bureau of Standards as Federal
Information Processing Standards.
In addition, EPA has internally standardized several 4th
generation programming languages in the interest of improving
productivity and reducing the cost of software development and
maintenance within the agency. Exhibit 5-1 presents the standard
programming languages used within EPA.
5.1.1 Programming Language Selection Guidelines
A number of factors go into deciding what computer
environment in which an application will operate. After the
computer hardware configuration has been identified, the
application programming language and associated support software
tools must be selected. While there is no "right" answer for each
information system being developed, the use of common sense and
the guidelines presented in this volume can lead to a reasonable
solution.
Software developers should consider the following questions:
. Is an off-the-shelf solution available?
. Has OIRM staff advice been solicited?
. Is the application covered by an existing Core System?
. Can the application be satisfied by'using an existing
system or" its software (e.g., software reuse, off-the-shelf
software, consulting the EPA Information System Inventory)?
5-1
-------
EPA System Design & Development
Guidance: Volume C
EXHIBIT 5-1
EPA STANDARD APPLICATION PROGRAMMING LANGUAGES
APPLICATION SOFTWARE
PROGRAMMING LANGUAGE
3GL
4GL
COBOL
FORTRAN
PL/I
PASCAL
INFO
NATURAL
FOCUS
dBASE III
SAS
STANDARD
EPA
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
FIPS
Yes
Yes
Yes
Yes
5-2
-------
EPA System Design & Development
Guidance: Volume C
Some of the factors which should be addressed when
determining the hardware/software environment are:
. Results of the requirement and feasibility studies
. Potential life span of the application
. Resources available now and in the future to support both
the development and maintenance of the application
. Telecommunications and local communications facilities
. Location and size of the data base(s)
. Number of users / Number of simultaneous users
. Complexity of the data
. Information security needs such as access controls, backup,
and recovery.
In an attempt to reduce the complexity of this effort, EPA
has defined the computer hardware/software environments available
for use. As a guideline, a decision matrix approach to
identifying what software support tools are appropriate has been
defined.
The decision matrices can be used to help determine the
support tools appropriate to system development in the absence of
OIRM staff guidance. The matrices apply only to the general
systems which store and retrieve information and should not be
construed as taking precedence over existing EPA system plans,
strategies and policies. Also they do not encompass statistical
systems, spread sheet systems, graphics systems and other
specialized functional systems. With minor exceptions, they do
not address hybrid systems - those which are developed using two
or more support tools (e.g., Natural/VSAM for data entry and
Natural/ADABAS for data retrieval).
The Software Support Tool Selection Matrices address systems
that are small, medium, and large.
. Small Systems - are generally programmed using 4GLs with or
without data base support, and they can run in either the
mainframe, minicomputer or microcomputer environments;
. Medium Systems - are generally programmed using either 3GLs
or 4GLs with or without data base support, and they can run
in either the mainframe or minicomputer environments and;
5-3
-------
EPA System Design & Development
Guidance: Volume C
. Large Systems - are generally programmed using either 3GLs
or 4GLs with or without data base support, and they run in
the mainframe environment.
The content of each matrix cell and the criteria of small,
medium and large systems are simplified to make them useful
There are several decision criteria along the legs of the matrices
and numbers in the intersections of the rows and columns which
correspond to the software support tools. The key for the
software support tools is:
1 - Mainframe 3GL/DBMS (COBOL, PL/I, FORTRAN)
2 - Mainframe 4GL/DBMS (Natural/ADABAS)
3 - Mainframe 4GL (FOCUS)
4 - Mainframe 4GL (NATURAL/VSAM)
5 - Minicomputer 3GL (COBOL, FORTRAN, PASCAL)
6 - Minicomputer 4GL (FOCUS, INFO)
7 - Microcomputer 4GL (INFO, FOCUS, dBASE III)
8 - Microcomputer 4GL/DBMS (dBASE III)
9 - Microcomputer 3GL (FORTRAN, PASCAL)
Exhibits 5-2, 5-3, and 5-4, on the following pages, present the
Software Support Tool Selection Matrices.
5.1.2 Source Program D^icm and Coding Conventions
EPA has a general set of minimum program design and program
coding standards which can be obtained from OIRM or office SIRMOs
These standards promote productivity, source code maintainability
and software sharing and reuse. These standards are patterned
after the standards used by the Department of Defense. The
salient characteristics of these standards are:
. Use of structured programming constructs to control the
flow of execution
. Elimination or significant reduction in the use of "GO TO"
statements and complicated negative Boolean expressions
. Applicability to 3GL and 4GL programming
. Modularity in source program design and coding
. Good documentation practices such as:
- Naming conventions
- Symbolic parameters
- Paragraphing
- Blocking
5-4
-------
EPA System Design & Development
Guidance: Volume C
EXHIBIT 5-2
SOFTWARE SUPPORT TOOL SELECTION MATRIX
SMALL SYSTEMS
NOTES:
1 - Mainframe
2 - Mainframe
3 - Mainframe
4 - Mainframe
3GL/OBMS (COBOL. PU1. FORTRAN)
4GL/OBMS (Natural/ADABAS)
4GL (FOCUS)
4GL (Natural/VSAM)
5 - Minicomputer 3GL
6 - Minicomputer 4GL
(COBOL FORTRAN. Pascal)
(FOCUS. INFO)
7 - Microcomputer 4GL (INFO. FOCUS. dBASE III)
8 - Microcomputer 4GUD8MS (dBASE III)
9 - Microcomputer 3GL (FORTRAN. Pascal)
SMALL SYSTEMS - « RECORDS < 10K OR TOTAL SIZE < 10 MEGABYTES |
Number of Simultaneous Users
Complex Random Retrievals?
Location
of Related
Data
None
Main-
Frame
Mini-
Computer
PC
1
YES
2.3,6.7
2.3
•
7,8.9
NO
2.3,4,6.7
2,3.4
6
7,8.9
1 15
YES
'
2
2
2
NO I
2.3.4 i
2.3.4 \
2.3.4 |
2.3.4 |
5-5
-------
EPA System Design & Development
Guidance: Volume C
EXHIBIT 5-3
SOFTWARE SUPPORT TOOL SELECTION MATRIX
MEDIUM SYSTEMS
kCDUU SYSTEM - 10K <
Volatility
Number of
Simultaneous Users
Complex Random
Retrievals?
Location
of Related
Data
None
Mini-
Computer
Main-
Frame
• RECORDS «100K OR 10 ICOABYTE9 « TOTAL SOE < 100 KGOABYTES :
Moderate Amount
at Cnanot per Day
$15
YES
2.3,6
6
2,3
NO
2.3,
4,6
6
2.3.4
>
YES
2
2
2
'•
NO
2.4
"
2.4
Volatile
£15 >15
YES NO YES NO
Highly |
Volatile \
£15 >15 ;
YES
2.6 2,3, 2,3 ! 2.4 1.2.
4.6 j 5,6
5.6 5.6 2.3 j 2,4 5.6
2 2,3,4 2.3 I 2.4
| |
1.2
,;
NO YES NO :
j
1.2. 1.2. 1.2 :i
5.6 5,6 :
5.6 1.2 1.2 :
1.2 1.2 1.2 ;
::
NOTES:
1 - Mainframe
2 - Mainframe
3 - Mainframe
4 - Mainframe
5 - Minicomputer
6 - Minicomputer
3GUO8MS (COBOL PU1. FORTRAN)
4GL/08MS (Natural/AOABAS)
4GL (FOCUS)
4GL (Natural/VSAM)
3GL (COBOL FORTRAN, Pascal)
4GL (FOCUS, INFO)
5-6
-------
EPA System Design & Development
Guidance: Volume C
EXHIBIT 5-4
SOFTWARE SUPPORT TOOL SELECTION MATRIX
LARGE SYSTEMS
LARGE SYSTEMS - • RECORDS
Volatility
Number of
Simultaneous Users
Complex Random
Retrievals?
File
Pass
Frequency .
n-1
per day
1 40
per day
> 100K OR TOTAL SIZE
Almost Staflc
(Update Weekly or Less)
S15
YES NO
2.3 2.3.4
2 2.4
Hybrid 4
1.2
,„
YES NO
2 i 2.4
2 I 2,4
Hybrid i 4
1.2 ';
> 100 MEGABYTES
Moderate Amount of
Change or Volatile
£15
YES
„»
NO
2 2.4
2
Hybrid
1.2
2.4
4
Highly i
Volatile i
S15 >15 ' 1
YES NO I
1.2 1,2 :
1.2- 1.2 I
Hybrid Hybrid i
1.2 1.2 I
NOTES:
1 - Mainframe
2 - Mainframe
3 - Mainframe
4 - Mainframe
3G I/DBMS
4GUDBMS
4GL
4GL
(COBOL. PL/1, FORTRAN)
(NaturaVADABAS)
(FOCUS)
(NaturaWSAM)
5-7
-------
EPA System Design & Development
Guidance: Volume C
- Indentation of source code
- Single statement per line
- Intelligent use of comments
- Error messages
The program design and source programming standards are
maintained and updated by OIRM and are held by office SIRMOs.
5.2 CORE SYSTEM STANDARDS
EPA's Office of Information Resources Management has
developed an important set of software engineering standards in
response to the growing concern for custom software development on
small and/or localized systems (personal computers and
minicomputers). In an effort to avoid the costly duplication of
application development, OIRM is developing a generic set of core
systems which include:
. Project Tracking
. Correspondence Control
. Bibliographic Retrieval
. Mailing List and Label Generation
. Travel Management
. Forms Generation
. Personnel Tracking.
As other core systems are developed, they will be made available
through the EPA System Design and Development Guidance.
An outgrowth of this effort was the development of core
system standards for the development of core systems for. EPA
microcomputers (IBM Personal Computers) and minicomputers (Prime
2250, 2550, and 2665 minicomputers). The objectives for a
standardized design for core systems are to:
. Provide clarity and consistency between core system
applications
. Identify functional commonalities between core system
applications
. Reduce the costs of similar one time development efforts
through the availability of common software
. Provide the basis for the modular development of a System
Builder for core systems.
The standards that have been developed and are included in the
Software Engineering Program are:
. End-User Interface
. Software Engineering
5-8
-------
SPA System Design & Development
Guidance: Volume C
. Data Interchange
. User Documentation.
These standards must be followed by developers of small systems —
e.g., those produced for use on minicomputers and microcomputers.
The'core System Standards can be obtained from OIRM or office
SIRMOs.
5.3 FPA STANDARD SPECIALIZED SOFTWARE TOOLS
The EPA has a number of specialized tools for use on its
various computer hardware configurations. The standard specialized
software packages that have been approved for use in the
development of EPA software systems are presented in Exhibit 5-5.
For detailed information on current software development standards
contact OIRM or office SIRMOs.
5.4 HARDWARE/SOFTWARE ENVIRONMENTAL STANDARDS
The EPA standard hardware/software environments available for
software development are presented in Exhibit 5-6. This exhibit
identifies the EPA standard software packages that are available
and the hardware environments in which each of the software
packages is supported. Any software development effort which uses
software packages or hardware outside the EPA Hardware/Software
Environment Standards must have approval from the Director, Office
of Information Resources Management (OIRM).
5-9
-------
EPA System Design & Development
Guidance: Volume C
EXHIBIT 5-5
EPA STANDARD SPECIALIZED SOFTWARE TOOLS
FUNCTION
Data Base
Management
Graphics
Geographies
i
Spreadsheet
Word Processing j
i
I
Text Processing j
and Retrieval i
Programmer Tools j
Software j
Maintenance Tools i
Communications i
Software i
TOOL INTEGRATED
WITH
ADABAS NATURAL
dBASE III
SASGRAPH SAS
TELAGRAPH
VERSAGRAPH INFO
ARC/INFO INFO
UNIRAS
LOTUS 1-2-3
20/20
MEGACALC
LEXITRON
LEXITYPE
WORDSTAR
MULTI-MATE .
TEXT
WORD MARC INFO-TEXT
BASIS
INFO-TEXT INFO
ATMS
ISPF
EMACS
LIBRARIAN i
COBOL DEBUGGERS !
PUI DEBUGGERS I
SNA i
DECNET i
PRIMENET |
GNETII !
PRIMELINK i PRIME/PC Connection
CROSSTALK i
KERMIT i
1
|
:il
:'!:*
1
1
i
i
if
:
i
ji
|
]
:j
|
1
• i
:)
|
j
1
i
,-»
i
|
1
^
j
4
I
5-10
-------
EPA System Design & Development
Guidance: Volume C
EXHIBIT 5"-6
EPA - Agency Standard Hardware/Software
TOOLS
3rd Generation:
COBOL
FORTRAN
PL/1
PASCAL
4th Generation:
INFO
FOCUS
NATURAL
SAS
dBASE III Plu<
Easytrieve Plus
Data Base Management
AOABAS
Graphics Facilities
TELL-A-GRAPH/ Cuechart
VERSAGRAPH
SASGRAPH
Spreadsheet
LOTUS 1-2-3
20/20
MEGACALC
SAS/FSP
Geographies
ARC/INFO (Pilot)
UNIRAS (Pilot)
TARGET HARDWARE ENVIRONMENT
IBM 3090 1
£ i
BM43XX
DEC/VAX
PRIME
IBM/PC
•
9 ^ ^ i ^*
•
•
* 1
•
• •
_ A A *
•
9 ™ i ™
• i
1
i
1
•
• 1
• j
•
• ! j I 1
•
•
•
•
• •
_
•
• 1
— • i
•
]
•
1
!
i •
I
_i i :'
! i »
5-11
-------
EPA System Design & Development
Guidance: Volume C
EXHIBIT 5-6 (Continued)
EPA - Agency Standard Hardware/Software
TOOLS
Word and Taxt Software
LEXfTRON WP DEVICE
LEXfTYPE
WORDSTAR
MULTI-MATE
WORD PERFECT
WOROMARC
Displaywrit04
BASIS
TEXTWP
INFO-TEXT
Project Management
ToU-A-Plan
MtefOBOd Projwa
Talacom Capabllltlas
SNA
AS YNCH ASCII
HASP
X25
PRIMENET
OECNET
CROSSTALK
KERMfT
GNETII
PRIMELINK
NATURAL/CONNECTION
SAS/RInk Rltrm
3270 PC FH» Transfer
Electronic Mail
OIALCOM SERVICE
Local Capability
Programmmar Productivity
Alda/FacllWas
ISPF
LIBRARIAN
EMACS
COBOL DEBUGGER
Fortran/ DEBUGGER
EVE/TPU
TARGET HARDWARE ENVIRONMENT |
IBM 3090
IBM 43XX DEC/VAX PRIME IBM/PC
•
•
• ;
• s
• 1
• ;
• \
• \
I
• I
• i
• i 1 !
j I i • i
•
•
•
•
•
•
•
• • •
• • 1
m • ;
• 1
• • ;
• j
• • • i
• I
• • :
I * 1
• i
• i • " '-9 1
|
• • I
•
•
•
•
•
•
i
••'
• • i
• 5
5-12
-------
EPA System Design & Development
Guidance: Volume C
6. SUMMARY
6.1 SYSTEM DESIGN. DEVELOPMENT AND IMPLEMENTATION OUTPUTS
The outputs, documents and results of the System Design,
Development and Implementation process are as follows:
. EEI-4, System Implementation Plan*
. EEI-5, System Detailed Requirements Document
. EEI-6, Software Management Plan
. EEI-7, Software Test and Acceptance Plan*
. EEI-8, Software Preliminary Design Document*
. EEI-9, Software Detailed Design Document*
. EEI-10, Software Maintenance Document
. EEI-11, Software Operations Document
. EEI-12, Software User's Reference Guide
. EEI-13, System Integration Test Reports*
. Working, tested and user accepted automated or partially
automated solution to the problem
. Established Configuration Management or change control
procedures
* Note: These EEI requirements are the basic requirements for User
Owned Systems that DO NOT involve OIRM.
6.2 NEXT STEPS
After the user has accepted the application system it begins
the transition to the operation and maintenance phase of the
system life cycle. The application specific guidelines for
conducting this phase are outlined in the Software Maintenance
Document, EEI-10, which is required for all systems. The key
elements during the maintenance phase of the life cycle are
planning, analysis, preparation, improvement and implementation.
[Guidance concerning the Maintenance and Operation phase of
the software life cycle will be released under a separate
cover.]
6-1
-------
EPA System Design & Development
Guidance: Volume C
APPENDIX A
ESSENTIAL ELEMENTS OF INFORMATION
-------
EPA System Design & Development
Guidance: Volume C
APPENDIX A
ESSENTIAL ELEMENTS OF INFORMATION
A. FSSKNTTAL ELEMENTS OF INFORMATION
This appendix provides representative outlines of each of the
system-level documents that will be developed during the system
design, development and implementation phase.
A.I INTRODUCTION
The documentation requirements contained in this appendix
apply to all software .development projects, regardless of size,
complexity or origin — except as noted in subsection 4.2.1,
"Determining Documentation Requirements" in Chapter 4 of this
Volume. At a minimum, these standards apply to all new software
development projects. Maintenance and/or enhancements to existing
information systems must comply with the requirements set out in
Chapter 1, section 1.5 of Volume C, System Design, Development and
Implementation.
Compliance with the standards and conventions provided in
this appendix will ensure that adequate documentation is produced
for all system development projects.
The documents defined in this appendix are:
EEI-4 • • System Implementation Plan
EEI-5 • • System Detailed Requirements Document
EEI-6 • • Software Management Plan
EEI-7 • • Software Test and Acceptance Plan
EEI-8 • • Software Preliminary Design Document
EEI-9 • • Software Detailed Design Document
EEI-10 • • Software Maintenance Document
EEI-11 • • Software Operations Document
EEI-12 • • Software User's Reference Guide
EEI-13 • • System Integration Test Reports
When an asterisk or alphanumeric appears within a section
number in the outlines, it represents a repetition of the element
as many times as necessary to define multiple iterations of the
element.
The following milestone chart illustrates the relative
initiation and completion of each document with respect to the
software development life cycle, its major phases, and the span
and scope of Volumes A, B, and C.
A-l
-------
DOCUMENTATION VERSUS LIFE CYCLE
>
Mission Needs Analysis
EEI-1
Preliminary Design/
Options Analysis
EEI-2
EEI-3
System Detailed
Requirements Analysis
EEI-4
EEI-5
EEI-6
Preliminary Design
EEI-7
EEI-8
Detailed Design
EEI-9
System Production
and Programming
EEI-10
EEI-11
EEI-12
System Integration
Testing & Evaluation
EEI-13
System Installation
Qtitom Operations &
itenance
Volume B
Volume C
System Preliminary Critical
Requirement Design Design
Review Review Review
(U
D
DT&E
Review
OTAE
Review
A
User
Acceptance
J
O w
(D ft
O (ft
t-> w
o
<
§
-------
EPA System Design & Development
Guidance: Volume C
EEI-4 SYSTEM IMPLEMENTATION PLAN
1. INTRODUCTION
1.1 Purpose
1.2 Background
1.3 Scope
1.4 System References
1.5 Terms and Abbreviations
1.6 Organization of This Document
2. REFERENCED DOCUMENTS
2.1 Government Documents
2.2 Non-government Documents
3. IMPLEMENTATION PLAN
3.1 Plan Management
3.1.1 Policy Events and Actions
3.1.2 Program Management
3.1.3 Strategy for Acquiring Information/Data
3.1.3.1 Information- Collection
3.1.3.2 Forms
3.1.3.3 Clearance
3.1.4 Strategy for Integrating with other EPA
Information
3.1.4.1 Environmental Data
3.1.4.2 Administrative Data
3.1.5 Access Policy and Standards
3.1.6 Assessment of Existing Hardware/Software
Alternatives
3.1.6.1 EPA
3.1.6.2 Other Government Agencies
3.1.6.3 Commercial Vendors
3.1.7 Information Systems
3.1.7.1 Automated
3.1.7.2 Manual
3.1.8 Process and Procedure
A-3
-------
EPA System Design & Development
Guidance: Volume C
EEI-4 SYSTEM IMPLEMENTATION PLAN (Continued)
3.2 Work Plans and Schedules
3.3 Resource Requirements
3.3.1 Contractor
3.3.2 Personnel
3.3.3 Facilities
3.3.4 Government Furnished Property
3.4 Integrated Project Plan
4. NOTES
5. APPENDICES
6. GLOSSARY
A-4
-------
EPA System Design & Development
Guidance: Volume C
EEI-5 SYSTEM DETAILED REQUIREMENTS DOCUMENT
1. INTRODUCTION
1.1 Purpose
1.2 Background
1.3 Scope
1.4 System References
1.5 Terms and Abbreviations
1.6 Organization of This Document
2. REFERENCED DOCUMENTS
2.1 Government Documents
2.2 Non-government Documents
3. DETAILED CHARACTERISTICS AND REQUIREMENTS
3.1 System Definition Requirements
3.1.1 System Purpose
3.1.2 Concept of Operation
3.1.3 System Sizing and Timing Requirements
3.1.4 Design Standards
3.1.5 Design Constraints
3.1.6 Data Requirements
3.2 Subsystem Definition Requirements
3.2.1 Subsystem #1
3.2.1.1 Subsystem #1 Purpose/Definition
3.2.1.2 Subsystem #1 Interface Definition
3.2.1.2.1 Network
3.2.1.2.2 Software Systems
3.2.1.2.3 Data Base
3.2.1.2.4 Entity Relationships
3.2.1.3 Assumptions and Constraints
3.2.1.4 Subsystem #1 Level II Requirement 1
3.2.1.4.1 Level II Requirement 1 Description
3.2.1.4.1.1 Level III Detailed Functional Requireme:
A-5
-------
EPA System Design & Development
Guidance: Volume C
EEI-5 SYSTEM DETAILED REQUIREMENTS DOCUMENT (Continued)
3.2.1.4.1.1.1 Title and Description Of Level III
Function 1
3.2.1.4.1.1.N Title and Description Of Level III
Function N
3.2.1.4.1.n Level III Requirement n Description
3.2.1.4.m Level II Requirement m Description
3.2.M Subsystem IM
3.3 System Physical Requirements
3.3.1 HVAC and Electrical Requirements
3.3.2 Facilities Management
3.3.3 Computer Hardware Requirements
3.3.4 Computer Operating System Requirements
3.3.5 Software Utilities and Tools
3.4 System Security Requirements
3.4.1 System Backup Procedures
3.4.2 Review/Activity Log Files
3.4.3 Disaster Recovery Procedures
3.5 Quality Requirements
3.5.1 Reliability
3.5.2 Maintainability
3.5.3 Flexibility and Expansion
3.5.4 Transportability
3.6 Life Cycle Requirements
3.6.1- Software Maintenance Personnel
3.6.2 User Support and Training
3.6.3 Hardware and Supplies
4. Testing and Verification Requirements
4.1 Testing Requirements
4.1.1 Method
4.1.2 Responsibility
A-6
-------
EPA System Design & Development
Guidance: Volume C
EEI-5 SYSTEM DETAILED REQUIREMENTS DOCUMENT (Continued)
5. Project Schedules and Work Plans
5.1 Schedules
5.2 Work Plan
5.2.1 Personnel
5.2.2 Milestones
5.2.3 Budget
6. NOTES
7. APPENDICES
8. GLOSSARY
A-7
-------
EPA System Design & Development
Guidance: Volume C
EEI-6 SOFTWARE MANAGEMENT PLAN
1. INTRODUCTION
1.1 Purpose
1.2 Background
1.3 Scope
1.4 System References
1.5 Terms and Abbreviations
1.6 Organization of This Document
2. REFERENCED DOCUMENTS
2.1 Government Documents
2.2 Non-government Documents
3. PLANNING
3.1 Project Resources
3.1.1 Contractor Facilities
3.1.2 Government Furnished Equipment, Software and
Services
3.1.3 Personnel
3.1.4 Organizations Responsible for Design,
Implementation, Configuration Management,
Reliability and Quality Assurance
3.2 Review Responsibilities
3.3 Software Development
3.3.1 Organization Structure
3.3.2 Personnel
3.3.3 Resources
3.3.4 Software Development Tools, Techniques,
Methodologies and Standards
3.3.5 Manual Procedures/Forms
4. MANAGEMENT CONTROLS
4.1 Project Schedule, Reviews and Report Controls
4.1.1 Work Plan
4.1.2 Activity Network and Dependencies
4.1.3 Risk Areas
A-8
-------
EPA System Design & Development
Guidance: Volume C
LEI-6 SOFTWARE MANAGEMENT PLAN (Continued)
4.2 Risk Management
4.1.1 New Technologies
4.1.2 Backup - Recovery
4.1.3 Manual Procedures/Forms
5. SOFTWARE PRODUCT ASSURANCE
5.1 Software Configuration Management
5.2 Software Independent Verification and Validation
5.3 Software Security
5.4 Software Reliability and Quality Control
5.5 Software Interface Definition
5.6 Software Waivers to Policy and Procedures
5.6.1 Permanent Waivers
5.6.2 Temporary Waivers
5.6.3 Tools and Standards Waivers
5.7 Data Administration
5.8 Quality Assurance
5.8.1 Program Monitoring
5.8.2 Quality Reviews
5.8.3 Reporting and Control
5.8.4 Reviews
5.8.4.1 System Requirements Reviews
5.8.4.2 Preliminary Design Review
5.8.4.3 Critical Design Review
5.8.4.4 Code Reviews
5.8.4.5 Development Test and Evaluation Review
5.8.4.6 Operational Test and Evaluation Review
5.9 Testing
5.9.1 Software Test Plan
5.9.2 Software Test Description
5.9.3 Software Test Procedures
5.9.4 Conducting the Software Test
5.9.5 Software Test Reports
A-9
-------
EPA System Design & Development
Guidance: Volume C
EEI-6 SOFTWARE MANAGEMENT PLAN (Continued)
7.
8.
9.
SOFTWARE DEVELOPMENT PROCEDURES
6.1 Software Standards and Procedures
6.1.1 Software Tools
6.1.2 Commercial and Reusable Software
6.1.2.1 Data Rights and Documentation
6.1.2.2 Certification
6.1.3 Software Test Tools
6.1.4 Software Design
6.1.4.1 Software Design Methodology
6.1.4.2 Programming Language
6.1.4.2 Interface Methodology
6.1.4.4 Network Methodology
6.1.5 Software Design and Coding Standards
6.1.6 Firmware
6.2 Software Configuration Management
6.2.1 Configuration Identification
6.2.1.1 Documentation Baselines
6.2.1.2 Methods and Approach to Standards
Implementation
6.2.2 Configuration Control
6.2.2.1 Configuration Control Flow Chart
6.2.2.2 Forms
6.2.2.3 Storage and Release of Master Copies
6.2.3 Configuration Reviews
NOTES
APPENDICES
GLOSSARY
A-10
-------
EPA System Design & Development
Guidance: Volume C
EEI-7 SOFTWARE TEST AND ACCEPTANCE PLAN
1. INTRODUCTION
1.1 Purpose
1.2 Background
1.3 Scope
1.4 System References
1.5 Terms and Abbreviations
1.6 Organization of This Document
2. REFERENCED DOCUMENTS
2.1 Government Documents
2.2 Non-government Documents
3. LIMITATIONS/TRACEABILITY
3.1 Limitations
3.2 Traceability
4. TEST PLANS
4.1. Software Unit Testing (includes Manual Procedures)
4.1.1 Test Requirements
4.1.2 Test Management
4.1.2.1 Integration Test Team Organization
and Responsibility
4.1.2.2 Responsibilities of Other
Organizations
4.1.2.3 Product Control
4.1.2.4 Test Control
4.1.2.5 Evaluation and Retest Criteria
4.1.2.6 Test Reporting
4.1.2.7 Test Review
4.1.2.8 Test Identification
4.1.2.9 Test Data Environment
4.1.3 Test Schedule
4.1.4 Test Results
A-ll
-------
EPA System Design & Development
Guidance: Volume C
EEI-7 SOFTWARE TEST AND ACCEPTANCE PLAN (Continued)
4.2 Integration Testing of Software Units, Modules and
Software Functions/Risk Management
4.2.1 Integration Test Requirements
4.2.2 Integration Test Management
4.2.3 Integration Test Categories
4.2.4 Integration Test Methods
4.2.5 Integration Test Schedules
4.2.6 Integration Test Results
4.2.6.* (Insert Name) Integration Test
4.3 Required Resources
4.3.1 Facilities
4.3.2 Hardware
4.3.3 Interface/Support Software
4.3.4 Personnel
4.4 System Test
4.4.1 System Test Requirements
4.4.2 System Test Management
4.4.3 System Test Categories
4.4.4 System Test Methods
4.4.5 System Test Schedules
4.4.6 System Test Results
5. USER ACCEPTANCE
5.1 Test Team
5.2 Pretest Preparations
5.2.1 Development of Test Scenarios and Test Data
5.2.2 Development of Predicted Results
5.2.3 Development of Acceptance Procedures
5.3 Test Execution
5.3.1 Data Analysis
5.3.2 Test Evaluation
5.3.3 Problem Report and Problem Resolution Process
A-12
-------
EPA System Design & Development
Guidance: Volume C
EEI-7 SOFTWARE TEST AND ACCEPTANCE PLAN (Continued)
5.4 Formal Acceptance
5.4.1 Test Report
5.4.1.1 Detailed Test History
5.4.1.2 Detailed Test Results
5.4.1.2.* (Insert Test Name) Test
Results
6. NOTES
7. APPENDICES
8. GLOSSARY
A-13
-------
EPA System Design & Development
Guidance: Volume C
EEI-8 SOFTWARE PRELIMINARY DESIGN DOCUMENT
1. INTRODUCTION
1.1 Purpose
1.2 Background
1.3 Scope
1.4 System References
1.5 Terms and Abbreviations
1.6 Organization of This Document
2. REFERENCED DOCUMENTS
2.1 Government Documents
2.2 Non-government Documents
3. SOFTWARE DESIGN REQUIREMENTS (SDR)
3.1 Concepts
3.2 Functional Flow
3.n (Insert Name) Requirement
3.*.1 Description of Requirements and Associated
Software Design Functions (SDFs), including
Manual Procedures
4. SOFTWARE DESIGN FUNCTION (SDF)
4.* (Insert Name) Function
4.*.1 Inputs
4.*.2 Local Data
4.*.3 Initiation, Timing and Sequencing
4.*.4 Interrupts
4.*.5 Processing
4.*. 5.1 Algorithms
4.*.5.2 Error Handling
4.*.5.3 Test Structures
4.*.6 Outputs
4.*.7 Adaption
A-14
-------
ZPA System Design & Development
Guidance: Volume C
EEI-8 SOFTWARE PRELIMINARY DESIGN DOCUMENT (Continued)
5. DATA BASE DESIGN
5.1 Data Base Management System
5.2 Data Structure (Logical Design)1
5.3 Interrelationships
5.4 Design Characteristic/Requirements Traceability
5.5 Physical Design (EEI-8)1
6. NOTES
7. APPENDICES
8. GLOSSARY
For ADABAS refer to EPA/NCC ADABAS Application Development
Procedures Manual for CDBA requirements.
A-15
-------
EPA System Design & Development
Guidance: Volume C
EEI-9 SOFTWARE DETAILED DESIGN DOCUMENT
INTRODUCTION
1.1 Purpose
1.2 Background
1.3 Scope
1.4 System References
1.5 Terms and Abbreviations
1.6 Organization of This Document
REFERENCED DOCUMENTS
2.1 Government Documents
2.2 Non-government Documents
SOFTWARE FUNCTION REQUIREMENTS (SFR)
3.1 SFR External Interfaces (including Manual Procedures)
3.1.* (Insert Name) Interfacer
3.1.*.* (Insert Name) Software Unit (SU)
DETAIL DESIGN
4.* (Insert Name) SFR
4.*.1 SFR Inputs
4.*. 2 SFR Local Data
4.*.3 SFR Processing
.3.1 Control
4
4
4
.3.2 .Algorithms
.3.3 Error Handling
.3.4 Data Conversion
.3.5 Test Structures
.3.6 Manual Procedures
4.*.4 SFR Outputs
4.*.5 SFR Decomposition
A-16
-------
EPA System Design & Development
Guidance: Volume C
EEI-9 SOFTWARE DETAILED DESIGN DOCUMENT (Continued)
4.*.5.* (Insert Name) Software Unit (SU)
4.*.5.*.1 SU Formal Parameters
4.*.5.*.2 SU Inputs
4.*.5.*.3 SU Local Data
4.*.5.*.4 SU Processing
4.*.5.*.5 SU Outputs
4.*.5.*.6 SU Limitations
4.*.5.*.7 Use of Other Elements
4.*.5.*.8 Manual Procedures
5. DATA BASE DESIGN (If Applicable)
5.1 Data Base Management System
5.2 Data Structure (Logical Design)1
5.3 Interrelationships
5.4 Design Characteristic/Retirements Traceability
5.5 Physical Design1
5.5.* File (Insert Name)
5.5.*.* Record (Insert Name)
5.5.*.*.* Field (Insert Name)
5.5.*.*.*.* Item (Insert Name)
6. NOTES
7. APPENDICES
8. GLOSSARY
For ADABAS refer to EPA/NCC ADABAS Application Development
Procedures Manual for CDBA retirements.
A-17
-------
EPA System Design & Development
Guidance: Volume C
EEI-10 SOFTWARE MAINTENANCE DOCUMENT
1. INTRODUCTION
1.1 Purpose
1.2 Background
1.3 Scope
1.4 System References
1.5 Terms and Abbreviations
1.6 Organization of This Document
2. REFERENCED DOCUMENTS
2.1 Government Documents
2.2 Non-government Documents
3. MAINTENANCE PROCEDURES
3.1 Source Code Standards
3.2 Documentation Update (including non-software elements)
3.3 Coding and Review Process
3.3.1 Top Down Approach
3.3.2 Peer Review
3.3.3 Walkthrough
3.3.4 Team Leader Review
3.4 Change Control Process
3.4.1 Change Request
3.4.2 Code Review
3.4.3 Review and Approval
3.4.3.1 Maintainer
3.4.3.2 User
3.5 Testing Standards and Procedures
3.5.1 Test Plans
3.5.2 Test Data
3.5.3 Test Scenarios
3.5.4 Test Results
3.6 Change Implementation Methods
3.6.1 Test to Production Method
A-18
-------
EPA System Design & Development
Guidance: Volume C
EEI-10 SOFTWARE MAINTENANCE DOCUMENT (Continued)
4. MAINTENANCE TOOLS
4.1 Technical Tools
4.1.1 Processing Tools
4.1.1.1 Compilers
4.1.1.2 Cross Reference
4.1.1.3 File Comparator
4.1.1.4 Traces/Dumps
4.1.1.5 Test Data Generator
4.1.1.6 Test Coverage Analyzer
4.1.1.7 Preprocessor
4.1.1.8 Verification/Validation
4.1.2 Clerical Tools
4.1.2.1 On-line Editor
4.1.2.2 Documentation Library
4.1.2.3 Archival Processor
4.1.2.4 Source Code Reformatter
4.1.2.5 Data Dictionary
4.2 Management Tools
4.2.1 Problem Reporting
4.2.2 Status Reporting
4.2.3 Scheduling
4.2.4 Configuration Management
5. SOURCE CODE
5.* (Insert Software Unit Name) Source Listing
6. NOTES
7. APPENDICES
8. GLOSSARY
A-19
-------
EPA System Design & Development
Guidance: Volume C
EEI-11 SOFTWARE OPERATIONS DOCUMENT
1. INTRODUCTION
1.1 Purpose
1.2 Background
1.3 Scope
1.4 System References
1.5 Terms and Abbreviations
1.6 Organization of This Document
2. REFERENCED DOCUMENTS
2.1 Government Documents
2.2 Non-government Documents
3. OPERATIONS
3.1 System Initialization
3.2 System Restart
3.2.* (Insert Name) Function
3.2.*.l Execution
3.2.*. 2 Inputs
3.2.*.2.1 User Inputs
3.2.*.2.2 System Inputs
3.2.*.3 Outputs
3.2.*. 4 Termination
3.2.*.5 Error Messages
3.3 System Manager
3.3.1 Manager's Functions/Menu
3.3.1.* (Insert Name ) Function
3.4 System Backup/Recovery Provisions
3.5 System Security
4. NOTES
5. APPENDICES
6. GLOSSARY
A-20
-------
EPA System Design & Development
Guidance: Volume C
EEI-12 SOFTWARE USER'S REFERENCE GUIDE
1. INTRODUCTION
1.1 Purpose
1.2 Background
1.3 Scope
1.4 System References
1.5 Terms and Abbreviations
1.6 Organization of This Document
2. REFERENCED DOCUMENTS
2.1 Government Documents
2.2 Non-government Documents
3. DESCRIPTION OF THE SYSTEM
3.1 System Overview and Mission Based Activities
3.2 System Flow and Data Descriptions
3.3 System and Program Manager
3.4 Data Dictionary
4. SYSTEM ACCESS TECHNIQUE(S)
4.1 Hardware/Software Interface(s)
4.2 Menus and Other Methods of Access
4.3 Manual Procedures
5. USER ANALYSIS / REPORTING OPTIONS
5.1 Standard Reports
5.2 Ad-hoc Capabilities
5.3 Specialized Capabilities
5.3.1 Models, Algorithms, Etc.
5.3.2 Graphics
5.3.3 Expert Systems
5.3.4 Laser and Other Output Media
6. DATA ENTRY AND UPDATE PROCESSES
6.1 Methods and Descr': .ions of Processes
6.2 Data Responsibilities
A-21
-------
EPA System Design & Development
Guidance: Volume C
EEI-12 SOFTWARE USER'S REFERENCE GUIDE (Continued)
7. USER SUPPORT AND TRAINING PROGRAM/SOURCES
7.1 User Support
7.2 Training Sources/Schedules
8. NOTES
9. APPENDICES
10. GLOSSARY
• A-22
-------
EPA System Design & Development
Guidance: Volume C
EEI-13 SYSTEM INTEGRATION TEST REPORT
1. INTRODUCTION
1.1 Purpose
1.2 Background
1.3 Scope
1.4 System References
1.5 Terms and Abbreviations
1.6 Assumptions and Constraints
1.7 Organization of This Document
2. REFERENCED DOCUMENTS
2.1 Government Documents
2.2 Non-government Documents
3. SUMMARY OF TESTING
3.1 Test Environment
3.2 Chronology of the Testing Process
4. TEST RESULTS
4.1 Resolved Incidents
4.2 Outstanding Incidents
4.3 Evaluation and Recommended Disposition
5. NOTES
6. APPENDICES
7. GLOSSARY
A-23
------- |