MONRS_Tech_Vision_and_Funct_Reqts.pdf
PDF 122 KB Posted
- Attached to
- Calibration and Metrology Services Federal contract opportunity
- Solicitation number
- 80JSC020CAMSIV
View the file
Other files for this federal contract opportunity
Show all 34
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
Metrology OOT Notification and Reporting System Technical Vision & Functional Requirements
1. Introduction The Metrology Out-of-Tolerance (OOT) Notification and Reporting System (MONRS) will be a two-part system; the MONRS Data Store (or MONRS-DS) which will provide the primary notification and records functionality, and the MONRS Data Interface (or MONRS-DI) which will provide the data interface between the Metrology Information Management System (MIMS) and MONRS-DS.
MONRS-DI will be a small, standalone middleware application that provides an on-demand, synchronous and unidirectional mechanism for pulling OOT data from MIMS and providing it to MONRS-DS. As such MONRS-DI will have a direct interface to both MIMS and MONRS-DS.
MONRS-DS will provide an automated means by which Measurement and Test Equipment (MTE) owners are notified in the event a specific piece of MTE is found to be out-of-tolerance by the JSC Measurement Standards and Calibration Laboratory (MSCL). Secondly, it will provide a mechanism by which MTE owners record the evaluation of the out-of-tolerance MTE. Thirdly, it will maintain a historical record of out-of-tolerance MTE and corresponding evaluations, including the ability to perform record lookup and reporting.
2. Positioning
2.1 Problem Statement
The problem of a manual notification, evaluation, and record-keeping process for out-of-tolerance MTE affects MTE owners and MSCL staff the impact of which is Inefficient, paper-intensive processes susceptible to error and misplacement of records a successful solution would be
A system in which: 1) out-of-tolerance data is retrieved directly from MIMS, 2) notification of out-of-tolerance MTE occurs automatically, 3) evaluation is recorded through a electronic-form-type interface, and 4) historical records are immediately accessible from an authoritative source for the purposes of business intelligence, audits, etc.
2.2 Product Position Statement
For MTE owners and MSCL staff
That Presently must manually process notifications and evaluations and maintain paper records for out-of-tolerance
MTE
The MONRS is an automated notification, evaluation, and record-keeping system for out-of-tolerance MTE
That Will eliminate the manual process and paper record keeping related to the notification and evaluation of out-of-tolerance
MTE
Unlike The current manual process
Our product Automates the notification and evaluation process for out-of-tolerance MTE and establishes an electronic, authoritative repository for out-of-tolerance MTE-related data.
3. Stakeholders Name Description Responsibilities
MSCL Responsible for detecting out-of-tolerance MTE.
Generates the out-of-tolerance MTE data that is used as input to the
MONRS.
MTE Owner Responsible for the evaluation of MTE determined to be out-of-tolerance.
Receives notifications from MONRS concerning out-of-tolerance MTE for which he or she is responsible (as determined by MONRS). Logs disposition of out-of-tolerance MTE in MONRS.
Office of Primary Responsibility (OPR) for Calibration and Metrology
Responsible for ensuring a historical record of all processed out-of-tolerance MTE and corresponding evaluations is maintained for reporting and auditing.
Owns the MONRS requirements.
4. Environment
4.1 User Environment
User environment is considered to be a typical NASA office environment, which is a mix of Windows, OS X and Linux operating systems utilizing the agency-standard web browsers. User interaction with the system will be strictly through a web-based interface. Internal access to the system will be limited to intra-agency networks; remote access will be limited to agency-approved remote networking solutions (currently VPN and R2S). No mobile accessibility is required at this time.
4.2 System Environment
The MONRS system environment will be the Directorate’s Engineering High-Availability Web Architecture (EHWA), a high-performance, fault-tolerant web platform for serving Microsoft SharePoint and custom-developed web applications. This same environment hosts the MIMS in which the OOT data originates. All applicable EHWA platform and development standards will be followed.
5. Features Description Includes Excludes
[MONRS-DI]: Provides data interface abstraction between MONRS-DS and
MIMS
Interface to and unidirectional communication with MIMS.
Interface to and bidirectional communication with MONRS- DS. Simple error detection.
Advanced error correction.
[MONRS-DS]: Provides manual entry of OOT details for a single piece of MTE and calibration instance.
Interface that allows manual upload of OOT details and supporting documentation into the system for notification and reporting purposes.
Detection of a conflict between a manually entered OOT instance and an automatically imported OOT instance from
MIMS.
[MONRS-DS]: Notifies MTE owners of newly-identified
OOT MTE
Automated mechanism for notifying MTE owners of OOT MTE based on externally-provided OOT data.
Mechanism for maintaining MTE owner table.
[MONRS-DS]: Records evaluation of OOT MTE as provided by MTE owner
Form-based input to collect the evaluation data pertaining to OOT MTE; identified by JPR
1281.11 to be: 1) identification of measurements made by the OOT MTE asset, 2) assessment of the impact of the OOT condition, 3) disposition of OOT MTE asset, and 4) closure.
MTE within scope of JWI
8730.4 (e.g. Flight hardware).
[MONRS-DS]: Provides OOT MTE evaluation reporting
User interface for searching and filtering all active or archived evaluations.
Anything beyond the out-of-box reporting facilities of SharePoint 2010.
6. Requirements
6.1 MONRS-DI Requirements
ID Requirement
6.1.1 MONRS-DI will extract data from MIMS’s data system on an on-demand basis.
6.1.2 The extracted data from MIMS will be sufficient to: 1) provide enough information to the MTE owner such that he or she can perform an adequate evaluation of the impact (including calibration data), and 2) uniquely identify each out-of-tolerance instance within MONRS-DS.
6.1.3 MONRS-DI will provide data extracted from MIMS to MONRS-DS on an on-demand basis.
6.1.4 MONRS-DI will be capable of detecting and logging failures to successfully export OOT data to MONRS-DS.
6.2 MONRS-DS Requirements
ID Requirement
6.2.1 MONRS-DS will notify MTE owners of any new OOT MTE as identified by the data import from MONRS-DI.
6.2.2 MONRS-DS will use NDC domain authentication to control application access.
6.2.3 MONRS-DS will use role-based access control (authorization) to limit record-change authority to MTE owner.
ID Requirement
6.2.4 MONRS-DS will collect the same input from MTE owners evaluating a piece of OOT
MTE that is currently collected on the JSC Form 190, including any file attachments provided by MTE owners as needed to support the evaluation.
6.2.5 MONRS-DS will provide long-term storage for the OOT data extracted from MIMS and the associated evaluation data provided by the MTE owner.
6.2.6 MONRS-DS will provide the ability to search for records by MTE asset calibration tag, MTE asset inventory tag, status, days open, organization or any combination thereof.
6.2.7 MONRS-DS will be a web-based application.
7. Signatures
[Author] [Signature] [Date]
[Requirements Owner] [Signature] [Date]
[EA2 Manager] [Signature] [Date]
| 1. Introduction |
| 2. Positioning |
| 2.1 Problem Statement |
| 2.2 Product Position Statement |
| 3. Stakeholders |
| 4. Environment |
| 4.1 User Environment |
| 4.2 System Environment |
| 5. Features |
| 6. Requirements |
| 6.1 MONRS-DI Requirements |
| 6.2 MONRS-DS Requirements |
7. Signatures
File details come from the government source that posted it. Updated .