Software Requirements Specification

for

eventLock, Release 1.0

Version 1.0 draft Prepared by Justin Kinney, Brandon Fore, Khoa Nguyen, Omar Zaman COSC4320 Team 4

October 17, 2010

Software Requirements Specification for eventLock

Page ii

Table of Contents
1. Introduction................................................................................................................................1 2. Overall Description....................................................................................................................1 3. System Features..........................................................................................................................3 4. External Interface Requirements..............................................................................................7 5. Other Nonfunctional Requirements.........................................................................................8 1. Content Model............................................................................................................................9 2. Interaction Model......................................................................................................................9 3. Functional Model.....................................................................................................................13 4. Navigation Model.....................................................................................................................13 5. Configuration Model...............................................................................................................13

Revision History
Name Justin Kinney Justin Kinney Date 10/5/10 10/17/10 Reason For Changes initial draft second revision to be submitted 10/17/10 Version 1.0 draft 1 1.0 draft 2

Software Requirements Specification for eventLock

Page 1

1.
1.1

Introduction
Purpose

This SRS describes the software functional and nonfunctional requirements for release 1.0 of eventLock. This document is intended to be used by the members of the project team that will implement and verify the correct operation of the system. Unless otherwise noted, all requirements specified here are high priority and committed for release 1.0.

1.2

Project Scope and Product Features

eventLock is a web application that allows users to schedule reminders for arbitrary events which will be delivered via email, SMS, or a telephone calls. A detailed project description is available in the eventLock Vision and Scope Document [1]. The Scope of Initial and Subsequent Releases section in that document lists the features that are scheduled for full or partial implementation in this release.

1.3

References

1. Fore, Kinney, Nguyen, Zaman. eventLock Vision and Scope Document, www.eventlock.me/project/eventLock_vision_and_scope.doc

2.
2.1

Overall Description
Product Perspective

eventLock is a new system that provides users a previously unavailable capability to send reminders to themselves or others based on a set schedule. The context diagram in Figure 1 illustrates the external entities and system interfaces for release 1.0. The system is expected to evolve over several releases, ultimately connecting to at least two identified service providers on the Internet for additional functionality.

Software Requirements Specification for eventLock

Page 2

Figure 1. eventLock Context Diagram

2.2 2.3

Product Features User Classes and Characteristics

A User is a registered user of the eventLock site. The User wishes to schedule events on the site that will later trigger alerts via email, SMS, or voice phone call. The User expects to be able to access the site via the Internet and modify scheduled events at will. The Administrator is capable of viewing all data (schedules, events, user information, etc.) on the eventLock site. The Administrator is also capable of modifying users, events, and site operations such as enabling/disabling the event reminder routine.

User (favored)

Administrator

Software Requirements Specification for eventLock

Page 3

2.4

Operating Environment
OE-1: OE-2: OE-3: OE-4: eventLock shall operate with the following Web browsers: Microsoft Internet Explorer versions 7.0 and greater, Mozilla Firefox 3.0 and greater, Safari 4.0 and greater. eventLock shall operate on a server running the latest version of openSUSE Linux and Apache Tomcat, as well as MySQL for database access. eventLock shall permit user access from the general Internet. eventLock shall communicate with Twilio using the version 2010-04-01 REST API.

2.5

Design and Implementation Constraints

CO-1: CO-2: CO-3: The system shall use the MySQL version 5 as a database backend. All HTML code shall conform to the HTML 4.0 standard. All code shall be written in Groovy, utilizing the Grails web application framework.

2.6

User Documentation
UD-1: System features shall be inherently simple operations that users will intuitively understand how to use.

2.7

Assumptions and Dependencies

AS-1: DE-1: The cafeteria is open for breakfast, lunch, and dinner every company business day in which employees are expected to be on site. The operation of eventLock is closely tied to the availability of two external service providers: Twilio and Postmark.

3.
3.1

System Features
Create, View, Modify, and Delete Event Reminders
3.1.1 Description and Priority An eventLock user who has authenticated on the site may schedule an event reminder. The reminder may include one of several notification methods, including email, SMS, and voice reminder. A user may cancel or change an event reminder if it has not been delivered. Priority = High. 3.1.2 Stimulus/Response Sequences Stimulus: Response: Stimulus: Response: Stimulus: Response: eventLock user adds an event for one or more reminders. System prompts eventLock user for details of event/task(s), name, time/date, and notification method. eventLock user requests to change an event/task(s) reminder. If status is Accepted, system allows user to edit a previous event/task(s) reminder. eventLock user requests to cancel an event/task reminder. If status is Accepted, system cancels an event/task reminder.

Software Requirements Specification for eventLock

Page 4

3.1.3 Functional Requirements Event.Schedule: The system shall let an EventLock user who is logged into EventLock to schedule an event/task to be reminded of for one or more event/task. Event.Schedule.Auth: The system shall confirm that the EventLock user is registered to place an event/task order. Event.Schedule.Action: If the EventLock user is not registered for EventLock, the system shall give the user options to register now and continue to placing an event/task to place. Event.Schedule.Date: The system shall prompt the EventLock user for the event/task date. Event.Schedule.Validate: If the event/task date is the current date and the current time is after the event/task cutoff time, the system shall inform the user that its too late to place an event/task for that data and time. The user may either change the date or cancel the event. Event.Reminder.Method: The user shall specify whether the event/task delivery is to be SMS, EMAIL, VOICE, or all three. Event.Reminder.Copy: The system shall permit the user to define multiple identical event/task for delivery.

