Developing Website Requirements

This article summarizes key requirements for developing Web Functional Specifications as a helpful guideline. This information shared is part of the commons network and developed by a promising online community coordinator. Helpful points of view for consideration.

Section Areas

1. Overview
1.1. Objectives
1.2. Assumptions
1.3. User Groups/Audience and Goals
2. High Level Site Layout (Site Map)
3. Functional Requirements
3.1. Software Functions
3.2. End-User Functions
3.3. Administrative Functions
4. User Scenarios
4.1. Scenario #1
5. Reporting Structure

OVERVIEW

1.1. Objectives

This project is intended to update the interface, functionality, and positioning of ASQ’s internal online communities, including those currently hosted in SharePoint. As part of this goal, the project will offer community members such enhanced functionalities as single sign-on, improved online community tools (profile, discussion board, real-time interaction, chat features, direct messaging features, rating and comment features, and selective visibility/privacy features, among others), and increased visibility as well as participation/inter-linkage in external online communities such as LinkedIn, Facebook, Twitter, Digg, Delicious, etc.

The primary goals of the project are to increase user engagement and expand the members of the Community (MOC), supporting the Community EA in place for this fiscal.

A few key measures of success would be increased engagement with ASQ’s online communities (i.e. more posts to discussion boards, blogs, and comment/rating features, as well as sharing links with off-site communities); increased responsiveness to internal community opportunities; X number of external site conversations leading to participation in internal communities; and development of X number of “super-users” (users whose comments are highly rated by other participants, who post frequently, who return frequently, and who show a steady rate of returning over time) within the first three months of launch.

1.2. Assumptions

IT is responsible for selecting, purchasing, and implementing software that meets the needs outlined in this document
- A single software solution exists to meet all of ASQ’s needs, and will allow previously installed instances of blog, discussion board, calendar, etc. content to be imported into it
- The software solution will be able to communicate with ASQ’s existing CMS and TIMSS solutions to allow User-Generated Content to be linked with CMS content, and to allow tracking of and reporting on usage, activity, and points/user-rating build-up

1.3. User Groups/Audiences and Goals

• ASQ Admin: Assign privileges to users; housekeeping needs.
• ASQ Member/Advocate: Read all comments, ratings, and discussion boards; post to discussion boards, comments, ratings, community; earn points and recognition; at pre-set point amount, gain blogging privilege
• ASQ Member: Read all comments, ratings, and discussion boards; post to discussion boards, comments, ratings, community; earn points and recognition
• ASQ Registered Visitor: Read public comments, ratings, and discussion boards; post to discussion boards, comments, ratings, community; earn points and recognition
• ASQ non-member: Read public comments, ratings, and discussion boards

2. HIGH LEVEL SITE MAP

Please find preliminary wireframes from Hanson Dodge attached as Appendix 1. These wireframes were developed last fiscal, and are being reworked to take into account new developments on asq.org, as well as additional details and guidance given by the Community Development team.

3. FUNCTIONAL REQUIREMENTS
Software Functions Required

3.1. Requirement #1 – ASQ Branding & Templating

3.1.1. Definition: Templates within the community must allow for ASQ-defined templates to be put in place seamlessly with the rest of the site. WO must be able to have access to the templates in order to be able to update them as appropriate.
3.1.2. Goal of function: Integrate the community functions with the rest of the site and allow for easy design integration and maintenance with the rest of the site.
3.1.3. Notes/Assumptions: While blog and discussion board templates currently bear almost no relationship to the look and feel of the rest of the site, it would be preferable that this distance be lessened over time, to allow the full integration of the interactive experience with ASQ’s content.
3.1.4. This feature is required

3.2. Requirement #2 – No User Limit

3.2.1. Definition: The community software should be able to scale to at least the million-member MOC level targeted as an org goal.
3.2.2. Goal of function: To avoid user dissatisfaction as the community experiences rapid growth.
3.2.3. This feature is required

3.3. Requirement #3 – Network Site Statistics

3.3.1. Definition: Ability to gain actionable insight into community usage.
3.3.2. Goal of function: To continue current reporting practices.
3.3.3. Notes/Assumptions: There is likely to be something of a shift if the new software offers integrated reporting tools (preferred), since current methods involve hand counts out of TIMSS reports. If this could be automated or more closely integrated with Web Trends, that would be the best of all possible worlds.
3.3.4. This feature is required

3.4. Requirement #4 – Authenticate into ASQ community

3.4.1. Definition: Ability of site visitors to log into the community using systems already in place and following Customer Records rules and practices.
3.4.2. Goal of function: Unified/seamless user experience that nonetheless allows ASQ to control access based on current business rules.
3.4.3. This feature is required

3.5. Requirement #5 – Shared User Base

3.5.1. Definition: Registered visitors and members should be able to carry credentials earned in one portion of the software/site to all other portions.
3.5.2. Goal of the function: Unified/seamless user experience that more tightly integrates disparate elements of the software with the overall site visit experience.
3.5.3. This feature is required

3.6. Requirement #6 – External-facing Content Moderation System

3.6.1. Definition: Members who have achieved a certain credibility point threshold in the system should be allowed to flag (at lower threshold), and moderate (at higher threshold) other community members’ comments according to rules established at HQ and agreed to at the time the responsibility is earned.
3.6.2. Goal of the function: Self-sustaining community establishment requires that the members have a significant degree of control over what is acceptable to the community.
3.6.3. This feature is required

3.7. Requirement #7 – Ability to import content from previous systems

3.7.1. Definition: Content previously contributed via the homegrown comments and ratings features and calendar features; posts from the discussion boards and blogs; and content shared via the current community interface should all move into the new software as a basis for seeding the new community areas and maintaining continuity over time.
3.7.2. Goal of the function: The transition to the new software should be as transparent to the user as possible. Since not only the layout and functionalities will be significantly different, ASQ should be sensitive to the perceived credibility already established in our historical offerings and allow that to transfer without the end user having to worry about its loss.
3.7.3. Notes/Assumptions: The transfer should also allow us to start tying comments to registered visitors and members to begin to generate a more robust view of these individuals as well as pre-populate some points for such visitors who have already undertaken the desired activities within the old framework, giving them deeper incentive to continue contributing user-generated content within the more robust offering.
3.7.4. This feature is required

3.8. Requirement #8 – Authenticate according to specific customer type

3.8.1. Definition: There should be different access levels to the software features depending on criteria stored in TIMSS (i.e. registered visitor, vs. member, vs. member leader, etc.).
3.8.2. Goal of the function: Continue the outline of the customer records project to encourage registered visitors to establish and nurture a relationship with ASQ through to membership and beyond.
3.8.3. This feature is required


3.9. Requirement #9 – Sentiment Analysis available as a metric

3.9.1. Definition: The software should provide a high-level analysis of keywords and topics to give an easily generated report on key interests being discussed within the community setting, to be actionable by Community Development, Membership, and Market Development in support of needs expressed by the members of the communities.
3.9.2. Goal of the function: Support a conversation with members and customers that helps develop ASQ’s offerings according to the needs expressed in the community context.
3.9.3. This feature would be nice to have

3.10. Requirement #10 – Network Privacy Settings

3.10.1. Definition: Participants should be able to determine how much of their profile information is shared with different classes of contacts.
3.10.2. Goal of the function: Support participants’ desire for control of the information in their profiles.
3.10.3. This feature is required

3.11. Requirement #11 – OpenID compatible

3.11.1. Definition: Log-in and profile elements match up with current OpenID standards.
3.11.2. Goal of the function: This will allow ASQ’s communities to be more transparently connected with other communities, allowing for a richer data set per user, as well as increasing the ease of use for the participants by streamlining log-on across multiple social networking sites.
3.11.3. This feature is required


3.12. Requirement #12 – Online document storage, sharing, and commenting

3.12.1. Definition: Users should be able to upload documents (Word, PowerPoint, etc.) to the system and designate others who are authorized to view or edit those documents.
3.12.2. Goal of the function: Replace SharePoint document sharing. Individual users will be limited to 5MB of storage; groups that have been given appropriate authorization by the organization may access up to 5GB of storage.
3.12.3. This feature is required

End-User Functions Required

1.1 Requirement #1 – Spam Control

1.1.1. Definition: An automated challenge system that reduces the number of spam comments that either need moderation or slip through standard keyword or rules-based filtering.
1.1.2. Goal of the function: Keep community-based content on-topic and relevant to improve the visitors’ likelihood of staying through the whole conversation.
1.1.3. This feature is required

1.2. Requirement #2 – Search

