# *DETAILED ANALYSIS and DESIGN PHASE*

# 4.1 Introduction

**\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_**

## 4.1.1 Purpose

During the Detailed Analysis and Design Phase, the Project Manager and
the System Development Manager work closely together to:

a.  Complete business process engineering of the functions to be
    supported,

b.  Complete component selection.

c.  Develop detailed data and process models,

d.  Refine functional and system requirements that are not easily
    expressed in data and process models,

e.  Refine the high level architecture and logical design to support the
    system, functional, and electronic records management requirements,

f.  Continue to identify and mitigate risk that the technology can be
    phased-in and coordinated with the business.

There are three key reviews during the Detailed Analysis and Design
Phase: the Detailed Level Requirements Review, Logical Design Review,
and the Technical Design Review. This phase is completed when the
Technical Review Board approves the high level architecture and system
requirements, revised economic analysis, the logical design including
the business process description, and the technical design. This
approval is provided at these three reviews.

## 4.1.2 Overview

Detailed logical models of business data and processes needed to guide
system development are created in the Detailed Analysis and Design
Phase, and a description of the technical architecture is refined to
guide the allocation of computing resources and capabilities. When
practicable, the deployment of the new AIS should be planned to coincide
with the implementation of new business processes and procedures. The
Project Manager and the System Development Manager should continue to
assess both business and technical risks and seek additional management
support as necessary to manage those risks. Both the Project Manager and
the System Development Manager may wish to document project risks and
risk management activities in a risk management matrix for future
reference.

## 4.1.3 Tasks

The primary tasks performed during the Detailed Analysis and Design
Phase are as follows:

a.  Consolidate and affirm business needs,

b.  Implement AIS project management infrastructure including
    requirements, configuration, and data management support services
    and utilities,

c.  Revise plans to document changes in project scope including changes
    in business, schedule, and technical requirements,

d.  Revise plans to document changes in available resources including
    budget, skills, staff, and training,

e.  Update list of candidate reuse components, and complete reuse
    component selection.

f.  Complete electronic records management requirements,

g.  Identify data acquisition, conversion, and validation strategies,

h.  Refine the technical architecture and build architectural prototype,

i.  Identify design tools, techniques, and procedures,

j.  Perform detailed AIS analysis and design, and

k.  Continue planning for AIS testing, training, deployment, operation
    and business transition, and

l.  Define and refine detailed requirements and allocate requirements to
    design.

## 4.1.4 Activities and Documentation

Detailed Analysis and Design Phase activities and documentation
requirements as summarized in the following table must conform to the
indicated Technical Standard and Guidelines or other standards as noted.

The set of system requirements that satisfies the Business Case is
contained in the Functional Baseline as indicated under the "Functional"
subheading in Table 4.1.4. Work products and design documents included
in the Logical Design (Allocated) Baseline are identified under the
"Logical Design" subheading in Table 4.1.4.

The Configuration Management TSG, IT-212.2-06, provides additional
information about these baselines. Published standards and guidelines
may be augmented with Tailoring Agreements.

