View
217
Download
1
Category
Preview:
Citation preview
King Saud University College of Computer and Information Sciences
Information Technology Department
IT322 Software Engineering I
Student Scientific Symposium Software Requirements Specification
Prepared by:
Supervised by: L. Ebtisam AlAbdulqader Second Semester 1432
Spring/Summer 2011
Group#: 4 Grade:
Group Email/Wiki: http://sw322.pbworks.com/w/page/37082027/WELCOME
Group members: Alaa AlFadhel, 429202040, Leader
Shahd alBluwi, 429202616, Analysis1
Majd AlOnaizan, 429202591, Analysis2
Fay alSehaibani, 429201998, Analysis3
Ghalya AlBugami, 429204669, Analysis4
Software Requirements Specification SRS
Page 2
Revision Table
Page# Section# Reviewer Corrected by (Reviewer, Author)
3 1 Alaa Alfadhel Alaa Alfadhel, Mjd AlOnaizan
4 2 Alaa Alfadhel Alaa Alfadhel, Fay Al-Sehaibani
5 3 Alaa Alfadhel Alaa Alfadhel, Ghalya Albugami
6 4.1 AlaaAlfadhel
Shahd Albluwi
Alaa Alfadhel Shahd Albluwi,
Ghalya Albugami
7 4.2 Shahd Albluwi Shahd Albluwi, Mjd AlOnaizan
11 4.3 Shahd Albluwi Shahd Albluwi, Fay Al-Sehaibani
14 5.1 Shahd Albluwi
Fay Al-Sehaibani
Ghalya Albugami
Mjd AlOnaizan Alaa Alfadhel
19 5.2 Shahd Albluwi
Fay Al-Sehaibani
Ghalya Albugami
Mjd AlOnaizan Alaa Alfadhel
20 6 Alaa Alfadhel
Mjd AlOnaizan
Fay Al-Sehaibani
Shahd Albluwi, Ghalya Albugami
39 7.1 Alaa Alfadhel
Mjd AlOnaizan
Fay Al-Sehaibani
Shahd Albluwi, Ghalya Albugami
40 7.2 Alaa Alfadhel
Shahd Albluwi
Ghalya Albugami
Mjd AlOnaizan,Fay Al-Sehaibani
50 7.3 Alaa Alfadhel
Shahd Albluwi
Ghalya Albugami
Mjd AlOnaizan, Fay Al-Sehaibani
51 7.4 Ghalya Albugami
Fay Al-Sehaibani
Alaa Alfadhel, Mjd AlOnaizan
Shahd Albluwi
55 7.5 Mjd AlOnaizan
Shahd Albluwi
Alaa Alfadhel, Ghalya Albugami
Fay Al-Sehaibani
58 7.6 Mjd AlOnaizan
Shahd Albluwi
Alaa Alfadhel, Ghalya Albugami
Fay Al-Sehaibani
Software Requirements Specification SRS
Page 3
TABLE OF CONTENTS
1. Introduction ..................................................................................................................................................... 4
2. Scope ............................................................................................................................................................... 5
3. User Characteristics ......................................................................................................................................... 6
4. Requirements Determination ........................................................................................................................... 7
4.1. literature review ...................................................................................................................................... 7
4.2. Interview ................................................................................................................................................. 8
4.3. Questionnaire ........................................................................................................................................ 12
5. Specific Requirements ................................................................................................................................... 15
5.1. User And System Requirements ........................................................................................................... 15
5.2. Non Functional Requirements .............................................................................................................. 20
6. Use Cases ...................................................................................................................................................... 21
7. System Models .............................................................................................................................................. 40
Use Case Diagram .................................................................................................................................................. 40
SSD Diagram ......................................................................................................................................................... 41
Conceptual Diagram ............................................................................................................................................... 50
Contract: ................................................................................................................................................................. 51
Collaboration Diagram: .......................................................................................................................................... 56
Class Diagram: ....................................................................................................................................................... 59
8. References ..................................................................................................................................................... 60
Appendices ........................................................................................................................................................... 61
Software Requirements Specification SRS
Page 4
1. INTRODUCTION
Student Scientific Symposium (SSS) is a web based software application that supports the
Student Partnership Program (SPP) at King Saud University in a way that helps
researchers and faculty members to know about for any events related.
The purpose of this document is to present a detailed description of the Student Scientific
Symposium. It will explain the purpose and features of the system, what the system will do
and the constraints under which it must operate. This document is intended for both the
stakeholders and the developers of the system.
This document will give further details on the overall system description, including user
characteristics and system scope.
The document will also include the specific requirements needed. These will include the
functions and performance. It also includes use cases diagram in order to make system
requirements clearer and more obvious to the developers. Since the system will be
developed in releases, only primary use cases were expanded.
Then, the document explains the interaction between the system and users through system
sequence diagrams. Besides, it shows the association between objects through the
conceptual diagram. Finally, it includes contracts for more clarification of the system
behavior.
This document is organized in a logical manner and is easy to follow. Readers could refer
to the table of contents if looking for something in specific.
Software Requirements Specification SRS
Page 5
2. SCOPE
It is English interface software to help managing the Student Scientific Symposium (SSS)
online.
It Allows students to register at the symposium and submit their researches’ papers. The
system will send submitted research papers to the Technical Chair (TC). After that, the TC
will resend the researches to the reviewers depending on the track after encrypting the
researchers’ information.
The system allows reviewers to record their comments and grades on researches submitted
to them, then allows the TC to determine wither the research passed round one, then
informs the student with round results and comments , it's also allows him/her to upload
the symposium schedule in the system interface.
The system also responsible for attendees’ registration, allows them to print the
symposium proceeding and allows the Steering Chair to see the attendance Information,
also allows the judges to record grades of presentations, after that the system calculates the
final grades and selects the wining researches.
The system does not check if the research papers was submit before or if there is a match
between two research papers.
Software Requirements Specification SRS
Page 6
3. USER CHARACTERISTICS
Our system is a system that will help all kinds of researchers in King Saud University such
as doctors, teachers, PHD students, master students, bachelor students, and anyone who
wants to register and attend in conference.
The system will manage faculty members (steering chair, technical chair, judges and
reviewers) work.
To use this system, the user should be able to read/write English properly since the system
is English interface.
In general, users of this system are most likely has the experience of using such similar
system and used to deal with different kinds of software.
Software Requirements Specification SRS
Page 7
4. REQUIREMENTS DETERMINATION
4.1. LITERATURE REVIEW
Keele
Conferences
and
events[1]
Annual
Conference
of the
Australasia
n Research
Managemen
t Society[2]
The
Australasia
n Research
Managemen
t Society [3]
Academic
conference
international
[4]
Melbourne
Conference
Management
[5]
Website
registration
√ √ √
Registration
via email
√
Replay √
Prevent
duplication
√
Hide
information
√ √ √
Sign up √ √
Contact
administration
√ √ √ √ √
Conference
abstract
√ √ √
Paper
submission
√ √
New
conferences
√ √ √ √ √
Software Requirements Specification SRS
Page 8
4.2. INTERVIEW
Interviewee: Ms.Mjdah Interviewers:
Askers: Alaa Al-Fadhel
Writers: Fay alsehbani
Ghalya albgmi
Mjd AlOnaizan
Shahad Albluwi
Location/medium:
King Saud University.
College of Computer and Information sciences.
Building#20, 1 floor, Room# 20.
Appointment date:
Monday 14, Mar 2011
Objective:
Collect the software user requirements.
Reminders:
Keep your questions short
but clear and give other
groups the chance to ask
their own questions.
Interviewee is a busy
person and has a limited
time for answering your
questions.
Don’t repeat questions
have been asked before by
other groups.
Listen carefully to other
groups’ questions and
make notes.
Software Requirements Specification SRS
Page 9
Agenda:
Q1.
Q2
Q3
Q4
Q5
Q6
Q7
Q8
Q9
Q10
Q11
Q12
Q13
Q14
Q15
Approximate time:
1 minutes
1 minute.
1 minute.
2 minutes.
1 minute.
2 minutes.
3 minutes.
3 minutes.
1 minute.
1 minute.
2 minutes.
1 minute
1 minute
3 minutes
3 minutes
General Observation:
She was very interesting about the system, so she
trying to give information as much as she can
Unresolved Issues, Topics Not
covered :
Nothing so far.
Software Requirements Specification SRS
Page 10
THE INTERVIEW TRANSCRIPT:
Interviewee: Ms Mjdah Date: Monday 14 Mar 2011
Questions Notes
Q1: What is the basic information needed for signing
up?
Answer: personal information (Name, age, Date of
birth) – mobile number and email.
And the member should have the option to make
the email address visible for others.
Q2: Is there any email services if yes what exactly? Answer: yes, members should receive emails for
register activation and the results.
Q3: Would you like the registration for the conferences
to be exclusive for the members of king Saud
University?
Answer: No
Q4: Would u like the members to be able to upload
their researches in the interface of the site?
Answer: No, only the abstract for each research
Q5: Can the researchers hand more than one research
in different track?
Answer: yes.
Q6: Dose the researches has the ability to modify in
their researches after the due date of submission?
Answers: yes, only after round 1.
Q7: Who is responsible for organizing the conference
schedules?
Answer: the system should give suggestion for the
TC, and TC have the ability to modify.
Q8: Are there different judges in every track? Answer: yes, there are different judges in different
track.
And every field should have a winner research.
Q9:What is the judges responsibilities Answer: to write their comments in each research
Software Requirements Specification SRS
Page 11
Questions Notes
Q10: Is there any advertising on the page? Answer: No, only for the events sponsors.
Q11: Dose the TC has to make sure that there is no
personal information on the research?
Answer: yes, he have to double check
Q12: Who is responsible to send the researches to
judges in the same track?
Answer: the system gives suggestion and waits for
the approval from the TC before sending the
researchers to judges.
Q13: If there is any modification on the research
should the system keep all the draft?
Answers: No, the system should eliminate any
draft and the TC only receives the final draft.
Additional information from the interviewee:
It is English interface system.
There will be an email services to inform users with the results
Anyone can register to attend the conference.
No modification after the due date.
There is a winner in each track.
For security issue, The system should keep the user logged in for 5 minutes
The system should keep the information of members for four years.
Interview summary:
The interviewee answered all our questions about the system and added some additional
information. The interview took 45 minutes, which was enough for gathering most of user
requirements, she explains how she wants to use the system, what they want the system to
provide for them and the system boundaries.
Software Requirements Specification SRS
Page 12
4.3. QUESTIONNAIRE
Agree. Disagree. Not
interested
1- Would you like the
system's language to be
English?
80% 10% 10%
2- Registration required
accessing the system.
70% 30%
3- Would you like the
registration for
attendance to be by
membership?
90% 10%
4- Receive an email from
the website about the
latest dates.
80% 20%
5- Summary and glossary
after each symposium
service.
100%
6- Categorize events in to
sections based on
especially field.
30% 10% 60%
7- Alert members 3 days
before symposiums’
dates, submission
deadline and
registration date on the
website home page.
60% 40%
… If you AGREE
Would you like the alert to be
optional?
90% 10%
Software Requirements Specification SRS
Page 13
8- Would you like the
Member’s email,
password and phone
number to be private
unless user wants
otherwise?
70% 30%
If you agree The
information that appears to
the public about members
is name, specialty.
100%
9- Do you want to be able
to search for members?
50% 30% 20%
10- Would you like to have
a help and common
questions bar?
100%
11- Knowing the event
attendees may concern
you?
40% 50% 10%
12- Would you like to
display the
Participating
researches?
20% 50% 30%
If you Disagree would you
like to have an abstract for
each research?
50% 40% 10%
13- Would you like to have
a limited time for your
membership?
10% 70% 20%
14- Show the wining
research?
100%
15- Show the winners’
name?
90% 10%
Software Requirements Specification SRS
Page 14
SUMMARY OF THE QUESTIONNAIRE:
The questionnaire was advertised across the Student Partnership Program (SPP) by hand.
It was available for one week. 10 students and instructors answered out of 20.
The result of this questionnaire generally is that most of the students and instructors prefer
to have a system with the English language, Registration, Summary and glossary after
each symposium service, Showing the wining research and agreed on alerting members 3
days before an event date. On the other hand, most of them disagreed on knowing the
event attendees, displaying all Participating researches and having limited time for
membership.
To see questionnaire sample, see appendix A.
Software Requirements Specification SRS
Page 15
5. SPECIFIC REQUIREMENTS
5.1. USER AND SYSTEM REQUIREMENTS
1. The system administrator shall register TC, SC and all reviewers to access the system.
1.1 The system shall save the information of TC, SC, judges and all the reviewers
entered by system administrator which are (name, track, KSU email
“email@ksu.edu.sa”, mobile number, office number, and office location).
1.1 The system shall save members’ information entered by system administrator.
1.3 The system shall send an activation link to the member’s email to activate
his/her registration.
2 The student shall sign up to access the system.
2.1 The student shall enter his/her information (name, age, date of birth, mobile
number, and KSU email “email@ksu.edu.sa”).
2.2 The system shall save the student’s information entered by the student.
2.3 The system shall send an activation link to the member’s email to activate
his/her registration.
3. The member shall log in the system to identify himself/ herself to the system.
3.1 The system shall request from the member for KSU email and password.
3.2 If the password entered is incorrect, the system shall ask the member to re-
enter his password.
3.3 The system shall send a password resetting link to the member email in case
he/she forget the password.
3.4 The system shall redirect the member to his account page immediately as he
log in with the correct password and member name.
Software Requirements Specification SRS
Page 16
4. Each member shall have an account to manage his/her some personal information.
4.1 The system shall allow the member to reset his password if he wants, the system
shall request the member to enter his old password and the new one.
4.2 The system shall allow the member to modify his/her personal information.
4.3 The system shall allow the member to have a choice to appear his/her email
address.
5. by logging in, the student shall be able to upload his/her researches.
5.1 The system shall allow the student to upload his/her researches on his/her account.
5.2 The system shall allow the student to upload many researches.
5.3 The system shall replace researches that have the same title while uploading.
5.4 The system shall allow the student to delete his/her researches from his/her
account.
6. The system allows TC to announce information of a new event.
6.1 The system shall allow the TC to post conference’s information (name, time, date,
and sponsors).
6.2 The system shall allow the TC to post the due date of each round.
6.3 The system shall allow the TC to edit conference’s information.
7. The student shall be allowed to send his/her research.
7.1 The system shall allow sending more than one research.
7.2 The system shall prevent the student to send more than one research for each track.
7.3 The system shall prevent the student to send researches after the due date.
7.4 The system shall prompt the student to write the track name before sending the
research.
Software Requirements Specification SRS
Page 17
8. The system allows TC to approve each research that has been assigned to the right
reviewer.
8.1 The system shall give suggestions to TC and wait for the approval from TC before
sending it to reviewers.
8.2 The system shall allow TC to change assigned reviewers.
8.3 The system shall allow TC to make sure the researches do not have students’
personal information.
9. The reviewers add comments and grade for each research.
9.1 The system shall allow the reviewers to add comments and grades for each
research.
10. The system allows TC to sends messages to rejected students and comments to the
accepted students.
10.1 The system shall eliminate students with grade lower than 70%.
10.2 The system shall allow TC to send comments and acceptance messages to
students more with grade than 70%.
10.3 The system shall allow TC to send rejected messages to students below than 70%.
10.4 The system shall send messages to students’ emails to inform them with the
results.
11. The system shall allow Judges to add grade of students’ presentation.
11.1 The system shall allow judge to add grade in presentation’s time.
11.2 The system shall allow judge to view the winner.
Software Requirements Specification SRS
Page 18
12. The system shall calculate the grade of researches.
12.1 The system shall determine the pass students in round one who got over
than 70%.
12.2 The system shall calculate the grade from round one and presentation’s
grade that have been added by judges.
12.3 The system determines the winner, who got the highest grade.
13. The system allows TC to organize the presentations’ schedules.
13.1 The system shall give suggestions for the presentations’ schedules.
13.2 The system should allow any modification in the presentation schedules
by TC.
13.3 The system shall organize the presentations’ schedules depending on track’s name
and in each track depend on alphabetical order of the students names.
14. The system allows SC to manage the conference attendance.
14.1 The system shall allow the SC to determine the number of attendance in each
conference.
14.2 The system shall allow the SC to announce the location of the conference.
14.3 The system shall allow the SC to print certificates for the attendances.
Software Requirements Specification SRS
Page 19
15. Anyone can register to attend the conference.
15.1 The system shall allow the people to fill up their information (name, Email, date of
conference and phone number).
15.2 The system shall reject any registration’s request if number of attendance exceeds the
limit.
16. The member should log out from the system before leaving the website.
16.1 The system shall end the session if the member hasn't made any action after 5
minutes.
16.2 The system shall provide a log out function.
17. The interface of the website has an abstract for each research, events and presentations
information.
17.1 The system shall provide an abstract for each research that contains research name,
researcher name and researcher’s email if he/she wants.
17.2 The system shall provide event information which is: event name, due date.
17.3 The system shall provide presentations time and name and sponsors.
Software Requirements Specification SRS
Page 20
5.2. NON FUNCTIONAL REQUIREMENTS
PRODUCT REQUIREMENTS
Training time for each user won’t exceed four hours which make the average of error
made by them not exceed three per day.
The system will drop the information in the database after period of time “five years”
to clean up the memory space.
The system handles more than 30 transactions per second.
The system takes 15 minutes to upload files.
The system takes 3 seconds for “sending” function.
The system has the ability to recover from failure within a day.
The system should keep a back up copy in case it’s destroyed.
The system supported in many browsers: Internet Explorer, FireFox , Google Chrome
and Safari.
ORGANIZATIONAL REQUIREMENTS
System’s members will walk through the instructions of King Saud University
The system takes 8 months to deliver to the customer.
Programmer will use XHTML, CSS and PHP languages in implementations.
WaterFall will be use as a process model for the system.
EXTERNAL REQUIREMENT
The system sends an activation link to members’ emails to guarantee their identity.
The system insures the accounts’ security since it keeps the member logged in for five
minutes.
Software Requirements Specification SRS
Page 21
6. USE CASES
Use Case 1: Register members. Actor:
Purpose:
Overview:
Type:
Cross
reference:
System administrator
Register faculty member in order to access the system
System administrator enters faculty members’ information to register them in the system.
The system sends an activation email to each member. The members shall activate her/his
account.
Primary
Functions: R1
Typ
ical
cou
rse
of
even
ts :
Actor action System response
1. This use case begins when the
system administrator request
registration of faculty.
2. Show registration form .
3. The system administrator records
one faculty member information
(full name, track, KSU email,
mobile number, office number
and office location) in the system.
4. The administrator requests the
system to send activation emails
to faculty members.
5. The system sends an activation email
which contains an activation email
and a random password to members
KSU emails.
6. The system displays a confirmation
message to the administrator.
Alternitve:
Line 1: if the administrator didn’t fill up all required informatiom, system re-request to enter all required
informatiom.
Software Requirements Specification SRS
Page 22
Use Case 2: Log In.
Actor:
Purpose:
Overview:
Type:
Cross
reference:
Faculty member , Student
Enable member to access the system.
The member enters his KSU email and password. The system checks the validity of the
data entered. The system allows the member to access the system.
Primary
Function: R3
Typ
ical
cou
rse
of
even
ts :
Actor action System responce
1. This use case begins when the
member reach the website page and
wants to access the system.
2. The system request the member to
enter his KSU email and the passowrd.
3. The member enters his/her KSU
email and password.
4. The system validate the email and
password entered by the member.
5. The system allows the member to
access the system and transfer him to
his account page.
Alternative:
Line 3: if the password entered was incorrect, the system shows a message and requests the member to re-
enter the password again.
Line3: if the member forger his/her password, see Use Case: retrieve password.
Software Requirements Specification SRS
Page 23
Use Case 3: Retrieve Password.
Actor:
Purpose:
Overview:
Type:
Cross
reference:
Faculty member , student
Create a new password in case the member forgets his/her old password.
The member requests to retrieve his/her password and enters his/her email. The system
sends an email with a link. The member enters the link. The member enters a new password
for his/her account.
Primary
Function: R3.3
Use case: log in.
Typ
ical
cou
rse
of
even
ts :
Actor action System responce
1. This use case begins when the
member request the system for
retrieving his/her password.
2. Show retrieving form and request to
enter his/her email .
3. The member enters his/her email.
4. The system sends to the member an
email with a link for retrieving the
password.
5. The member enters the link
provided in the email.
6. The system request the member for
resetting his password.
7. The member enters a new password
and re-enter it again for
confirmation.
8. The system saves the new password
and display a confirmation message.
Alternitave:
Line 5: If the confirmation password does not match the entered one. The system will not save the new
password and request the member to re-enter the password again.
Software Requirements Specification SRS
Page 24
Use Case 4: Manage Account.
Actor:
Purpose:
Overview:
Type:
Cross
reference:
Faculty Member, student.
Allow the member to manage his/her account.
The member enters his/her account profile. He/she manages the account by resetting
password and modifies personal account. On completion, the system saves the changes.
Primary
Functions: R4
Typ
ical
cou
rse
of
even
ts :
Actor action System response
1. This use case begins when the
member enters in his/her account
profile.
2. The user chooses a function to
modify personal information(name,
phone number, showing email).
3. System displays the modification form
4. The member confirms the changes
he made in his/her account page.
5. The system saves any changes have
been made.
6. The system display the new function
that she/he performed.
7. This use case ends when the
member leaves page.
Alternitave :
Line 2: If the member wants to reset his/her password, see use case Reset password.
Software Requirements Specification SRS
Page 25
Use Case 5: Reset Password. Actor:
Purpose:
Overview:
Type:
Cross
reference:
Faculty Member, student.
Allow the member to reset his/her account password.
The member request for password resetting. The member enters the new password. The
new password is saved.
Primary
Functions: R4.1
Use cases: Manage Account
Typ
ical
cou
rse
of
even
ts :
Actor action System response
1. This use case begins when the
member chooses to reset his
password through his account.
2. The system request the member to
enter his/her old password
3. The member enters his/her old
password.
4. The system checks tha validity of the
old password.
5. The system request the member to
enter the new password and confirm it
by rewriting it again.
6. The member enters the new
password and the confirmation.
7. The system displays a successful
message.
Alternatives:
Line 3. If the old password entered is wrong, the member will be notified and asked to enter his old
password again.
Line 6. If the confirmation entry did not match the new password entered, the member will be notified and
asked for a new password and its confirmation.
Software Requirements Specification SRS
Page 26
Use Case 6: Sign up
Actor:
Purpose:
Overview:
Type:
Cross
reference:
Student
Register students in order to access the system
A Student enters his/her information to register them in the system. The system sends an
activation email to the student. The student activates her/his account.
Primary
Functions: R2
Typ
ical
cou
rse
of
even
ts :
Actor action System response
1. This use case begins when the
students request to sign up in
order to enter the system .
2. The system show the sign up page
3. The student fill up his/her
information (full name, age, KSU
email, mobile number, Date of
birth) and save the information.
1. The system display message to
confirm the student that an activation
link have been send to his\her email.
2. sends an activation email which
contains an activation email and a
random password to members KSU
emails.
Alternitve:
Line 4: If the student didn’t fill up all required informatiom, system re-request to enter all required
informatiom.
Software Requirements Specification SRS
Page 27
Use Case 7: Submit Research. Actor:
Purpose:
Overview:
Type:
Cross
reference:
Student.
Enable student to upload, then send researches
The student uploads his/her research. The research is added to the system database. The
research is posted on the student account, finally the system send it to Technical chair.
Primary
Functions R5,R7
T
yp
ical
cou
rse
of
even
ts :
Actor action System response
1. This use case begins when the
student chooses to upload a
research .
2. The system allows the student to
browse into his/her computer.
3. The student choose file.
4. The system adds the file into the
database and reqeust research
detailes.
5. Complete research detailes by
abstract,topic and track .
6. The system posts the file into
student’s account and some the
detailes .
7. The system send research to
Technical chair.
Alternitve:
Line1:If the student choose to upload after or before due date. the system display messasge that you’ve
missed the deadline and prevent this action.
Line3:If the student choose file with name that already exists in his/her account.The system will replace
it.
Line5: If the student choose track that have been sent before, The system prevent this action and show
message.
Software Requirements Specification SRS
Page 28
Use Case 8: Edit research. Actor:
Purpose:
Overview:
Type:
Cross
reference:
Student.
To upload the final manuscripts.
When the student receives the research with the comments, she/he will edit the research .
Primary.
Function R7
Use cases: Upload file.
Typ
ical
cou
rse
of
even
ts :
Actor action System response
1. This use case begins when the
student receives the reasearch and
the comments from the Technical
Chair and requests to edit in it.
2. The system views the research with
the ability to edit in it .
3. The student edit the changes in the
research.
4. On compleation ,the student requst
to save the changes .
5. The system saves the changes add to
the research then resends it to the
Technical Chair.
Alternitve:
Line1:If the student choose to edit after due date for round two. the system display messasge that
you’ve missed the deadline and prevent this action.
Software Requirements Specification SRS
Page 29
Use Case 9: Approve researches.
Actor:
Purpose:
Overview:
Type:
Cross
reference:
Technical Chair.
Allows Technical Chair to send researches to appropriate reviewers.
The Technical chair receives researches that have been assigned to appropriate reviewers
and approves these assigned, then send it to specific reviewer.
Primary.
Function R8.
Use cases: Send research
Typ
ical
cou
rse
of
even
ts :
Actor action System responce
1. This use case begins when the
Technical Chair receveied research
with researcher’s name.
2. The system assigned researches to
reviewer depending on the track.
3. The Technical Chair make sure that
research dosen’t contain any
personal informaation.
4. The Technical Chair approve the
suggestion that have been given by
the system and send it.
5. The system send the research to
assigned reviwer.
Alternitve:
Line4: The Technical Chair may modify assigned reviwers, the ystem save the modification.
Software Requirements Specification SRS
Page 30
Use Case 10: Evaluate research.
Actor:
Purpose:
Overview:
Type:
Cross
reference:
Reviewer
Allows Reviewer to add comments and grades.
Reviewer received research, view it, add comment and decide grade, then send it to
Technical Chair.
Primary.
Function R9.
Use cases: Send research
Typ
ical
cou
rse
of
even
ts :
Actor action System responce
1. This use case begins when the
Reviewer receveied research from
Technical Chair and reguest the list
2. Show research list .
3. Chose the requsted research . 4. Display the selected research detailes
and evaluation form .
5. The Reviewer add comment to the
reseach and grade. 6. The system save comment and grade.
Software Requirements Specification SRS
Page 31
Use Case 11: Create Event.
Actor:
Purpose:
Overview:
Type:
Cross
reference:
Technical Chair
Create new event to start competition.
Technical Chair start to create new event and determinate due date for each round and
conference information, then post it.
Primary.
Function R6.
Typ
ical
cou
rse
of
even
ts :
Actor action System responce
1. This use case begins when the
Technical Chair want create new
event.
2. The system prompt to fill up event
information.
3. The Technical Chair enter
confernce information ( Name ,
Time, Date and sponser).
And due date for each round.
4. The system save information and post
it in interface of the website.
Alternitve:
Line4: The Technical Chair modify the schedule, System save the modification and post new
modification.
Software Requirements Specification SRS
Page 32
Use Case 12: Send acceptance and rejection messages.
Actor:
Purpose:
Overview:
Type:
Cross
reference:
Technical Chair
To inform the student with the result.
Technical Chair receives grade, sends acceptance and rejection messages according to
researches’ grades, then the student receives the message.
Primary.
Function R10.
Typ
ical
cou
rse
of
even
ts :
Actor action System response
1. This use case begins when the
Technical Chair recevie comments
and grades from reviewers.
2. The system determine the accepted
researches over than 70%
3. The Technical Chair send
acceptance and rejection messages
with their comments.
4. The system send messages to students
according to their grades.
5. The system send messages to
students’ emails.
Software Requirements Specification SRS
Page 33
Use Case 13: Create presentation schedule
Actor:
Purpose:
Overview:
Type:
Cross
reference:
Technical Chair
To create and organize presentation schedule.
Technical Chair start to create presentation schedule according to tracks, then the
presentation schedule will be post.
Primary.
Function R13.
Typ
ical
cou
rse
of
even
ts :
Actor action System response
1. This use case begins when the
Technical Chair start to create the
presentation schedule.
2. The system prompt the technical chair
to enter presentation time and date.
3. The Technical Chair determine the
presentation time, date.
4. The system gives suggestion of the
schedule depending on track name,
and in each track depend on alphabtic
order of researchers.
5. The Technical Chair approve the
given suggestion.
6. The system post the presentation
schedule.
Alternitve:
Line3: The Technical Chair modify the schedule, System save the modification.
Software Requirements Specification SRS
Page 34
Use Case 14: Evaluate presentation
Actor:
Purpose:
Overview:
Type:
Cross
reference:
Judge
Add presentation grade.
The judge start to add grade, the system calculate the grades, then determine the winner.
Primary.
Function R11.
Typ
ical
cou
rse
of
even
ts :
Actor action System response
1. This use case begins when the
researcher present his/her
researchand requst the list .
2. Show presentation list .
3. Chose the research presentation. 4. Display the selected presintation
detailes and evaluation form .
5. The judges enter the presentation’s
grade 6. The system save grades.
7. calculate the average grade of
judges.and save it.
Software Requirements Specification SRS
Page 35
Use Case 15: Determinate the winner.
Actor:
Purpose:
Overview:
Type:
Cross
reference:
Technical Chair
To determine the winner
The judge choose to determine the winner, the system calculate the grades, then determine
the winner.
Primary.
Function R11.
Use Case: Add grade.
Typ
ical
cou
rse
of
even
ts :
Actor action System responce
1. This use case begins when the
judge choose to determinate the
winner.
2. The system calculate grade depend on
round one grade and presentation
grade.
3. The system display the winner who
got the highest grade.
Software Requirements Specification SRS
Page 36
Use Case 16: Manage conference attendance.
Actor:
Purpose:
Overview:
Type:
Cross
reference:
Steering Chair.
Manage conference’s attendance
Steering Chair choose to start manages the number of attendance and the location..
Primary
Functions R14
Typ
ical
cou
rse
of
even
ts :
Actor action System response
1. This use case begins when the
Steering Chair start manage the
confrence attendance
2. The system prompt Steering Chair to
enter number of attendance and
location.
3. The SC enter the attendance’s
number and location for each day. 4. The system save the information.
5. The system post the location on the
interface.
Software Requirements Specification SRS
Page 37
Use Case 17: Attendance register.
Actor:
Purpose:
Overview:
Type:
Cross
reference:
Steering Chair, attendance.
To allows entering the conference.
The attendance requests to attend the conference, enter his/her information, and then print
their certification after the conference..
Primary.
Function R15.
Typ
ical
cou
rse
of
even
ts :
Actor action System responce
1. This use case begins when the
attendance request to attend the
confernce.
2. The system prompt the attendance to
fill up their information.
3. The attendance enter their
information ( name, email, phone
number and date)
4. The system decrease the allowed
number of attendace in assign date
and save the attendance information .
Line3: The attendance choose date that exceeds the allowed number of attendance, the system
reject the request.
Line3: The attendance didn’t fill up all required informarion. The system show message to re-enter
required information.
Software Requirements Specification SRS
Page 38
Use Case 18: Create Proceeding.
Actor:
Purpose:
Overview:
Type:
Cross
reference:
Steering Chair.
To create proceeding for attendances of the conferences in order to print it.
The Steering Chair request to create proceeding, system show information for all presented
researches, system will print them.
Primary.
Function R14.
Typ
ical
cou
rse
of
even
ts :
Actor action System responce
1. This use case begins when the
Steering Chait request to create
proceeding.
2. The system show all researches
information(researcher, topic and
abstract) depend on their presentation
time and date.
3. Steering Chair choose specific day. 4. The system print proceeding.
Software Requirements Specification SRS
Page 39
Use Case 19: Log Out.
Actor:
Purpose:
Overview:
Type:
Cross
reference:
Faculty member, student.
Allow the member to exit the system safely.
The member requests the system to log out. The system closes and then transfers the user to
front page of the website.
Primary
Function R16
Typ
ical
cou
rse
of
even
ts :
Actor action System response
1. The member requests the system to
log out through a log out
application.
2. The system logs out the member and
then closes.
3. Member leave the system.
Software Requirements Specification SRS
Page 40
7. SYSTEM MODELS
USE CASE DIAGRAM
Software Requirements Specification SRS
Page 41
SSD DIAGRAM
UC1: Register members:
UC2: Log In:
Software Requirements Specification SRS
Page 42
UC3: Retrieve Password:
UC4: Manage Account:
:system
Faculty member
student
RequestModification()
ModifyInformation (Information)
ConfirmChange()
NewFunctionPerformed
Software Requirements Specification SRS
Page 43
UC5: Reset Password:
UC6: Sign Up:
:system
Student
RequestRegister()
AddRegisterationInfo(name, age, email,
mobileNo, DOB)
ConfirmationMessage
Software Requirements Specification SRS
Page 44
UC7: Submit research:
:systemStudent
AddReseachRequest()
UploadBrowser
AddResearch(File)
Request details
AddResearchInfo (abstract,topic,track)
UC8:Edit research:
:systemStudent
RequestEditResearch()
Research
EditResearch(NewFile)
Software Requirements Specification SRS
Page 45
UC9: Approve research.
UC10: Evaluate research:
:systemReviewer
RequestResearchList()
List
ChooseResearch(ResearchTopic)
Research
EvaluteResearch(Comment,Grade)
:systemTechnical chair
Assigned research ()
Approve research(Research)
Software Requirements Specification SRS
Page 46
UC11: Create Event:
:systemTechnical chair
RequestCrateEvent ()
AddEvent ( name,time,date,sponsee due date )
UC12: Send acceptance and rejection messages:
Software Requirements Specification SRS
Page 47
UC13: Create presentation schedule:
:system
Technical chair
RequestCreateSchudle()
AddSchduleInfo(time,date)
suggestion
ApproveSchudle()
UC14: Evalute presentation:
system:judge
RequestResearchList()
Research List
ChoosePresentation(P.topic)
EvaluatePresentation(Grade)
Software Requirements Specification SRS
Page 48
UC15: Determinate the winner:
system:technical chair
RequestToShowTheWinner(event)
The winner
UC16: Manage conference attendance:
system: steering chair
StartManage()
AddInfo(location ,attendanceNumberm,day)
UC17: Attendance registers:
system:attendance
RequestAttendance()
addInfo(Name ,Email ,phoneNumber ,Date)
Software Requirements Specification SRS
Page 49
UC18: Create proceeding:
:system
Steering chair
Request create proceeding()
information
Choose proceed(Day)
Proceeding
UC19: Log Out:
Software Requirements Specification SRS
Page 50
CONCEPTUAL DIAGRAM
Presentation slot DateTime
Research
TopicAbstract
TrackResearchBody
StudentName Age
KSU_emailMobileNo
DOB
ReviwerFulName
TrackKSU_emailMobileNOofficeNOlocation
Account
Password
technical chairFulName
TrackKSU_emailMobileNOofficeNOlocation
Presentation evaluation
grade
steering chairFulName
TrackKSU_emailMobileNOofficeNOlocation
Conference
MaxNoLocation
TimeDate
DueDate
Attendee
NameEmail
mobileNo
JudgeFulName
TrackKSU_emailMobileNOofficeNOlocation
Has
Record bySubmit
ManageApproved
by
Managed by
Managed by
Manage
Evaluated by Manage
attends
Managed by
1
1
1
1
1
1
1
1
1
1
11
1
*
*
*
**
*
*
11
Research evaluation
Comment grade
Has1 1
*
1
1
Has
Proseed by
*
1
Department
Name
enroll
enroll
enroll
1
1
1
*
*
*
include1
*
Sponsor
Name
Sponsor1*
*
1
Software Requirements Specification SRS
Page 51
CONTRACT:
SSS System
AddResearchRequest()
RecordFaculty(Fname,track,email,Pno,OffNo,location)
RequestSendingEmail()
RequestAccess(Email,Password)
RequestRetrieve()
EnterEmail()
AddNewPassword(NewPass)
Re-AddNewPassword(NewPass)
RequestModification()
ModifyInfo(Info)
ConfirmChange()
RequestResetPass()
EnterOldPass(OldPass)
EnterNewPass(NewPass,ConfirmationMsg)
RequestRegester()
AddRegisrationInfo(Name,Age,Email,Pno,DOB)
AddResearchRequest()
AddResearch(File)
AddResearchInfo(RID,Abstract,topic,track)
RequestEditResearch()
EditResearch(NewFile)
ApproveResearch(Research)
RequestResearchList()
ChooseResearch(Topic)
EvaluateResearch(Comment,Grade)
RequestCreateEvent()
AddEvent(Name,time,date,sponsor,duedate)
RequestAcceptanceAndRejection()
RequestSendMsg(Comment,grade)
RequestCreateSchedule()
AddScheduleInfo(time,date,trackduration)
ApproveSchedule()
RequestResearchList()
ChoosePresentation(Topic)
EvaluatePresentation(Grade)
RequestToShowWinner(Event)
StartManage()
AddInfo(Location,atendeeNo,day)
RequestToAttend()
AddInfo(Name,Email,Pno,Date)
RequestCreateProceeding()
ChooseProceedDay(Day)
RequestLeaveSystem()
Software Requirements Specification SRS
Page 52
UC7: Submit Research:
Contract CO7.1: AddResearchRequest.
Operation: AddResearchRequest().
Cross References: Use Case : Submit Research .
Pre-condition: Student is logged-in and before due date of the submission.
Post-condition: None.
Contract CO7.2: AddResearch.
Operation: AddResearch(File).
Cross References: Use Case : Submit Research.
Pre-condition: Student is logged-in and before due date of the submission.
Post-condition:
Research instance "R" was created (instant creation).
R.ResearchBody was set to File (Attribute modification).
R was associated with Sudent (association formed).
R was associated with Conference (association formed).
.
Contract CO7.3: AddResearchInfo.
Operation:, AddResearchInfo(RID,abstract,topic,track).
Cross References: Use Case : Submit Research.
Pre-condition: There is a research added.
Post-condition:
R.Topic was set to topic (Attribute modification).
R.Track was set to track (Attribute modification).
R.Abstract was set to abstract (Attribute modification).
.
Software Requirements Specification SRS
Page 53
UC10: Evaluate Research:
Contract CO10.1: Choose research.
Operation: ChooseResearch(research Topic)
Cross References: Use Case: Evaluate Research.
Pre-condition: The reviewer is logged-in and there is a research assigned to the
reviewer.
Post-condition:
None.
Contract CO10.2: Evaluation research.
Operation:, EvaluationResearch (Comment , grade).
Cross References: Use Case: Evaluate Research.
Pre-condition: There is a chosen research.
Post-condition:
Research evaluation instance “RE” was created (instant creation).
RE.Comment was set to comment (Attribute modification).
RE.Grade was set to grade (Attribute modification).
RE was associated with Reviewer (association formed).
RE was associated with Research (association formed).
Software Requirements Specification SRS
Page 54
Use Case13: Create presentation schedule:
Contract CO13.1: Request create schedule.
Operation: RequestCreateSchedule()
Cross References: Use Case: Create presentation schedule.
Pre-condition: All accepted research were submitted.
Post-condition:
None.
Contract CO13.2: Add schedule information.
Operation: AddScheduleInformation(time,date)
Cross References: Use Case: Create presentation schedule.
Pre-condition: All accepted research were submitted.
Post-condition:
Presentation slot instance “PS” was created (instant creation).
PS.Date was initialized (Attribute modification).
PS.Time was initialized (Attribute modification).
PS was associated with Research (association formed).
PS was associated with Conference (association formed).
Software Requirements Specification SRS
Page 55
Use Case14: Evaluate Presentation:
Contract CO 14.1: Choose presentation.
Operation: ChoosePresentation(Rtopic).
Cross References: Use Case: Evaluate Presentation.
Pre-condition: Researches have been assigned to judge.
Post-condition:
None.
Contract CO 14.2: Evaluate presentation list.
Operation: EvaluatePresentation(grade).
Cross References: Use Case: Evaluate Presentation.
Pre-condition: Specific research has been selected
Post-condition:
Presentation evaluation instance “PE” was created (instant creation).
PE.Grade was set to grade (Attribute modification).
PE associated with judge (association formed).
PE was associated with research (association formed).
.
Software Requirements Specification SRS
Page 56
COLLABORATION DIAGRAM: UC7: Submit Research:
CD 7.1: Add research:
AddResearch (file):Student R:Research :Conference
1:Create(file) 1.1:AddResearch(R)
:Research2:add(R)
:Research
1.1.1:Add(R)
CD 7.2: Add research info:
AddResearchInfo(
RID,abstract,topic,track):Student
1:R;=find (RID) Research
R:Resreach
2:set(Abstract)
3:set (Track)
4:set(Topic)
Software Requirements Specification SRS
Page 57
UC 10: Evaluation Research:
CD 10.1: Choose research:
:Reviewer:Research
1:R;=find(RTopic)ChooseResearch(Rtopic)
CD 10.2: Evaluate research:
:Reviewer
EvaluateResearch (comment
,grade,RTopic) 1:R;=find(RTopic)Research
2:create (grade,
comment) RE:Research
Evaluate
3:Add(RE) :Research
evaluation
Software Requirements Specification SRS
Page 58
UC13: Create presentation schedule:
CD 13.1: Add Schedule Info:
:Conference :Presentation
slot
AddScheduleInfo (Date,Time)
*
2:PS;=create(Date,Time,R)
1*:[Foreach]
R;=next():Research
:Presentation
slot
3:add(PS)
Software Requirements Specification SRS
Page 59
CLASS DIAGRAM:
Student - Name : String
- Age : Real
- KSU_emai : String
- MobileNo : String
- DOB : Date
+ AddResearch (file)
+ AddResearchInfo( abstract,topic,track)
Research -Topic : String
-Abstract : String
-Track : String
-ResearchBody : String
Conference
-MaxNo : Integer
-Location : String
-Time : Time
-Date : Date
+AddResearch(R)
+AddScheduleInfo (Date,Time))
Research evaluation -Comment : String
-Grade : Real
Reviwer -FulName : String
-Track : String
-KSU_email : String
-MobileNO : String
-officeNO: Srting
-Location : String
+EvaluateResearch(comment,grade
,RTopic)
+ChooseResearch(Rtopic)
PresentationSlot-Time: Time-Date : Date
Submit
ReviewedBy
Contain
Include
1*
1
11
1
*
*
1
1
Software Requirements Specification SRS
Page 60
8. REFERENCES
[1] Keele Conferences and events[Online], Available: http://www.keele-conference.com/38/packages
[2] Annual Conference of the Australasian Research Management Society[Online], Available :
http://www.promaco.com.au/2010/arms/
[3] The Australasian Research Management Society[Online], Available: http://www.iceaustralia.com/arms2011/
[4] Academic conference international[Online], Available: http://www.academic-
conferences.org/ecrm/ecrm2011/ecrm11-home.htm
[5] Melbourne Conference Management[Online], Available: http://www.mcmconferences.com/conferences.html
Software Requirements Specification SRS
Page 61
APPENDICES APPENDIX A
Questionnaires’ sample
Students Scientific Symposium (SSS) is a web-based software application it’s the most
important event that Students Partnership Program (SPP) has organized, it aims students to
contest against each other by submitting a scientific research papers in specific track.
To help us to create a system that satisfies you and find what you need in this system, please
fill the questionnaire below:
1- Would you like the system's language to be English?
Agree
Disagree
Not interested
2- Registration required accessing the system.
Agree
Disagree
Not interested
3- Would you like the registration for attendance to be by membership?
Agree
Disagree
Not interested
4- Receive an email from the website about the latest event.
Agree
Disagree
Not interested
Software Requirements Specification SRS
Page 62
5- Summary and glossary after each conference service.
Agree
Disagree
Not interested
6- Categorize events in to sections based on especially field.
Agree
Disagree
Not interested
7- Alert members 3 days before symposiums’ dates, submission deadline and
registration date on the website home page.
Agree
Disagree
Not interested
… If you AGREE Would you like the alert to be optional?
Agree
Disagree
Not interested
8- Would you like the Member’s email, password and phone number to be
private unless user wants otherwise?
Agree
Disagree
Not interested
Software Requirements Specification SRS
Page 63
If you agree The information that appears to the public about members is
name, specialty.
Agree
Disagree
Not interested
9- Do you want to be able to search for members?
Agree
Disagree
Not interested
10- Would you like to have a help and common questions bar?
Agree
Disagree
Not interested
11- Knowing the event attendees may concern you?
Agree
Disagree
Not interested
12- Would you like to see the Participating researches ?
Agree
Disagree
Not interested
Software Requirements Specification SRS
Page 64
… If you Disagree would you like to have an abstract for each research?
Agree
Disagree
Not interested
13- Would you like to have a limited time for your membership?
Agree
Disagree
Not interested
14- Show the wining research?
Agree
Disagree
Not interested
15- Show the winners’ name?
Agree
Disagree
Not interested
Recommended