Appendix 4 - HistoryHub_RVTM_v.2.0.xlsx
XLSX spreadsheet 216 KB Posted
- Attached to
- History Hub - External Support Community System
- Solicitation number
- 88310322Q00053
About this file
This request for quotation (RFQ) from the National Archives and Records Administration (NARA) solicits proposals for a Software as a Service (SaaS) to support NARA's customer support community platform, History Hub. The SaaS must provide out-of-the-box capabilities for functions including role-based access control, content management, communities, and notifications. 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 technical approach, past performance, and price. The award will be made to the offeror whose quotation is most advantageous to the government considering these factors.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| 88310322Q00053 Amendment 002 Questions and Answers_FINAL.docx | DOCX document | |
| Appendix 10 - Cloud_CMDB_Template.xlsx | XLSX spreadsheet | |
| 88310322Q00053 HH Platform Solicitation Attachments 1-13.docx | DOCX document | |
| PWS Attachment 1 - StRS - RVTM - HH 2.0 Contractor Response Sheet.xlsx | XLSX spreadsheet | |
| Appendix 1 - NARA 805-h1.pdf | ||
| Appendix 5 - Test_Plan_Template_v2.1.docx | DOCX document | |
| Appendix 6 - Test_Procedures_Template.xlsx | XLSX spreadsheet | |
| Appendix 2 - NARA_IT_Security_Requirements v7.1.pdf | ||
| Appendix 3 - HistoryHub_StRS_v.2.0.docx | DOCX document | |
| Appendix 7 - Test_Report_Template.docx | DOCX document | |
| Appendix 11 Section 508 ICT Requirements.docx | DOCX document |
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
Text version
Title Page
| NATIONAL ARCHIVES AND RECORDS ADMINISTRATION (NARA) | |
| Revision History |
| Date | Version | Author | Revision Description |
| 11/17/2016 | 1.0 | NARA Requirements Management Division (IR) | Initial Draft |
| 01/13/2017 | 1.1 | NARA Requirements Management Division (IR) | Updated Section 508 requirements based on feedback from NARA Acquisitions |
| 8/30/21 | 2.0 | NARA Requirements Management Division (IR) | Updated to support History Hub Platform Modernization effort |
| Requirements Verification Traceability Matrix |
| (RVTM) |
History Hub
| Version: 2.0 FINAL |
| Prepared by NARA Requirements Management (IR) Division |
| August 30, 2021 |
Requirements
| REQUIREMENTS | MISC | DESIGN | DEVELOPMENT | VERIFICATION | DEPLOYMENT PREPARATION | ||||||||||||||
| Req # | Requirement Text | Type | Category | Sub-Category | Feature | Req Priority | Status | Target Release | Source | Notes | Element | Iteration | Verification Method | Verification Test Case / Step | Verification Status | Verification Criteria | UAT Test Case | UAT Status | Validation Criteria |
ID#AAAAT5ocxk0 James Mischke (2022-01-05 14:54:37)
| All changes made by Office of Innovation on December 16th are included here. | 1.0 | The system shall support role-based access and account management. | Stakeholder | Functional | NA | Account Management | Must | Approved | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | 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 | NA | Account Management | Must | Approved | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | ||
| 1.2 | The system shall provide the capability for an Application Administrator to conduct tasks requiring administrative rights within History Hub. | Stakeholder | Functional | NA | Account Management | Must | Approved | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | ||
| 1.3 | The system shall provide the capability for a user to register for an account within History Hub. | Stakeholder | Functional | NA | 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 | NA | 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 | NA | Account Management | Must | Approved | |||
| 1.3.3 | The system shall provide the capability for a registered user to manage their password. | Stakeholder | Functional | NA | 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 | NA | 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 | NA | 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 | NA | 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 | NA | Account Management | Must | Approved | |||
| 2.0 | The system shall provide the capability to manage announcements within the system. | Stakeholder | Functional | NA | Announcements | Must | Approved | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | ||
| 2.1 | The system shall provide the capability for an authorized user to create announcements. | Stakeholder | Functional | NA | Announcements | Must | Approved | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | ||
| 2.2 | The system shall provide the capability for an authorized user to post announcements. | Stakeholder | Functional | NA | Announcements | Must | Approved | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | ||
| 2.3 | The system shall provide the capability to display announcements across the system. | Stakeholder | Functional | NA | Announcements | Must | Approved | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | ||
| 2.4 | The system shall provide the capability to display announcements within a community in History Hub. | Stakeholder | Functional | NA | Announcements | Must | Approved | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | ||
| 3.0 | The system shall provide the capability to manage artifacts and attachments within the system. | Stakeholder | Functional | NA | Attachments | Must | Approved | |||
| 3.1 | The system shall provide the capability for authorized registered users to upload artifacts within History Hub. | Stakeholder | Functional | NA | Attachments | Must | Approved | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 4.2 | The system shall provide the capability for authorized registered users to create communities within History Hub. | Stakeholder | Functional | NA | Communities | Should | Approved | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 4.7 | The system shall provide the capability to support user community blogs. | Stakeholder | Functional | NA | Communities | Must | Approved | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 4.9 | The system shall provide the capability for registered users to follow communities within History Hub. | Stakeholder | Functional | NA | Communities | Must | Approved | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 6.7 | The system shall provide the capability for registered users to share content within History Hub. | Stakeholder | Functional | NA | Content Management | Must | Approved | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 6.10 | The system shall send an alert to Application Administrators when content is flagged. | Stakeholder | Functional | NA | Content Management | Must | Approved | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 6.11 | The system shall provide the capability for registered users to rate content within History Hub. | Stakeholder | Functional | NA | Content Management | Should | Approved | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 7.2 | The system shall provide the capability for all users to view discussion threads. | Stakeholder | Functional | NA | Discussions / Forums | Must | Approved | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 8.2 | The system shall provide the capability for registered users to customize notifications within History Hub. | Stakeholder | Functional | NA | Notifications | Should | Approved | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 9.1.2 | The system shall provide the capability for an Application Administrator to update user profiles. | Stakeholder | Functional | NA | Profile Pages | Must | Approved | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 9.1.3 | The system shall provide the capability for an Application Administrator to delete user profiles. | Stakeholder | Functional | NA | Profile Pages | Must | Approved | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 9.4 | The shall display a summary of a registered user's contributed content through their profile. | Stakeholder | Functional | NA | Profile Pages | Must | Approved | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 9.5 | The system shall display a registered user's connections and organizations through their profile. | Stakeholder | Functional | NA | Profile Pages | Should | Approved | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 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 | Core_RIM_Reqts_v.1.2_2019Jul18 | |
| 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 | Core_RIM_Reqts_v.1.2_2019Jul18 | 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 | Core_RIM_Reqts_v.1.2_2019Jul18 | 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 | Core_RIM_Reqts_v.1.2_2019Jul18 | 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 | Core_RIM_Reqts_v.1.2_2019Jul18 | 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 | Core_RIM_Reqts_v.1.2_2019Jul18 | 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 11.6 | The system shall provide the capability to generate reports on content popularity. | Stakeholder | Functional | NA | Reporting | Should | Approved | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 11.7 | The system shall provide the capability to generate reports on content ratings. | Stakeholder | Functional | NA | Reporting | Should | Approved | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 11.8.1 | The system shall provide the capability to generate reports on user satisfaction. | Stakeholder | Functional | NA | Reporting | Should | Approved | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | 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 | New Reqt requested on 8/19 | 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 New Reqt requested on 8/20 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 12.1 | The system shall display search results based on a user's role within History Hub. | Stakeholder | Functional | NA | Search | Must | Approved | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 12.3 | The system shall display search results based on a user's permission level within History Hub. | Stakeholder | Functional | NA | Search | Must | Approved | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 12.4 | The system shall provide the capability for all users to filter on search results. | Stakeholder | Functional | NA | Search | Must | Approved | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 15.0 | The system user interface shall be responsive for use of History Hub on mobile devices. | Stakeholder | Functional | NA | User Interface | Must | Approved | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | 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 | Stakeholder feedback on 8/26/2021 | 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 22.0 | The system shall support Internet Protocol version 6 (IPv6). | Stakeholder | NonFunctional | Supportability | Hosting | Must | Approved | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 23.0 | The system shall support a minimum of 7.5 million page views a month. | Stakeholder | NonFunctional | Performance | Performance | Must | Approved | Stakeholder feedback on 8/26/2021 | |
| 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 25.0 | The system shall be in compliance with NARA IT Security Requirements. | Stakeholder | NonFunctional | Reliability | Security | Must | Approved | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 30.0 | The system shall be in compliance with Section 508 Standards for Electronic and Information Technology. | Stakeholder | NonFunctional | Usability | System Accessibility | Must | Approved | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | |
| 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | 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 | DRAFT StRS_HistoryHub2.0_v0.1_2021Feb3 | 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. |
History Hub Requirements Verification Traceability Matrix (RVTM)
&F Page &P of 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.
Standard Values
| Type | Business | Stakeholder | System | BusinessRule | NA | Functional | NonFunctional | Constraint | Constraint. | Priority | |||||||
| Status | Verification Method | Verification Status | UAT Status | ||||||||||||||
| Business | NA | Functional | Functional | Constraint. | NA | NA | Usability | Concerned with characteristics such as aesthetics and consistency in the user interface. | Design | Specifies or constrains the options for designing a system. For example, if you specify that a relational database is required, that's a design constraint. | NA | Must | Requirements that are CRITICAL to meeting the project's objectives and ensuring all core business needs are met. Not meeting a Must Have requirement will cause the project to be considered unacceptable to end users and/or a failure by key stakeholders | Approved | Inspection | Pass | Pass |
| Stakeholder | NonFunctional | NonFunctional | Reliability | Concerned with characteristics such as availability (the amount of system "up time"), accuracy of system calculations, and the system's ability to recover from failure. | Implementation | Specifies or constrains the coding or construction of a system. Examples might include required standards, implementation languages, and resource limits. | Should | Requirements that are of high value to end users and stakeholders and that should be included, but which can be excluded especially if a workaround exists that enables the core business needs to be met | Deferred | Analysis | Fail | Fail | |||||
| System | Constraint | Constraint | Performance | Concerned with characteristics such as throughput, response time, recovery time, start-up time, and shutdown time. | Interface | Specifies an external item with which a system must interact, or constraints on formats or other factors used within such an interaction. | Could | Requirements that are part of the project's scope and add or enhance project benefit | Draft | Test | NA | NA | |||||
| BusinessRule | Supportability | Concerned with characteristics such as testability, adaptability, maintainability, compatibility, configurability, installability, scalability, and localizability. | Physical | Specifies a physical constraint imposed on the hardware used to house the system — shape, size, or weight, for example. | 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 | |||||||||||||||||
| NA |
History Hub Requirements Verification Traceability Matrix (RVTM) / &A
&F Page &P of
WARNING! Some of the information in this worksheet is used to implement cascading drop-down lists in the 'Requirements' worksheet, be aware of this when modifying it, and especially when deleting columns! Refer to the 'Notes' worksheet for more information.
Column Descriptions
| Column Name | Column Descriptions | Required (Y/N?) | |
| Req # | A unique identifier for the requirement. | Yes | |
| Requirement Text | The text of the requirement. | Yes | |
| Type | The type of the requirement, such as "Business" or "Stakeholder". | ||
| Values: Business | Stakeholder | System | BusinessRule | Yes | ||
| Category | The category of the requirement, such as "Functional" or "Non-Functional". |
Values: Functional | NonFunctional | Constraint | NA
| Yes; Use "NA" for business requirements. | |||
| Sub-Category | The sub-category of requirement that applies to Non-Functional requirements only. | ||
| Values: Usability | Reliability | Supportability | Performance | Design | Implementation |Interface | Physical | Yes | ||
| Feature | The high-level function, capability, feature or other grouping that has meaning for the stakeholders. | Yes | |
| Req Priority | |||
| The priority of the stakeholder requirement as assigned by the stakeholders. |
Values: Must | Should | Could | Would
| Yes | |||
| Status | The status of the requirement. | ||
| Values: Approved, Deferred, Draft, Obsolete | Yes |
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .