Order-to-Pay (OtP) System Requirements Review (SRR)

Order-to-Pay (OtP) System Requirements Review (SRR)
Terry Conroy / Jim Walker Pam Wolfe/ Sittra Battle 10:00 – 11:30 am 07/08/14 Conroy/Walker

OtP (Center Validation and EUSO Refreshes) Project SRR, 07/08/2014
AGENDA Project Governance SRR overview Project Overview system overview Requirements overview success criteria Summary Conroy/Walker OtP (Center Validation and EUSO Refreshes) Project SRR, 07/08/2014

Project Governance Reviews Decision Authority SRR (CVT and Tech Refresh) NSSC SD Director / OCIO I3P Project Manager TRR (CVT and Tech Refresh) ORR (Center Validation Tool—CVT) CDR /KDP-C (CVT and Tech Refresh) I3P KDP Review Board Chair ORR/KDP-E (ORR for Tech Refresh/KDP-E for CVT and Tech Refresh) Sprint Reviews Project Managers / Scrum Team * Conroy/Walker * These projects are using a hybrid model to facilitate rapid development for on time delivery. Much of the work and decisions will be made by the Project Manager and Scrum team. Monthly reviews will be held to demonstrate progress to the stakeholder community and determine priorities for the next sprint. In the event that the Project Managers do not have consensus with the Scrum team, or there is concern for increase in the scope of the project, the co Decision Authorities will resolve the matter. OtP (Center Validation and EUSO Refreshes) Project SRR, 07/08/14

