Appendix 3 - HistoryHub_StRS_v.2.0.docx

NATIONAL ARCHIVES AND RECORDS ADMINISTRATION (NARA)

History Hub (HH) Stakeholder Requirements Specification (StRS)

STAKEHOLDER REQUIREMENTS SPECIFICATION

(STRS)

HISTORY HUB,

NARA’S CROWDSOURCED HISTORY SUPPORT COMMUNITY

Version 2.0 FINAL Prepared by NARA Requirements Management Division (IR) August 30, 2021

Table of Contents

Revision History

1 Introduction This section introduces the Stakeholder Requirements Specification (StRS) for a Crowdsourced History Support Community, 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 a crowdsourced history support community, known as History Hub, which promotes communication between public researchers, NARA staff, and other institutions. The purpose of History Hub is to support the public interest in historical questions and research, reduce NARA’s burden involved in responding to common repetitive requests, 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 History Hub that serve as a foundation of the standard capabilities defined for the system.

1.2 Scope

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 topical communities, user profiles, discussion forums, tagging, blogs, collaborative documents, file sharing, polls, 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 History Hub.

1.2.1 Assumptions

The following assumptions pertain to the contents of this document in general and to the requirements specifically:

· 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.

1.3 References

This section lists the sources 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.

1.3.1 Compliance

1.3.1-1. History Hub Business Case, Version 4.2; NARA; 03/07/2016.

1.3.1-2. History Hub Platform Modernization Business Need, Signed Version; NARA; 05/19/2021.

1.3.1-3. Section 508 of the Rehabilitation Act of 1973, as amended (29 U.S.C. §794 (d)); US Government; 1/03/2012; http://www.section508.gov/.

1.3.1-4. NARA Visual Identity Guide; NARA; 12/18/2019; https://work.nara.gov/nara_policies_and_guidance/directives/0100_series/nara0105.html 1.3.1-5. NARA Website Requirements Checklist; NARA; 03/05/2007; https://work.nara.gov/websites/website-checklist.html 1.3.1-6. Information and Communication Technology (ICT) Standards and Guidelines (82 FR 5790); US Government; 1/18/2017; https://www.gpo.gov/fdsys/granule/FR-2017-01-18/2017-00395.

1.3.1-7. NARA IT Security Requirements, Version 6.18; NARA (IS); 09/12/2019.

1.3.1-8. NARA IT Security Requirements Language for Unclassified Systems, Version 1.2; NARA (IS); 09/13/2017.

1.3.2 Guidance

1.3.2-1. NARA Systems Development Life Cycle (SDLC) Methodology Version 1.6; NARA; 11/27/2013.

1.3.2-2. NARA Requirements Management Plan: Guide to Services, Version 3.4; NARA (IR); 01/20/2021.

1.3.2-3. International Standard ISO/IEC/IEEE 29148:2018(E): Systems and software engineering —Life cycle processes — Requirements engineering; Institute of Electrical and Electronics Engineers, Inc. (IEEE); 11/2018.

1.3.2-4. Non-Functional Requirements Analysis Guidance, Version 1.1; NARA (IR); 11/19/2020.

2 Business Abstract This section introduces the History Hub project and describes its business context.

2.1 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 NARA’s mission, a web-based crowdsourced support community, known as History Hub (HH), was developed to enable technical innovation and provide the public with wider access to subject matter experts at NARA and similar institutions. NARA is seeking a cost effective, flexible, and adaptable system to modernize the History Hub platform and continue to address the business needs of staff and the research needs of the public.

The goal of History Hub is to allow NARA to more effectively communicate and connect with the public and subject matter experts within and outside of NARA. History Hub provides a government-sponsored platform for crowd-sourced information with subject matter experts. In addition, History Hub supports NARA’s strategic goals in order to:

· Make Access Happen – 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 – 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.

2.2 Business Scope

First launched in 2016, NARA’s History Hub is a crowdsourced community platform providing support and guidance for historical and archival research to the general public. The platform enables users to pose questions to NARA staff and subject matter experts (SMEs), staff from other cultural and historical institutions and libraries, professional researchers, as well as other members of the public. All content is publicly browsable and searchable, allowing anyone to benefit from the information contained in past questions and answers, enabling more timely responses to common inquiries, and reducing the burden on NARA staff by eliminating repetitive requests.

To date, History Hub has fielded nearly 10,000 questions, plus associated answers and replies. Almost 30,000 users have registered accounts. The platform saw over 500,000 web visitors in Fiscal Year (FY) 2020 and is projected to see over one million web visitors in FY2021. It had nearly 1.5 million page views in FY2020 and is estimated to have over 2.5 million page views in FY2021.

The scope of this project consists of the following:

· Hosting History Hub system

· Designing and configuring a History Hub production instance that aligns to the stakeholder requirements defined in Section 3 of this document, as well as supporting a seamless migration of the data within the current production instance to the new production instance

· The solution should also adhere to the following business requirements:

· 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

· Create a knowledge base that effectively captures, develops, shares and preserves organizational knowledge

