DOC LMS Technical Requirements_Draft.pdf

14.1 Technical Documentation

Office of Human Resources Management

Office of Learning and Development

Learning Management System Requirements

Updated: October 31, 2024.

Contents

Delivery Schedule

CORE SYSTEM Requirements (Platform)

1.0 System

2.0 Integration

3.0 Implementation

4.0 Documentation

5.0 Administration

6.0 Communication

7.0 Content

8.0 Reporting

9.0 Tracking

10.0 Website / End User View

11.0 Social

12.0 Talent / Knowledge Management

13.0 Coaching Platform as a Service (PaaS) Management

CORE SUPPORT Requirements

1.0 End-user eSkillz Help Desk Support Solutions

2.0 Dedicated Full-Time LMS Administrative Services

3.0 LMS Special Project Services

4.0 Skillsoft E-learning Library Curation Development Services

5.0 LMS User Experience (UX)/ User Interface (U/I) Customization Services

6.0 E-Learning Course Instructional Design and Development Services

7.0 Administrative Staff Training Services

8.0 EHRI LMS Data Feed Management Services

9.0 Information Security System Officer ISSO/FedRAMP Authority to Operate (ATO) Support Services

10. External Training and SF-182 EHRI Data Management

11.0 Training Evaluation Assessment and Consultation

12.0 Training Needs Analysis, Competency, 180-degree, and 360-degree Assessment Development Services

13.0 Reporting / Billing

Glossary

Delivery Schedule

Deliverable Description Quantity/Media Date

1 Kick-off meeting with LMS SaaS representatives.

1 June 1, 2024

2 Premium Support 24/7 resource accessible to DOC administrators

June 1, 2024

3 LMS SaaS Course Publisher

Licenses

10 June 1, 2024

4 LMS SaaS Client Success

Center Licenses

20 June 1, 2024

5 LMS SaaS Named Care

Licenses

8 June 1, 2024

6 Online Content Hosting – 80,000 end user licenses

80,000 June 1, 2024

7 Online content storage on LMS

SaaS servers

As applicable June 1, 2024

8 Catalog Synchronization Service Once a month or more Every month through May 31, 2029

9 Web Services Integration Support As applicable June 1, 2024

10 In-Bound Data Feed Once a month or more Every month through May 31, 2029

11 Tier (Level 1) Help-Desk Support Ongoing, as needed June 1, 2024

12 Tier (Level 2) Help-Desk Support Ongoing, as needed June 1, 2024

13 Tier (Level 3) Help-Desk Support Ongoing, as needed June 1, 2024

14 System Administrators Training Ongoing, as needed June 1, 2024

CORE SYSTEM Requirements (Platform)

The following terms are used in the requirements and carry specific meanings:

• MUST

• SHOULD

• WILL

• MAY

These terms are used to convey the relative importance of the requirements.

MUST: “MUST” identifies requirements that are vital for system functionality and services and “indicate an obligation to act” (FAR, Chapter 5). Non-support of the requirement will probably result in the dismissal of the proposal from the competition process.

SHOULD: “SHOULD” identifies requirements that are key for system functionality and services to provide in order for the DOC learning and development programs to be successful. “Should” indicates “an expected course of action” (FAR, Chapter 5). Non-support of the requirement will significantly decrease the likelihood of the vendor being selected.

WILL: “WILL” identifies requirements that are valued for system functionality and services to provide in order for the

DOC learning and development programs to be more efficient. “Will” indicates an anticipated action (FAR, Chapter 5).

Support of the requirement may increase the likelihood of the vendor being selected.

MAY: “MAY” identifies requirements that are convenient for system functionality and services to provide. “May” indicates a discretionary action (FAR, Chapter 5). Support of the requirement may be a deciding factor in the event two or more vendors are equal in other aspects of their proposal, vendor references, demonstration, and sandbox evaluation.

These keywords are used in the Requirement Description field.

Vendors are required to respond to the requirements with one of the following values:

• Fully

• Partially

• Customization

• Not at all

Fully: The vendor’s system completely meets the requirement as explained without customizations.

Partially: The vendor’s system meets some of the need of the requirement without customization.

Customization: The vendor’s system could meet the requirement but would require customizations. The vendor will be provided with space to provide a cost directly associated with customizing to meet the requirement.

Not at All: The vendor’s system does not provide functionality to support the requirement and cannot be customized to meet the requirement.

The vendor is to respond with one of the above values in the Vendor Response field.

In addition to the vendor’s response, the vendor should provide some description of how their product addresses the requirement. This information should be provided in the Vendor Comments field.

If there are specific costs above the base-line cost of the product for addressing the requirement, the cost should be noted in the Added Cost column.

The following actors are used within the requirements:

• End User/User

• Administrator

• Training Administrator

• System Administrator

End User/User: An employee that accesses the system for the purpose of managing their own training or the training of one of their subordinates.

Supervisor: An End User that has one or more employees reporting directly to them.

Manager: An End User that has one or more Supervisors reporting directly to them

Training Administrator: A Training Administrator accesses the system for the purpose of doing day-to-day operational work within the system such as configuring training.

System Administrator: A System Administrator accesses the system for the purpose of configuring the system in ways that have a global impact on all users or to system performance.

