Table of contents

1. Introduction..........................................................................................................................................4
1.1.Purpose...............................................................................................................................................4
1.1...................................................................................................................................................Scope
4
1.2..............................................................................................Definitions acronyms and abbreviations
4
1.3.........................................................................................................................References documents
4
1.4.............................................................................................................................................Overview
5
2. The overall description.........................................................................................................................6
1.2. Product perspectives.........................................................................................................................6
1.3. Product functions...............................................................................................................................6
2.1.......................................................................................................... Uses classes and characteristics
7
2.3.1. Administrator...............................................................................................................................7
2.3.2. Lectures...........................................................................................................................................7
2.3.3. Delegate.....................................................................................................................................8
2.3.4. Students......................................................................................................................................8
1.4.Constraints..........................................................................................................................................8
a) Hardware constraints ...................................................................................................................8
b) Development constraints..............................................................................................................8
2.5 Assumptions and dependencies...........................................................................................................8
3. Detailed Description............................................................................................................................9
1.5.Class Diagram.....................................................................................................................................9
1.6.Use case of the general system..........................................................................................................10
1.7.Use case by actor..............................................................................................................................10
1.7.1. Student.......................................................................................................................................11
3.3.2 Delegate.....................................................................................................................................13
1.7.2. Lecturer......................................................................................................................................17
 3.3.3 Administrator.............................................................................................................................20
3.1........................................................................................................Sequence diagrams of the system
30
3.4.1 Administrator’s sequence diagrams............................................................................................30
3.4.2 Lecturer’s and delegate’s sequence diagrams...............................................................................42
3.2.................................................................................................................................Activity Diagram
46
1.8.Interfaces..........................................................................................................................................49
3.6.1 Administrator’s interface............................................................................................................49
3.6.2. Lecturer and delegate interface.....................................................................................................50
3.6.3. Student’s interface.......................................................................................................................51
1.9. The Non-functional requirements...................................................................................................52

REVIEW AND RESULTS

Date Tasks Descriptions
03/11/ 2012 Listing of Actors who will interact with the sys
To RMS description Listing of use cases and available classes,
20/11/2012 Enumeration of attributes and methods associa

21/11/2012 Plannificationof working meetings To elaborate the time,dates ,and places of meet
23/11/2012 Analysis of information Analysis of information collected from the inte
To Resources plannification comprehension of the theme,
03/12/2012 Plannification of resources.
04/12/2012 Translation of functionalities in Define all the functionalities and their actors in
English
07/12/2012 Correction of questionnaires Make the questionnaire clear and removal of e
12/12/12 Requirement specification Specify all the requirements needed for the ana
16/12/2012 Analysis and comprehension Analysis of requirements and constraints, Form
To constraints, analysis of questionnaires.
19/12/2012

20/12/2012 Gantt diagram Creation of tasks that will enter in the gantt dia
09/01/2013 Reminder of functionalities, actors Remind the functionalities in other to bring ou
To and formulation of use cases thereby scenarios of some use cases
20/01/2013 ,scenarios
21/01/2013 Drawing of diagrams To bring out the sequences diagrams, the class
To And the use case diagrams.
24/01/2013
25/01/2013 Readaptation of the Gantt diagram Readaptation according to new tasks and perio
To
02/02/2013
04/02/2013 Revision of diagrams correction of diagrams
To for eventual errors
21/02/2013
22/02/2013 Global revision -revision of diagrams
To And finalization of the first phase of -finalization of the SRS
22/03/2013 the project. -redaction of power point presentation
Chapter 1. INTRODUCTION

1.1. Purpose

The Room Management system is software that will help administrative personnel of the
University of Ngaoundere to have a better management of rooms. In fact rooms are
insufficient in the university of Ngaoundere and needed to be well manage in order to
overcome all type of problems linked to their management.. This document will permit us to
describe requirements of the RMS in order to make it understandable by the stakeholders and
to help developers to have a good comprehension and know what exactly they will have to
do. Specification also describes all hardware, software requirements, behavior and
components of the product.

1.2. Scope
The RMS will help to resolve many problems linked to the management of rooms .The major
one is room’s insufficiency. The RMS will give an overview of all existing rooms and the
planning of those rooms in order to help administrative personals, lecturers, students to have
information on it. The system will not resolve the problem of timetable of a course, a lecturer
or a level but that of rooms. It will not allow to managematerials in full details even if they
are included in rooms.

