Name

Date

Reason For Changes

Version

Team

12/15/12

First commit

0.1

Christopher Wood

3/5/13

Updated use cases based on phase 2 features

0.2

ID

Primary Actor

Use Cases

Description

UC-1

RIT SG Representative

User management

Adding and deleting new users from the ASKSG system.

UC-2

RIT SG Representative

View conversation data

Viewing the conversation data that comes in through any of the communication channels (e.g. email, Twilio, or social media).

UC-3

RIT SG Representative

Reply to message

Replying to a specific message on the appropriate channel.

UC-4

RIT SG Representative

Hide message

Hiding a conversation message from the conversation view.

UC-5

RIT SG Representative

Delete conversation

Deleting (archiving) a conversation from the conversation view.

UC-6

RIT SG Representative

Export to Excel

Exporting semantic analysis data on-demand to an Excel file for offline analysis.

UC-7

RIT SG Representative

Configuration

Configuring the parameters of the system (e.g. the scheduling frequency, service or social media subscriptions, etc).

UC-8

RIT SG Representative

Synchronize conversations

Synchronizing the conversation data with the ASKSG system (mainly for social media data).

UC-9

RIT SG Representative

View analytics dashboard

Viewing the analytics dashboard and all of the results from the semantic analysis.

UC-10

RIT SG Representative

Tag message

Tagging a message with a specific user or topic to redirect it to the correct person.

UC-11

RIT SG Representative

Chatterbox analysis

Interface with Chatterbox to perform semantic analysis on a set of conversation data.

UC-12

RIT SG Representative

Mark message as read

Mark a message as read on the conversation view (similar to tagging).

UC-13

RIT Student

View word cloud

Generate and display the word cloud to be viewed by users on the public-facing web page.

Use Case ID:

1

Use Case Name:

User management

Created By:

Team Watchmen

Last Updated By:

Team Watchmen

Date Created:

2/25/13

Date Last Updated:

3/9/13

Actors:

RIT SG Representative

Description:

Adding and deleting new users from the ASKSG system.

Preconditions:

The user is logged into the system.

Postconditions:

None

Normal Flow:

1.0 Add a user

1. The user navigates to the Settings page.
2. The user navigates to the User Management sub-page.
3. The system displays the list of users registered in the system.
4. The user enters the new user credentials into the provided form.
5. The user submits the user information.
6. The system responds with a success notification.

Alternative Flows:

1.1 Delete user (branch after 1.0 : Step 3)

1. Select the delete button next to a highlighted user.
2. Verify the delete operation by selecting “Yes”.
3. The system responds by removing the old user from the User Management sub-page.

Exceptions:

1.0.E.1 EXCEPTION DESCRIPTION (at 1.0 : Step 5)

1. The system indicates that the credentials are incorrect or missing.
2. The user corrects the credentials in the form.
3. The user submits the new user information.
4. The system responds with a success notification.

Includes:

None

Priority:

Moderate

Frequency of Use:

Monthly or weekly

Business Rules:

N/A

Special Requirements:

None

Assumptions:

There exists one root user who cannot be deleted.

Notes and Issues:

Use Case ID:

2

Use Case Name:

View conversation data

Created By:

AUTHOR

Last Updated By:

AUTHOR

Date Created:

DATE

Date Last Updated:

DATE

Actors:

RIT SG representative

Description:

Viewing the conversation data that comes in through any of the communication channels (e.g. email, Twilio, or social media).

Preconditions:

The user is logged into the system.

Postconditions:

The conversation data is displayed.

Normal Flow:

1.0 View conversation data

1. The user selects the dashboard page.
2. The system displays all of the conversation data.

Alternative Flows:

None

Exceptions:

None

Includes:

None

Priority:

High

Frequency of Use:

Daily

Business Rules:

N/A

Special Requirements:

None

Assumptions:

None

Notes and Issues:

Use Case ID:

3

Use Case Name:

Reply to a message

Created By:

Team Watchmen

Last Updated By:

Team Watchmen

Date Created:

2/25/13

Date Last Updated:

3/9/13

Actors:

RIT SG representative

Description:

Replying to a specific message on the appropriate channel.

Preconditions:

The user is logged in.

Postconditions:

The user has responded to a message

