doing system srs

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

Table of Contents....................................................................................................................... iiRevision History......................................................................................................................... ii1. Introduction.......................................................................................................................... 1

1.1 Purpose..................................................................................................................................11.2 Project Scope and Product Features........................................................................................11.3 References..............................................................................................................................1

2. Overall Description.............................................................................................................. 12.1 Product Perspective................................................................................................................12.2 Product Features.....................................................................................................................22.3 User Classes and Characteristics.............................................................................................22.4 Operating Environment..........................................................................................................32.5 Design and Implementation Constraints..................................................................................32.6 User Documentation...............................................................................................................32.7 Assumptions and Dependencies..............................................................................................3

3. System Features................................................................................................................... 33.1 Create, View, Modify, and Delete Event Reminders...............................................................33.2 Register for Site Access..........................................................................................................43.3 Manage User Profile...............................................................................................................53.4 Send Event Reminder.............................................................................................................6

4. External Interface Requirements........................................................................................74.1 User Interfaces........................................................................................................................74.2 Hardware Interfaces................................................................................................................74.3 Software Interfaces.................................................................................................................74.4 Communications Interfaces.....................................................................................................8

5. Other Nonfunctional Requirements....................................................................................85.1 Performance Requirements.....................................................................................................85.2 Safety Requirements...............................................................................................................85.3 Security Requirements............................................................................................................85.4 Software Quality Attributes....................................................................................................9

Appendix A: System Models..................................................................................................... 91. Content Model...................................................................................................................... 92. Interaction Model................................................................................................................. 93. Functional Model................................................................................................................. 94. Navigation Model................................................................................................................. 95. Configuration Model............................................................................................................ 9Appendix B: Analysis Models.................................................................................................... 11

Revision History

Name Date Reason For Changes Version

Justin Kinney 10/5/10 initial draft 1.0 draft 1

Justin Kinney 10/17/10 second revision – to be submitted 10/17/10 1.0 draft 2

Software Requirements Specification for eventLock Page 1

1. Introduction

1.1 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 FeatureseventLock 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 References1. Fore, Kinney, Nguyen, Zaman. eventLock Vision and Scope Document,

www.eventlock.me/project/eventLock_vision_and_scope.doc

2. Overall Description

2.1 Product PerspectiveeventLock 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.


Figure 1.eventLock Context Diagram

2.2 Product Features

2.3 User Classes and CharacteristicsUser (favored) 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.

Administrator 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.


2.4 Operating EnvironmentOE-1: 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.

OE-2: eventLock shall operate on a server running the latest version of openSUSE Linux and Apache Tomcat, as well as MySQL for database access.

OE-3: eventLock shall permit user access from the general Internet.OE-4: eventLock shall communicate with Twilio using the version 2010-04-01 REST API.

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

2.6 User DocumentationUD-1: System features shall be inherently simple operations that users will intuitively

understand how to use.

2.7 Assumptions and DependenciesAS-1: The cafeteria is open for breakfast, lunch, and dinner every company business day in

which employees are expected to be on site.DE-1: The operation of eventLock is closely tied to the availability of two external service

providers: Twilio and Postmark.

3. System Features

3.1 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: eventLock user adds an event for one or more reminders.Response: System prompts eventLock user for details of event/task(s), name,

time/date, and notification method.Stimulus: eventLock user requests to change an event/task(s) reminder.Response: If status is “Accepted,” system allows user to edit a previous

event/task(s) reminder.Stimulus: eventLock user requests to cancel an event/task reminder.Response: If status is “Accepted, “system cancels an event/task reminder.


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 it’s 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 user’s 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


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.


Stimulus: User clicks the “Try eventLock Now” button on the landing page.


Response: System prompts user for username, email, password, first name, and last name to complete registration.

Stimulus: eventLock user requests a password reset.Response: System prompts for username, resets the password, and emails the

password to the user.


User.Register.Form: System will display a registration form. User.Register.Accept: 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 user’s account profile.

User.Login: The system will present an easy to find Login form in the upper right hand corner of the site

User.Login.Redirect: Once logged in, the user will be redirected to the events page.

User.Logout.Link: Once logged in, the user will see a logout link on the uppor right hand corner of the site.

