Facebook Storyteller
Software Requirements Specification
EEL5881, Fall 2008
Modification history:
|
Version |
Date |
Who |
Comment |
|
v0.0 |
8/15/00 |
G. H. Walton |
Template |
|
v1.0 |
9/12/2008 |
S. Williams |
Initial Edition |
|
v1.1 |
9/28/2008 |
S. Williams |
Revised after peer review. Various formatting changes |
Team Name: Facebook Storyteller.
Team Members:
Sean Williams <seanthomaswilliams@gmail.com>
Peter Clements <pete3@petemac.cc>
Joan Baldriche <baldriche85@gmail.com>
Anusha Kotha <anushakotha@gmail.com>
Contents of this Document
Make a facebook application that allows a set of friends to tell a round-robin story. That is, one user will contribute one part of the story, and then pass it to a friend, who will then continue the story. The last user to receive the story will be able to determine the user who will receive it next, and if the next user refuses, should be able to choose another user. At any time, all of the involved users should be able to look at the full story.
Team members will use the IEEE 830-1998 standard.
Definitions, Acronyms, and Abbreviations:
Definitions:
Application – In this document, taken to imply “The Facebook Storyteller” application.
Acronyms:
FB – Facebook
DB – Database
API – Application Programming Interface
FBML – Facebook Markup Language
The Facebook website will always be online and available to users.
Users will have access to an internet connection.
Users will have a Facebook account.
Users will allow the Facebook application to access their information.
Dr Damla Turgut - The Software Engineering course instructor.
Facebook Members – Who will benefit from the experience of using the application.
The Facebook corporation – Every new application adds to the inherent value of the Facebook user experience.
Sponsors - Benefit from ads ran by Facebook while using the application.
|
Event Name |
External Stimuli |
External Responses |
Internal data and state |
|
Add Application to Facebook Account |
User clicks “Allow” when prompted to add the application. |
Application is given permissions to access the user's account information. |
The application can now interact with the user. |
|
Remove Application from Facebook Account |
User selects the applications dialog and clicks Remove Application. |
Application permissions are removed and application no longer has access to the users information. |
The application can no longer interact with the user, but previous user contributions are still stored. |
|
Start a new story |
User starts a new story, enters text and submits the story information. |
The story is displayed on the screen and a notification is sent to the user the story was sent to. |
An entry with a new story thread id, story paragraph, writing user and user receiving the story is added to the DB. |
|
Add to an existing story |
User selects the thread of the story to add to and submits new story information. Only functions if the current user has permission. |
If the current user is the user allowed to add to the story, the entry will be added and the entire story will be displayed. |
An entry is added to the DB with the current story thread id, story paragraph, writing user and user receiving the story. |
|
List all stories the user has contributed to |
User views the application page. |
If the user has contributed stories, they will be available individually as links. |
The DB is queried to find all stories matching the user's id number. Stories are returned by thread id. |
|
View a story that the user has contributed to |
The user selects a link containing a story of interest from the application page. |
The selected story is displayed on the application page. User data associated with the story entries is also displayed. |
The DB is queried to find all entries matching the story id. The entries are displayed in chronological order. |
|
Reject adding to a story |
User receives a story and selects reject story. |
Story is reassigned back to the sender. The sender is notified and has the option to pass the story on to another user or add to it again. |
The latest record from the story is selected from the DB and the owner id is modified to the sender id. |
|
Pass a story on without adding information |
The user is viewing a story where he is the most recent owner. User selects a friend and selects pass story. |
Story is reassigned to the friend. The friend is notified and has the option to pass the story on to another user, reject it or add to it again. |
The latest record from the story is selected from the DB and the owner id is modified to the friend id. |
Add application – After the Facebook user logs into their account, they are able to add the application through Facebook's applications dialog or by visiting the application page and clicking add.
Remove application – After the Facebook user logs into their account, they are able to remove the application through Facebook's applications dialog by clicking remove.
Start story – Once users access the application page, they are able to start a new story by default and send it to one of their friends. This is event-based and all communication will be done through Facebook notifications.
Receive story – Once another Facebook user sends a story, the principal user can view the story by clicking on the notification. At this point, the user can view the story.
List stories – Once the user accesses the application page, all stories the user has contributed to are listed. By clicking the story links, the user can view those stories.
View Story – Once the story is being viewed, the user has the options to pass the story, add to the story or reject the story as long as they are the current owner.
Pass Story – The user selects a friend to pass the story to and selects pass story. The friend receives a notification.
Add to story - The user adds information so the story and selects a friend to send it to and submits the information. The friend receives a notification.
Reject story – The user neither selects a friend nor inputs story information. The story is sent back to the previously sending friend. The friend receives a notification.
SECTION 3: Specific Requirements
|
No: FST1 |
|
Statement: The user shall have the ability to add the application to their Facebook profile. |
|
Source: Software Engineering I, Facebook Storyteller Project |
|
Dependency: None |
|
Conflicts: None |
|
Supporting Materials: Use Case Diagram, Facebook API |
|
Evaluation Method: Execution |
|
Revision History: 1.0, S. Williams, Initial Edition |
|
No: FST2 |
|
Statement: The user shall have the ability to remove the application from their Facebook profile. |
|
Source: Software Engineering I, Facebook Storyteller Project |
|
Dependency: FST1 |
|
Conflicts: FST1 |
|
Supporting Materials: Use Case Diagram, Facebook API |
|
Evaluation Method: Execution |
|
Revision History: 1.0, S. Williams, Initial Edition |
|
No: FST3 |
|
Statement: The user shall have the ability receive notifications informing them of story status or updates. |
|
Source: Software Engineering I, Facebook Storyteller Project |
|
Dependency: FST1 |
|
Conflicts: None |
|
Supporting Materials: Use Case Diagram, Facebook API |
|
Evaluation Method: Execution |
|
Revision History: 1.0, S. Williams, Initial Edition |
|
No: FST4 |
|
Statement: The user shall have the ability to start a new story. |
|
Source: Software Engineering I, Facebook Storyteller Project |
|
Dependency: FST1 |
|
Conflicts: None |
|
Supporting Materials: Use Case Diagram, Facebook API |
|
Evaluation Method: Execution |
|
Revision History: 1.0, S. Williams, Initial Edition |
|
No: FST5 |
|
Statement: The user shall have the ability to view stories they have participated in. |
|
Source: Software Engineering I, Facebook Storyteller Project |
|
Dependency: FST1, FST4, FST6, FST9 |
|
Conflicts: None |
|
Supporting Materials: Use Case Diagram, Facebook API |
|
Evaluation Method: Execution |
|
Revision History: 1.0, S. Williams, Initial Edition |
|
No: FST6 |
|
Statement: The user shall have the ability to add to an existing story that they are the current owner of. |
|
Source: Software Engineering I, Facebook Storyteller Project |
|
Dependency: FST1, FST3 |
|
Conflicts: FST7, FST8 |
|
Supporting Materials: Use Case Diagram, Facebook API |
|
Evaluation Method: Execution |
|
Revision History: 1.0, S. Williams, Initial Edition |
|
No: FST7 |
|
Statement: The user shall have the ability to pass a received story to another user. |
|
Source: Software Engineering I, Facebook Storyteller Project |
|
Dependency: FST1, FST3 |
|
Conflicts: FST6, FST8 |
|
Supporting Materials: Use Case Diagram, Facebook API |
|
Evaluation Method: Execution |
|
Revision History: 1.0, S. Williams, Initial Edition |
|
No: FST8 |
|
Statement: The user shall have the ability to reject a received story. |
|
Source: Software Engineering I, Facebook Storyteller Project |
|
Dependency: FST1, FST3 |
|
Conflicts: FST6, FST7 |
|
Supporting Materials: Use Case Diagram, Facebook API |
|
Evaluation Method: Execution |
|
Revision History: 1.0, S. Williams, Initial Edition |
|
No: FST9 |
|
Statement: The user shall have all stories they have contributed to listed. |
|
Source: Software Engineering I, Facebook Storyteller Project |
|
Dependency: FST1, FST6 |
|
Conflicts: None |
|
Supporting Materials: Use Case Diagram, Facebook API |
|
Evaluation Method: Execution |
|
Revision History: 1.0, S. Williams, Initial Edition |
|
No: FST10 |
|
Statement: The user shall be able to select story listings individually. |
|
Source: Software Engineering I, Facebook Storyteller Project |
|
Dependency: FST1, FST3, FST9 |
|
Conflicts: None |
|
Supporting Materials: Use Case Diagram, Facebook API |
|
Evaluation Method: Execution |
|
Revision History: 1.0, S. Williams, Initial Edition |
Add Application
Remove Application
Start a story
Receive a story
List stories
View a story
Pass a story
Add to a story
Reject a story
Inputs:
User ID is non-zero and supplied by the Facebook application
Paragraph is non-null by input check
Thread is provided by the application and is a hidden input
3.2 Interface Requirements:
The Facebook application complies with all Facebook APIs for user interaction.
The application communicates to the local database through SQL queries
Input items are:
Recipient user id – Integer type.
Story text – String type.
Output items are:
Writer's user id – Integer type.
Story “paragraphs” by story thread – String type.
Notifications sent to recipient users – Facebook API.
Only one user can “own” a story at any one time. There are no concurrency issues.
3.3 Physical Environment Requirements:
Any modern computer with a capable internet browser and internet connection.
3.4 Users and Human Factors Requirements:
Users must know how to operate Facebook.
The application will provide user documentation for all application tasks.
Any misuse is handled by the anti-spam filters in Facebook.
3.5 Documentation Requirements:
Application documentation will be available online.
Facebook documentation is available online.
Users must be able to read and understand English.
User id numbers and story information will be maintained from users.
The application server will be hosted remotely.
No funding or physical resources will be required.
All user security issues are handled through Facebook and the users privacy preferences.
Information stored is non-sensitive and for entertainment purposes only.
3.9 Quality Assurance Requirements:
The application:
Must available to users at all times.
Must be reliable and maximize uptime.
Require little to no maintenance after deployment.
Must store and retrieve information as it was inputted.
SECTION 4: Supporting Material
None.
Template created by G. Walton (GWalton@mail.ucf.edu) on Aug 30, 1999 and last updated Aug 15, 2000
This page last modified by Sean Williams (seanthomaswilliams@gmail.com) on 9/28/2008 at 7:30 PM