+----------------+-------+-------+----+----+----+------+----+------+
|                |       |       |    |    |    | Base |    |      |
|                |       |       |    |    |    | line |    |      |
+----------------+-------+-------+----+----+----+------+----+------+
| Work Product   | TSG/  | Who's | Mu | Sh | Mu | Fu   | L  | Must |
|                |       | R     | st | ou | st | ncti | og |      |
|                | Sta   | espon |    | ld |    | onal | ic | Comp |
|                | ndard | sible | Cr |    | Up |      | al | lete |
|                |       |       | ea | Up | da |      | De |      |
|                |       |       | te | da | te |      | si |      |
|                |       |       |    | te |    |      | gn |      |
+----------------+-------+-------+----+----+----+------+----+------+
| Business Case  | I     | Pr    |    |    | X  |      |    |      |
|                | T-212 | ogram |    |    |    |      |    |      |
|                | .2-13 | Spo   |    |    |    |      |    |      |
|                |       | nsor, |    |    |    |      |    |      |
|                |       | Pr    |    |    |    |      |    |      |
|                |       | oject |    |    |    |      |    |      |
|                |       | Ma    |    |    |    |      |    |      |
|                |       | nager |    |    |    |      |    |      |
+----------------+-------+-------+----+----+----+------+----+------+
| Project        | I     | Pr    |    |    | X  |      |    |      |
| Management     | T-212 | oject |    |    |    |      |    |      |
| Plan and       | .2-01 | Man   |    |    |    |      |    |      |
| supporting     |       | ager, |    |    |    |      |    |      |
| baseline       |       | S     |    |    |    |      |    |      |
| project        |       | ystem |    |    |    |      |    |      |
| schedules      |       | D     |    |    |    |      |    |      |
|                |       | evelo |    |    |    |      |    |      |
|                |       | pment |    |    |    |      |    |      |
|                |       | Ma    |    |    |    |      |    |      |
|                |       | nager |    |    |    |      |    |      |
+----------------+-------+-------+----+----+----+------+----+------+
| AIS Project    | I     | O     |    | X  |    |      |    |      |
| Quality        | T-212 | ffice |    |    |    |      |    |      |
| Assurance Plan | .2-04 | of    |    |    |    |      |    |      |
|                |       | S     |    |    |    |      |    |      |
|                |       | ystem |    |    |    |      |    |      |
|                |       | Pr    |    |    |    |      |    |      |
|                |       | oduct |    |    |    |      |    |      |
|                |       | Assu  |    |    |    |      |    |      |
|                |       | rance |    |    |    |      |    |      |
+----------------+-------+-------+----+----+----+------+----+------+
| Data           | I     | O     |    |    | X  |      |    |      |
| Management     | T-212 | ffice |    |    |    |      |    |      |
| Plan           | .2-05 | of    |    |    |    |      |    |      |
|                |       | Data  |    |    |    |      |    |      |
|                |       | Manag |    |    |    |      |    |      |
|                |       | ement |    |    |    |      |    |      |
+----------------+-------+-------+----+----+----+------+----+------+
| AIS            | I     | O     |    | X  |    |      |    |      |
| Configuration  | T-212 | ffice |    |    |    |      |    |      |
| Management     | .2-06 | of    |    |    |    |      |    |      |
| Plan           |       | S     |    |    |    |      |    |      |
|                |       | ystem |    |    |    |      |    |      |
|                |       | Pr    |    |    |    |      |    |      |
|                |       | oduct |    |    |    |      |    |      |
|                |       | Assu  |    |    |    |      |    |      |
|                |       | rance |    |    |    |      |    |      |
+----------------+-------+-------+----+----+----+------+----+------+
| System         | I     | Pr    |    |    | X  |      | X  | X    |
| Boundary       | T-212 | oject |    |    |    |      |    |      |
| Agreement      | .2-10 | Man   |    |    |    |      |    |      |
|                |       | ager, |    |    |    |      |    |      |
|                |       | S     |    |    |    |      |    |      |
|                |       | ystem |    |    |    |      |    |      |
|                |       | D     |    |    |    |      |    |      |
|                |       | evelo |    |    |    |      |    |      |
|                |       | pment |    |    |    |      |    |      |
|                |       | Ma    |    |    |    |      |    |      |
|                |       | nager |    |    |    |      |    |      |
+----------------+-------+-------+----+----+----+------+----+------+
| Concept of     | I     | Pr    |    |    | X  | X    | X  |      |
| Operations     | T-212 | ogram |    |    |    |      |    |      |
|                | .2-11 | Spo   |    |    |    |      |    |      |
|                |       | nsor, |    |    |    |      |    |      |
|                |       | Pr    |    |    |    |      |    |      |
|                |       | oject |    |    |    |      |    |      |
|                |       | Ma    |    |    |    |      |    |      |
|                |       | nager |    |    |    |      |    |      |
+----------------+-------+-------+----+----+----+------+----+------+
| Detailed       | I     | S     | X  |    |    | X    | X  |      |
| Design         | T-212 | ystem |    |    |    |      |    |      |
| (includes data | .2-12 | D     |    |    |    |      |    |      |
| model, screen  |       | evelo |    |    |    |      |    |      |
| shots and      |       | pment |    |    |    |      |    |      |
| report         |       | Man   |    |    |    |      |    |      |
| layouts)       |       | ager, |    |    |    |      |    |      |
|                |       | S     |    |    |    |      |    |      |
|                |       | ystem |    |    |    |      |    |      |
|                |       | Arch  |    |    |    |      |    |      |
|                |       | itect |    |    |    |      |    |      |
+----------------+-------+-------+----+----+----+------+----+------+
| Interface      | I     | S     | X  |    |    |      |    | X    |
| Design         | T-212 | ystem |    |    |    |      |    |      |
| Definition     | .3-14 | D     |    |    |    |      |    |      |
|                |       | evelo |    |    |    |      |    |      |
|                |       | pment |    |    |    |      |    |      |
|                |       | Ma    |    |    |    |      |    |      |
|                |       | nager |    |    |    |      |    |      |
+----------------+-------+-------+----+----+----+------+----+------+
| Economic       | I     | Pr    |    |    | X  |      |    |      |
| Analysis       | T-212 | oject |    |    |    |      |    |      |
|                | .2-13 | Man   |    |    |    |      |    |      |
|                |       | ager, |    |    |    |      |    |      |
|                |       | S     |    |    |    |      |    |      |
|                |       | ystem |    |    |    |      |    |      |
|                |       | D     |    |    |    |      |    |      |
|                |       | evelo |    |    |    |      |    |      |
|                |       | pment |    |    |    |      |    |      |
|                |       | Ma    |    |    |    |      |    |      |
|                |       | nager |    |    |    |      |    |      |
+----------------+-------+-------+----+----+----+------+----+------+
| Business       | I     | Pr    | X  |    |    |      |    | X    |
| Transition     | T-212 | ogram |    |    |    |      |    |      |
| Plan           | .3-05 | Spo   |    |    |    |      |    |      |
|                |       | nsor, |    |    |    |      |    |      |
|                |       | Pr    |    |    |    |      |    |      |
|                |       | oject |    |    |    |      |    |      |
|                |       | Ma    |    |    |    |      |    |      |
|                |       | nager |    |    |    |      |    |      |
+----------------+-------+-------+----+----+----+------+----+------+
| Requirements   | IT    | Pr    | X  |    | X  |      | X  |      |
| Specification, | 212   | oject |    |    |    |      |    |      |
| Part 2         | .3-11 | Man   |    |    |    |      |    |      |
|                |       | ager, |    |    |    |      |    |      |
| (Completed     |       | S     |    |    |    |      |    |      |
| through lower  |       | ystem |    |    |    |      |    |      |
| level          |       | D     |    |    |    |      |    |      |
| requirements)  |       | evelo |    |    |    |      |    |      |
|                |       | pment |    |    |    |      |    |      |
|                |       | Ma    |    |    |    |      |    |      |
|                |       | nager |    |    |    |      |    |      |
+----------------+-------+-------+----+----+----+------+----+------+

