PWS Attachment 1 - StRS - RVTM - HH 2.0 Contractor Response Sheet.xlsx

XLSX spreadsheet 41 KB Posted Mar 30, 2022

Attached to: History Hub - External Support Community System
Solicitation number: 88310322Q00053
Issued by: National Archives and Records Administration

About this file

Written by GovTribe AI · Dec 28, 2023

This document contains a Request for Quotation (RFQ) for a Software as a Service (SaaS) solution to support the National Archives and Records Administration's (NARA) customer support community, History Hub. The RFQ seeks quotations to provide an out-of-the-box SaaS with capabilities outlined in the attached Performance Work Statement, such as user and content management, search, notifications, and reporting. The period of performance consists of a base year and four option years. Quotations are due by April 27, 2022 and will be evaluated based on factors in the attached evaluation document. The award will be made to the offeror whose quotation is most advantageous to the government considering price and other factors. The successful contractor must comply with representations, certifications, and clauses in the RFQ attachments, including Section 508 accessibility and NARA security requirements.

View the file

Other files

File	Type	Posted
88310322Q00053 Amendment 002 Questions and Answers_FINAL.docx	DOCX document	Apr 15, 2022
Appendix 1 - NARA 805-h1.pdf	PDF	Mar 30, 2022
Appendix 5 - Test_Plan_Template_v2.1.docx	DOCX document	Mar 30, 2022
Appendix 6 - Test_Procedures_Template.xlsx	XLSX spreadsheet	Mar 30, 2022
88310322Q00053 HH Platform Solicitation Attachments 1-13.docx	DOCX document	Mar 30, 2022
Appendix 4 - HistoryHub_RVTM_v.2.0.xlsx	XLSX spreadsheet	Mar 30, 2022
Appendix 2 - NARA_IT_Security_Requirements v7.1.pdf	PDF	Mar 30, 2022
Appendix 3 - HistoryHub_StRS_v.2.0.docx	DOCX document	Mar 30, 2022
Appendix 7 - Test_Report_Template.docx	DOCX document	Mar 30, 2022
Appendix 11 Section 508 ICT Requirements.docx	DOCX document	Mar 30, 2022
Appendix 10 - Cloud_CMDB_Template.xlsx	XLSX spreadsheet	Mar 30, 2022

Show all 11

On GovTribe

Work with this file

Download the original file
Contacts named in this file
Similar government files
Ask GovTribe AI about this file

Try for free Login

Text version

The file's text, extracted by GovTribe without its formatting.

Requirements

REQUIREMENTS

MISC

DESIGN

DEVELOPMENT

VERIFICATION

DEPLOYMENT PREPARATION

VENDOR'S RESPONSE

VENDOR'S TIME TO IMPLEMENT

VENDOR'S NOTES

Req #

Requirement Text

Type

Category

Sub-Category

Feature

Req Priority

Status

Target Release

Notes

Element

Iteration

Verification Method

Verification Test Case / Step

Verification Status

Verification Criteria

UAT Test Case

UAT Status

Validation Criteria

0-4

Ready at Award through +90 Days

(May be Used for Brief explanations, where applicable)

1.0

The system shall support role-based access and account management.

Stakeholder

Functional

Account Management

Must

Approved

User roles and permissions are defined in the Stakeholder Requirements Specification (StRS).

1.1

The system shall provide the capability for an Application Administrator to create and maintain user accounts within History Hub.

Stakeholder

Functional

Account Management

Must

Approved

1.2

The system shall provide the capability for an Application Administrator to conduct tasks requiring administrative rights within History Hub.

Stakeholder

Functional

Account Management

Must

Approved

1.3

The system shall provide the capability for a user to register for an account within History Hub.

Stakeholder

Functional

Account Management

Must

Approved

1.3.1

When a user requests a new account, the system shall generate a notification to verify the email address of the user.

Stakeholder

Functional

Account Management

Must

Approved

If the email verification message is not acted upon within the specified window of time, the new account request times out and the user needs to start over.

1.3.2

The system shall enforce password rules for user profiles.

Stakeholder

Functional

Account Management

Must

Approved

1.3.3

The system shall provide the capability for a registered user to manage their password.

Stakeholder

Functional

Account Management

Must

Approved

1.3.3.1

The system shall provide the capability for a registered user to change their own password when already logged in to History Hub.

Stakeholder

Functional

Account Management

Must

Approved

1.3.3.2

The system shall provide an automated method for resetting a registered user password when the user is not logged in to History Hub.

Stakeholder

Functional

Account Management

Must

Approved

1.3.4

The system shall provide the capability for a registered user to submit a request to obtain their username.

Stakeholder

Functional

Account Management

Must

Approved

1.3.5

The system shall support the use of authenticating users via any federated identity systems such as login.gov.

Stakeholder

Functional

Account Management

Must

Approved

2.0