Normal Flow:

1.0 Reply to a message

1. The user navigates to the conversation view.
2. The system displays the list of conversation data.
3. The user selects the message reply box underneath the message.
4. The user enters the message response.
5. The user selects “Submit” or hits the return key.
6. The system sends the message to the appropriate channel.

Alternative Flows:

1.1 Reply to a social media message  (branch after 1.0 : Step 2 )

1. The user selects the conversation URL associated with the conversations.
2. The user is redirected to the social media website (e.g. Twitter, Facebook, or Reddit).
3. The users enters a response as needed using the external system’s interface.

Exceptions:

None

Includes:

None

Priority:

High

Frequency of Use:

DAILY FREQUENCY

Business Rules:

N/A

Special Requirements:

None

Assumptions:

None

Notes and Issues:

Social media responses are easier to manage using the external service provider’s interface, which is why ASKSG does not support the ability to allow users to view this other information.

Use Case ID:

4

Use Case Name:

Hide message

Created By:

Team Watchmen

Last Updated By:

Team Watchmen

Date Created:

2/25/13

Date Last Updated:

3/9/13

Actors:

RIT SG representative

Description:

Hiding a conversation message from the conversation view.

Preconditions:

The user is logged in.

Postconditions:

A message or conversation is hidden.

Normal Flow:

1.0 Hide message

1. The user navigates to the conversation view.
2. The system displays the conversation data.
3. The user selects the hide button in the conversation or message pane.
4. The system hides the message from the view.

Alternative Flows:

None

Exceptions:

None

Includes:

None

Priority:

Moderate

Frequency of Use:

DAILY FREQUENCY

Business Rules:

N/A

Special Requirements:

None

Assumptions:

None

Notes and Issues:

Use Case ID:

5

Use Case Name:

Delete conversation

Created By:

Team Watchmen

Last Updated By:

Team Watchmen

Date Created:

2/25/13

Date Last Updated:

3/9/13

Actors:

RIT SG representative

Description:

Deleting (archiving) a conversation from the conversation view.

Preconditions:

The user is logged in.

Postconditions:

A conversation is deleted (archived).

Normal Flow:

1.0 Delete message

1. The user navigates to the conversation view.
2. The system displays the conversation data.
3. The user highlights a conversation of interest.
4. The user selects the “delete” button in the conversation view pane.
5. The system deletes (archives) the conversation and removes it from the conversation view.

Alternative Flows:

None

Exceptions:

None

Includes:

None

Priority:

Moderate

Frequency of Use:

Weekly frequency

Business Rules:

N/A

Special Requirements:

None

Assumptions:

None

Notes and Issues:

Email and SMS messages will be archived, and social media information will be deleted from the ASKSG system because it is already persisted on the corresponding service.

Use Case ID:

6

Use Case Name:

Export to Excel

Created By:

Team Watchmen

Last Updated By:

Team Watchmen

Date Created:

2/25/13

Date Last Updated:

3/9/13

Actors:

RIT SG representative

Description:

Exporting semantic analysis data on-demand to an Excel file for offline analysis.

Preconditions:

The user is logged in.

Postconditions:

The system produces an Excel file for the user to download.

Normal Flow:

1.0 Export to Excel

1. The user navigates to the analytics view.
2. The system displays the most recent analytics data.
3. The user selects the “Export to Excel” tab in the view.
4. The system displays the options page for specifying what information to generate for the Excel file.
5. The user enters the appropriate information and clicks the “Generate File” button.
6. The system parses the user parameters, creates, the Excel file, and presents it to the user to be downloaded.

Alternative Flows:

1.1 Default parameters (branch after 1.0 : Step 4 )

1. The user clicks the “Generate File” button.
2. The system creates the Excel file and presents it to the user to be downloaded.

Exceptions:

None

Includes:

None

Priority:

Moderate

Frequency of Use:

Monthly

Business Rules:

N/A

Special Requirements:

None

Assumptions:

It is assumed that only the semantic analysis data will be inserted into the Excel file and that no Excel-compatible charts will be produced by the file. The spreadsheet will only contain raw data that the user may use to create their own charts and figures.

Notes and Issues:

Use Case ID:

7

Use Case Name:

Configuration

