Content Authoring, Access and User Authentication Model 3

Table of Contents

Contents

Summary 1

Versions 1

Security & Performance 2

Vulnerability Scan Testing 2

Load Testing 2

Performance / Loading Objectives 3

Content Authoring, Access and User Authentication Model 3

Server Infrastructure 4

Development Environment 5

Production Environment 5

Staging Environment 5

Misc. Server Infrastructure Notes 6

Accessibility Requirements 6

Commonwealth of Virginia Requirements 7

Retention Requirements 8

Content Management System 8

Server and Browser Requirements for Episerver 9

Responsive Design 11

Search Functionality 12

Global Search 12

Scoped Search: Department 13

Forms Center 15

Web Forms 17

Polls / Survey Functionality 17

Dynamic Org Chart 17

Analytic Tracking 18

Episerver-specific 18

Google Analytics Functionality 18

Product Catalog Functionality 18

Catalog View 19

Detail View 19

Not Needed for Product Catalogs 19

Variable Management (Optional) 20

Department Contact List Look-up 20

Advisor Lookup Functionality 20

Newsletter Subscriptions & End User Profile Account Management Functionality 21

Newsletter Signup & View Functionality 22

Urgent Alerts System 22

Video Embed Functionality 23

Photo Gallery / Media Library Functionality 23

FAQ Management Functionality 24

Calendar Functionality 24

URL Management 25

For Key Existing URLs: 25

For New URLs: 25

Other General URL and SEO-related Requirements 25

Social Functionality 25

Items Not Needing Requirements 26

Virtual Tour Functionality 26

Online Manuals Functionality 26

©2016 VA DGS. All Rights Reserved. Confidential Materials | Not for Redistribution Page 2

Functional Requirements

Summary

The purpose of this functional requirements document is to define the core requirements for the actual functionality necessary to support the redesigned public web site at the end of 2016. As a starting point, it should be understood that the vast majority of the new VA DGS public web site will be content-oriented. However, there are several areas on the site that go beyond the critical mission of delivering timely content – namely, there is functionality that better allows web site visitors to access this important content, primarily in the search and Forms Center experiences. In addition to these items, there are several other important functionalities to be found on the site, including calendaring, newsletter notifications, product catalog and detail pages for fleet information and surplus properties and more.

Of course, the fundamental role of the redesigned web site will be to better answer customer needs, which means that the majority of the focus of the redesign project will focus on core content delivery, content marketing and related concentrations. The goal of this document is to describe the functionality of the redesigned web site in a way that is easily relatable to non-technical stakeholders. Subsequent documentation will be created that illustrates how this will be accomplished using the CMS platform and related development. The overall user interface, information architecture and related materials may also be found in separate deliverables, including the sitemap, user interface comps, configuration guides and other, related project documentation. One final note: illustrations found in this document are meant only to further convey and clarify functional needs; they are not necessarily representative of the final, expected user interface or experience.

Versions

Version Number and Date
/ Author / Notes
Draft 1.0 – 6/15/2016 / Brian Browning / Initial Draft Version developed; based on functional requirements meetings with web design team, IS team and business stakeholders.
This version will be presented to the VA DGS team on June 15th, 2016 and feedback will be solicited.

Security & Performance

Several security and performance requirements exist for the revised VA DGS site. The overall goal will be to provide a secured environment in which web site visitors feel comfortable with sharing information (in the form of web submissions or social shares) and a browsing experience that is perceived to be fast-loading by users, regardless of channel used to access the site (traditional PC/laptop, large or small tablet and smartphones).

Vulnerability Scan Testing

The new web site will require industry-standard vulnerability testing to validate that common exploits (examples include cross-site scripting, SQL Injection hacks, web form security, etc.) are not possible on the new web site.

·  VA DGS, or the State, will provide a vulnerability testing tool that can be used for security validation.

