Waterfall Methodology: Technology Solution Requirements Process

PURPOSE ▪ SCOPE ▪ PROCESS DESCRIPTION ▪ PROCESS DIAGRAM ▪ PROCESS INPUTS/OUTPUTS ▪ PROCESS RELATIONSHIPS ▪ ROLES AND RESPONSIBILITIES ▪ SUPPORTING DOCUMENTATION ▪ REVISION HISTORY

Process Owner: Manager, Solutions Development and Support

Note: An owner must be a PCES-level manager or higher.

This process establishes standard tools and processes for the TSLC Waterfall Requirements phase within the Postal Service Technical Environment.

1. PURPOSE

The purpose of the Technology Solution Requirements process is to discover and document business and technology requirements to be utilized in the development of a Technology Solution.  The final approved Technology Solution Requirements will serve as the foundation for the Technology Solution Analysis & Design and Technology Solution Build processes.

2. SCOPE

The Technology Solution Requirements process applies to all Technology Solution projects including, but not limited to:

This Technology Solution Requirements process must be followed by all internal and external service providers.  This process does not include activities related to the development of the initial business concept and initial business case.

Important: All “Freeze Waiver Approvals” are stored in the Technology Solution Requirements – Approved folder for the project(s) to which the freeze applies.

3. PROCESS DESCRIPTION

The Technology Solution Requirements process consists of the following sub-processes:

1. Develop Technology Solution Requirements

This activity relates to the collection of all the Technology Solution requirements associated with customer business needs.  It is recommended that the Technology Solution Life Cycle (TSLC) requirements template be used to facilitate ensuring all business and technical requirements are defined.

2. Conduct Business Impact Assessment (BIA)

The TSPM and ISSO complete the BIA Template.  Security requirements are defined for all applications commensurate with the risks. In addition to the baseline security requirements that apply to all applications, mandatory security requirements (based on application sensitivity and criticality, federal legislation, federal regulations, federal directives, industry requirements, the operating environment, and the risks associated with the information resource) and discretionary requirements (based on generally accepted industry practices) are determined. 

Discretionary security requirements are recommended by the ISSO and are implemented at the discretion of the executive sponsor.

3. Solution Stakeholders Review Requirements

The TSC coordinates review by all Solution Stakeholders (i.e., Customer, Technology Service Providers, Portfolio) for validation of the requirements.

This review must include the Enterprise Architecture Committee for applicable Technology Solutions (as outlined in the Enterprise Architecture Policy).  Upon successful completion of this review the EA Committee provides EA Checkpoint 1 acknowledgement.

4. Technology Solution Requirements with Approval

After all Solution Stakeholders have reviewed and agreed the requirements document is complete, the Customer and TSP Stakeholders will sign the requirements as approved.

5. Implement Change Control

Upon formal approval, the Technology Solution Requirements is placed under change control. Any changes to the requirements document must go through the CCB process.

4. PROCESS DIAGRAM

In this section, there is a process diagram of the Technology Solution Requirements process. The process steps are stacked vertically in the center; as each process step is completed, there is a downward arrow to the next process step in the sequence. On the left side are Inputs to the process step in the center from which there is an Output. For some process steps, there may not be an input and/or an output. The first process step is Develop Requirements for which the inputs are the Business Needs Statement; Documented Approval and Funding to Proceed; and the Initial Project Plan. The output is Technology Solution Requirements. The second process step is Conduct Business Impact Assessment; this process step does not have a corresponding input, but its output is the Business Impact Assessment. The third process step is Solution Stakeholders Review Requirements; this process step does not have a corresponding input, but the outputs are the Traceability Test Matrix and EA Checkpoint 1. The fourth process step is a decision point as to whether or not the project is Approved. If the project is not approved, the process ends. If the project is approved, the fifth process step is Documented Approval. This process step does not have a corresponding input; however, its corresponding output is Technology Solution Requirements with Approval. The Technology Solution Requirements with Approval artifact has an asterisk to indicate that it is a Baseline requirement. The sixth process step is Change Management. This process step does not have a corresponding input or output. There are no further process steps for this process.

An asterisk (*) denotes a Baseline requirement.

5. PROCESS INPUTS/OUTPUTS

Inputs

Outputs

An asterisk (*) denotes a Baseline requirement.

6. PROCESS RELATIONSHIPS

In this section, there is a relationship diagram of the Technology Solution Requirements process. There are eight processes which comprise the USPS Technology Solution Lifecycle (TSLC) Technology Solution Planning methodology. The processes are aligned vertically as bookends next to each other, specifically: the first process is Initiate & Plan; the second process is Technology Solution Requirements; the third process is Analysis & Design; the fourth process is Technology Solution Build; the fifth process is System Integration Testing (SIT); the sixth process is Customer Acceptance Testing (CAT); the seventh process is Governance Compliance; and the eighth process is Release Management. For all of the processes, there are both Inputs and Outputs to the planning activity. Within the Technology Solution Requirements process, the inputs for the planning activity are Business Needs Statement (from the Customer); Documented Approval and Funding to Proceed; and Initial Project Plan. Within the Technology Solution Requirements process, there are also several outputs. The output from the Requirements process is EA Checkpoint 1. Outputs to the Analysis & Design process are Technology Solution Requirements with Approval; Business Impact Assessment; and Traceability Test Matrix. The Technology Solution Requirements with Approval artifact has an asterisk to indicate that it is a Baseline requirement. In addition to being an output to the Analysis & Design process, the Technology Solution Requirements with Approval is also an output to the Technology Solution Build process, the System Integration Testing (SIT) process, the Customer Acceptance Testing (CAT) process, and the Governance Compliance process. As previously noted, the Technology Solution Requirements with Approval artifact has an asterisk to indicate that it is a Baseline requirement. There are no additional outputs of the Technology Solution Requirements process.

An asterisk (*) denotes a Baseline requirement.

7. ROLES AND RESPONSIBILITIES

8. SUPPORTING DOCUMENTATION

For access to the following documents, contact the US Postal Service. See Publication 5, Let's Do Business for further information about local US Postal Service contacts.

9. REVISION HISTORY

Version #1.0  
Section(s) Revised: N/A
Revision Description: Baseline
Revision Date:  
   
Version #1.1  
Section(s) Revised: Title, 8 – Supporting Documentation
Revision Description: Added “Waterfall”
Section(s) Revised: Introduction
Revision Description: Updated Process Owner to Manager, Solutions Development and Support to reflect current organization
Section(s) Revised: 4 – Process Description, 5 – Process Diagram, 7 – Process Relationships
Revision Description: Removed text indicating that TSR template is mandatory; Added indicators and text for baseline artifacts
Section(s) Revised: 5 – Process Diagram, 7 – Process Relationships
Revision Description: Added text in non-displayable format for Section 508 compliance
Section(s) Revised: 4 – Process Description, 5 – Process Diagram, 7 – Process Relationships
Revision Description: Added indicators and text for baseline artifacts
Revision Date: 02/22/2012
   
Version #1.2  
Section(s) Revised: All
Revision Description: This document was made Section 508 compliant and was converted to HTML.
Revision Date:  FY12/Q3