Author: Group 03 Yuly Suvorov, Luke Harvey, Ben Holland, Jordan Cook, Michael Higdon. All Completed SRS2 Steps

Transcription

1 Software Requirements Document for Graffiti Author: Group 03 Yuly Suvorov, Luke Harvey, Ben Holland, Jordan Cook, Michael Higdon Version Date Author Change /13/ SM Initial Document /22/ LH + Updated Section 1 08 MH / 22/08 All Completed SRS2 Steps Table of Contents 1 Introduction Purpose Scope Definitions, acronymns, abbreviations References Overview Overall Description Product Perspective Product functions User characteristics Constraints Assumptions and Dependencies Specific Requirements External Interface Requirements FEATURES Performance requirements Design Constraints Software System Attributes Other Requirements. 24

2 1 Introduction 1.1 Purpose This document is to present a detailed description of the Graffiti application for the Android mobile operating system. It will explain the purpose, features, and interfaces of the Graffiti system. It will specify constraints and list actor interactions. This document was created with both developers and customers in mind. 1.2 Scope This document will contain the details of the development and requirements of the Graffiti project. It consists of project definitions, use cases and diagrams, sequence diagrams, concepts of operation, and general details about the project's requirements. 1.3 Definitions, acronyms, abbreviations Term Login View Make Post View Reply Post View Profile View Zone View Post View Streetname Street Cred Anonymous User Registered User Description The technical reference to the login screen The technical reference to the screen that allows the user to make a new post The technical reference to the screen that allows the user to reply to a post The technical reference to the screen that allows the user to view and change their profile The technical reference to the screen that allows the user to view the posts in the nearby area The technical reference to the screen the screen that allows the user view the content of a post Equivalent to a login username A peer review point value system to review user posts A user privilege level that only allows anonymous posting A user privilege level that allows posting along with anonymous posting and allow interaction with peer review system

3 Administrative User A user level privilege that provides all lower level privileges and administrative data access 1.4 References Google's Android OS Homepage Overview [OMIT] 2 Overall Description Graffiti is a social, GPS based, mobile message posting system for the Android operating system. It is a way to connect with strangers and interact with the environment. Think about graffiti on the side of the a building or written on a bathroom wall. Graffiti is the digital enhancement of this interaction. If you are at a bar and you want to post a photo of you and your friends, the photo will be linked to that location so that anyone who goes there can view it. If you had a bad or good experience at a location, you can tell the Graffiti community about it. Graffiti also has a web interface that allows you to track your posts and view Street Cred, Graffiti's peer review system. 2.1 Product Perspective The Android platform is a system that is still in development. There is a competing product called Graffitio developed for the iphone, but unlike our product it is covered by Apple's Non-Disclosure Act which prevents sharing any code that uses the Apple iphone SDK. Our product on the other hand could be released as an open source project which users could view and modify. While the project itself is open source and can be downloaded freely, there still exists potential for commercial profit. Advertizing space entries in the database could be sold to make a profit Concept of Operations When the application is loaded from the Android application menu the Graffiti Login screen is loaded. The user is given the option to Login anonymously or with a registered username, recover his or her lost password, or register a new account name. When the user logs into the application the Zone View screen is loaded, displaying topics in the nearby area. From the Zone View screen the user may view topics, and after selecting a topic from the Zone view screen the Topic View screen is displayed. At the Topic View screen the user

4 may select an individual post from the Topic View screen to view in the Post View Screen. After viewing the post the user may either reply to the post or return to a previous screen. At anytime the user may logout or navigate to the Profile screen to update thier user profile Major User Interfaces See Appendix A for screenflow diagram Example Screenshot and description See Appendix B for screenshots and descriptions Hardware Interfaces Hardware interfaces include an Android cellphone and a computer terminal for the web interface Software Interfaces // example: CGI-URL or function signatures etc (OMIT for now) Communication Interfaces // example: modem etc (OMIT for now) Memory Constraints // RAM, and other storage constraints (OMIT for now) Operations // special operations (if any) (OMIT for now) Site Adaptation Requirements //ex: Japanese language etc (OMIT for now)

5 2.2 Product functions Major Use case User logs in using a registered account, he then views nearby posts on zone view. He decides to read a post which opens the topic view. User selects the first post in the topic view which opens post view of that topic. The user then hits the reply button and responds to post. Then user selects log out from the menu and exits the program Example use case Title: Login Description: The purpose of this view is to allow an actor to login in order to gain access to their profile and to have posts tagged with their user name. Primary Actors: Administrator, Registered User, Anonymous User Basic Flow:

6 1. The actor loads graffiti and types in his username and password into the text boxes and selects the login button. 2. Upon successful login, the users profile is loaded and the screen then changes to Zone View. 3. Preferences are loaded to display all posts in area. Alternate Flows: 1. The actor loads graffiti and selects the login anonymously button. 2. No profile is loaded. 3. The screen changes to Zone View with default preferences. 4. The actor types in his username and password but they are incorrect. 5. The actor is prompted with a window asking him to re-enter his login information again. Preconditions: User has just launched application, is brought to login screen. Postconditions: The actor is successfully logged in with preferences loaded.

7 Title: New User Description: This use case is a way for the user to create his profile and set his settings using a browser. Primary Actors: Administrator, Registered User, Anonymous User Basic Flow: 1. The actor loads graffiti and selects New User? link. 2. A web Browser is loaded with a registration form. 3. The user enters in his profile information including desired username and password and selects submit. Alternate Flows: 1. The actor loads graffiti and selects Forgot password? link. 2. A web browser is loaded with a password recovery form. 3. The user enters password retrieval information and a new password is sent to him. Preconditions: Actor is at login screen and has no username and password or forgotten username and password. Postconditions: The actor is returned to the login screen with a valid username and password.

8 Title: Reply to a Post Description: User wishes to reply to an existing post. He is able to accomplish this through the 'Reply to a Post' screen. Primary Actors: Administrator, Registered User, Anonymous User Basic Flow: 1. User enters the message he wishes to use as a reply 2. User clicks 'upload image' and selects an image to upload 3. User presses 'Post!' 4. Message is sent from phone to server with a date, time, and position stamp. 5. Server sends query to database adding a row for the reply. 6. User is returned to the 'Post View' screen. Alternative Flows: 1. Same as regular flow, but step 2 is omitted. 2. In other words, an image is not uploaded as part of the reply. Preconditions: User is logged in and on the 'Reply to a Post' screen. Postconditions: User is returned to the 'Post View' screen. The reply message is added to the database. Title: Cancel Reply Description: User selects 'Reply to a Post' but does not wish to actually send the reply. Instead the user chooses to cancel his action and navigate to a different screen, discarding his reply. Primary Actors: Administrator, Registered User, Anonymous User

9 Basic Flow: 1. User clicks the 'Menu' button. 2. Users clicks either 'Profile', 'Zone View', or 'Topic View' 3. The reply message is discarded. 4. User is navigated to the screen he chose. Alternative Flow: 1. In step 2, user clicks 'Logout'. 2. The user is logged off and returned to the login screen. Preconditions: User is logged and on the 'Reply to a Post' screen. Postconditions: The reply message is not added to the database. Title: Select Make Post Description: User wishes make a new post. He is able to accomplish this through the Make Post' screen. Primary Actors: Administrator, Registered User, Anonymous User Basic Flow: 1. User enters the message he wishes to use as a new post 2. User clicks 'upload image' and selects an image to upload 3. User presses 'Post!' 4. Message is sent from phone to server with a date, time, and position 5. Server sends query to database adding a row for the reply. 6. User is returned to the the 'Zone View' screen. Alternative Flows: 1. Same as regular flow, but step 2 is omitted.

10 2. In other words, an image is not uploaded as part of the reply. Preconditions: User is logged in, User is on the Make Post' screen. Postconditions: User is returned to the 'Zone View' screen. The new post message is added to the database. Title: Cancel Make Post Description: User selects Make Post' but does not wish to actually make a new post. Instead the user chooses to cancel his action and navigate to a different screen, discarding his new post. Primary Actors: Administrator, Registered User, Anonymous User Basic Flow: 1. User clicks the 'Menu' button. 2. Users clicks either 'Profile', 'Zone View', or 'Topic View' 3. The new post message is discarded. 4. User is navigated to the screen he chose. Alternative Flow: 1. In step 2, user clicks 'Logout'. 2. The user is logged off and returned to the login screen. Preconditions: User is logged in and on the 'Make Post' screen. Postconditions: The reply message is not added to the database.

11 Title: Select Zone View Description: This use case details the selection and loading of the Zone View screen. Primary Actors: Administrator, Registered User, Anonymous User Basic Flow: 1. User presses the menu button, the main menu frame is loaded 2. User selects "Zone View" from the main menu 3. System loads the Zone View screen and returns messages within range Alternative Flow: 1. User presses the menu button, menu frame is loaded 2. User selects Logout, About, Profile, or Zone View 3. System navigates to the user selected screen Precondition: User has logged in via the Login screen