Event.Reminder.List:

When the user indicates that he/she does not wish to order any more event/task items, the system shall display the event/task items ordered and the individual delivery method. Event.Remind.Confirm: The system shall prompt the user to confirm the event/task order. Event.Remind.Cancel: If the user does not confirm the event/task order, the user may either edit or cancel the order. Event.Remind.More: The system shall let the user define additional event/task for the same or for different date Event.Remind.Update: Update the users page for the current event/task reminder date to reflect any event/task items that are now or has been delivered. Event.Remind.Email: Send an e-mail message to the user with the event/task order information.

3.2

Register for Site Access

3.2.1 Description and Priority In order to use eventLock, a user must first register for site access. In addition, eventLock will provide the user a method for resetting his or her password in case it is forgotten. Priority = High. 3.2.2 Stimulus/Response Sequences Stimulus: User clicks the Try eventLock Now button on the landing page.

Software Requirements Specification for eventLock

Page 5

Response: Stimulus: Response:

System prompts user for username, email, password, first name, and last name to complete registration. eventLock user requests a password reset. System prompts for username, resets the password, and emails the password to the user.

3.2.3 Functional Requirements User.Register.Form: User.Register.Accept: System will display a registration form. System will validate that the user has read and accepts the system terms of use. User.Register.Name: System will validate that the mandatory fields first name and last name, are populated. User.Register.Email: System will validate that email address is unique within the system. User.Register.Email.NG: System will display a message informing user that the email is already registered. User.Register.Username: :System will validate that the username is unique within the system. User.Reg.Username.NG: System will display a message informing user that the username is already registered. User.Register.Redirect: After clicking the Sign up button the user will be redirected to the events list, where they can begin using the system. User.Forgot.Password: The system will prompt for username and offer a Reset Password button. User.Forgot.Reset: The system will offer no recovery option, but will instead reset the users password. User.Forgot.Email The system will email the new password to the address registered in the users account profile. User.Login: User.Login.Redirect: User.Logout.Link: User.Logout.Redirect: The system will present an easy to find Login form in the upper right hand corner of the site Once logged in, the user will be redirected to the events page. Once logged in, the user will see a logout link on the uppor right hand corner of the site. When the user clicks log out, the system will automatically log the user out and redirect them to the login page.

3.3

Manage User Profile

3.3.1 Description and Priority Once registered with eventLock, a user must be able to manage his or her profile. This includes updating the details provided upon initial registration, as well as adding or updating methods of contact. In addition, an administrative user should be able to manage the profiles of any user in the system. Priority = High.

Software Requirements Specification for eventLock

Page 6

3.3.2 Stimulus/Response Sequences Stimulus: Response: eventLock user clicks Change Password link in the profile pane. System queries eventLock user for old password, new password, and confim new password. If validation of old password compared to current password, as well as new password compared to confirm new password is successful, password is updated. eventLock user clicks Change Email link in the profile pane. System queries eventLock user for new email address. If validation of new email address is successful, email address is updated. eventLock user clicks Delete Account link in the profile pane. System prompts user to confirm delete. If confirmed, the user is immediately logged out and all account information, including any event reminders, is deleted. eventLock user clicks Update Timezone link in the profile pane. System prompts user to choose from a list of time zones. Upon form submission, system updates timezone settings for user.

Stimulus: Response: Stimulus: Response: Stimulus: Response:

3.3.3 Functional Requirements Profile.Change.Pass: Profile.Change.Email: The system shall allow a user to change his password. The system shall allow a user to change the email associated with his account. Profile.Delete.Account: The system shall allow a user to delete his account entirely. Profile.Time.Zone The system shall allow a user to indicate in which time zone reminders will be sent. Admin.Profile.Access: The system shall allow an authenticated administrator to access all user account information. Admin.Profile.Reset: The system shall allow an authenticated administrator to reset any users password. Admin.Profile.Manage: The system shall allow an authenticated administrator to list, create, update, and delete system users. Admin.Events.Manage: The system shall allow an authenticated administrator to list, create, update, and delete any event in the system.

3.4

Send Event Reminder

3.4.1 Description and Priority The eventLock system must be capable of sending event reminders. The main actor in this feature is the system itself, performing actions on behalf of a user. Priority = High. 3.4.2 Stimulus/Response Sequences Stimulus: Response: eventLock scans database every 58 seconds and finds an un-reminded events whose remind time is set for the current time or earlier. eventLock triggers appropriate notify task based on notification method, and marks the event as notify complete.

3.4.3 Functional Requirements

Software Requirements Specification for eventLock

Page 7

Event.Remind.Email: Event.Remind.Email.1: Event.Remind.SMS:

The system shall have the capability of sending a preformatted message to an external email management system (Postmark). The system shall send an email event reminder to the email address associated with the event owners profile.

