United States Department of Agriculture (USDA) eGovernment Program

#########  {#section .unnumbered}

######### Technological Profile - Technical Requirements  {#technological-profile---technical-requirements .unnumbered}

######### eDeployment Business Case  {#edeployment-business-case .unnumbered}

May 2004

![](media/image1.jpeg){width="1.75in" height="1.2666666666666666in"}

**Table of Contents**

[Revision History iii](#revision-history)

[Previous Change History iii](#previous-change-history)

[Document Sign-off iii](#document-sign-off)

[1 Introduction 1](#introduction)

[2 Current Technical Architecture Assessment
2](#current-technical-architecture-assessment)

[3 Architecture Drivers 3](#architecture-drivers)

[4 Technical Requirements 6](#technical-requirements)

[4.1 Common Requirements 6](#common-requirements)

[4.2 Portal Services Technical Requirements
17](#portal-services-technical-requirements)

[4.3 Web Content Management Technical Requirements
21](#web-content-management-technical-requirements)

[4.4 Document Management Technical Requirements
28](#document-management-technical-requirements)

[4.5 Data Management Technical Requirements
32](#data-management-technical-requirements)

[4.6 Web Presence Technical Requirements
33](#web-presence-technical-requirements)

[5 Assumptions 35](#assumptions)

#  Revision History {#revision-history .unnumbered}

## Previous Change History {#previous-change-history .unnumbered}

Table a -- Previous Change History

  --------------------------- ------------------------ -------------------------- -----------------------------
  **[Version]{.smallcaps}**   **[Date]{.smallcaps}**   **[Author]{.smallcaps}**   **[Comment]{.smallcaps}**

  1.0                         04/23/04                 Trang Pham                 Initial Draft

  1.1                         04/29/04                 Tom Taliaferro             Updated formatting
  --------------------------- ------------------------ -------------------------- -----------------------------

## Document Sign-off {#document-sign-off .unnumbered}

Table b -- Document Sign-off

  ------------------------ ------------------------ ---------------------------------------
  **[Date]{.smallcaps}**   **[Name]{.smallcaps}**   **[Title]{.smallcaps}**

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

# Introduction

In defining the solutions that meet the needs of the eGovernment
Enablers initiatives, a technical requirements gathering process is
necessary. As opposed to functional requirements that ensure that a
system provides all the features necessary as dictated by the user
community, technical requirements outline criteria of how these features
should be delivered. Technical requirements, in conjunction with
functional requirements, serve as input to the technical architecture as
well as the vendor selection processes. The key technology drivers
listed in *Section 3* document the basic components that are necessary
in any enterprise solution. The technical requirements are greatly
influenced by these drivers.

The purpose of this document is to provide a comprehensive list of
technical requirements for all eDeployment Enabler initiatives. The
following sections will address:

-   **Current architectural environment:** This section provides a brief
    overview of the current USDA environment as it relates to the
    eDeployment initiatives;

-   **Architectural Drivers:** This section identifies architectural
    drivers that provide a basis for the technical requirements;

-   **Technical Requirements:** The technical requirements section
    provides a detailed list of requirements for all eDeployment
    initiatives. This section is sub-divided into common and
    initiative-specific requirements; and

-   **Assumptions:** This section provides a list of the assumptions
    that were made in formulating the technical requirements.

Please note that this is a select phase business case document. It
should be expected that contents of this document might change and
evolve in response to additional information, and change of initiative
direction and user requirements. Additionally, requirements outline
desired capability for the long term. Some of these capabilities may not
be implemented in the initial phases of the eDeployment implementation.

# Current Technical Architecture Assessment

Department-wide capabilities do not currently exist within USDA in the
areas of content management, document management, data management, Web
presence, collaboration and portal services. Each Agency implements
technology solutions and manual processes to address needs in these
areas. This has resulted in redundant development efforts across the
Department, redundant/inconsistent data, lack of sharing of pertinent
information, excessive time spent on back office processes and
inconsistent to non-existent online brand. This stovepipe approach to
data management and system development has hampered USDA in being cost
effective towards IT investments as well as in better serving its
customers and partners.

# Architecture Drivers

The following architecture drivers are at the crux of the technical
requirements that are contained in the sections to follow:

**Suitability**

The solution technology must address the Department's business
(functional) requirements as well as fit into the current technological
environment. Suitability to both the business and technological
environment is further complicated due to changing business needs and
market trends. It is of prime importance that the solution technology
should remain suitable over a period of time and be easy to adapt to
support future requirements.

**Performance**

Performance measures the ability of a system to deliver the intended
capabilities within the specified application response time. One of the
key goals of the designed solution should be to meet the minimum
Performance Standards. These performance standards are derived from
business requirements. The solution has to perform at the required level
under stress from large volumes and sudden traffic peaks, and with
possible diversities in user configurations.

**Resilience**

Resilience is the ability to cope with problems gracefully, as opposed
to failing at the smallest error. Applications should be designed and
implemented with adequate exception handling to address processing
anomalies (user caused or otherwise).

The emergence of internet-based applications has further complicated the
issue for resilience by enabling the deployment of applications to a
large audience. A larger user audience increases the unpredictability of
user actions and application events that may cause errors. In addition,
as opposed to applications deployed to a small audience where training
can be used to ensure that user actions follow certain paths to reduce
exceptions, applications with a large audience do not have that luxury
of the use of training to supplement exception handling.

**Interoperability**

Interoperability is ensuring that all parts of the selected solution
work together. Interoperability is of prime importance for the
eDeployment initiative as it encompasses various components; namely Web
Presence, Portal Services, Web Content Management, and Document
Management. Interoperability between vendor products, interoperability
of the enabling initiatives, and interoperability with existing USDA
systems all fall into this category. Interoperability relies on the need
for a strong technical architecture and proper testing. Failing to
account for interoperability will impact the ability to run, maintain,
and extend the architecture of a solution. Selection of products and
platforms that adhere to industry standards (*de facto* and otherwise)
as well as use of Enterprise Application Integration solutions are also
ways to ensure interoperability within and across systems.

**Availability**

The Technology Architecture must be able to support the application at
the required times (such as running on a full 24x7 schedule). Opening
access to corporate applications through the Internet typically extends
the availability requirements. However, there is a cost trade off with
high availability. Having applications offline for a short period during
low usage hours might be a realistic alternative to handle backup and
other maintenance operations, compared to the added complexity and cost
of 24x7 availability. There are two types of availability stops:

-   Planned availability stops (such as maintenance activities); and

-   Non-planned availability stops (such as unpredicted hardware or
    software malfunctions)

> Availability stops vary by application and can be caused by factors
> internal to as well as external of (example: network outage) the
> application.

**Security**

The solution must support the appropriate levels of security. Security
becomes a critical driver at USDA due to issues such as privacy and
integrity of data and national security. Security considerations are
discussed in further detail in the *Technology Profile - Security Plan*
control phase business case deliverable.

**Scalability**

A solution is scalable if it can change to meet an increase in
transaction/request volume. The scalability driver is critical at USDA,
as the Enabler capabilities will be rolled out to Agencies
incrementally. As more Agencies come on board and more Agency
applications leverage the Enabler components, the solution has to scale
to accommodate the increasing number of users and volume of data.

As defined below, scalability can be either vertical or horizontal:

-   Vertical scalability is the ability to increase the power of a
    particular hardware component to support growth (for example, adding
    CPUs, RAM, cache, disks, etc. to a server). Vertical scaling offers
    quick solutions to many scalability issues, but the law of
    diminishing returns dictates that there is always a level at which
    simply adding more hardware has very little effect; and

-   Horizontal scalability is the ability to increase the number of
    parallel hardware components to support a particular part of the
    architecture (for example, introducing a new application server or
    database server).

**Flexibility**

Flexibility is the ability to change the solution to quickly meet new
business requirements. Flexibility is not a single entity. Generally, it
is the combination of other architectural goals. Adhering to industry
standards and use of Enterprise Application Integration solutions, as
opposed to custom system interfaces, are some ways to ensue solution
flexibility.

**Equipment**

Equipment make-up is another factor in the solution design. Equipment
can generally be classified into:

-   Terminal devices (client), such as personal computers, mobile
    devices, interactive TVs, and kiosks;

-   Network (access channel), such as network (Internet) access point,
    routers, modems, and firewalls; and

-   Server devices, such as Web servers, application servers, video
    stream servers, authentication and authorization servers.

As a general rule, scalability, performance, and reliability should be
the prime considerations in obtaining network and server equipment.

**Competency**

Developing and maintaining the appropriate levels of competency is
critical to the success of the eDeployment initiatives. In addition to
developing the right mix of skills through training and recruiting,
special attention must be paid to retain highly valued skills and
anticipate turnover. Alliances and partnership can help ensure that the
right mix of competencies is available through shared resources.

# Technical Requirements

The following section outlines the technical requirements for the
eDeployment initiatives. It is sub-divided into two categories of
requirements: common requirements (shared across portal, Web content
management and document management) and initiative specific
requirements.

The requirements document addresses all of the technical requirements
for the eDeployment solution. The requirements table lists the
requirement number, the requirement, the grouping, the priority, and the
requirement description.

Priority identifies the relative priority of each requirement by numeric
value. The values within this field are 1, 2, or 3.

-   High Priority requirements are denoted with the number 1. These High
    Priority requirements must be met by the system in order to be
    deemed compliant;

-   Medium Priority requirements, designated with the number 2, are
    requirements that are desired as part of the solution, but are not
    mandatory for the first implementation; and

-   Low Priority requirements, denoted with a Priority Number of 3,
    correspond to requirements that provide best practices that support
    the implementation of efficient and effective functionality, but do
    not directly implement a functional requirement alone.

Web presence and data management requirements are separated out and
formatted differently. This has been done because these two initiatives
are intended to dictate standards and policies to the other initiatives
as opposed to deliver a system to the end user community. Thus
requirements around these initiatives are naturally of a different
nature.

## Common Requirements 

The requirements groupings for the common technical eDeployment
requirements are as follows:

-   Administration;

-   Application Programmability;

-   Authentication and Authorization;

-   Execution Architecture;

-   Feature Set;

-   Interoperability;

-   Operations;

-   Operations Architecture;

-   Scalability and Performance; and

-   Security.

Table 4.1: Technical Requirements - Common Requirements

+----+----------------+---------+-----+------------------------------+
| ** | **[Requirement | **[Gr   | **  | **[Requirement               |
| [\ | \#]            | ouping] | [Pr | Description]{.smallcaps}**   |
| #] | {.smallcaps}** | {.small | ior |                              |
| {. |                | caps}** | ity |                              |
| sm |                |         | ]{. |                              |
| al |                |         | sma |                              |
| lc |                |         | llc |                              |
| ap |                |         | aps |                              |
| s} |                |         | }** |                              |
| ** |                |         |     |                              |
+====+================+=========+=====+==============================+
| 1. | The solution   | Adminis | 1   | The solution should provide  |
|    | should provide | tration |     | for a complete Web-enabled   |
|    | Web enabled    |         |     | Administration console.      |
|    | administration |         |     | These tools should allow     |
|    | capability.    |         |     | administrators to remotely   |
|    |                |         |     | perform their tasks.         |
+----+----------------+---------+-----+------------------------------+
| 2. | Administrators | Adminis | 1   | The administration of the    |
|    | should be able | tration |     | solution should be granular. |
|    | to create,     |         |     | The administration tool      |
|    | view, update   |         |     | should provide hierarchy of  |
|    | and delegate   |         |     | administrators with          |
|    | user           |         |     | different levels of access.  |
|    | permissions    |         |     | User access should be        |
|    | and access     |         |     | customizable down to the     |
|    | controls to    |         |     | user level to create, view   |
|    | application    |         |     | and update the different     |
|    | components.    |         |     | solution components that the |
|    |                |         |     | user can access.             |
|    |                |         |     |                              |
|    |                |         |     | Administration should also   |
|    |                |         |     | be available at the          |
|    |                |         |     | project/collaboration level  |
|    |                |         |     | to allow administrators to   |
|    |                |         |     | set access rights to         |
|    |                |         |     | documents, data, document    |
|    |                |         |     | folders and add or delete    |
|    |                |         |     | users within set             |
|    |                |         |     | collaborative parameters.    |
+----+----------------+---------+-----+------------------------------+
| 3. | The solution   | Adminis | 3   | The solution should provide  |
|    | should provide | tration |     | the capability for creating  |
|    | mechanism to   |         |     | batch jobs. For example      |
|    | create batch   |         |     | creating a job to upload     |
|    | jobs for       |         |     | 1000 users at one time etc.  |
|    | administrative |         |     |                              |
|    | activities.    |         |     |                              |
+----+----------------+---------+-----+------------------------------+
| 4. | Modification   | Appl    | 1   | Where possible,              |
|    | to base code   | ication |     | modifications to solution    |
|    | should not be  | P       |     | components/configuration     |
|    | required to    | rogramm |     | should be accomplished via   |
|    | confi          | ability |     | changes to user              |
|    | gure/customize |         |     | interface/APIs rather than   |
|    | solution.      |         |     | base code. Changes to base   |
|    |                |         |     | code not only add to the     |
|    |                |         |     | cost of the solution, but    |
|    |                |         |     | also restrict the            |
|    |                |         |     | adaptability of the solution |
|    |                |         |     | to upgrades and servicing.   |
+----+----------------+---------+-----+------------------------------+
| 5. | The solution   | Appl    | 1   | The solution should be based |
|    | should provide | ication |     | on open APIs to enable       |
|    | an open API to | P       |     | custom development, third    |
|    | facilitate     | rogramm |     | party tool integration and   |
|    | custom         | ability |     | future implementations. The  |
|    | development/   |         |     | solution should support      |
|    | modifications. |         |     | industry standards such as   |
|    |                |         |     | XML, J2EE, JDBC, ODBC, FTP,  |
|    |                |         |     | HTTP, Web Folders (also      |
|    |                |         |     | WebDAV for Web Content,      |
|    |                |         |     | Management and Document      |
|    |                |         |     | Management) etc to support   |
|    |                |         |     | existing applications and    |
|    |                |         |     | databases. The solution      |
|    |                |         |     | should also support use of   |
|    |                |         |     | programming languages for    |
|    |                |         |     | example: Java, VB, C+, C++,  |
|    |                |         |     | etc. for development of new  |
|    |                |         |     | components.                  |
+----+----------------+---------+-----+------------------------------+
| 6. | The solution   | Appl    | 1   | The solution APIs should be  |
|    | APIs should be | ication |     | fully documented and         |
|    | fully          | P       |     | supported by the vendor.     |
|    | documented and | rogramm |     |                              |
|    | supported.     | ability |     |                              |
+----+----------------+---------+-----+------------------------------+
| 7. | The solution   | Appl    | 2   | The solution should provide  |
|    | should provide | ication |     | GUI based tools for          |
|    | visual         | P       |     | configuration of the         |
|    | configuration  | rogramm |     | solution. These tools would  |
|    | tools plus     | ability |     | be used for the initial      |
|    | code.          |         |     | configuration of the         |
|    |                |         |     | solution and subsequent      |
|    |                |         |     | releases.                    |
+----+----------------+---------+-----+------------------------------+
| 8. | The solution   | Authent | 1   | The solution should be       |
|    | should be      | ication |     | easily integrated with       |
|    | capable of     | &       |     | Department's planned         |
|    | integrating    | Author  |     | eAuthentication solution.    |
|    | with USDA's    | ization |     | Please refer to              |
|    | planned        |         |     | eAuthentication Business     |
|    | e              |         |     | Case.                        |
|    | Authentication |         |     |                              |
|    | solution.      |         |     |                              |
+----+----------------+---------+-----+------------------------------+
| 9. | The solution   | Authent | 1   | The solution should conform  |
|    | should provide | ication |     | to current Role-Based Access |
|    | an integrated  | &       |     | Control (RBAC) standards.    |
|    | user           | Author  |     | The solution should also     |
|    | management and | ization |     | provide tools for the        |
|    | permission     |         |     | following to provide         |
|    | system to be   |         |     | internal users access to the |
|    | used for       |         |     | applications and content:    |
|    | role-based     |         |     |                              |
|    | user           |         |     | -   User Management - for    |
|    | authentication |         |     |     activities like          |
|    | and            |         |     |     creating, deleting,      |
|    | authorization  |         |     |     updating and assigning   |
|    | for accessing  |         |     |     roles to internal users; |
|    | appli          |         |     |                              |
|    | cation/content |         |     | -   Authorization - for      |
|    | functionality. |         |     |     enforcing usage rights   |
|    |                |         |     |     around content; and      |
|    |                |         |     |                              |
|    |                |         |     | -   Permissions Management - |
|    |                |         |     |     for providing real-time  |
|    |                |         |     |     permissions to access    |
|    |                |         |     |     content and approvals.   |
|    |                |         |     |                              |
|    |                |         |     | > The solution should also   |
|    |                |         |     | > support planned USDA       |
|    |                |         |     | > single sign-on solution.   |
+----+----------------+---------+-----+------------------------------+
| 10 | The solution   | Ex      | 1   | The n-tiered approach to     |
| .  | should support | ecution |     | architecture accounts for    |
|    | n-tier         | Archi   |     | future innovations. The      |
|    | architecture.  | tecture |     | solution architecture should |
|    | The solution   |         |     | separate the three tiers     |
|    | architecture   |         |     | namely User Interface,       |
|    | should have    |         |     | Business Logic and Data      |
|    | separate User  |         |     | Access layer to provide      |
|    | Interface,     |         |     | enhanced design flexibility. |
|    | business       |         |     | It should also support       |
|    | logic, and     |         |     | multiple middleware tiers to |
|    | data access    |         |     | enable integration with      |
|    | layers.        |         |     | Agency application including |
|    |                |         |     | legacy systems.              |
+----+----------------+---------+-----+------------------------------+
| 11 | The solution   | Ex      | 1   | The solution should be easy  |
| .  | should be      | ecution |     | to integrate with existing   |
|    | deployable     | Archi   |     | USDA infrastructure and      |
|    | within the     | tecture |     | policies for accessing       |
|    | USDA and       |         |     | information within           |
|    | Agency         |         |     | Department firewalls.        |
|    | firewall       |         |     |                              |
|    | infrastructure |         |     |                              |
|    | and policies.  |         |     |                              |
+----+----------------+---------+-----+------------------------------+
| 12 | The solution   | Ex      | 1   | The solution should be able  |
| .  | should         | ecution |     | to support transactions      |
|    | facilitate     | Archi   |     | originating from both sides  |
|    | communication  | tecture |     | of the corporate firewall.   |
|    | across         |         |     |                              |
|    | corporate      |         |     |                              |
|    | firewall.      |         |     |                              |
+----+----------------+---------+-----+------------------------------+
| 13 | The solution   | Ex      | 1   | The solution should support  |
| .  | should support | ecution |     | distributed, multiple-data   |
|    | multi-site     | Archi   |     | centers deployment for       |
|    | deployment.    | tecture |     | optimal response time.       |
|    |                |         |     |                              |
|    |                |         |     | A multi-site deployment      |
|    |                |         |     | works as a single unit and   |
|    |                |         |     | enables the system to direct |
|    |                |         |     | the users to the most        |
|    |                |         |     | optimal servers for quick    |
|    |                |         |     | response time and positive   |
|    |                |         |     | user experience.             |
+----+----------------+---------+-----+------------------------------+
| 14 | The solution   | Ex      | 1   | The solution should be based |
| .  | should provide | ecution |     | on Open Standards (such as   |
|    | vendor neutral | Archi   |     | J2EE, XML, ODBC, etc...) and |
|    | framework for  | tecture |     | capable of integrating with  |
|    | application    |         |     | existing non-proprietary     |
|    | integration    |         |     | applications, Web sites,     |
|    | for example    |         |     | databases, workflow          |
|    | other third    |         |     | systems and document         |
|    | party          |         |     | management systems. The      |
|    | solu           |         |     | solution should also be able |
|    | tions/packages |         |     | to integrate with any data   |
|    | such as CRM    |         |     | source or application        |
|    | solutions.     |         |     | regardless of the operating  |
|    |                |         |     | system or hardware. These    |
|    |                |         |     | may include other third      |
|    |                |         |     | party solutions/packages     |
|    |                |         |     | like CRM solution,           |
|    |                |         |     | interoperability between the |
|    |                |         |     | eDeployment initiatives      |
|    |                |         |     | namely Portal, Web Content   |
|    |                |         |     | Management and Document      |
|    |                |         |     | Management solution etc. The |
|    |                |         |     | solution should also be able |
|    |                |         |     | to integrate with            |
|    |                |         |     | Department's current and     |
|    |                |         |     | future technology direction. |
+----+----------------+---------+-----+------------------------------+
| 15 | The solution   | Ex      | 1   | The solution architecture    |
| .  | should allow   | ecution |     | should allow distributed     |
|    | for            | Archi   |     | architecture for data and    |
|    | distributed    | tecture |     | content repositories.        |
|    | data/content   |         |     |                              |
|    | repositories.  |         |     |                              |
+----+----------------+---------+-----+------------------------------+
| 16 | The solution   | Ex      | 1   | The solution should follow   |
| .  | should comply  | ecution |     | the component-based          |
|    | with           | Archi   |     | application design approach  |
|    | c              | tecture |     | to enable: Customizability,  |
|    | omponent-based |         |     | and Extensibility.           |
|    | architecture.  |         |     |                              |
|    |                |         |     | **Customizability:** The     |
|    |                |         |     | solution should be easy to   |
|    |                |         |     | customize to cater to USDA   |
|    |                |         |     | specific requirements not    |
|    |                |         |     | fulfilled by out-of-box      |
|    |                |         |     | functionality and available  |
|    |                |         |     | third party tools.           |
|    |                |         |     |                              |
|    |                |         |     | **Extensibility**: The       |
|    |                |         |     | Solution should support      |
|    |                |         |     | custom extensions to better  |
|    |                |         |     | suit specific needs. This    |
|    |                |         |     | may include development of   |
|    |                |         |     | custom APIs.                 |
+----+----------------+---------+-----+------------------------------+
| 17 | The solution   | Ex      | 1   | The selected solution should |
| .  | should be easy | ecution |     | easily integrate with the    |
|    | to integrate   | Archi   |     | overall architectural design |
|    | with USDA and  | tecture |     | for the Department and       |
|    | Agency         |         |     | agency architectures that    |
|    | Enterprise     |         |     | are in-line with the         |
|    | Architecture.  |         |     | principles of EA.            |
+----+----------------+---------+-----+------------------------------+
| 18 | The solution   | Ex      | 1   | All components of the system |
| .  | should be      | ecution |     | should be hardware and       |
|    | platform       | Archi   |     | Operating System             |
|    | independent.   | tecture |     | independent.                 |
+----+----------------+---------+-----+------------------------------+
| 19 | The solution   | Ex      | 1   | The solution should be able  |
| .  | should support | ecution |     | to support XML for Data      |
|    | XML standards  | Archi   |     | interchange.                 |
|    | for data       | tecture |     |                              |
|    | interchange.   |         |     |                              |
+----+----------------+---------+-----+------------------------------+
| 20 | The            | Ex      | 1   | The user should be able to   |
| .  | presentation   | ecution |     | access the solution from a   |
|    | layer of the   | Archi   |     | standard Web-based GUI.      |
|    | solution       | tecture |     |                              |
|    | should be      |         |     |                              |
|    | Web-based and  |         |     |                              |
|    | fully          |         |     |                              |
|    | compliant with |         |     |                              |
|    | all browsers.  |         |     |                              |
+----+----------------+---------+-----+------------------------------+
| 21 | The solution   | Ex      | 1   | The solution will require    |
| .  | should         | ecution |     | data storage for user        |
|    | integrate with | Archi   |     | profile information,         |
|    | large storage  | tecture |     | indexes, configuration       |
|    | components.    |         |     | information, job schedules,  |
|    |                |         |     | etc. The solution will       |
|    |                |         |     | require compatibility with   |
|    |                |         |     | large storage components for |
|    |                |         |     | example Storage Area         |
|    |                |         |     | Networks (SAN)               |
+----+----------------+---------+-----+------------------------------+
| 22 | The solution   | Ex      | 2   | The system should have the   |
| .  | should be able | ecution |     | ability to deploy cached     |
|    | to facilitate  | Archi   |     | content on multiple Web      |
|    | a scalable     | tecture |     | servers.                     |
|    | Caching        |         |     |                              |
|    | architecture.  |         |     | The solution should also     |
|    |                |         |     | have the ability to          |
|    |                |         |     | synchronize cached content   |
|    |                |         |     | on multiple distributed Web  |
|    |                |         |     | servers                      |
+----+----------------+---------+-----+------------------------------+
| 23 | The solution   | Ex      | 1   | The integration with the     |
| .  | should         | ecution |     | mail applications provides   |
|    | integrate with | Archi   |     | connectivity with external   |
|    | mail           | tecture |     | mail-based solutions. The    |
|    | applications,  |         |     | solution should thus be able |
|    | *e.g.* SMTP.   |         |     | to interface with Lotus      |
|    |                |         |     | Notes, Microsoft Outlook,    |
|    |                |         |     | Exchange etc.                |
+----+----------------+---------+-----+------------------------------+
| 24 | The solution   | Ex      | 1   | The solution should have the |
| .  | should be able | ecution |     | ability to provide internal  |
|    | to support     | Archi   |     | users access from outside    |
|    | users          | tecture |     | Department/Agency networks.  |
|    | accessing the  |         |     |                              |
|    | information    |         |     |                              |
|    | via extranets. |         |     |                              |
+----+----------------+---------+-----+------------------------------+
| 25 | The solution   | Ex      | 1   | The solution should be able  |
| .  | should have    | ecution |     | to support both internal and |
|    | the ability to | Archi   |     | external users.              |
|    | support        | tecture |     |                              |
|    | requests from  |         |     |                              |
|    | either side of |         |     |                              |
|    | the firewall.  |         |     |                              |
+----+----------------+---------+-----+------------------------------+
| 26 | The solution   | Ex      | 1   | The Department and its       |
| .  | should be able | ecution |     | Agencies have offices around |
|    | to support     | Archi   |     | the globe. The solution      |
|    | users located  | tecture |     | should be able to support    |
|    | globally.      |         |     | the users located at all     |
|    |                |         |     | regional centers globally.   |
+----+----------------+---------+-----+------------------------------+
| 27 | The system     | Feature | 1   | The system should meet all   |
| .  | should comply  | Set     |     | accessibility requirements   |
|    | with Section   |         |     | defined under [Section       |
|    | 508.           |         |     | 508](http:                   |
|    |                |         |     | //www.section508.gov/index.c |
|    |                |         |     | fm?FuseAction=Content&ID=11) |
|    |                |         |     | of the US Government         |
|    |                |         |     | Rehabilitation Act.          |
+----+----------------+---------+-----+------------------------------+
| 28 | The system     | Feature | 1   | The solution should be easy  |
| .  | should be      | Set     |     | to integrate with third      |
|    | compatible     |         |     | Party tools for Section 508  |
|    | with best of   |         |     | compliance.                  |
|    | breed third    |         |     |                              |
|    | party tools    |         |     |                              |
|    | for Section    |         |     |                              |
|    | 508 Compliance |         |     |                              |
+----+----------------+---------+-----+------------------------------+
| 29 | Content that   | Feature | 2   | The collaborative server     |
| .  | resides in     | Set     |     | should be easy to integrate  |
|    | multiple       |         |     | with document servers, email |
|    | and/or         |         |     | servers, portals, Intranets, |
|    | different      |         |     | databases and legacy         |
|    | content        |         |     | applications.                |
|    | sources,       |         |     |                              |
|    | should be      |         |     |                              |
|    | easily         |         |     |                              |
|    | integrated to  |         |     |                              |
|    | create content |         |     |                              |
|    | from multiple  |         |     |                              |
|    | sources and    |         |     |                              |
|    | displayed as a |         |     |                              |
|    | single piece   |         |     |                              |
|    | of content.    |         |     |                              |
+----+----------------+---------+-----+------------------------------+
| 30 | The solution   | Feature | 2   | The solution should be       |
| .  | should be      | Set     |     | UNICODE enabled with         |
|    | developed      |         |     | language aware deployment    |
|    | based on       |         |     | engine to support global     |
|    | UNICODE for    |         |     | applications.                |
|    | multilingual   |         |     |                              |
|    | support.       |         |     | This means that the content  |
|    |                |         |     | can be contributed and       |
|    |                |         |     | encoded in virtually any     |
|    |                |         |     | language in the world. When  |
|    |                |         |     | the page is deployed, the    |
|    |                |         |     | page name, header, automated |
|    |                |         |     | navigational links, and      |
|    |                |         |     | banners are generated        |
|    |                |         |     | according to the designated  |
|    |                |         |     | language setting.            |
+----+----------------+---------+-----+------------------------------+
| 31 | The solution   | In      | 1   | The solution should rely on  |
| .  | should support | teroper |     | both *de facto* and Open     |
|    | Open Standards | ability |     | Standards (J2EE, CORBA, XML, |
|    | to enable      |         |     | Web Services, etc) instead   |
|    | seamless       |         |     | of proprietary protocols for |
|    | int            |         |     | application integration.     |
|    | er-operability |         |     |                              |
|    | in a           |         |     |                              |
|    | heterogeneous  |         |     |                              |
|    | environment.   |         |     |                              |
+----+----------------+---------+-----+------------------------------+
| 32 | The solution   | In      | 1   | Web services are basically   |
| .  | should support | teroper |     | objects that are based on    |
|    | Web Services.  | ability |     | Open Standards. They provide |
|    |                |         |     | additional support to        |
|    |                |         |     | integrate third party tools  |
|    |                |         |     | and extend solution          |
|    |                |         |     | programmability.             |
+----+----------------+---------+-----+------------------------------+
| 33 | The solution   | Ope     | 1   | Load balancing is dividing   |
| .  | architecture   | rations |     | the amount of work that a    |
|    | should provide |         |     | system has to do across      |
|    | load balancing |         |     | multiple instances of the    |
|    | for all tiers. |         |     | system for the purpose of    |
|    |                |         |     | sharing workload. User state |
|    |                |         |     | would be maintained across   |
|    |                |         |     | the multiple instances of    |
|    |                |         |     | the solution.                |
+----+----------------+---------+-----+------------------------------+
| 34 | The solution   | Ope     | 1   | Fault-tolerant describes a   |
| .  | should provide | rations |     | system or component designed |
|    | fault-tolerant |         |     | so that, in the event that a |
|    | /fail-over     |         |     | component fails, a backup    |
|    | features.      |         |     | component or procedure can   |
|    |                |         |     | immediately take its place   |
|    |                |         |     | with no loss of service.     |
|    |                |         |     |                              |
|    |                |         |     | Fail-over is a backup        |
|    |                |         |     | operational mode in which    |
|    |                |         |     | the functions of a system    |
|    |                |         |     | component (such as a server, |
|    |                |         |     | network, or database) are    |
|    |                |         |     | assumed by secondary system  |
|    |                |         |     | components when the primary  |
|    |                |         |     | component becomes            |
|    |                |         |     | unavailable through either   |
|    |                |         |     | failure or scheduled down    |
|    |                |         |     | time.                        |
|    |                |         |     |                              |
|    |                |         |     | Fail-over is typically an    |
|    |                |         |     | integral part of             |
|    |                |         |     | mission-critical systems     |
|    |                |         |     | that should be constantly    |
|    |                |         |     | available. The procedure     |
|    |                |         |     | involves automatically       |
|    |                |         |     | offloading tasks to a        |
|    |                |         |     | standby system component so  |
|    |                |         |     | that the procedure is as     |
|    |                |         |     | seamless as possible to the  |
|    |                |         |     | end user.                    |
+----+----------------+---------+-----+------------------------------+
| 35 | The solution   | Ope     | 1   | The solution should be       |
| .  | should         | rations |     | rolled into the existing     |
|    | integrate with |         |     | USDA onsite and offsite      |
|    | the USDA and   |         |     | backup/recovery solutions    |
|    | Agency backup  |         |     | such as tape management      |
|    | and recovery   |         |     | systems.                     |
|    | solutions.     |         |     |                              |
+----+----------------+---------+-----+------------------------------+
| 36 | The solution   | Ope     | 1   | The solution should allow    |
| .  | should allow   | rations |     | installation of upgrades     |
|    | for product    |         |     | without the need of          |
|    | upgrades on    |         |     | uninstalling. Also, the      |
|    | top of         |         |     | upgrades should provide      |
|    | existing       |         |     | compatibility with the third |
|    | version unless |         |     | party vendor-integrated      |
|    | uninstalling   |         |     | components. Some approaches  |
|    | is a better    |         |     | to ensure compatibility      |
|    | alternative.   |         |     | during upgrades is use of    |
|    |                |         |     | one vendor for multiple      |
|    |                |         |     | components or use of vendors |
|    |                |         |     | that have close              |
|    |                |         |     | partnerships.                |
+----+----------------+---------+-----+------------------------------+
| 37 | The solution   | Ope     | 2   | The solution should provide  |
| .  | should provide | rations |     | the capability to manage the |
|    | mechanism to   |         |     | archiving and deletion of    |
|    | archive and    |         |     | out dated content through    |
|    | purge content. |         |     | administrative tools and     |
|    |                |         |     | automated processes where    |
|    |                |         |     | appropriate.                 |
+----+----------------+---------+-----+------------------------------+
| 38 | The solution   | Ope     | 1   | The solution should provide  |
| .  | should provide | rations |     | basic monitoring             |
|    | automated      |         |     | capabilities to determine    |
|    | monitoring     |         |     | transaction volume and       |
|    | tools.         |         |     | application responsiveness.  |
|    |                |         |     | The monitoring tools should  |
|    |                |         |     | also provide the ability to  |
|    |                |         |     | set customized alerts for    |
|    |                |         |     | status/problem notification. |
+----+----------------+---------+-----+------------------------------+
| 39 | The network    | Ope     | 3   | The solution should be easy  |
| .  | management of  | rations |     | to integrate with the        |
|    | the solution   |         |     | existing network management  |
|    | should         |         |     | solutions at USDA and its    |
|    | integrate with |         |     | Agencies. It should also     |
|    | existing USDA  |         |     | support solutions for        |
|    | and mainstream |         |     | example Microsoft Management |
|    | network        |         |     | Console, BMC Patrol, IBM     |
|    | management     |         |     | Tivoli for network           |
|    | solutions.     |         |     | management.                  |
+----+----------------+---------+-----+------------------------------+
| 40 | The solution   | Scal    | 1   | The solution should be able  |
| .  | should be able | ability |     | to successfully cater to a   |
|    | to support a   | &       |     | large User base concurrently |
|    | large User     | Perf    |     | with minimal upload          |
|    | base           | ormance |     | time/delay to provide a      |
|    | concurrently   |         |     | great User experience.       |
|    | (number of     |         |     |                              |
|    | targeted       |         |     |                              |
|    | concurrent     |         |     |                              |
|    | users TBD).    |         |     |                              |
+----+----------------+---------+-----+------------------------------+
| 41 | The solution   | S       | 1   | Content may be transmitted   |
| .  | should enable  | ecurity |     | to and from browsers over a  |
|    | transmission   |         |     | secure connection for        |
|    | of content     |         |     | example SSL.                 |
|    | over secure    |         |     |                              |
|    | connections.   |         |     |                              |
+----+----------------+---------+-----+------------------------------+
| 42 | The solution   | S       | 1   | The solution should enable   |
| .  | should enable  | ecurity |     | the administrators to create |
|    | administrators |         |     | a granular structure of      |
|    | to establish a |         |     | administration. The          |
|    | hierarchy of   |         |     | administrators should be     |
|    | components and |         |     | able to create component     |
|    | rules for      |         |     | accessibility rules, Read    |
|    | feature        |         |     | Write and Delete rules.      |
|    | accessibility  |         |     |                              |
|    | to Users.      |         |     |                              |
+----+----------------+---------+-----+------------------------------+
| 43 | The solution   | S       | 1   | The solution should track    |
| .  | should         | ecurity |     | all events on the servers    |
|    | maintain logs  |         |     | for example user logins,     |
|    | of all user    |         |     | tracking of activities       |
|    | activity.      |         |     | performed by the user, user  |
|    |                |         |     | log-out etc                  |
+----+----------------+---------+-----+------------------------------+
| 44 | The solution   | S       | 1   | The solution should generate |
| .  | should provide | ecurity |     | logging event reports        |
|    | the ability to |         |     | compatible with generic      |
|    | generate       |         |     | reporting tools.             |
|    | activity       |         |     |                              |
|    | reports from   |         |     |                              |
|    | user logs.     |         |     |                              |
+----+----------------+---------+-----+------------------------------+
| 45 | The solution   | S       | 1   | The solution should enable   |
| .  | should provide | ecurity |     | secure hosting of shared     |
|    | robust         |         |     | resources for example        |
|    | security       |         |     | hosting multiple Agency data |
|    | architecture   |         |     | securely.                    |
|    | to enable a    |         |     |                              |
|    | controlled     |         |     | Security features should     |
|    | sharing of     |         |     | ensure data sharing is       |
|    | appropriate    |         |     | strictly limited to          |
|    | resources.     |         |     | authorized Users only.       |
+----+----------------+---------+-----+------------------------------+

## Portal Services Technical Requirements 

The requirements groupings for the Portal Services technical
requirements are as follows:

-   Administration;

-   Collaboration;

-   Feature Set;

-   Infrastructure;

-   Metrics Reporting;

-   Operations;

-   Scalability and Performance;

-   Search Engines; and

-   Security.

Table 4.2: Technical Requirements - Initiative Specific: Portal Services

+----+-----------------+---------+-----+------------------------------+
| ** | **[Requirement  | **[Gr   | **  | **[Requirement               |
| [\ | \#              | ouping] | [Pr | Description]{.smallcaps}**   |
| #] | ]{.smallcaps}** | {.small | ior |                              |
| {. |                 | caps}** | ity |                              |
| sm |                 |         | ]{. |                              |
| al |                 |         | sma |                              |
| lc |                 |         | llc |                              |
| ap |                 |         | aps |                              |
| s} |                 |         | }** |                              |
| ** |                 |         |     |                              |
+====+=================+=========+=====+==============================+
| 1. | The solution    | Adminis | 2   | The solution should provide  |
|    | should enable   | tration |     | a single administrative view |
|    | single view of  |         |     | of the enterprise and its    |
|    | enterprise and  |         |     | work group portals.          |
|    | workgroup       |         |     |                              |
|    | portals.        |         |     |                              |
+----+-----------------+---------+-----+------------------------------+
| 2. | The solution    | Collab  | 1   | The community tools          |
|    | should provide  | oration |     | including but not limited to |
|    | Portal          |         |     | the following:               |
|    | Community       |         |     |                              |
|    | Building tools. |         |     | -   Workgroup community: The |
|    |                 |         |     |     solution should be able  |
|    |                 |         |     |     to provide creation,     |
|    |                 |         |     |     maintenance and support  |
|    |                 |         |     |     for Web-based user group |
|    |                 |         |     |     communities with access  |
|    |                 |         |     |     to shared content,       |
|    |                 |         |     |     calendars, discussion    |
|    |                 |         |     |     boards, chat rooms and   |
|    |                 |         |     |     online meeting rooms     |
|    |                 |         |     |     with Webcam, whiteboard  |
|    |                 |         |     |     and application support  |
|    |                 |         |     |     facility.                |
|    |                 |         |     |                              |
|    |                 |         |     | -   Third party work group   |
|    |                 |         |     |     data sharing: The        |
|    |                 |         |     |     solution should be able  |
|    |                 |         |     |     to provide integration   |
|    |                 |         |     |     with third party         |
|    |                 |         |     |     collaborative content    |
|    |                 |         |     |     from applications such   |
|    |                 |         |     |     as Lotus Notes,          |
|    |                 |         |     |     Microsoft Exchange etc.  |
|    |                 |         |     |                              |
|    |                 |         |     | -   Peer-to-peer             |
|    |                 |         |     |     collaboration: The       |
|    |                 |         |     |     solution should provide  |
|    |                 |         |     |     for peer-to-peer data    |
|    |                 |         |     |     sharing and personal     |
|    |                 |         |     |     content sharing.         |
|    |                 |         |     |     Peer-to-peer             |
|    |                 |         |     |     collaboration tools such |
|    |                 |         |     |     as chat clients and      |
|    |                 |         |     |     Net-Meeting allow for    |
|    |                 |         |     |     the direct connection of |
|    |                 |         |     |     two clients to exchange  |
|    |                 |         |     |     messages and content.    |
|    |                 |         |     |                              |
|    |                 |         |     | -   Collaboration with       |
|    |                 |         |     |     business partners: The   |
|    |                 |         |     |     Portal solution's        |
|    |                 |         |     |     Collaboration module     |
|    |                 |         |     |     should provide           |
|    |                 |         |     |     Integration with         |
|    |                 |         |     |     business partner         |
|    |                 |         |     |     applications/portals to  |
|    |                 |         |     |     enable creation of       |
|    |                 |         |     |     eCommunities.            |
+----+-----------------+---------+-----+------------------------------+
| 3. | The solution    | Feature | 1   | USDA's current Portal        |
|    | should support  | Set     |     | strategy requires deployment |
|    | multiple        |         |     | of portal solution with      |
|    | portals that    |         |     | small pilot implementations  |
|    | can be          |         |     | at Agency level and then     |
|    | integrated      |         |     | phasing the knowledge to     |
|    | under a single  |         |     | scale to enterprise wide     |
|    | Department-wide |         |     | deployment. This translates  |
|    | portal.         |         |     | into the development and     |
|    |                 |         |     | existence of multiple        |
|    |                 |         |     | Portals within USDA and its  |
|    |                 |         |     | Agencies.                    |
|    |                 |         |     |                              |
|    |                 |         |     | The solution should support  |
|    |                 |         |     | the existence of multiple    |
|    |                 |         |     | portals (both vertical and   |
|    |                 |         |     | horizontal) and provide      |
|    |                 |         |     | selective integration (only  |
|    |                 |         |     | those portals that want to   |
|    |                 |         |     | be a part of the USDA        |
|    |                 |         |     | Portal) of these portals     |
|    |                 |         |     | under a USDA portal.         |
+----+-----------------+---------+-----+------------------------------+
| 4. | The solution    | Infrast | 1   | The solution should support  |
|    | should support  | ructure |     | delivery rich-media content  |
|    | multimedia      |         |     | such as streaming video,     |
|    | content.        |         |     | streaming audio and software |
|    |                 |         |     | distribution.                |
+----+-----------------+---------+-----+------------------------------+
| 5. | The solution    | Infrast | 1   | The solution should provide  |
|    | should          | ructure |     | support for low bandwidth    |
|    | accommodate     |         |     | for users with slow          |
|    | low-bandwidth   |         |     | connections.                 |
|    | users (baseline |         |     |                              |
|    | TBD).           |         |     |                              |
+----+-----------------+---------+-----+------------------------------+
| 6. | The solution    | Infrast | 3   | The ability to configure     |
|    | should have the | ructure |     | additional servers will      |
|    | ability to      |         |     | provide global deployment    |
|    | configure local |         |     | benefits for low bandwidth   |
|    | multimedia      |         |     | regions that can benefit     |
|    | servers to      |         |     | from installation of local   |
|    | store           |         |     | multimedia servers.          |
|    | multimedia      |         |     |                              |
|    | content         |         |     |                              |
|    | separate from   |         |     |                              |
|    | the portal      |         |     |                              |
|    | server.         |         |     |                              |
+----+-----------------+---------+-----+------------------------------+
| 7. | The solution    | Metrics | 1   | The solution should provide  |
|    | should provide  | Re      |     | a built-in console or        |
|    | a User Session  | porting |     | support third-party          |
|    | tracking        |         |     | consoles, for example        |
|    | console.        |         |     | WebTrends for user tracking. |
+----+-----------------+---------+-----+------------------------------+
| 8. | The solution    | Metrics | 2   | Metrics/Data Reporting can   |
|    | should provide  | Re      |     | integrate with standard      |
|    | Metrics         | porting |     | reporting solutions, for     |
|    | reporting tools |         |     | example Brio, Crystal        |
|    | that can be     |         |     | Reports.                     |
|    | integrated with |         |     |                              |
|    | thi             |         |     |                              |
|    | rd-party/custom |         |     |                              |
|    | reporting       |         |     |                              |
|    | tools.          |         |     |                              |
+----+-----------------+---------+-----+------------------------------+
| 9. | The solution    | Ope     | 2   | The solution should provide  |
|    | should provide  | rations |     | the ability to perform       |
|    | the ability to  |         |     | standard SQL queries on      |
|    | perform         |         |     | content and meta data.       |
|    | standard SQL    |         |     |                              |
|    | queries on      |         |     |                              |
|    | content and     |         |     |                              |
|    | meta data.      |         |     |                              |
+----+-----------------+---------+-----+------------------------------+
| 10 | The solution    | Scal    | 1   | The solution should support  |
| .  | should be able  | ability |     | the baseline users of both   |
|    | to support the  | and     |     | the pilot phase and the      |
|    | estimated       | Perf    |     | initial implementation       |
|    | initial         | ormance |     | phase.                       |
|    | baseline of     |         |     |                              |
|    | users for pilot |         |     |                              |
|    | phase (baseline |         |     |                              |
|    | TBD).           |         |     |                              |
+----+-----------------+---------+-----+------------------------------+
| 11 | The solution    | Scal    | 1   | The solution architecture    |
| .  | should be able  | ability |     | should be able to support    |
|    | to support the  | and     |     | the estimated concurrent     |
|    | estimated       | Perf    |     | users (TBD) for the early    |
|    | initial         | ormance |     | adopters.                    |
|    | baseline of     |         |     |                              |
|    | concurrent      |         |     |                              |
|    | users (baseline |         |     |                              |
|    | TBD).           |         |     |                              |
+----+-----------------+---------+-----+------------------------------+
| 12 | The solution    | Scal    | 1   | The solution should be       |
| .  | architecture    | ability |     | scalable to support the      |
|    | should          | and     |     | targeted users. (baseline    |
|    | eventually be   | Perf    |     | TBD)                         |
|    | scalable to     | ormance |     |                              |
|    | service         |         |     |                              |
|    | additional      |         |     |                              |
|    | users and       |         |     |                              |
|    | necessary       |         |     |                              |
|    | hardware        |         |     |                              |
|    | components      |         |     |                              |
|    | required to     |         |     |                              |
|    | support the     |         |     |                              |
|    | targeted number |         |     |                              |
|    | of users at     |         |     |                              |
|    | full            |         |     |                              |
|    | deployment.     |         |     |                              |
+----+-----------------+---------+-----+------------------------------+
| 13 | The solution    | Search  | 3   | The Portal solution should   |
| .  | should provide  | Engines |     | be able to support a         |
|    | plug-and-play   |         |     | plug-and-play approach for   |
|    | functionality   |         |     | existing USDA or Agency      |
|    | to support      |         |     | search engines, e.g.         |
|    | existing USDA   |         |     | Firstgov.com search.         |
|    | and Agency      |         |     |                              |
|    | search engines. |         |     |                              |
+----+-----------------+---------+-----+------------------------------+
| 14 | The solution    | S       | 1   | The eAuthentication          |
| .  | should be able  | ecurity |     | initiative will provide the  |
|    | to pass single  |         |     | single sign-on and           |
|    | sign-on to      |         |     | authorization. The solution  |
|    | various         |         |     | should have the ability to   |
|    | applications.   |         |     | pass on the single sign-on   |
|    |                 |         |     | to various applications      |
|    |                 |         |     | integrated with portal.      |
+----+-----------------+---------+-----+------------------------------+

## Web Content Management Technical Requirements 

The requirements groupings for the Web Content Management technical
requirements are as follows:

-   Application Programmability;

-   Execution Architecture;

-   Feature Set; and

-   Interoperability.

Table 4.3: Technical Requirements - Initiative Specific: Web Content
Management

+----+----------------+---------+-----+------------------------------+
| ** | **[Requirement | **[Gr   | **  | **[Requirement               |
| [\ | \#]            | ouping] | [Pr | Description]{.smallcaps}**   |
| #] | {.smallcaps}** | {.small | ior |                              |
| {. |                | caps}** | ity |                              |
| sm |                |         | ]{. |                              |
| al |                |         | sma |                              |
| lc |                |         | llc |                              |
| ap |                |         | aps |                              |
| s} |                |         | }** |                              |
| ** |                |         |     |                              |
+====+================+=========+=====+==============================+
| 1. | The solution   | Appl    | 2   | The solution should be easy  |
|    | should provide | ication |     | to adapt and configure for   |
|    | a configurable | P       |     | creating both developers and |
|    | user interface | rogramm |     | Web content managers.        |
|    | for template   | ability |     |                              |
|    | developers as  |         |     |                              |
|    | well as        |         |     |                              |
|    | content        |         |     |                              |
|    | managers.      |         |     |                              |
+----+----------------+---------+-----+------------------------------+
| 2. | The solution's | Ex      | 1   | The solution should support  |
|    | fundamental    | ecution |     | template development based   |
|    | technology     | Archi   |     | on use of XML/XSL and enable |
|    | should support | tecture |     | dynamic content              |
|    | use of         |         |     | transformation.              |
|    | XML/XSL. It    |         |     |                              |
|    | should comply  |         |     |                              |
|    | with standard  |         |     |                              |
|    | versions of    |         |     |                              |
|    | XML/XSL        |         |     |                              |
|    | parsers and    |         |     |                              |
|    | transformers.  |         |     |                              |
|    | Should also    |         |     |                              |
|    | support voice  |         |     |                              |
|    | XML as well as |         |     |                              |
|    | DHTMLs.        |         |     |                              |
+----+----------------+---------+-----+------------------------------+
| 3. | The solution   | Ex      | 1   | The solution should provide  |
|    | should provide | ecution |     | the capability of scaling in |
|    | the ability to | Archi   |     | terms of both Users as well  |
|    | deploy Web     | tecture |     | as additional repositories   |
|    | Content        |         |     | as Agencies may come         |
|    | Management     |         |     | on-board to use the          |
|    | solution       |         |     | solution.                    |
|    | incrementally. |         |     |                              |
|    |                |         |     | The solution should also     |
|    |                |         |     | address the                  |
|    |                |         |     | scaled-deployment of         |
|    |                |         |     | functionality for Agencies.  |
+----+----------------+---------+-----+------------------------------+
| 4. | The solution   | Ex      | 2   | The solution should provide  |
|    | should provide | ecution |     | deployment of multi-language |
|    | multi-language | Archi   |     | content from a single        |
|    | deployment and | tecture |     | project. It should have the  |
|    | management     |         |     | ability to provide           |
|    | from a single  |         |     | synchronization of multiple  |
|    | project.       |         |     | language versions of the     |
|    |                |         |     | content driven by specific   |
|    |                |         |     | local requirements.          |
|    |                |         |     |                              |
|    |                |         |     | The solution should support  |
|    |                |         |     | central management of        |
|    |                |         |     | linguistic assets to ensure  |
|    |                |         |     | language accuracy and        |
|    |                |         |     | consistency across multiple  |
|    |                |         |     | projects and vendors (for    |
|    |                |         |     | example translation memory,  |
|    |                |         |     | terminology databases,       |
|    |                |         |     | etc.).                       |
|    |                |         |     |                              |
|    |                |         |     | The solution should also     |
|    |                |         |     | provide integration of       |
|    |                |         |     | translation/adaptation       |
|    |                |         |     | specific tools (for example  |
|    |                |         |     | on- and off-line translation |
|    |                |         |     | workbenches, instant preview |
|    |                |         |     | in context,                  |
|    |                |         |     | language-to-language         |
|    |                |         |     | comparisons, etc.).          |
|    |                |         |     |                              |
|    |                |         |     | In case the above needs are  |
|    |                |         |     | not met through the          |
|    |                |         |     | solution, it should allow    |
|    |                |         |     | integration with             |
|    |                |         |     | Globalization Management     |
|    |                |         |     | Software.                    |
+----+----------------+---------+-----+------------------------------+
| 5. | The solution   | Ex      | 2   | The solution should enable   |
|    | should support | ecution |     | publishing to multiple       |
|    | deployment of  | Archi   |     | formats, such as: HTML       |
|    | content        | tecture |     | (Web), printed, PDF,         |
|    | through        |         |     | hand-held (WAP) etc. The     |
|    | multiple       |         |     | solution should also support |
|    | channels using |         |     | dynamic repurposing of the   |
|    | the            |         |     | content for multiple         |
|    | appropriate    |         |     | devices.                     |
|    | formats (WAP,  |         |     |                              |
|    | PDA, HTML,     |         |     | The solution should also     |
|    | XML, etc).     |         |     | enable adding support for    |
|    |                |         |     | additional formats, which    |
|    |                |         |     | will be necessary as new     |
|    |                |         |     | standards evolve.            |
|    |                |         |     |                              |
|    |                |         |     | To promote high quality in   |
|    |                |         |     | every format, the solution   |
|    |                |         |     | should allow separation of   |
|    |                |         |     | content from presentation at |
|    |                |         |     | the time of authoring to     |
|    |                |         |     | allow creation of distinct   |
|    |                |         |     | layouts for each output.     |
+----+----------------+---------+-----+------------------------------+
| 6. | The solution   | Ex      | 2   | The solution should support  |
|    | should support | ecution |     | the use of multiple Document |
|    | DTD (Document  | Archi   |     | Type Definitions (DTD) for   |
|    | Type           | tecture |     | template development to      |
|    | Definition).   |         |     | allow for Agency specific    |
|    |                |         |     | template requirements.       |
+----+----------------+---------+-----+------------------------------+
| 7. | The solution   | Ex      | 3   | The solution should allow    |
|    | should enable  | ecution |     | content authors/template     |
|    | distributed    | Archi   |     | designers to contribute      |
|    | template and   | tecture |     | content concurrently from    |
|    | content        |         |     | different locations.         |
|    | development.   |         |     |                              |
+----+----------------+---------+-----+------------------------------+
| 8. | The solution   | Feature | 1   | The solution should provide  |
|    | should support | Set     |     | automatic maintenance of     |
|    | automated      |         |     | hyperlinks, at least between |
|    | management of  |         |     | objects in the repository.   |
|    | links          |         |     | For example if a page is     |
|    | (including     |         |     | moved from one folder in the |
|    | manually       |         |     | repository to another, the   |
|    | created and    |         |     | solution should              |
|    | edited).       |         |     | automatically update all     |
|    |                |         |     | pages that refer to the URL  |
|    |                |         |     | of the moved page with the   |
|    |                |         |     | new URL.                     |
+----+----------------+---------+-----+------------------------------+
| 9. | The solution   | Feature | 1   | Meta data can be viewed as a |
|    | should provide | Set     |     | number of attributes         |
|    | Metadata       |         |     | associated with a specific   |
|    | Management     |         |     | class of objects (for        |
|    | tool to enable |         |     | example on a Web page the    |
|    | search and     |         |     | objects would include the    |
|    | correlation    |         |     | header, the footer, images,  |
|    | between        |         |     | audio content or any         |
|    | multiple       |         |     | database fields etc).        |
|    | repositories.  |         |     |                              |
|    |                |         |     | The solution should provide  |
|    |                |         |     | the ability to define and    |
|    |                |         |     | manage meta data information |
|    |                |         |     | about the objects being      |
|    |                |         |     | stored.                      |
|    |                |         |     |                              |
|    |                |         |     | This allows support of key   |
|    |                |         |     | functions such as search     |
|    |                |         |     | classification,              |
|    |                |         |     | personalization, and         |
|    |                |         |     | correlation between multiple |
|    |                |         |     | repositories                 |
+----+----------------+---------+-----+------------------------------+
| 10 | The solution   | Feature | 2   | The solution should support  |
| .  | should support | Set     |     | all forms of digital         |
|    | multimedia     |         |     | content, including eBooks,   |
|    | content.       |         |     | video, streaming music and   |
|    |                |         |     | software for distribution.   |
+----+----------------+---------+-----+------------------------------+
| 11 | The solution   | Feature | 1   | The solution should enable   |
| .  | should support | Set     |     | access to content and        |
|    | access to      |         |     | content attributes across    |
|    | content and    |         |     | repositories.                |
|    | content        |         |     |                              |
|    | attributes in  |         |     |                              |
|    | all Web        |         |     |                              |
|    | Content        |         |     |                              |
|    | Management     |         |     |                              |
|    | repositories.  |         |     |                              |
+----+----------------+---------+-----+------------------------------+
| 12 | The solution   | In      | 2   | Some of the capabilities     |
| .  | should provide | teroper |     | provided by Digital Rights   |
|    | integration    | ability |     | Management tools are as      |
|    | with third     |         |     | follows:                     |
|    | party digital  |         |     |                              |
|    | rights         |         |     | -   Management of user       |
|    | management     |         |     |     access to digital        |
|    | solutions.     |         |     |     content for example      |
|    |                |         |     |     Audio, video, images;    |
|    |                |         |     |                              |
|    |                |         |     | -   Watermarking facility    |
|    |                |         |     |     for images; and          |
|    |                |         |     |                              |
|    |                |         |     | -   Pay-per-view enforcement |
|    |                |         |     |     for the digital content. |
+----+----------------+---------+-----+------------------------------+
| 13 | The solution   | In      | 2   | Digital asset management     |
| .  | should allow   | teroper |     | solutions provide tools to   |
|    | integration    | ability |     | manage the multimedia        |
|    | with third     |         |     | content on the servers       |
|    | party digital  |         |     | including indexing, creating |
|    | asset          |         |     | libraries etc.               |
|    | management     |         |     |                              |
|    | solutions.     |         |     |                              |
+----+----------------+---------+-----+------------------------------+
| 14 | The solution   | In      | 1   | The solution should provide  |
| .  | should support | teroper |     | support for existing USDA    |
|    | re-use of      | ability |     | Web assets including         |
|    | organizational |         |     | existing Web sites,          |
|    | assets and     |         |     | templates, style sheets,     |
|    | provide tools  |         |     | multimedia etc. The solution |
|    | to mass import |         |     | should also provide Users    |
|    | the existing   |         |     | (Developers and Web Content  |
|    | content.       |         |     | managers) tools to re-use    |
|    |                |         |     | these assets for example the |
|    |                |         |     | ability to mass import       |
|    |                |         |     | images, Web sites etc.       |
+----+----------------+---------+-----+------------------------------+
| 15 | The solution   | S       | 1   | Digital Signatures are extra |
| .  | should support | ecurity |     | data appended to the         |
|    | Digital        |         |     | document/message that        |
|    | signatures.    |         |     | identifies and authenticates |
|    |                |         |     | the document/message owner   |
|    |                |         |     | using public key encryption. |
|    |                |         |     |                              |
|    |                |         |     | The solution should support  |
|    |                |         |     | appending Digital Signatures |
|    |                |         |     | to documents.                |
+----+----------------+---------+-----+------------------------------+
| 16 | The solution   | Distr   | 1   | The solution should be able  |
| .  | should         | ibution |     | to reside on a network that  |
|    | accommodate    | and     |     | supports the transport of    |
|    | various and    | D       |     | various bandwidths of data.  |
|    | expanding      | elivery |     |                              |
|    | levels of      |         |     |                              |
|    | bandwidths of  |         |     |                              |
|    | data.          |         |     |                              |
+----+----------------+---------+-----+------------------------------+
| 17 | The solution   | Distr   | 1   | The solution should support  |
| .  | should allow   | ibution |     | mirroring of content across  |
|    | for the        | and     |     | all environments;            |
|    | transfer of    | D       |     | development, testing,        |
|    | web content    | elivery |     | pre-production and           |
|    | between        |         |     | production to ease the       |
|    | servers and    |         |     | development and solution     |
|    | site mirroring |         |     | lifecycle process.           |
|    | including      |         |     |                              |
|    | moving across  |         |     |                              |
|    | development    |         |     |                              |
|    | testing        |         |     |                              |
|    | staging and    |         |     |                              |
|    | production     |         |     |                              |
|    | environments.  |         |     |                              |
+----+----------------+---------+-----+------------------------------+

##  Document Management Technical Requirements 

The requirements groupings for the Document Management technical
requirements are as follows:

-   Execution Architecture;

-   Feature Set;

-   Interoperability;

-   Scalability and Performance; and

-   Security.

Table 4.4: Technical Requirements - Initiative Specific: Document
Management

+----+----------------+---------+-----+------------------------------+
| ** | **[Requirement | **[Gr   | **  | **[Requirement               |
| [\ | \#]            | ouping] | [Pr | Description]{.smallcaps}**   |
| #] | {.smallcaps}** | {.small | ior |                              |
| {. |                | caps}** | ity |                              |
| sm |                |         | ]{. |                              |
| al |                |         | sma |                              |
| lc |                |         | llc |                              |
| ap |                |         | aps |                              |
| s} |                |         | }** |                              |
| ** |                |         |     |                              |
+====+================+=========+=====+==============================+
| 1. | The solution   | Ex      | 1   | The solution should enable   |
|    | should enable  | ecution |     | access to documents and      |
|    | access to      | Archi   |     | their attributes their       |
|    | documents with | tecture |     | respective document          |
|    | their          |         |     | repositories.                |
|    | attributes and |         |     |                              |
|    | their          |         |     |                              |
|    | respective     |         |     |                              |
|    | document       |         |     |                              |
|    | repositories.  |         |     |                              |
+----+----------------+---------+-----+------------------------------+
| 2. | The solution   | Ex      | 2   | The solution should provide  |
|    | should support | ecution |     | support for existing USDA    |
|    | re-use of      | Archi   |     | document assets including    |
|    | organizational | tecture |     | existing documents,          |
|    | assets and     |         |     | templates (for example Word  |
|    | provide tools  |         |     | templates, fax templates),   |
|    | to mass import |         |     | etc. The solution should     |
|    | the existing   |         |     | also provide Users tools to  |
|    | documents.     |         |     | re-use these assets for      |
|    |                |         |     | example the ability to mass  |
|    |                |         |     | import documents.            |
+----+----------------+---------+-----+------------------------------+
| 3. | The solution   | Ex      | 1   | The solution should allow    |
|    | should allow   | ecution |     | document authors/template    |
|    | distributed    | Archi   |     | designers to contribute      |
|    | authoring and  | tecture |     | documents concurrently from  |
|    | support        |         |     | different locations.         |
|    | concurrent     |         |     |                              |
|    | authoring.     |         |     |                              |
+----+----------------+---------+-----+------------------------------+
| 4. | The solution   | Feature | 1   | The community tools          |
|    | should support | Set     |     | including but not limited to |
|    | collaboration. |         |     | the following:               |
|    |                |         |     |                              |
|    |                |         |     | -   Workgroup community: The |
|    |                |         |     |     solution should be able  |
|    |                |         |     |     to provide creation,     |
|    |                |         |     |     maintenance and support  |
|    |                |         |     |     for Web-based user group |
|    |                |         |     |     communities with access  |
|    |                |         |     |     to shared content,       |
|    |                |         |     |     calendars, discussion    |
|    |                |         |     |     boards, chat rooms and   |
|    |                |         |     |     online meeting rooms     |
|    |                |         |     |     with Webcam, whiteboard  |
|    |                |         |     |     and application support  |
|    |                |         |     |     facility.                |
|    |                |         |     |                              |
|    |                |         |     | -   Third party work group   |
|    |                |         |     |     data sharing: The        |
|    |                |         |     |     solution should be able  |
|    |                |         |     |     to provide integration   |
|    |                |         |     |     with third party         |
|    |                |         |     |     collaborative content    |
|    |                |         |     |     from applications such   |
|    |                |         |     |     as Lotus Notes,          |
|    |                |         |     |     Microsoft Exchange etc.  |
+----+----------------+---------+-----+------------------------------+
| 5. | The solution's | Feature | 1   | The solution should support  |
|    | fundamental    | Set     |     | template development both in |
|    | technology     |         |     | native application and using |
|    | should support |         |     | XML.                         |
|    | use of         |         |     |                              |
|    | XML/XSL.       |         |     |                              |
+----+----------------+---------+-----+------------------------------+
| 6. | The solution   | Feature | 1   | The solution should support  |
|    | should support | Set     |     | version control of           |
|    | version        |         |     | documents.                   |
|    | control.       |         |     |                              |
+----+----------------+---------+-----+------------------------------+
| 7. | The solution   | Feature | 2   | The solution should provide  |
|    | should allow   | Set     |     | a capability for the         |
|    | for creation   |         |     | grouping of documents into   |
|    | of association |         |     | logical groupings. These     |
|    | between        |         |     | groups would be created by   |
|    | documents.     |         |     | users and would constitute   |
|    |                |         |     | of assets that have related  |
|    |                |         |     | contents or would be used    |
|    |                |         |     | together.                    |
+----+----------------+---------+-----+------------------------------+
| 8. | The solution   | In      | 1   | The solution should support  |
|    | should be      | teroper |     | native document formats to   |
|    | based on open  | ability |     | allow users to edit and      |
|    | standards like |         |     | create documents in their    |
|    | ODMA (Open     |         |     | native formats (example:     |
|    | Document       |         |     | Microsoft Word).             |
|    | Management     |         |     |                              |
|    | API) to        |         |     |                              |
|    | provide        |         |     |                              |
|    | connectivity   |         |     |                              |
|    | with native    |         |     |                              |
|    | document       |         |     |                              |
|    | formats.       |         |     |                              |
+----+----------------+---------+-----+------------------------------+
| 9. | The solution   | In      | 2   | The solution should be able  |
|    | should support | teroper |     | to integrate with fax        |
|    | integration    | ability |     | servers.                     |
|    | with eFax      |         |     |                              |
|    | capabilities.  |         |     |                              |
+----+----------------+---------+-----+------------------------------+
| 10 | The solution   | In      | 2   | The solution should allow    |
| .  | should support | teroper |     | integration to accommodate   |
|    | integration    | ability |     | ingestion of scanned assets. |
|    | with USDA's    |         |     |                              |
|    | existing       |         |     |                              |
|    | desktop/high   |         |     |                              |
|    | speed scanning |         |     |                              |
|    | capability.    |         |     |                              |
+----+----------------+---------+-----+------------------------------+
| 11 | The solution   | In      | 2   | The solution should support  |
| .  | should support | teroper |     | integration of               |
|    | the ability to | ability |     | Personalization console.     |
|    | integrate      |         |     |                              |
|    | third-party    |         |     |                              |
|    | p              |         |     |                              |
|    | ersonalization |         |     |                              |
|    | solutions.     |         |     |                              |
+----+----------------+---------+-----+------------------------------+
| 12 | The solution   | Scal    | 1   | The solution should provide  |
| .  | should provide | ability |     | the capability of scaling in |
|    | the ability to | &       |     | terms of both Users as well  |
|    | deploy the     | Perf    |     | as additional repositories   |
|    | Document       | ormance |     | as Agencies may come         |
|    | Management     |         |     | on-board to use the          |
|    | solution       |         |     | solution.                    |
|    | incrementally. |         |     |                              |
|    |                |         |     | The solution should also     |
|    |                |         |     | address the                  |
|    |                |         |     | scaled-deployment of         |
|    |                |         |     | functionality for Agencies.  |
+----+----------------+---------+-----+------------------------------+
| 13 | The solution   | Scal    | 3   | The solution should be       |
| .  | should be able | ability |     | scalable to integrate        |
|    | to integrate   | &       |     | Service Bureau imaging       |
|    | with Service   | Perf    |     | solutions for document       |
|    | Bureau Imaging | ormance |     | imaging and indexing.        |
|    | applications.  |         |     |                              |
|    |                |         |     | Service Bureau Imaging       |
|    |                |         |     | solutions provide high-speed |
|    |                |         |     | scanning of Paper records    |
|    |                |         |     | along with advanced features |
|    |                |         |     | such as OCR and automated    |
|    |                |         |     | index-matching (meta-data)   |
|    |                |         |     | with SQL databases or        |
|    |                |         |     | external files.              |
+----+----------------+---------+-----+------------------------------+
| 14 | The solution   | S       | 1   | Digital Signatures are extra |
| .  | should support | ecurity |     | data appended to the         |
|    | Digital        |         |     | document/message that        |
|    | signatures.    |         |     | identifies and authenticates |
|    |                |         |     | the document/message owner   |
|    |                |         |     | using public key encryption. |
|    |                |         |     |                              |
|    |                |         |     | The solution should support  |
|    |                |         |     | appending Digital Signatures |
|    |                |         |     | to documents.                |
+----+----------------+---------+-----+------------------------------+

## Data Management Technical Requirements

Data management provides support for other initiatives by making
available guidelines and policies for data definition and use. Please
review the eDeployment Concept of Operations document for details. In
the role of ensuring data standards are followed across the Department,
the data management team members will follow a set of objectives for all
development efforts including other eDeployment initiatives. The nature
of these objectives is as follows:

1.  The data architecture of an initiative should be documented.

2.  The initiative should create, maintain and publish a data
    dictionary.

3.  Data Model of the proposed solution should be documented and made
    available.

4.  The data architects should provide standards to enable integration
    with Enterprise Architecture.

5.  The application development team, with the assistance of the data
    architects should identify systems where data elements may already
    exist. The team shall attempt to reuse existing data wherever
    appropriate.

6.  Applications should adhere to policies, standards and guidelines
    defined by the data architects.

7.  Proper constraints should be built into database to ensure data
    integrity, quality and validity.

8.  The appropriate database performance and volume monitoring processes
    and tools should be in place.

9.  An index analysis should be performed and proper indexes built for
    the database.

10. With the aid of the data architects, the application development
    team should assess if there is a need to build unified database of
    records (such as data warehouse), conduct database inventory to
    address application data needs. The data architects team should also
    provide standards for integrating existing data with data
    warehouses.

11. The application team should have a data backup & recovery plan in
    place.

12. The application team should have a security plan defined to ensure
    application data security.

13. Applications should adhere to XML standards.

14. The data architects should set guidelines for metadata information
    across board to create consistent metadata database.

As the eDeployment and Strategic eGovernment solutions mature, this list
of objectives will evolve and grow to guide application development
efforts in building databases that will be interoperable and
non-redundant.

## Web Presence Technical Requirements

Similar to the Data Management initiative, the Web Presence initiative
provides standards for other development efforts. These standards, in
the form of requirements are as follows:

1.  The Web application should adhere to look, feel and navigation
    standards as outlined by the Web Presence initiative.

2.  The Web application should meet all accessibility requirements
    defined under [Section
    508](http://www.section508.gov/index.cfm?FuseAction=Content&ID=11)
    of the US Government Rehabilitation Act.

3.  Page layout should be designed to fit into 640x480 pixel screen
    resolution across the Department and its Agencies.

4.  All Web applications should support text-only browsers.

5.  The Web applications should support at a minimum the following
    browsers:

    -   Internet Explorer (IE) version 5.0 and above;

    -   Netscape Navigator version 4.5 and above; and

    -   Lynx.

> Additionally support of AOL, Opera and Mozilla browsers should be
> considered.

6.  Web applications should not depend on a particular browser window,
    font size or color table to be readable. They should not depend on
    any visual presentation, except where the information content is
    inherently visual in nature.

7.  The eDeployment Enabler solutions should support streaming audio and
    video in multiple formats. The solutions should also provide users
    with selection tools for Internet connections to access the media.
    At a minimum the following formats should be supported for streaming
    audio and video:

    -   Real player (baseline version TBD);

    -   Windows Media Player (baseline version TBD); and

    -   QuickTime (baseline version TBD).

8.  It is advisable to create all Web content (not including images,
    audio or video) using the enterprise Web Content Management
    solution.

9.  Web applications should provide both client-side as well as server
    side controls.

10. Client-side scripting languages such as JavaScript, VBScript,
    JScript should be used, provided it does not detract from the
    page\'s accessibility to browsers not supporting or enabling this
    feature.

11. Use of more than one frameset-based layout on a site should be
    avoided.

12. Content available in more than one language should be presented as
    parallel hierarchies in the languages concerned and every piece of
    content in a multilingual hierarchy should include links to the
    other languages available.

13. Style sheets should not be used in a manner detrimental to
    accessibility for browsers not supporting this feature.

14. Style sheets should not be visible to browsers that do not support
    them.

15. Standards should be developed for image size and image maps.

16. The Web content should have low upload-time. This can be achieved
    through page design so that pages download in approximately 20
    seconds or less with a 28.8 connection.

17. All Web applications should follow the Department and Agency
    navigational standards.

# Assumptions

The assumptions section will list all the assumptions there were made
about the different initiatives in the creation of technical
requirements. Changes in assumptions may add to or modify list of
technical requirements.

Table 5: Initiative Assumptions

+-------+--------------+-----------------------------------------------+
| **[N  | **[I         | **[Assumption]{.smallcaps}**                  |
| umber | nitiative]{. |                                               |
| ]{.sm | smallcaps}** |                                               |
| allca |              |                                               |
| ps}** |              |                                               |
+=======+==============+===============================================+
| 1.    | Portal       | The portal solution will be an integrated     |
|       |              | solution that is comprised of one or more     |
|       |              | COTS and/or custom components.                |
+-------+--------------+-----------------------------------------------+
| 2.    | Portal       | The Portal solution will be deployed          |
|       |              | enterprise-wide.                              |
+-------+--------------+-----------------------------------------------+
| 3.    | Portal       | Deployment of portal services will occur in   |
|       |              | increments beginning with early adopter       |
|       |              | Agencies and eventually extending across the  |
|       |              | enterprise.                                   |
+-------+--------------+-----------------------------------------------+
| 4.    | Portal       | eAuthentication initiative will provide       |
|       |              | single-sign-on for the Portal and all content |
|       |              | and applications available through Portal.    |
+-------+--------------+-----------------------------------------------+
| 5.    | Portal       | All available content [may not]{.underline}   |
|       |              | require access through Single sign-on.        |
+-------+--------------+-----------------------------------------------+
| 6.    | Portal       | The Portal will be integrated with federated  |
|       |              | search engine that allow access to agency     |
|       |              | content repositories, including document      |
|       |              | management solutions and repositories, e-mail |
|       |              | servers, and content management solution and  |
|       |              | repositories.                                 |
+-------+--------------+-----------------------------------------------+
| 7.    | Portal       | The Department and its Agencies may create    |
|       |              | sub-portals.                                  |
+-------+--------------+-----------------------------------------------+
| 8.    | Portal       | A wide range of content will be available     |
|       |              | through Department Portal including but not   |
|       |              | limited to the following:                     |
|       |              |                                               |
|       |              | -   Static Web Content;                       |
|       |              |                                               |
|       |              | -   Dynamically generated pages sourced from  |
|       |              |     databases etc.;                           |
|       |              |                                               |
|       |              | -   Training Manuals, Policies, Procedures    |
|       |              |     etc.;                                     |
|       |              |                                               |
|       |              | -   General Business documents;               |
|       |              |                                               |
|       |              | -   Community based content;                  |
|       |              |                                               |
|       |              | -   Newsletters;                              |
|       |              |                                               |
|       |              | -   Chatting and virtual meeting features     |
|       |              |     including Web telecasting features; and   |
|       |              |                                               |
|       |              | -   Access to applications and databases.     |
+-------+--------------+-----------------------------------------------+
| 9.    | Web Content  | The Web Content Management will be the tool   |
|       | Management   | used to manage Web content across the         |
|       |              | Department.                                   |
+-------+--------------+-----------------------------------------------+
| 10.   | Web Content  | CM will be deployed enterprise-wide.          |
|       | Management   |                                               |
+-------+--------------+-----------------------------------------------+
| 11.   | Web Content  | Deployment of CM will occur in increments     |
|       | Management   | beginning with early adopter Agencies and     |
|       |              | eventually extending across the enterprise.   |
+-------+--------------+-----------------------------------------------+
| 12.   | Web Content  | CM system will be integrated with federated   |
|       | Management   | search engine that allow access to agency     |
|       |              | content repositories, including portal        |
|       |              | solution, document management solution,       |
|       |              | e-mail servers, and repositories.             |
+-------+--------------+-----------------------------------------------+
| 13.   | Web Content  | CM will be integrated with the                |
|       | Management   | eAuthentication Solution.                     |
+-------+--------------+-----------------------------------------------+
| 14.   | Web Content  | The Department and its Agencies will develop  |
|       | Management   | and use content templates extensively.        |
+-------+--------------+-----------------------------------------------+
| 15.   | Web Content  | The Department and its Agencies will re-use   |
|       | Management   | content templates.                            |
+-------+--------------+-----------------------------------------------+
| 16.   | Web Content  | A wide range of content will be published     |
|       | Management   | using the CM including but not limited to the |
|       |              | following:                                    |
|       |              |                                               |
|       |              | -   Static Web Content;                       |
|       |              |                                               |
|       |              | -   Dynamically generated pages sourced from  |
|       |              |     databases etc.;                           |
|       |              |                                               |
|       |              | -   Training Manuals, Policies, Procedures    |
|       |              |     etc.;                                     |
|       |              |                                               |
|       |              | -   General Business documents;               |
|       |              |                                               |
|       |              | -   Community based content; and              |
|       |              |                                               |
|       |              | -   Newsletters.                              |
+-------+--------------+-----------------------------------------------+
| 17.   | Document     | The Document Management System will be the    |
|       | Management   | tool used to manage documents/records across  |
|       |              | the Department.                               |
+-------+--------------+-----------------------------------------------+
| 18.   | Document     | Documents existing in electronic formats only |
|       | Management   | will be integrated with the DM.               |
+-------+--------------+-----------------------------------------------+
| 19.   | Document     | Legacy systems and paper-based documents will |
|       | Management   | need to be migrated into the DM as the Agency |
|       |              | is migrated into the solution.                |
+-------+--------------+-----------------------------------------------+
| 20.   | Document     | For the purpose of this technical             |
|       | Management   | requirements document and the USDA enablers   |
|       |              | initiatives, the term document refers to      |
|       |              | files in various formats including but not    |
|       |              | limited to Word, Excel, PowerPoint, Visio,    |
|       |              | Adobe Acrobat .pdf, Images etc.               |
+-------+--------------+-----------------------------------------------+
| 21.   | Document     | DM will be deployed enterprise-wide.          |
|       | Management   |                                               |
+-------+--------------+-----------------------------------------------+
| 22.   | Document     | Deployment of DM will occur in increments     |
|       | Management   | beginning with early adopter Agencies and     |
|       |              | eventually extending across the enterprise.   |
+-------+--------------+-----------------------------------------------+
| 23.   | Document     | The DM system will be integrated with the     |
|       | Management   | Portal Solution, Web Content Management       |
|       |              | Solution and federated search engines that    |
|       |              | allow access to agency content repositories,  |
|       |              | including e-mail servers, portal and content  |
|       |              | management repositories.                      |
+-------+--------------+-----------------------------------------------+
| 24.   | Document     | DM will be integrated with the                |
|       | Management   | eAuthentication Solution.                     |
+-------+--------------+-----------------------------------------------+
| 25.   | Document     | DM will be integrated with Web Content        |
|       | Management   | Management System.                            |
+-------+--------------+-----------------------------------------------+
| 26.   | Document     | The Department and its Agencies will develop  |
|       | Management   | and use document templates extensively.       |
+-------+--------------+-----------------------------------------------+
| 27.   | Document     | The Department and its Agencies will re-use   |
|       | Management   | document templates.                           |
+-------+--------------+-----------------------------------------------+
| 28.   | Data         | The scope of this initiative is limited to    |
|       | Management   | Databases.                                    |
+-------+--------------+-----------------------------------------------+
| 29.   | Data         | These guidelines will support existing        |
|       | Management   | Department-wide guidelines subject to         |
|       |              | re-evaluation.                                |
+-------+--------------+-----------------------------------------------+
| 30.   | Data         | These guidelines will be applicable to all    |
|       | Management   | new databases designed and maintained by the  |
|       |              | Department and its Agencies.                  |
+-------+--------------+-----------------------------------------------+
| 31.   | Data         | Upgrade of existing systems will adhere to    |
|       | Management   | data management standards on components being |
|       |              | modified.                                     |
+-------+--------------+-----------------------------------------------+
| 32.   | Web Presence | The scope of this initiative is limited to    |
|       |              | the Web Content including Web pages, portal   |
|       |              | presentation view and Web applications.       |
+-------+--------------+-----------------------------------------------+
| 33.   | Web Presence | These guidelines will support existing        |
|       |              | Department-wide guidelines subject to         |
|       |              | re-evaluation.                                |
+-------+--------------+-----------------------------------------------+
| 34.   | Web Presence | The guidelines will be applicable to all Web  |
|       |              | content available to citizens, employees and  |
|       |              | partners.                                     |
+-------+--------------+-----------------------------------------------+