StRS,_RVTM_Contractor_Technical_Response_Worksheet,_HH.xlsx
XLSX spreadsheet 24 KB Posted
- Attached to
- Internal Collaboration Network and History Hub
- Solicitation number
- NAMA-17-R-0001
About this file
NAMA-17-R-0001, Attachment 9, Proposal Submission Instructions, paragraph 1(a)(ii), StRS RVTM Contractor Technical Response Worksheet (HH)
View the file
Other files
| File | Type | Posted |
|---|---|---|
| NAMA-17-R-0001_Amendment_002_FINAL.doc | DOC document | |
| PWS Appendix 5, RVTM_Template_v2.0.xlsx | XLSX spreadsheet | |
| PWS Appendix 8, Test_Report_Template.docx | DOCX document | |
| PWS Appendix 3, StRS_ICN_v1.1_FINAL Redacted.docx | DOCX document | |
| PWS Appendix 11, Cloud_CMDB_Template.xlsx | XLSX spreadsheet | |
| GFI_-_PWS_Appendices_1_-_8,_and_11.zip | ZIP file | |
| PWS Appendix 7, Test_Procedures_Template.xlsx | XLSX spreadsheet | |
| StRS,_RVTM_-_Contractor_Technical_Response_Worksheet,_ICN.xlsx | XLSX spreadsheet | |
| PWS Appendix 4, StRS_HistoryHub_v1.1_FINAL Redacted.docx | DOCX document | |
| PWS Appendix 1, NARA SDLC v1.6.pdf | ||
| NAMA-17-R-0001_ICN_-_HH_CSS_Attachments_1-12.docx | DOCX document | |
| PWS Appendix 6, Test_Plan_Template.docx | DOCX document | |
| PWS Appendix 2, NARA IT Security Requirements v6.5.pdf |
Show all 13
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
Requirements
| REQUIREMENTS | MISC | DESIGN | DEVELOPMENT | VERIFICATION | DEPLOYMENT PREPARATION | VENDOR'S RESPONSE | VENDOR'S TIME TO IMPLEMENT | VENDOR'S NOTES | ||||||||||
| Req # | Requirement Text | Type | 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 | 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). | |||||||||||
| 2 | The system shall provide the capability for Application Administrators to create and maintain user accounts within History Hub. | Stakeholder | Functional | Account Management | Must | Approved | ||||||||||||
| 3 | The system shall provide the capability for Application Administrators to conduct tasks requiring administrative rights within History Hub. | Stakeholder | Functional | Account Management | Must | Approved | ||||||||||||
| 4 | The system shall provide the capability for an Authorized User to create and post announcements. | Stakeholder | Functional | Announcements | Must | Approved | ||||||||||||
| 5 | The system shall provide the capability to display announcements across the History Hub or within a group in History Hub. | Stakeholder | Functional | Announcements | Must | Approved | ||||||||||||
| 6 | The system shall provide the capability for registered users to upload artifacts within History Hub. | Stakeholder | Functional | Attachments | Should | Approved | 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 .bmp. | |||||||||||
| 7 | The system shall provide the capability for all users to download artifacts within History Hub. | Stakeholder | Functional | Attachments | Should | Approved | ||||||||||||
| 8 | The system shall provide the capability for an Application Administrator to specify the file size limitation for uploaded attachments within History Hub. | Stakeholder | Functional | Attachments | Should | Approved | ||||||||||||
| 9 | The system shall provide the capability for registered users to tag another registered user within History Hub as a connection. | Stakeholder | Functional | Contacts | Must | Approved | ||||||||||||
| 10 | The system shall provide the capability for registered users to send a direct message to other registered users within History Hub. | Stakeholder | Functional | Contacts | Should | Approved | ||||||||||||
| 11 | The system shall provide the capability for registered users to follow and unfollow other registered users within History Hub. | Stakeholder | Functional | Contacts | Must | Approved | ||||||||||||
| 12 | The system shall provide the capability for registered users to create content within History Hub. | Stakeholder | Functional | Content Management | Must | Approved | ||||||||||||
| 13 | The system shall provide the capability for unregistered users to view content within History Hub. | Stakeholder | Functional | Content Management | Must | Approved | ||||||||||||
| 14 | The system shall provide the capability for Authorized Users to moderate content and comments before they can be displayed in the system. | Stakeholder | Functional | 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.) | |||||||||||
| 15 | The system shall provide the capability for registered users to create a discussion thread. | Stakeholder | Functional | Discussion/Forums | Must | Approved | ||||||||||||
| 16 | The system shall provide the capability for all users to view discussion threads. | Stakeholder | Functional | Discussion/Forums | Must | Approved | ||||||||||||
| 17 | The system shall provide the capability for registered users to post comments or questions via a discussion thread. | Stakeholder | Functional | Discussion/Forums | Must | Approved | ||||||||||||
| 18 | The system shall provide the capability for registered users to respond to a post within a discussion thread. | Stakeholder | Functional | Discussion/Forums | Must | Approved | ||||||||||||
| 19 | The system shall provide the capability for Insider/Expert Users to post responses to content that are displayed as official responses. | Stakeholder | Functional | Discussion/Forums | Must | Approved | ||||||||||||
| 20 | The system shall provide the capability for registered users to flag History Hub content for abuse. | Stakeholder | Functional | Flag Content | Must | Approved | ||||||||||||
| 21 | The system shall send an alert to Application Administrators when content is flagged. | Stakeholder | Functional | Flag Content | Must | Approved | ||||||||||||
| 22 | The system shall provide the capability for Application Administrators to manage groups within History Hub, including creating, updating, and deleting groups. | Stakeholder | Functional | Groups | Must | Approved | ||||||||||||
| 23 | The system shall provide the capability for registered users to create groups within History Hub. | Stakeholder | Functional | Groups | Must | Approved | ||||||||||||
| 24 | The system shall provide the capability for registered users to delete a group within History Hub, if they are the owner of that group. | Stakeholder | Functional | Groups | Must | Approved | ||||||||||||
| 25 | The system shall provide the capability to define group access as open to all registered and unregistered users. | Stakeholder | Functional | Groups | Must | Approved | ||||||||||||
| 26 | The system shall provide the capability to define group access by invitation only, with all group members and content visible via a search. | Stakeholder | Functional | Groups | Must | Approved | ||||||||||||
| 27 | The system shall provide the capability to define group access by invitation only, with all group members and content hidden via a search. | Stakeholder | Functional | Groups | Must | Approved | ||||||||||||
| 28 | The system shall provide the capability for groups to manage calendars. | Stakeholder | Functional | Groups | Should | Approved | ||||||||||||
| 29 | The system shall provide the capability to support user group blogs. | Stakeholder | Functional | Groups | Must | Approved | ||||||||||||
| 30 | The system shall provide the capability for registered users to customize a group's settings and overview page, if they are the owner of that group. | Stakeholder | Functional | Groups | Should | Approved | ||||||||||||
| 31 | The system shall provide the capability for registered users to request to join a group. | Stakeholder | Functional | Groups | Must | Approved | ||||||||||||
| 32 | The system shall provide the capability for registered users to accept or deny a request to join a group, if they are the owner of that group. | Stakeholder | Functional | Groups | Must | Approved | ||||||||||||
| 33 | The system shall be available via a mobile device app. | Stakeholder | Functional | Mobile Access | Should | Approved | ||||||||||||
| 34 | The system shall send a notification to a registered user when content followed by the user is updated within History Hub. | Stakeholder | Functional | Notifications | Should | Approved | ||||||||||||
| 35 | The system shall provide the capability for an Application Administrator to add, update, and delete user profiles. | Stakeholder | Functional | Profile Pages | Must | Approved | ||||||||||||
| 36 | The system shall provide the capability for an Application Administrator to add, update, and delete the display of user profile images. | Stakeholder | Functional | Profile Pages | Must | Approved | Profile images are user 'headshots' or profile pictures. | |||||||||||
| 37 | The system shall provide the capability for an Application Administrator to add, update, and delete the contact information from a user profile. | Stakeholder | Functional | Profile Pages | Must | Approved | ||||||||||||
| 38 | The system shall provide the capability for an Application Administrator to add, update, and delete the groups and contacts associated with a user's profile. | Stakeholder | Functional | Profile Pages | Must | Approved | ||||||||||||
| 39 | The system shall provide the capability for a registered user to add, change, and delete content within their user profile, including their contact information. | Stakeholder | Functional | Profile Pages | Must | Approved | Registered users can 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.) | |||||||||||
| 40 | The system provide the capability for a registered user to upload and display profile images for their user profile. | Stakeholder | Functional | Profile Pages | Should | Approved | Profile images are user 'headshots' or profile pictures. | |||||||||||
| 41 | The system shall provide the capability for a registered user to enter and update contact information within their user profile. | Stakeholder | Functional | Profile Pages | Must | Approved | ||||||||||||
| 42 | The system shall provide the capability for a registered user to associate their user profile with organizations, working groups, business functions, and other registered users within History Hub. | Stakeholder | Functional | Profile Pages | Should | Approved | ||||||||||||
| 43 | The system shall provide the capability for registered users to define who can see elements of their profile information. | Stakeholder | Functional | Profile Pages | Must | 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 user name will always be visible to other registered users. | |||||||||||
| 44 | The system shall display a summary of a registered user's History Hub activities in their profile page. | Stakeholder | Functional | Profile Pages | Should | Approved | ||||||||||||
| 45 | The shall display a summary of a registered user's contributed content in their profile page. | Stakeholder | Functional | Profile Pages | Must | Approved | ||||||||||||
| 46 | The system shall display a registered user's connections and groups in their profile page. | Stakeholder | Functional | Profile Pages | Should | Approved | ||||||||||||
| 47 | The system shall provide the capability for registered users to assign a value for rating content within History Hub. | Stakeholder | Functional | Rating | 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. | |||||||||||
| 48 | The system shall provide the capability for an Application Administrator to generate standard and ad hoc reports. | Stakeholder | Functional | Reporting | Must | Approved | ||||||||||||
| 49 | The system shall provide the capability for all users to search on content within History Hub. | Stakeholder | Functional | Search | Must | Approved | ||||||||||||
| 50 | The system shall display search results based on a user's role, permissions, and group membership within History Hub. | Stakeholder | Functional | Search | Must | Approved | Search results must respect access rights. | |||||||||||
| 51 | The system shall provide the capability for all users to filter on search results. | Stakeholder | Functional | Search | Must | Approved | Filtering is the ability to refine and get a subset of search results based on the groups, people, or type of content associated with the search results. | |||||||||||
| 52 | When performing a search on tags, the system shall return search results based on keyword matching. | Stakeholder | Functional | 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. | |||||||||||
| 53 | The system shall provide the capability for registered users to share items of interest within History Hub and outside of History Hub. | Stakeholder | Functional | Social Bookmarking | Must | Approved | Sharing consists of sharing a link (URL) to content inside History Hub (e.g., a blog post) or content outside History Hub (e.g., an article on the internet.) | |||||||||||
| 54 | The system shall provide the capability for registered users to tag content within History Hub. | Stakeholder | Functional | Tagging | Must | Approved | Tagging will consist of allowing users to assign keywords, terms or metadata to a piece of information. | |||||||||||
| 55 | The system shall provide the capability for registered users to enter tags as free text or by selecting from an administered pick list. | Stakeholder | Functional | Tagging | Should | Approved | ||||||||||||
| 56 | 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 | Tagging | Should | Approved | ||||||||||||
| 57 | The system user interface shall be responsive for use of History Hub on mobile devices. | Stakeholder | Functional | UI/Mobile Access | Must | Approved | The History Hub should be accessible via Android, iOS, and Windows devices. | |||||||||||
| 58 | The system user interface shall provide the capability for registered users to view, post and reply to content within History Hub via a mobile device. | Stakeholder | Functional | UI/Mobile Access | Must | Approved | ||||||||||||
| 59 | The system user interface shall provide the capability for registered users to follow groups, registered users, or content within History Hub. | Stakeholder | Functional | User Interface | Should | Approved | ||||||||||||
| 60 | The system user interface shall provide the capability for registered users to unfollow groups, registered users, or content within History Hub. | Stakeholder | Functional | User Interface | Should | Approved | ||||||||||||
| 61 | The system user interface shall display an activity stream based on updates to a registered user's groups, content, or followed users. | Stakeholder | Functional | User Interface | Should | Approved | A personalized activity stream, similar to Facebook, that displays updates that occur to the groups, content or contacts associated with a registered user's profile. | |||||||||||
| 62 | The system shall be a web-based Software-as-a-Service (SaaS) solution. | Stakeholder | Constraint | Hosting | Must | Approved | ||||||||||||
| 63 | The system user interface shall comply with the Section 508 Standards for Electronic and Information Technology as defined in the Contractor submitted and Government accepted Government Product Accessibility Template. | Stakeholder | Constraint | Usability | Must | Approved | ||||||||||||
| 64 | The system shall be compatible with the current and the one (1) prior version of Chrome, Internet Explorer, Firefox, Safari, and Microsoft Edge web browsers. | Stakeholder | Constraint | Web Browser Compatibility | Must | Approved | ||||||||||||
| 65 | The system shall be IPv6 compliant. | Stakeholder | Constraint | Web Browser Compatibility | Must | Approved | ||||||||||||
| 66 | The system shall be 99% available, 24 hours a day, 7 days a week, with the exception of scheduled maintenance downtime. | Stakeholder | Non-functional | Availability | Must | Approved | This will enable records to be accessible for agency responsiveness to discovery, FOIA, Privacy Act, or other access requests. | |||||||||||
| 67 | The system shall provide the capability for backup and recovery of the system. | Stakeholder | Non-functional | Backup and Recovery | Must | Approved | ||||||||||||
| 68 | The system shall support the bulk import of all data from the existing History Hub system to the new History Hub system. | Stakeholder | Non-functional | Data Transfer | Must | Approved | This includes user accounts and user profile information, established groups and membership data, and all contributed/posted content. | |||||||||||
| 69 | The system shall support unlimited page views. | Stakeholder | Non-functional | Performance | Must | Approved | ||||||||||||
| 70 | The system shall be capable of supporting at a minimum one million (1,000,0000) user accounts. | Stakeholder | Non-functional | Performance | Must | Approved | ||||||||||||
| 71 | The system shall be in compliance with NARA IT Security Contractual Requirements. | Stakeholder | Non-functional | Security | Must | Approved | ||||||||||||
| 72 | The system shall provide secure application access and data transport. | Stakeholder | Non-functional | Security | Must | Approved | Secure access and data transport can be achieved via Secure Socket Layer (SSL). | |||||||||||
| 73 | The system shall prevent unauthorized access to the administration functions of the History Hub. | Stakeholder | Non-functional | Security | Must | Approved | Administrative access is restricted to NARA Application Administrators and vendor System Administrators. Administrative functions include system configuration and account management tasks. |
&"+,Bold"&10History Hub (HH) Requirements Verification Traceability Matrix (RVTM)
&"+,Regular"&10&F &"+,Regular"&10Page &P of &N
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 .