Created By:

Team Watchmen

Last Updated By:

Team Watchmen

Date Created:

2/25/13

Date Last Updated:

3/9/13

Actors:

RIT SG representative

Description:

Configuring the parameters of the system (e.g. the scheduling frequency, service or social media subscriptions, etc).

Preconditions:

The user is logged in.

Postconditions:

System parameters are (potentially) changed.

Normal Flow:

1.0 Configuration.

1. The user navigates to the configuration view.
2. The system displays the configuration view.
3. The user navigates to the options sub-view.
4. The system displays the options sub-view.
5. The user enters new configuration options (scheduling and polling frequency, SMS analysis bounds, etc) and then selects “Submit”/
6. The system parses the new configuration options and then persists the information to the database.

Alternative Flows:

1.1 Configure social media subscriptions (branch after 1.0 : Step 2)

1. The user navigates to the services sub-view.
2. The system displays the services sub-view.
3. The user modifies the service provider information and credentials as needed (i.e. Twitter API tokens, Facebook credentials, etc), and then selects “Update”.
4. The system persists the new service configuration information and resets this information in the backend for immediate use.

Exceptions:

None

Includes:

None

Priority:

High

Frequency of Use:

Monthly

Business Rules:

N/A

Special Requirements:

None

Assumptions:

None

Notes and Issues:

Configurability requirements may change over time, so there may need to be more sub-views to the configuration view that are responsible for modifying the system parameters. This will need to be addressed by future developers.

Use Case ID:

8

Use Case Name:

Synchronize conversations

Created By:

Team Watchmen

Last Updated By:

Team Watchmen

Date Created:

2/25/13

Date Last Updated:

3/9/13

Actors:

RIT SG representative

Description:

Synchronizing the conversation data with the ASKSG system (mainly for social media data).

Preconditions:

The service provider credentials are installed in the ASKSG system and the ASKSG instance has been authenticated to access new data from each provider.

Postconditions:

The conversation data in the frontend is synchronized with the conversation data scraped from the service providers.,

Normal Flow:

1.0 Synchronize conversations

1. When the polling wait period has expired, each service will query the external services for new conversation data for ASKSG.
2. The services will respond with new and modified conversation data.
3. The system will update the conversation data in the backend databases accordingly.

Alternative Flows:

None

Exceptions:

None

Includes:

None

Priority:

High

Frequency of Use:

Daily

Business Rules:

N/A

Special Requirements:

None

Assumptions:

The polling wait period is configured by the ASKSG system administrator(s) so that new conversation data will actually be requested by the external service.

Notes and Issues:

Use Case ID:

9

Use Case Name:

Authenticate with Facebook

Created By:

Team Watchmen

Last Updated By:

Team Watchmen

Date Created:

3/18/13

Date Last Updated:

3/18/13

Actors:

RIT SG ASKSG Administrator

Description:

Authenticating with Facebook so the system can get Facebook posts and write comments.

Preconditions:

The ASKSG Facebook App “App ID” and “App Secret” have been copied from the ASKSG Facebook App configuration page.

Postconditions:

ASKSG has the OAuth Token needed to communicate with Facebook.

Normal Flow:

1.0 Authenticate with Facebook

1. On the Configuration tab, the user presses the button to add a new Facebook service.
2. The user enters the ASKSG Facebook App App ID and App Secret and presses the Authenication button.
3. The user is directed to Facebook, and must log in to Facebook as the ASKSG user account if they are not already.
4. The user accepts the ASKSG Facebook App permissions and is redirected to ASKSG, which receives the OAuth one-time code.
5. ASKSG requests an OAuth token from Facebook and saves it.

Alternative Flows:

None

Exceptions:

None

Includes:

None

Priority:

High

Frequency of Use:

Every 2 months (Facebook OAuth tokens expire after 60 days)

Business Rules:

N/A

Special Requirements:

None

Assumptions:

The user needs to be able to access the ASKSG Facebook App and log in as the ASKSG Facebook user.

Notes and Issues:

Use Case ID:

8

Use Case Name:

Synchronize conversations

Created By:

Team Watchmen

Last Updated By:

Team Watchmen

Date Created:

2/25/13

Date Last Updated:

3/9/13

Actors:

