ASKSG
Requirements Specification
Version 0.3 (awaiting approval)
Prepared by Team Watchmen
12/06/12
Revision History
Name | Date | Reason For Changes | Version |
Christopher Wood | 12/6/12 | Stubbed out the document with the required sections | 0.1 |
Christopher Wood | 12/29/12 | Started filling out content | 0.2 |
Christopher Wood | 2/27/12 | Continued filling out content and finished the first preliminary draft | 0.3 |
Contents
2.2. User Classes and Characteristics
2.4. Design and Implementation Constraints
3.1. System Feature: Collate student conversations from SMS text and email messages
3.4. System Feature: Perform semantic analysis on conversation data and view the results
3.6. System Feature: Manage SG users that are allowed to use the system
4. External Interface Requirements
5. Other Nonfunctional Requirements
5.1. Security and Privacy Requirements
1. Introduction
1.1. Purpose
ASKSG is a comprehensive platform that corrals student ideas, questions, and concerns from a variety of online sources into a single portal for the RIT Student Government (SG). The goal is to enhance their relationship with students and to provide a channel for advice on what the governance body should focus on, such as programs or policies on campus to change, replace or recreate. ASKSG provides a common interface for all directed student questions and inquiries to provide an overarching picture of student sentiment. This interface, which meets federal accessibility requirements, will funnel student questions submitted through SMS, phone calls, and social media private messaging, and then enable responses to be reciprocated using the same incoming interface.
ASKSG will also integrate with social media services (e.g. Reddit, Twitter, and Facebook) to passively collect and collate data from student interactions and conversations and analyze it to identify patterns of shared thought among groups of students. Such information will be available to Student Government through a secure portal and formatted to allow for easy use in legislative, promotional and analytic duties. From this work, SG will have quantitative evidence to sustain policy changes and promote new programs and services, to respond promptly to direct inquiries, and indirectly identify issues discussed online by the student body. This will promote a new standard of information availability and enable the RIT SG to predict student interest and opinion changes over time to make the best decisions for the organization’s constituency.
This document covers the main functional and nonfunctional requirements for ASKSG, including additional requirements for usability, product deliverables, operating environment constraints, and security concerns.
1.2. Project Scope
Refer to the ASKSG Vision and Scope document for information regarding the project scope.
2. Overall Description
2.1. Product Perspective
ASKSG is a web application that collates student communications from a variety of sources, including text messages, emails, Twitter tweets, Facebook posts, and Reddit threads in a single interface to enable SG representatives to quickly and easily respond to student inquiries and make informed school-wide decisions. ASKSG will also conduct fundamental semantic analysis on this conversation data using text analysis and simple word counts. The results of this analysis will then be funneled into a presentation-friendly report for the SG to use for critical decisions. All of this functionality is captured in the system context diagram shown in Figure 1.
Figure 1. System context diagram for ASKSG.
2.2. User Classes and Characteristics
RIT SG Representative
SG representatives are the primary ASKSG users. They are responsible for handling all incoming student conversation data and utilizing the programatically-generated reports to make internal decisions. These users are not required to have any technical experience to use the system. At a minimum, they should know how to configure the external social media subscriptions that are watched when the system is live. Each representative will have their own account to log in and use the ASKSG system, and each account will have the same set of privileges to handle conversations and application settings.
RIT Student
RIT students will only interface with the public-facing web page for the system. They will use the information on this page to determine the various ways to communicate with the SG representatives through the ASKSG system. Their usage of this system is purely informational - they have no role in actually managing conversations or using reports within the scope of the system.
2.3. Operating Environment
OE-1: Users can access the system from any geographical location (i.e. they need not be on the RIT campus).
OE-2: The ASKSG server will run on a custom built machine with a static IP address registered with the RIT DNS.
OE-3: All conversation data will be generated external from the ASKSG web application (i.e. through SMS text messages, email messages, and social media content).
OE-4: The system must persist relevant conversation data even when the web application becomes unavailable.
OE-5: The ASKSG dashboard interface shall only be available to registered SG representatives who serve as application administrators.
2.4. Design and Implementation Constraints
CO-1: The design will rely on external tools to implement the social media APIs correctly.
CO-2: The system architecture will be designed to horizontally scale to serve many clients.
CO-3: The system will be implemented using free and open source libraries, frameworks, and tools. Only paid external services for semantic analysis and SMS text messaging will be incorporated into the design.
2.5. User Documentation
UD-1: The system shall be delivered with a set of installation documentation required to migrate the ASKSG application to a new machine should this situation arise.
UD-2: The system shall be delivered with a complete set of logistical documentation, including an application security assessment and hosting pricing report.
UD-3: The student public-facing page will contain step-by-step instructions on how to submit conversation data to the ASKSG system.
3. System Features
3.1. System Feature: Collate student conversations from SMS text and email messages
Description and Priority
This feature will enable the system to collect all of the student messages and inquiries in a single, unified interface. It is one of the highest priority features for the system next to performing semantic analysis on the conversational data.
Functional Requirements
REQ-F1-1: The system shall accept conversation data input from Twilio (SMS) and email communication mediums.
REQ-F1-2: The system shall put all email and SMS messages in the same interface and provide a common interface for replying to these messages.
3.2. System Feature: Collate student conversations from social media channels, including Twitter, Facebook, and Reddit
Description and Priority
This feature will enable the system to collect the conversation data from the Twitter, Facebook, and Reddit social media channels.
Functional Requirements
REQ-F2-1: The system shall poll the Twitter, Facebook, and Reddit social media channels for new conversation data directed towards ASKSG or related to topics of interest.
REQ-F3-2: The system shall display all social media conversation data in the same interface and provide a common interface that provides a link to the location where these messages can be responded to outside of the ASKSG system.
3.3. System Feature: Filter, sort, and search conversation data for viewing
Description and Priority
This feature enables ASKSG users to filter conversation data based on a set of fixed queries (i.e. the service provider through which the conversations came, whether or not the message was read or unread, etc), and also sort the messages based on a variety of criteria to enable more efficient response times. This feature also enables ASKSG users to filter through existing conversation data using custom string-based searches.
Functional Requirements
REQ-F3-1: The system shall enable the user to filter conversations (not messages) based on services, read/unread tags, and tags for specific topics/people.
REQ-F3-2: The system shall enable the user to enter strings to filter the conversation data that is displayed based on the contents of the string and the conversation messages.
REQ-F3-3: The system shall enable the user to sort the conversations based on time of arrival, topic, and service.
3.4. System Feature: Perform semantic analysis on conversation data and view the results
Description and Priority
This feature will enable the ASKSG system to asynchronously perform semantic analysis on all conversation data and then provide the results from this analysis to the SG users upon request. This is a high priority feature for the system.
Functional Requirements
REQ-F4-1: The system shall use the Chatterbox service to analyze all text conversation data and store the result with each corresponding message.
REQ-F4-2: The system shall periodically send blocks of new messages to be analyzed, rather than streaming them to Chatterbox in real-time.
3.5. System Feature: Generate visual reports that show semantic analysis results with the relevant conversation data
Description and Priority
This feature describes how the system will generate images from the semantic analysis data, such as those that show the semantic weight for all messages relating to specific topics, and render them for the user to see and download.
Stimulus/Response Sequences
Stimulus: An SG user (administrator) queries the system for the conversation analysis results.
Response: The system either parses the user query, pulls the most up-to-date analysis data, generates the appropriate plots and figures, and displays them to the user.
Functional Requirements
REQ-F5-1: The system shall support the ability to generate plots of semantic data (e.g. plots of topics versus their aggregate semantic weight across all conversation data) on demand.
REQ-F5-2: The system shall display the plots of semantic data to the user and allow them to save the files as images.
3.6. System Feature: Manage SG users that are allowed to use the system
Description and Priority
This feature requires current SG users to be able to add and remove other SG users from the system, thus extending the user base to enable quicker message response times.
Stimulus/Response Sequences
Stimulus: A current SG user visits the “Add New User” page and enters the new user information, including their email address and temporary password.
Response: The system creates and persists a new user to the database and sends an appropriate email to the new user that tells them about this change.
Functional Requirements
REQ-F6-1: The system shall allow existing SG users to add new users to the system.
REQ-F6-2: The system shall send an email notification to new users once they are registered.
4. External Interface Requirements
4.1. User Interface
UI-1: The ASKSG web application interface shall comply with WC3 standards.
UI-2: The ASKSG web application shall strive to optimize screen real estate for all device resolutions.
UI-3: The ASKSG web application shall support the usage of keyboard and mouse input to navigate through the various web pages.
4.2. Communication Interfaces
CI-1: The system shall poll the appropriate social media channels for new conversation data in a periodic fashion.
CI-2: The system shall interface with the Twilio communication service to send and receive SMS text messages.
CI-3: The system shall rely on the Spring Social library to handle Twitter and Facebook communications.
CI-4: The system shall use the Reddit REST API (with OAuth implemented) to receive Reddit conversation data.
5. Other Nonfunctional Requirements
5.1. Security and Privacy Requirements
SE-1: The system shall not store any personal identification information for users involved with conversations.
5.2. Performance requirements
PR-1: The system shall horizontally scale to handle arbitrarily large numbers of clients.
PR-2: The social media polling shall not render the ASKSG web application unavailable.