1.3Definitions, acronyms and abbreviations

In this document, some words , acronyms and abbreviations that will be often use, or are
not explicit are going to be explain in the context we uses them :

Definitions
 Room: It is a place where activities such as courses or events can take place.
 Event: External activity to lectures such as meetings, defends, conferences...
 Stakeholder: A person with an interest in the project.
 Actor: A person who interact with the system.
 Website: A computer connected to the Internet that maintains a series of web pages on
the World Wide Web
 Client Desktop: Computers in which the final application will be able to run.
 Task: Something to be done.
 Material: All equipment present in a room and useful for lectures or events.
 Administrative personnel: People responsible to manage rooms.
  Acronyms and Abbreviations

- RMS: Room Management System

- UN: University of Ngaoundere
- DB: Data base

1.4.References documents.
As documents we have use:

 IEEE Standard

 lesson on Requirements specification(e-learning)

I-5 Overview
In the following, we are going at first to give the overall description of the RMS. This
part will talk about product perspectives, product functions, user characteristics, constraints
and assumptions and dependencies.
The second part will give specific requirements. According to the IEEE Standard, they
are eight different templates that are going to be detail in this section. We are going to talk
about external an interface which contains User interfaces, hardware interfaces, software
interfaces and communication interfaces. We will also give functional requirements,
performance requirements, design constraints, security requirements, safety requirements,
software quality attributes and other requirements.
Chapter 2 THE OVERALL DESCRIPTION

In this section, we will talk about product perspectives, product functions, user classes
and characteristics, constraints and we will end with assumptions and dependencies.

2.1Productperspectives
The RMS is at his first version in the UN and will help to better manage the rooms by
bringing out timetables of any room. It is developed to join into the Ngaoundere’s university
web site as a web service called via the interface offers by the web site. Both systems will be
related via a link contain in the web site. After the loading, the RMS will be able to operate
alone as an application and will just works with his functionalities in the web site.

2.2Product functions
It became very difficult to establish timetables in University of Ngaoundere because
of rooms Insufficient. Room management system our project is the way to resolve this
problem. Our application will give the overview of all existing lecture room. Our principle is
that rooms we canuse must have teaching materials like blackboard with chalks, blackboard
with markers, laptop, and beamer also electricity, comfort, etc. This application must also
help to manage rooms for non-teaching activities such as meeting rooms, defend rooms for
master and PhD thesis, etc.
The RMS system should :
 Allow to add/delete room records and edit their details.
 Allow to create categories of rooms and edit their details.
  Allow to add/delete a room from a category.
 Provide complete and exact state of a room regarding the equipment which is inside
and for how long.
 Permit to transfer equipment from one room to another or to add/remove equipment
to/from the rooms.
 This must be possible only for the administrative people.
 Allow to book rooms and equipment for a specific date/time. The system should allow
online booking request. The booking can be also requested by phone or via e-mail, but
in such cases the responsible person will have to store the booking in the system.
 Allow to modify booking details (date, time, related room number, etc.) or cancel a
booking. This feature should only be available to the administrative personnel.
 Allow to automatically send a confirmation/refusal message (e.g. via email) to the
person that requested the booking as well as informational message in case of any
change in the booking details.
 Provide the users with the schedule for the use of the rooms or the equipment for a
specific time period. This feature must be available to end-users as well.
 Allow the user to search for available lecture rooms as well as rooms for non-teaching
activities.
 Allow the creation of user accounts as well as user categories for privileged groups.
 Allow to modify/delete user accounts and user categories as well to change the
category of a user.
 Provide registration and login processes for the users.
 Render immediately changes between bookings, rooms, equipment and users so to
avoid booking collisions.
 Allow invoicing of room, equipment and booking information. This must be possible
only for the chiefs of the university subdivisions.
 Locate the rooms to the end-users using building maps.
 Provide statistical reports concerning the use of rooms and resources.
 Be adaptable to integration of specific parameters for different institution.

2.3. User classes and Characteristics