+---------------+-------+-------+----+----+----+------+----+------+
|               |       |       |    |    |    | Base |    |      |
|               |       |       |    |    |    | line |    |      |
+---------------+-------+-------+----+----+----+------+----+------+
| Work Product  | TSG/  | Who's | Mu | Sh | Mu | Fu   | L  | Must |
|               |       | R     | st | ou | st | ncti | og |      |
|               | Sta   | espon |    | ld |    | onal | ic | Comp |
|               | ndard | sible | Cr |    | Up |      | al | lete |
|               |       |       | ea | Up | da |      | De |      |
|               |       |       | te | da | te |      | si |      |
|               |       |       |    | te |    |      | gn |      |
+---------------+-------+-------+----+----+----+------+----+------+
| Requirements  | I     | O     | X  |    |    |      | X  |      |
| Traceability  | T-212 | ffice |    |    |    |      |    |      |
| Matrix        | .3-11 | of    |    |    |    |      |    |      |
|               |       | S     |    |    |    |      |    |      |
|               |       | ystem |    |    |    |      |    |      |
|               |       | Pr    |    |    |    |      |    |      |
|               |       | oduct |    |    |    |      |    |      |
|               |       | Assu  |    |    |    |      |    |      |
|               |       | rance |    |    |    |      |    |      |
+---------------+-------+-------+----+----+----+------+----+------+
| Test Plan     | I     | O     | X  |    |    |      |    | X    |
|               | T-212 | ffice |    |    |    |      |    |      |
|               | .3-01 | of    |    |    |    |      |    |      |
|               |       | S     |    |    |    |      |    |      |
|               |       | ystem |    |    |    |      |    |      |
|               |       | Pr    |    |    |    |      |    |      |
|               |       | oduct |    |    |    |      |    |      |
|               |       | Assu  |    |    |    |      |    |      |
|               |       | rance |    |    |    |      |    |      |
+---------------+-------+-------+----+----+----+------+----+------+
| Training Plan | I     | Pr    | X  |    |    |      |    | X    |
|               | T-212 | oject |    |    |    |      |    |      |
|               | .3-02 | Man   |    |    |    |      |    |      |
|               |       | ager, |    |    |    |      |    |      |
|               |       | S     |    |    |    |      |    |      |
|               |       | ystem |    |    |    |      |    |      |
|               |       | D     |    |    |    |      |    |      |
|               |       | evelo |    |    |    |      |    |      |
|               |       | pment |    |    |    |      |    |      |
|               |       | Ma    |    |    |    |      |    |      |
|               |       | nager |    |    |    |      |    |      |
+---------------+-------+-------+----+----+----+------+----+------+
| AIS Security  | I     | Pr    |    |    | X  |      | X  |      |
| Plan          | T-212 | oject |    |    |    |      |    |      |
|               | .2-08 | Man   |    |    |    |      |    |      |
| (only if      |       | ager, |    |    |    |      |    |      |
| sensitive     |       | S     |    |    |    |      |    |      |
| data)         |       | ystem |    |    |    |      |    |      |
|               |       | D     |    |    |    |      |    |      |
|               |       | evelo |    |    |    |      |    |      |
|               |       | pment |    |    |    |      |    |      |
|               |       | Ma    |    |    |    |      |    |      |
|               |       | nager |    |    |    |      |    |      |
+---------------+-------+-------+----+----+----+------+----+------+
| Operational   | I     | Pr    | X  |    |    |      |    | X    |
| Support Plan  | T-212 | oject |    |    |    |      |    |      |
|               | .5-01 | Man   |    |    |    |      |    |      |
|               |       | ager, |    |    |    |      |    |      |
|               |       | S     |    |    |    |      |    |      |
|               |       | ystem |    |    |    |      |    |      |
|               |       | D     |    |    |    |      |    |      |
|               |       | evelo |    |    |    |      |    |      |
|               |       | pment |    |    |    |      |    |      |
|               |       | Ma    |    |    |    |      |    |      |
|               |       | nager |    |    |    |      |    |      |
+---------------+-------+-------+----+----+----+------+----+------+