·  VA DGS requires the use of Nessus Cloud (http://www.tenable.com/products/nessus/nessus-cloud) which is used to scan, on a scheduled basis, the web site to identify security holes.

·  It will be necessary to develop test scripts that will comprehensively look at the entirety of the web site, to include:

o  Anonymous web site visitor

o  Multiple content pages, not just the main home page

o  Pages or sections that have specific functionality (calendars, newsletter subscriptions, etc)

o  CMS Author and Administrator access need not necessarily be included in this, as the only way to access author and administrator logins will be via the VA DGS network, or VPN connection to the VA DGS network

·  The site will require periodic re-scanning to ensure new vulnerabilities are not introduced. Requirement is to complete the new scans at least weekly.

·  Note that the scanning process can take some time, between 24 – 28 hours on average. Deployment planning should keep this in mind as it may have an impact on the final deployment timeline. Project Management should also factor in time to address any fixes required to address any security concerns.

·  Development team must work with Episerver to ensure that the core CMS product is always up-to-date with patches, hotfixes and updated version releases.

Load Testing

Load testing will be required to define the upper limits of concurrent user activity. Based on a review of previous traffic patterns, we do not believe that the server will ever see a tremendous load, but it will be necessary to define what the limits of the new codebase running against the new hosting infrastructure are.

·  Vendor will be responsible for defining load test parameters, in conjunction with VA DGS stakeholders.

·  Load Runner or Performance Center may be used as tools

·  Vendor will execute load tests and provide documentation demonstrating the peak performance limits of the codebase and hosting infrastructure

Performance / Loading Objectives

The goal of the web site experience is to be perceived to be loading “quickly” regardless of channel used to access the redesigned site.

·  The goal for overall page performance will be a load time of 3 Seconds, average, or Less

o  “Load time” will be defined as the finish time presented by the Google Chrome’s Developer Tools functionality

o  Load time testing should be measured on a high-bandwidth connection (Cable / DSL/ T-1 or higher)

·  In general, all efforts should be made to ensure that both the perception of quick loading and actual performance to load meets these performance goals

·  To further enhance speed, a well-formed Caching strategy will be paramount

o  Implementation approach should leverage out-of-the-box caching capabilities found in Episerver

o  .NET-based forms of caching should be documented and reviewed to see if they can also speed the performance of the site

o  At this time, leveraging a content delivery network (CDN) is not required. However, video assets will only be served on YouTube, alleviating concerns around web site server bandwidth or load

Content Authoring, Access and User Authentication Model

In order to ensure security, CMS authors and administrators will only be able to access their login paths while they are directly within the VA DGS network, either physically or via secured VPN.

·  Production servers will have no access to a CMS Author or Administrator login page.

·  Production servers will essentially be a Read-Only model, simply serving content to the public in response to web site visitor traffic

·  Content changes will only be accessible within the VA DGS network:

o  Login page will be created and physically present only in the internal server

o  Authentication for CMS Authors and Administrators will be tied to Active Directory, or a VA DGS-supplied LDAP-compatible directory

o  A group will be setup for Administrators within Active Directory (or LDAP) and will map to the Administrators group in Episerver

o  Another group will be setup for CMS Authors within Active Directory (or LDAP) and will map to the CMS Authors group in Episerver

§  CMS Author groups will be further distilled to specific departments

§  NEED TO BUILD A PERMISSIONS MATRIX FOR CMS AUTHOR GROUPS

o  Password and related identity management for CMS authors and administrators will be managed following existing business and IS policies within VA DGS

Server Infrastructure

The server infrastructure has already been defined and illustrated in the diagram below:

VA DGS will have three different environments for this application which are as follows

Server Name / Description
Development / This will be the development server.
Testing / This acts as a content Authoring server and also as a test server
Production / This will be the Production Server

Additional details about each of these key environments is found on the next page.

Development Environment

Server Name / Description
Server Count / 3
Webserver Read-only / Dev Read-only wwb1033
The Internal Protected Zone Read Only Server
Editing Server / Dev Content Mgmt wwb01054
The content editing server which is separated from the public facing read only server
Database Server / SQL Dev wsq00857
The database server
Storage / DGNAS2
Separate Blob Storage to save the blob on to a network shared drive
Zone / All the 3 servers are protected in the Internal Protected Zone
Load Balancing / No
Mirroring / No

Production Environment

Server Name / Description
Server Count / 3
Webserver Read-only / Prod Read-only wwb1031
The public facing read only server
Editing Server / Prod Content Mgmt wwb01056
The content editing server which is separated from the public facing read only server
Database Server / SQL Prod wsq00859
The database server
Storage / DGNAS2
Separate Blob Storage to save the blob on to a network shared drive
Zone / The read only web server is placed in the DMZ environment.
The content editing server and the database servers are placed in the Internal Protected Zone
Load Balancing / No
Mirroring / No

Staging Environment

Server Name / Description
Server Count / 3
Webserver Read-only / Test Read-only wwb1032
The public facing read only server
Editing Server / Test Content Mgmt wwb01055
The content editing server which is separated from the public facing read only server
Database Server / SQL Test wsq00858
The database server
Storage / DGNAS2
Separate Blob Storage to save the blob on to a network shared drive
Zone / The read only web server is placed in the DMZ environment.
The content editing server and the database servers are placed in the Internal Protected Zone
Load Balancing / No
Mirroring / No

Misc. Server Infrastructure Notes

·  Specific requirements for CMS Authoring and Access include:

o  Must include robots.txt file that disallows public indexing

o  Will use IP to address dev servers – no DNS name will be used

o  Will use DNS for test servers, unless we use IPs, or servername: port approach

Accessibility Requirements

The redesigned web site is subject to the Section 508 accessibility standards found in the Americans with Disabilities Act (ADA). The following requirements apply to the accessibility standards to be met across the site:

·  Priority Level 1 will be the baseline compliance level required for the redesigned web site

·  Key 508 requirement impacts on content include:

(a)  A text equivalent for every non-text element shall be provided (e.g., via “alt”, “longdesc”, or in element content).

(b)  Equivalent alternatives for any multimedia presentation shall be synchronized with the presentation.

(c)  Web pages shall be designed so that all information conveyed with color is also available without color, for example from context or markup.

(d)  Documents shall be organized so they are readable without requiring an associated style sheet.

(e)  Redundant text links shall be provided for each active region of a server-side image map.

(f)  Client-side image maps shall be provided instead of server-side image maps except where the regions cannot be defined with an available geometric shape.

(g)  Row and column headers shall be identified for data tables.

(h)  Markup shall be used to associate data cells and header cells for data tables that have two or more logical levels of row or column headers.

(i)  Frames shall be titled with text that facilitates frame identification and navigation.

(j)  Pages shall be designed to avoid causing the screen to flicker with a frequency greater than 2 Hz and lower than 55 Hz.

(k)  A text-only page, with equivalent information or functionality, shall be provided to make a web site comply with the provisions of this part, when compliance cannot be accomplished in any other way. The content of the text-only page shall be updated whenever the primary page changes.

(l)  When pages utilize scripting languages to display content, or to create interface elements, the information provided by the script shall be identified with functional text that can be read by assistive technology.

(m) When a web page requires that an applet, plug-in or other application be present on the client system to interpret page content, the page must provide a link to a plug-in or applet that complies with §1194.21(a) through (l).

(n)  When electronic forms are designed to be completed on-line, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues.

(o)  A method shall be provided that permits users to skip repetitive navigation links.

(p)  When a timed response is required, the user shall be alerted and given sufficient time to indicate more time is required.

The source of the requirements shared above is the US Access Board: (https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-section-508-standards/section-508-standards#subpart_b)

Additional accessibility requirements include:

·  Vendor will be expected to define an Accessibility testing tool, appropriate tests to run and documentation to the VA DGS team demonstrating that accessibility standards have been met