According to the project proposal and the requirement analysis that we made with
informations we got by making interviews in each faculty and school of the University of
Ngaoundere, we brought out four users whom will interact with our system : Administrator,
Lecturers, delegates as privileged students and other students. In what follows, we are going
to list functions of each of them.
2.3.1. Administrator
In University of Ngaoundere, an administrator can be the vice-dean in charge of
allocating rooms concerning faculties or the pedagogical responsible of a level concerning
schools (e.g. UIT, ENSAI,etc.).He belongs to the first category and have more privileges than
the others. He is the one who can perform management tasks. He subscribes the others actors
in the system and can also modify their category or delete their accounts if necessary. He
receives booking requests from lecturers or delegate and is able to confirm booking and store
it in the system or refuse booking. Administrator is the person who also plans rooms
timetables. He updates the system when connected in his session.

2.3.2. Lecturers
Lecturers are registered in the system by administrator so that, they have their account
(log in and password) in the system. Except to display, print or download their timetables,
they can create events and book rooms and materials if necessary for that. They can also
cancel booking or modify details of their booking.

2.3.3. Delegate
He is a privileged student who can also book classrooms, but with the permission of the
lecturer. He has too an account in the system. As student, he is able to look for rooms, display
room timetables and print or download it.

2.3.4. Students
This category of user contains the students of the university or any other person which want
to use the application to have information of the system. They don't need an account. They
can just look for rooms, display rooms planning and print or download it.

2.4. Constraints
a). Hardware constraints
The system must run in:
 Server : CPU 2.4 GHZ; RAM : 512 Mo
 Client desktop: CPU : 800 MHZ; RAM: 128Mo ; screen 1024*800
 Client mobile.
 The interface must allow anonymous to use easily the system.
 The RMS system must be design as a Web Service.
b). Development constraints
 The RMS system must be implemented in JAVA language
 The RMS system must be able to be placed in every web site.

2.5Assumptions and dependencies

For good running, our system requires a good and fast Internet connection so that users will
been notified of any updating at time. The location functionality of our system depends on the
Campus Plan project.

Chapter 3 DETAILED DESCRIPTION

This chapter is to describe the RMS functional requirements. We are going to do it by

presenting first our uses cases, sequences diagrams, interfaces and at last the class diagram.

3.1 The Class Diagram of system

 Figure 1: Class diagram

3. 1 Uses case of the general system

This section gives the overview of all the use cases diagrams; it summarizes all the functional
requirement of the RMS system.

Figure 2: General use cases diagram

3.2 Uses cases by actors

This section shows the different uses cases by actors with their description in scenarios.

3.2.1Student
The functionalities of the student are:
 Display rooms of all the system or of a specific category
 Display planning of a room
  Print planning of a room
 Download planning
 Research a room
 Display details of an announcement about an event
 Get statistical reports about resources
These functions are represented in the following use cases diagram:

Figure 3: Student use's case diagram

A student interacts with the system through use case which description are done in the
following scenarios:

Title Display room

Objective To see room details
Date 21/03/2013
Version 1.0
Author EBANDJI EBANG Murielle
Primary actor User: Administrator, Lecturer, Delegate, Student
Secondary actor DB
Preconditions The user is connected in the system and the interfa
room is in front of him
Nominal scenario N1: The user selects the task to display room
N2: The system displays rooms by category

Alternative scenario A1: At the step 3, the administrator cancel the ope
Errors None
Post conditions The user see details concerning a room
Title Display a Planning
Objective To display the informationconc
Date 20/03/2013
Updated 20/03/2013
Version 1.0
Author TemwaDouskreo
Primary actor User(Administrator, Lecturer,
Secondary actor DB
Precondition User has in front of him an inte
display a planning.
Nominal scenario N1: User sends a request of dis
N2: System retrieves informati

Alternative scenario None

Exceptional scenario None
Post condition The planning is displayed
3.2.2 Delegate
The delegate is a special student who has an account and except what a normal student can do
he has others functionalities:
 Can do all what a normal student can do
 Display material of a room
 Book a classroom
 Book a material for a course
 Cancel a booking
 Display all the booking
 Modify his account
The delegate uses case diagram is:

Figure 4: Delegate use cases diagram

The scenarios of the delegate use cases are:

Name Authenticate
Objective Allow administrator, lecturer or special student to connect in the system
Date 15/02/2013
Updated 15/03/2013
Version 1.0
Author YouegoJoseline
Primary actor Administrator, Lecturer, special student
Secondary actor DB
Precondition User has in front of him an interface which allows the authentication in the syste
Nominal scenario N1: User selects task to authenticate;
N2: System loads and displays interface which permit the connection;
N3: User enters his login and his password and validates;
N4: System checks if this login and password exist and it displays the interface a
profile of the authenticated user;

Alternative scenario A1: At step 3,user cancels operation and system returns to point N1;
A2: At step 3, user has forgotten his login/password and he select task password
The system go to Password/login forgotten use case:
Exceptional scenario E1: At step4, system doesn’t find his login and/or his password and it sends a me
interface of connection (this login and/or password is not correct try again).
Post condition User is connected.
Name Book
Objective Allow Lecturer and special student to book for a material or room
Date 31/01/2013
Updated 15/03/2013
Version 1.0
Author YouegoJoseline
Primary actor Lecturer, special student
Secondary actor DB
Precondition User is authenticated and has in front of him the list of available materials/rooms
Nominal scenario N1: User select one material/room and select task to book;
N2: System loads and displays an interface which permit the booking;
N3: User enters the information about his booking and validates;
N4: System checks different information’s and asks the confirmation of user.
N5: User confirms;
N6: System saves information’s
Alternative scenario A1: At step 3, user cancels operation and system returns to point N1;
A2: At step 4, information’s are not corrects, the system returns to point 2.
A3: At step 5, user cancels operation and systems returns to point N1.
Exceptional scenario None
Post condition The booking request is saves in the system.
Name Cancel Booking

Objective Allow administrator to cancel a book

Date 21/03/2013
Updated 25/03/2013
Version 2.0
Author GotchoFabrice O.
Primary actor User
Secondary actor DB
Precondition User is authenticated and has in front of him the list of the l
confirmed
Nominal scenario N1: User selects one or more items into the list in front of h
N2: User chooses option cancel
N2: The system sends the confirmation of cancelling
N3: User accepts
N4: The system cancels that booking into DB
N5: The system removes that booking into the list of bookin
cancelling to the user.
Alternative scenario A1: At the Step3, Administrator cancels the operation, and
Exceptional scenario None
Post condition The room never exits into the system
3.2.3. Lecturer
He is the one who can book a room for an event that he has first created. He also allows a
delegate to book the classroom. His functionalities in the system are:
 Can do all what a delegate can do
 Book all rooms

The following diagram expresses his use cases:

Figure 5: Lecturer use cases

The lecturer uses cases descriptions are:

Title Modify account

Summary change user name or password
Creation date 31/01/2013
Update date 20/03/2013
Version 1.1
Responsible KEPLO MADI

Actors Delegate Lecturer, Administrator

The system is running
Preconditions User is authenticated and the interface of account is displayin

Nominal scenario N1:The lecturer or delegate click on modify my count;

N2:the system edit all information about this user;
N3:The user modify and click on save’s option,
N4:The system checks information, ask user to confirm modif
N5: The user confirm to modify
N6: The system save and confirm the update
A1. The syntax is not correct.
Alternative scenario:  the system resend and back to 2 and the user modify ag
A2.At 3 the user has opted to cancel modification
 the system back to 1
A3 : At 5 the user refuse to confirm the modification
the system cancel modification and back to 2

Errors E1:The user's count is not modified in the application

Post conditions New values have been registered in the user account
3.2.4 Administrator
He is the one who is able to perform the whole system management tasks. He has the
main functionalities in the system:
 Can do all what a lecturer can do
 Subscribe users or add account
 Add room in the system
 Add material in a room
 Delete a room
 Delete a material inside a room
 Delete a user’s account
 Modify details on a room
 Modify details on a materialà
 Modify or add a room’s planning
 Transfer a material from a room to another
 Confirm or refuse a booking.
The following diagram shows the use cases of the administrator:
Figure 6: Administrator use cases

The scenarios of these use cases are:

Name Refuse /Confirm booking

Objective Allow administrator to refuse or confirm a booking
Date 15/02/2013
Updated 15/03/2013
Version 1.0
Author SontiaRomual
Primary actor Administrator
Secondary actor DB
Precondition Administrator is authenticated and has in front of him the list of booking
Nominal scenario N1: User select one booking;
N2: System loads and displays details about selected booking
N3: User checks details and refuse the booking;
N4: System deletes/saves the booking request and sends a message to th
booking.
Alternative A1: At step 3, user cancels operation and system returns to point N1;
scenario
Exceptional None
scenario
Post condition The booking request is deleting or mention into the state of a room and a
to his author.
Name Subscribe a user
Objective Allow administrator to register a user in the system
Date 31/01/2013
Updated 15/03/2013
Version 1.0
Author YouegoJoseline
Primary actor Administrator
Secondary actor DB
Precondition Administrator is authenticated and has in front of him an interface which
register a user.
Nominal scenario N1: Administrator select task to subscribe a user;
N2: System loads and displays an interface which permit him to subscrib
N3: Administrator enters the information about the user and validates;
N4: System checks different information’s and asks the confirmation of
N5: User confirms;
N6: System saves information’s
Alternative A1: At step 3, user cancels operation and system returns to point N1;
scenario A2: At step 4, information’s are not corrects, the system returns to point
A3: At step 5, user cancels operation and systems returns to point N1.
Exceptional None
scenario
Post condition The user is register in the system.
Name Transfer of material
Objective Allow administrator to transfer a material from one room to another
Date 15/02/2013
Updated 15/03/2013
Version 1.0
Author SontiaRomual
Primary actor Administrator
Secondary actor DB
Precondition The administrator is authenticated and has in front of him an interface w
list of materials of a room.
Nominal scenario N1: administrator select one material and select task to transfer it;
N2: System loads and displays interface which content information abou
possibility to change the localization of this material;
N3: User select the new localization validates;
N4: The system asks the confirmation of the user;
N5: User confirms his/her choice
N6: System saves the modification.
Alternative A1: At step 5,user cancels operation and system returns to point N1;
scenario
Exceptional E1: The material is booked, the system inform the user and cancel the tra
scenario
Post condition The transfer is effective in the system.
Name To add a room

Objective Allow the administrator to add a new room in the system

Date 21/03/2013
Updated date
Author EBANDJI EBANG Murielle
Primary actor Administrator

Secondary actor DB
Preconditions The administrator is authenticated, all existing rooms are dis
task that allows him to add room
Nominal scenario N1: The administrator select the task to add a new room
N2: The system send him the form to fill with details about
N3: The administrator fill the form with room information
N4: The system checks those information, then load its an
administrator that a new room is added

Alternative scenario A1: At the step 3 the user cancel the operation
A4: At the step 4, the type of information that the administrat
the system return the form until the administrator fills correct
Errors None
Post condition: A new room is added
Title To add a material
Objective To declare a new material in the system
Date
Author YouegoJoseline
Primary actor Administrator
Secondary actor DB
Preconditions The administrator is in his session and have in front of him th
Nominal scenario N1: The administrator chooses the task to add material.
N2: the system displays the interface (the form) to fill inform
N3: The administrator fills the information about the materia
attributes and the room which the material belongs to and the
N4: The system checks the type of the data, save the materi
the administrator.

Alternative scenario None

Exceptional scenario : E1: The administrator doesn’t click on OK but closes the for
in the system: he goes back to N1.

post conditions A new material has been added in a room.

Title To modify a material
Objective To modify the details on a material
Date 21/02/2013
Version 1.0
Author YouegoJoseline
Primary actor Administrator
Secondary actor DB
Preconditions The administrator is authenticated and has in front of him th
Nominal scenario N1: The administrator selects a material in the list and choos
N2: The system displays attributes as active fields.
N3: The administrator chooses a field and keyboards the new
N4: The system asks the administrator to confirm if he really
N5: The administrator confirms.
N6: The new data are saving in the DB.

Alternative scenario None.

Errors None.
Post conditions The details on a material are modify.
Name Delete Room
Objective
Date
Updated date
Version
Author
Primary actor
Secondary actor
Precondition
Nominal scenario

Alternative scenario

Exceptional scenario
Post condition
Name

Objective
Date
Updated date
Version
Author
Primary actor
Secondary actor
Precondition
Nominal scenario

Alternative scenario

Exceptional scenario
Post condition
Name

Objective Allow administrator to remove one room into the list

Date 21/03/2013
Updated date 25/03/2013
Version 2.0
Author GotchoFabriceO..
Primary actor Administrator
Secondary actor DB
Precondition Administrator is authenticated and has in front of him the l
Nominal scenario N1: Administrator selects one room into the list in front o
N2: Administrator chooses option delete
N2: The system sends the confirmation of removing
N3: Administrator accepts
N4: The system deletes that room into DB and sends mess
Administrator.
Alternative scenario A1: At the Step3, Administrator cancels the operation, and
Exceptional scenario None
Post condition The room no more exits into the system.
3.3 Sequence diagrams of the system

This part of the document will show all sequence diagrams of the system use cases

3.3.1Administrator sequence diagrams

Figure 7: To authenticate
Figure 8: Add material
Figure 9: Add room
Figure 10: Modify room
Figure 11: Delete room
Figure 12:Add planning
Figure 13: Modify planning
Figure 14: To subscribe a user
Figure 15: Delete account
Figure 16: To transfer a material
 Figure 17: Accept booking

3.3.2 Lecturer and delegate sequence diagrams

Figure 18: To book
Figure 19: Display planning
Figure 20: Display room
 Figure 21: To modify account.

3.4.Activities diagram
The following diagrams represent the whole activities of two among the important use cases:
book and modify details on room.
Figure 22: To book activity diagram
 Figure 23: Modify details on room

Table des matières

4 Tapez le titre du chapitre (niveau 1)..........................................................................................................1
Tapez le titre du chapitre (niveau 2).............................................................................................................2
4.6 Tapez le titre du chapitre (niveau 3).......................................................................................................3
5 Tapez le titre du chapitre (niveau 1)..........................................................................................................4
Tapez le titre du chapitre (niveau 2).............................................................................................................5
5.6 Tapez le titre du chapitre (niveau 3).......................................................................................................6
 Figure 24: The activity diagram of scenario: modify planning

3. 5 Interfaces
This section presents some prototypes of administrator’s interfaces, to show how he can
modify details on rooms, and the host page.

3.5.1Administrator’s interface
 Figure 25: The interface of add room’s scenario

3.5.2 Lecturer and delegate interface

 Figure 26: The interface of booking scenario

3.5.3Student’s interface
 Figure 27: host page’s interface prototype

4. 3.6. Non - Functional Requirements.

3.6.1. Look and Feel Requirements.
According to the Customer requirements, the RMS should include following interfaces:

The RMS interfaces will the same for patrons and librarians based on
JavaScript/php application. Differences will depend on users’ functions. users will
have simple version of RMS without add, remove and modify possibilities.
The RMS interface for system administrator will include Java/JavaScript
application, Command Line, System files
Web interface. This interface will provide search, request and renew procedures,
connection with other online databases. Web interface should work correctly in
different browsers.
3.6.2.Usability Requirements.
As it was mentioned above, product’s users are adults that are why there are no
special requirements to simplicity of system.

 Ergonomical and clear interface

 The interface should contain prompts and help to avoid making mistakes
 The product should be used by people with no training.
3.6.3.Performance Requirements
 Any interface between a user and RMS should have a maximum response time of 5
seconds
The response should be fast enough to avoid users’ response collisions
The RMS should be available for use 24 hours per day, 365 days per year.
The RMS should support 500 users and 1000 requests/min simultaneously.

3.6.4Operational Requirements
The RMS should be used on IBM-compatible workstations with 50Mbytes free
space on HDD for library workstations (80Gbytes for server) and 32Mbytes RAM
for library workstations (256Mbytes for server)
The RMS should be correctly implemented in different Internet browsers
The RMS should correctly interface if MS Access applications and MS SQL Server

3.6.5.Maintainability and Portability Requirements

Changes (new patrons addition, password changes, database changes) must be
verified once per day at least
The RMS should provide automatically notification to patrons by e-mail about
item’s overdue, reservation results, availability of reserved item and etc
The RMS is expected to run under all O.S (Windows XP, Linux),

3.6.6.Security Requirements

The RMS should provide databases’ modification only for librarians and system
administrator after authorization procedures
Access to the RMS is permitted only for College student and staff after authorization
procedures
3.6.7. Legal Requirements
Personal information should be protected
 The RMS should comply with quality assurance standards
DES AJOUTS DANS

- LE USE CASE DE ADMINISTRATEUR

L’administrateur pourra également imprimer directement le planning