The system shall provide the capability to manage announcements within the system.

Stakeholder

Functional

Announcements

Must

Approved

2.1

The system shall provide the capability for an authorized user to create announcements.

Stakeholder

Functional

Announcements

Must

Approved

2.2

The system shall provide the capability for an authorized user to post announcements.

Stakeholder

Functional

Announcements

Must

Approved

2.3

The system shall provide the capability to display announcements across the system.

Stakeholder

Functional

Announcements

Must

Approved

2.4

The system shall provide the capability to display announcements within a community in History Hub.

Stakeholder

Functional

Announcements

Must

Approved

3.0

The system shall provide the capability to manage artifacts and attachments within the system.

Stakeholder

Functional

Attachments

Must

Approved

3.1

The system shall provide the capability for authorized registered users to upload artifacts within History Hub.

Stakeholder

Functional

Attachments

Must

Approved

Only NARA approved staff members have the capability to upload attachments.

At a minimum, the following formats need to be supported for uploaded attachments: Microsoft Word (.doc/.docx), Microsoft Excel (.xls, .xslx), Microsoft PowerPoint (.ppt/.pptx), .pdf, .jpg, .tif, and .gif.

3.2	The system shall provide the capability for all users to download artifacts within History Hub.	Stakeholder	Functional	NA	Attachments	Must	Approved
3.3	The system shall provide the capability for an Application Administrator to specify the file size limitation for uploaded attachments within History Hub.	Stakeholder	Functional	NA	Attachments	Should	Approved
4.0	The system shall provide the capability to manage communities within the system.	Stakeholder	Functional	NA	Communities	Must	Approved	Communities consist of spaces, projects, and groups.
4.1	The system shall provide the capability for an Application Administrator to manage communities within History Hub.	Stakeholder	Functional	NA	Communities	Must	Approved
4.1.1	The system shall provide the capability for an Application Administrator to create communities within History Hub.	Stakeholder	Functional	NA	Communities	Must	Approved
4.1.2	The system shall provide the capability for an Application Administrator to update communities within History Hub.	Stakeholder	Functional	NA	Communities	Must	Approved
4.1.3	The system shall provide the capability for an Application Administrator to delete communities within History Hub.	Stakeholder	Functional	NA	Communities	Must	Approved
4.2	The system shall provide the capability for authorized registered users to create communities within History Hub.	Stakeholder	Functional	NA	Communities	Should	Approved
4.3	The system shall provide the capability for registered users to delete a community within History Hub, if they are the owner of that community.	Stakeholder	Functional	NA	Communities	Should	Approved
4.4	The system shall provide the capability to define community access as open to all registered and unregistered users.	Stakeholder	Functional	NA	Communities	Must	Approved
4.5	The system shall provide the capability to define community access by permission only, with all content visible via a search.	Stakeholder	Functional	NA	Communities	Must	Approved
4.6	The system shall provide the capability to define community access by permission only, with all community members and content hidden via a search.	Stakeholder	Functional	NA	Communities	Must	Approved
4.7	The system shall provide the capability to support user community blogs.	Stakeholder	Functional	NA	Communities	Must	Approved
4.8	The system shall provide the capability for registered users to customize a community's settings and overview page, if they are the owner of that community.	Stakeholder	Functional	NA	Communities	Should	Approved
4.9	The system shall provide the capability for registered users to follow communities within History Hub.	Stakeholder	Functional	NA	Communities	Must	Approved
4.10	The system shall provide the capability for registered users to unfollow communities within History Hub.	Stakeholder	Functional	NA	Communities	Must	Approved
5.0	The system shall provide the capability for registered users to manage contacts within the system.	Stakeholder	Functional	NA	Contacts	Must	Approved
5.1	The system shall provide the capability for registered users to link to another registered user within History Hub as a connection.	Stakeholder	Functional	NA	Contacts	Should	Approved
5.2	The system shall provide the capability for registered users to send a direct message to other registered users within History Hub.	Stakeholder	Functional	NA	Contacts	Should	Approved
5.3	The system shall provide the capability for registered users to follow other registered users within History Hub.	Stakeholder	Functional	NA	Contacts	Could	Approved
5.4	The system shall provide the capability for registered users to unfollow other registered users within History Hub.	Stakeholder	Functional	NA	Contacts	Could	Approved
6.0	The system shall provide the capability to manage content within the system.	Stakeholder	Functional	NA	Content Management	Must	Approved
6.1	The system shall provide the capability for registered users to create content within History Hub.	Stakeholder	Functional	NA	Content Management	Must	Approved	Registered users may create content such as blog posts, documents, discussions, polls, and videos.
6.2	The system shall provide the capability for all users to view content within History Hub.	Stakeholder	Functional	NA	Content Management	Must	Approved
6.3	The system shall provide the capability for Authorized Users to moderate content and comments before they can be displayed in the system.	Stakeholder	Functional	NA	Content Management	Must	Approved	Moderation includes approving or declining content and comments before they can be displayed, as well as editing content or comments if needed (e.g., to remove Personally Identifiable Information.)
6.4	The system shall provide the capability to publish content to be embedded on other external websites and platforms.	Stakeholder	Functional	NA	Content Management	Must	Approved	The sharing of content on platforms may be supported via RSS feeds or other industry standard mechanisms.
6.5	The system user interface shall provide the capability for registered users to follow content within History Hub.	Stakeholder	Functional	NA	Content Management	Must	Approved	Content that may be followed includes questions, blog posts, documents, discussions, polls, and videos.
6.6	The system user interface shall provide the capability for registered users to unfollow content within History Hub.	Stakeholder	Functional	NA	Content Management	Must	Approved
6.7	The system shall provide the capability for registered users to share content within History Hub.	Stakeholder	Functional	NA	Content Management	Must	Approved	Allows a registered user to share content inside History Hub (e.g., a blog post) with other registered users or a community within History Hub.
6.8	The system shall provide the capability for registered users to share content outside of History Hub.	Stakeholder	Functional	NA	Content Management	Must	Approved	Allows a registered user to share a URL link to History Hub content outside of History Hub (e.g., to share on Facebook, Twitter, etc.)
6.9	The system shall provide the capability for registered users to flag History Hub content for abuse.	Stakeholder	Functional	NA	Content Management	Must	Approved
6.10	The system shall send an alert to Application Administrators when content is flagged.	Stakeholder	Functional	NA	Content Management	Must	Approved
6.11	The system shall provide the capability for registered users to rate content within History Hub.	Stakeholder	Functional	NA	Content Management	Should	Approved	Rating allows a user to indicate how much he or she liked or disliked a content item. For example, a rating could be on a scale, such as 1 to 5 stars, or it could be a simple thumbs up or thumbs down, depending on the platform. Ratings contribute to the reputation and perception of that content.
7.0	The system shall provide the capability to manage discussions and forums in the system.	Stakeholder	Functional	NA	Discussions / Forums	Must	Approved
7.1	The system shall provide the capability for registered users to create a discussion thread.	Stakeholder	Functional	NA	Discussions / Forums	Must	Approved
7.2	The system shall provide the capability for all users to view discussion threads.	Stakeholder	Functional	NA	Discussions / Forums	Must	Approved
7.3	The system shall provide the capability for registered users to post comments via a discussion thread.	Stakeholder	Functional	NA	Discussions / Forums	Must	Approved
7.4	The system shall provide the capability for registered users to post questions via a discussion thread.	Stakeholder	Functional	NA	Discussions / Forums	Must	Approved
7.5	The system shall provide the capability for registered users to respond to a post within a discussion thread.	Stakeholder	Functional	NA	Discussions / Forums	Must	Approved
7.6	The system shall provide the capability for Insider/Expert Users to post responses to content that are displayed as official responses.	Stakeholder	Functional	NA	Discussions / Forums	Must	Approved
7.7	The system shall provide the capability for authorized registered users to assign questions to themselves for follow-up actions.	Stakeholder	Functional	NA	Discussions / Forums	Must	Approved
7.8	The system shall provide the capability for other registered users to assign questions to other registered users for follow-up actions.	Stakeholder	Functional	NA	Discussions / Forums	Must	Approved
7.9	The system shall provide the capability for authorized registered users to track the status of questions.	Stakeholder	Functional	NA	Discussions / Forums	Should	Approved	This includes being able to track the status of unanswered, assigned, and answered questions.
7.10	The system shall provide the capability for authorized registered users to save draft replies.	Stakeholder	Functional	NA	Discussions / Forums	Could	Approved
7.11	The system shall provide the capability for authorized registered users to share draft replies.	Stakeholder	Functional	NA	Discussions / Forums	Could	Approved
7.12	The system shall provide the capability for authorized registered users to save boilerplate text for re-use.	Stakeholder	Functional	NA	Discussions / Forums	Could	Approved
7.13	The system shall provide the capability for authorized registered users to share boilerplate text for re-use.	Stakeholder	Functional	NA	Discussions / Forums	Could	Approved
7.14	The system shall provide the capability to integrate with an Artificial Intelligence (AI) product to provide dynamic responses to user questions.	Stakeholder	Functional	NA	Discussions / Forums	Should	Approved	For example, integrate with a "chatbot".
7.15	The system shall provide the capability to track the time elapsed for a response to a question from an authorized registered user.	Stakeholder	Functional	NA	Discussions / Forums	Could	Approved
7.16	The system shall provide users with suggested answers when registered users are about to submit commonly asked questions.	Stakeholder	Functional	NA	Discussions / Forums	Could	Approved
8.0	The system shall provide the capability to manage notifications in the system.	Stakeholder	Functional	NA	Notifications	Must	Approved
8.1	The system shall send a notification to a registered user when content followed by the user is updated within History Hub.	Stakeholder	Functional	NA	Notifications	Must	Approved
8.2	The system shall provide the capability for registered users to customize notifications within History Hub.	Stakeholder	Functional	NA	Notifications	Should	Approved
8.3	The system shall provide the capability for registered users to receive notifications as emails from History Hub.	Stakeholder	Functional	NA	Notifications	Must	Approved
8.4	The system shall provide the capability for an Application Administrator to send notifications to registered users that may be viewed within the system.	Stakeholder	Functional	NA	Notifications	Could	Approved	For example, within a registered user's inbox.
8.5	The system shall provide the capability for an Application Administrator to send notifications to registered users via email.	Stakeholder	Functional	NA	Notifications	Could	Approved
9.0	The system shall provide the capability to manage profiles within the system.	Stakeholder	Functional	NA	Profile Pages	Must	Approved
9.1	The system shall provide the capability for an Application Administrator to manage user profiles.	Stakeholder	Functional	NA	Profile Pages	Must	Approved
9.1.1	The system shall provide the capability for an Application Administrator to add user profiles.	Stakeholder	Functional	NA	Profile Pages	Must	Approved
9.1.2	The system shall provide the capability for an Application Administrator to update user profiles.	Stakeholder	Functional	NA	Profile Pages	Must	Approved
9.1.3	The system shall provide the capability for an Application Administrator to delete user profiles.	Stakeholder	Functional	NA	Profile Pages	Must	Approved
9.1.4	The system shall provide the capability for an Application Administrator to add the display of user profile images.	Stakeholder	Functional	NA	Profile Pages	Must	Approved	Profile images are user 'headshots' or profile pictures.
9.1.5	The system shall provide the capability for an Application Administrator to update the display of user profile images.	Stakeholder	Functional	NA	Profile Pages	Must	Approved
9.1.6	The system shall provide the capability for an Application Administrator to delete the display of user profile images.	Stakeholder	Functional	NA	Profile Pages	Must	Approved
9.1.7	The system shall provide the capability for an Application Administrator to add contact information to a user profile.	Stakeholder	Functional	NA	Profile Pages	Must	Approved
9.1.8	The system shall provide the capability for an Application Administrator to update the contact information for a user profile.	Stakeholder	Functional	NA	Profile Pages	Must	Approved
9.1.9	The system shall provide the capability for an Application Administrator to delete the contact information from a user profile.	Stakeholder	Functional	NA	Profile Pages	Must	Approved
9.1.10	The system shall provide the capability for an Application Administrator to add the organizations and contacts associated with a user's profile.	Stakeholder	Functional	NA	Profile Pages	Must	Approved
9.1.11	The system shall provide the capability for an Application Administrator to update the organizations and contacts associated with a user's profile.	Stakeholder	Functional	NA	Profile Pages	Must	Approved
9.1.12	The system shall provide the capability for an Application Administrator to delete the organizations and contacts associated with a user's profile.	Stakeholder	Functional	NA	Profile Pages	Must	Approved
9.2	The system shall provide the capability for a registered user to manage their own user profile.	Stakeholder	Functional	NA	Profile Pages	Must	Approved
9.2.1	The system shall provide the capability for a registered user to add content within their user profile, including their contact information.	Stakeholder	Functional	NA	Profile Pages	Must	Approved
9.2.2	The system shall provide the capability for a registered user to change content within their user profile, including their contact information.	Stakeholder	Functional	NA	Profile Pages	Must	Approved
9.2.3	The system shall provide the capability for a registered user to delete content within their user profile, including their contact information.	Stakeholder	Functional	NA	Profile Pages	Must	Approved	Registered users may delete most contact information in their profile page, but they cannot delete their name and email address (i.e., cannot delete their entire user profile from the system.)
9.2.4	The system provide the capability for a registered user to upload profile images to display in their user profile.	Stakeholder	Functional	NA	Profile Pages	Should	Approved	Profile images are user 'headshots', profile pictures, or avatars.
9.2.5	The system shall provide the capability for an Application Administrator to associate a registered user's profile with organizations within History Hub.	Stakeholder	Functional	NA	Profile Pages	Should	Approved	Application Administrators can associate users with groups, business functions and other registered users, but there is no way for users to do this themselves. There is also no way for an end user to view, search, or sort users by these attributes.
9.2.6	The system shall provide the capability for an Application Administrator to associate a registered user's profile with working groups within History Hub.	Stakeholder	Functional	NA	Profile Pages	Should	Approved
9.2.7	The system shall provide the capability for an Application Administrator to associate a registered user's profile with business functions within History Hub.	Stakeholder	Functional	NA	Profile Pages	Should	Approved
9.2.8	The system shall provide the capability for an Application Administrator to associate a registered user's profile with other registered users within History Hub.	Stakeholder	Functional	NA	Profile Pages	Could	Approved
9.2.9	The system shall provide the capability for registered users to define who can see elements of their profile information.	Stakeholder	Functional	NA	Profile Pages	Could	Approved	This is the ability for a user to set privacy settings on their profile. Users may be able to define privacy settings for most portions of their user profile (i.e., make them private and not be displayed), but their username will always be visible to other registered users.
9.3	The system shall display a summary of a registered user's History Hub activities through their profile.	Stakeholder	Functional	NA	Profile Pages	Should	Approved
9.4	The shall display a summary of a registered user's contributed content through their profile.	Stakeholder	Functional	NA	Profile Pages	Must	Approved
9.5	The system shall display a registered user's connections and organizations through their profile.	Stakeholder	Functional	NA	Profile Pages	Should	Approved
10.0	The system shall provide the capability to manage records according to NARA records management standards and procedures.	Stakeholder	Functional	NA	Records Management	Must	Approved
10.1	The system shall provide the capability for NARA authorized users to identify and properly disposition electronic records.	Stakeholder	Functional	NA	Records Management - Records Disposition	Must	Approved	This supports the deletion or transfer of the records at the end of the retention period as applicable to the records.
10.1.1	The system shall provide the capability to export electronic records in a NARA-approved format.	Stakeholder	Functional	NA	Records Management - Records Disposition	Must	Approved	Exporting records and associated metadata from the system supports the ability to manually transfer the records to a permanent archival repository. See NARA Bulletin 2014-04 at: https://www.archives.gov/records-mgmt/bulletins/2014/2014-04.html
10.1.2	The system shall provide the capability to export the associated metadata with the electronic records.	Stakeholder	Functional	NA	Records Management - Records Disposition	Must	Approved	NARA Bulletin 2015-04 (Metadata Guidance for the Transfer of Permanent Electronic Records) defines the minimum set of metadata elements that must accompany transfers of permanent electronic records to the National Archives.
10.2	The system shall provide the capability for authorized users to manage electronic records metadata.	Stakeholder	Functional	NA	Records Management - Metadata	Must	Approved	Manage means to create, read, update, and delete.
10.2.1	The system shall provide the capability to capture the associated metadata of an electronic record that is compliant with NARA metadata standards.	Stakeholder	Functional	NA	Records Management - Metadata	Must	Approved	For example, in the header of the file or in a separate file, depending on the format of the record. Electronic records created within the solution must embed metadata about the record (unique identifier, creation time-stamp, format type and version, etc.) that are compliant with NARA metadata standards found in NARA Bulletin 2015-04, Metadata Guidance for the Transfer of Permanent Electronic Records. See: https://www.archives.gov/records-mgmt/bulletins/2015/2015-04.html
11.0	The system shall provide the capability to generate reports.	Stakeholder	Functional	NA	Reporting	Must	Approved
11.1	The system shall provide the capability for an Application Administrator to generate standard reports.	Stakeholder	Functional	NA	Reporting	Must	Approved	Reports should be statistically valid and reliable.
11.2	The system shall provide the capability for an Application Administrator to generate ad hoc reports.	Stakeholder	Functional	NA	Reporting	Must	Approved	Reports should be statistically valid and reliable.
11.3	The system shall provide the capability to generate reports on user activity.	Stakeholder	Functional	NA	Reporting	Should	Approved	For example, a User Activity Report that provides information on individual registered user content, replies, and contributions.
11.4	The system shall provide the capability to generate report metrics on internal search queries from users.	Stakeholder	Functional	NA	Reporting	Should	Approved	For example, a Search Query Report that provides information on internal search queries from users including keywords, volume, and results.
11.5	The system shall provide the capability to generate reports on content views.	Stakeholder	Functional	NA	Reporting	Should	Approved
11.6	The system shall provide the capability to generate reports on content popularity.	Stakeholder	Functional	NA	Reporting	Should	Approved
11.7	The system shall provide the capability to generate reports on content ratings.	Stakeholder	Functional	NA	Reporting	Should	Approved
11.8	The system shall provide the capability to measure user satisfaction regarding responses to their questions or search.	Stakeholder	Functional	NA	Reporting	Should	Approved
11.8.1	The system shall provide the capability to generate reports on user satisfaction.	Stakeholder	Functional	NA	Reporting	Should	Approved
11.9	The system shall provide the capability to measure anonymous user success when searching for answers on History Hub.	Stakeholder	Functional	NA	Reporting	Could	Approved	An 'anonymous user success' is the success of a non-registered user searching History Hub (such as via Google or directly within History Hub), and successfully finding an answer to their question, without having to create an account or submit a new question.
11.9.1	The system shall provide the capability to report anonymous user success when searching for answers on History Hub.	Stakeholder	Functional	NA	Reporting	Could	Approved
11.10	The system shall provide the capability for authorized registered users to view a report of their content, replies, contributions, and ratings on History Hub.	Stakeholder	Functional	NA	Reporting	Could	Approved
11.11	The system shall provide the capability for authorized registered users to download a report of their content, replies, contributions, and ratings on History Hub.	Stakeholder	Functional	NA	Reporting	Could	Approved	Download reports in common formats, such as, .csv, .xlsx, .pdf, etc.
11.12	The system shall provide the capability to integrate with external web analytics systems.	Stakeholder	Functional	NA	Reporting	Must	Approved	For example, Google Analytics and Google Tag Manager.
11.13	The system shall provide the capability for authorized users to download reports.	Stakeholder	Functional	NA	Reporting	Must	Approved	Download reports in common formats, such as, .csv, .xlsx, and .pdf.

Authorized users consists of Application Administrators and authorized registered users.

11.14 The system shall provide the capability for authorized users to export reports. Stakeholder Functional NA Reporting Must Approved Download reports in common formats, such as, .csv, .xlsx, and .pdf.

Authorized users consists of Application Administrators and authorized registered users.

12.0	The system shall provide the capability for all users to search on content within History Hub.	Stakeholder	Functional	NA	Search	Must	Approved
12.1	The system shall display search results based on a user's role within History Hub.	Stakeholder	Functional	NA	Search	Must	Approved	Search results must respect access rights.
12.2	The system shall display search results based on a user's permissions within History Hub.	Stakeholder	Functional	NA	Search	Must	Approved
12.3	The system shall display search results based on a user's permission level within History Hub.	Stakeholder	Functional	NA	Search	Must	Approved
12.4	The system shall provide the capability for all users to filter on search results.	Stakeholder	Functional	NA	Search	Must	Approved	Filtering is the ability to refine and get a subset of search results based on the communities, people, or type of content associated with the search results.
12.5	The system shall provide the capability for all users to sort search results.	Stakeholder	Functional	NA	Search	Must	Approved	For example, users may sort results by date created, latest activity, title, or the most or least followers.
12.6	When performing a search on tags, the system shall return search results based on keyword matching.	Stakeholder	Functional	NA	Search	Should	Approved	Tag meanings shall be combined so that, for example, "web," "web site," and "website" will all be returned on a search for any one of these keywords.
12.7	The system shall provide the capability for a registered user to save custom search queries.	Stakeholder	Functional	NA	Search	Should	Approved
12.8	The system shall provide the capability for a registered user to follow custom searches on History Hub.	Stakeholder	Functional	NA	Search	Should	Approved
12.9	The system shall provide the capability for a registered user to receive notifications on new search hits for searches that they follow.	Stakeholder	Functional	NA	Search	Should	Approved
12.10	The system shall provide a predictive search algorithm that provides suggestions for questions being entered by a user.	Stakeholder	Functional	NA	Search	Must	Approved
12.11	The system shall provide a predictive search algorithm that provides suggestions for search queries being entered by a user.	Stakeholder	Functional	NA	Search	Must	Approved
12.12	The system shall provide the capability for an Application Administrator to select search queries to include 'promoted' or weighted results.	Stakeholder	Functional	NA	Search	Should	Approved	To allow Application Administrators to prioritize certain content to appear at the top of specific search results. For example, an authoritative post on Deck Logs appears at the top of the results for any search for "deck log": https://historyhub.history.gov/search.jspa?q=deck+log
12.13	The system shall provide the capability to customize a thesaurus for the search engine.	Stakeholder	Functional	NA	Search	Could	Approved	This will allow the search engine to link common synonyms or word variants, related terms, and custom proprietary terminology, in order to improve search recall.
12.14	The system shall provide a search engine capable of stemming search terms.	Stakeholder	Functional	NA	Search	Should	Approved	For example, a search on "photo" would retrieve results that contain the words "photo", "photos", "photographs", etc.
13.0	The system shall provide the capability to tag content within the system.	Stakeholder	Functional	NA	Tagging	Must	Approved
13.1	The system shall provide the capability for registered users to tag content within History Hub.	Stakeholder	Functional	NA	Tagging	Must	Approved	Tagging consists of allowing users to assign keywords, terms, or metadata to a piece of information.
13.1.1	The system shall provide the capability for registered users to enter tags as free text.	Stakeholder	Functional	NA	Tagging	Should	Approved
13.1.2	The system shall provide the capability for registered users to enter tags by selecting from an administered pick list.	Stakeholder	Functional	NA	Tagging	Should	Approved	For an "administered pick-list" you would need to use the Categories function in the current system.
13.2	The system shall provide the capability for an Application Administrator to manage a pick list of tags to be applied to content in the History Hub.	Stakeholder	Functional	NA	Tagging	Should	Approved	This functions as Categories but not as "Tags" per-se in the current system.
13.3	The system shall provide the capability for an authorized users to curate tags.	Stakeholder	Functional	NA	Tagging	Could	Approved	Authorized users may be Community Managers (i.e., Application Administrators) or authorized registered users.
13.4	The system shall provide the capability to suggest existing tags to registered users when creating questions.	Stakeholder	Functional	NA	Tagging	Could	Approved
14.0	The system shall provide the capability for an Application Administrator to customize the design and layout of the system's public facing website.	Stakeholder	Functional	NA	User Interface	Must	Approved
15.0	The system user interface shall be responsive for use of History Hub on mobile devices.	Stakeholder	Functional	NA	User Interface	Must	Approved	The History Hub should be accessible via Android, iOS, and Windows devices.
15.1	The system user interface shall provide the capability for registered users to view content within History Hub via a mobile device.	Stakeholder	Functional	NA	User Interface	Must	Approved
15.2	The system user interface shall provide the capability for registered users to post content within History Hub via a mobile device.	Stakeholder	Functional	NA	User Interface	Must	Approved
15.3	The system user interface shall provide the capability for registered users to reply to content within History Hub via a mobile device.	Stakeholder	Functional	NA	User Interface	Must	Approved
16.0	The system user interface shall display an activity stream based on updates to a registered user's communities, content, or followed users.	Stakeholder	Functional	NA	User Interface	Should	Approved	A personalized activity stream, similar to Facebook, that displays updates that occur to the communities, content, or contacts associated with a registered user's profile.
17.0	The system shall be 99% available, 24 hours a day, 7 days a week, with the exception of scheduled maintenance downtime.	Stakeholder	NonFunctional	Reliability	Availability	Must	Approved	This will enable records to be accessible for agency responsiveness to discovery, FOIA, Privacy Act, or other access requests.
18.0	The system shall provide the capability for backup and recovery of the system.	Stakeholder	NonFunctional	Reliability	Backup and Recovery	Must	Approved
19.0	The system shall support the bulk import of all data from the existing History Hub system to the new History Hub system.	Stakeholder	NonFunctional	Supportability	Data Transfer	Must	Approved	This includes user accounts and user profile information, established groups and membership data, and all contributed / posted content.
20.0	The system shall scale to handle a maximum of 90 million page views annually to support future data growth without major design or architectural changes.	Stakeholder	NonFunctional	Supportability	Elasticity	Should	Approved	To support being able to double the amount of page views per year, for the next 5 years. Currently, History Hub supports a minimum of 7.5M page views per month.
21.0	The system shall be a web-based Software-as-a-Service (SaaS) solution.	Stakeholder	NonFunctional	Supportability	Hosting	Must	Approved
22.0	The system shall support Internet Protocol version 6 (IPv6).	Stakeholder	NonFunctional	Supportability	Hosting	Must	Approved
23.0	The system shall support a minimum of 7.5 million page views a month.	Stakeholder	NonFunctional	Performance	Performance	Must	Approved
24.0	The system shall be capable of supporting at a minimum one million (1,000,0000) user accounts.	Stakeholder	NonFunctional	Performance	Performance	Must	Approved
25.0	The system shall be in compliance with NARA IT Security Requirements.	Stakeholder	NonFunctional	Reliability	Security	Must	Approved	NARA IT Security Requirements are included in NARA IT Security Requirements Version 6.18, 09/12/2019; and NARA IT Security Requirements Language for Unclassified Systems Version 1.2, 02/13/2017.

