functional requirements - virginia · web viewthe purpose of this functional requirements document...

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

FUNCTIONAL REQUIREMENTSVA DGS PUBLIC WEB SITE REDESIGN PROJECTIdentifying the Requirements for the Functionality of the Redesigned VA DGS Public Web Site

Virginia Department of General Services1100 Bank St #420, Richmond, VA 23219(804) 786-3311http:/dgs.virginia.gov

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


TABLE OF CONTENTS

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


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


Functional RequirementsSeveral 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 TESTINGThe 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 visitoro Multiple content pages, not just the main home pageo 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 TESTINGLoad 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 OBJECTIVESThe goal of the web site experience is to be perceived to be loading “quickly” regardless of channel used to access the redesigned site.


http://www.tenable.com/products/nessus/nessus-cloud

Functional Requirements 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 paramounto Implementation approach should leverage out-of-the-box caching capabilities found in Episervero .NET-based forms of caching should be documented and reviewed to see if they can also speed

the performance of the siteo 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 MODELIn 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 servero Authentication for CMS Authors and Administrators will be tied to Active Directory, or a VA DGS-

supplied LDAP-compatible directoryo A group will be setup for Administrators within Active Directory (or LDAP) and will map to the

Administrators group in Episervero 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 DescriptionDevelopment This will be the development server.Testing This acts as a content Authoring server and also as a test serverProduction This will be the Production Server

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

DEVELOPMENT ENVIRONMENTServer Name DescriptionServer Count 3Webserver Read-only Dev Read-only wwb1033

The Internal Protected Zone Read Only Server



Editing Server Dev Content Mgmt wwb01054The content editing server which is separated from the public facing read only server

Database Server SQL Dev wsq00857The database server

Storage DGNAS2Separate Blob Storage to save the blob on to a network shared drive

Zone All the 3 servers are protected in the Internal Protected ZoneLoad Balancing NoMirroring No

PRODUCTION ENVIRONMENTServer Name DescriptionServer Count 3Webserver Read-only Prod Read-only wwb1031

The public facing read only serverEditing Server Prod Content Mgmt wwb01056

The content editing server which is separated from the public facing read only server

Database Server SQL Prod wsq00859The database server


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 NoMirroring No

STAGING ENVIRONMENTServer Name DescriptionServer Count 3Webserver Read-only Test Read-only wwb1032

The public facing read only serverEditing Server Test Content Mgmt wwb01055

The content editing server which is separated from the public facing read only server

Database Server SQL Test wsq00858The database server


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 NoMirroring No

MISC. SERVER INFRASTRUCTURE NOTES Specific requirements for CMS Authoring and Access include:

o Must include robots.txt file that disallows public indexingo Will use IP to address dev servers – no DNS name will be usedo 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.