Key Dates, Milestones, and Approach
Key Milestones Project Approach The two projects (Center Validation Tool [CVT], and EUSO Refreshes [TR] share a common governance with a single review board and a hybrid Agile / 7120 approach. There will be a single SRR and TRR for both projects. Each will have an ORR as they are released. Between SRR and TRR there will be periodic Sprint Review meetings open to all external stakeholders. The expected interval is approximately 30 to 45 days. These reviews will transparent for all stakeholders. KDP-C and E will be brief by the Project Management team to the I3P KDP Review Board. A Project Completion Review (PCR) will be held after the OtP – Tech Refreshes project is released. Milestone Date SRR (both) 07/08/14 TRR (both) 09/09/14 ORR (CVT) 09/22/14 CDR/KDP-C (both) 11/05/14 ORR/KDP-E (ORR TR/KDP-E both) 02/02/15 PCR (both) 03/02/15 Conroy/Walker OtP (Center Validation and EUSO Refreshes) Project SRR, 07/08/14

SRR Purpose System Engineering Review Team (SERT) Members and Decision Authority SRR Entrance Criteria Review Item Discrepancy (RID) Overview SRR Overview OtP (Center Validation and EUSO Refreshes) Project SRR, 07/08/14

SRR Purpose The purpose of the SRR is to: Examine the functional, technical, performance, and security requirements for the system and elements of the preliminary Project Plan. Ensure that the requirements and the selected concept will satisfy the system objectives. NPR /NID Appendix G.2 Agile Scrum 1 2 3 3 4 5 n 7120 OtP (Center Validation and EUSO Refreshes) Project SRR, 07/08/14

System Engineering Review Team (SERT) Members and SRR Decision Authority Name Role Organization Ken Newton Decision Authority NSSC – SD Director Terry Jackson OCIO – I3P Program Manager John McDougle SERT Chair MSFC – DCIO Dan Conway SERT Member OCIO – IT Security Denise Travers KSC – ACIL / Business Office SME Tuesday Dodson HQ – ESD SME Gary Seloff JSC – CIL Elizabeth Sudderth MSFC – CSO OtP (Center Validation and EUSO Refreshes) Project SRR, 07/08/14

SRR NPR 7120.7/NID 7120.99 Entrance Criteria Status
Item# Entrance Criteria Complete? Artifact of Evidence/Details Responsible POC 1. A preliminary SRR agenda, success criteria, and charge to the board have been agreed to by the technical team, project manager, and review chair prior to the SRR. Y FAD (See Note Below) Jim Walker / Terry Conroy 2. The following technical products (a. – n.) for hardware and software system elements are available to the cognizant participants prior to the review: a. System requirements document Order to Pay Requirements Document (See Note Below) Pam Wolfe/Sittra Battle b. System software functionality description System Overview (See Note Below) Diane Fulton / Wendy Lockhart c. Concept of Operations See Note Below Terry Conroy / Jim Walker d. Preliminary system requirements allocation to the next lower-level system e. Updated cost estimate Executive Summary (See slide 16) Jim Walker / Sittra Battle f. Risk assessment and mitigations Top 5 Project Risks (See slide 18) Jim Walker / Terry Conroy / Sittra Battle / Pam Wolfe Y (Yes)  N (No) T (Tailored) N/A (Not Applicable) OtP (Center Validation and EUSO Refreshes) Project SRR, 07/08/14

SRR NPR 7120.7/NID 7120.99 Entrance Criteria Status (cont’d)
Item# Entrance Criteria Complete? Artifact of Evidence/Details Responsible POC g. Configuration management plan Y See Note Below Diane Fulton h. Initial document tree i. Verification and validation approach j. Information/system security categorization. Danny Harvill k. Identification of personally identifiable information l. Identification of records retention requirements James Barnett m. Identification of required system security controls n. Preliminary software development / management plan Y (Yes)  N (No) T (Tailored) N/A (Not Applicable) OtP (Center Validation and EUSO Refreshes) Project SRR, 07/08/14

Review Item Discrepancy (RID) Overview
A RID is a formal written request submitted to the RID Review Team (below) that describes a problem, provides possible recommendations, and details impact(s) to the project if the recommendation is not implemented. RID Considerations RIDS must submitted by 9 am Pacific time, 14 July, Only RIDS addressing issues within the scope of this review will be accepted. All RIDS with their disposition will be available for review via a website (TBD) for interested stakeholders. RIDs must be submitted via the RID form available in ServiceNow Project Portfolio Management (PPM). Completed forms must be ed to Diane Fulton and RID Review Team (RRT) Jim Walker, NSSC Acting CIO Terry Conroy, Service Integration Manager Pam Wolfe, I3P Business Office Manager Sittra Battle, End User SOIL Paul Rydeen, ESD SOM OtP (Center Validation and EUSO Refreshes) Project SRR, 07/08/14

Executive Summary Project Organizational Structure Key Dates, Milestones, and Approach Top 5 Project Risks and Issues Project Communications Plan and Activities Project Overview OtP (Center Validation and EUSO Refreshes) Project SRR, 07/08/14

Executive Summary (1 of 5)
Project’s Purpose – The IT Infrastructure Integration Program (I3P) utilizes the Enterprise Service Request System (ESRS) for service order and delivery from the End User Service Office (EUSO) service provider, Hewlett Packard Enterprise Services (HPES). The Agency Consolidated End-User Services (ACES) contract between HPES and NASA, managed by the EUSO, supplies end-user devices to the majority of NASA employees and contractors. The I3P Business Office (I3P BO) manages invoice processing of ACES services for NASA. Centers support both the EUSO and I3P BO objectives through Center asset management and invoice reconciliation activities. Continual Service Improvement continually drives change for ESD and ACES to enhance business processes, eliminate manual workarounds and further define the CMDB. Consequently, enhancements are needed to optimize lifecycle management for end-user service delivery and NASA’s Configuration Management Database (CMDB), eliminate spreadsheet uploads (both for ordering and for CMDB loads) included manual intervention that made the data suspect and optimize business processes to align with system functionality and contract line item (CLIN) tracking. All data within NASA’s CMDB is currently a reflection of order and fulfillment data captured within HPES systems. The result is an inability for NASA to assert that ACES invoices received are accurate, or that data supporting technology lifecycle management (tech refresh, early tech refresh, de-subscribe, etc.) is accurate. Need OtP info OtP (Center Validation and EUSO Refreshes) Project SRR, 07/08/14

Project’s Purpose – This project is intended to resolve some of the operational concerns with invoice reconciliation and usability. This project will: Identify necessary remediation requirements in current business processes and systems that were impeding the ability to reconcile ACES invoices; Develop automated processes and services such that ESRS could be used to order all new and technology refresh services as required by the EUSO; Create an independent repository of NASA ACES order and fulfillment data against which the I3P Business Office could validate ACES vendor invoices; and, Eliminate the need for manual data entry and updates (e.g., spreadsheets) throughout the order to pay lifecycle (both the bulk order templates (BOTs) used for ordering; and, the bulk load templates (BLTs) used for CMDB updates). Need OtP info OtP (Center Validation and EUSO Refreshes) Project SRR, 07/08/14

Project’s Purpose – While this is project is being managed as an integrated whole, it actually contains two separate sets of deliverables and milestones. These releases are being managed internally by the NSSC on parallel paths so that all dependencies can be identified and accommodated. The two components are: Center Validation Tool (CVT): This deliverable set will include functionality and tools that support the I3P Business Office’s and Centers’ ACES invoice reconciliation processes. EUSO Refreshes: This deliverable will support the End User Service Office (EUSO) requirements for automated technology and early technology refresh. This project is dependent on a parallel project underway at the NSSC: ServiceNow Transition. For each of our major deliverables listed above, components of the ServiceNow infrastructure must be available for production use. Each of these dependencies will be identified and tracked as part of this projects dependencies, and risks. Need OtP info OtP (Center Validation and EUSO Refreshes) Project SRR, 07/08/14

Program Project Goals and Objectives A hybrid 7120 and Agile Scrum approach shall be utilized to develop the solution, as permitted by NID section During the Formulation Phase the project shall: define the requirements define unique project components develop an integrated list of dependencies to support identified use cases. NASA civil servant and contractor support shall complete these activities. All activity expenses for the Formulation Phase will use existing NSSC operational in-guide funding supplemented by OCIO funding. Expected Benefits: Reduction in workload burden for I3P support contractors Increased customer satisfaction with user interface, service catalog and lifecycle management capabilities Increased confidence in data integrity relative to invoice processing and asset refresh Improved accuracy in ACES invoice reconciliation Goals and Objectives: Enhanced functionality for on-line ordering and provisioning of services for NASA customers Accurate and timely ACES invoice processing Stakeholder participation and thorough communications to customer base Integrated service delivery and invoice processing for EUSO customers Need OtP info OtP (Center Validation and EUSO Refreshes) Project SRR, 07/08/14

Current project rating as of SRR: Overall Cost Schedule Technical Programmatic Total Development Cost: $2.1M Expected Yearly Operational Cost: None Funding Source – NSSC - $1M for OTP OCIO - $400K to NSSC and $700K to HP for OTP High Level Assumptions and Constraints – The software solution is seen as an ITSM question from the I3P perspective but also has to address NSSC platform needs (e.g., Customer Contact Center and NSSC Service Request [NSR]). ESD requirements are well-known and well-documented going into the project. Changes to requirements will only be considered to adopt improvements in the new tool or to eliminate customizations, and will receive full vetting by the SERT. No change in NSSC functional area requirements once base lined. October 2014 desired delivery date for OTP/CVT; January 2015 desired delivery date for OTP/TR. NSSC CSC contract expiration of August 2015. Dependencies – Interfaces to I3P Tier 2 systems (ACES Service Manager, Asset Manager, APC / NICS Remedy). ServiceNow infrastructure is available when needed to support functional requirements. Y Y G Y G Need OtP, need to determine RYG colors, verify funding OtP (Center Validation and EUSO Refreshes) Project SRR, 07/08/14

Projects Organizational Structure
Governance Diane Fulton (NSSC/CSC) Wendy Lockhart (EUSO/HP) Project Managers OHCM, EUSO, and ESD Major External Stakeholders I3P BO, EUSO and ESD Major Internal Stakeholders ACES, NICS, NEACC, WEST Prime, GRC UAT, HQ HITSS Project Impacts I3P BO, CRAs, CILs, SMEs, OCIO Service Execs, et al Communities of Interest Ken Newton (NSSC) Terry Jackson (OCIO) Sponsors/Co-DA Jim Walker Terry Conroy Project Executives Doug LeMere OSC2 Laura Diggs NSSC IT SCRUM Master Donald St. Germain Transition & Integration Darren Davis HP Development Team I3P KDP Review Board Jonathan Pettus Chair Governance Project Project OtP (Center Validation and EUSO Refreshes) Project SRR, 07/08/2014

Risk Criticality Color Key
Top 5 Project Risks LIKELIHOOD Very High 5 High 4 Mod 3 Low 2 Very Low 1 CONSEQUENCE Risk Criticality Color Key Med Risk Seq # Risk ID Trend Statement Status M,W,R,C,A 1 10096 If the I3P vendors cannot support scheduled integration tasks, then the project schedule may not be met. W 2 10117 If the OtP Data Store is not implemented and ready to receive only fulfillment data, then the web service will need to be expanded to pass all data currently contained in the BLTs. R 3 10118 If the Remedy to ServiceNow migration requires resources that are needed to support the OtP project, then contention for resources may cause a schedule delay. 4 10098 If sufficient development and testing environments do not exist to manage concurrent tasks, then project delays may occur. M 5 10114 If the ServiceNow cloud environment cannot obtain people data from the NED, additional HW/SW may need to be procured. a 1 5 a 2 4 a 3 a a What we are going to do here is take the top 5, most impactful, risk from L x C Trend Codes Decreasing (Improving) Increasing (Worsening) a Unchanged New Since Reporting Period Status Codes M Mitigate W Watch R Research C Closed A Accept OtP (Center Validation and EUSO Refreshes) Project SRR, 07/08/14

Project Communication Plan
Communication Plan for the Order to Pay (OtP) Sec. 3 project provides messages, both operational regarding enhancements, applications and improvements to key stakeholders within the NASA OCIO community and I3P providers, to maximize ESD’s continued use by all NASA users. Stakeholders identified in the plan are shown on the following two slides. The communication plan was published 9/1/2012; OtP added 6/30/14 An additional “mini-communication plan” has been developed specifically for all eight requirements Execution of the plan is dependent on the receipt of current, accurate information from the Project Managers. There are no issues that need to be addressed concerning this plan. Communications are on schedule for deployment. Doug OtP (Center Validation and EUSO Refreshes) Project SRR, 07/08/14

Communications and Outreach Activities Develop Center Validation Tool (CVT) Topic Message Vehicles Used Stakeholders Frequency Status Improve the I3P Business Office tools and reports Provide informational option to streamline processes , Website, Newsletter I3PBO, ACES SME’s, Center RA’s, ESD SME’s. Once, bi-weekly if needed Planning Develop Center Validation Tool (CVT) Inform as new process For I3PBO, ACES SME’s, Center RA’s, ESD SME’s, possibly OSC2. Once, bi-weekly if needed Produce a monthly exception report for the business office Inform of new process For I3PBO, ACES SME’s, Center RA’s, ESD SME’s. Provide role-based, self-service capability for the management data fields Doug OtP (Center Validation and EUSO Refreshes) Project SRR, 07/08/14

Communications and Outreach Activities End User Services Office Refresh Topic Message Vehicles Used Stakeholders Frequency Status Add a “Show My Services” capability to Order Services in ESRS. What to expect , Website, Newsletter EUSO, OSC2 Once, weekly if needed Planning Develop within ESRS a function for Early and Tech Refreshes Inform of new process to reduce notifications Develop a web interface for I3P vendors to electronically update the OtP system Coordinate the elimination of CMDB Inform of removal of requirement of maintain CI data in CMDB Newsletter I3PBO, ACES SME’s, Center RA’s, ESD SME’s, EUSO, OSC2 Doug OtP (Center Validation and EUSO Refreshes) Project SRR, 07/08/14

Analysis of Alternatives (AoA) Activities System Concept System Description Major System Interfaces System Overview OtP (Center Validation and EUSO Refreshes) Project SRR, 07/08/14

Analysis of Alternatives (AoA) Activities
In April 2014 OCIO asked NSSC to develop a technical solution to improve ACES monthly reconciliation and to provide the EUSO Refresh services via ESRS. Three scenarios: Do Nothing: Not an option. Customer and program impact with current service model was inadequate. Make Changes in Remedy: Initial thought was to move in this direction, patching what we could in incremental steps. Concerns: Remedy did not easily support required customization Remedy was out of both maintenance and BMC support, making any effort more complex and risky NSSC Business Case supported move to ServiceNow. All Remedy services would need to be rewritten. Make Changes using ServiceNow: Decision based on combination of factors: NSSC Business Case approved move to ServiceNow product migration sooner than anticipated. ServiceNow offered out-of-the-box functionality and features desired by customers and the program with no customization. Based on the business case the upgrade effort for both SN and Remedy 8.0 were similar with SN having a slight advantage. In evaluating the requirements for TR and CVT, the limitations within 7.5 would result in customization, elongated development schedule and eventual rework. Use of SN would shorten development time for both CVT and TR. SN enhanced capabilities led to increased likelihood of meeting customer expectations for delivery. This covers Migration, not OtP OtP (Center Validation and EUSO Refreshes) Project SRR, 07/08/14

System Concept The OTP project will leverage capabilities offered with the ServiceNow platform that add value to data lifecycle management and customer use. Components of the ServiceNow product will be implemented at identified project milestones. The result will be a gradual transition from the Remedy to ServiceNow platform, while implementing functionality for the end-user community. During the CVT phase, Remedy order data will be deposited into the ServiceNow data store. The data store will be a relational model, allowing for the tracking of each service provisioned under the ACES contract as well as changes to any component/asset associated with that service. In addition, the CVT will be implemented such that end-users will be able to assert that their service and asset data is correct prior to invoicing. The result should be a substantial reduction in invoice errors. Implementation of the Tech/Early Tech Refreshes processes will rely on several ServiceNow components being in production operation: service catalog, ‘my services’ view, and all service definitions eligible for tech/early tech Refreshes. In order to leverage the service catalog in ServiceNow, all services will transition; not just the 45 associated with Tech/Early Tech Refresh. Testing of all services will be included within the test plan. To streamline processes and increase data integrity, a web service interface between NASA and HP will allow for order and fulfillment data to be updated in near real-time, eliminating today’s manual processes. OtP (Center Validation and EUSO Refreshes) Project SRR, 07/08/14

Sprints Center Validation Tool (FY14 Q3 through FY15 Q1) Release 1—Eliminate CI Spreadsheets (Requirement 7.0) Sprint 1—Eliminate CI Spreadsheets Release 2—OtP Data Store and User Interfaces (Requirements 2.0, 3.0, 4.0) Sprint 1—Order to Pay Foundation and Web Services Sprint 2—Center Validation Tool (Requirement 2.0) Sprint 3—Role Based View/Modify Access (Requirement 4.0) Sprint 4--Invoice/Order Exception Reports (Requirement 3.0) Tech Refresh (FY14 Q3 through FY15 Q2) Release 1—Tech Refresh and Early Tech Refresh (Requirements 5.0, 6.0) Sprint 1—Show My Services (Requirement 5.0) Sprint 2—Build Foundation for TR and ETR Services Sprint 3—Build Tech Refresh and ETR (Requirement 6.0) Sprint 4—Scripting Integrations/Reporting Deliverables include time for unit, integration and user acceptance testing OtP (Center Validation and EUSO Refreshes) Project SRR, 07/08/14

Major System Interfaces
Want to review with Laura Diggs OtP (Center Validation and EUSO Refresh) Project SRR, 07/01/14

Requirements Overview
Concept of Operations Requirements Elicitation Approach Review Specific Questions Requirements Traceability and Approach to Requirements Management Functional Requirements Non- Functional Requirements Performance Requirements Requirements Overview OtP (Center Validation and EUSO Refreshes) Project SRR, 07/08/14

Concept of Operations Web services Any service Incidents Order fulfillment CMDB/AM ESRS User at Tier 0 in ESRS BMC -ICAM CMDB NED WO Asset Mgr Update FcART Access dB AMES ARFC MSFC SSC JSC KSC GRC GSFC NSSC HQ Langley I3P BO OtP (Center Validation and EUSO Refreshes) Project SRR, 07/08/14

Requirements Elicitation Approach
The project team includes members from each of the primarily affected groups: EUSO, I3PBO, ESD, CSC, and HP. This group met via telecon/Lync and F2F since February 2014 formulating the Requirements Document. Each draft of the requirements document has been distributed to the project team for dissemination to their communities of interest, including CILs, SMEs, Resource Analysts, and Service Executives. F2F meetings included time at the end of each day for a report out to CILs and SMEs at which time questions would be asked/answered or taken as actions. Stakeholders are defined as all persons involved in the EUSO and I3PBO business work streams as primary, and all those within the realm of I3P and NSSC service delivery as secondary. I will work this on Wednesday OtP (Center Validation and EUSO Refreshes) Project SRR, 07/08/14

Review Specific Questions
OTP 1. To what level have the requirements been captured; 5 recommended? (If less than five, briefly discuss.) Level 4 2. Are requirements traceable forward and backward? (If no, briefly discuss.) Yes 3. Is a tool/process being used to manage the requirements? (If no, briefly discuss.) 4. Are there any requirements that are not verifiable or very difficult to verify? (If yes, briefly show them on a separate slide.) No 5. Were all stakeholders queried for requirements? (If no, briefly discuss.) 6. Have software component requirements been developed? (If no, briefly discuss.) 7. Are there any requirements under investigation for final definition/resolution? (If yes, briefly discuss.) 8. Does the project control changes to requirements? (If no, briefly discuss.) 9. Has the project reviewed the requirements of the Architecture Assessment (AA) checklist and complied with the AA Checklist requirements? (if no, briefly explain.) N/A OtP (Center Validation and EUSO Refreshes) Project SRR, 07/08/14

Requirements Traceability and Approach to Requirements Management
Requirements Approach The following process of discovering, analyzing, defining, and documenting the requirements were used: Identified Key Stakeholders Captured Stakeholder requirements Held focus groups and requirements meetings Categorized and prioritized requirements. Defined and recorded high level requirements. Held several Face to Face Meetings to determine lower level requirements. All parties agreed too and signed off on the requirements. Requirements Management and Control All requirement updates will need to be approved by the Project Executives and the Project Sponsor. The Project Manager will be responsible for updating the project requirements document and uploading the new version to Sharepoint. Requirements Repository Repository Description ServiceNow NSSC’s Project Management Portfolio is the ServiceNow module. Key project team members have a license to access the data in real time on demand. OtP (Center Validation and EUSO Refreshes) Project SRR, 07/08/14

OtP Level 1 High-Level Requirements
Level 1 Requirement Statement 1.0 Improve the I3P Business Office tools and reports to streamline the time necessary to complete the monthly reconciliation process. 2.0 Develop a Center Validation Tool (CVT) to be used at Centers to validate the receipt of ESRS orders for accountability and update to status the OtP data stores. 3.0 Shall provide a capability to produce a monthly exception report for the business office. 4.0 The SP shall provide role-based, self-service capability to the I3P BO and the Centers for the management data fields. 5.0 Add a “Show My Services” capability to Order Services in ESRS. This will facilitate removing free form text fields for asset information when requesting changes to existing services. 6.0 Shall develop within the Enterprise Service Request System a function for Tech Refresh. 7.0 Shall develop a web interface for I3P vendors to electronically update the OtP system via unique identifier as needed. 8.0 The NSSC CIO will coordinate the elimination of the CMDB as a requirement from the NASA OCIO’s ESD requirement document. OtP (Center Validation and EUSO Refreshes) Project SRR, 07/08/14

NSSC Level 2 Functional Requirements
Level 2 functional requirements are identified below. L1 L2 Requirements Statement 1.0 Improve the I3P Business Office tools and reports to streamline the time necessary to complete the monthly reconciliation process. 1.1 The SP shall lead an end to end discussion on the current tools used in the I3P BO to assess the viability of FCaRT as a tool. 1.2 Shall provide all data flow, data scheme, and process flows as they currently work in FCaRT. 1.3 Shall provide details of current services defined in ESRS. 2.0 Develop a Center Validation Tool (CVT) to be used at Centers to validate the receipt of ESRS orders for accountability and update to status the OtP data stores. 2.1 Capture all available data at Approval of a Remedy Service Request. 2.2 Develop a migration plan for all existing services. 2.3 Shall develop the means to ensure all ESRS resolved tickets are positively acknowledged by one of the designated center approvers. OtP (Center Validation and EUSO Refreshes) Project SRR, 07/08/14

Level 2 functional requirements are identified below. L1 L2 Requirements Statement 2.4 Shall ensure an audit log including date, time, order identifier and UUPIC is maintained. 2.5 Shall develop fields within the OtP data stores that show data has been positively validated and includes the date of the update. Data to be validated: Remedy SR number, Seat type, Date requested, Requested for, OBO, Description of the Base CLIN. 2.6 Shall utilize the existing process to manage non concurrence of service delivery survey by creation of an incident to the appropriate vendor. 2.7 Returned tickets shall require a reason for the return based on a drop down selection. SR Reasons for return: ACES action. 2.8 Shall provide the ability to view and export (via excel and CSV at a minimum) non-concurred service delivery items based on roles by center. 2.9 The system shall apply the following business rules to establish the billing start date for a service: 3.0 Shall provide a capability to produce a monthly exception report for the business office. 3.1 Shall provide the I3P BO with a capability to upload monthly invoices. 3.2 Shall provide the I3P BO the capability to compare the monthly invoices with the NSSC’s validated data store. OtP (Center Validation and EUSO Refreshes) Project SRR, 07/08/14

Level 2 functional requirements are identified below. L1 L2 Requirements Statement 4.0 The SP shall provide role-based, self-service capability to the I3P BO and the Centers for the management data fields. 4.1 Shall develop and implement a model that allows role based users, managed via NAMS, to access the OtP data stores. 4.2 Shall create an electronic system to notify I3P stakeholders when the OtP data store is modified as defined. 5.0 Add a “Show My Services” capability to Order Services in ESRS. This will facilitate removing free form text fields for asset information when requesting changes to existing services. 5.1 Shall provide service display functionality that allows users and on-behalf of users to select an existing service when submitting a Service Request. 5.2 Once this capability is available the services listed in Appendix E will be modified in SDR. When defined in the Service Definition the service display shall show all of the current user’s services unless further restricted by additional requirements. NOTE: If user switches to order on-behalf of another user the display is of the on-behalf of user. 5.3 Shall, in the event all of a user’s services are not displayed, provide instructions or a mechanism for the user to report the discrepancy. OtP (Center Validation and EUSO Refreshes) Project SRR, 07/08/14

Level 2 functional requirements are identified below. L1 L2 Requirements Statement 5.4 The following data elements will be displayed to allow the user to select the service they need to action: 5.5 Shall allow a user to select one service, auto populate a Service Request with existing service data. Based on the service selected the system should limit the available selections to relevant service types. 6.0 Shall develop within the Enterprise Service Request System a function for Tech Refresh. 6.1 The Enterprise Service Request System shall provide a capability in the catalog for Early Technology Refresh (ETR). 6.2 The Enterprise Service Request System shall provide a capability in the catalog for Technology Refresh. 7.0 Shall develop a web interface for I3P vendors to electronically update the OtP system via unique identifier as needed. 7.1 Develop a modify web interface for CI/service information from ACES as needed. OtP (Center Validation and EUSO Refreshes) Project SRR, 07/08/14

Level 2 functional requirements are identified below. L1 L2 Requirements Statement 7.2 Data is assumed to be the same information exchanged in the BLT’s as of 4/15/14. 7.3 Web service will be configured to accept an ACES “eligibility” field for use in display My Services. 8.0 The NSSC CIO will coordinate the elimination of the CMDB as a requirement from the NASA OCIO’s ESD requirement document. 8.1 Shall descope the I3P Program Offices requirement for a NASA CMDB. Service Offices shall depend on vendor provided asset management and CMDB data upon completion of this requirement. OtP (Center Validation and EUSO Refreshes) Project SRR, 07/08/14

HP Functional Requirements
Level 2 functional requirements are identified below. L1 L2 Requirements Statement 1.0 Improve the I3P Business Office tools and reports to streamline the time necessary to complete the monthly reconciliation process. 1.1 New service to be defined in ESRS to add legacy seats not already accounted for in Asset Manager. 1.2 Support walkthrough of process and touch points with the invoice (SACM & invoicing). 2.0 Develop a Center Validation Tool (CVT) to be used at Centers to validate the receipt of ESRS orders for accountability and update to status the OtP data stores. 2.1 HP will provide reasons for ticket return that will be used by the existing process. 2.2 Verify source billing start date equals the fulfillment date provided in the web service call at order completion by ACES. 2.3 Review what the survey looks like and who will approve the changes (EUSO/HP). 2.4 HPES will be involved with the planning of the data migration, but will not have an active role in the creation and migration of data. 2.5 HPES will be involved with System Integration Testing OtP (Center Validation and EUSO Refreshes) Project SRR, 07/08/14

Level 2 functional requirements are identified below. L1 L2 Requirements Statement 2.6 Understand the escalations that the tool will follow—HPES will need to be involved if there are changes made to them. 3.0 Shall provide a capability to produce a monthly exception report for the Business Office. 3.1 HPES will update invoice to reflect the data to be used for invoicing to NASA (start/end, WO, etc.) process, tool, that need changes. 3.2 HPES to ensure that the exception report includes all data HPES requires 3.3 HPES involved in testing. 4.0 The SP shall provide role-based, self-service capability to the I3P BO and the Centers for the management data fields. 4.1 HPES will develop a process for the BO and HPES to decide if the billing start date needs to be changed. 4.2 UUPIC – changing who an asset is assigned to – web service notification of changes to a UUPIC. 4.3 Validation and error processing will occur. OtP (Center Validation and EUSO Refreshes) Project SRR, 07/08/14

Level 2 functional requirements are identified below. L1 L2 Requirements Statement 5.0 Add a “Show My Services” capability to Order Services in ESRS. This will facilitate removing free form text fields for asset information when requesting changes to existing services. 5.1 SDR Mod requests will be submitted to update existing service configuration seats to utilize new functionality 5.2 KA created for ESD and Tier 2. 5.3 Communications for the end users and internal teams created (EUSO & HPES). 5.4 Service Manager updates to put the data received into the right fields in the ticket. 5.5 Create Connectit (CiT) scenario to process the data into Asset Manager. 5.6 Existing web service will be updated to consume the data sent across the WSDL for each request. 5.7 Testing of the changes implemented in the Mod requests. 5.8 Production review and promotion to production. OtP (Center Validation and EUSO Refreshes) Project SRR, 07/08/14

Level 2 functional requirements are identified below. L1 L2 Requirements Statement 6.0 Shall develop within the Enterprise Service Request System a function for Tech Refresh. 6.1 ETR— Web service to send/receive ATV data for ETR – also may be used for stand alone ATV service. 6.2 ETR—New service to be defined in ESRS for stand alone ATV request for quote 6.3 ETR/TR— New service to be defined in ESRS for early tech refresh (ETR) and tech refresh submitted. 6.4 ETR—Receive ETR request, process in workflow (interface work required). 6.5 ETR—Manage ETR seat orders, link to logistics. 6.6 ETR—Process (KA, Work Instructions, etc.) and communication work (processing ETRs and orders) 6.7 ETR—Ensure ETR service and processing covers capture of “V” CLIN that will hold ATV that will be billed and will be passed to HP OtP (Center Validation and EUSO Refreshes) Project SRR, 07/08/14

Level 2 functional requirements are identified below. L1 L2 Requirements Statement 6.8 ETR—Create mechanism to store and invoice the “V” CLIN ATV charges. 6.9 TR—Web service in refresh portal to receive notification when a “like for unlike” ESRS request is started, completed, approved, cancelled. 6.10 TR—Develop code to create extract of seats that are refresh eligible in refresh cycle, web service to send info to ESD for when they are eligible, and when eligibility ends. 6.11 TR—Update refresh portal when user selects like for unlike, create with details on how to order seat in ESRS. 6.12 TR—Update refresh portal to aggregate “like for like” and “like for unlike” requests up to Refresh cycle lock, then release all orders for provisioning of the devices. 6.13 TR—Create web service integration for compute seats for the “like to like” portal to SM. 6.14 TR—Define survey that is sent after “like for like” refresh completed, since the order does not hit ESRS to generate the survey that includes CVT. 6.15 TR—Process (KA, Work Instructions, etc.) and communication work (processing ETRs and orders). 6.16 TR—Design and functionality to manage the ordering of devices for a refresh cycle. OtP (Center Validation and EUSO Refreshes) Project SRR, 07/08/14

Level 2 functional requirements are identified below. L1 L2 Requirements Statement 7.0 Shall develop a web interface for I3P vendors to electronically update the OtP system via unique identifier as needed. 7.1 Bulk Load Template (BLT) is being replaced to communicate to the web service that will feed the data repository maintained by NASA. 7.2 Define data dictionary and data governance with NASA, CSC and the NASA I3P BO. 7.3 Create the new Connectit interface (service) to interface with the new OtP interface. 7.4 Incorporate the ability to monitor and measure SACM3. 7.5 HPES will be involved in System Integration Testing (SIT). 7.6 Exception processes—HPES will work with the NASA BO, the Asset Management team, and CSC on defining the process for dealing with exceptions in the new process. OtP (Center Validation and EUSO Refreshes) Project SRR, 07/08/14

NPR /NID Success Criteria SRR Success Criteria OtP (Center Validation and EUSO Refreshes) Project SRR, 07/08/14

SRR NPR 7120.7/NID 7120.99 Success Criteria
Item # Success Criteria Satisfied ? Details 1. The project utilizes a sound process for the allocation and control of requirements throughout all levels, and a plan has been defined to complete the definition activity within schedule and cost constraints. Y [For Satisfied = Yes, no detail is required in this column.] 2. Top-level requirements definition is complete, and interfaces with external entities and between major internal elements have been defined. 3. Requirements allocation and flow down of key driving requirements have been defined down to subsystems. 4. Preliminary approaches have been determined for how requirements will be verified and validated down to the subsystem level. 5. Major risks have been identified, and viable mitigation strategies have been defined. 6. IT security, privacy, and records retention requirements are complete and have been incorporated into project requirements documentation. TBD IT Security Plan for ServiceNow is under development. 7. The preliminary software development/management plan meets the requirements of NPR Y (Yes)  N (No) T (Tailored) N/A (Not Applicable) OtP (Center Validation and EUSO Refreshes) Project SRR, 07/08/14

Lessons Learned Stakeholder Concur Conclusion Request for Approval Summary OtP (Center Validation and EUSO Refreshes) Project SRR, 07/08/14

Lessons Learned Phase Lessons Learned YTD Lessons Learned It’s easy to talk past each other when we use the same term to mean different things. Walking through the requirements with use cases affirms whether the full scope of requirements is captured. OtP (Center Validation and EUSO Refreshes) Project SRR, 07/08/14

Stakeholder Outreach Stakeholder Meeting Dates Actions Concurrence (Y or N) Resource Analysts Multiple meetings Described to Center RA’s how the CVT would be implemented. Y ESD SMEs June 2014 ServiceNow team provided a demonstration of the tool suite and the ESD SOM outlined the OtP/Refresh project. I3P Program CILs & SMEs April/May 2014 Daily outbrief to all stakeholders at week long F2F EUSO SMEs Regular weekly meeting Described to Center EUSO SME’s how the CVT would be implemented. CILs Reviewed at bi-weekly CIL meetings Service Execs/Offices May/June/July 2014 Provided briefings at weekly integration meetings and at SO F2F events ??? OtP (Center Validation and EUSO Refreshes) Project SRR, 07/08/14

Conclusion / Request for Approval
Concurrence: All entrance criteria have been met. All success criteria for the SRR are satisfied. Name Role Organization Ken Newton Decision Authority NSSC – SD Director Terry Jackson OCIO – I3P Program Manager John McDougle SERT Chair MSFC – DCIO Dan Conway SERT Member OCIO – IT Security Denise Travers KSC – ACIL / Business Office SME Tuesday Dodson HQ – ESD SME Gary Seloff JSC – CIL Elizabeth Sudderth CSO OtP (Center Validation and EUSO Refreshes) Project SRR, 07/08/14

Key References and Points of Contact OTP Level 3 & 4 Functional Requirements Backup Material OtP (Center Validation and EUSO Refreshes) Project SRR, 07/08/14

Key References and Points of Contact Order to Pay (CVT & TR)
All references for this project are stored in the ServiceNow Repository at the NSSC: Points of Contact Name Role Location Phone Jim Walker Project Executive NSSC Terry Conroy OCIO Diane Fulton Project Manager NSSC/CSC Wendy Lockhart EUSO/HP OtP (Center Validation and EUSO Refreshes) Project SRR, 07/08/14

OTP Level 3-4 Functional Requirements
Level 3-4 functional requirements are identified below. L2 L3 L4 Requirements Statement 1.1 The SP shall lead an end to end discussion on the current tools used in the I3P BO to assess the viability of FCaRT as a tool. 1.2 Shall provide all data flow, data scheme, and process flows as they currently work in FCaRT. 1.3 Shall provide details of current services defined in ESRS. 2.1 Capture all available data at Approval of a Remedy Service Request. 2.2 Develop a migration plan for all existing services. 2.3 Shall develop the means to ensure all ESRS resolved tickets are positively acknowledged by one of the designated center approvers. 2.3.1 The un-validated order is escalated to the originally selected (at the time of order) Service Request Org Approver queue. 2.3.2 The time to escalate will be 6 calendar days from the SR completion date (implies that no response to the survey was provided by the user). 2.3.3 Final escalation occurs 12 calendar days from the SR completion date (implies that no response to the survey was provided and no action by the First-line Center Escalation and remains here until validation occurs). OtP (Center Validation and EUSO Refreshes) Project SRR, 07/08/14

Level 3-4 functional requirements are identified below. L2 L3 L4 Requirements Statement 2.4 Shall ensure an audit log including date, time, order identifier and UUPIC is maintained. 2.5 Shall develop fields within the OtP data stores that show data has been positively validated and includes the date of the update. Data to be validated: Remedy SR number, Seat type, Date requested, Requested for, OBO, Description of the Base CLIN. 2.6 Shall utilize the existing process to manage non concurrence of service delivery survey by creation of an incident to the appropriate vendor. 2.6.1 Upon completion of vendor incident, created as a result of the “no” to SR survey, the user shall have the capability to concur with the delivery of the service via the incident survey. A positive response will automatically validate the service in the OtP data source. A negative response will reopen the incident and send back to the appropriate vendor. A non-response will follow the OtP validation escalation process. OtP (Center Validation and EUSO Refreshes) Project SRR, 07/08/14

Level 3-4 functional requirements are identified below. L2 L3 L4 Requirements Statement 2.7 Returned tickets shall require a reason for the return based on a drop down selection. SR Reasons for return: ACES action. 2.7.1 Escalation of tickets not validated. Shall escalate tickets awaiting user verification to the First-line Center queue for tickets older than 6 calendar days from WO completion date. 2.7.2 Shall escalate tickets awaiting First-line Center verification to the Center Final Validation queue for tickets older than 12 calendar days from the WO completion date. 2.7.3 Tickets escalated to the Center Final Validation queue will remain there until action is taken. 2.8 Shall provide the ability to view and export (via excel and CSV at a minimum) non-concurred service delivery items based on roles by center. OtP (Center Validation and EUSO Refreshes) Project SRR, 07/08/14

Level 3-4 functional requirements are identified below. L2 L3 L4 Requirements Statement 2.9 The system shall apply the following business rules to establish the billing start date for a service: 2.9.1 Business rule 1. If the validation process confirms receipt of the service then OtP data source billing start date equals the fulfillment date provided in the web service call at order completion by ACES 2.9.2 Business rule 2. The I3P BO will have an interface allowing them to adjust the billing start date in the OTP data store if needed. The WO completion date will not be changed. When the I3P BO modifies data the updates will need to be passed to the I3P Vendor as defined in Requirement 4.2. 3.1 Shall provide the I3P BO with a capability to upload monthly invoices. 3.2 Shall provide the I3P BO the capability to compare the monthly invoices with the NSSC’s validated data store. 3.2.1 Provide a consolidate report of invoice line items indicating matched and unmatched between the invoices and NSSC’s OtP data store. Data fields to be included are: Work Order Number; First Name; Last Name; UUPIC; Cost; Vendor Fulfillment Date; Service Request Number; Service Name. OtP (Center Validation and EUSO Refreshes) Project SRR, 07/08/14

Level 3-4 functional requirements are identified below. L2 L3 L4 Requirements Statement 3.2.2 Provide reporting via self-service to the I3P BO with export capabilities to both excel and CSV. 4.1 Shall develop and implement a model that allows role based users, managed via NAMS, to access the OtP data stores. 4.1.1 Role based users shall be able to modify data based on categorization of the OtP’s data. The OtP will use the following roles: Center Final Validation queue is the final escalation role at each Center. Center Resource Analyst shall have the privileges necessary to change predefined fields. I3P BO role will have the privileges to maintain all business office data in the database. OtP (Center Validation and EUSO Refreshes) Project SRR, 07/08/14

Level 3-4 functional requirements are identified below. L2 L3 L4 Requirements Statement 4.2 Shall create an electronic system to notify I3P stakeholders when the OtP data store is modified as defined. 4.2.1 All role based users shall have the capability to self-service from the OtP data store to query for changes by date range and field. 4.2.2 Shall utilize a new ACES web service to notify ACES when Service Manager data fields are changed in OtP: fields needed by SM7 UUPIC and Billing Center and other data as defined by the I3P BO. 5.1 Shall provide service display functionality that allows users and on-behalf of users to select an existing service when submitting a Service Request. 5.2 Once this capability is available the services listed in Appendix E will be modified in SDR. When defined in the Service Definition the service display shall show all of the current user’s services unless further restricted by additional requirements. NOTE: If user switches to order on-behalf of another user the display is of the on-behalf of user. 5.3 Shall, in the event all of a user’s services are not displayed, provide instructions or a mechanism for the user to report the discrepancy. OtP (Center Validation and EUSO Refreshes) Project SRR, 07/08/14

Level 3-4 Functional Requirements
Level 3-4 functional requirements are identified below. L2 L3 L4 Requirements Statement 5.4 The following data elements will be displayed to allow the user to select the service they need to action: a. Asset Type b. Asset Description (make/model) c. Asset Tag (for mobile refresh this will be mobile #) d. Serial Number e. Refresh Eligible Date 5.5 Shall allow a user to select one service, auto populate a Service Request with existing service data. Based on the service selected the system should limit the available selections to relevant service types. 6.1 The Enterprise Service Request System shall provide a capability in the catalog for Early Technology Refresh (ETR). 6.1.1 Like to Like (ETR). When the user selects the desired service in ESRS that allows for early tech refresh, the system shall display a list of services within the same category for the user to select for early tech refresh. Example compute to compute; mobile to mobile. The system shall provide the capability to choose one (and only one) type of Service to be refreshed per service request (i.e., compute seat, mobile, etc.). For the chosen service the system shall provide the capability to generate a request for the Asset Transition Value (ATV) and refresh date from the HP-ACES System. OtP (Center Validation and EUSO Refreshes) Project SRR, 07/08/14

Level 3-4 functional requirements are identified below. L2 L3 L4 Requirements Statement After the ATV value is returned, the user selects the service options to be provisioned for the seat the user will receive as an ETR. User hits “Submit Now” for the ETR. The system shall account for constant changing costs in the ATV by clearing all shopping carts in draft status nightly. ESRS should only clear ATV requests. 6.1.2 This capability shall be available for the requestor or for a “request on behalf of”. 6.1.3 Invoicing for a Refreshed Device When an Early Tech Refresh is submitted for invoicing, the following data elements shall be presented to the I3P BO. 6.2 The Enterprise Service Request System shall provide a capability in the catalog for Technology Refresh. OtP (Center Validation and EUSO Refreshes) Project SRR, 07/08/14

Level 3-4 functional requirements are identified below. L2 L3 L4 Requirements Statement 6.2.1 The Enterprise Service Request System shall provide a capability in the catalog for Technology Refresh. Like to Like Refresh will be executed out of the HP System. Fulfillment data will be sent via the Web Interface directly to the data store as defined in These orders will not be initiated through ESRS. Notifications will be sent from HPs System. The centers will not validate like to like refreshes via the Center Validation Tool (CVT). 6.2.2 Like to Unlike is based on the refresh eligible date in ACES’s IT04 data. The user will receive instructions from ACES informing them that if they wish to order a service unlike their current service they may go to ESRS and select the desired service. ACES will provide the user with a link to ESD.NASA.GOV with instructions on how to select a different service and associate the refresh eligible service. OtP (Center Validation and EUSO Refreshes) Project SRR, 07/08/14

Level 3-4 functional requirements are identified below. L2 L3 L4 Requirements Statement Instructions: a. Select Order Services b. Select Service Category c. Select desired service All fields are required: a. Select type of request (new/temp/early tech refresh /tech refresh) i. If “tech refresh” is selected, only services that are “eligible” and of the same service category will be displayed in the drop down. ii. The title of the drop down for eligible services will be “The following seats are available for Tech Refresh. If no seats are displayed then none are eligible for tech refresh. Please select “Early Tech Refresh” for existing assets. b. Select existing asset up for refresh (one and only one) c. Select new service options d. Click Submit All data necessary to order the new service and decommission the old service is captured in the data store Ensure that service is setup to dispatch desubscribe service. When the Remedy SR is submitted ACES is notified of the submitted order for Tech Refresh only. OtP (Center Validation and EUSO Refreshes) Project SRR, 07/08/14

Level 3-4 functional requirements are identified below. L2 L3 L4 Requirements Statement Request follows normal approval process for service request a. ESRS shall send the following data to Service Manager as part of a new service request: 1) New Seat Work Order - (Tech Refresh Type) after approval (same as currently configured WO dispatch web service to ACES). b. Current Asset Info (assumes no free form text except comments) that will be displayed to the Approvers: 1) Existing seat data (see ) 2) Requested seat data (currently provided today in service requests). The service is Approved/Rejected as current process. If approved a WO is dispatched to ACES as per the service definition and follows the normal “new” service process (i.e. center validation) If rejected the Remedy SR moves to closed status and ACES is notified of Remedy SR rejection for Tech Refresh only. (NOTE: This needs to be ACES Services only.) If any Remedy SR (not limited to refreshes) stays in the approval cycle for 60 days the ESRS shall cancel the Remedy SR. (NOTE: This could have impacts on other I3P Service Offices/Vendors. Additional details will need to be addressed.) ACES assumes the user will go back into the refresh pool because they didn’t get an approved “tech refresh” work order. OtP (Center Validation and EUSO Refreshes) Project SRR, 07/08/14

