> **SYSTEM/SUBSYSTEM**
>
> **SPECIFICATIONS**
>
> *Project or System Name*
>
> **U.S. Department of Housing and Urban Development**
>
> Month, Year

**Revision Sheet**

  ----------- ---------- --------------------------------------------------
  **Release   **Date**   **Revision Description**
  No.**                  

  Rev. 0      5/30/00    System/Subsystem Specifications Template and
                         Checklist

  Rev. 1      4/12/02    Conversion to WORD 2000 format

                         

                         

                         

                         

                         
  ----------- ---------- --------------------------------------------------

  ---------------------------------------------------- -----------------------------------------------
  ![](media/image3.wmf){width="1.1152777777777778in"   **System/Subsystem Specifications Authorization
  height="1.0951388888888889in"}                       Memorandum**

  ---------------------------------------------------- -----------------------------------------------

I have carefully assessed the System/Subsystem Specifications for the
[(System Name)]{.underline}. This document has been completed in
accordance with the requirements of the HUD System Development
Methodology.

MANAGEMENT CERTIFICATION - Please check the appropriate statement.

\_\_\_\_\_\_ The document is accepted.

\_\_\_\_\_\_ The document is accepted pending the changes noted.

\_\_\_\_\_\_ The document is not accepted.

We fully accept the changes as needed improvements and authorize
initiation of work to proceed. Based on our authority and judgment, the
continued operation of this system is authorized.

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

NAME DATE

Project Leader

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

NAME DATE

Operations Division Director

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

NAME DATE

Program Area/Sponsor Representative

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

NAME DATE

Program Area/Sponsor Director

**SYSTEM/SUBSYSTEM SPECIFICATIONS**

**TABLE OF CONTENTS**

