June 8, 1999

1. The Consolidated Database must be
1. Timely: varies with data, i.e. data required on a monthly, daily, hourly or as needed basis
2. Accurate: default values, data validity checks, range checks, etc.
3. Automated: minimum of data entry, table look-up updates, select choices, ease of retrieval and update processing

2. System must interface with all existing and to be developed MSRC/DC databases
3. Field Names should be consistent with HPCMO policies
4. Database must be fully Relational
5. Front-end report software must be easy to learn and executable
6. Retrieval should be via the Internet; download capability
7. Availability of the following types of information:
1. Project Information
2. User/Person Information
3. Resource Allocation Data
4. Resource Utilization Data

1. contain user/project information
2. contain the associated allocation and foreground and background utilization.
3. loaded with each site’s (MSRC/DC) utilization information, once weekly.
4. Provide current cumulative foreground and background utilization in a flat file format, once weekly.
5. Loaded with each site’s user/project and allocation information when each site provides the data.
6. Provide changes to allocation data (keeping historical track of all changes) in a flat file format, when allocation has been added or updated in the database.
7. Provide current user/project information in a flat file format, when user/project information has been added or updated in the database.
8. provide an interface to allow editing for an allocation change or user/project information change.
9. When user/project information additions or changes are made in the CDB, notification of this change must be given to the other sites immediately.
10. When allocation changes are made in the CDB, notification of this change must be given to the other sites immediately in a manner that will allow for automatic updating of the database.
11. The CDB shall not allow activation of new users until all sites have completed providing user information.
12. The CDB shall maintain user/project, allocation, and utilization data for the current Fiscal Year to date.
13. The CDB shall maintain Quarterly Summary level user/project, allocation, and utilization data for all past Fiscal Year.
14. The CDB shall maintain Yearly Summary level user/project, allocation, and utilization data for all past Fiscal Years prior to the past Fiscal Year.
15. The CDB shall archive user/project, allocation, and utilization data by Fiscal Year. This data would then only be retrievable by doing an ad hoc query.

1. The CDB shall have "Internet" access to the CDB "web site" to either retrieve data online or to download a snapshot of data for analysis using the "Pivot" form capability.
2. The CDB shall interface with the current standard software (i.e. currently Microsoft COTS) that the government is using at the time of development and use of the CDB.
3. The CDB shall support database connection functionality from another Oracle or Microsoft Access System(s). This also includes the different version levels of the both Oracle and Microsoft software.
4. The CDB database connection functionality shall allow for reading and writing data depending upon the security restrictions applied.
5. The CDB shall employ proper access controls, which prevent unauthorized access to data in the database via the database connection. Each CDB user must be given access control based upon their need to know.
6. The CDB shall provide output in a flat file format, which contains the user/project, utilization, and allocation data. "Pass Through" queries at various levels of summary detail will be required.
7. The CDB shall be able to read a flat format, which contains the user/project, utilization, and allocation data and populate the database accordingly.

1. Data in the CDB shall be available 7 days a week, 24 hours a day, except for scheduled maintenance periods.
2. Full backups of the CDB shall be performed once a week and incremental backups will be performed daily.

1. General Requirements by PI’s and/or S/AAA’s
1. Generate account applications for new FY renewals
2. Establish process to include new projects/PI’s.
3. Procedures for moving allocations among projects.
4. Process to clean out old accounts/projects
5. Generate usage reports
6. Manage allocations between PI’s and S/AAA’s
7. Ensure extent of user’s valid access
8. Establishing Accounts
9. Keep record of all Transaction (history) processing
2. Allocation of resources HPCMO
1. by SERVICE
2. by MSRC/DC
3. by MACHINE
3. S-AAA allocation and/or re-allocation capability within
1. SITE
2. PROJECT (4 character)
3. Sub-Project
4. Other MSRC’s/DC’s Unique levels of Allocation as required
4. Report requirements (Allocation summary using the Pivot Table Form in Microsoft Access providing spreadsheet data with pre-determined graphics and ad hoc capabilities)
• SERVICE
• MSRC/DC
• SITE
• S-AAA
• PROJECT
• MACHINE
• REPORT PERIOD (Run Date, Monthly, Quarter, Fiscal Year)
• TYPE PROJECT (Challenge, Support, Regular, Admin, etc)
• CTA
5. Metrics requirements (Per the Metrics requirements document as submitted earlier in draft form to HPCMO for review).

a. Summary report requirements across HPCMO

1. Utilization summary and/or Utilization summary of Hours
2. Report requirements; Allocation summary (Pivot Table Capability using Microsoft Access Form capability as the front end/providing (spreadsheet data with graphics capabilities)

• SERVICE
• MSRC/DC
• SITE
• S-AAA
• PROJECT
• USER
• MACHINE
• REPORT PERIOD (Run Date, Monthly, Quarter, Fiscal Year)
• TYPE PROJECT (Challenge, Support, Regular, etc.)
• CTA

• PI/PL Name and associated information (see "Person" information below)
• Title
• Organization
• Project Number
• Sub-project Number
• Resources with valid allocations
• CTA
• S/AAA (see "Person" information below)
• Requirements
• Co-Investigators working on project (see "Person" information below)
• Special software requested
• Requirements data

• User Name
• User Title
• Citizenship
• Alien registration number/expiration date if not US citizen
• Organization
• Organization hierarchy indicator
• Mailing address (five lines maximum)
• Phone
• Fax
• Email
• Government/non-government
• Government POC plus POC information if not Government
• Contract number/expiration date if not Government
• NAC information
• Relevant Issuing Security Office
• Date issued/expired
• Kerberos Principal
• Last 4 digits of SSAN (optional)
• S/AAA
• Centers/systems on which user has valid has access
• User Names at the above Centers
• Signed Section 3 on file? Where? Dated?
• Latest FY for which paperwork complete

• Challenge allocation/utilization by center/system
• Service/Agency level allocation/utilization by center/system
• Allocation request per sub-project by center/system
• Allocation awarded per sub-project by center/system
• Utilization per user per sub-project per center/system (daily values)

• Debits/Credits
• Date of Transaction
• Organization(s) involved
• Appropriate Occurrences(s)

1. MSRC/DC Allocation Utilization
2. SERVICE Allocation Utilization
3. SITE Allocation Utilization
1. PROJECT (4) Allocation Utilization
2. Sub-Project Utilization
3. MACHINE Allocation Utilization
4. USER Utilization
5. CPU Hours Utilization
6. TYPE PROJECT Allocation Utilization
7. CTA Allocation Utilization
8. REPORT PERIOD Allocation Utilization