**Table 4.1.4 Detailed Analysis and Design Phase Activities and
Documentation Requirements (Concluded)**

# 4.2 Detailed Requirements Analysis

**\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_**

Business requirements are intended to state in a concise, complete, and
unambiguous manner what the system must do to meet business needs.
Business requirements should not introduce unnecessary design
assumptions or technical constraints. In this phase, the high level data
and functions defined in the Concept Phase are transformed into a
detailed description from which the system can be developed. This
description will use a combination of textual and graphical
representations to express the requirements in a form that users can
readily understand. The functional, data, and support requirements must
be approved by the Program Sponsor. Direct involvement of supported
users and business area experts is essential to developing functional
and data requirements. See IT-212.3-11, Requirements Management, for a
description of the requirements definition process and documentation
requirements.

## 4.2.1 Functional and Data Requirements Definition

Complete, user-oriented functional and data requirements for the system
must be analyzed, defined, and documented. Screens, reports, and
diagrams are useful in documenting the functional and data requirements.
Analysis, definition, and documentation of requirements ensures :

a.  All requirements can be traced to the System Boundary Agreement and
    Concept of Operations.

b.  Business process descriptions contained in the Concept of Operations
    are further refined. The detailed design is captured in the Detailed
    Design Document and must be consistent with the Concept of
    Operations.

c.  Reuse of existing USPTO software components is based on the list of
    candidate components. Components identified in the USPTO reuse
    repository should be evaluated against the AIS requirements to
    determine if the component meets the system needs as-is, requires a
    defined set of enhancements, or is incompatible with the AIS
    requirements.

d.  The USPTO reuse repository is extended by selecting candidate
    components to be developed in parallel with the AIS development
    effort. For each component selected, a component specification
    should be defined to document the services offered by the component.

e.  A logical model is constructed that describes the fundamental
    processes and data needed to support the desired business
    functionality. This logical model will show how processes interact
    and how processes create and use data. These processes will be
    derived from the activity descriptions provided in the System
    Boundary Agreement and Concept of Operations. For projects involving
    migration, old data elements should be mapped to new data elements.

f.  Functions and entity types contained in the logical model are
    extended and refined from those provided in the Concept Phase.
    End-users and business area experts will evaluate all identified
    processes and data structures to ensure accuracy, logical
    consistency, and completeness.

g.  An analysis of business activities and data structures is performed
    to produce work products such as, entity-relationship diagrams,
    process hierarchy diagrams, and process dependency diagrams.

h.  A detailed analysis of the current technical architecture,
    application software, and data is conducted to ensure that
    limitations or unique AIS requirements have not been overlooked.

These requirements must include considerations for capacity and growth.
Where feasible, the I-CASE tool will be used to assist in this analysis,
definition, and documentation.

