Attach006-FMS-ACES RFI - Requirements Master List.xlsx
XLSX spreadsheet 315 KB Posted
- Attached to
- Foreign Military Sales-Army Case Execution System (FMS-ACES) Development and Deployment Federal contract opportunity
- Solicitation number
- W519TC-23-R-ACES
View the file
Other files for this federal contract opportunity
Show all 16
On GovTribe
Work with this file on GovTribe
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Cover Page Attachment 006 – FMS-ACES RFI Requirements Master List
| Request For Information |
| Requirements Master List |
as of 21 OCT 2022
Reference the "Table of Contents" TAB for additional information.
Table of Contents
| Table Of Contents | |
| Tab Name | Description |
| RTM | Requirements Traceability Matrix (RTM) - FMS-ACES Requirements List |
This includes:
Column A - Requirement ID Column B - Core Capability (see FMS-ACES Development and Deployment RFI.pdf for description of each) Column C - Category (e.g., Query/Reports, Alerts and Notifications, Interfaces, etc.) if applicable Column D - Requirement Statement
| Business Rules | A list of Business Rules the system is required to implement. Included are business rules logic, data validation rules, data required to generate reports, specific user access rules, etc. This list is not all encompassing and is intended to provide further context. Business Rules are aligned to Core Capability (Column C) and Category (Column D) where applicable. |
| Interface Requirements | Alignment of required system interfaces to their corresponding requirements in the RTM Tab. |
| Interface Details | 1-n list of system interfaces required to be implemented, and associated attributes for each interface. |
| Interface Definitions | Definition of interface attributes (columns C thru F in Interface Details Tab) |
| LPRDs | Applicable Laws, Policies, Regulations and Directives |
| Acronyms | Acronym List |
RTM
| Requirement ID | Core Capability | Category | FMS-ACES Requirement Statement |
| 1 | Case Closure | The system shall provide the ability to reopen close cases (both Accelerated/Non Accelerated). | |
| 2 | Case Closure | The system shall provide the ability to execute Line Recertification on reopened/closed cases. | |
| 3 | Case Closure | The system shall provide the ability to cancel a case after certification. | |
| 4 | Case Closure | The system shall provide the ability to manage and execute the Line Certifications. | |
| 5 | Case Closure | The system shall provide the ability to manage and execute Case Certifications. | |
| 6 | Case Implementation | The system shall provide the ability to receive case documentation and authority for implementation. | |
| 7 | Case Implementation | The system shall provide the ability to manually force implement a case. | |
| 8 | Case Implementation | The system shall provide the ability to manually update the LOA Master data to implemented. | |
| 9 | Case Implementation | The system shall provide the ability to emergency implement a case. | |
| 10 | Case Implementation | The system shall provide the ability to perform logistical page review for execution. | |
| 11 | Case Initiation | The system shall provide the ability to receive case data from DSAMS and create a new and/or populate an existing case master record (ILIF). | |
| 12 | Case Initiation | The system shall provide the ability to manually create a new case master record (ILIF) based on defined user roles. | |
| 13 | Case Initiation | The system shall provide the ability to manually create a new Presidential Drawdown record based on defined user roles. | |
| 14 | Case Initiation | The system shall provide the ability to validate the case status (Proposed, Offered, Accepted, Implemented) and take appropriate action based on validation rules. | |
| 15 | Case Lifecycle | The system shall provide the ability to track and display the real time status via dashboard of each case and provide alerts and/or notifications IAW established business rules/parameters based on defined user roles. | |
| 16 | Case Lifecycle | The system shall provide the ability to manage Case Cost, Schedule and Performance. | |
| 17 | Case Lifecycle | The system shall provide the ability to execute Case Financial Evaluations. | |
| 18 | Case Lifecycle | The system shall provide the ability to execute Case Logistical Evaluations. | |
| 19 | Case Lifecycle | The system shall provide the ability to execute Case Closure Evaluation. | |
| 20 | Case Lifecycle | The system shall provide the ability to create and Maintain the Case Master Plan. | |
| 21 | Case Lifecycle | The system shall provide the ability to conduct Case Lifecycle Management Reviews to include centralized error correction activities. | |
| 22 | Foundational | The system shall be compliant with CJCSI 6211.02C (DISN). | |
| 23 | Financial Execution | The system shall provide the ability to receive and process case and line funding data. | |
| 24 | Financial Execution | The system shall provide the ability to receive and process requisition funding data. | |
| 25 | Financial Execution | The system shall provide the ability to trigger the execution of Emergency Order funding data. | |
| 26 | Financial Execution | The system shall provide the ability to receive and execute Interfund Accruals. | |
| 27 | Financial Execution | The system shall provide the ability to receive and manage Purchase Card data. | |
| 28 | Financial Execution | The system shall provide the ability to trigger the execution of Travel Case funding data. | |
| 29 | Financial Execution | The system shall provide the ability to process Write-Offs for irresolvable Supply Discrepancy Reports (SDR). | |
| 30 | Financial Execution | The system shall provide the ability to create and manage publication billing. | |
| 31 | Financial Execution | The system shall provide the ability to manage the FMSO1 process (Part "A") IAW Security Assistance Management Manual (SAMM). | |
| 32 | Financial Execution | The system shall provide the ability to receive and execute Interfund Billing. | |
| 33 | Financial Execution | The system shall provide the ability to manage the performance of and trigger the execution of disbursements. | |
| 34 | Foundational | The system shall provide the ability to create/read/update/delete business rules using existing data fields based on user defined roles. | |
| 35 | Foundational | The system shall provide the ability to create/read/update/delete reference tables. | |
| 36 | Foundational | Interface | The system shall provide the ability to prioritize and process incoming transactions based on defined and configurable business rules. |
| 37 | Foundational | The system shall provide the ability to maintain consistency with numerical data formats (date, dollars, numbers) IAW LPRDs. | |
| 38 | Foundational | Data Migration | The system shall provide the ability to accept and load legacy data for conversion. |
| 39 | Foundational | Cyber | The system shall provide the ability to incorporate Public Key Infrastructure (PKI), Public Key Cryptography (PKC) and Secure Sockets Layer (SSL) to enable secure authentication, log-on, and encrypted transmission of sensitive data to client workstations in accordance with published DoD policy and procedures. |
| 40 | Foundational | The system shall provide the ability to monitor all system logs to identify anomalies in data, data volume, account status, rejects, etc. | |
| 41 | Foundational | Cyber | The system shall provide the ability the use of a Defense Militarized Zone (DMZ) in the system design is required for any remote access as well as any access to the Internet through systems that are isolated from all other DoD information systems through physical means. |
| 42 | Foundational | Cyber | The system shall provide the ability to satisfy Connection Approval Procedures (CAP) prior to connection to the Defense Information System Network (DISN). |
| 43 | Foundational | Cyber | The system shall provide the ability for products or technology whose primary purpose is to provide security services (e.g., firewalls, encryptors, intrusion detection devices) to comply with Common Criteria Certification (CCC) which produces an Evaluation Assurance Level (EAL) that represents a level of confidence in the security functions. |
| 44 | Foundational | Cyber | The system shall provide the ability for products or technology whose primary role is not security, but which provides security services as an associated feature of its intended operating capabilities to be configured in accordance with DoD-approved Security Technical Implementation Guidance (STIG) |
| 45 | Foundational | Cyber | The system shall provide the ability to support DoD-approved Antivirus protection with automatic update ability. |
| 46 | Foundational | Cyber | The system shall be compliant with DoDI 8500.2 (IA Implementation). |
| 47 | Foundational | Cyber | The system shall be compliant with DoDI 5400.16 (PIA). |
| 48 | Foundational | Cyber | The system shall be compliant with DoDD 8570.01-M (IA Workforce Improvement Program). |
| 49 | Foundational | Cyber | The system shall be compliant with FIPS PUB 140-2 (Cryptographic). |
| 50 | Foundational | Cyber | The system shall be compliant with DoDI 8510.01 (DIACAP). |
| 51 | Foundational | Cyber | The system shall be compliant with DoD STIGS. |
| 52 | Foundational | Cyber | The system shall be compliant with IA Controls as listed in the DIACAP Knowledge Service for MAC & CL. |
| 53 | Foundational | Cyber | The system shall be compliant with CJCSM 6510.01. |
| 54 | Foundational | Cyber | The system shall be compliant with DoDD 8500.1. |
| 55 | Foundational | Cyber | The system shall be compliant with DoDI 8500.2. |
| 56 | Foundational | The system shall provide the ability for processing online transactions, batch jobs and transactions submitted via system interface simultaneously. | |
| 57 | Foundational | The system shall provide the ability to reject transactions from business partners and provide the ability to recycle. |
Reject processing shall include the ability to perform the following functions:
- Report rejected transactions
- Report recycled transactions
| 58 | Foundational | The system shall provide the ability for internal database controls to maintain internal database consistency at all times. In the event of a system failure, the system shall have the ability to re-apply all incomplete transactions previously submitted by the user. | |
| 59 | Foundational | The system shall provide the ability for system administrators to restart failed or incomplete batch jobs without creating duplicate records. | |
| 60 | Foundational | The system shall provide the ability to process batch jobs without impacting system performance or availability. | |
| 61 | Foundational | The system shall provide the capacity to complete all required processing within the specified batch processing window and report on the system performance to this requirement. | |
| 62 | Foundational | Performance | The system shall provide the ability to update/refresh a display (web page) within 5 seconds, after all display associated database operations are complete. |
| 63 | Foundational | Performance | The system shall provide response times of less than 2 seconds for all screens that have static content or are unpopulated forms, based on minimal latency and bandwidth issues. |
| 64 | Foundational | Performance | The system shall provide the ability to provide a report on response time performance. |
| 65 | Foundational | Performance | The system shall provide the ability to have a response times of less than 5 seconds for all screens/queries.. Screens requiring more than 10 seconds should be tuned to the extent technically feasible. |
| 66 | Foundational | Performance | The system shall provide the ability to generate user initiated reports within a reasonable response time (10 seconds) under normal operating load. |
| 67 | Foundational | Compliance | The system shall be implemented, using the American National Standards Institute (ANSI) X-12 standards, IAW DoDD 8190.01, DoD Logistics Use of Electronic Data Interchange (EDI) Standards. |
| 68 | Foundational | Compliance | The system shall be implemented IAW DoD NetOps Global Information Grid as specified in the latest version of DoDI 8410.02 or its superseding DoDI. |
| 69 | Foundational | Compliance | The system shall be implement IAW the latest version of DoD Guidance 8320.02-G (Guidance for Implementing Net-Centric Data Sharing) or its superseding DOD Guidance. |
| 70 | Foundational | Compliance | The system shall be implemented IAW Data Sharing in a Net-Centric DoD and the Department of Defense Net-Centric Service Strategy, 05/04/2007, or the latest approved versions. |
| 71 | Foundational | Compliance | The system shall be implemented IAW DoDI 5400.16, Privacy Impact Assessment (PIA) Guidance, 2/12/2009, or the latest approved version. |
| 72 | Foundational | Compliance | The system shall be implemented IAW DoDI 4630.08 Procedures for Interoperability and Supportability of Information Technology (IT) and National Security Systems (NSS), 6/30/2004, or the latest approved version. |
| 73 | Foundational | LPRD | Provide the ability for upgradeability. The delivered system must be upgradeable to accommodate changes in LPRD or new technology. |
| 74 | Foundational | The system shall provide the ability for data entry efficiencies. | |
| 75 | Foundational | The system shall provide user interface features designed to reduce the amount of direct keying required for transaction processing such as: |
• Default values based on system maintained transaction and user profiles
• Value look-up tables
• Highlighting or accentuating required fields
• Grayed data fields that are unavailable for user entry
• Cut/copy/paste functionality
• Keyboard shortcuts (e.g. function keys to invoke help facility clear screen etc.)
• Menu mode of screen navigation
• Ability to select records from a list by scrolling or typing only part of an entry.
| 76 | Foundational | The system shall provide the ability to integrate with (upload/download) other common desktop applications (e.g., Microsoft Office Suite, Adobe, Tableau, etc.). | |
| 77 | Foundational | The system shall adopt the use of standard DoD language and naming conventions to the extent practical. | |
| 78 | Foundational | The system shall provide web based user interfaces for all authorized users. | |
| 79 | Foundational | The system shall provide the ability to customize workflow processes to automate agency-defined business rules. | |
| 80 | Foundational | The system shall provide the ability to make data corrections for harmonization and data quality based on defined user roles. | |
| 81 | Foundational | The system shall provide the ability to suspend an interface as required. | |
| 82 | Foundational | The system shall provide the ability to assign and manage roles based on organization division, branch, country, service, case and line. | |
| 83 | Foundational | Interface | The system shall provide the ability to perform an automatic reconciliation between the data posted in the case master file and information received from other systems (e.g., DSAMS, GFEBS) and provide results to the case manager. |
| 84 | Foundational | Audit | The system shall provide the ability to maintain an audit trail of manual changes to data after it has been submitted. The audit shall include the ID of the individual making the change, the IP address from which the change was made, the DTG of the change, what field, record was changed, type of change (add, modify, delete), what it was changed from, and what it was changed to. |
| 85 | Foundational | Data Retention | The system shall provide the ability to retain CLSSA Program Files for the previous 10 calendar years. |
| 86 | Foundational | Data Retention | The system shall provide the ability to archive logistical, financial, and contractual data IAW Army and DoD Retention Policy |
| 87 | Foundational | Query/Report | The system shall provide the ability to archive, retrieve, and restore system data for closed cases IAW Army and DoD retention policies. Data shall be retrievable and restorable at the country, case, line, or requisition level. |
| 88 | Foundational | Alerts and Notifications | The system shall provide the ability to display notifications upon logon based on user profile and roles. |
| 89 | Foundational | Query/Report | The system shall provide the ability to generate exception reports (logs) and notifications for any interfaced transmission failures. |
| 90 | Foundational | The system shall provide the ability for an authorized user to access data element definitions and associated code definitions (e.g. delivery term code, status codes) on view screens, wizard programs, and ad hoc report generation screens. | |
| 91 | Foundational | The system shall provide the ability to generate Job processing alerts and notifications, to include job or transaction type, name, when processing initiates, when it completes, and any processing errors encountered. | |
| 92 | Foundational | Query/Report | The system shall provide the ability for Productivity reporting. |
| 93 | Foundational | Query/Report | The system shall provide the ability to maintain and report application usage statistics. Productivity statistics shall include concurrent users, job submissions, transactions throughput and system availability. |
| 94 | Foundational | Query/Report | The system shall provide the ability for an authorized user to specify a recurring time interval for an ad hoc report to be generated, notify the requestor of the report when it has been generated and is available, and allow the requester or admin to suspend or terminate these reports. |
| 95 | Foundational | Query/Report | The system shall provide the ability to query database auditing. |
| 96 | Foundational | The system shall provide the ability to create and sort rejects and notification by Country, Case or by specific system user ID. | |
| 97 | Foundational | Query/Report | The system shall provide the ability to display a header and footer on reports, such as disclaimers on pages and reports. |
| 98 | Foundational | The system shall provide the ability to Create/Read/Update/Delete/Print case master record data based on defined user roles. | |
| 99 | Foundational | The system shall provide the ability to Create/Read/Update/Delete/Print Presidential Drawdown record data based on defined user roles. | |
| 100 | Foundational | Document Management | The system shall provide the ability to use a document upload tool to associate supporting documentation, images, and/or data contained to a specific case, line, requisition, etc. according to user defined permissions. |
| 101 | Foundational | The system shall provide the ability to maintain historic versions of the Case (new version would be created each time a Modification or Amendment is Implemented). | |
| 102 | Foundational | Query/Report | The system shall provide the ability to perform analytics and generate reports based on predefined business rules and processes. |
| 103 | Foundational | Document Management | The system shall provide the ability to share documents for approval with electronic signature. |
| 104 | Foundational | The system shall provide the ability to allow authorized user to access online help. | |
| 105 | Foundational | Testing | The system shall provide the ability to test the system in accordance with US Army and non-Army systems acceptance criteria with hands on user acceptance testing and sandbox capabilities. |
| 106 | Foundational | Continuous Upgrades | The system shall provide a multi-tenant environment from which continuous upgrades are issued based on best business practices or changes in law, policy, regulations, directives (LPRD). |
| 107 | Foundational | Continuous Upgrades | The system shall provide a multi-tenant environment from which continuous security upgrades are issued based on best business practices. |
| 108 | Foundational | Continuous Upgrades | The system shall provide a multi-tenant environment from which continuous application upgrades are issued based on best business practices. |
| 109 | Foundational | Continuous Upgrades | The system shall provide a multi-tenant environment from which continuous innovation ability can be made available based on best business practices. |
| 110 | Foundational | Common Operating Picture (COP) | The system shall provide the ability to create and display a Common Operating Picture. |
| 111 | Foundational | Common Operating Picture (COP) | The system shall provide the ability for a user to create and interact with configurable dashboards and reports in multiple formats based on user role. |
| 112 | Foundational | Common Operating Picture (COP) | The system shall provide standardized content for user defined displays that are configurable based upon role. |
| 113 | Foundational | Common Operating Picture (COP) | The system shall provide the ability for a user to create a configurable dashboard in multiple format based on user role. |
| 114 | Foundational | Common Operating Picture (COP) | The system shall provide the ability for a user to create a configurable report in multiple formats based on user role. |
| 115 | Foundational | Common Operating Picture (COP) | The system shall provide the ability for a user to interact with the user dashboard in multiple formats based on user role. |
| 116 | Foundational | Common Operating Picture (COP) | The system shall provide the ability for a user to interact with the user reports in multiple formats based on user role. |
| 117 | Foundational | Common Operating Picture (COP) | The system shall provide tracking data and make it available to users based on role. |
| 118 | Foundational | Common Operating Picture (COP) | The system shall provide the ability to create standardized templates based on defined user roles. |
| 119 | Foundational | Common Operating Picture (COP) | The system shall provide the ability to standardize data input and reduce the amount of free text. |
| 120 | Foundational | Common Operating Picture (COP) | The system shall provide the ability to print locally and remotely. |
| 121 | Foundational | Common Operating Picture (COP) | The system shall provide the ability for users to upload documents. |
| 122 | Foundational | LPRD | The system shall provide the ability to implement system changes based on changes to applicable laws, policies, regulations, and directives (LPRDs). |
| 123 | Foundational | LPRD | The system shall provide the ability to implement system changes in support of laws, policies, regulations, and directives (LPRDs). |
| 124 | Foundational | LPRD | The system shall provide the ability to implement system changes in support of directive changes. |
| 125 | Foundational | LPRD | The system shall provide the ability to implement system changes in support of statutory changes. |
| 126 | Foundational | LPRD | The system shall provide the ability to implement system changes in support of policy changes. |
| 127 | Foundational | LPRD | The system shall provide the ability to implement system changes in support of regulatory changes. |
| 128 | Foundational | LPRD | The system shall provide the ability to rapidly implement system-configurable parameter changes in support of statutory changes. |
| 129 | Foundational | LPRD | The system shall provide the ability to rapidly implement system-configurable parameter changes in support of policy changes. |
| 130 | Foundational | LPRD | The system shall provide the ability to rapidly implement system-configurable parameter changes in support of regulatory changes. |
| 131 | Foundational | LPRD | The system shall provide the ability to track and report system changes. |
| 132 | Foundational | LPRD | The system shall provide the ability to centrally deploy system changes and updates. |
| 133 | Foundational | LPRD | The system shall provide the ability to predict and assess the impacts of changes to doctrine, laws, policies, regulations, and directives (LPRDs). |
| 134 | Foundational | LPRD | The system shall provide the ability to create user-defined and configurable business rules. |
| 135 | Foundational | LPRD | The system shall provide the ability to create user-defined and configurable workflows. |
| 136 | Foundational | Business Process Workflow Automation | The system shall provide the ability to automate business process workflows via a visual display. |
| 137 | Foundational | Business Process Workflow Automation | The system shall provide a user-facing application processing workflow with embedded help ability. |
| 138 | Foundational | Business Process Workflow Automation | The system shall provide the ability to implement standardized workflow processes and procedures that are available for the next action by authorized users in near real time 99% of the time. |
| 139 | Foundational | Business Process Workflow Automation | The system shall provide the ability to define workflow processes and procedures that allow parallel workflows and concurrent users. |
| 140 | Foundational | Document Management | The system shall provide the ability to perform document management. |
| 141 | Foundational | Data Quality | The system shall provide the ability for single data entry that populates required fields for specified forms. |
| 142 | Foundational | Document Management | The system shall provide the ability to generate paperless documents complete with an authentication in accordance with laws, policies, regulations, and directives (LPRDs). |
| 143 | Foundational | Document Management | The system shall provide the ability to prompt the user to obtain a new signature if form data was changed subsequent to signing. |
| 144 | Foundational | Document Management | The system shall provide the ability to amend, append, or revoke a form subsequent to signing. |
| 145 | Foundational | Alerts and Notifications | The system shall provide the ability to send alerts and notifications. |
| 146 | Foundational | Alerts and Notifications | The system shall provide the ability to send alerts and notifications in accordance with defined business rules. |
| 147 | Foundational | Alerts and Notifications | The system shall provide the ability to send alerts and notifications in accordance with defined workflows. |
| 148 | Foundational | Alerts and Notifications | The system shall provide the ability to send system-wide alerts and notifications. |
| 149 | Foundational | Data Quality | The system shall provide data validation. |
| 150 | Foundational | Data Quality | The system shall provide an automated validation function. |
| 151 | Foundational | Data Quality | The system shall provide the ability for real-time data validation during business process workflows. |
| 152 | Foundational | Data Quality | The system shall provide the ability to identify and flag data that has failed validation within the country, case, and line. |
| 153 | Foundational | The system shall be able to use currently approved user authentication methods. | |
| 154 | Foundational | The system shall provide an application-based, operating system-agnostic capability. | |
| 155 | Foundational | The system shall provide the ability to operate on approved devices. | |
| 156 | Foundational | The system shall provide the ability to perform administrative functions based on defined user roles. | |
| 157 | Foundational | The system shall provide a user-configurable, interactive, context-aware help ability within business process implementation. | |
| 158 | Foundational | The system shall provide the ability for a consistent user experience across all approved devices commensurate with platform specifications. | |
| 159 | Foundational | The system shall provide access to multiple domains including NIPR, .com, .gov, .org, and .net. | |
| 160 | Foundational | Interoperability | The system shall comply with Interoperability of Information Technology (IT) IAW DoDI 8330.01. |
| 161 | Foundational | Interoperability | The system shall support the Key Management Interoperability Protocol (KMIP) standard. |
| 162 | Foundational | Interoperability | The system shall be compliant with Net-Centric Data Strategy and Net-Centric Services Strategy. |
| 163 | Foundational | Interoperability | The system shall support contingency planning for a MAC level III systems as defined by AR 25-2. |
| 164 | Foundational | Interoperability | The system shall comply with DoD IA requirements IAW DoD Instruction 8580.1. |
| 165 | Foundational | Interoperability | The system shall provide client-side security. |
| 166 | Foundational | Interoperability | The system shall support soft certifications (software form of PKI credentials). |
| 167 | Foundational | Compliance | The system shall support compliance with DA and DoD requirements in a commercial cloud configuration, and the National Institute of Standards and Technology Special Publication 800-145, September 2011. |
| 168 | Foundational | Compliance | The system shall provide automatic virtual server provisioning to dynamically scale capacity during demand spikes to maintain performance and decrease capacity during lulls to reduce costs. |
| 169 | Foundational | Compliance | The system shall be compliant with FEDRAMP+ security controls and DoD Cloud Computing Security Requirements Guide (SRG) cloud security information impact level (IL) 4 security controls. |
| 170 | Foundational | Compliance | The system shall provide capabilities that are available over the network and accessed through standard mechanisms that promote use by heterogeneous thin or thick client platforms (e.g., tablets, laptops). |
| 171 | Foundational | Compliance | The system shall provide computing resources that are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to consumer demand. |
| 172 | Foundational | Compliance | The system shall provide the ability to automatically control and optimize resource use by leveraging a metering ability at some level of abstraction appropriate to the type of service provided (e.g., storage, processing, bandwidth, and active user accounts) so that resource usage can be monitored, controlled, and reported. |
| 173 | Foundational | Compliance | The system shall provide the ability to limit a user's access to data and reports at the organizational level required with a level of accuracy that meets or exceeds industry standards (e.g., a 99.9% level of accuracy). |
| 174 | Foundational | Compliance | The system shall provide a 508 compliant or certified exempt, client, or Web-based user interface. |
| 175 | Foundational | System Availability | The system shall provide a mission availability rate of 98%. |
| 176 | Foundational | The system shall have at least a 98% probability of operating over a 72 hour period without an Essential Function Failure (EFF). | |
| 177 | Foundational | The system shall ensure a mean time between failures (MTBF) of greater than 4 weeks, and a mean time to repair (MTTR) of less than 2 hours. | |
| 178 | Foundational | Compliance | The system shall comply with Information Assurance Requirements IAW DoDD 8500.01E. |
| 179 | Foundational | Compliance | The system shall comply with all Information Assurance requirements as defined in the FMS-ACES program guidance for DoD, Army, and National Institute of Standards and Technology (NIST) Policy, Guidance, and Directives. |
| 180 | Foundational | Single Data Entry | The system shall maximize single data entry. |
| 181 | Foundational | Single Data Entry | The system shall derive a minimum of 95% of postings from single entry of data. |
| 182 | Foundational | Disaster Recovery | The system shall provide a backup and disaster recovery ability. |
| 183 | Foundational | Disaster Recovery | The system shall provide recovery of full capabilities within 24 hours of the official declaration of a disaster (e.g. loss of the primary data center), to include reestablishment of critical system interfaces, to a state not more than 4 hours prior to disaster Recovery Point Objective (RPO). |
| 184 | Foundational | Query/Report | The system shall provide the ability for all transactions internal to FMS-ACES (which do not involve exchanging data with any partner system) to be recorded and viewable for reporting in real time. |
| 185 | Foundational | Query/Report | The system shall provide the ability for all transactions external to FMS-ACES (requiring data exchange with one or more partner systems) to be recorded and viewable for reporting in near real time. |
| 186 | Foundational | Interface | The system shall provide the ability to interface with financial systems of record (SOR). |
| 187 | Foundational | Interface | The system shall provide the ability to interface with logistics systems of record (SOR). |
| 188 | Foundational | Interface | The system shall provide the ability to interface with DoD reporting systems of record (SOR). |
| 189 | Foundational | Interface | The system shall provide the ability to interface with DoD enterprise analytical platforms and data warehouses. |
| 190 | Foundational | Interface | The system shall provide the ability to prepare and securely transmit accurate status reports and data to military departments and agencies via electronic files or API. |
| 191 | Foundational | Interface | The system shall provide the ability to interface with DoD enterprise analytical platforms and data warehouses. |
| 192 | Foundational | Interface | The system shall provide the ability to exchange information with Army commands, agencies, and offices. |
| 193 | Foundational | Interface | The system shall provide the ability to exchange information with Joint Commands and other military departments. |
| 194 | Foundational | Interface | The system shall provide the ability to interface with systems in accordance with the OV-3: Operational Resource Flow Matrix and Information Exchange Requirements. |
| 195 | Foundational | Deduplication | The system shall provide the ability to identify duplicate data entering the system and provide the ability to deconflict duplicate data based on user defined roles. |
| 196 | Foundational | The system shall be compliant with DoDD 5200.1-R. | |
| 197 | Foundational | The system shall be compliant with ASD (C31) Memorandum dated 6/4/01 (Disposal of Unclassed HD). | |
| 198 | Foundational | The system shall be compliant (for regulation/directives sections which are applicable) with DoDD S-5200.19 (TEMPEST). | |
| 199 | Logistics | The system shall provide the ability to flag requisitions that have failed validation. | |
| 200 | Logistics | The system shall provide the ability to re-generate any reject (controlled exception) that is deleted in error. | |
| 201 | Logistics | The system shall provide the ability to systematically assign a unique reject code for each controlled exception and a reference table to provide the user with the reason for the reject and processing instructions to resolve it. | |
| 202 | Logistics | The system shall provide the ability to assign project codes at a case level and line level. | |
| 203 | Logistics | The system shall provide the ability to store the major shipment milestones from initial shipment (from the depot or vendor) to receipt by the BPC Customer. | |
| 204 | Logistics | The system shall provide the ability to create a funding only document (Pseudo) to General Fund Enterprise Business System (GFEBS). | |
| 205 | Logistics | The system shall provide the ability to generate cancellation requests (869C) to the source of supply to stop logistical actions/delivery at the Country, Case, line, requisition level as required.(i.e. sanctions). | |
| 206 | Logistics | The system shall provide the ability to manually create a Supply Discrepancy Report (SDR) record based on defined user roles. | |
| 207 | Logistics | The system shall provide the ability to query and display data from the Supply Discrepancy Report (SDR) record. | |
| 208 | Logistics | The system shall provide the ability to Create/Update/read/Delete/Print Supply Discrepancy Report (SDR) record data based on defined roles. | |
| 209 | Logistics | The system shall provide the ability to allow limited deletion capabilities as long as the Progression Code has not progressed beyond date code "B" . | |
| 210 | Logistics | The system shall provide the ability to calculate an average monthly demand for each NIIN determined to be included in the CLSSA forecast process. (Always round down) | |
| 211 | Logistics | The system shall provide the ability to update all equity list attributes. | |
| 212 | Logistics | The system shall provide the ability to duplicate CSP Master file list generated for one country to another. | |
| 213 | Logistics | The system shall provide the ability to create/read/update/delete standard templates (e.g., CSP Master File List). | |
| 214 | Logistics | The system shall provide the ability to systematically create a duplicate CSP list when requested by the CM. | |
| 215 | Logistics | The system shall provide the ability to track publication requisitions through the approval/release authority process (request, approval/disapproval and release). | |
| 216 | Logistics | The system shall provide the ability to recycle/reuse publication account numbers. | |
| 217 | Logistics | The system shall provide ability to add remarks to the SDR master file. | |
| 218 | Logistics | The system shall provide the ability to Create/Update/read/Delete/Print line/sub-line record data based on user defined roles. | |
| 219 | Logistics | The system shall provide ability to allow end users to create/read/update/delete publication account numbers (PANs) associated to a Country and Case. | |
| 220 | Logistics | Financial | The system shall provide the ability to create/read/update/delete a Supply Discrepancy Report (SDR) record based on defined user roles. |
| 221 | Logistics | Financial | The system shall provide the ability to create a new and/or populate an existing Material Request History and Status (MRHS) record based on defined user roles. |
| 222 | Logistics | Financial | The system shall provide the ability to receive requisition data and create a new and/or populate an existing Material Request History and Status (MRHS) record based on defined user roles. |
Business Rules
| Business Rule ID | Core Capability | Category | Business Rule Description |
| 1 | Case Closure | Document Management | For Army and supported IAs, produce a unique closure certificate for each of the three closure types (direct final closure, interim closure and interim to final closure). |
| 2 | Case Closure | Query/Report | Query each case line with logic programmed to find and code Command case lines that have all materiel requisitions shipped and all services completed, however other Command lines on the case are not SSC as supply, service complete (SSC) with priority code 2. |
| 3 | Case Closure | Query/Report | Query each case line with logic programmed to find and code Command case lines that have at least one Command line that has all materiel requisitions shipped and all services completed, however has at least one Command line on the case is not SSC as supply, service complete (SSC) with priority code 3. |
| 4 | Case Closure | User Roles and Permissions | For Army and supported IAs, provide the capability For the Case Closure management team to manually submit a line IHC that codes the line For deletion in the case closure master. The new system then systemically removes the line from the case closure master. |
| 5 | Case Closure | For Army and supported IAs, prevent an ACCP Country case with a ULO threshold from being interim certified for closure if the ULO threshold is higher than the country allowed ULO threshold. | |
| 6 | Case Closure | For Army and supported IAs, when a case is re-opened or moved back to C2 status, submit a request to the PBAS Administration at USASAC Finance Office to take the case back to AC or C2 status in PBAS/PBAS replacement systems. This appears to be a USASAC "super user role". | |
| 7 | Case Closure | For Army and supported IAs, provide the capability For the CCM to input a check to an override button in the system if the CCM is certifying an interim case For closure with the ULO balance exceeding the ULO closure threshold and with country permission to certify the case with the exceeded ULO closure threshold. | |
| 8 | Case Closure | For Army and supported IAs, provide the capability For the calendar year and month alpha inhibitor codes to be automatically added to the system and the Mutual Date File (MDF) three months beFore the new calendar year. Example: January 2015 alpha inhibitor code is "XA" and December 2015 alpha inhibitor code is "XL". In October 2014, "XA" through "XL" should be automatically added to the system with the definition and timeframe to resolve the inhibitor code. | |
| 9 | Case Closure | For Army and supported IAs, capture and display current case closure progression code (PC) For each case and line. The system must be able to use the 3 case closure PC's to systemically prioritize workload For the case and line managers. PC 1 identifies cases that are supply, service complete (SSC), which means all materiel has shipped and all services are completed For all lines on the case. PC 2 identifies case lines that are SSC For a Command. PC 3 identifies case lines that have some lines that are SSC and at least one line that is not SSC. | |
| 10 | Case Closure | Propagate the SSC date using the latest ship date or service completion date at case, line and requisition level(s). | |
| 11 | Case Closure | For Army and supported IAs, identify and notify the Case Manager when the remaining Unliquidated Obligation (ULO) value is at or below the ULO threshold at the case level and case certification can begin. (Example NE greater than $250,000) | |
| 12 | Case Closure | For Army and supported IAs, receive transactions (from system perForming DIFS/replacement system functions) (DIFS MO transactions) confirming a refund on the unliquidated obligation (ULO) amount For a final or interim closed case occurred at case/line level to include the date of transaction, Country Code, Case and Line and automatically post this transaction at case/line level in the case closure master file in the new system. | |
| 13 | Case Closure | For Army and supported IAs, notify the case closure team, the central case manager (CCM) and financial manager when a transaction For a case in final closure status is received to include line level detail of all ULO refunds that processed against this case. | |
| 14 | Case Closure | For Army and supported IAs, perForm a calculation of the ULO and applicable surcharges For and view the ULO to automatically calculate the surcharges and accessorial For Accelerated Case Closure Program (ACCP) cases using data from the Case Master to include the annual CAS percentages at the requisition level. | |
| 15 | Case Closure | For Army and supported IAs, notify the Central Case Manager and Line Financial Manager when obligation and expenditures are equal on an ACCP interim closed case in order to review and prepare For financial closure. | |
| 16 | Case Closure | For Army and supported IAs, notify the CCM and FM when actual Contract Administrative Services (CAS) exceeds estimated CAS by configurable amount or percentage. | |
| 17 | Case Closure | For Army and supported IAs, provide the capability For those Purchasers participating in ACCP to interim close the ACCP case with ULO. | |
| 18 | Case Closure | For Army and supported IAs, systemically populate the applicable case closure inhibitors when the case is systemically changed to SSC. | |
| 19 | Case Closure | For Army and supported IAs, validate that all verification steps were taken prior to allowing the IA to certify the case For closure under ACCP interim procedures, using business rules at case and line levels. | |
| 20 | Case Closure | For Army and supported IAs, validate that all verification steps were taken prior to allowing the IA to certify the case For closure under ACCP direct final procedures, using business rules at case level. | |
| 21 | Case Closure | For Army and supported IAs, validate that all verification steps were taken prior to allowing a case closure transaction to be sent under Non-ACCP procedures, using business rules at case and line levels. | |
| 22 | Case Closure | For Army and supported IAs, validate that all verification steps were taken prior to allowing a case to progress from ACCP interim to ACCP final status, using business rules provided at case and line levels. | |
| 23 | Case Closure | For Army and supported IAs, validate that all verification steps were taken prior to allowing a case to revert from ACCP final to ACCP interim status, using business rules provided at case and line levels. | |
| 24 | Case Closure | For Army and supported IAs, validate that all verification steps were taken prior to allowing a non-ACCP case to revert from closed to an implemented status, using business rules provided at case and line levels. | |
| 25 | Case Closure | For Army and supported IAs, establish an inhibitor review suspense date, based on the type of inhibitor assigned at the case, line and subline level. | |
| 26 | Case Closure | For Army and supported IAs, systemically calculate and update the latest line inhibitor suspense date at the line and subline level using the case closure inhibitor mutual data file. | |
| 27 | Case Closure | For Army and supported IAs, update the estimated closure date For the Case based on the latest line inhibitor suspense date For all the lines within the case. | |
| 28 | Case Closure | For Army and supported IAs, notify the applicable case/line logistic/financial manager on the next review suspense date or when the last inhibitor is cleared at the case, line and subline level. | |
| 29 | Case Closure | For Army and supported IAs, automatically assign standard closure inhibitor codes to lines and cases identified as Supply Service Complete(SSC) and progress closure inhibitor codes as conditions are satisfied at case and line level. | |
| 30 | Case Closure | For Army and supported IAs, record central case manager approval and date For the case closure certificate at case level in the case closure master. | |
| 31 | Case Closure | For Army and supported IAs, provide the capability upon the case closure certification to prevent manual input or systemic receipt of new requisitions. | |
| 32 | Case Closure | For Army and supported IAs, notify the Case Manager and FMS Customer when the case is closed and provide the closure date value. | |
| 33 | Case Closure | For Army and supported IAs, notify Case Manager, Financial Manager and DFAS of ACCP cases that are Supply Services Complete (SSC) For greater than 18 months that have not been submitted For closure. | |
| 34 | Case Closure | For Army and supported IAs, notify case manager and financial manager of ACCP cases SSC greater than two years that have not been submitted For closure and do not have the following closure inhibitors in the SAMM RCG: SC, KO, AF, LP, SU, AA, PD. | |
| 35 | Case Closure | For Army and supported IAs, send notifications to the Case Manager and Financial Manager For Non ACCP eligible cases based on configurable timeframes when the supply/services completion date is greater than two years and the case has not been submitted For closure provided the following closure inhibitors in the SAMM RCG are not identified : OC, FD, SC, KO, AF, LP, SU, AA, PD. | |
| 36 | Case Closure | For Army and supported IAs, notify the CCM and Financial manager of interim closed cases where the ULO has not changed within a configurable timeframe using data from Army accounting systems and non-Army agency accounting system/DAI. | |
| 37 | Case Closure | For Army and supported IAs, notify case managers at configurable timeframes For cases after estimated SSC date at Case/line level and the Case/line SSC date has not been posted. | |
| 38 | Case Closure | For Army and supported IAs, notify the CCM and financial manager at configurable timeframes that non-ACCP case is eligible For closure based on the last contract physical completion date when Open Contract (OC) is the only closure inhibitor. | |
| 39 | Case Closure | For Army and supported IAs, notify the CCM and FMS Customer when a case systemically becomes supply service complete (SSC). | |
| 40 | Case Closure | For Army and supported IAs, alert the CCM and Financial Manager when all closure inhibitors have been resolved at case and line level. | |
| 41 | Case Closure | For Army and supported IAs, systemically record that all lines on a case are financially complete. | |
| 42 | Case Closure | For Army and supported IAs, alert the financial line manager when a case line is logistically complete by assigning the appropriate reason (inhibitor) code to begin the financial reconciliation of the case line. | |
| 43 | Case Closure | For Army and supported IAs, automatically populate the SSC date using the latest ship date or service completion date at both line and case level. | |
| 44 | Case Closure | Validate that all FMSO II cases are closed prior to closing the related FMSO I case. | |
| 45 | Case Closure | For Army and supported IAs, create and maintain the closure certificate versions (Direct final closure, Interim Closure, Non-ACCP Closure and Interim to Final Closure) that were processed on each FMS Case to include date of closure certificate and closure values. | |
| 46 | Case Closure | For Army and supported IAs, send a notification when an ACCP case is within a configurable number of days from an estimated closure date. | |
| 47 | Case Closure | For Army and supported IAs, systemically suspend a requisition received when a line is supply service complete (SSC), and send an alert to the CCM. | |
| 48 | Case Closure | Manually submit an inhibitor code that allows the case to remain open and permits additional requisitions to process against the case when all lines are SSC using supporting narrative text. | |
| 49 | Case Closure | For Army and supported IAs, notify the CCM within a configurable time period after the estimated case closure date is reached and the SSC date has not been posted. | |
| 50 | Case Closure | For Army and supported IAs, notify the CCM and Financial line manager at a configurable time period after the contract (ACRN, CLIN, SLIN, and ELIN) estimated completion date is reached and the associated Final Bill has not been received. | |
| 51 | Case Closure | Systemically update the estimated case closure date including FMSO I cases by adding the either 24 months for ACCP cases or 36 months for NON-ACCP cases to the SSC date. | |
| 52 | Case Closure | For Army and supported IAs, alert CCM, the Financial Manager, DFAS and DSCA Purchaser when IA has certified a case ready For closure. | |
| 53 | Case Closure | For Army and supported IAs, generate a Final Closure Certificate and have the ability to attach to the case master file. | |
| 54 | Case Closure | For Army and supported IAs, notify the CCM of DSCA decision to reopen an ACCP closed case and change the case status to implemented For approvals once the case is reopened in all applicable systems. | |
| 55 | Case Closure | For Army and supported IAs, systemically prevent the CCM from certifying a case For interim closure if the ULO balance exceeds the FMS Customer's ULO Closure Threshold. | |
| 56 | Case Closure | For Army and supported IAs, systemically record the latest estimated SSC date of all the lines on a case, as the Case estimated SSC date. | |
| 57 | Case Closure | Apply the 3 case closure PCs to systemically prioritize workload for the case and line managers. PC 1 identifies cases that are supply, service complete (SSC), which means all materiel has shipped and all services are completed for all lines on the case. PC 2 identifies case lines that are SSC for a Command. PC 3 identifies case lines that have some lines that are SSC and at least one line that is not SSC. | |
| 58 | Case Closure | For Army and supported IAs, systemically populate the applicable line/subline closure inhibitors when the line is systemically changed to SSC. | |
| 59 | Case Closure | For Army and supported IAs, provide the capability For the new system to systemically add a line and sublines to the case closure master with an Alpha Inhibitor Code (that identifies the month and year the line became SSC) when the line/subline is Supply Service Complete. | |
| 60 | Case Closure | For Army and supported IAs, systemically code SDAF lines with IHC "1D" and generate a SDAF line certificate to the CCM team. | |
| 61 | Case Closure | For Army and supported IAs, systemically remove an SSC date when a Service Completion date is changed to a future date in the Case Master Plan and systemically code the line For deletion and systemically adjust the internal workload priorities on case lines accordingly in the case closure master. |
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .