Functional Specifications
5000 N. Willamette Blvd.Fax 503 943 7316
Portland, OR97203-5798
Functional Specifications
Project Santiam: Whenever Messenger
Contributors:
Lisa Eberle
Jason Favors
Ben Foran
Approvals
Name / Date / Name / DateDr. Vegdahl / Dr. Lillevik
Insert checkmark (√) next to name when approved.
University of PortlandSchool of EngineeringContact: J. FavORS
Revision History
Rev. / Date / Author / Reason for Changes0.9 / 09/27/05 / L. Eberle, J. Favors, B. Foran / Initial draft
0.91 / 09/28/05 / L. Eberle, J. Favors, B. Foran / Revisions –per Dr. Vegdahl’s comments
0.95 / 09/30/05 / L. Eberle / Revisions – per Dr. Vegdahl
0.96 / 10/3/05 / L. Eberle, J. Favors, B. Foran / Revisions – per approval meeting
0.97 / 10/4/05 / L. Eberle, B. Foran / Revisions – per Dr. Vegdahl’s comments
1.0 / 10/4/05 / L. Eberle, J. Favors, B. Foran / Revision – per weekly meeting
University of PortlandSchool of EngineeringContact: J. FavORS
functional specificationsRev. 1.0Page 1
Project SANTIAM
Table of Contents
Summary
Introduction
Background
Requirements
Overview
Core Functionality
Website Specifications
Server Specifications
Client Specifications
Sending Client
Receiving Client
Conclusions
Appendices
Appendix A: Terms
Appendix B: Glossary
University of PortlandSchool of EngineeringContact: J. FavORS
functional specificationsRev. 1.0Page 1
Project SANTIAM
List of Figures
Figure 1. Block Diagram of Project Santiam (First Time User)
Figure 2. Block Diagram of Project Santiam (User Enters Message to be sent)
Figure 3. Block Diagram of Project Santiam (User Receives Stored Message)
University of PortlandSchool of EngineeringContact: J. FavORS
functional specificationsRev. 1.0Page 1
Project SANTIAM
List of Tables
Table 1. Core Functionality Specifications
Table 2. Website Functional Specifications
Table 3. Server System Specifications
Table 4. Sending Client System Specifications
Table 5. Receiving Client System Specifications
Table 6. Glossary of Terms
University of PortlandSchool of EngineeringContact: J. FavORS
Functional specificationRev. 0.96Page 1
Project SANTIAM
Chapter / Summary1
Project Santiam is an offline messaging program that will allow people to send plain text messages to an offline contact. Once the offline contact logs in to their Instant Messaging client, they will receive the messages that were sent to them while they were offline. Project Santiam will initially work with the AOL Instant Messaging (AIM) client, designed with the possibility to extend to other IM clients.
The Project Santiam program, titled Whenever Messenger, is a web-based application. Users will access the Whenever Messenger website using a web browser and logging in with a username and password they registered with the website. Then they will simply enter the screen name and a short text message for the person they wish to contact. The Whenever Messenger will then store the message and deliver it to the indicated user once they come online. During the process of using Whenever Messenger, the program will provide feedback as to whether or not its actions were performed correctly, assuring the user of the program’s progress.
Messages will be sent to a user like an ordinary Instant Message (IM) from the Whenever Messengerscreen name (“whenever msngr”), with details explaining the automated message. When a user logs on that has a message waiting for them, Whenever Messenger will IM them. The message will include who left the message, the time it was sent, followed by the message they sent. If more than one message was sent, either by one or more people, Whenever Messenger will leave subsequent IMs in the same window.
Stored messages will be limited so that receiving users will not be bombarded with messages once they come online. A receiver’s “mailbox” will have a limit as to how many characters can be stored on the server. Hence the length of the message sent from “whenever msngr”, which includes the messages from all users that send messages while the receiver was offline, is also limited. This will also allow for efficient use of server storage. Message lengths will also be regulated to follow AIM messaging restrictions. Receiving messages from Whenever Messenger also depends upon the receiving party’s settings. A person cannot receive messages if they block the Whenever Messengerscreen name or do not allow IMs from people other than those on their buddy list.
The Whenever Messenger will have its own account with AIM and will use the AIM protocol Open System for Communication in Real-time (OSCAR)[1] to interact with AIM. This will allow Whenever Messenger to verify users’ accounts, see when a user comes online, and send the IM. This will also allow Whenever Messenger to have its own buddy list to determine who it can send messages to.Whenever Messenger will log into the AIM network through a protocol named Talk to Oscar (TOC). This protocol exists to allow open access to the AIM network. TOC connects to the network through OSCAR allowing Whenever Messenger to interact with AIM in the same way as an AIM client. This will allow the program to avoid being disconnected from the AIM network because the program is not authorized by AOL to interface directly through OSCAR.
University of PortlandSchool of EngineeringContact: J. FavORS
Functional specificationRev. 0.96Page 1
Project SANTIAM
Chapter / Introduction2
The purpose of this functional specification document is to provide clarification and definition of Project Santiam to the faculty advisors at the University of Portland, the industry representatives, the project members, and other potential users. After reading this document you should have a better understanding of the proposed functionalities and use of this project. This document will outline the basic functionalities of the project as well as define the project's limitations.
The remainder of the functional specification document will include an overview of the background and the requirements of the project, including the core functionality, the website specifications, server specifications and client specifications.
University of PortlandSchool of EngineeringContact: J. FavORS
Functional specificationRev. 0.96Page 1
Project SANTIAM
Chapter / Background3
Instant messenger services allow users who are online and signed in to send plain text messages to other online. An instant message (IM) can only be sent to users who are online. If an instant messenger user who is online and signed in tries to send an IM to an offline contact, an error message will be returned to the user. The automatically generated message informs the user that the message was not able to be sent because the other user is currently not logged in.
AOL Instant Messaging (AIM) client uses a protocol known as Open System for Communication in Real-time (OSCAR). OSCAR is based on theTransmission Control Protocol (TCP). It provides validation of user name and password. In the case of AIM, the user name is synonymous with the user’s screen name. Once the user’s screen name and password are validated, the OSCAR protocol connects the user to the Basic Oscar Service (BOS). BOS allows the user to send and receive IM’s.
The OSCAR protocol was created by AOL for its instant messenger client. It is a closed source protocol and is controlled by AOL. This provides a challenge for developers who want to create applications that interface with the AIM protocol. If the OSCAR protocol changes, then an application that interfaces with it may no longer function properly.
University of PortlandSchool of EngineeringContact: J. FavORS
Functional specificationRev. 0.96Page 1
Project SANTIAM
Chapter / Requirements4
Overview
Project Santiam plans to take a step to improve upon the current IM services. Whenever Messenger will enable IM users to send messages to their offline contacts. When a user returns from being offline, he/shewill be able to receive messages that were sent to them while they were offline.
Before using Whenever Messenger, a person must create an account on the website forthe program. Once the initial account has been created, the user can login to the website and begin sending messages to offline contacts by entering their screen name in the designated text box.
The following requirements have a priority level of 1, 2, or 3. Priority level 1 means that the requirement must be implemented in version 1.0; this is indicated by a base number and a decimal 1 (e.g. 100.1). Priority level 2 is an optional requirement that we would like to implement if time permits for improved functionality; this is indicated by a base number followed by a decimal point and 2 (e.g. 100.2). Priority level 3 is a requirement that we would like to implement and will be included in the design, but that we will most likely not have time to implement; this is indicated by a base number followed by a decimal point and 3 (e.g. 100.3).
Figure 1. Block Diagram of Project Santiam (First Time User)is a block diagram that shows the steps necessary to set up an account and use Whenever Messenger.
Figure 1. Block Diagram of Project Santiam (First Time User)
After a user creates an account, he/she can begin sending messages to be stored to the server that will then be sent to contacts as they log on to AIM. A person wanting to send a message to an offline contact must first log in to the website for Whenever Messenger. Upon successful log in, the user can type in the screen name of the receiver of the message, then the IM can be entered into a text field on the website. This message will then be stored on the server once the user indicates that the message is complete and ready to be sent. If the recipient of the message happens to be online rather than offline, the message will be sent immediately from the server to this contact. Otherwise, the message will be stored untilthis contact logs on to AIM, or 30 days has passed without the receiving user logging in.
Figure 2. Block Diagram of Project Santiam (User Enters Message to be sent)is a block diagram that shows the steps necessary to prepare a message to be stored on the Whenever Messenger server that will be sent to an offline contact.
Figure 2. Block Diagram of Project Santiam (User Enters Message to be sent)
The Whenever Messenger server retains messages that have been stored until the intended recipient logs in to AIM. Once that user logs in, the server sends the message to him/her. The message is deleted from the server once it is sent to the recipient. The sender of the original message may select to receive a confirmation message from Whenever Messenger when sending their message. The message appears as a normal IM but includes additional information, including a timestamp and the contact that created the IM.
Figure 3. Block Diagram of Project Santiam (User Receives Stored Message)is a block diagram that shows how a message is sent from the Whenever Messenger server to a contact that logs on to AIM.
Figure 3. Block Diagram of Project Santiam (User Receives Stored Message)
Core Functionality
The core functionalities of Whenever Messenger will include the websitewhere the program is based, the interaction between AOL’s protocol and Whenever Messenger, and the communication between the user and Whenever Messenger to verify the sending of a message.
Table 1. Core Functionality Specificationscontains a list of the basic specifications necessary for the Whenever Messenger to work overall.
Table 1. Core Functionality Specifications
Req. Num. / Requirement100.1 / Whenever Messengershallfunction with Firefox 1.0.7 or higher
100.3 / Whenever Messenger might be functional across multiple web browsers.
101.1 / Whenever Messengershall interact with AOL’s OSCAR instant messaging protocol.
102.1 / Whenever Messenger shall notify the user that their message was successfully stored in the server.
Website Specifications
Whenever Messenger’s website is instrumental to the message sending process. It provides the main interaction between the message sender and the product. The website will provide information about the project as well as the finished product. The website is also where the user will login to send a message to an offline contact. In addition, users of Whenever Messenger will be able to leave feedback regarding error messages and difficulties when using the product.
The text message that is sent to the database and stored on the database does not need to be secure because AIM does not send their messages securely. AIM’s messages are sent as plaintext.
Table 2. Website Functional Specifications contains a list of specifications necessary for the function of the project’s website.
Table 2. Website Functional Specifications
Req. Num. / Requirement200.1 / The website for Whenever Messengershall provide login for the user.
200.2 / The website for Whenever Messengermayprovide a secure login.
200.3 / The website for Whenever Messengermight provide a way for the user to retrieve lost passwords.
201.1 / The website shall provide a page to send a person aplain text message, complete with a place to enter the screen name of the receiving party as well as a place to enter the message (which will be limited to meet AIM messaging requirements).
201.3 / The website might allow basic text formatting, such as bold, italicized, and underlined text messages.
202.1 / The website shall have a registration page in order to be able to use Whenever Messenger.
203.2 / The website may have an “about” page describing the project, complete with available project documentation.
204.2 / The websitemay have a help page with step-by-step instructions on using Whenever Messenger.
205.2 / The website may have a contact page to get in touch with the project members.
206.1 / The website shall provide feedback as to whether a user was successful in sending his/her message to the server or if there was an error.
Server Specifications
The server will act as the backbone of the website. Messages are stored on the server insecurely and possibly securely in the future. Once messages are sent to the server a sender is not able to access the message they sent. After a period of 30 days if the recipient has not logged on to AIM the message is deleted from the server. The sender of the message may be notified that the deletion occurred, if they selected that option when they sent the message.
Table 3. Server System Specifications contains a list of the systemspecifications for the program’s server.
Table 3. Server System Specifications
Req. Num. / Requirement300.1 / The messages by the Whenever Messenger user shall be stored on the server.
300.3 / The message might be securely stored on the server.
301.3 / The sender of the message might be notified if the deletion of their stored message occurred.
302.1 / The receiving user shall have a designated storage space on the server with a limit as to how many characters can be stored.
Client Specifications
Sending Client
The sending client side of Project Santiam will require that the user be able to run a web browser to interface with the program. It will not require the user to be running its AIM client, but it will require the user to currently have an AIM screen name. The user will use his or her user name registered with the Whenever Messenger website to login and begin using the program.
Table 4. Sending Client System Specifications contains a list of the system specifications for the sending client.
Table 4. Sending Client System Specifications
Req. Num. / Requirement400.1 / The client shall have a Firefox 1.0.7 web browser or higher for functional purposes.
400.3 / The client might be able to use multiple web browsers.
401.1 / The client shall have a registered AIM screen name.
402.1 / The client shall have a registered account with Whenever Messenger.
Receiving Client
The receiving client will be required to use AIM in typical fashion. Whenever Messenger will recognize when the user is logged on and ready to receive messages. They will not be required to be registered with Whenever Messenger.The user must not have the screen name “whenever msngr” blocked.
Table 5. Receiving Client System Specifications contains a list of the system specifications for the receiving client’s computer.
Table 5. Receiving Client System Specifications
Req. Num. / Requirement500.1 / The client shall run his or her AIM client.
501.1 / The client shall be signed in to AIM.
502.1 / The client shall allow incoming messages from people not on his/her buddy list; if they ONLY accept incoming IMs from people on their buddy list, they need to add the Whenever Messengerscreen name to their buddy list (screen name: ‘whenever msngr’).
502.3 / There mightbe additional Whenever Messenger screen names to handle load distribution.
503.1 / The Whenever Messengerscreen nameshall not be blocked.
503.3 / Additional Whenever Messenger screen names (if used for load distribution) might not be blocked as well.
University of PortlandSchool of EngineeringContact: J. FavORS
Functional specificationRev. 0.96Page 1
Project SANTIAM
Chapter / Conclusions5
Project Santiam will allow for more efficient communication between IM users by allowing them to message each other even when a user is offline. The Whenever Messenger will improve upon and add more functionality to the current instant messaging programs.
The users of Whenever Messenger will have the capability to send a message to a fellow contact despite the fact that person is offline. Once that contact signs online again,he (she) will receive the message that was sent to him (her)previously. This will provide for more effective and efficient communication for the users. With this system, users will now be able to contact each other, online or offline, through one program.
Overall, Project Santiam’s Whenever Messenger plans to assist the communication between friends, colleagues, and families across the Internet.
University of PortlandSchool of EngineeringContact: J. FavORS
Functional specificationRev. 0.96Page 1
Project SANTIAM
AppendicesAppendix A: Terms
AIM – AOL Instant Messenger
BOS – Basic OSCAR Service
CSS – Cascading Style Sheets
IM – Instant Messenger