## 4.2.2 Support Requirements

Additional requirements that affect the design or use of the system must
be defined in the Detailed Analysis and Design Phase as indicated below.

a.  Functional and technical training needed for development,
    deployment, and operation of the AIS, including associated training
    schedules and costs, must be coordinated with the business area
    training representative, system users, and training organizations,
    such as the Work Force Effectiveness Division and the Patent
    Academy, in a timely manner. Section 6.6 provides additional
    information on training.

b.  Requirements for logistical and network support needed to develop,
    deploy, and operate the AIS are identified in this phase and are
    documented in the Detailed Design and in the Operational Support
    Plan. These documents may be updated during follow-on phases.

c.  AIS review, testing, evaluation, certification, and security
    requirements are identified, including associated schedules and
    costs. Timely coordination with all support organizations involved
    in addressing these requirements must be provided, particularly for
    independent, third‑party organizations.

d.  Plans needed to support system development, deployment, training,
    operation, and maintenance must be developed and coordinated with
    system users and support organizations, and must be implemented in a
    timely manner.

e.  The justification for developing or enhancing an AIS application
    must always be expressed in business terms. The specific business
    needs that must be addressed are referred to as "performance
    requirements." In addressing performance requirements, project
    management is able to demonstrate that the AIS addresses a set of
    real business needs and objectives. Performance requirements focus
    on improving customer satisfaction, work force accuracy,
    productivity, responsiveness, and reliability.

## 4.2.3 Requirements Traceability

Requirements will be captured in a requirements traceability matrix as
described in the Requirements Management TSG, IT-212.3-11 for designated
AIS projects. This matrix must show the traceability of the detailed
requirements contained in the Requirements Specification, Part 2 to the
Detailed Design Document The high level requirements are recorded in the
System Boundary Agreement, the Concept of Operations, and the
Requirements Specification, Part 1.

## 4.2.4 Detailed Level Requirements Review

The products of the detailed requirements analysis are reviewed by the
Technical Review Board at the Detailed Level Requirements Review. The
purposes of this review are to:

a.  Confirm functional and data requirements,

b.  Review the candidate component list and selected reusable
    components.

c.  Review data and process models (e.g., entity relationship and
    process hierarchy diagrams),

d.  Confirm the decomposition of AIS into subsystems (if applicable),
    and

e.  Approve the functional baseline.

The documents that are reviewed are: Requirements Specification,
Requirements Traceability Matrix, and any changes to documents approved
by the Technical Review Board during the Concept Phase. Requirements
documents will be validated against the System Boundary Agreement and
the Project Management Plan and will be reviewed for completeness and
consistency. See IT-212.2-04, Quality Assurance, for additional guidance
in preparing review materials, and attending and conducting Detailed
Level Requirements Review.

# Business Transition Planning

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

Once the Concept of Operations has been accepted by the Program Sponsor,
the Project Manager will work with the business area to plan how the
organization will migrate to the desired business process. The Project
Manager will use the Concept of Operations TSG, IT-212.2-11, as the
guideline for designing and planning transition activities.

## 4.3.1 Transition Activities

Transition activities cover all personnel, business process, budget, and
organizational changes. Each transition activity is a required task and
includes activities such as: revising policies, procedures, and job
descriptions, providing training, establishing standard office formats,
and providing necessary facilities and infrastructure to accommodate
computer systems or work activities. In developing the transition
activities, the Project Manager should coordinate with USPTO management
to work with the unions to identify specific activities regarding labor
management relations that must be implemented to provide a smooth
transition to the new business processes. The accumulation of all
transition activities will form the Business Transition Plan (refer to
IT-212.3-05). All transition and change management activities will be
documented and tracked in the Project Management Plan according to
IT-212.2-01.

## 4.3.2 Preparing the Organization for Change

Special attention must be given to reducing any adverse impact that may
result from the transition process. Project Managers should prepare
their organization to effectively cope with change by building consensus
among key personnel in affected groups. This can be accomplished by
establishing more effective communications with internal and external
customers, effectively managing labor relations through early and
frequent communications, and by openly discussing anticipated changes
with employees.

# 4.4 AIS Technical Architecture and Detailed Design

**\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_**

A technical architecture is a detailed design of the AIS hardware and
software components, and their interrelationships. In the Detailed
Analysis and Design Phase, the technical architecture for the AIS is
captured in the Detailed Design Document and described in sufficient
detail to guide the integration of applications and data to be developed
in later life cycle phases as specified in the Detailed Design TSG,
IT-212. 4-12. The allocated baseline is established by mapping detailed
requirements to the architectural elements identified in the high level
architecture.

The detailed design must show the major types of processing platforms,
how they interconnect, and the allocation of processing and storage
resources to ensure that business requirements can be satisfied within
system boundary constraints. An analysis of the architecture\'s
capabilities must be conducted to determine performance and growth
constraints in hardware, operating system software and utilities, and
support software. All external system interfaces and internal subsystem
interfaces must be identified and defined as specified in the Interface
Design Definition, IT-212.3-14. The following policies are applicable to
defining the technical architecture for this phase.

## Use of Existing System Components or Commercial Off-The- Shelf (COTS) Products

The use of reusable components and/or COTS products, which comply with
the USPTO Technical Reference Model, may significantly reduce the effort
required to develop, test, and deploy the AIS, and should be a
consideration in defining the AIS architecture. Design of new systems,
subsystems, or components should be initiated only after a review of
COTS products and existing USPTO system components indicates that COTS
or existing PTO system components can not be used or economically
modified to satisfy functional requirements.

## 4.4.2 Design Characteristics

The Detailed Design must comply with the USPTO Technical Reference
Model. The technical architecture will:

a.  Define the hardware, software, and network components in which the
    AIS will operate,

b.  Show how functional, data, and electronic records management
    requirements will be allocated among these components, and

c.  Describe the means used to interconnect these components.

Characteristics of the detailed design specified during the Detailed
Analysis and Design Phase should establish confidence that the system
components, when integrated, will meet all functional, performance, and
support requirements. The detailed design establishes a level of
uniformity for further AIS design and development. Architectural
limitations, such as the ability to handle changing user needs,
increased performance, and upward compatibility to new technologies,
must be determined, and if necessary, classified as project risks. The
Detailed Design must:

a.  Allow for maximum automated generation of application-specific code
    and databases using the CASE tool.

b.  Allow for maximum reuse of existing system components.

c.  Employ COTS software products wherever economically feasible.

d.  Ensure that the application software can be processed on hardware
    and system software that is either currently available in the USPTO
    inventory or has been approved for acquisition and delivery in
    sufficient lead-time to allow for use during the test process of the
    Development Phase.

e.  Provide for the collection of performance metrics.

f.  Provide for including designer‑added software capabilities for
    internal controls to facilitate functional and technical audits of
    the AIS.

g.  Specify functional and technical requirements for integration of the
    AIS with other PTO business processes, as needed.

h.  Handle sensitive information as specified in security related
    policies and requirements.

## 4.4.3 Prototyping

The use of prototyping is encouraged. Prototypes can be useful in
refining requirements and may significantly enhance both user and
developer understanding of requirements. Prototypes can also be used to
validate portions of the technical architecture against the functional
requirements, technical specifications, and may be used to obtain
performance measures. In the Detailed Analysis and Design Phase,
emphasis should be given to architectural prototypes that demonstrate
the ability to integrate the preferred reusable components or COTS
products into a coherent system that can satisfy functional,
performance, and support requirements.

## 4.4.4 Peer Reviews

Peer reviews will be conducted on designated critical AIS projects to
identify and remove defects from the products early and efficiently.
Peer reviews can be particularly effective when used to review the work
products and documentation developed during the Detailed Analysis and
Design and Development phases of the life cycle. AIS or infrastructure
project development documentation will be reviewed in accordance with
the Quality Assurance TSG, IT-212.2-04. For designated AIS projects,
reviews, inspections and walk-throughs will be scheduled, conducted,
tracked, and the results reported in accordance with the project\'s
Quality Assurance Plan.

# 4.5 Subsystem Identification, Definition and Management

**\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_**

## Evolutionary Development and Incremental Delivery of Capabilities

The Project Manager and the System Development Manager are encouraged to
follow an evolutionary development approach and divide up the AIS
Project into several smaller components or subsystems. Based upon an
analysis of the business processes, the Project Manager and System
Development Manager should focus on providing end users with needed
capabilities as early as practical. Typically each subsystem performs a
unique function and supports an easily identifiable segment of the
desired business process. Subsystem identification and definition occurs
early in the Detailed Analysis and Design Phase.

Subsystems must be identified in the high level architecture and
sufficiently documented to support adequate subsystem testing,
integration, and integration testing. The Project Manager and the System
Development Manager allocate requirements to subsystems based upon
commonality of purpose in such a manner as to minimize the number of
interactions that must occur between distinct subsystems. Interfaces
between subsystems will be identified in terms of shared entities and
functional services. Project management must update the Quality
Assurance Plan to show the documents and reviews planned for each
subsystem.