12 Title: Select Topic View Description: This use case details the selection and loading of the Topic View screen. Primary Actors: Administrator, Registered User, Anonymous User Basic Flow: 1. User selects a message from the Zone View 2. System returns the selected message and any replies Alternative Flow: 1. User presses the menu button, menu frame is loaded 2. User selects Logout, About, Profile, or Zone View 3. System navigates to the user selected screen Preconditions: User has logged in via the Login screen and has selected Zone View.

13 2.3 User characteristics This application is intended for users ages 10 and up with various levels of education. Projected Screen Usage Login Screen - High Frequency Zone View - High Frequency Topic View - High Frequency View Post - High Frequency Reply Post - Medium Frequency Make Post - Medium Frequency Profile - Low Frequency About - Low Frequency 2.4 Constraints // all conditions that may limit design options (INCLUDE NON FUNCTION CONSTRAINTS) 2.5 Assumptions and Dependencies // hardware and software assumptions and dependencies 3 Specific Requirements // Here you need to put in details (if any). Mark items [None] if you do not have any information.

14 3.1 External Interface Requirements User Interfaces See Appendix A: Screen Shots Hardware Interfaces [None] Software Interfaces [None] Communications Interfaces Graffiti will use the internet to communicate with the graffiti servers. 3.1 External Interface Requirements 3.2 Features Profile Customization - Jordan User Profile Priority Benefit Penalty Cost Risk Low Medium Medium Medium Low Description: The system shall store information about the user to be made available as a user profile. This includes content supplied by the user as well as content supplied by the system. The user will have options for editing their own profile, and will able to view their own profile as well as the profiles of other users as static web pages. Stimulus/Response Sequence: From the main menu, the user can select User Profile, and the system will query the database for user information and return the profile page. From the profile page, the user can select Edit Profile, and the system will return a page allowing the user to input and modify profile information. Functional Requirements: REQ-1: The user shall have the option to input descriptive text into a text field, which is then submitted to the system and stored on the database REQ-2: The user shall have the option to input an image into an image upload dialogue, which is then submitted to the system and stored on the database

15 REQ-3: The system shall generate an overall street cred rating for the user based on the combined peer ratings of the user s individual posted messages, which will be stored on the database REQ-4: When a user s profile is viewed, the system shall query the database and return the user s street cred rating, user-specified information, and avatar image REQ-5: Other information stored on the database about the user, such as username, date joined, last login date, and number of posts, shall also be displayed on the profile. Inverse Requirements: REQ-6: The system shall not allow the user to edit the profiles of other users Error Handling Requirements: REQ-7: When entering descriptive text, if no text is supplied or the text exceeds a certain character limit, the system shall return a notification that the text was not properly submitted REQ-8: When uploading an image, if the user does not specify a valid image or the image exceeds a certain filesize or dimensions limit, the system shall return a notification that the image was not properly submitted REQ-9: If a connection with the database cannot be made, the system shall return an error notification Message filtering Priority Benefit Penalty Cost Risk Low Medium Low Medium Low Description: The user shall have the option to filter messages based on various criteria. Stimulus/Response Sequence: From the Edit Profile page, the user can select 'Message Filtering,' and the system will return a page containing message filtering options. If the user changes options an submits the changes, the system will store the settings in the database and return the user to the Edit Profile page. Functional Requirements: REQ-1: The system shall provide an option for the user to filter messages by date and time of post REQ-2: The system shall provide an option for the user to filter messages by username. The user will input a list of usernames to filter out into a text field rating REQ-3: The system shall provide an option for the user to filter messages by cred

16 REQ-4: When the user submits any changes made, the system will store the settings in the database Inverse Requirements: REQ-5: The system shall not save changed settings if the user navigates away from the page before submitting changes. Error Handling Requirements: REQ-6: If a connection with the database cannot be made, the system shall return an error notification Authentication User Authentication - Ben Priority Benifit Penalty Cost Risk High High High Medium Low Description: Registered users have the ability to authenticate a sesssion with the server which allows the users to claim a registered username stopping other users from using the same username. Unregistered users cannot use a specified username, they can only post as anonymous. Stimulus/Response Sequence: The user opens the application and is prompted to either log in or log in anonymously. The user chooses to log in using a registered username. The user enters their registered username and password. The password is hashed and sent to the server which will check for a matching username and hashed password in the database. The system confirms that the username exists and the supplied hashed password matches the stored hashed password. Functional Requirements: REQ-1: The user must be allowed to log into the system anonymously REQ-2: The user must be allowed to log into the system using their registered username REQ-3: The system must provide a password recovery mechanism Inverse Requirements: REQ-4: The system should not allow an unauthorized user to log into a registered account REQ-5: The system must not store an unhashed value of an account password Error Handeling Requirements: REQ-6: The system should should inform the user if a username or password is incorrect Messages Message Posting - Luke

17 Priority Benefit Penalty Cost Risk High High High Medium Low Description: The message posting function should create a connection with the Graffiti server and submit the information the actor entered into the make new post screen fields. Stimulus/Response Sequence: From the make new post view the user enters his desired message into the fields and then presses the "Post!" button. This causes the software to create a connection with the Graffiti server, convert the user entered information into XML format, and then send the post to the Graffiti server. Once the post is successful the view will be switched to the post view screen with the user's new post displayed. Functional Requirements: REQ-1: If the application is interrupted by a phone call the system should save all the user entered information and restore it after the system is restored. REQ-2: When the user presses "Post!" and they have at least included a title the software must make a valid connection with the server REQ-3: Once a successful connection is made with the server, the system must parse the user input into a format to be sent to the server REQ-4: The system must successfully send the message to the server REQ-5: The system must allow the user to be able to upload pictures with their post REQ-6: The system must allow the user to post anonymous messages REQ-7: The system must allow the user to post messages using a registered username Inverse Requirements: REQ-8: The system should not drop messages REQ-9: The system should not switch views automatically unless the message has been published to the server Error Handling Requirements: REQ-10: The system should notify the user if a connection with the server cannot be made title REQ-11: The system should notify the user if he tries to post and doesnt have a Message Browsing- Luke Priority Benefit Penalty Cost Risk High High High Low Low

18 Description: The message browsing function should get the users GPS location and send a request to the Graffiti server to retrieve all of the visible posts in the area. Stimulus/Response Sequence: When the user selects zone view from the menu or logs in the software should create a connection with the graffiti server. It then retrieves all relevant information from the server and displays a list of the available posts to the user. The user may select a post which is then retrieved from the server and post view will then be loaded with the relevent post information. Functional Requirements: REQ-1: If the application is interrupted by a phone call, the user interface should be reloaded upton return to the system REQ-2: The system should display a list of all messages in the GPS range of the user when in zoneview REQ-3: If the user selects a message in zone view it should be loaded into post view REQ-4: If any pictures are associated with a post, they must be displayed REQ-5: If the user moves locations, zoneview should update the visible post list REQ-6: If the user selects reply, post make reply post view should be loaded with that message information Inverse Requirements: REQ-7: The system should not display messages that are not in range REQ-8: The system should not display messages that are not part of the current filter settings. REQ-9: The system should not display messages that are not within GPS range of the user Error Handling Requirements: REQ-10: The system should notify the user if a connection with the server cannot be made GPS GPS - Ben Priority Benifit Penalty Cost Risk High High High Medium High Description: GPS (global posistioning system) is used to catagorize posts according to the locations that they were physically made. GPS allows the user to constantly update their current location and view posts that were generated in their physical area.

19 Stimulus/Response Sequence: In every situation GPS is constantly updated the users current position. The user queries the client for its current GPS posistion before viewing local posts or making a post or replying to an existing post. Functional Requirements: REQ-1: The GPS coordinates should be accurate to within 150 feet REQ-2: A GPS location must map to a zone that can be accessed efficiently in the database Inverse Requirements: REQ-3: The user must not be able to provide false GPS location data Graffiti Server - Yuly Message Storage Priority Benefit Penalty Cost Risk High High High Medium Low Description: The server receives information from clients and stores the information in a database. Stimulus/Response Sequence: A message is received from a client -- corresponding to a new post or a reply to an existing post. The new data is added to the database. The server then sends a success message to the client. Functional Requirements: REQ-1: A new post / reply is correctly stored in the database. Updating all necessary fields REQ-2: The server must send a success message to the client upon adding the post to the database REQ-3: The server must be able handle multiple client connections REQ-4: The server must respond to the client within 15 seconds REQ-5: The server must decode the data sent from the client to extract username, message title, message text, image, and location REQ-6: The server must successfully store all the decoded information from the client in the database Inverse Requirements: REQ-7: The server should not lose any messages from the client REQ-8: The database should not lose any posts REQ-9: The only change to the database should be the addition of the new post

20 REQ-10: The server should protect the database from SQL injection. Error Handling Requirements: REQ-11: The database should return an error response if it fails to store a message Message List Retrieval Priority Benefit Penalty Cost Risk High High High Medium Low Description: The server receives a request for message posts from a client. Stimulus/Response Sequence: A message is received from a client requesting a list of posts. The server locates all relevant posts in the database and sends the message titles and descriptions. Functional Requirements: REQ-1: The server responds to the client with a list (may be empty) REQ-2: The server must access the database to locate all posts matching the client's criteria REQ-3: The server must be able handle multiple client connections REQ-4: The server must respond to the client within 15 seconds. REQ-5: The server must encode the data (message title and description) retrieved from the database in the form that can be sent to the client REQ-6: The server must successfully send the list of posts to the client Inverse Requirements: REQ-7: The database should not change from viewing a post Error Handling Requirements: REQ-8: The server must send an error message to the client if it fails to create a list of messages Individual Message Retrieval Priority Benefit Penalty Cost Risk High High High Medium Low Description: The server receives a request for specific message. Stimulus/Response Sequence: A message is received from a client requesting a specific post. The server locates the post in the database and returns it to the client.

21 Functional Requirements: REQ-1: The server responds to the client with a list (may be empty) REQ-2: The server must access the database and locate the requested thread and any replies REQ-3: The server must be able handle multiple client connections REQ-4: The server must respond to the client within 15 seconds REQ-5: The server must encode the data (message title, description, text, and image) in a format readable by the client REQ-6: The server must successfully send the message to the client Inverse Requirements: REQ-7: The database should not change from viewing a post Error Handling Requirements: REQ-8: The server must send an error message to the client if it fails to create a thread of messages Web Interface - Michael User Functions Priority Benefit Penalty Cost Risk High High Medium Medium Low Description: The web interface shall provide the user with the ability to register a new username or recover the password of an existing account. Stimulus/Response Sequence: A user presses either the "New user?" or "Forgot Password" button. The Android phone will then open it's web browser and navigate to the Graffiti web interface. The user will then be prompted to enter information, depending on what option was selected to reach the web interface. Functional Requirements: REQ-1: The interface shall allow the user to apply for a new username REQ-2: The interface shall accept a username and address when a user applies for a new account REQ-3: The system shall query the login database to verify that the requested username in a new account application is not already registered REQ-4: The interface shall allow the user to request for his or her password be reset REQ-5: The interface shall accept a username and address when a user requests to have his or her password reset

22 REQ-6: The system shall query the login database to verify information when a user submits information to reset a password REQ-7: The interface shall allow the user to close the interface and return to the last opened Graffiti view Inverse Requirements: REQ-8: The system shall not allow new registration of an existing username REQ-9: The system shall not reset a user's password if the entered username does not match the entered address Error Handling Requirements: REQ-10: The system shall return an error message if the a username is unavailable for new registration REQ-11: The sytem shall return an error message if the wrong username/ address combination is submitted for a password reset request Administrative functions Priority Benefit Penalty Cost Risk High High Medium Medium Low Description: The web interface shall provide the Administrator with the ability to: delete posts, edit posts, ban users, and view all posts independent of location. Stimulus/Response Sequence: The administrator navigates to the web interface using a web browser. The admin then enters his or her account information. If the account information is valid the administrator is given access to a few administrative functions. Functional Requirements: REQ-1: The interface shall allow the administrator to make a pos REQ-2: The interface shall allow the administrator to delete posts REQ-3: The interface shall allow the administrator to edit posts REQ-4: The system shall update the post database when a new posts is made, a post is edited, or a post is removed REQ-5: The interface shall allow the administrator to ban users for a period of time REQ-6: The interface shall allow the administrator to browse posts by physical location REQ-7: The interface shall require a username and password for administrator login

23 REQ-8: The system shall query the login database to verify that the administrator account information is valid Inverse Requirements: REQ-9: The interface shall not require the admin to be at a location to make a post REQ-10: The interface shall not require the admin to be at a location to delete a post REQ-11: The interface shall not require the admin to be at a location to edit a post REQ-12: The system shall not allow administrator access if the submitted account does not have administrator privileges Error Handling Requirements: REQ-13: The system shall return an error if the submitted administrator account information is not valid 3.3 Performance requirements [None] 3.4 Design Constraints The system will be implemented using Java, PHP, MySQL, XML and will run on Android SDK Software System Attributes Reliability If system is interrupted by a phone call it should save its state and return when the system is resumed. If the phone loses power or is shut off, non saved data will be lost. The server will run 24/7 barring network and power outages Availability The system is available to anyone with a Google Android phone. The registration system is open to the public, and unregistered, anonymous posting is also allowed for Security Passwords will be stored on our data servers and encrypted using a hashing algorithm.

24 3.5.4 Maintainability All code will be highly modularized, allowing for easy modification of subsystems Portability The Graffiti application will only be available as an application for Google Android phones. The web interface for user registration, however, will be accessible online. 3.6 Other Requirements [None] // ADD Appendices (if any) // Regenerate Table of Contents

25 Appendices Appendix - A