Level 3-4 functional requirements are identified below. L2 L3 L4 Requirements Statement 7.1 Develop a modify web interface for CI/service information from ACES as needed. 7.1.1 Shall develop a web interface that the I3P can utilize to update the OtP data store. 7.1.2 Shall build logic to ensure records are not added or deleted via this web interface. 7.1.3 Exception handling rules need to be in place to ensure that at design time there is appropriate exception handling. 7.1.4 Changes made via this web service will be captured in the OtP data store audit trial. 7.1.5 The I3P BO will provide business rules for like to like and what data is updated. What information will be populated in the order. What fulfillment data is needed. What data is ACES going to be allowed to update. OtP (Center Validation and EUSO Refreshes) Project SRR, 07/08/14

Level 3-4 functional requirements are identified below. L2 L3 L4 Requirements Statement 7.1.6 The I3P BO will provide business rules for like to unlike and what data is updated and how it is validated. What information will be populated in the order. What fulfillment data is needed. What data is ACES going to be allowed to update. 7.2 Data is assumed to be the same information exchanged in the BLT’s as of 4/15/14. 7.2.1 Order information will be the responsibility of NASA. NOTE: Fulfillment data may be as simple as a completed service request which would not be the responsibility of the I3P (example international calling) or fulfillment data may result in a modification to an asset and be the responsibility of the I3P (example seat replacement). OtP (Center Validation and EUSO Refreshes) Project SRR, 07/08/14

Level 3-4 functional requirements are identified below. L2 L3 L4 Requirements Statement 7.3 Web service will be configured to accept an ACES “eligibility” field for use in display My Services. 7.3.1 Not Eligible. This will avoid initiating early refresh during ACES EOL refresh process. 7.3.2 Eligible. This will allow initiating early refresh. 8.1 Shall descope the I3P Program Offices requirement for a NASA CMDB. Service Offices shall depend on vendor provided asset management and CMDB data upon completion of this requirement. OtP (Center Validation and EUSO Refreshes) Project SRR, 07/08/14

Order-to-Pay (OtP) System Requirements Review (SRR)

Similar presentations

Presentation on theme: "Order-to-Pay (OtP) System Requirements Review (SRR)"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Order-to-Pay (OtP) System Requirements Review (SRR)

Similar presentations

Presentation on theme: "Order-to-Pay (OtP) System Requirements Review (SRR)"— Presentation transcript:

Similar presentations

About project

Feedback