PWS Appendix 3, StRS_ICN_v1.1_FINAL Redacted.docx
DOCX document 85 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 | |
| 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 | ||
| StRS,_RVTM_-_Contractor_Technical_Response_Worksheet,_ICN.xlsx | XLSX spreadsheet | |
| StRS,_RVTM_Contractor_Technical_Response_Worksheet,_HH.xlsx | XLSX spreadsheet | |
| PWS Appendix 4, StRS_HistoryHub_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 |
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
Internal Collaboration Network (ICN) Stakeholder Requirements Specification (StRS)
STAKEHOLDER REQUIREMENTS SPECIFICATION
(STRS)
NARA INTERNAL COLLABORATION NETWORK (ICN)
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 the NARA Internal Collaboration Network (ICN). 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 and Records Administration (NARA) has a need to migrate and support an enterprise-wide Internal Collaboration Network (ICN) that uses web-based social media software to enable its employees to better communicate, collaborate, and build communities. The ICN has features similar to that of other popular social networks, such as Facebook and LinkedIn; however, it has been implemented with the communication, workflow, document organization, and security capabilities that allow NARA employees to collaborate throughout the entire organization.
The purpose of this document is to address the key features identified to support the migration and ongoing support of the ICN.
1.2 Scope
The ICN serves as a platform for NARA employees that are dispersed throughout the nation to exchange information and share knowledge. Through its use, the ICN allows NARA to preserve and capture the expertise of its long-serving staff, create a centralized location where information is searchable and accessible, and most importantly, build a network amongst staff who serve as subject matter experts throughout the agency. The goal of implementing an ICN has been to enable NARA employees to collaborate in a way that provides tangible benefits to the agency, while facilitating achievement of agency objectives.
This document provides the high-level, functional and non-functional stakeholder requirements describing the capabilities and functionality of the ICN.
1.2.1 Assumptions
The following assumptions pertain to the contents of this document in general and to the requirements specifically:
· The ICN will be implemented as a web-based, Commercial-Off-The-Shelf (COTS) solution.
· The ICN will be implemented as a Software-as-a-Service (SaaS) solution with no hardware required at NARA locations.
· The ICN will be configured, hosted, and support, at a minimum, all current existing ICN functional features.
· Data from the existing ICN solution will be migrated to the new ICN system.
References This section lists the “documents” that were utilized during the refinement of the ICN 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. NARA Capital Planning (CPIC) Small Investment Business Case for the ICN, NARA; 10/28/2010.
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 805: 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 (IQS); 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 ICN project and describes its business context.
Business Purpose The National Archives and Records Administration (NARA) is an independent Federal Agency whose mission is to preserve and provide ready access to records of the Federal Government. The purpose of this acquisition is to procure the software and services to continue operating NARA’s enterprise-wide, social media-based Internal Collaboration Network (ICN). This system contributes to the success of NARA’s mission by:
| • | Unifying NARA staff throughout more than 40 facilities nationwide; |
| • | Retaining knowledge of retiring and departing staff; |
| • | Using flexible and adaptable technology to address the business needs of staff; |
| • | Encouraging technical innovation; |
| • | Providing wider access to staff knowledge and expertise; and |
| • | Using relatively inexpensive technology to address budget challenges. |
The ICN helps NARA staff to connect, collaborate, and communicate more effectively, which in turn will help the National Archives rise to meet the challenges it faces.
Business Scope The ICN helps NARA promote a culture that is focused on high-touch engagement and collaboration for the knowledge sharing, such as, circulation of ideas and conversations with subject matter experts and lessons learned. Internal collaboration enables employees to enhance communication, and improve productivity through document and file sharing, discussions, and social networking.
The ICN enables NARA staff to:
| • | Create professional profile pages |
| • | Tag profiles with areas of expertise (professional and vocational) |
| • | Establish internal contacts to allow for collaboration and quicker response to customers |
| • | Create collaborative workspaces |
| • | Notify managers and other NARA staff of the status of individual and collaborative projects |
| • | Engage in cross-agency discussions |
| • | Manage projects |
| • | Create internal blogs (team and individual) |
| • | Collaborate on shared documents |
| • | Create team calendars |
| • | Share files |
| • | Create and manage polls |
| • | Make announcements |
| • | Create social bookmarks |
| • | Rate content |
| • | Generate standard and ad hoc reports |
| • | Integrate user experience into a mobile platform |
| • | Comprehensively search ICN interactions to find relevant information and contacts |
When more information is exchanged between staff, it fosters an environment for perpetual growth and learning opportunities. In addition, when more perspectives are shared and subject matter experts are available to participate in the process, better and faster decisions are made.
Using the ICN, NARA will increase team productivity by leveraging subject matter knowledge that exists within the enterprise and thus reduce the time needed to make informed decisions. This will allow NARA to be more competitive and do things faster and more efficiently. Increased efficiency will save time and money, which are challenges that most federal agencies are trying to overcome.
Stakeholders The primary stakeholders of the ICN program are described in the table below.
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 ICN 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 ICN system and is responsible for user account management, reporting, and other administrative tasks. |
| External User |
| A user with an ICN account who is not a NARA employee, and who utilizes the system to view and generate content, posts, and discussions within the groups that are restricted to their access. |
| Registered User |
| A NARA employee with an ICN account who utilizes the system to generate and manage content, posts, and discussions. |
| System Administrator |
| A person who is responsible for the upkeep, configuration, and reliable operation of the ICN. A System Administrator may generally perform any function in the ICN without any access restrictions (i.e., having "root access") for all domains. |
Stakeholder Requirements This section describes how the ICN 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 ICN.
1.3.1 Types
One type of requirement is identified for the ICN, as specified in Table 3-1.
Table 31: Types 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 of requirements are identified for the ICN, 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 ICN 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 "Stakeholder" or “System.” Refer to Table 31.
· Category The category of the requirement, such as "Functional", “Constraint” 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 stakeholder requirement, such as “Approved” or “Obsolete”.
· Source The source of the stakeholder requirement, such as “Statement of Work” or "Business Case".
· 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') |
| ICN |
| Internal Collaboration Network |
| 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 |
ICN_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 the Internal Collaboration Network (ICN.) Stakeholder Functional Account Management Must Approved
3 The system shall provide the capability for registered users to create announcements. Stakeholder Functional Announcements Must Approved These announcements differ from blogs as they are a "one-time" broadcast.
4 The system shall provide the capability to display announcements across the ICN or within a group in the ICN. Stakeholder Functional Announcements Must Approved
5 The system shall provide the capability for registered users to upload artifacts within the ICN. Stakeholder Functional Attachments Must Approved At a minimum the following formats need to be supported for uploaded attachments: Microsoft Word (.doc/.docx), Microsoft Excel (.xls/.xlsx), Microsoft PowerPoint (.ppt/.pptx), .pdf, jpg, .tif, and .bmp.
6 The system shall provide the capability for registered users to download artifacts within the ICN. Stakeholder Functional Attachments Must Approved
7 The system shall provide the capability for an Application Administrator to specify the file size limitation for uploaded attachments within the ICN. Stakeholder Functional Attachments Must Approved
8 The system shall provide the capability for registered users to tag another registered user within the ICN as a connection. Stakeholder Functional Contacts Must Approved
9 The system shall provide the capability for registered users to send a direct message to other registered users within the ICN. Stakeholder Functional Contacts Must Approved
10 The system shall provide the capability for registered users to follow and unfollow other registered users within the ICN. Stakeholder Functional Contacts Must Approved This is a feature similar to adding a friend in Facebook.
11 The system shall provide the capability for registered users to create content within the ICN. Stakeholder Functional Content Management Must Approved
12 The system shall provide the capability for registered users to view content within the ICN. Stakeholder Functional Content Management Must Approved
13 The system shall provide the capability for registered users to create a private document. Stakeholder Functional Content Management Must Approved
14 The system shall provide the capability for registered users to create a document visible to only select users. Stakeholder Functional Content Management Must Approved
15 The system shall provide the capability for registered users to create a document visible to all registered users in the ICN. Stakeholder Functional Content Management Must Approved
16 The system shall provide the capability to embed photos and videos in documents. Stakeholder Functional Content Management Must Approved
17 The system shall provide the capability for groups to collaborate on documents. Stakeholder Functional Content Management Must Approved
18 The system shall provide the capability to restrict what registered users can edit a document. Stakeholder Functional Content Management Must Approved
19 The system shall provide the capability to prevent users from commenting on a document. Stakeholder Functional Content Management Must Approved
20 The system shall provide the capability for a registered user to create a personal task and assign a due date. Stakeholder Functional Content Management Must Approved A personal task is not associated with a particular project.
21 The system shall provide the capability for a registered user to create an idea for other registered users to view and vote on. Stakeholder Functional Content Management Must Approved
22 The system shall provide the capability for a registered user to create content in the ICN via their NARA email account. Stakeholder Functional Content Management Must Approved Creating content via email includes sending a status update; creating personal tasks, bookmarks, a private document, a private discussion, or a private idea; and responding to discussions.
23 The system shall provide the capability for external users to create content within the groups that are restricted to their access. Stakeholder Functional Content Management Should Deferred
24 The system shall provide the capability for external users to view content within the groups that are restricted to their access. Stakeholder Functional Content Management Should Deferred
25 The system shall provide the capability for registered users to create a private discussion thread. Stakeholder Functional Discussion/Forums Must Approved
26 The system shall provide the capability for registered users to create an open (i.e., not private) discussion thread. Stakeholder Functional Discussion/Forums Must Approved
27 The system shall provide the capability for registered users to post comments or questions via a discussion thread. Stakeholder Functional Discussion/Forums Must Approved
28 The system shall provide the capability for registered users to respond to a post within a discussion thread. Stakeholder Functional Discussion/Forums Must Approved
29 The system shall provide the capability for registered users to view initial posts and responses to discussion threads. Stakeholder Functional Discussion/Forums Must Approved
30 The system shall provide the capability for external users to post comments or questions via a discussion thread within the groups that are restricted to their access. Stakeholder Functional Discussion/Forums Should Deferred
31 The system shall provide the capability for external users to respond to a post within a discussion thread within the groups that are restricted to their access. Stakeholder Functional Discussion/Forums Should Deferred
32 The system shall provide the capability to create a workspace that allows multiple registered users to collaborate on the same project or document within a group. Stakeholder Functional Document Collaboration Must Approved
33 The system shall provide the capability for registered users to create a document and enable or disable collaborators' editing permissions at the page level. Stakeholder Functional Document Collaboration Must Approved Editing permissions are those related to the add, update, delete capabilities at the page and/or document level.
34 The system shall provide the capability for registered users to create a document and enable or disable collaborators' editing permissions at the document level. Stakeholder Functional Document Collaboration Must Approved
35 The system shall have the ability to export content in .pdf format. Stakeholder Functional Export Must Approved
36 The system shall provide the capability for registered users to flag ICN content for abuse. Stakeholder Functional Flag Content Must Approved
37 The system shall send an alert to Application Administrators when content is flagged. Stakeholder Functional Flag Content Must Approved
38 The system shall provide the capability for registered users to create groups within the ICN. Stakeholder Functional Groups Must Approved
39 The system shall provide the capability for registered users to delete a group within the ICN, if they are the owner of that group. Stakeholder Functional Groups Must Approved
40 The system shall provide the capability for Application Administrators to manage groups within the ICN, including creating, updating, and deleting groups. Stakeholder Functional Groups Must Approved
41 The system shall provide the capability to define group access as open to all registered users. Stakeholder Functional Groups Must Approved
42 The system shall provide the capability to define group access as open by invitation only, with all group members and content visible via a search. Stakeholder Functional Groups Must Approved
43 The system shall provide the capability to define group access as private and by invitation only, with all group members and content hidden via a search. Stakeholder Functional Groups Must Approved
44 The system shall provide the capability for groups to manage calendars. Stakeholder Functional Groups Must Approved
45 The system shall provide the capability for groups to manage tasks. Stakeholder Functional Groups Must Approved
46 The system shall provide the capability to support user group blogs. Stakeholder Functional Groups Must Approved
47 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 Must Approved
48 The system shall provide the capability for registered users to request to join a group. Stakeholder Functional Groups Must Approved
49 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
50 The system shall allow registered users to generate and display a status message. Stakeholder Functional Microblogging/Status Updates Must Approved
51 The system shall provide the capability for registered users to display a status message to all registered users or a sub-set of selected registered users. Stakeholder Functional Microblogging/Status Updates Must Approved
52 The system shall send a notification to a registered user when content followed by the user is updated within the ICN. Stakeholder Functional Notifications Must Approved
53 The system shall provide the capability for registered users to create a personal blog. Stakeholder Functional Personal Blogs Must Approved
54 The system shall provide the capability for registered users to generate a poll. Stakeholder Functional Polls Must Approved
55 The system shall provide the capability for registered users to vote on poll content. Stakeholder Functional Polls Must Approved
56 The system shall provide the capability for registered users to provide text-based responses on poll content. Stakeholder Functional Polls Must Approved
57 The system shall provide the capability for an Application Administrator to add, update, and delete user profiles. Stakeholder Functional Profile Pages Must Approved
58 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.
59 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
60 The system shall provide the capability for an Application Administrator to add, update, and delete the organizations, working groups, business functions and contacts associated with a user's profile. Stakeholder Functional Profile Pages Must Approved
61 The system shall provide the capability for an Application Administrator to define the organizational relationships between user profiles. Stakeholder Functional Profile Pages Must Approved Organizational relationships pertain to a user's manager/supervisor, division/branch chief, subordinates.
62 The system shall provide the capability for registered users to upload and display a profile image for their user profile. Stakeholder Functional Profile Pages Must Approved Profile images are user 'headshots' or profile pictures.
63 The system shall provide the capability for registered users to enter and update contact information within their user profile. Stakeholder Functional Profile Pages Must Approved
64 The system shall provide the capability for registered users to delete elements of the contact information within their user profile. Stakeholder Functional Profile Pages Must Approved Registered users can delete most contact information themselves, but they cannot delete their name and email address (i.e., cannot delete their entire user profile from the system.)
65 The system shall provide the capability for registered users to associate their user profile with organizations, working groups, business functions, and other registered users within the ICN. Stakeholder Functional Profile Pages Must Approved
66 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 some portions of their user profile (i.e., make it private and not be displayed), but their name and email address will always be visible.
67 The system shall display a summary of a registered user's ICN activities in their profile page. Stakeholder Functional Profile Pages Must Approved
68 The system shall display a summary of a registered user's contributed ICN content in their profile page. Stakeholder Functional Profile Pages Must Approved
69 The system shall display a registered user's connections, groups, tasks, and bookmarks in their profile page. Stakeholder Functional Profile Pages Must Approved
70 The system shall provide the capability for registered users to create and describe projects and their associated timelines. Stakeholder Functional Project Management Must Approved
71 The system shall provide the capability for registered users to track and assign their own project tasks and sub-tasks, as well as, for other registered users. Stakeholder Functional Project Management Must Approved
72 The system shall provide the capability to assign a value for rating content within the ICN. Stakeholder Functional Rating Must 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.
73 The system shall provide the capability for an Application Administrator to generate standard and ad hoc reports. Stakeholder Functional Reporting Must Approved
74 The system shall provide the capability for registered users to generate standard and ad hoc reports. Stakeholder Functional Reporting Must Approved
75 The system shall provide the capability for registered users to search on content within the ICN. Stakeholder Functional Search Must Approved
76 The system shall display search results based on a user's role, permissions, and group membership within the ICN. Stakeholder Functional Search Must Approved Search results must respect access rights.
77 The system shall provide the capability for registered 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.
78 When performing a search on tags, the system shall return search results based on keyword matching. Stakeholder Functional Search Must Approved Tag meanings shall be combined so that "web," "web site," and "website" (for example) will all be returned on a search for any one of these keywords.
79 The system shall provide the capability for registered users to share items of interest within the ICN and outside of the ICN. Stakeholder Functional Social Bookmarking Must Approved Sharing consists of sharing a link (URL) to content inside the ICN (e.g., a blog post) or content outside the ICN (e.g., an article on the internet.)
80 The system shall provide the capability for registered users to tag content within the ICN. Stakeholder Functional Tagging Must Approved Tagging will consist of allowing users to assign keywords, terms, or metadata to a piece of information.
81 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 Must Approved
82 The system shall provide the capability for registered users to specify categories to be applied to content within their group. Stakeholder Functional Tagging Must Approved Categories are created by a group owner/administrator and can be selected when content is created or added later. Categories are used to group content that falls under the same topic.
83 The system user interface shall be responsive for use of the ICN on mobile devices. Stakeholder Functional UI/Mobile Access Must Approved The ICN should be accessible via Android, iOS, and Windows devices.
84 The system user interface shall provide the capability for registered users to view, post and reply to content within the ICN via a mobile device. Stakeholder Functional UI/Mobile Access Must Approved
85 The system user interface shall provide the capability for registered users to follow groups, registered users, or content within the ICN. Stakeholder Functional User Interface Must Approved
86 The system user interface shall provide the capability for registered users to unfollow groups, registered users, or content within the ICN. Stakeholder Functional User Interface Must Approved
87 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 Must 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.
88 The system user interface shall display trending content and trending people to show the most active content and people in the ICN. Stakeholder Functional User Interface Must Approved
89 The system shall be a web-based Software-as-a-Service (SaaS) solution. Stakeholder Constraint Hosting Must Approved
90 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
91 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
92 The system shall be IPv6 compliant. Stakeholder Constraint Web Browser Compatibility Must Approved
93 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.
94 The system shall provide the capability for backup and recovery of the system. Stakeholder Non-functional Backup and Recovery Must Approved
95 The system shall support the bulk import of all data from the legacy ICN system to the new ICN 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.
Note: The current backend database for ICN on the Jive platform is Oracle.
96 The system shall be capable of integrating with Google Docs. Stakeholder Non-functional Integration Should Approved
97 The system shall provide the capability to assign metadata and maintain links between the content and its metadata. Stakeholder Non-functional Metadata Assignment Must Approved This includes user applied tags and metadata automatically attributed from the creator’s user and/or group profile.
98 The system shall support a minimum of 3,500 users. Stakeholder Non-functional Performance Must Approved
99 The system shall be capable of expanding support up to 5,000 users without system performance degradation. Stakeholder Non-functional Performance Must Approved
100 The system shall be in compliance with NARA IT Security Contractual Requirements. Stakeholder Non-functional Security Must Approved
101 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).
102 The system shall be capable of using NARA’s identity management and authentication service for access control. Stakeholder Non-functional Security Must Approved
103 The system shall be capable of restricting access on the basis of Internet Protocol (IP) addresses. Stakeholder Non-functional Security Must Approved
104 The system shall prevent unauthorized access to the administration functions of the ICN. 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"&10Internal Collaboration Network (ICN) 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 .