The Project Management and Business Transition Plans should be reviewed
and updated to ensure that subsystem deployment is synchronized with
changes in business practices and procedures. A Functional Baseline may
be established at the end of the Detailed System Analysis Subphase and
subsystem changes controlled in accordance with the Configuration
Management TSG, IT-212.2-06.

## 4.5.2 Subsystem Project Management

The System Development Manager will designate a Lead Analyst for each
subsystem to be developed. The Detailed Design Document and the
Interface Design Definition will reflect the scope, requirements,
performance measures, cost, and schedule for the system, including the
subsystems. The individual subsystems will be controlled and coordinated
within the boundaries established by the project System Boundary
Agreement. See IT-212.2-12 and IT-212.3-14 for guidance on developing
and documenting the Detailed Design Document and the Interface Design
Definition, respectively.

# 4.6 COTS Detailed Analysis and Design Considerations

**\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_**

COTS software products seldom provide the functionality necessary to
address all business requirements. System Development Managers will not
modify the COTS product. USPTO unique requirements not provided by the
COTS product will be satisfied through application program interfaces.
Unless the COTS software firm fully supports USPTO unique modifications
and makes them generally available to the public, the software package
is no longer a COTS package. At this point there is a significant risk
to the USPTO that the former COTS package may not perform as expected or
be supported over time. Moreover, if the System Development Manager
implements a modification in a COTS product, it may be very costly, if
not impossible, to obtain vendor support in resolving software
performance issues, even those apparently unrelated to the modification.

The System Development Manager must consider the time and skills needed
to integrate COTS components into an AIS. Developers must specify,
design, code, document, and test "in-house" software that will support
COTS integration. When constructing COTS integration software, it may be
necessary to verify COTS specifications and performance through unit
testing or with prototypes. The System Development Manager must also
keep in mind that new versions or COTS upgrades may alter the external
interface to the COTS package. Software developers may find that it is
necessary to design, integrate, and test integration software for new
COTS releases to ensure compatibility with the existing AIS and other
COTS components of the AIS. The System Architect will approve the
selection of COTS software products.

# 4.7 Project Risk Management

**\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_**

During this phase the Project Manager and System Development Manager
will continue to identify and evaluate risks to AIS project
requirements, cost, and schedule. Issues related to managing AIS project
requirements, creating AIS designs and supporting plans, and
establishing realistic Subsystem Boundary Agreement conditions,
contribute to project risks during this phase. Risks associated with an
inability to quantify, verify, or test requirements can also begin to
affect AIS project performance during this phase. The most significant
risks during this phase, however, are typically risks that result from
an inability to monitor or evaluate the effectiveness and timeliness of
AIS analysis and design. Peer reviews can provide useful information
used to identify risk classes, establish risk management criteria, and
establish risk management measures associated with analysis and design
activities. The risk management section of the Project Management TSG
(IT-212.2-01) provides additional guidance for managing AIS project
risks.

# 4.8 AIS Security

**\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_**

During the Detailed Analysis and Design Phase project management will
initiate preliminary steps to systematically identify and analyze AIS
security requirements. The Project Manager should work closely with the
security analysts in the Office of Information Systems Security (OISS)
in analyzing security requirements. The AIS project team may apply
information provided in the preliminary risk assessment to prototype
security measures and safeguards. The System Development Manager may
also use this information to develop back-up, contingency, and
operational support plans. The Project Manager will advise the Program
Sponsor, the CIO, the Systems Development Manager, and the OISS on
matters of significant security threats.

## 4.8.1 Security Analysis and Design

Both the Project Manager and the System Development Manager must work
closely with USPTO security analysts to identify, analyze, and
prioritize AIS security issues during this phase. With the assistance of
AIS security specialists the AIS project team will determine what
security features, assurances, and operational practices are appropriate
to address these issues. In designing the AIS, the System Development
Manager must incorporate these security requirements into the AIS design
specifications. AIS security analysts will evaluate security
requirements, designs, and supporting plans upon request and will advise
project management, the Program Sponsor, CIO, or the Technical Review
Board regarding areas of weakness or needed improvement.

### 4.8.2 Determining Security Requirements

Security requirements should be developed at the same time system
requirements are defined. These security requirements can be expressed
as technical features (e.g., log-in procedures or other access
controls), assurances (e.g., background checks for system developers and
users), or operational practices (e.g., awareness and training). The
Project Manager, System Development Manager, OSAE, and USPTO security
analysts must actively work together to ensure that the technical
designs reflect the system's security needs. AIS security requirements,
like other system requirements, are derived from a number of sources
including law, policy, applicable standards and guidelines, functional
needs of the system, risk assessment, and cost-benefit trade-off and are
documented in the risk analysis.

## 4.8.3 Incorporating Security Requirements into Specifications

Security analysts will provide the Project Manager with reports that
identify, estimate, and evaluate significant security issues, and, if
requested, will research and recommend safeguards that address these
issues. This analysis can result in voluminous amounts of information
that must be validated, updated and organized into detailed security
requirements and specifications.

During the development of AIS security specifications, it may become
necessary for the Project Manager to re-examine initial risk assessments
to ensure that all requirements are compatible and feasible to
implement. The Project Manager must be able to determine that security
features and practices will work correctly and effectively as early in
the system life as possible. The Project Manager will brief the Program
Sponsor, CIO, or Technical Review Board as recommended by the security
analyst. Based upon the recommendations of the Project Manager, the
Program Sponsor or the CIO may assign additional staff or allocate
additional resources to ensure the development of that adequate AIS
security specifications.

**4.9 Logical Design Review**

**\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_**

The products of the detailed requirements analysis, including the high
level architecture and support plans must be reviewed by the Technical
Review Board. The Logical Design Review will confirm that the business
area logical model is sufficiently complete, correct, and stable to
allow for the physical design to begin. Deficiencies identified in the
logical model must be resolved, and changes generated by the review must
be incorporated into the logical design as directed by the Technical
Review Board. The High Level Architecture will be reviewed to verify its
ability to satisfy the approved functional, data, and support
requirements. Components of the logical model and other requirements
shall be allocated to components of the technical architecture.
Traceability shall be demonstrated to ensure that decisions concerning
the high level architecture account for all allocated requirements.
Issues governing the possibility of future change in the business or
information technology infrastructure and the ability of the information
and technical architectures to endure those changes shall be identified
and appropriately addressed. This includes an analysis of the
performance and growth requirements for the system throughout its
planned operational use. Support plans will be validated against the
Project Management Plan and will be reviewed for completeness and
consistency. The support plans which are reviewed are: Test Plan,
Training Plan, components of the Operational Support Plan including
provisions for network and computer equipment support, and any changes
to plans approved by the Technical Review Board during the Concept
Phase. The Logical Design Review (which may be conducted as one or more
events) will be conducted in accordance with IT-212.2-04, Quality
Assurance. The approved High Level Architecture and approved products of
detailed requirements analysis shall be placed in a Logical Design
(allocated) Baseline under configuration control.

## Technical Design Review

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

The Technical Design Review is conducted during the Detailed Analysis
and Design Phase to evaluate the appropriateness of the technical
design. This review verifies that the system conforms to the
infrastructure baseline. The products of the Detailed Analysis and
Design Phase, and updates to existing plans and specifications must be
reviewed by the Technical Review Board. The Technical Design Review will
confirm that the AIS or infrastructure system design is complete,
correct, and ready for the Development Phase to begin. The Technical
Design Review will be conducted in accordance with IT-212.2-04, Quality
Assurance.

## Analysis and Design Considerations 

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

The overriding consideration when beginning to implement the final code
and architecture for a system is to thoroughly understand the
requirements and design. The following should be in place to begin
development or existing problems/design holes will only be amplified
down the road with project delays, unhappy users, and cost overruns.

a.  Requirements should be known in detail. Functional requirements
    should be linked to the finished design. Detailed finalized screen
    formats, menu items, fields (mandatory and optional), and report
    layouts are necessary to proceed.

b.  The database design should be complete. The physical design and its
    mapping to interfaces, screens fields and reports columns must be
    solid.

c.  The mapping of legacy data to the new physical database should be
    established for all fields. Methods for handling rejected conversion
    data and illegal data values should be in place.

d.  User access levels should be known. The functionality, data, and
    fields each user type is allowed to access should be detailed.

e.  An estimate of frequency and size of all transactions, number of
    users, user screen use, report volumes should be created. This will
    ensure that the architecture and hardware products are sufficient to
    support required response times and data volumes.

f.  Key Volume Indicators (KVI), process static reporting, management
    information requirements, maintenance hooks, and other
    enterprise-wide requirements should be addressed in this phase.

g.  Design elements that are not defined because the requirements are
    not finalized due to technical risk elements that require
    prototyping should be identified in the Detailed Design Document and
    completed in the Development Phase.