· Provide metrics and analytics as to the use of the platform, content popularity, and relative user satisfaction.

2.3 Stakeholders

The Stakeholders that are relevant to the History Hub requirements are specified in Table 2-1.

Table 2-1: Stakeholders – Organizations

2.4 User Roles and Characteristics

The History Hub business roles that are relevant to the stakeholder requirements are specified in Table 2-2.

Table 2-2: User Roles and Characteristics

3 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.

3.1 Attributes

This section describes the attributes of the stakeholder requirements utilized for History Hub.

3.1.1 Types

One type of requirement is identified for History Hub, as specified in Table 3-1.

Table 3-1: Types of Requirements

3.1.2 Categories

Three categories of requirements are identified for History Hub, as specified in Table 3-2.

Table 3-2: Categories of Requirements

3.1.3 Sub-Categories

Six sub-categories of requirements are identified for History Hub, as specified in Table 3-3.

Table 3-3: Sub-Categories of Requirements

3.1.4 Cascading Drop-Down Lists

The 'Category' and 'Sub-Category' columns of the RVTM are implemented as cascading drop-down lists, which means that the items in the 'Category' and 'Sub-Category' drop-down lists depend upon the value in another column. Simple drop-down lists (such as that implemented for the 'Type' column) and cascading drop-down lists have been implemented in the RVTM to help ensure that consistent values are used for important information. The values used in columns with drop-down lists are restricted to the values in the list.

Table 3-4 below depicts how the cascading drop-down lists are defined in the RVTM.

Table 3-4: Valid Type → Category → Sub-Category Combinations

NA

3.2 Requirements

The History Hub stakeholder requirements are maintained in the RVTM that is embedded in this document. To view the contents of this Microsoft Excel 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 RVTM workbook consists of four worksheets:

· Title Page This worksheet contains the name of the project, version, and revision history of the requirements.

· 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 #”.

Columns with a red header are required attributes. Columns with a blue header are optional attributes.

· Standard Values This worksheet contains the lists of standard values that are used by the Requirements Management Division (IR) to instantiate drop-down lists for some of the columns of the Requirements worksheet.

· Column Descriptions This worksheet contains a description of the columns within the Requirements worksheet including which columns are required for a project.

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 "Business" or "Stakeholder". Refer to Table 3-1.

· Category The category of the requirement, such as "Functional" or "Non-Functional". Refer to Table 3-2.

The category values for a requirement depend upon the 'Type' value for the requirement. Refer to Table 3-4 for a list of valid values.

· Sub-Category The sub-category of the requirement, such as "Usability” or “Performance”. Refer to Table 3-3.

The valid sub-category values for a requirement depend upon the 'Category' value for the requirement. Refer to Table 3-4 for a list of valid values.

· 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:2] 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 [2: Minimal Useable SubseT (MUST)]

· Status The status of the requirement.

The valid values for this column are:

Approved The requirement (and its traceability) has been reviewed and approved for implementation by the appropriate authorities.[footnoteRef:3] [3: A requirement is expected to be "Approved" only after it has completed its final review. What this final review consists of and who the authorities are depends upon the project. The authority would normally be expected to be IR after a quality assessment (when a Requirements Stage Gate [RSG] is not performed) or the RSG Chairperson.]

Deferred The requirement is applicable, but it is considered to be on hold and is not a current target for implementation.[footnoteRef:4] [4: A deferred requirement is an approved requirement that the business stakeholders want but do not currently need. This status is not typically used until after the solution has been implemented; before the solution is implemented, the priority indicates the desirability of a requirement.]

Draft The requirement is under development.[footnoteRef:5] [5: The expectation is that draft requirements will only exist during the requirements development effort: when the StRS / RVTM is final, there should be no draft requirements.]

Obsolete The requirement is no longer needed.[footnoteRef:6] [6: An obsolete requirement is an approved requirement that the business stakeholders decided that they no longer need. This status is not typically used until after the solution has been implemented; before the solution is implemented, the requirement would just be removed / deleted.]

· Target Release The release in which the requirement will be developed. Note that this column may be blank and hidden from view upon the initial documentation of the requirements but should be updated during the appropriate phase of the project.

· Source The source of the stakeholder requirement, such as "Business Case" or "Interview".

· Notes Pertinent additional information about the requirement.

For example, it is sometimes very difficult to state a function clearly and precisely. 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.

Note: There are additional columns in the embedded RVTM to capture the requirements traceability to Design, Development, Verification, and Deployment Preparation (User Acceptance Testing) attributes. These columns will be blank upon the initial documentation of the requirements but should be updated during the appropriate life cycle phases of the project.

Appendix A – Glossary

HistoryHub_StRS_v.2.0_2021Aug30.docx Page 2 of 3 image1.emf

HistoryHub_RVTM_v.2.0_2021Aug30.xlsx Title Page

NATIONAL ARCHIVES AND RECORDS ADMINISTRATION (NARA)

Revision History

Date Version Author Revision Description

08/16/2021 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

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

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 Must 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 Should 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 Must 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…