The system shall have the capability of sending a preformatted message to an external SMS delivery system (Twilio). Event.Remind.SMS.1: The system shall send an SMS event reminder to the SMS phone number associated with the event owners profile. Event.Remind.Voice: The system shall have the capability of sending a preformatted voice message to an external voice over ip management system (Twilio). Event.Remind.Voice.1: The system shall send an event reminder to the voice phone number associated with the event owners profile. Event.Remind.Log: The system shall log all notifications sent to users for auditing purposes. Event.Remind.Log.1: The system shall log all data necessary to provide user accounting and billing information to a billing system to be implemented at a later time.

4.
4.1

External Interface Requirements

User Interfaces
UI-1: UI-2: UI-3: The Cafeteria Ordering System screen displays shall conform to the Process Impact Internet Application User Interface Standard, Version 2.0 [4]. The system shall provide a help link from each displayed HTML page to explain how to use that page. The Web pages shall permit complete navigation and food item selection using the keyboard alone, in addition to using mouse and keyboard combinations.

4.2 4.3

Hardware Interfaces Software Interfaces

SI-1: Twilio SMS SI-1.1: To send an SMS event reminder, eventLock shall transmit the SMS destination and reminder message to Twilio through the Twilio REST programmatic interface. SI-1.2: eventLock shall capture any responses from Twilio in a log file for access by an administrator. SI-2: Twilio Voice SI-2.1: To send a voice event reminder, eventLock shall transmit the voice destination as well as the reminder message to Twilio using the REST programmatic interface.

No hardware interfaces have been identified.

Software Requirements Specification for eventLock

Page 8

SI-2: Postmark Email SI-2.1: To send an email event reminder, eventLock shall transmit the email destination as well as the reminder message to Postmark using the SMTP protocol.

4.4

Communications Interfaces
CI-1: eventLock shall send an e-mail message to the User only upon the following events: CI-1.1: CI-1.2: CI-1.3: CI-2: Event Reminder Password Reset User Registration

eventLock shall send an SMS message to the User only upon the following events: CI-2.1: Event Reminder

CI-3:

eventLock shall send a voice message to the User only upon the following events: CI-3.1: Event Reminder

5.
5.1

Other Nonfunctional Requirements

Performance Requirements
PE-1: PE-2: PE-3: PE-4: The system must perform scans of the database for unreminded events in 2 seconds or less. All Web pages generated by the system shall be fully downloadable in no more than 5 seconds via a typical high-bandwidth internet connection. Responses to queries shall take no longer than 7 seconds to load onto the screen after the user submits the query. The system shall display confirmation messages to users within 4 seconds after the user submits information to the system.

5.2 5.3

Safety Requirements Security Requirements

SE-1: SE-2: SE-3: SE-4: All transactions that would send authentication details or other sensitive information across the internet shall be encrypted using SSL encryption. Users shall be required to log in to eventLock for all transactions and use of the system beyond viewing public information. Administrators of the system shall have the ability to view and modify data across the system. The system shall permit eventLock users to view only their own system data, and not the data of other users.

No safety requirements have been identified.

5.4

Software Quality Attributes

Availability-1: The eventLock system shall be designed with high availability in mind. This may require using language features to keep data serializable.

Software Requirements Specification for eventLock

Page 9

Robustness-1: In the case of a system failure, events that have not been reminded will be reminded at the earliest possible moment.

Appendix A: System Models

As eventLock is a web application, the models provided below reflect requirements modeling with an agile development model in mind.

1.

Content Model
Event Content

The model below identifies the content to be provided by eventLock.

User Profile Content

2.

Interaction Model

The model below describes the manner in which users interact with eventLock. It is a graphical representation of what the user will see.

Software Requirements Specification for eventLock

Page 10

Landing Page

Registration Page

Software Requirements Specification for eventLock

Page 11

Manage Events

Manage Profile

Software Requirements Specification for eventLock

Page 12

Admin Manage Users Page

Admin Application Control Page

Software Requirements Specification for eventLock

Page 13

Password Reset Page

3.

Functional Model

The model below defines operations of eventLock that are user facing as well as processing functions that are independent of content but necessary for the user.

4. 5.

Navigation Model Configuration Model

The model below describes the overall navigation strategy for eventLock.

The model below describes the environment and infrastructure in which eventLock resides.

Software Requirements Specification for eventLock

Page 14

Patron
1

placing
m

Meal Order
1

containi ng

Ordered Food Item

1

paying
1

choosi ng
m

Meal Payment

Menu Food Item

m

containi ng
m

Menu

Figure 2 Partial data model for release 1.0 of the Cafeteria Ordering System.

Software Requirements Specification for eventLock

Page 15

Appendix B: Analysis Models

Incomplete
System accepts completed order

Patron cancels; do not charge

Accepted

Patron cancels; do not charge

Canceled

Cafeteria Staff prepares food

Prepared
Patron refuses delivery because order is incorrect Cafeteria Staff requests delivery

Patron cancels; charge payment

Pending Delivery
Meal Deliverer delivers meal

Delivered

Figure 3 State-transition diagram for meal order status.