1.0 System

Req. ID Requirement Description

1.01.01 Products and software provided MUST comply with Section 508 of the Rehabilitation Act of 1998 and WCAG 2.0 (https://www.w3.org/TR/WCAG20/). Section 508 governs providing accessibility to people with disabilities. All Electronic and Information Technology (EIT), as defined at FAR 2.101, supplied under this contract, must conform to the Architectural and Transportation Barriers

Compliance Board Electronic and Information Technology Accessibility Standards (36 CFR Part

1194).

As part of the submission process, vendors MUST submit two Voluntary Product Accessibility

Template (VPAT) documents. One VPAT will be submitted for the end-user functions of the product.

The second VPAT will be submitted for Administrator functions of the product.

The VPAT explanation and form may be found at:

https://www.section508.gov/sell/acr-vpat-faq/

The Contractor shall also identify the technical standards applicable to all products proposed.

Additionally, the Contractor shall clearly indicate where this list with full details of compliance can be found (e.g., vendors or other exact web page location). The Contractor shall ensure that the list is easily accessible by typical users beginning at time of award. At time of award, the list provided by the Contractor shall be included as an attachment.

The Contractor shall ensure that all EIT products that are less than fully compliant are offered pursuant to extensive market research, which ensures that they are the most compliant products available to satisfy the solicitation’s requirements.

If any EIT product proposed is not fully compliant with all of the standards, the Contractor shall specify each specific standard that is not met; provide a detailed description as to how the EIT product does not comply with the identified standard(s); and shall also indicate the degree of compliance.

Full details demonstration compliance with Section 508 requirements shall be provided as a separate attachment to the technical proposal. This information will be made a part of any resulting award.

Additional information may be found at: http://www.section508.gov

1.01.01.01 Products and software provided WILL comply with WGAC 2.0.

1.02 The Products and services MUST successfully complete a Security Assessment and Authorization

A&A (formally known as Certification and Accreditation or C&A).

Successful Completion of the A&A will require FISMA compliance and FIPS 199, 200, and 140-2 compliance.

The following summarizes some of the expectations, but this is not inclusive:

• Servers located in a secure location.

• Nightly backups

• Backups stored at a location separate from the servers

The vendor should refer to https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-

53r5.pdf for

Internal site:

https://csrc.nist.gov/projects/risk-management/sp800-53-controls https://www.w3.org/TR/WCAG20/ https://www.section508.gov/sell/acr-vpat-faq/ http://www.section508.gov/ https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf https://csrc.nist.gov/projects/risk-management/sp800-53-controls

DOC OCIO is the primary manager for this requirement and the vendor should coordinate with their

OCIO contact.

1.02.01 The products and services WILL complete the FedRAMP process. More information can be found at:

https://www.cio.gov/policies-and-priorities/fedramp/

1.03.01 The system end user interface MUST be web-based.

1.03.02 The system administrator interface MUST be web-based.

1.03.03 The following web Browsers SHOULD be supported:

• Internet Explorer 7 to 11.

• Firefox 4 to 27.

• Safari on Mac 6 to 8.

• Chrome 23 to 33.

1.03.04 The vendor WILL support future versions of the following web browsers:

• Internet Explorer

• Firefox

• Safari on Mac

• Chrome

1.04 The system MUST allow for the creation of hierarchy of “nodes”.

See the Glossary of this document for the definition of “node”.

1.04.01 The nodes SHOULD be able to make the learning system available to subcomponents of the organization.

1.04.02 Nodes SHOULD be able to segregate users, content or both.

1.05 The system screens SHOULD be highly configurable by Department Learning Administrators via web interface without the assistance of the vendor.

1.05.01 The system screens WILL be individually configurable by node (see 1.04).

1.06 The system SHOULD be available 365 days, 24 hours per day.

1.06.01 The vendor MUST provide a copy of their service level agreement (SLA) as part of the response to this proposal.

1.07 The system SHOULD provide the ability to allow a new employee to self-register.

The system is to be used for on-board training for a new hire that has not officially started.

Once officially on board, their training records would be reconciled.

1.07.01 The system SHOULD allow for accounts to be reconciled between an account created through self-registration and data imported from the HR system.

1.07.02 The content available to the account created through self-registration SHOULD be restricted.

1.07.03 System features available to the account created through self-registration SHOULD be restricted.

1.07.04 The system SHOULD provide the ability to have an approval process for individuals requesting to self-register.

1.08 The system SHOULD provide the ability to customize the login page. Examples of customizations include adding technical support links and user help contact information.

1.08.01 The system configurable user interface sections (see 1.08) WILL support links that contain JavaScript.

1.09 The system vendor SHOULD provide the ability for DOC to export the entire database content

(complete data dump) into a text file or other agreed upon format.

Designated DOC administrators SHOULD be able to export the database at any time without limitations.

1.10 The vendor MUST provide a test site for DOC administrators.

https://www.cio.gov/policies-and-priorities/fedramp/

The test site is to be updated with new software releases at least 30 days prior to the releases being migrated to on the DOC production sites.

1.11 The vendor MAY provide end user technical support for 63,000 end users.

1.12 The vendor MAY allow the integration with 3rd party end user support.

1.13 The vendor MUST provide as part of their response a summary listing of technologies used to implement the system.

Examples technologies include: ASPX, J2EE, HTML, etc.

1.14 The vendor SHOULD have a process in place for customer feedback on vendor performance.

1.15 The system SHOULD support 1000 Simultaneous Users and 5000 Concurrent Users. See the Glossary section of this document for definitions of Concurrent and Simultaneous User.

It is recommended that the vendor include in the proposal response a system load report as evidence that the environment can support the specified number of users.

1.16 The vendor MUST explain their experience with Shared Service environments as part of their proposal response.

1.17 The system MUST comply with the Plain Writing Act of 2010.

https://www.plainlanguage.gov

1.18 The system WILL support providing training to external users.

1.18.01 The system WILL support ecommerce activities for external users.

1.18.02 The system WILL support self- registration for external users and flag the record as an external user record.

1.18.03 The system WILL provide a mechanism for limiting the system features available to an external user.

1.18.04 The system WILL provide a mechanism for limiting the content available to an external user.

1.19 The system MUST support the following environment: Microsoft

Thin Client Virtual Desktop in Azure

1.19.01 The vendor SHOULD provide a list of secure VPN solutions their product has been validated against.

1.20 The vendor SHOULD provide a strategy for addressing product licensing and support the cost for large fluctuations in the number of employees.

NOTE: Census’ employee population fluctuates from approximately 16,200 to 500,000. The fluctuation occurs over a period of ten years.

https://www.plainlanguage.gov/

2.0 Integration

2.01.01 User Accounts: Integration MUST automatically create user accounts the first time a user appears in the

“user data feed”.

2.01.01.01 The system MUST provide a mechanism for merging user accounts so that A DOC System

Administrator is able to correct situations where a DOC user may have a duplicate account.

2.01.02 User Accounts: Integration MUST deactivate a user account after a period of time to be defined by DOC when the user is no longer contained in the “user data feed”.

2.01.03 User attributes within the system MUST be updated through the user data feed.

2.01.04 Users MUST be given membership to a “Parent” system node and additional nodes that are under the parent node by the data feed.

Membership is determined by user attributes within the user data feed.

2.01.05 Nodes MUST be definable so that they reflect the organizational structure of DOC.

2.01.05.01 Nodes MUST allow a security domain to be defined for it so that administrative activities are isolated from siblings and child nodes. The parent node has access to administrator access to children nodes.

2.02 The automated user integration SHOULD assign users to groups based upon attributes in the “user data feed”.

2.02.01 Groups SHOULD be ad hoc definable.

Groups are used to simplify administrative activities such as training assignments based upon shared user attributes regardless of the nodal membership.

2.03 A user’s group membership SHOULD be updated through the “user data feed” as the user’s attributes change in the data feed.

2.04 The vendor MUST provide a process for migrating user training records from previous system.

The vendor MUST provide import templates that will allow existing data to be imported into their system. These import templates may be provided to DOC’s current vendor to support data migration.

DOC has roughly 10 years of data for roughly 50,000 employees.

2.04.01 The vendor MAY provide hands on data migration services including minor data cleansing.

The vendor can explain their history with data migration support in their response.

2.05 The system MUST store user attribute information such as name, employee number, supervisor, job role, email, organization code, supervisor, organization account code, employee ID (DOC Master ID) and other contact information.

2.05.01 Sensitive Personally Identifiable Information (SPII) MUST NOT be viewable through the user or administrative interfaces.

Examples of SPII include Social Security Number.

2.06 The system MUST provide a mechanism for importing personnel data from DOC’s HR system.

The awarded vendor will work with the Department of Treasury, our HRMS system provider, to create a bi-directional interface (via Web Services of daily file transfers through agreed upon secure architecture) to share all learning data (Completed, In Process, Scheduled or Pending Training History and all associated costs etc.) from the system. This data would interface directly with the HR system and with the reporting system to allow the system to be linked to the core HR data module.

In addition to the Treasury integration, there will be an additional user data feed from DOC for bureaus that are not currently supported by the Treasury system.

2.07 The system SHOULD integrate with DOC financial systems to obligate funds and capture revenues and costs.

This requirement includes adjusting values in the financial system based on the number of employees registered for ILT Training.

2.08 The system SHOULD provide a method for integration with commercial courses, eBook, and video libraries.

Integration includes the Enterprise Human Resources Integration (EHRI) required data fields provided by the commercial library vendor.

Ability to search through the 3rd party library titles and descriptions to find courses, eBooks, and Videos matching a given criterion.

2.08.01 The system SHOULD integrate with the course library.

See requirement 2.08.

2.08.02 The system SHOULD enable the integration with the commercial vendor to automatically update the items available.

2.09 The vendor MUST acknowledge

system data pertinent to DOC is “owned” by DOC.

2.09.01 The vendor MUST upon termination of agreement provide all data collected by the system to DOC in a common format with a comprehensive data definition document or other equivalent documentation.

2.10 When a new user account is created, a welcome email SHOULD be sent to the user.

2.10.1 The content of the welcome email SHOULD be configurable by each DOC bureau.

2.10.2 The system SHOULD allow a welcome email to be sent manually.

2.10.3 The system WILL generate a new welcome email when a deactivated user account is reactivated.

2.11 The system MUST support administrators by adding user training completed outside the system to the system.

Examples of external training data to be included are username, WBT or ILT name, start date, completion date, scores, and training hours.

This requirement addresses the needs of DOC user web-based and instructor-led training data import applications.

2.11.1 The system SHOULD support EHRI data capture as part of the external training data entered.

See the glossary of this document for additional information about EHRI.

2.11.2 The system MUST allow for a “batch” upload of user training records.

2.11.2.01 The “batch” upload of the external training data SHOULD include EHRI data.

3.0 Implementation

3.01 The vendor MUST provide a strategy and cost for training for training 100 DOC administrators located across the United States. The strategy should address sustainment training for DOC. This strategy is to be provided as part of the response to this proposal request.

3.01.01 The vendor SHOULD provide training for changes in future upgrades, and system enhancement releases.

3.01.02 The vendor MAY provide online courses to support administrator training.

3.01.03 The vendor WILL provide documentation on best practices for system implementation.

3.01.04 The vendor SHOULD provide training materials to support end user training for the system.

3.01.05 The vendor MAY provide webinar-based training for end users.

3.01.06 The vendor MUST schedule and provide monthly webinar-based training for administrators.

3.01.07 The vendor MUST provide initial hands-on virtual instructor led training for administrators.

3.01.08 The vendor MUST provide continuing hands-on virtual instructor led training for new administrator

3.01.09 The vendor MAY provide continuing online training for new administrator

3.02 The vendor WILL provide organizational change management support for the implementation.

3.03 The vendor MUST provide an Implementation Plan to support the implementation during the planning phase of the project.

3.04 The vendor MUST provide a Quality Assurance Plan to support the implementation during the planning phase of the project.

4.0 Documentation

4.01 The system MUST provide online documentation on all aspects of the system functionality.

4.01.01 The system SHOULD provide downloadable documentation on all aspects of the system functionality.

4.02 The system SHOULD provide an online help feature for administrators.

4.02.01 The system SHOULD provide an online help feature for end users.

5.0 Administration

5.01 System MUST provide for self-enroll for instructor led and online training.

5.01.01 The system MUST allow for a training activity to require supervisor approval of a training request.

User’s request would be automatically routed to the user's supervisor for approval. System would notify user of the action (approved or disapproved) taken by the user’s supervisor.

5.01.02 The system SHOULD allow multiple levels of approval beyond the supervisor.

5.01.03 The system SHOULD allow approval routing to be configurable by each node.

NOTE: Nodes will be configured based upon DOC’s hierarchical organization structure (e.g. local office, regional or national).

5.02 The system MUST provide a functional equivalent to the SF-182 form.

The SF-182 form is the government authorization for training request which is used for all training requests and approvals.

5.02.01 The system MUST support the SF-182 training form being completed by the user and then using a workflow be routed to one or more individuals (e.g. supervisor, training officers) for approval and the obligation of funds.

The approval process SHOULD support routing the SF-182 form based upon roles. For example, the fact that someone is a “Training Coordinator” vs. by name.

5.02.02 The system WILL automatically populate user data fields in the SF-182 form with values stored in the system from the “user data import”.

5.02.03 The number of levels in the system’s SF-182 routing process and the approvers within the process

SHOULD be configurable by Node to mirror OPM requirements.

5.03 The system WILL provide a master schedule that allows setting holidays and other non-training events for display system-wide or bureau-wide.

5.04 The system WILL provide a calendar view of course offerings formatted in a monthly view.

5.04.01 The system SHOULD provide an indication if a course is residence, web-based, or virtual.

5.04.02 The calendar view SHOULD indicate course availability.

5.04.03 The user WILL be able to register for a course by selecting the item from the calendar view.

5.05 The user WILL be able to view additional course information by selecting the item from the calendar view.

5.06 End users MAY have a calendar available showing training items they have registered to attend.

5.06.01 End users MAY be able to review additional details about a course by selecting the link for the course from the calendar.

5.06.02 The system WILL send a reminder notice to the end user for events they are scheduled to attend.

5.06.02.01 The reminder notice WILL be provided as a standard ICS file.

5.07 End users MUST have a view of the training that they have registered for.

NOTE: This view does not need to be in a calendar format (see requirement 5.06) This would be an alternate view.

5.07.01 End users SHOULD be able to access additional information by selecting the course link.

NOTE: This view does not need to be in a calendar format (see requirement 5.06) This would be an alternate view.

5.08 The system MUST allow restriction of course access regardless of the course type to a specific group of users.

5.09 The system MAY allow the restriction of access to web-based training based upon a specified time period.

5.10 The system MUST support scheduling of Instructor Led Training (classroom or virtual).

5.10.01 The system MUST support self-enrollment for Instructor Led Training (classroom or virtual)

5.10.01 The system SHOULD include at a minimum the following information: Name, Description, “Open” date/time, “Close” date/time, “Visible” date/time, time zone, post enrollment status, and options such as:

user approval, user drop enrollment, and a user wait list.

5.10.02 The system MUST support rescheduling instructor-led training events.

5.10.03 The system MUST support cancelling of instructor-led training events.

5.10.04 The system MAY support the ability to cancel a group of instructor-led training sessions for a given course in batch.

5.11 The system SHOULD support allowing web-based training to be made available based upon licensing

(seat) limits and/or user type (employee or contractor).

5.12 Administrators SHOULD be able to reserve facilities independent of training events.

5.13 The system SHOULD support administrators to associate facilities or equipment with training events

(e.g. schedule classrooms and equipment for ILT).

5.14 Schedules for facilities MUST be available for view by administrators and instructors.

5.15 Administrators MUST be able to create and modify facilities in the system (e.g. classrooms and related information).

5.16 The system SHOULD allow classroom capacity to be set at the course level for Instructor Led Training.

5.16.1 The system SHOULD allow classroom capacity to be set at the instructor-led training session level.

5.17 The system WILL allow administrators to manually modify course roster layout.

5.18 Administrators MUST be able to manually add or remove users from instructor-led training sessions.

5.19 The system SHOULD allow for tests for instructor-led training courses to be made available online.

5.19.01 The system SHOULD allow for surveys for instructor-led training courses to be made available online.

5.20 The system SHOULD support wait listing for instructor-led training courses.

5.21 The system MUST identify scheduling conflicts for physical resources (e.g. classrooms, equipment, instructors, etc.).

5.22 The system SHOULD support administrators assigning permissions to individual users or groups to control access to content at the course level.

5.23 The system SHOULD support the ability to configure views and data access by role, such as administrator, manager, instructor, course scheduler, registrar, distribution personnel, different user groups, etc.

5.24 The system SHOULD provide for individuals of various authorities to access certain data within the system

5.25 The system MUST provide configurable access/permission levels without system Vendor intervention.

5.26 The system SHOULD permit administrators to assign permissions to individual end users or groups to control access to run specific reports.

5.26.1 The system MUST permit administrators to assign permissions to administrator roles.

5.27 The system SHOULD permit Administrators to assign granular system privileges or defined roles to individual end users or groups.

5.27.1 The system MUST permit administrators to assign granular system privileges or defined roles to administrators.

5.28 The system MUST allow user enrollment status to be viewed and updated by the user, supervisor, or administrator or other individual with appropriate access level or permissions.

The user cannot be allowed to unregister for training that was assigned to them by a Training

Administrator.

5.29 The system SHOULD allow enrollment cancellation by the user to be configurable at the system, subsystem, or course level.

The user cannot be allowed to unregister for training that was assigned to them by a Training

Administrator.

5.30 The system SHOULD prevent users from registering for more than one session of a training event.

5.31 The system SHOULD allow session timeout period to be configurable by the system administrator.

5.32 The system MUST support User authentication via password.

The password MUST be compliant with DOC password rules in accordance with requirement 1.02

5.32.01 The vendor MUST provide a strategy for implementing and maintaining single sign on with DOC’s network as part of their response to this proposal. The DOC network environment is to be updated to require the use of PIV/CAC cards to log into the network. The response MUST include a budgetary cost estimate.

5.33 The system SHOULD provide a password reset feature for users who have forgotten their passwords that does not require intervention from an administrator or help desk support.

5.34 The system MUST allow end-users to change their passwords.

The vendor can provide recommendations on best practices for password management.

5.34.01 The system MUST allow administrators to change their passwords.

5.35 The system MUST allow the system administrators to define password complexity rules, and password expiration time period.

5.36 Managers MUST be able to view courses their subordinates are registered for.

5.36.1 Supervisors MUST be able to view courses their subordinates are registered for.

5.36.2 Managers SHOULD be able to view the attendance of their subordinates.

5.36.3 Supervisor SHOULD be able to view attendance of their subordinates.

5.37 Managers SHOULD be able to view non-sensitive information for their subordinates.

5.37.1 Supervisors SHOULD be able to view non sensitive information for their subordinates.

5.37.2 The data that is viewable by the supervisor and managers MAY be configurable by the system administrator. Data may include user attributes, course completion information, and scores.

5.38 Managers MUST be able to view the completion status of employee training.

5.38.1 Supervisors MUST be able to assess the completion status of employee training.

5.38.2 The system SHOULD be configurable so that Managers are NOT able to view training scores of employees

5.38.3 The system SHOULD be configurable so that select training administrator roles are able to view training scores of employees

5.39 The system SHOULD provide a Graphical User Interface (GUI) or template-based entry for course scheduling.

5.39.01 When a session is duplicated the notification message text for the session MAY also be duplicated.

5.39.02 The system SHOULD provide a means to easily duplicate an existing training session.

5.39.03 The system SHOULD provide for easy modification of existing training sessions.

5.40 The system SHOULD provide options for rescheduling registrants based upon course availability

5.41 The system SHOULD support the definition of ad hoc groups as well as hierarchical/ organizational groups.

5.42 The system WILL permit administrators or instructors to schedule one-on-one sessions.

5.43 The system MUST permit the setting of course enrollment cutoff times.

5.43.01 The system MAY permit the setting of course enrollment opening timeframes

5.44 The system WILL provide capability for instructor profiles including contact information, qualifications, accreditations, certifications, etc.

5.44.1 The system MAY provide links to instructor profiles from in course descriptions.

5.45 The system MUST provide a way for multiple sessions of the same course to be scheduled, and tracked, for the same day.

5.46 The system SHOULD support a 3rd party web conferencing tool integrating with the setup/creation of a virtual ILT (VILT) session.

The integration is defined as creating a VILT session in the system, where the session name, date(s) and time(s) are automatically communicated and set up in the 3rd party web conferencing tool. You only set up the session in the system and you don't have to manually setup the session in the web conferencing tool.

The web conferencing login and call information can be imported or inserted into the system enrollment communication messages.

The integration also includes the web conferencing tool sending attendance information back to the system, so the instructor does not have to take attendance.

5.46.1 VILT integration WILL support WebEx

5.46.2 VILT integration WILL support GoToMeeting

5.46.3 VILT integration WILL support GoToWebinar

5.46.4 VILT integration WILL support MS Teams

5.46.5 VILT integration WILL support Adobe Connect

5.46.6 VILT integration WILL support Google Meets

5.47 The system WILL support end-user requests for enrollment in an unscheduled session of an existing course.

These class session request forms can be used to assist in class session planning, and resource allocation.

5.48 The system SHOULD permit end users to update their user profile.

DOC will coordinate communicating with end-users which fields are controlled by the “user data feed”.

5.49 The system SHOULD provide for the implementation of subsets of functionality and components based on the user attributes.

5.50 The system SHOULD provide “Graphical User Interface (GUI)s” for completing multi-step/complex tasks such as adding an instructor-led or web-based training item.

5.51 The system WILL provide functionality for uploading/downloading audio/video podcasts.

5.52 The system MUST provide a mechanism for organizing courses by categories.

Categories: Hierarchical directory and sub directory file structure that can be created to be used as

“folders” for organizing a course catalog or mapping training content to a directory/ subdirectory.

5.53 The vendor SHOULD provide a streaming video server to host videos.

5.54 The system MAY allow a user to upload a photo or image as part of their user profile or properties page.

5.55 The system WILL allow administrators to activate and set up training ratings and review features for users to post ratings and comments on web-based and instructor led training.

The “star” rating and associated text would be configurable.

5.55.1 If 5.57 is supported, administrators MUST have the ability to remove inappropriate user comments.

5.56 The system SHOULD Include electronic signature capability.

End users can electronically sign they have taken training or read a document.

The vendor needs to explain their electronic signature process noting and standards that it is compliant.

6.0 Communication

6.01 The messaging system MUST send enrollment confirmation for courses at time of enrollment to users, supervisors, instructor, and administrator as configured.

6.02 The messaging system SHOULD include the ability to have email messages sent based upon configurable triggers (event specific) or periodic schedule.

Some examples include enrollment, drop, waitlist, minimum class size, schedule changes, etc.

6.03 The messaging system MUST include the ability to include plain text.

6.03.01 The messaging system SHOULD include the ability to include HTML messages.

6.04 The messaging system SHOULD have the ability to add recipients to messages, such as users, supervisor, or others.

6.05 Messages SHOULD allow for file attachments.

Attachments are typically used for related training materials.

The vendor needs to include information about file size limitations as part of their response.

6.06 Messages SHOULD be configurable to notify appropriate people of schedule changes.

6.07 Reminder messages SHOULD be sent as configured by triggers prior to or after a training event.

6.07.01 Reminder messages SHOULD be sent as configured by trigger based upon a calendar date.

6.08 Messages SHOULD be sent when changes to the waitlist status occur.

6.09 The system WILL suggest alternative dates for users attempting to register for training sessions that are full or in waitlist status.

6.09.01 The system WILL suggest alternative courses for users attempting to register for courses that are full.

6.10 The system WILL notify users and supervisors of accreditation and certification timing requirements

6.11 The system SHOULD allow administrators to suppress notifications to an identified list of users.

6.11.01 The system SHOULD permit notification process to be suppressed/ inactivated by course

6.12 The system WILL provide e-mail notifications of completion results to users.

6.13 The system SHOULD permit global broadcast messaging.

Permission to send the broadcast message would need to be restricted by system permissions.

6.14 Notifications MUST be available to the user via message within the system and to an official email address.

6.15 The system MAY provide RSS syndication to communicate with subscribers.

Includes the ability to enable RSS for individual components such as course catalog updates, news and announcements, etc.

6.16 The system SHOULD provide the ability to email course certificates to participants who have completed courses and to the supervisor or designated person.

6.17 The system MAY notify users of a more advanced class addressing a subject of a class they completed.

7.0 Content

7.01 The system SHOULD provide the ability to display training as being “New”, or “Updated”.

7.01.01 The system WILL allow an expiration date to be set per training item to determine how long the indicator

(requirement 7.01) will be displayed to users.

7.02 The system MUST allow web-based training and instructor-led training completion criteria to be set by administrator or instructor (tests, surveys, attendance, and prerequisites).

Administrators can make the awarding course completion certificates contingent upon successful completion of the training or other criteria such as a user getting the right score to pass the course.

7.03 The system SHOULD allow allocation of seats (slotting) for instructor-led courses.

7.04 End users on an instructor-leading training wait list SHOULD be automatically enrolled and notified if space becomes available in the session.

7.04.01 Configuration of if automatic enrollment from waitlist MAY be set by training session.

7.04.02 If the enrollment cut off deadline has passed, the system SHOULD NOT automatically enroll individuals into the session.

7.05 An instructor-led training waitlist MUST be updated upon receipt of a user withdrawing from a session.

The next user (in-line) on the wait list is moved from the wait list to the session.

7.05.01 The option to notify all users on the wait list and enroll the first user who is approved for the training WILL be provided by the system.

7.06 The system MUST allow administrators with appropriate permissions to override reservations, waitlists, and withdrawal policies.

7.07 The system SHOULD allow administrators to waive pre-requisite or other required training for an individual or group

7.08 The system MUST allow courses to have any number of prerequisites defined.

Prerequisites may be any other type of training item.

Enrollment is prevented if prerequisites are not completed.

7.09 The system SHOULD allow surveys to be a prerequisite to a course.

The prerequisite is met if the survey is fully completed.

7.10 The system SHOULD allow defining different prerequisites for different user groups.

7.11 The system SHOULD allow course evaluation entry for ILT courses with user anonymity preserved

7.12 The system SHOULD support course equivalencies providing end users with choices for alternate learning content.

7.13 The system SHOULD facilitate collaborative distributed development of training materials and courses

7.14 The system SHOULD allow a single course catalog to provide access to all training tracked by system regardless of delivery method whether residence, remote, online synchronous or online asynchronous.

7.15 The system SHOULD allow self-service withdrawal.

Allow users to withdraw from registered courses.

This should be a configurable item per course.

7.16 The system MUST support access, launch and tracking progress of AICC courses.

7.16.01 The system MUST support access, launch and tracking progress of SCORM 1.2, courses.

7.16.02 The system MUST support access, launch and tracking progress of SCORM 2004 courses.

7.16.03 The system SHOULD support access, launch and tracking progress of Experience API (Tin-Can) standards courses.

7.16.04 The vendor MUST describe how they support cross-domain launches for SCORM based courses.

7.17 The system MUST allow accessing and launching of content that is not standards-compliant (not AICC or

SCORM).

Target content may include PowerPoint, Word, PDF, etc.

7.17.01 The system MUST allow marking the content complete based upon the end user confirming that they have read the materials.

7.18 The system SHOULD include robust course lifecycle management tools for content development, including the ability to deactivate, archive and re-activate courses without removing them from the system library.

7.19 The system MUST permit administrators to establish courses as mandatory or elective

7.20 The system SHOULD provide the ability to create web-based tests.

7.20.01 The system SHOULD provide the ability to create paper-based tests for use in ILT.

7.21 The system WILL provide customizable formatting capabilities (e.g. alphanumeric numbering) for setting naming conventions for courses.

7.22 The system WILL allow for content under development for multiple versions of the coursework at the same time

This is for the purpose of testing.

7.23 The system SHOULD allow a survey to be a standalone item without other content.

7.23.01 The system SHOULD allow a test to be a standalone item without other content.

7.24 The system SHOULD permit an administrator to configure prohibition of a user to print tests.

7.25 The system SHOULD facilitate the maintenance of course title, description, objectives, outlines, eligibility, abstracts, and other course information

7.26 The system WILL deliver pre-course assessments to identify appropriate course levels and learning plans.

7.27 The system WILL allow users to create study aids for self-paced courses.

7.28 The system SHOULD provide the ability to download courses for offline use, and report progress to the system.

7.29 The system SHOULD allow the creation and the editing of custom tests.

7.29.01 The system SHOULD allow the creation and the editing of custom surveys.

7.30 System testing engine SHOULD support configurable feedback on a per test basis.

7.31 The system WILL permit users to take practice tests before taking final test.

7.31.01 The system MAY permit users to complete course-related exercises before taking final tests.

7.32 The system SHOULD permit an administrator to set a time limit for completing the test.

7.33 The system SHOULD permit an administrator to deactivate, archive and re-activate tests.

7.34.01 The system SHOULD support managing multiple versions of practice tests and final tests.

7.35 The system SHOULD guide users to courses based on results of pre-assessments “Testing Out”.

Prescriptive testing.

7.36 Tests SHOULD be capable of multiple-choice single select, multiple choice multiple select, true/false, fill-in-the-blank, matching, or short answer (essay) questions.

Question types would be gradable and reportable.

7.37 The system SHOULD have the ability to randomize assessment questions (stems and detractors).

7.38 Online test SHOULD allow for “question pools” with selection of a randomized set of questions.

7.39 The system SHOULD allow the number of test attempts to be configurable.

In such cases, test scores from all retakes are available and reportable.

7.40 The system SHOULD allow individual test questions to be weighed differently.

7.41 The system MAY allow assessments (tests) to be configured so that they can be performed before, during, and after course participation as an option.

7.42 Test results SHOULD be able to trigger feedback with “pointers” to remedial materials or otherwise highlight areas that need improvement.

7.43 The system MAY allow the start and end dates/times to be defined for test availability.

7.44 The system SHOULD allow pre-tests to be designated as satisfaction of course requirements (“Testing

Out”).

7.45 The system MAY provide dynamic testing.

Provides adaptive/ conditional branching based on how questions are answered

7.46 The system SHOULD allow course evaluations to be required for completion of a course.

7.47 The system SHOULD provide web services that allow bi-directional integration with other learning management-type systems.

Use web services to integrate third-party courses into the system. The third-party courses are hosted on the provider’s servers and using web services are integrated into the system. This way the latest course version and course player would always be available if the content is hosted on the provider’s site. The system needs to be able to integrate the provider’s course catalog into the system. (Note: need the ability to add

EHRI data).

7.48 The system MAY contain authoring tools to develop interactive SCORM compliant web-based courses.

7.48.01 The authoring tool MUST be able to create section 508 compliant courseware.

7.48.02 The authoring tool SHOULD provide templates or Graphical User Interface (GUI)s to create different types of user interactions within the course content.

7.48.03 The system MAY contain authoring tools to develop interactive AICC compliant web-based courses.

7.49 The authoring tool SHOULD have the ability to support multiple file types in web-based training courses such as

Audio: MP3, WMA

Video: MP4, WMV, OGG

Image: JPG, GIF, PNG

7.50 The vendor MUST provide the ability to upload and host current repository of and future DOC created e-learning and supplemental content.

7.51 The vendor SHOULD provide publishing guidelines for the following products:

• Articulate Presenter

• Articulate Storyline

• Camtasia

• Captivate

• Lectora

• Vyond

8.0 Reporting

8.01 The system SHOULD permit administrators to view listings of all courses within system

8.01.01 The system SHOULD permit administrators to view listings of all ILT sessions within the system including past, present and future offerings as well as rosters.

8.01.02 The system WILL permit supervisors to view listings of all courses within system

8.02 Evaluation interactions SHOULD be stored in database and SHOULD be reviewable, downloadable and analyzable online.

8.02.01 Test result interactions SHOULD be stored in database and SHOULD be reviewable, downloadable, and analyzable online.

8.03 Reports MUST be exportable for supplemental analysis and reporting.

Data must be transferred under SSL/TLS.

The system can provide two versions of reports, one for HTML/PDF view and another appropriate for

Excel.

8.04 All reports MUST be viewable in the web browser under SSL/TLS.

8.05 The system MUST have an audit trail linking the users and administrators to key transactions updating the database.

8.05.01 The system SHOULD provide a report for analysis of administrative actions in the system.

8.06 The system MUST Include pre-built standard reports for common reporting needs.

Examples include reports for individual and group results, scoring patterns, etc.

8.06.01 The vendor MUST provide a listing and short description of the reports available in the system as part of their response to this proposal request.

8.07 Reports MUST include the ability to filter attributes such as completion date range, user organization, user position information, user location, etc.

8.08 The system MUST permit report data to be exported to CSV

8.08.01 The system MUST permit report data to be exported to Excel

8.08.02 The system WILL permit report data to be exported to MS Word

8.08.03 The system WILL permit report data to be exported to Access

8.08.04 The system MUST permit report data to be exported to PDF

8.08.05 The system SHOULD permit report data to be exported to Google Docs Document

8.08.06 The system SHOULD permit report data to be exported to Google Docs Spreadsheet

8.09 The system MUST allow for in-house development of customized reports.

These reports can be shared with any users.

8.10.01 Customized reports SHOULD be shareable between administrators.

8.10.02 Customized reports SHOULD be shareable with end users.

8.11 The system SHOULD provide reports on pre- and post-assessments

8.12 The system SHOULD track self-study training by time, participation, and completion).

8.13 The interface to run a report MUST NOT require coding or scripting skills.

8.14 The system MUST monitor, track, and report on individual user progress and deadlines

8.15 The system WILL perform, facilitate, and report on test validation, including item validation, based on statistical models.

8.16 The system SHOULD report on assessment results.

8.17 The system MUST provide the ability to restrict reports available to end users based upon user permissions.

8.17.01 The system MUST provide the ability to restrict data available in reports to end users based upon user permissions.

8.18 The system MUST allow administrators to review answers to short answer and essay questions.

8.19 The system MAY provide an easy to use “single button” report or dashboard for Supervisors showing training completions and training in progress (incomplete) for their subordinates (individuals in their line of supervision to any level).

8.20 The system MUST generate monthly EHRI reports

8.20.01 The system MUST be able to send the required monthly EHRI reports to OPM.

It is recommended that the vendor provides a listing of customers they currently provide EHRI data for.

NOTE: This must be submitted in the required OPM format using the security protocols as defined by

OPM. The system must allow constraints to be placed on data entry to limit the administrator/participant from entering incorrect data. If this cannot be done, then the system must send EHRI error report prior to data being submitted to OPM.

8.21 The system SHOULD support developing and provide access develop reports compatible with Microsoft

365 and Google suite business tools.

8.22 The vendor MUST provide in their response with a description of how custom reports are developed for their system.

8.23 The system SHOULD provide a report that calculates the number of training completions by Online, Instructor-Led, Job Series (job position), and grade (position level).

8.24 The vendor SHOULD provide a list of System Administration and Usage reports they will provide to DOC on a recurring basis (monthly/ quarterly/ annual). Examples but not all inclusive: number of site licenses consumed, number of page hits per hour for the previous month, peak use days and times, technical support provided i.e.