[Page \#]{.underline}

1.0 GENERAL INFORMATION

> 1.1 Purpose
>
> 1.2 Scope
>
> 1.3 System Overview
>
> 1.4 Project References
>
> 1.5 Acronyms and Abbreviations
>
> 1.6 Points of Contact
>
> 1.6.1 Information
>
> 1.6.2 Coordination

2.0 SYSTEM CHARACTERISTICS

> 2.1 System/Subsystem Description
>
> 2.2 System/Subsystem Partitions and Functions
>
> 2.3 Accuracy and Validity
>
> 2.4 Timing
>
> 2.5 Adaptability
>
> 2.6 Failure Contingencies
>
> 2.7 System Logical Flow

3.0 ENVIRONMENT

> 3.1 Equipment Environment
>
> 3.1.1 Processors
>
> 3.1.2 Storage Media
>
> 3.1.3 Input/Output Devices
>
> 3.2 Communications Environment
>
> 3.2.1 Network
>
> 3.2.2 Interface Protocol
>
> 3.3 Software Environment
>
> 3.4 Software Interfaces
>
> 3.5 Diagnostics
>
> 3.6 Data and Reports
>
> 3.6.1 Inputs 3-2
>
> 3.6.2 Outputs/Reports 3-3

4.0 SECURITY

> 4.1 Control Points
>
> 4.2 Vulnerabilities
>
> 4.3 Safeguards

**1.0 GENERAL INFORMATION**

*[**NOTE TO AUTHOR:** Highlighted, italicized text throughout this
template is provided solely as background information to assist you in
creating this document. Please delete all such text, as well as the
instructions in each section, prior to submitting this document. **ONLY
YOUR PROJECT-SPECIFIC INFORMATION SHOULD APPEAR IN THE FINAL VERSION OF
THIS DOCUMENT**.]{.mark}*

*[The System/Subsystem Specifications provides a listing of the
specifications of the system and its subsystems, as well as a detailed
description of the system/subsystem functions. It also defines in detail
the interfaces with other systems and subsystems and the facilities to
be used for accomplishing the interfaces. For each subsystem, include
such information as timing requirements, equipment needs, communications
environment, support software, security, and input and output
records.]{.mark}*

# GENERAL INFORMATION

## 1.1 Purpose

Describe the purpose of the System/Subsystem Specifications.

## 1.2 Scope

Describe the scope of the System/Subsystem Specifications as it relates
to the project.

## 1.3 System Overview

Provide a brief system overview description as a point of reference for
the remainder of the document. In addition, include the following:

-   Responsible organization

-   System name or title

-   System code

-   System category

```{=html}
<!-- -->
```
-   *Major application*: performs clearly defined functions for which
    there is a readily identifiable security consideration and need

-   *General support system*: provides general ADP or network support
    for a variety of users and applications

```{=html}
<!-- -->
```
-   Operational status

```{=html}
<!-- -->
```
-   Operational

-   Under development

-   Undergoing a major modification

```{=html}
<!-- -->
```
-   System environment and special conditions

## 1.4 Project References

Provide a list of the references that were used in preparation of this
document. *[Examples of references are:]{.mark}*

-   [Previously developed documents relating to the project]{.mark}

-   [Documentation concerning related projects]{.mark}

-   [HUD standard procedures documents]{.mark}

## 1.5 Acronyms and Abbreviations

Provide a list of the acronyms and abbreviations used in this document
and the meaning of each.

## 1.6 Points of Contact

### 1.6.1 Information

Provide a list of the points of organizational contact (POCs) that may
be needed by the document user for informational and troubleshooting
purposes. Include type of contact, contact name, department, telephone
number, and E-mail address (if applicable). Points of contact may
include, but are not limited to, helpdesk POC, development/maintenance
POC, and operations POC.

### 1.6.2 Coordination

Provide a list of organizations that require coordination between the
project and its specific support function (e.g., installation
coordination, security, etc.). Include a schedule for coordination
activities.

**2.0 SYSTEM CHARACTERISTICS**

# SYSTEM CHARACTERISTICS

*[This section provides an expansion of the information published in the
Functional Requirements Document (FRD) and Data Requirements Document
(DRD) to reflect additional details.]{.mark}*

## 2.1 System/Subsystem Description

Provide a general description of the system/subsystem to establish a
reference for the remainder of the document. Within this description,
you may include graphics representing the relationship of the user
organizations to the major components including networking,
communications, and distributed processing.

## 2.2 System/Subsystem Partitions and Functions

*[Although the descriptions of the system/subsystem functions may be
refined and more detailed as a result of the continuing analysis and
design effort, they must maintain a direct relationship to the system
functions established in the FRD and be described in such a way that the
system/subsystem environment can be related to them.]{.mark}*

Describe the system/subsystem partitions and functions, documenting the
traceability between the functional and data requirements and the
defined subsystem.

## 2.3 Accuracy and Validity

Describe the features incorporated in the design of the system/subsystem
that meet the accuracy and validity requirements imposed on each
system/subsystem level. Accuracy requirements of mathematical
calculations and data must be considered.

## 2.4 Timing

Describe the timing requirements imposed on the system/subsystem, if
applicable. For example, the following timing requirements may be
considered:

-   Throughput time

-   Response time to queries and to updates of the data files

-   Sequential relationship of system/subsystem functions

-   Priorities imposed by types of input and changes in modes of
    operation

-   Timing requirements for the range of traffic load under varying
    operating conditions

-   Sequencing and interleaving of software units and systems (including
    the requirement for interrupting the operation of a software unit
    without loss of data)

## 2.5 Adaptability

Provide a description of the capability to be incorporated for adapting
the system/subsystem to changing requirements, such as anticipated
operational changes, interaction with new or improved systems, and
planned periodic changes. Components and procedures designed to be
subject to change will be identified.

## 2.6 Failure Contingencies

Discuss alternative courses of action that are to be taken to satisfy
requirements if the proposed system fails. Include as appropriate:

-   Backup. Alternative requirements for ensuring the continued
    achievement of system functions.

-   Fallback. Fallback techniques for ensuring the continued
    satisfaction of the specific requirements of the system. Fallback
    indicates the use of another system to satisfy the system
    requirements. For example: the fallback techniques for an automated
    system might be manual manipulation and recording data.

-   Degraded Modes of Operation. If applicable, state priorities for
    restoring the essential functional processing steps in the event
    that full processing capability is not available.

## 2.7 System Logical Flow

Present the logical flow of the system/subsystem. Supplement the
representation with a program design language presentation, a narrative
presentation, or a combination of the two. Graphics should provide an
integrated presentation of the system/subsystem dynamics, entrances and
exits, and interfaces with other software units. Represent all modes of
operations, priorities, cycles, special handling and general flow of
control.

**3.0 ENVIRONMENT**

# ENVIRONMENT

[This section provides detailed information on the environment discussed
in the FRD and the Capacity Planning Survey (Final Assessment). These
changes will be discussed in terms of the impacts on the currently
available environmental components (equipment, software) as well as the
impacts on estimates and functions that were based on the originally
planned environment.]{.mark}

## 3.1 Equipment Environment

Provide a description of the equipment required for the operation of the
system/subsystem. Include descriptions of the equipment presently
available, as well as a more detailed discussion of the characteristics
and impact of any new equipment necessary for system operation.

### 3.1.1 Processors

Include number and type of each online/offline processor, and size of
internal storage.

### 3.1.2 Storage Media

Include number and type of storage media.

### 3.1.3 Input/Output Devices

Include number and type of each online/offline device.

## 3.2 Communications Environment

Describe the data communications environment of the system.
Additionally, provide detailed schematics of the portions of the
communications environment that directly relate to the system or
subsystem being documented. If a standard communications environment is
being used, reference can be made to it.

### 3.2.1 Network

Describe the network configuration and characteristics if non-HUD
standard configuration or Web-based, including, at a minimum, the
following:

-   Transmission requirements and technique

-   Data transfer rates (baud rates)

-   Gateways

-   Geographic locations

-   Required system use times, if any

-   Line speed capability

    If the system utilizes a non-HUD standard configuration, indicate
    the date the proposed configuration was approved for this project by
    the Configuration Change Management Board (CCMB).

### 3.2.2 Interface Protocol

Identify all protocols.

## 3.3 Software Environment

Describe the software with which the system/subsystem must interact.
Include both support software and test software, if needed. Provide the
correct name, description, and documentation references of each such
software system, subsystem, and program. Include a reference to the
operating system to be used, the database management system (if any),
and the language for the following:

-   compiler

-   assembler

-   program

-   query

    If any of the software components used are not currently
    HUD-approved standards, indicate the date these items were approved
    for this project by the Configuration Change Management Board
    (CCMB).

## 3.4 Software Interfaces

Provide a description of the interfaces with other application software
units, including those of other operational capabilities and from other
government agencies. For each interface, specify the file format
(input/output) and delivery media.

## 3.5 Diagnostics

Describe diagnostic procedures that will allow identification and
classification of system/subsystem problems.

## 3.6 Data and Reports

### 3.6.1 Inputs

Identify the inputs and provide information about the characteristics of
each input to the system/subsystem, such as:

-   file name

-   format and type of data

-   validation criteria

-   volume

-   frequency

-   means of entry

-   source documents and their disposition

-   security and privacy considerations

### 3.6.2 Outputs/Reports

Identify the output data and reports, including information about the
characteristics of each output from the system/subsystem, such as:

-   file names

-   report formats

-   selection criteria for displays or outputs

-   types of output media

-   disposition of products

**4.0 SECURITY**

# SECURITY

[To control dissemination of sensitive information, all or portions of
this chapter may be maintained and distributed separately from the
remainder of the document.]{.mark}

## 4.1 Control Points

*[A control point can be located at any interface at which there is
movement of data within or between sites.]{.mark}*

Describe the points in the system at which there is a known
vulnerability that requires specific safeguards.

## 4.2 Vulnerabilities

*[A design, implementation, or operational condition inherent in the
application or system that lends itself to error, loss, or compromise of
information, or denial of service is a system vulnerability.]{.mark}*

Describe the vulnerabilities at each control point.

## 4.3 Safeguards

Describe the safeguard requirements at each control point to reduce
vulnerabilities.