Sprint 0 / Requirements Process

PURPOSESCOPEPROCESS DESCRIPTIONPROCESS INPUTS/OUTPUTSSUPPORTING DOCUMENTATIONREVISION HISTORY

Process Owner: Manager, Business Relationship Management

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

This document establishes standard processes for the Technology Solution Life Cycle (TSLC) Agile Sprint 0 and Waterfall Requirements phase within the Postal Service Technical Environment. It addresses both Agile and Waterfall methodology.

PURPOSE

The final approved Technology Solution Requirements (TSRs) will serve as the foundation for the Agile Sprint 0-n process and the Waterfall Analysis and Design and Build processes.

The purpose of the Sprint 0 / Requirements process is to:

SCOPE

This process applies to all:

PROCESS DESCRIPTION

The Technology Solution Requirements process consists of the following subprocesses:

  1. Follow the Certification and Accreditation Process.
  2. The Business Relationship Management Program Manager (BRM PM) coordinates this task.

    For security-related processes and artifacts, follow the Certification and Accreditation Process as described in the Handbook AS-805A, Information Resource Certification and Accreditation Process.

  3. PCI In-Scope Only: Develop and Maintain Secure PCI In-Scope Systems and Applications.
  4. The BRM PM coordinates this task.

    Ensure that all requirements listed and referenced in the Develop and Maintain Secure PCI In-Scope Systems and Applications are met.

  5. Create/Manage Initial Requirements.

    1. Develop Initial Requirements.
    2. The BRM PM coordinates this activity.

      This activity relates to the collection of all the TSRs associated with business owner (customer) business needs. The requirements developed in Sprint 0/Requirements are high-level requirements and address the initial backlog for release.

      While the Technology Solution Requirements (TSR) TSLC template may be used to ensure that all business and technical requirements are defined, the Requirements Traceability Matrix (RTM) with requirements and approvals will become the Baseline artifact in the next phase.

      Note: The TSR is a checklist, not a format for a requirements document.

      The RTM facilitates stakeholder involvement in a release by tracing each requirement from initial approval through System Integration Testing (SIT) scripts and results and Customer Acceptance Testing (CAT) scripts and results. If there is a CAT exemption, then the Post-Production Review (PPR) test scripts and results must be included in the RTM. This is a mandatory document for all releases. The RTM must contain or reference the requirement ID, requirement description, design document title, SIT script, SIT results, CAT script, and CAT results.

      The RTM must be uploaded to the “Requirements with Approval and RTM” folder under the "Requirements" parent folder. TSR/SRS (Software Requirements Specifications) are optional as supplemental documentation. All requirements in any supplemental documents must be included in the RTM. The BRM PM is responsible for coordinating the creation and maintenance of the RTM.

      For Tollgate releases, the RTM must also be associated to the appropriate Business Needs Statement (BNS) in the Master Release Inventory TSLC Template.

    3. Review and Approve Initial Requirements.
    4. The BRM PM coordinates review by all Solution Stakeholders, as identified in the Change Control Board (CCB) Document, for validation of the requirements.

      After all Solution Stakeholders have reviewed and agreed the requirements document is complete, Stakeholders approve the requirements as outlined in the CCB Document.

        Tollgate Process Only: Conduct Baseline Tollgate.

        Approved Requirements and initial RTM comprise the Baseline Tollgate. Approved Requirements, RTM, and Tollgate Meeting Minutes are mandatory outputs of this meeting.

    5. Implement Change Control.

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

  6. Create Initial Technology Solution Design (TSD).

    The following tasks are performed by the Technology Solution Provider (TSP):

  7. Plan the Release(s).
  8. The BRM PM coordinates the following tasks:


  9. Address Component Procurement.
  10. The BRM PM coordinates the following task:

    Determine components to be procured. This process involves performing preliminary procurement activities such as making versus buying / analysis and procurement / award supplier identification. This information will be used in the development of the project cost and schedule.

  11. Address Technology Solution Implementation Cost and Schedule.
  12. The BRM PM coordinates the following tasks:

    1. Assemble Cost and Schedule from the TSPs. The Technology Solution Coordinator (TSC) has up to two weeks to request, obtain, and compile the Technology Solution implementation costs and schedule milestones from the TSPs. Decision Analysis Reports (DARs) and large project Technology Solution implementations that will require longer than the two-week timeframe can request an extension in writing in advance from the BRM PM responsible for the Technology Solution. Though the Technology Solution costs and schedule milestones have been provided, the TSC continues to complete and obtain signoff on the Technology Solution design document.

    2. Technology Solution Implementation Cost and Schedule Business Owner (Customer) Approval. Upon the stakeholder review of the cost and schedule to develop the Technology Solution, stakeholders provide a decision to proceed with the project. If approved to proceed, funding is then obtained to support the rest of the TSLC processes (Sprints 1-n [Analysis and Design/Build], SIT, CAT, and Release) in implementing the Technology Solution.

  13. Submit the Impact Assessments.
  14. The BRM PM submits the SOX Impact Assessment (SIA) for SOX in-scope systems.

  15. Upload Documents to the TSLC Artifacts Library.
  16. The BRM PM ensures that the following artifacts are uploaded to the TSLC Artifacts Library in the appropriate folders:

    Tollgate process only: Artifacts must be uploaded within 10 business days of the Tollgate meeting.

PROCESS INPUTS/OUTPUTS

Baseline artifacts are mandatory and must be uploaded prior to release to production unless the project is following the Tollgate process. If Tollgate, documents from the Tollgate must be uploaded within 10 business days. Baseline artifacts are indicated in this document by an asterisk (*).

Inputs

Outputs

SUPPORTING DOCUMENTATION

Access supporting documentation from ITWEB (Internal):

Access Supporting Documentation from USPS.com (external):

REVISION HISTORY

Version
Date
Description of Change
1.0 05.10.2013 Agile and Waterfall processes combined; updated for Tollgates, PCI, and general compliance; ownership of TSLC processes transferred from Manager, Solutions Development and Support, to Manager, Business Relationship Management.

Note: This document is Section 508 compliant.
1.1 08.16.2013 Scope, Process:
Updated to clarify that the Requirements must be approved, not the Requirements Traceability Matrix document.
1.2 10.15.2013 Scope:
Removed references to the Freeze Waiver as this is a Change Management requirement, not a TSLC requirement.
1.3 03.18.2014 Process Description:
Replaced "customer" with "business owner (customer)" to define the customer as the business owner. Reworded description of RTM so it is not a baseline artifact in this phase.

Process Inputs/Outputs:
Updated "baseline artifacts" statement to clarify that they must be uploaded prior to release unless the project is following the Tollgate process. If Tollgate, required Tollgate artifacts must be uploaded within 10 business days. Removed baseline indicator (*) from RTM.
1.4 02.10.2015 Process, Process Inputs/Outputs:
Removed references to PCI Impact Assessment artifact. PCI Impact Assessment is retired.
1.4.1 06.15.2015 The annual review for functional accuracy and current PCI DSS requirements has been completed: No changes. CR 81805
1.4.2 06.26.2015 Non-substantive update: Update CR for annual review. Remove link and version of PCI DSS.
1.4.3 03.14.2016 Annual Review: No changes. The annual review for functional accuracy and current PCI requirements has been completed. CR 154951
1.4.4 10.31.2016 Annual Review: The annual review for functional accuracy and current PCI requirements has been completed. CR 223948
Powered By OneLink