Functional Requirements(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

It will be of critical importance that the CMS be setup to provide support for accessibility wherever possible. For example, configuring the CMS to automatically apply the name of an image uploaded and used in content with the ALT tag for that image would help to ensure accessibility standards compliance.

Where functionality exists that prevents 508 compliance (for example, a video), a text-only equivalent describing that content should be made available

COMMONWEALTH OF VIRGINIA REQUIREMENTSSeveral components of functionality and content are required by the Commonwealth of Virginia, including:

The VA.GOV Banner must be displayed across the top of the redesigned web site user interface. This must appear on all web pages and will open in an external window when clicked.

Some of the following resources and standards may apply to the redesigned web site:o Enterprise Architecture Standardo Website Topic Reporto Common Banner resources (code and instructions) o WSTR revision presentation o Social Media Topic Reporto IT Accessibility Standard o IT Accessibility Toolkit o IT Accessibility Requirements Checklist o Section 508 Compliance

Additional information about these standards and tools may be found at: http://www.vita.virginia.gov/default.aspx?id=663


http://www.vita.virginia.gov/default.aspx?id=663

https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-section-508-standards/section-508-standards#subpart_b

https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-section-508-standards/section-508-standards#subpart_b


RETENTION REQUIREMENTSAs content is created and managed through the CMS, it will be necessary to retain records of how content was changed, published and how it appeared at a given point in time. Episerver provides for much of this functionality using out-of-the-box configurations. The requirements for retention of content include:

For web page content:o Audit Trails will be required; must track CMS Author name, Administrator approval name and

details of versioning. o Note that only published versions must be maintained; intra-version edits are not necessary for

retention. o Retention time period should be 7 years. Note that due to concerns over database size, it is

appropriate to export and/or truncate the content logs as long as it is possible to restore when and if needed.

For uploaded assets (PDF documents, MS Office documents, etc.):o Audit Trails will be required; must track CMS Author name, Administrator approval name and

details of versioning. o Note that only published versions must be maintained; intra-version edits are not necessary for

retention. o Retention time period should be 7 years.

For web form submissions:o Audit Trails of both the form content and submissions will be requiredo Form submission data must also be stored in the Episerver database, even if the business request

is to email (note that emailing form results and storing in the Episerver database can both be supported)

o Must track CMS Author name, Administrator approval name and details of versioning. o Note that only published versions must be maintained; intra-version edits are not necessary for

retention. o Retention time period should be 7 years. Note that due to concerns over database size, it is

appropriate to export and/or truncate the content logs as long as it is possible to restore when and if needed.

Content Management System

The redesigned VA DGS public web site will require a web-based content management system that will allow for the following key capabilities:

1. Easy-to-use authoring experience, highly adaptable to non-technical business users2. Utilizes the .NET technical stack to be as compatible as possible with the technical skillsets within

VA DGS3. Provide required functionality to address the needs of this initial redesign project4. Provide the foundation for additional functionality to be added in the future, including end-to-end

e-commerce, personalization and content marketing functionality.


Functional RequirementsAs a result of extensive testing and reviews, Episerver has been selected as the most appropriate CMS platform to develop upon.

SERVER AND BROWSER REQUIREMENTS FOR EPISERVERThe following requirements represent the baseline specifications for both the Episerver CMS Server and browsers accessing the CMS.

Server requirements

Operating system Any of the following:

Microsoft Windows Server 2012 R2Microsoft Windows Server 2012All service packs are supported.

Note: From CMS 9, Windows Server 2008/2008 R2 and Windows 7 are no longer supported.

Web server Any of the following must be installed as part of the Windows Server installation:

Microsoft Internet Information Services (IIS) 8.5Microsoft Internet Information Services (IIS) 8.0Microsoft Internet Information Services (IIS) 7.5Microsoft Internet Information Services (IIS) 7.0

Database Any of the following:

Microsoft SQL Server 2014Microsoft SQL Server 2012Microsoft SQL Server 2008 R2Microsoft SQL Server 2008

All service packs are supported.

Other requirements Microsoft .NET Framework 4.5.2 C# 5.0Note: After 2015, Microsoft .NET Framework 4.5.0 and 4.5.1 are no longer supported

Plus any of the following:

Microsoft MVC 5Microsoft MVC 4

Note: In a production environment, a permanent IP or MAC address is



required.

Client requirements for editing

Browser for editing Any of the following:

Microsoft Internet Explorer 11*Microsoft Internet Explorer 10*Mozilla Firefox, latest**Google Chrome, latest**

* For Commerce Manager, see product-specific requirements.** Due to fast release cycles, we only support the latest versions for these.

Client requirements for browsing

Browser for viewing Any of the following:

Microsoft Internet ExplorerMozilla FirefoxGoogle ChromeOperaApple Safari

Development and demonstration environment

Operating system Any of the following:

Microsoft Windows 10Microsoft Windows 8.1Microsoft Windows 8Microsoft Windows Server 2012 R2Microsoft Windows Server 2012

Note: From CMS 9, Windows Server 2008/2008 R2 and Windows 7 are no longer supported.

Development tool Any of the following:

Microsoft Visual Studio 2015

Microsoft Visual Studio 2013Microsoft Visual Studio Express 2013 for WebMicrosoft Visual Studio 2012Microsoft Visual Web Developer 2012 Express Edition



Note: The Episerver Visual Studio integration installation requires IIS Express, which you can install using the Web Platform Installer.

Database Any of the following:

Microsoft SQL Server 2014Microsoft SQL Server 2012Microsoft SQL Server 2012 ExpressMicrosoft SQL Server 2008 SP3Microsoft SQL Server 2008 SP3 ExpressMicrosoft SQL Server 2008 R2

Note: The Episerver Visual Studio integration installation requires Microsoft SQL Server Express.

Other requirements Any of the following:

Microsoft MVC 5Microsoft MVC 4

Source: Episerver, latest updated material May 12, 2016 at:http://world.episerver.com/documentation/items/system-requirements/system-requirements---episerver/

Responsive Design

The new version of the VA DGS web site will be delivered using a responsive design approach. Responsive design allows for multiple viewports to be defined for the types of devices that will be accessing the site.

Three viewports will be developed for the new site:o Desktop / Laptop (980 px or higher)o Tablet (Approx 380 px – 980 px)o Smartphone (Approx Lower than 380px)

Bootstrap will be the responsive framework that will be utilized to accomplish the responsive design The following browsers support responsive design technology:

o HTML 5 support or highero CSS 3 support or highero Common browsers that support this include:


http://world.episerver.com/documentation/items/system-requirements/system-requirements---episerver/

http://world.episerver.com/documentation/items/system-requirements/system-requirements---episerver/

http://www.microsoft.com/web/downloads/platform.aspx


Current CSS 3 support across browsersSource: http://caniuse.com/#feat=css-mediaqueries

For browsers that don’t meet the requirements above, several options exist:o At a minimum, these users should be presented with a web page that contains links to updated

versions of the user’s browsero Other options exist that may allow non-compliant browsers to still utilize aspects of the

responsive design. These options include Modernizr and several others. Additional details can be found at: https://www.sitepoint.com/understanding-responsive-web-design-cross-browser-compatibility/

Search Functionality

Search is one of the most important aspects of the newly redesigned VA DGS web site. Multiple versions of search exist and are defined below. It is important to note that more advanced search functionality, including look-ahead search, saved search results, personalized search results and auto-faceting are not included as part of this project due to additional costs associated with search licensing from Episerver and a lack of request or interest in these advanced search features from the business units.

GLOBAL SEARCH Global search box is available on all web pages found throughout the site Search is based on keyword or phrase entered by the web site user Search Results should be:

o Sorted by relevance, then most recent date


https://www.sitepoint.com/understanding-responsive-web-design-cross-browser-compatibility/

https://www.sitepoint.com/understanding-responsive-web-design-cross-browser-compatibility/

http://caniuse.com/#feat=css-mediaqueries

Functional Requirementso Searches all web pages, PDF documents and MS Office documentso Scope of search is entire web site

Recommended Search Results functionalityo Develop a method, using Episerver’s out-of-the-box functionality, to match keyword or phrases

against a list of CMS author-managed terms.o When there is a match, above search engine results, provide a box where content can be

displayedo For example, a user types in “Forms” into the global search. The experience would include:

A box above the search results showing a HTML “advertisement” for the Forms Center area. The content in the HTML “advertisement” is provided by the CMS Author

o Develop an interface for authoring the HTML “advertisements”, the terms that should be used to match and the alignment to each term or phrase

o Multiple HTML “advertisements” may be triggered by a keyword or phrase. o Administration functionality should allow CMS Author to set the priority of each HTML

“advertisement” to address sort order when multiple HTML “advertisements” match a particular term or phrase.

o Recommended that VA DGS Team starts with 50 or 100 of the most popular search terms being used today

Look ahead search is not included in this phase

SCOPED SEARCH: DEPARTMENTEach department will also have its own search experience provided for within the user interface design of each department. This scoped search augments the master global site search, but does not replace it.

Scoped search boxes are available only on a given department’s web site Search is based on keyword or phrase entered by the web site user Search Results should be:

o Sorted by relevance, then most recent dateo Searches all web pages, PDF documents and MS Office documentso Scope of search is only on a given department’s web site

Recommended Search Results functionalityo Develop a method, using Episerver’s out-of-the-box functionality, to match keyword or phrases

against a list of CMS author-managed terms.o When there is a match, above search engine results, provide a box where content can be

displayedo For example, a user types in “Forms” into the global search. The experience would include:

A box above the search results showing a HTML “advertisement” for the Forms Center area. The content in the HTML “advertisement” is provided by the CMS Author

o Develop an interface for authoring the HTML “advertisements”, the terms that should be used to match and the alignment to each term or phrase

o Multiple HTML “advertisements” may be triggered by a keyword or phrase.


Functional Requirementso Administration functionality should allow CMS Author to set the priority of each HTML

“advertisement” to address sort order when multiple HTML “advertisements” match a particular term or phrase.

Note that the Forms Center area has one additional instance of search functionality, whose requirements are included there.

Example Screenshot: Basic Episerver Search, Thumbnail view enabled:



Forms Center

The Forms Center is one of the most important aspects of the redesigned VA DGS web site, considering that much of the site traffic today is geared toward finding the correct form to utilize. There are multiple ways to access the forms center, but there are 2 main approaches: Global or from a department or division page. Put simply, if entering the Forms Center from the global navigation, the default view will be for all Forms to be displayed. If entering from the Forms link of one of the department or division pages, the user will enter the Forms Center with a filter already applied for the department or division that they came from.

Default forms sort rules:o Ascending list by form name, then date (If BCOM, see below)o All form fields will be sortable o Form columns should include:

Date Form Name Form Number Document Type Description (limit to 200 characters in description, until you get to detail page view) Division Category Sub-category

o BCOM only Default sort order would be by form number, not name All other departments will sort by form name, not number

Search Capability within the Forms Center Keyword based only Must include Department-specific Filters

Default is global search for all forms Drop-down box includes filters for departments

Follows the same sort rules as defined above Searches all web pages, PDF documents and MS Office documents

The following pages provide 2 sample wireframes of how the Form Center may be laid out. However, this is only intended as a wireframe guide to the functionality, not an exhaustive design for this functionality.



Web Forms

The CMS will provide business users with the ability to deploy their own web forms that will allow web site visitors to complete and submit information to the organization. Using Episerver’s out-of-the-box functionality for developing web forms, the web site will allow:

Basic web forms to be developed allowing non-technical end users to create web forms to be published on the web site once approved

Web forms must follow the same permissioning and auditing requirements as other forms of content No branching will be allowed within the forms. Forms that branch change the questions they ask based on

the answer to a previous question. Form submissions can be emailed to one author, multiple authors or a CMS group. In addition, form

results will also be stored in the Episerver CMS database. Reporting on form submissions will be limited to the capabilities of Episerver’s out-of-the-box

functionality A single generic web forms template will be created that will be used to house all web forms

Polls / Survey Functionality

Related to web forms, polls and surveys are other forms of web forms that have specific purposes. In the example of a poll, the purpose is to ask several questions and provide multiple choice responses with reporting of results possible. Surveys tend to be longer, more open-ended form questions with fewer multiple choice answers.

In addition to the requirements defined earlier in the Web Forms functional requirements, the following additional requirements apply to polls and survey forms:

Utilize only what is possible and available out-of-the-box with Episerver No registration will be required in order to participate in a poll or survey Ideally, it would be possible to track the IP address of people participating so as to eliminate multiple votes

from the same person, on a per session basis DESIGN OR WIREFRAME NEEDED?

Dynamic Org Chart

The web site will feature a tool for displaying organization charts of personnel within the VA DGS team. The following requirements apply to this:

Organization charts will be displayed for each department There will be no master organization chart for all employees


Functional Requirements Only CMS Administrators will be able to manage the organization chart for their department, unless they

delegate to authors The organization charts should support responsive displays For each entry on the organization chart, the following data may be displayed:

o Full name

o Organizational Unit

o Title

o Email Address

o Phone Number

o Reporting Relationship

The charts may be added to the CMS as static graphics, PDF files or similar, static views. It is not necessary that the organization chart be dynamically rendered in real-time.

It may be decided that a custom tool be purchased or developed to meet this requirement. DESIGN OR WIREFRAME NEEDED?

Analytic Tracking

Two types of analytics will be required on the redesigned web site, including Episerver-specific Analytics and Google Analytic tracking.

EPISERVER-SPECIFIC Most viewed content Most popular content by organizational unit Most popular search terms Most popular downloads

GOOGLE ANALYTICS FUNCTIONALITY Basic Google Analytics will be required for general traffic monitoring

o VA DGS will provide a new Google Analytics UA Account code to use on the new site Downloads must be reported and captured in the Google Analytics reporting engine

o Download handler must be modified to include calls to Google Analytics account to capture the document URL, name and download event to Google Analytics

Product Catalog Functionality

Several business units have identified a desire to present content in a way that is similar to e-commerce catalogs. One example would be a listing of surplus real estate and properties. Another example would be the ability to list


Functional Requirementsthe different types of vehicles found in the State’s fleet. Episerver provides e-commerce capabilities and while the requirement is not to make actual transactional functionality available through the web site in this phase of development, the business units would like to utilize this functionality to accommodate the product catalog and product display modes, as defined below.

CATALOG VIEW A view that lists available “products” – examples would include state vehicles found in the fleet or surplus

real estate properties Each item belonging to a catalog would contain “products” that are grouped together. An initial view showing the products displayed together, in a single, graphical view is required Clicking a “product” link in the product catalog will take users to the detail page Note that this is only focused on content displays; no actual e-commerce transaction is available VA DGS would like to have a single, generic template that can be used for each instance of this functionality It should be easy for a department that doesn’t have this functionality at launch to add it with a minimum

of involvement from the VA DGS IS team DESIGN OR WIREFRAME NEEDED?

DETAIL VIEW Once a product is clicked, a detail view of that product page will render The product detail page is mainly included for informational purposed and will generally follow the same

approach and layout:o Large graphico Several additional, supporting, optional graphicso Headlineo Several paragraphs of text content, with embedded links as defined by the CMS Author

VA DGS would like to utilize the same product detail template for all instances of this functionality DESIGN OR WIREFRAME NEEDED?

NOT NEEDED FOR PRODUCT CATALOGSThe following functionality is NOT required in this phase of development and may be included in future iterations of the web site:

Inventory Management Stock Status Reporting Shopping Cart Functionality User Account Creation Order Tracking Functionality Sales Reporting Tax Calculations Shipping Calculations Order / Stock Notifications



Variable Management (Optional)

This is an optional requirement. Variable management functionality is a requirement that essentially would allow key terms and phrases to be used throughout the site to be variabilized. For example, making the Governor’s name a variable would allow for the name to be changed in one place and have it automatically updates throughout the site and would save CMS Authors and Administrators a tremendous amount of time and effort.

Develop the ability to define a Variable Name and Type (examples would include: Governor: Terry McAuliffe or Department Head: John Smith)

Store a series of variables in a secured access manner within the CMS itselfo Restrict management of Variables to CMS Administrators

Develop a method for inserting Variables into contento For example: The department is chaired by the <<<DEPT HEAD>>> o Must be easy enough that non-technical, end users are easily able to add within the content

editor

Department Contact List Look-up

This requirement would be for a structured set of data that would allow for a listing of all department contact names to be shown to end users.

Using a structured data approach, develop a way in which key contact information for department contacts can be added, edited and managed over time by CMS Authors or Administrators

Provide the ability to present contact names in each department that wants it to include the following fields:

o Full Nameo Titleo Business Unito Email addresso Phone Number

All fields are sortable Ideally, this same data would be shared with the Organization Chart functionality described elsewhere in

this document. DESIGN OR WIREFRAME NEEDED?

Advisor Lookup Functionality

Similar to the Department Contact List Look-up, there is another need to assist State Employees to identify the key representatives within each agency. Using a similar approach, provide a system that will:

Present the web site visitor with an expanded drop-down box that lists the 90+ agencies found When the users selects the agency, the lookup occurs within the database and then returns the contact

information for the agency’s advisor


Functional Requirements Need to ensure that administrative functionality exists to manage the lists of the agencies and the content

that shows DESIGN OR WIREFRAME NEEDED?

Newsletter Subscriptions & End User Profile Account Management Functionality

In order to provide some of the functionality described (for example, the newsletter subscription capabilities), a special, end-user account has to be created within Episerver. However, VA DGS does not wish to expose this functionality to the end user. As a result, the following requirements apply to end-user accounts. Note that these end-user accounts are not the same as CMS Author or Administrator accounts, which are tied to Active Directory (or other LDAP source) and are able to be logged into.

There will be no method for an end user to login, access, edit or modify their account information. All account information should be hidden from the end user.

CMS Administrators may delete accounts if needed through the out-of-the-box functionality provided by Episerver

The main use case for this functionality involves the sign-up for newsletter forms. In these cases, the following flow will apply:

o To sign-up for a subscription, user must enter their email addresso As part of the subscription request, user must also complete the Google reCAPTCHA process to

aid in spam reduction Additional information can be found at:

https://www.google.com/recaptcha/intro/index.html o VA DGS site sends an email to that address requesting that they click the link to prove that they

entered the correct email address and have authority to receive email. This double-validation step also assist with compliance with the CAN-SPAM act

o Once the validation email is received by the VA DGS site, user is added to the internal subscription list

Users can subscribe to multiple newsletterso When receiving requests, the end user’s address should be used as the unique identifier. o If there are multiple requests from the same email address, append each new subscription to the

same user profile Unsubscriptions

o When notifications are sent to subscribers, they will have a link embedded in the email that allows them to request to unsubscribe

o The only way to unsubscribe is to unsubscribe from the newsletter email that the users receive; no login or administrative interface will be built to support the management of these accounts to end users

o In the case of multiple newsletter subscriptions, users will receive a newsletter from each subscription they are signed up for. Using that, they can then click the unsubscribe link to unsubscribe from that specific listing


https://www.google.com/recaptcha/intro/index.html


NEWSLETTER SIGNUP & VIEW FUNCTIONALITY For Existing Subscriptions:

o BCOM has 2 lists types (State and Non-State) Folders for State-based and non-state-based users should be setup to allow them to

discriminate between the two groups of userso BCOM’s current subscription list has to be moved into the new web site model and a method for

importing existing users, along with custom subscription options for the users, will need to be developed

For New Subscriptions:o Several other organizational units also have requested to setup new need to setup newsletters

for: Fleet Surplus DCLS

Content Delivery for Newsletter Subscriptionso Content will be authored in the CMSo When published and approved, CMS Authors and Administrators can choose any of the following

notification methods for subscribers: Email notification that newsletter is available and include link back to the newsletter

page Email notification that newsletter is available, summary is included in the email and a

link back to the full newsletter is included Email delivery of the entire newsletter

o All notifications and newsletter deliveries must include Unsubscribe Links DESIGN OR WIREFRAME NEEDED?

Urgent Alerts System

There may be times when urgent alerts need to be published in parts or throughout the entire web site to alert visitors and employees to dangerous or otherwise important news. To accommodate this need, a design has been developed that is shown below, along with requirements for this functionality.

Example Alert Banner

Requirements for urgent alerts:

Any number of emergency banners can be added to a page If there are multiple banners, they will stack on top of one another and not scroll in a carousel style


Functional Requirements Urgent Alert Banners may be placed:

o On the main home pageo ALL web pages on the siteo On a specific department home pageo All of a specific department’s pages

Administrators alone will be able manage global alerts (alerts that affect all pages) Department heads can manage department-specific alerts

Video Embed Functionality

VA DGS has standardized on using YouTube as the preferred platform for video delivery. As such, it will be important to allow CMS Authors and Administrators the easy ability to embed videos from YouTube, or other embed sources, using only the CMS Editor.

Requires the ability to copy and paste embed code from external sources and add it through the CMS Editor

If possible, develop a “widget” that allows users to easily find and add videos from YouTube onto their pages

While YouTube is the primary source, ensure that support for other embed commands from other sources (examples would include Slideshare.net, the Federal or State Governments, etc)

Note that videos and other embedded content will not be searchable to the web site, so adding explanatory text around the embed command is the best way of ensuring that web site visitors will be able to access embedded content through global or scoped searches

Photo Gallery / Media Library Functionality

There are several places throughout the web site where it would be valuable to have the ability to present content in a photo gallery format. Although not a request of each and every department, the ability for any department to add a photo gallery in its site is required. Additionally, there should be no limit to the number of galleries that can be added to a department’s section on the web site.

Photo Gallery will take the form of an animated slideshowo Users will first see a series of thumbnails of the images o Clicking any image will take the user to that image in the slideshowo Slides will be larger versions of the photo and users may go back and forth in the slideshowo Users may also elect to have an auto-play mode turned on that automatically advances the

slideshow on a pre-determined time JQuery should be used to provide this functionality A Lightbox approach should be used to control the display of the slideshow Ideally, users would be able to select from multiple slideshow types, including:

o Carousel


Functional Requirementso Accordiono Random Animationo In-line slider

Structured data will be captured by the user to create the slideshow. For each slide, the user will provide:o Image title (after uploading it into the CMS)o Description of imageo Order number of image within slideshow

Must be able to be instantiated anywhere needed throughout the site DESIGN OR WIREFRAME NEEDED?

FAQ Management Functionality

Several parts of the web site require Frequently Asked Question areas. To ensure consistency, VA DGS required that FAQ functionality be built that easily allows CMS Authors to create, edit and manage FAQs on any web page in their site. Note that multiple FAQs may be added to the same page, if needed. Additional requirements below:

FAQs should be displayed in an accordion-style approach that illustrates questions and then, when clicked, open to show the answers to each question

To load questions, CMS Authors will first create a new FAQ and then add:o Question (Plain Text)o Answer (Rich Text)

CMS Authors must have the ability to sort the order and manage the number of questions Ability to do this and implement any number of instances of a FAQ

o Multiple FAQs can be applied on a pageo FAQs can also be used across departments

DESIGN OR WIREFRAME NEEDED?

Calendar Functionality

Calendaring functionality is another important requirement that can be used by one or more organizational units. Below, find core requirements for calendaring functionality:

Can be applied to any division or department Multiple calendars can exist within any division or department There is no need for one master, consolidated calendar Calendars should include:

o Monthly, Weekly and Daily Viewso Must support ICAL, ICS and similar format supporto Must support responsive views

Must be JQuery-based There will only be a need for one division-specific calendar function, Fleet, at launch No filtering capability needed



CALENDAR SAMPLESMonthly View

Weekly View

Daily View



URL Management

URLs are critically important for the new web site, for two specific reasons. First, it is important to maintain key (but not ALL) existing links found in printed materials, embedded in other systems and sites and already out in use in the public. These key links can’t break with the redesign and users will need to be either directed to the new location in the new site, or presented with a sitemap where they can find their way to the content that they seek. Secondly, new URLs must be search engine (and human, too) friendly to improve organic SEO performance and increase recognition in general.

FOR KEY EXISTING URLS: A list will be provided of key URLs to maintain A series of 301 redirect will be setup to redirect the key URLs to their new destinations and to update

external search engines

FOR NEW URLS: New URLs will be search engine friendly, human readable and conform to SEO guidelines, derived from

the sitemap

OTHER GENERAL URL AND SEO-RELATED REQUIREMENTS Custom 404 error messages will be developed that will point to the sitemap Robots.txt must be created to ensure that only appropriate content is indexed by external search robots A dynamic sitemap must be created and connected to the Custom 404 error page to ensure that up-to-

date, dynamic links are always captured Sitemap.xml must be created and maintained dynamically to further improve “findability”. Sitemap.xml

files should also be registered with Google’s Webmaster Tools.

Social Functionality

Two forms of social media functionality are required:

Social Followo The footer of each page must include links to the official Social Channels for VA DGS, including

Twitter, Facebook, YouTube and any others Social Share Content

o A service (examples include ShareThis.com or AddThis.com) should be utilized to allow web site visitors to share any web page with their own social channels

o Using a third-party service like ShareThis.com or AddThis.com will also allow for social sharing analytics to be captured.

o In addition to sharing, these services also generally allow web site visitors to email a web page to someone else, which may have additional business value



Items Not Needing Requirements

VIRTUAL TOUR FUNCTIONALITYA request was made for virtual tours, but this will be handled through the use of embedded media from third-party sources or will be static content or photo displays. No functional requirements apply to this.

ONLINE MANUALS FUNCTIONALITYAnother request was made around online manuals, but it was decided that as long as the online manuals (in PDF format) are searchable within the new global or scoped search functionality, no additional requirements would apply.