History Hub is currently FedRAMP compliant.

26.0	The system shall provide secure application access and data transport.	Stakeholder	NonFunctional	Reliability	Security	Must	Approved	Secure access and data transport can be achieved via Secure Socket Layer (SSL).
27.0	The system shall prevent unauthorized access to the administration functions of the History Hub.	Stakeholder	NonFunctional	Reliability	Security	Must	Approved	Administrative access is restricted to NARA Application Administrators and contractor System Administrators. Administrative functions include system configuration and account management tasks.
28.0	The system shall provide the capability to integrate with user authentication services.	Stakeholder	NonFunctional	Reliability	Security	Should	Approved	For example, integration with OpenId or single sign-on (SSO) via an SSO service.
29.0	The system shall require two-factor authentication for Application Administrators to gain access to administrative areas of the application.	Stakeholder	NonFunctional	Reliability	Security	Must	Approved
30.0	The system shall be in compliance with Section 508 Standards for Electronic and Information Technology.	Stakeholder	NonFunctional	Usability	System Accessibility	Must	Approved
30.1	The system shall comply with the Section 508 of the Rehabilitation Act (29 United States Code (U.S.C.) 794d), as amended by the Workforce Investment Act of 1998 (Public Law (P.L.) 105-220), August 7, 1998.	Stakeholder	NonFunctional	Usability	System Accessibility	Must	Approved
30.2	The system shall comply with the associated Section 508 Standards as set forth by the U.S. Access Board and updated as of January 22, 2018 (29 U.S.C. 794d).	Stakeholder	NonFunctional	Usability	System Accessibility	Must	Approved
30.3	The system shall comply with the Level A and Level AA Success Criteria and Conformance Requirements specified for Web pages in Web Content Accessibility Guidelines (WCAG) 2.0.	Stakeholder	NonFunctional	Usability	System Accessibility	Must	Approved
31.0	The system shall be compatible with NARA's Enterprise Architecture.	Stakeholder	Constraint	Implementation	System Architecture	Must	Approved	For more information, please refer to the NARA 812, Enterprise Architecture policy, at https://work.nara.gov/nara_policies_and_guidance/directives/0800_series/nara0812.html.
32.0	The system shall provide an Application Programming Interface (API) with capabilities to integrate with other NARA business systems.	Stakeholder	NonFunctional	Usability	System interoperability	Must	Approved	To support communication with NARA business systems such as the Enterprise Customer Relationship Management (eCRM) platform.
33.0	The system shall provide the capability to display dynamic content from History Hub on other platforms and websites.	Stakeholder	NonFunctional	Usability	System interoperability	Must	Approved	This includes support for Predictive Search via the API or some other mechanism, for example, the 'Contact Us' widget on Archives.gov.
34.0	The system shall be accessible to users via an internet browser.	Stakeholder	NonFunctional	Supportability	Web Browser Compatibility	Must	Approved
34.1	The system shall be accessible to a user using Chrome.	Stakeholder	NonFunctional	Supportability	Web Browser Compatibility	Must	Approved	The browser versions to be supported will be dependent upon when the system is deployed into production and the browser versions supported in the NARA baseline at that time.
34.2	The system shall be accessible to a user using Mozilla Firefox.	Stakeholder	NonFunctional	Supportability	Web Browser Compatibility	Must	Approved	The browser versions to be supported will be dependent upon when the system is deployed into production and the browser versions supported in the NARA baseline at that time.
34.3	The system shall be accessible to a user using Safari.	Stakeholder	NonFunctional	Supportability	Web Browser Compatibility	Must	Approved	The browser versions to be supported will be dependent upon when the system is deployed into production and the browser versions supported in the NARA baseline at that time.
34.4	The system shall be accessible to a user using Microsoft Edge.	Stakeholder	NonFunctional	Supportability	Web Browser Compatibility	Must	Approved	The browser versions to be supported will be dependent upon when the system is deployed into production and the browser versions supported in the NARA baseline at that time.

&"+,Bold"&10History Hub (HH) Requirements Verification Traceability Matrix (RVTM)

&"+,Regular"&10&F &"+,Regular"&10Page &P of &N https://www.archives.gov/records-mgmt/bulletins/2014/2014-04.htmlhttps://www.archives.gov/records-mgmt/bulletins/2015/2015-04.htmlhttps://historyhub.history.gov/search.jspa?q=deck+loghttps://work.nara.gov/nara_policies_and_guidance/directives/0800_series/nara0812.html.

StandardValues

Type	Category	Priority
	Status	Verification Method		Verification Status		UAT Status
Business	Functional	Must	Requirements that are CRITICAL to meeting the project's objectives		Approved		Inspection	Pass	Pass
Stakeholder	Non-functional	Should	Requirements that are critical and should be included if possible, but which can be excluded		Deferred		Analysis	Fail	Fail
System	Constraint	Could	Requirements that are part of the project's scope and add or enhance project benefits		Draft		Test	N/A	N/A
	N/A	Would	Requirements that do not have a significant impact on project benefits or could be considered as a “would like to have”		Obsolete		Demonstration
							Certification
							N/A

&"+,Bold"&10<Project Name> Requirements Verification Traceability Matrix (RVTM) - Standard Values

&"+,Regular"&10&F &"+,Regular"&10Page &P of &N

Legend for Fillable Values

Legend
0 - Cannot Meet	Cannot meet the requirement. Use this value if the solution cannot meet the requirement.
1 - Requires Significant Development	Requires significant customization or development (modification of source). Use this value if the solution will require changes or new development at the source code level to meet the requirement.
2 - Requires Advanced Configuration	Requires advanced configuration or custom development using an SDK or API. Use this value if the solution will customization using an SDK or API to meet the requirement.
3 - Requires Minimal Enhancement	Requires minimal or no special enhancements. Use this value if the solution meets the requirement with minimal configuration.
4 - Requires No Enhancement	Use this value if the solution meets the requirement without configuration or enhancement.

Include costs as part of your Volume III submission for individual or grouped items in the response for each item marked 1, 2, or 3.

Time

Ready at time of award

30 days from award

60 days from award

90+ days from award

File details come from the government source that posted it. Updated Mar 30, 2022.