PWS Appendix 4, StRS_HistoryHub_v1.1_FINAL Redacted.docx
DOCX document 83 KB Posted
- Attached to
- Internal Collaboration Network and History Hub
- Solicitation number
- NAMA-17-R-0001
About this file
Not Listed
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 | |
| StRS,_RVTM_-_Contractor_Technical_Response_Worksheet,_ICN.xlsx | XLSX spreadsheet | |
| StRS,_RVTM_Contractor_Technical_Response_Worksheet,_HH.xlsx | XLSX spreadsheet | |
| 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 | |
| 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
History Hub (HH) Stakeholder Requirements Specification (StRS)
STAKEHOLDER REQUIREMENTS SPECIFICATION
(STRS)
HISTORY HUB,
NARA’S EXTERNAL COLLABORATION NETWORK (ECN)
Version 1.1 FINAL Prepared by NARA IQ Requirements Team January 13, 2017
Signature Page
[REDACTED]
Table of Contents
| 1 | Introduction | 5 |
| 1.1 | Purpose | 5 |
| 1.2 | Scope | 5 |
| 1.2.1 | Assumptions | 5 |
| 1.3 | References | 5 |
| 1.3.1 | Compliance | 6 |
| 1.3.2 | Guidance | 6 |
| 2 | Business Abstract | 7 |
| 2.1 | Business Purpose | 7 |
| 2.2 | Business Scope | 7 |
| 2.3 | Stakeholders | 8 |
| 2.4 | User Roles and Characteristics | 9 |
| 3 | Stakeholder Requirements | 10 |
| 3.1 | Attributes | 10 |
| 3.1.1 | Types | 10 |
| 3.1.2 | Categories | 10 |
| 3.2 | Requirements | 10 |
| Appendix A – Glossary | 13 |
Revision History
| Date |
| Version |
| Author |
| Revision Description |
| 11/17/2016 |
| 1.0 |
| NARA IQ Team |
| Initial version |
| 01/13/2017 |
| 1.1 |
| NARA IQ Team |
| Updated Section 508 requirement with revised language provided by NARA Acquisitions. |
1 Introduction This section introduces the Stakeholder Requirements Specification (StRS) for an External Collaboration Network (ECN), referred to in this document as the History Hub. It discusses the purpose, scope and content of the document and provides an overview of the functionality that is addressed by the requirements.
1.1 Purpose
The National Archives, in an effort to engage the public, specifically those members with an interest in American history, genealogy, and its records, has established an External Collaboration Network (ECN), known as History Hub, which promotes communication between public researchers and NARA staff. The purpose of the History Hub is to support the public interest in historical questions, achieve agency mission goals, and allow the public to connect to and communicate more effectively with NARA subject matter experts, as well as experts from other cultural institutions.
The purpose of this document is to address the key features of the History Hub that serve as a foundation of the standard capabilities defined for the system.
1.2 Scope
The History Hub helps NARA engage with the public and provides wider access to staff knowledge and expertise. Through its use, the History Hub enables NARA staff, staff from other cultural institutions, and public researchers, who obtain History Hub accounts, the ability to create History Hub content. The content consists of user groups, profiles, discussion forums, tagging, blogs, collaborative documents, file sharing, polls, calendars, tasks, and announcements. This information is made viewable to the general public via the web.
This document provides the high-level, functional and non-functional stakeholder requirements describing the capabilities and functionality of the History Hub.
1.2.1 Assumptions
The following assumptions pertain to the contents of this document in general and to the requirements specifically:
· The History Hub will be a cloud-based Software as a Service (SaaS) solution made accessible via the web.
· Data from the current History Hub solution will be migrated to the full production system.
References This section lists the “documents” that were utilized during the refinement of the History Hub stakeholder requirements. It consists of two sub-sections, “Compliance” and “Guidance”. The documents listed under “Compliance” directly influenced the content of the stakeholder requirements (i.e., they contain requirements); the documents listed under “Guidance” contain information pertinent to the stakeholder requirements but do not themselves contain requirements.
Compliance 1.3.1-1. History Hub Business Case Version 4.2; NARA; 03/07/2016.
1.3.1-2. Section 508 of the Rehabilitation Act (29 U.S.C. '794 d), as amended by the Workforce Investment Act of 1998 (P.L. 105 - 220), August 7, 1998 (original source in uscode.house.gov); United States Federal Government; 8/7/1998; http://www.section508.gov/.
1.3.1-3. NARA Standard IT Security Contractual Requirements; NARA; 6/2016.
Guidance 1.3.2-1. NARA Systems Development Life Cycle (SDLC) Methodology Version 1.6; NARA; 11/27/2013.
1.3.2-2. NARA Enterprise Requirements Program Management Plan Version 2.0; NARA (IQ); 9/29/2015.
1.3.2-3. NARA 804: Information Technology System Security, NARA IT Security Requirements; Version 6.0; NARA; 11/10/2014.
1.3.2-4. International Standard ISO/IEC/IEEE 29148:2011(E): Systems and software engineering —Life cycle processes — Requirements engineering; Institute of Electrical and Electronics Engineers, Inc. (IEEE); 12/1/2011.
Business Abstract This section introduces the History Hub project and describes its business context.
Business Purpose The National Archives and Records Administration (NARA) is an independent Federal agency that helps safeguard and preserve our nation's history by overseeing the management of all Federal records. NARA’s mission is to ensure ready access to the essential evidence that documents the rights of American citizens, the actions of Federal officials, and the national experience. In order to further its mission, NARA is seeking a cost effective, flexible, and adaptable system to address the business needs of staff and the research needs of the public. As a result, a web-based External Collaboration Network (ECN), known as History Hub (HH), was developed to encourage technical innovation and provide wider access to the knowledge of subject matter experts.
The goal of the History Hub is to allow NARA to more effectively communicate and connect with the public and subject matter experts within and outside of NARA. The History Hub provides a government-sponsored platform for crowd-sourced information with subject matter experts. In addition, the History Hub supports NARA’s strategic goals in order to:
· Make Access Happen – The History Hub serves as a platform for crowd-sourcing information that allows the public to have access to information from multiple major cultural and historical institutions and libraries in one place.
· Connect with Customers – The History Hub allows researchers and citizens the ability to access and contribute content, as well as collaborate with each other and NARA internal subject matter experts, which may continuously add to and improve the knowledge base.
Business Scope In an effort to increase the public’s understanding of NARA and its relationship with other Federal cultural and historical institutions and libraries, NARA requested the development of an ECN, known as History Hub (HH). In early 2016, NARA launched a pilot of the History Hub in an effort to determine the public’s interest in an online external community where they could pose questions, formulate discussions, access and contribute content, as well as interact with NARA internal subject matter experts. The pilot proved successful, acquiring over six hundred (600) registered users within the first two months of its release, thus enabling the public the ability to pose questions and allowing NARA staff to more accurately respond within a timely fashion.
For this reason, NARA requested the development of a production ECN (i.e., History Hub) to serve as a ‘go-to’ resource for the general public, researchers, and subject matter experts (SMEs) to communicate with NARA staff and other federal cultural and historical institutions and libraries.
The scope of this project consists of the following:
· Hosting the History Hub system as well as the support of unlimited page views
· Designing and configuring a History Hub production instance that aligns to the stakeholder requirements defined in Section 3 of this document, as well as, support a seamless transition of the data within the current pilot instance to the new production instance
· The solution should also adhere to the following business requirements:
· Create a knowledge base that effectively captures, develops, shares and preserves organizational knowledge
· Allow researchers and citizens the ability to search, access and contribute content, as well as collaborate with each other and internal and external subject matter experts
· Allow the public to have easy access to information from multiple major cultural and historical institutions and libraries.
Stakeholders Table 2-1 below lists the stakeholders and describes how they may influence the project and how the project may impact them.
Table 21: Stakeholders – Individuals
| Name |
| Organization |
| Type |
| Main Interests |
| Impact of Project |
| [REDACTED] |
| Office of Innovation (V) |
| Primary |
| Oversees digital access and digitization, web and social media development, and enterprise lifecycle and description standards across the agency. |
| Ability to meet agency reporting requirements, meet strategic goals, and improve services to staff and the public. |
| [REDACTED] |
| Digital Engagement Division, Office of Innovation (VE) |
| Primary |
| Oversees online access, web and social media development, and enterprise lifecycle and description standards. |
| Ability to meet agency reporting requirements, meet strategic goals, and improve services to staff and the public. |
| [REDACTED] |
| Web and Social Media Branch, Office of Innovation (VES) |
| Primary |
| Responsible for online community management |
| More efficient, useful, and pleasant experience for public and staff users of the National Archives online community resources. |
| [REDACTED] |
| Project Management Division, Office of Innovation (VM) |
| Primary |
| Project Management |
| Project success |
| [REDACTED] |
| IT Project Management Branch, Office of Information Services (IPJ) |
| Primary |
| Project within cost, schedule, and performance criteria |
| Project success |
| [REDACTED] |
| IT Program Management Branch, Office of Information Services (IPG) |
| Primary |
| Project within cost, schedule, and performance criteria |
| Project success |
| [REDACTED] |
| Requirements Team, Office of Information Services (IQ) |
| Secondary |
| Quality of the requirements |
| Support of IT governance processes |
User Roles and Characteristics The History Hub business roles that are relevant to the stakeholder requirements are specified in Table 2-2.
Table 22: User Roles and Characteristics
| Role |
| Characteristics |
| Application Administrator |
| A person who serves as a technical administrator of the History Hub system and is responsible for user account management, reporting, and other administrative tasks. |
| Authorized User |
| A user who can create announcements, moderate content and comments, and administer groups within History Hub. |
| Insider / Expert |
| A user who is a NARA employee, employee of a federal cultural or historical institution, library, or other professional organization, who has been designated by NARA as an official responder to content posted in History Hub. |
| Registered User |
| A user with a History Hub account who utilizes the system to generate and manage content, posts, and discussions. A person who is a NARA employee, NARA contractor, member of the general public, member of a federal cultural or historical institution, or library. |
| System Administrator |
| A person who is responsible for the upkeep, configuration, and reliable operation of the History Hub. A System Administrator may generally perform any function in the History Hub without any access restrictions (i.e., having "root access") for all domains. |
| Unregistered User |
| A user without a History Hub account who utilizes the system to view content, posts, and discussions. |
Stakeholder Requirements This section describes how the History Hub stakeholder requirements are organized and provides access to the stakeholder requirements via an embedded Microsoft® Excel® object.
1.3 Attributes
This section describes some of the attributes of a stakeholder requirement utilized for the History Hub.
1.3.1 Type
One type of requirement is identified for the History Hub system, as specified in Table 3-1.
Table 31: Type of Requirements
| Category |
| Description |
| Stakeholder |
| Stakeholder requirements define decisions about business needs, goals, and objectives from the perspective of the stakeholders and their role in the business. |
1.3.2 Categories
Three categories are identified for the History Hub system, as specified in Table 3-2.
Table 32: Categories of Requirements
| Category |
| Description |
| Constraints |
| Constraints limit the options open to a designer of a solution by imposing immovable boundaries and limits (e.g., the system shall incorporate a legacy or provided system element, or certain data shall be maintained in an on-line repository). |
| Functional |
| Functional requirements describe the system functions or tasks to be performed. |
| Non-functional |
| Non-functional requirements identify operational or system properties. They define how a system should be. Information Management, Availability, Backup and Recovery, Compatibility, Maintainability, Reliability, Transferability, Performance, Capacity, Scalability, Security, Usability, and Interface requirements are examples of this type. |
1.4 Requirements
The History Hub stakeholder requirements are maintained in a Microsoft® Excel® workbook that is embedded in this document. To view the contents of this workbook, double-click the following icon.
↑ double-click to open ↑ Note: You must have Microsoft Excel 2007 or newer to view the above workbook.
The equivalent “viewing” application may also be used.
This workbook consists of two worksheets:
· Requirements This worksheet contains the stakeholder requirement id (i.e., Req #), requirements text, and related information.
The contents of this worksheet are sorted in ascending order by “Req #”.
· Standard Values This worksheet contains the lists of standard values that are used by the IQ Requirements Team to instantiate drop-down lists for some of the columns of the Requirements worksheet.
The columns in the Requirements worksheet are defined as follows:
· Req # A unique identifier for the requirement.
· Requirement Text The text of the requirement.
· Type The type of the requirement, such as "System" or "Stakeholder". Refer to One type of requirement is identified for the History Hub system, as specified in Table 3-1.
Table 31.
· Category The category of the requirement, such as "Functional" or "Non-functional". Refer to Table 32.
· Feature The high-level function, capability, feature or other grouping that has meaning for the stakeholders.
· Req Priority The priority of the stakeholder requirement as assigned by the stakeholders.
The valid values for this column (MoSCoW) are recorded in Section 6 of Reference 1.3.2-2 and are reproduced below:
Must[footnoteRef:1] requirements that are CRITICAL to meeting the project's objectives [1: Minimal Useable Subset (MUST)]
| Should | requirements that are critical and should be included if possible, but which can be excluded |
| Could | requirements that are part of the project's scope and add or enhance project benefits |
| Would | requirements that do not have a significant impact on project benefits or could be considered as a “would like to have” |
· Status The status of the requirement, such as “Approved” or “Obsolete”.
· Notes Pertinent additional information about the requirement.
For example, it is sometimes very difficult to state a function clearly and precisely without resorting to convoluted and confusing language syntax. In this case, simpler and more easily understood requirement text might be used with additional information under “Notes” which expands upon the intent of the requirement.
Appendix A – Glossary
| Abbreviation |
| Definition |
| BA |
| Business Analysis | Business Analyst |
| e.g. |
| exempli gratia ('for the sake of example') |
| ECN |
| External Collaboration Network |
| HH |
| History Hub |
| i.e. |
| id est ('that is'; 'in other words'; 'that is to say') |
| IEC |
| International Electrotechnical Commission |
| IEEE |
| Institute of Electrical and Electronics Engineers, Inc. |
| Inc. |
| Incorporated |
| IPG |
| [NARA organization] Program Management Branch, Portfolio Management Division |
| IPJ |
| [NARA organization] Project Management Branch, Portfolio Management Division |
| IQ |
| [NARA organization] Requirements Team, Quality Management Division |
| ISO |
| International Organization for Standardization |
| IT |
| Information Technology |
| MoSCoW |
| Must, Should, Could, Would (requirements priorities, in order of decreasing importance or desirability) |
| N/A |
| Not Applicable |
| NARA |
| National Archives and Records Administration |
| PM |
| Project Manager |
| POC |
| Point Of Contact |
| REQ |
| Requirement |
| RVTM |
| Requirements Verification Traceability Matrix |
| SDLC |
| Systems Development Life Cycle |
| StRS |
| Stakeholder Requirements Specification |
| TBD |
| To Be Determined |
| V |
| [NARA Organization] Office of Innovation |
| VE |
| [NARA Organization] Digital Engagement Division, Office of Innovation |
| VES |
| [NARA Organization] Web and Social Media Branch, Office of Innovation |
HistoryHub_RVTM_v1.1_2017Jan13.xlsx Requirements
REQUIREMENTS MISC DESIGN DEVELOPMENT VERIFICATION DEPLOYMENT PREPARATION
| 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 |
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 contractor 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 image1.emf image2.png
File details come from the government source that posted it. Updated .