RIT SG representative

Description:

Synchronizing the conversation data with the ASKSG system (mainly for social media data).

Preconditions:

The service provider credentials are installed in the ASKSG system and the ASKSG instance has been authenticated to access new data from each provider.

Postconditions:

The conversation data in the frontend is synchronized with the conversation data scraped from the service providers.,

Normal Flow:

1.0 Synchronize conversations

4. When the polling wait period has expired, each service will query the external services for new conversation data for ASKSG.
5. The services will respond with new and modified conversation data.
6. The system will update the conversation data in the backend databases accordingly.

Alternative Flows:

None

Exceptions:

None

Includes:

None

Priority:

High

Frequency of Use:

Daily

Business Rules:

N/A

Special Requirements:

None

Assumptions:

The polling wait period is configured by the ASKSG system administrator(s) so that new conversation data will actually be requested by the external service.

Notes and Issues:

Use Case ID:

8

Use Case Name:

Synchronize conversations

Created By:

Team Watchmen

Last Updated By:

Team Watchmen

Date Created:

2/25/13

Date Last Updated:

3/9/13

Actors:

RIT SG representative

Description:

Synchronizing the conversation data with the ASKSG system (mainly for social media data).

Preconditions:

The service provider credentials are installed in the ASKSG system and the ASKSG instance has been authenticated to access new data from each provider.

Postconditions:

The conversation data in the frontend is synchronized with the conversation data scraped from the service providers.,

Normal Flow:

1.0 Synchronize conversations

7. When the polling wait period has expired, each service will query the external services for new conversation data for ASKSG.
8. The services will respond with new and modified conversation data.
9. The system will update the conversation data in the backend databases accordingly.

Alternative Flows:

None

Exceptions:

None

Includes:

None

Priority:

High

Frequency of Use:

Daily

Business Rules:

N/A

Special Requirements:

None

Assumptions:

The polling wait period is configured by the ASKSG system administrator(s) so that new conversation data will actually be requested by the external service.

Notes and Issues:

Use Case ID:

8

Use Case Name:

Synchronize conversations

Created By:

Team Watchmen

Last Updated By:

Team Watchmen

Date Created:

2/25/13

Date Last Updated:

3/9/13

Actors:

RIT SG representative

Description:

Synchronizing the conversation data with the ASKSG system (mainly for social media data).

Preconditions:

The service provider credentials are installed in the ASKSG system and the ASKSG instance has been authenticated to access new data from each provider.

Postconditions:

The conversation data in the frontend is synchronized with the conversation data scraped from the service providers.,

Normal Flow:

1.0 Synchronize conversations

10. When the polling wait period has expired, each service will query the external services for new conversation data for ASKSG.
11. The services will respond with new and modified conversation data.
12. The system will update the conversation data in the backend databases accordingly.

Alternative Flows:

None

Exceptions:

None

Includes:

None

Priority:

High

Frequency of Use:

Daily

Business Rules:

N/A

Special Requirements:

None

Assumptions:

The polling wait period is configured by the ASKSG system administrator(s) so that new conversation data will actually be requested by the external service.

Notes and Issues:

Use Case ID:

8

Use Case Name:

Synchronize conversations

Created By:

Team Watchmen

Last Updated By:

Team Watchmen

Date Created:

2/25/13

Date Last Updated:

3/9/13

Actors:

RIT SG representative

Description:

Synchronizing the conversation data with the ASKSG system (mainly for social media data).

Preconditions:

The service provider credentials are installed in the ASKSG system and the ASKSG instance has been authenticated to access new data from each provider.

Postconditions:

The conversation data in the frontend is synchronized with the conversation data scraped from the service providers.,

Normal Flow:

1.0 Synchronize conversations

13. When the polling wait period has expired, each service will query the external services for new conversation data for ASKSG.
14. The services will respond with new and modified conversation data.
15. The system will update the conversation data in the backend databases accordingly.

Alternative Flows:

None

Exceptions:

None

Includes:

None

Priority:

High

Frequency of Use:

Daily

Business Rules:

N/A

Special Requirements:

None

Assumptions:

The polling wait period is configured by the ASKSG system administrator(s) so that new conversation data will actually be requested by the external service.

Notes and Issues: