CS352-SE2014-Project Requirements - Chat Server

CS352: Phase 1 A (Dr.
Mohammad El-Ramly)
Requirements Document
Software Requirements Specifications for Chat Server Component

ID 20110320 20110342 20110305 20110344 Name Mohamed Kamal Kamaly Mahmoud Mohsen Mohamed Salah Mahmoud Youssef Fadel Email mohamedkamalkamaly@hotmail.com m.mohsen_213@hotmail.com
CS352 CU FCI Software Engineering II 2014 Requirements Document DR. MOHAMMAD EL-RAMLY |1
CS352: Phase 1 A (Dr. Mohammad El-Ramly)
Table of Contents
Table of Contents ......................................................................................................................................... 2 Revision History ........................................................................................................................................... 4 Ownership Report ........................................................................................................................................ 4 1. Introduction ......................................................................................................................................... 5 1.1 1.2 1.3 1.4 2. Purpose ........................................................................................................................................ 5 Scope............................................................................................................................................ 5 Denitions, Acronyms and Abbreviations...................................................................................... 5 Overview ...................................................................................................................................... 5
Overall Description............................................................................................................................... 6 2.1 Product Perspective ...................................................................................................................... 6 Chat rooms ........................................................................................................................... 6 Users .................................................................................................................................... 7 Messages .............................................................................................................................. 7
2.1.1 2.1.2 2.1.3 2.2 2.3 2.4 3.
Product Functions ......................................................................................................................... 7 Client Component Characteristics ................................................................................................. 8 Assumptions ................................................................................................................................. 8
Requirements Table ............................................................................................................................. 9 3.1 3.2 3.3 3.4 3.5 3.6 3.7 Pre-login Requirements ................................................................................................................ 9 Logged-in user Requirements ....................................................................................................... 9 Chat Room Ownership and Administration ..................................................................................10 Chat Room Membership ..............................................................................................................11 Auto generated Messages ...........................................................................................................11 Persistence Requirements ...........................................................................................................11 Exceptional Handling Requirements.............................................................................................12
4. Requirements Use case tables .............................................................................................................13
Revision History
Date
14/4/2014
Version
1.0 - Initial version
Description
18/4/2014
1.1
- Added Overall Description section - Added Table of Contents - Added numbering to headers - Added Cover page
Ownership Report
Item
Software Requirements Introduction, Overall Description and Requirements Tables Requirements Use case tables All Team Members Mohamed Kamal Kamaly Mahmoud Mohsen
Owner
1. Introduction
1.1 Purpose
This document is the Software Requirements Specification (SRS) for the Chat Server component.It is designed and written for stakeholders: professors and project developers. Its purpose is to describe the functional and non-functional software requirements.
1.2 Scope
The scope of the project is to develop the back end component of a chat service to be used with other components (like client-side chat applications), it will offers a set of functionalities for these other components to through a well-defined Application Programming Interface.
1.3 Denitions, Acronyms and Abbreviations

API: Application Programming Interface Back End/Front End: http://en.wikipedia.org/wiki/Front_and_back_ends
1.4 Overview
The following sections of the document are divided as follows: Section 2 presents an overview of the chat server component, in terms of product perspective. Section 3 presents the component requirements, both functional and non-functional. Section 4 presents the User Case tables for each requirement in section 3.
2. Overall Description
2.1 Product Perspective
Chatting systems have a number of chat rooms which contain several users registered to these rooms. In chat rooms, users send and receive messages about specific topic. There are also auto-generated messages that are generated to highlight an event in the room. Examples of these events are (Member X have joined the room, Member Y has left the room, Member Z is now an admin). The product is the back-end component of the chat system that offers a set of functionalities which is then used by any other component to provide chat service to the users. The other components can vary from a normal chat client or a game that is using the product to provide chat for its players. So theres no limitations of the type of the component that uses the product. Following is definition for the product entities and functionalities it should provide. 2.1.1 Chat rooms It is a place where users send and receive messages regarding a specific topic. Any chat room has the following information: Title: limited words something that describes the chatting content. Description: a more detailed about the chatting content. Members: users that are registered in this room. Ownership log: describe the current and past owner of the chat room. Chat rooms may have several types: Public: The room and its messages can be accessed by any logged in user. Closed: The room can be by any logged in user, but its messages can be accessed only by its members. Private: The room cannot be seen nor accessed by any user who is not a member in it.
2.1.2 Users Any user has the following information: Name: the users real name. Email: An email owned by the user that will be used for the login process. Password: Chosen by the user to be used in the login process. Any user can have the following roles (at the same time for different rooms): Chat room member: A user which is a member of a Chat room. Chat room owner: The user who has the ability to delete the room and other privileges, initially the creator of the room. Chat room administrator: A member of the room who has some privileges assigned by the owner. 2.1.3 Messages A text that is sent in a chat room, any message have the following the information: Room: the chat room which has this message. User: the user who sent this message. Date: the date at which the message was sent. Any message can be one of the following types: User message: Any message sent by the users in the chat rooms Auto-generated messages:messages sent by the system to highlight events in the room. The user who sends this message then is a special user that represents the system.
2.2 Product Functions

The functions should be provided to other components using a well-defined API. Chat Rooms management: including manipulation and storage of their data. Users management: including manipulation and storage of their data. Messages management:including manipulation and storage of their data for both user messages and auto-generated messages.
2.3 Client Component Characteristics
The client component can have two states. These states are: Not logged-in state: the client component is not logged in or has logged out. Logged-in state: the client component is logged in using a users email and password, any operation done by the component in this state will affect this user.
2.4 Assumptions
There is a stable connection between the backend component and other components using its functionalities.
3. Requirements Table
The component should offer the following features mentioned in the requirements table through a well-defined interface, to other component that interacts with (like client-side applications).
3.1 Pre-login Requirements

ID 1 Description Register a new user using his email and password, the Back End component should validatehis email to be not already registered and to be owned by this new user through sending a confirmation email. Authenticate a user trying to log in using his email and password, the Back End should specify some kind of secured keyand all following communications done based on this key to avoid repetition of the authentication process. Complexity 2
3.2 Logged-in user Requirements

ID 3 4 5 6 7 8 9 10 Description A logged in user can logout, the authentication mechanism mention in Point 2 should handle the disposal of the secured key given to the logged in user once he is logged out. A logged in user can change his information (email, password). A logged in user can query the names of public and closed rooms only. The query allows listing all the public and closed rooms available. A private room cannot be seen nor accessed by any user who is not a member in it. A logged in user can create a new chat room. Any logged in user can accept or decline invitation to a room. Any logged in usercan browse the rooms he is member in. Any logged in user cant receive or send the messages in a room he is not member in. Complexity 1 3 2 5 3 2 2 4
3.3 Chat Room Ownership and Administration
ID 11 12 13 14 15 16 17 18 19 20 21 Description The owner of a new created chat room is the user that created it. The owner is also a member of the chat room. The owner of a chat room can give the ownership to another member in the room. The owner of a room can delete this room. The owner of a room can assign an admin from the room members. The owner of a room can accept\decline membership request. The owner of a room can change title, description of a room. The owner of a room can send membership request to a user to that room, the owner will use the user email to send him the request. The owner of a room can ban a member in it. The owner can give any of the privileges in to any of the admins except of point 11 and 12. The chat room admin is also a member. 3 2 2 2 3 1 2 Complexity 1
CS352 CU FCI Software Engineering II 2014 Requirements Document DR. MOHAMMAD EL-RAMLY | 10
3.4 Chat Room Membership
ID 22 23 24 25 Description A chat room member can send/receive messages to/from the chat room. A chat room member can browse room members and room information. A logged in user can request to join the room if he is not a member of it. Any chat room member can leave room except the owner. Complexity 1 1 2 1
3.5 Auto generated Messages

ID 26 27 28 Description When a new member joins the room an autogenerated message is sent to the room members to notify them. When a member leaves the room an auto generated message is sent to the room members to notify them. On any change in the room ownership and administration, an auto generated message is sent to the members to notify them. Complexity 5 5 5
3.6 Persistence Requirements

ID
29
Description
WebServer could ask PersistenceMechanism to create a room/user/message Object. The PersistenceMechanism object is one of 2 implementations: FilePersistence or SQLPersistence. Creating a room/user/message is done based on 2 parameters: SessionId and User ID. It is responsibility of PersistenceMechanism to create a unique room/user/message ID. WebServer could ask PersistenceMechanism to load any object(s). Loading an object could happen in 2 ways: - Load using objects ID - Load using SessionId and Users ID If multiple calls for loading same object occurred, one instance only should be in memory. WebServer could ask PersistenceMechanism to save user/message/room object.
30
31
3.7 Exceptional Handling Requirements
ID
32 33
Description
WebServer shouldn't be forced to handle different types of DataBase Exceptions (E.g. Microsoft Exception, MySql Exception). All such exceptions should be caught and wrapped in PersistenceException. PersistenceException typically will be fired if there are problems in loading/saving an object (user/room/message). In case webserver asked by the admin to do an operation over a user that doesnt exist, e.g UserNotFoundException should be thrown. For example, no request to update a delete a room if the user has no privilege to do that. In case webserver passed a wrong parameter (null object) or any invalid value (e.g. invlaid characters in login form), IllegalArgumentException should be thrown.
34
35
4. Requirements Use case tables
Use Case ID: Use Case Name: 1 Register a new user using his email and password, the Back End component should validate his email to be not already registered and to be owned by this new user through sending a confirmation email. User The user is not logged in. A new account is registered, and the user is logged in. User Action 1- The client side requests a new user registration. 2- The client side send the new account information 3- The server validates the information. 4- The system registers the new account, and log in the user. Exceptions: The user information is invalid. System Action
Actors: Pre-conditions: Post-conditions: Flow of events:
Use Case ID: Use Case Name: 2 Authenticate a user trying to log in using his email and password, the Back End should specify some kind of secured key and all following communications done based on this key to avoid repetition of the authentication process. User. The user is not logged. The user is logged in. User Action 1- The client side send a logging in request. 2- The client side send the logging information. 3- The system validate the information 4- System log in the user Exceptions: The user information is invalid. System Action
Use Case ID: Use Case Name: 3 A logged in user can logout, the authentication mechanism mention in Point 2 should handle the disposal of the secured key given to the logged in user once he is logged out. User. The user is logged in. The user is logged out. User Action 1- The client side send a logging out request. 2- System log the user out. 3- System send the client side a log out confirmation. System Action
Use Case ID: Use Case Name: Actors: Pre-conditions: Post-conditions: Flow of events: 4 A logged in user can change his information (email, password). User. The user is logged in. The user information is changed. User Action 1- The client side sends an information change request. 2- System sends the current user information. 3- The client side sends the new user information. 4- System validates the new information. 5- System changes the user information. 6- System send a confirmation to the client, side. Exceptions: The new information is invalid. System Action
Use Case ID: Use Case Name: 5 A logged in user can query the names of public and closed rooms only. The query allows listing all the public and closed rooms available. User. The user is logged in. User Action 1- The client side requests rooms query with certain name. 2- System apply searching algorithm, handling a degree of error. 3- System sends the result list to the client side. Notes and Issues: A private room is not disclosed if the user is not a member in it(refer to the requirements table row6). System Action
Actors: Pre-conditions: Flow of events:
Use Case ID: Use Case Name: Actors: Pre-conditions: Post-conditions: 7 A logged in user can create a new chat room. User. The user is logged in. A new room is created, with the creator its owner (refer to the requirements table row 11). User Action 1- The client side sends a new room request. 2- The client side sends the new room information. 3- System validates the room information. 4- System registers the new room. 5- System sends a confirmation to the client side. Exceptions: The new room information is invalid. System Action
Flow of events:
Use Case ID: Use Case Name: Actosr: Pre-conditions: Post-conditions: Flow of events: 8 Any logged in user can accept or decline invitation to a room. User The user is logged in. The user is a member in the other room, or the invitation is deleted. User Action 1- The client side requests the invitations list. 2- System responds with the user`s invitations list. 3- Client side sends a specific action regarding a specific item of the invitations list. 4- System processes the action. System Action
Use Case ID: Use Case Name: Actors: Pre-conditions: Flow of events: 9 Any logged in user can browse the rooms he is member in. User The user is logged in. User Action 1- The client side requests the users rooms. 2- System responds with the users rooms list. System Action
Use Case ID: Use Case Name: 13 This owner of a chat room can give the ownership to another member in the room. User. The user is logged in. The user is accessing a room owned by him. The room owner is changed. User Action 1- The client side request a room owner change. 2- The client side send the identification of the new user to be an owner. 3- System validate the user privileges. 4- System change the room owner 5- System respond with a confirmation. Exceptions: The specified user is not a member in the room. System Action
Actors: Pre-conditions:
Post-conditions: Flow of events:
Use Case ID: Use Case Name: Actors: Pre-conditions: 14 The owner of a room can delete this room. User The user is logged in. The user is accessing a room owned by him or administrated by him and have the privilege to delete the room. The room and all its information are deleted. User Action 1- The client side requests a room deletion. 2- The client side sends the identification of the target room. 3- System validates the user privileges. 4- System deletes the room. 5- System responds with a confirmation. System Action
Use Case ID: Use Case Name: Actors: Pre-conditions: 15
The owner of a room can assign an admin from the room members.
User The user is logged in. The user is accessing a room owned by him or administrated by him and have the privilege to assign an admin to the room. Another admin is assigned. User Action 1- The client side requests an admin assignment. 2- The client side sends the identification of the target user. 3- System validates the user privileges. 4- System assign the new admin to the room. 5- System responds with a confirmation. System Action
Exceptions:
The target user is not a member in the room.
Use Case ID: Use Case Name: Actors: Pre-conditions: 16 The owner of a room can accept\decline membership request. User The user is logged in. The user is accessing a room owned by him or administrated by him and have the privilege to accept\decline membership request. The user joins the room or the user`s invitation is disposed. User Action 1- The client side sends an invitation accept\decline. 3- System validates the user privileges. 4- System add the user to the room members or dispose the invitation. 5- System responds with a confirmation. System Action
Use Case ID: Use Case Name: Actosr: Pre-conditions: 17
The owner of a room can change title, description of a room.

User The user is logged in. The user is accessing a room owned by him or administrated by him and have the privilege to change title, description of a room. The title, description of the room is changed. User Action 1- The client side requests room information change. 2- The client side sends the room new information. 3- System validates the user privileges. 4- System validates the room new information. 5- System changes the room information. 6- System responds with a confirmation. System Action
Exceptions:
The room new information is invalid.
Use Case ID: Use Case Name: 18 The owner of a room can send membership request to a user to that room, the owner will use the user email to send him the request. User The user is logged in. The user is accessing a room owned by him or administrated by him and have the privilege to send membership requests to other users. The target user is not a member in the room. An invitation is send to the target user. User Action 1- The client side requests an invitation request to be sent. 2- The client side sends the target user identification. 3- System validates the user privileges. 5- System sends the invitation request to the target user. Exceptions: The target user is not a user in the system. System Action
Use Case ID: Use Case Name: Actors: Pre-conditions: 19 The owner of a room can ban a member in it. User The user is logged in. The user is accessing a room owned by him or administrated by him and have the privilege to ban a member in the room. The target user is a member in the room. The user is banned from the room and is no longer a member in it. User Action 1- The client side requests a member ban. 2- The client side sends the target member identification. 3- System validates the user privileges. 5- System bans the target member. System Action
Use Case ID: Use Case Name: 20 The owner can give any of the privileges in to any of the admins except of point 11 and 12. User The user is logged in. The user is accessing a room owned by him. The room admins privileges are changed. User Action 1- The client side requests an admins privileges change. 2- System validates the user privileges. 3- System sends the current admins privileges. 4-The client side sends the new admins privileges. 5- System change the room admins privileges. System Action
Use Case ID: Use Case Name: Actors: Pre-conditions: 22A A chat room member can send messages to the chat room. User The user is logged in. The user is member in the room. User Action 1- Client application sends a new message from the logged in user to the room. 2- System forward the message to all room members. System Action
Flow of events:
Use Case ID: Use Case Name: Actors: Pre-conditions: 22B A chat room member can receive messages from the chat room. User The user is logged in. The user is member in the room. User Action 1- Client application requests the new of the room. 2- System responds with the new messages. System Action
Flow of events:
Use Case ID: Use Case Name: Actors: Pre-conditions: 23 A chat room member can browse room members and room information. User The user is logged in. The user is member in the room. User Action 1- Client application requests the room members list and room information. 2- System responds with the members list and room information. System Action
Flow of events:
Use Case ID: Use Case Name: Actosr: Pre-conditions: 24 A logged in user can request to join the room if he is not a member of it. User The user is logged in. The user is not member in the room. A request is sent to the target room owner. User Action 1- The client side send request to join a room. 2- The client side send the target room identification. 3- The system send the request to the target room owner. Exceptions: The target room is not in the system. System Action
Use Case ID: Use Case Name: Actors: Pre-conditions: 25
Any chat room member can leave room except the owner.
User The user is logged in. The user is not member in the room. The user is not a member in the room. User Action 1- The client send a request that the logged in user leave a room. 2- The client send the target room identification. 3- System removes the user from the target room mebers. System Action
Exceptions:
The target room is not in the system.

CS352-SE2014-Project Requirements - Chat Server

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

CS352-SE2014-Project Requirements - Chat Server

Загружено:

Авторское право:

Доступные форматы

CS352: Phase 1 A (Dr.

Software Requirements Specifications for Chat Server Component

CS352: Phase 1 A (Dr. Mohammad El-Ramly)

2.1.1 2.1.2 2.1.3 2.2 2.3 2.4 3.

CS352: Phase 1 A (Dr. Mohammad El-Ramly)

CS352: Phase 1 A (Dr. Mohammad El-Ramly)

CS352: Phase 1 A (Dr. Mohammad El-Ramly)

1.3 Denitions, Acronyms and Abbreviations

CS352: Phase 1 A (Dr. Mohammad El-Ramly)

CS352: Phase 1 A (Dr. Mohammad El-Ramly)

2.2 Product Functions

CS352: Phase 1 A (Dr. Mohammad El-Ramly)

CS352: Phase 1 A (Dr. Mohammad El-Ramly)

3.1 Pre-login Requirements

3.2 Logged-in user Requirements

CS352: Phase 1 A (Dr. Mohammad El-Ramly)

CS352: Phase 1 A (Dr. Mohammad El-Ramly)

3.5 Auto generated Messages

3.6 Persistence Requirements

CS352: Phase 1 A (Dr. Mohammad El-Ramly)

CS352: Phase 1 A (Dr. Mohammad El-Ramly)

Actors: Pre-conditions: Post-conditions: Flow of events:

CS352: Phase 1 A (Dr. Mohammad El-Ramly)

Actors: Pre-conditions: Post-conditions: Flow of events:

CS352: Phase 1 A (Dr. Mohammad El-Ramly)

Actors: Pre-conditions: Post-conditions: Flow of events:

CS352: Phase 1 A (Dr. Mohammad El-Ramly)

CS352: Phase 1 A (Dr. Mohammad El-Ramly)

Actors: Pre-conditions: Flow of events:

CS352: Phase 1 A (Dr. Mohammad El-Ramly)

CS352: Phase 1 A (Dr. Mohammad El-Ramly)

CS352: Phase 1 A (Dr. Mohammad El-Ramly)

CS352: Phase 1 A (Dr. Mohammad El-Ramly)

Post-conditions: Flow of events:

CS352: Phase 1 A (Dr. Mohammad El-Ramly)

Post-conditions: Flow of events:

CS352: Phase 1 A (Dr. Mohammad El-Ramly)

Post-conditions: Flow of events:

The target user is not a member in the room.

CS352: Phase 1 A (Dr. Mohammad El-Ramly)

Post-conditions: Flow of events:

CS352: Phase 1 A (Dr. Mohammad El-Ramly)

The owner of a room can change title, description of a room.

Post-conditions: Flow of events:

The room new information is invalid.

CS352: Phase 1 A (Dr. Mohammad El-Ramly)

Post-conditions: Flow of events:

CS352: Phase 1 A (Dr. Mohammad El-Ramly)

Post-conditions: Flow of events:

CS352: Phase 1 A (Dr. Mohammad El-Ramly)

Post-conditions: Flow of events:

CS352: Phase 1 A (Dr. Mohammad El-Ramly)

CS352: Phase 1 A (Dr. Mohammad El-Ramly)

CS352: Phase 1 A (Dr. Mohammad El-Ramly)

CS352: Phase 1 A (Dr. Mohammad El-Ramly)

Post-conditions: Flow of events:

CS352: Phase 1 A (Dr. Mohammad El-Ramly)

Post-conditions: Flow of events:

The target room is not in the system.

Вам также может понравиться