1.2.1. Definition: Ability to search for user-generated content within the community area based on keywords and key phrases.
1.2.2. Goal of the function: Increase the visibility of the user-generated content to increase the likelihood that participants will continue previous conversations already taking place within the system.
1.2.3. Notes/Assumptions: This feature may be equally well-served by the current CMS, if the content generated within the community software is somehow tied to the CMS and we can use the CMS search function to find it. In fact, it would be preferable if we could maintain only one search engine to deal with visitors’ search needs.
1.2.4. Search function is required; it may not be necessary within the community software, however, if we can tie that content to the CMS.

1.3. Requirement #3 – User Profiles

1.3.1. Definition: User-generated information on self, falling into several categories.
1.3.2. Goal of the function: Increase the transparency of the participating individuals to allow for trust to be established between users based on self-advertised areas of interest, expertise, or industry.
1.3.3. This feature is required


1.4. Requirement #4 – Single log-on, unified user experience

1.4.1. Definition: Registered visitors and members should not need to log in separately to access any of their approved areas of community or site activity.
1.4.2. Goal of the function: Unified/seamless user experience that more tightly integrates disparate elements of the software with the overall site visit experience.
1.4.3. This feature is required


1.5. Requirement #5 – Reviews & rating system

1.5.1. Definition: A collaborative filtering algorithm that attempts to determine ratings for a collection of entities, given a collection of opinions that those entities hold about each other.
1.5.2. Goal of the function: Reputation systems are often useful in large online communities in which users may frequently have the opportunity to interact with other users with whom they have no prior experience or in communities where user-generated content is posted. In such a situation, it is often helpful to base the decision whether or not to interact with that user on the prior experiences of other users. Reputation systems may also be coupled with an incentive system to reward good behavior and punish bad behavior. For instance, users with high reputation may be granted special privileges, whereas users with low or unestablished reputation may have limited privileges.
1.5.3. This feature is required

1.6. Requirement #6 – Email notification settings

1.6.1. Definition: Simple notification system similar to RSS, only directed at a user-defined email address (can be constrained to the registered email address on the account, if necessary).
1.6.2. Goal of the function: Alternate means for participants to remain current with recent content additions.
1.6.3. Notes/Assumptions: Email notifications should be available for sets of content from particular segmented communities, particular users, particular topics, or particular industries.
1.6.4. This feature is required

1.7. Requirement #7 – RSS

1.7.1. Definition: Simple syndication.
1.7.2. Goal of the function: Alternate means for participants to remain current with recent content additions.
1.7.3. Notes/Assumptions: RSS feeds should be able to slice and dice content according to particular segmented communities, particular users, particular topics, or particular industries.
1.7.4. This feature is required

1.8. Requirement #8 – Member listings

1.8.1. Definition: Similar to current “Find a Member” functionality, these member listings would relate specifically to membership within particular segmented communities.
1.8.2. Goal of the function: Allow segmented community participants to know who else is participating in a particular dialogue to increase the trustworthiness of their communication within that context.
1.8.3. This feature is required

1.9. Requirement #9 – Variety of relationship types

1.9.1. Definition: Allow registered visitors and members to maintain varying levels of contact with other participants in the communities.
1.9.2. Goal of the function: Related to privacy concerns, some participants may not want all other participants to be aware of all levels of their activity. So display of particular online activity can be restricted according to the user-defined relationship with other participants (friend, colleague, group participant, mentor).
1.9.3. This feature would be nice to have.

1.10. Requirement #10 – Granular community descriptions

1.10.1. Definition: Segmented communities should have the ability to define who is allowed to participate and how the community will describe itself.
1.10.2. Goal of the function: Allow communities to arise through user demand, with parameters set by the participants (i.e. must have certain membership or registration credentials to participate).
1.10.3. This feature is required

1.11. Requirement #11 – Forums/message boards

1.11.1. Definition: Asynchronous, public discussion space for multiple participants.
1.11.2. Goal of the function: Allow space for members and registered visitors to interact in such a way that their conversations are publicly (as appropriate to the sponsoring body) available and can contribute to ASQ’s BOK.
1.11.3. Notes/Assumptions: Should add to the function-set currently available in ASQ’s discussion board, as well as allow current discussion board content to be imported into the new solution.
1.11.4. This feature is required

1.12. Requirement #12 – Tagging/folksonomy

1.12.1. Definition: User-generated tags and descriptions of content.
1.12.2. Goal of the function: Eventually ASQ’s folksonomy should offer an alternate method of navigating an increasingly large body of knowledge, as well as offer the Knowledge Offerings group insight into the ways community members interact with ASQ’s BOK.
1.12.3. This feature would be nice to have

1.13. Requirement #13 – Authenticated badges

1.13.1. Definition: Graphical tokens indicating a particular visitor has achieved certain levels of feedback quality, permitting them particular privileges.
1.13.2. Goal of the function: To establish an at-a-glance overview, in a transparent way, of which users are allowed to do what. These badges may be either community-generated/earned, or assigned by particular ASQ departments (i.e. LO, Cert, KO, Membership, Community Development) as appropriate to the needs of those departments (for instance, signifying that LO or KO has verified particular SME credentials, that particular certifications have been earned, or that particular member levels/distinctions/milestones have been achieved). Members have regularly requested such public acclaim, and this is given in offline circumstances; this feature would bring those offline credentials online.
1.13.3. Notes/Assumptions: There may be a need for a field-set expansion in TIMSS to hold ASQ-assigned credentials so that they can be accessed for the online community.
1.13.4. This feature is required

1.14. Requirement #14 – Events, calendar integration

1.14.1. Definition: Ability to set and find events within a single system. This system should also allow those events to be saved in iCal format, so to be integrated with external calendaring software (i.e. Google Calendar, Outlook Calendar, etc.) at the user’s discretion.
1.14.2. Goal of the function: Allow online participants to schedule offline events as appropriate.
1.14.3. Notes/Assumptions: This function should also have multiple layers of access, so that particular events can be designated as private (between “friends”), group-specific (for particular sections, divisions, networks, etc. only), or ASQ-wide. This should be able to replace and integrate the homegrown calendaring system currently in place.
1.14.4. This feature is required

1.15. Requirement #15 – Messaging

1.15.1. Definition: Asynchronous communication between two members of the community.
1.15.2. Goal of the function: Increase perception of community between two users.
1.15.3. Notes/Assumptions: For both messaging and chat there should be an ability to archive the conversation and determine its privacy setting (some conversations may turn out to be valuable to the community at large and could then be posted live for particular segments of the community to see at the discretion of the original participants).
1.15.4. This feature is required

1.16. Requirement #16 – Blogs

1.16.1. Definition: Site where one sufficiently credentialed member can post log entries on a regular basis.
1.16.2. Goal of the function: Reward for highly rated community participants to have their own space for ongoing posts about a particular topic of interest to them.
1.16.3. Notes/Assumptions: Some blogs will still be established by Market Development/Communications mandate, so there will need to be a function whereby administrative staff can turn on the function without the visitor/member having accrued sufficient community-generated ratings to open up access to that function automatically.
1.16.4. This feature is required

1.17. Requirement #17 – Chat

1.17.1. Definition: Synchronous communication between two members of the community.
1.17.2. Goal of the function: Increase perception of community between users.
1.17.3. This feature would be nice to have

1.18. Requirement #18 – Polls

1.18.1. Definition: Ability to gather visitor feedback in shorter, more informal circumstances, with immediate results visible to the visitor.
1.18.2. Goal of the function: Increase interactivity of the site and pique further discussion within other areas of the site.
1.18.3. Notes/Assumptions: There should be some filtering/restrictions in place to only allow one vote per user per poll. This could either take the place of, or take advantage of the poll program already available via QP. The feature should also have the capacity to have segmented community-specific polls (i.e. one for all community participants, one for webinar community participants, and yet a different one for the SOX community participants).
1.18.4. This feature is required

1.19. Requirement #19 - Wiki

1.19.1. Definition: Shared document creation and editing space.
1.19.2. Goal of the function: Allow properly registered community participants to collaborate on documentation online.
1.19.3. This feature would be nice to have

Administration Requirements
1.1. Requirement #1 – System-wide messaging
1.1.1. Definition: System whereby staff administrators can contact all or segmented community members to address community-wide administrative needs or reminders.
1.1.2. Goal of the function: Allow for easy administrative contact with participants to increase the transparency of necessary administrative actions.
Form/Data Collection
Initial access to ASQ’s online communities will be governed by the Customer Records log-in and rules. After pre-set thresholds of number of visits, registered visitors will be invited to fill out more elements of their profiles.

Source: The wiki text is available under the Creative Commons Attribution License agreement http://creativecommons.org/licenses/by/3.0/
Web Functional Specifications Author: Tonya Cannariato