User.Logout.Redirect: 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


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.



Stimulus: eventLock user clicks “Change Password” link in the profile pane.Response: 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.

Stimulus: eventLock user clicks “Change Email” link in the profile pane.Response: System queries eventLock user for new email address. If validation of

new email address is successful, email address is updated.Stimulus: eventLock user clicks “Delete Account” link in the profile pane.Response: System prompts user to confirm delete. If confirmed, the user is

immediately logged out and all account information, including any event reminders, is deleted.

Stimulus: eventLock user clicks “Update Timezone” link in the profile pane.Response: System prompts user to choose from a list of time zones. Upon form

submission, system updates timezone settings for user.


Profile.Change.Pass: The system shall allow a user to change his password.Profile.Change.Email: 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 user’s 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


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.


Stimulus: eventLock scans database every 58 seconds and finds an un-reminded events whose remind time is set for the current time or earlier.

Response: eventLock triggers appropriate notify task based on notification method, and marks the event as “notify complete”.



Event.Remind.Email: The system shall have the capability of sending a pre-formatted message to an external email management system (Postmark).

Event.Remind.Email.1: The system shall send an email event reminder to the email address associated with the event owner’s profile.

Event.Remind.SMS: The system shall have the capability of sending a pre-formatted 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 owner’s profile.

Event.Remind.Voice: The system shall have the capability of sending a pre-formatted 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 owner’s 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. External Interface Requirements

4.1 User InterfacesUI-1: The Cafeteria Ordering System screen displays shall conform to the Process Impact

Internet Application User Interface Standard, Version 2.0 [4].UI-2: The system shall provide a help link from each displayed HTML page to explain

how to use that page.UI-3: 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 Hardware InterfacesNo hardware interfaces have been identified.

4.3 Software InterfacesSI-1: Twilio SMSSI-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 VoiceSI-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.


SI-2: Postmark EmailSI-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 InterfacesCI-1: eventLock shall send an e-mail message to the User only upon the following events:

CI-1.1: Event ReminderCI-1.2: Password ResetCI-1.3: User Registration

CI-2: 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. Other Nonfunctional Requirements

5.1 Performance Requirements

PE-1: The system must perform scans of the database for unreminded events in 2 seconds or less.

PE-2: All Web pages generated by the system shall be fully downloadable in no more than 5 seconds via a typical high-bandwidth internet connection.

PE-3: Responses to queries shall take no longer than 7 seconds to load onto the screen after the user submits the query.

PE-4: The system shall display confirmation messages to users within 4 seconds after the user submits information to the system.

5.2 Safety RequirementsNo safety requirements have been identified.

5.3 Security RequirementsSE-1: All transactions that would send authentication details or other sensitive information

across the internet shall be encrypted using SSL encryption. SE-2: Users shall be required to log in to eventLock for all transactions and use of the

system beyond viewing public information.SE-3: Administrators of the system shall have the ability to view and modify data across

the system.SE-4: The system shall permit eventLock users to view only their own system data, and not

the data of other users.


5.4 Software Quality AttributesAvailability-1: The eventLock system shall be designed with high availability in mind. This may

require using language features to keep data serializable. 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 ModelThe model below identifies the content to be provided by eventLock.

Event Content

User Profile Content


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

Landing Page

Registration Page


Manage Events

Manage Profile


Admin Manage Users Page

Admin Application Control Page


Password Reset Page

3. Functional ModelThe 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. Navigation ModelThe model below describes the overall navigation strategy for eventLock.

5. Configuration ModelThe model below describes the environment and infrastructure in which eventLock resides.


Patron

Meal Order

Meal Payment

Menu

Menu Food Item

Ordered Food Item

paying

placing

choosing

containing

containing

1

1

m

11

1

m

m

m

m

Figure 2

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


Appendix B: Analysis Models

Incomplete

Pending Delivery

Delivered

Accepted

Prepared

Canceled

Meal Deliverer delivers meal

Patron refuses delivery because order is incorrect

Patron cancels; charge payment

Cafeteria Staff prepares food

Cafeteria Staff requests delivery

System accepts completed order

Patron cancels; do not charge

Patron cancels; do not charge

Figure 3

State-transition diagram for meal order status.

doing system srs

Documents