IT322 Software Engineering I Student Scientific … Engineering I Student Scientific Symposium ... Software Requirements Specification SRS Page 4 1. INTRODUCTION Student ... characteristics

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

http://sw322.pbworks.com/w/page/37082027/WELCOME

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


Shahd Albluwi

Ghalya Albugami

Mjd AlOnaizan,Fay Al-Sehaibani


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


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


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.


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.


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.


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

√ √ √ √ √


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.


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.


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


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.


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%


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%


Page 13


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%


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.


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 protected]”, 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 protected]”).

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.

mailto:[email protected]

mailto:[email protected]


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.


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.


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.


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.


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.


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.


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


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.


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 :



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.


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 :



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.


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 :



member chooses to reset his

password through his account.


enter his/her old password

3. The member enters his/her old

password.

4. The system checks tha validity of the

old password.


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.


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 :



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.


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 :



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.


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 :



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.


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 :



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.


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 :



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.


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 :



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.


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 :



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.


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 :



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.


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 :



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.


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 :



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.


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 :



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.


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 :



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.


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 :



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.


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 :


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.


Page 40

7. SYSTEM MODELS

USE CASE DIAGRAM


Page 41

SSD DIAGRAM

UC1: Register members:

UC2: Log In:


Page 42

UC3: Retrieve Password:

UC4: Manage Account:

:system

Faculty member

student

RequestModification()

ModifyInformation (Information)

ConfirmChange()

NewFunctionPerformed


Page 43

UC5: Reset Password:

UC6: Sign Up:

:system

Student

RequestRegister()

AddRegisterationInfo(name, age, email,

mobileNo, DOB)

ConfirmationMessage


Page 44

UC7: Submit research:

:systemStudent

AddReseachRequest()

UploadBrowser

AddResearch(File)

Request details

AddResearchInfo (abstract,topic,track)

UC8:Edit research:

:systemStudent

RequestEditResearch()

Research

EditResearch(NewFile)


Page 45

UC9: Approve research.

UC10: Evaluate research:

:systemReviewer

RequestResearchList()

List

ChooseResearch(ResearchTopic)

Research

EvaluteResearch(Comment,Grade)

:systemTechnical chair

Assigned research ()

Approve research(Research)


Page 46

UC11: Create Event:

:systemTechnical chair

RequestCrateEvent ()

AddEvent ( name,time,date,sponsee due date )

UC12: Send acceptance and rejection messages:


Page 47

UC13: Create presentation schedule:

:system

Technical chair

RequestCreateSchudle()

AddSchduleInfo(time,date)

suggestion

ApproveSchudle()

UC14: Evalute presentation:

system:judge


Research List

ChoosePresentation(P.topic)

EvaluatePresentation(Grade)


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)


Page 49

UC18: Create proceeding:

:system

Steering chair

Request create proceeding()

information

Choose proceed(Day)

Proceeding

UC19: Log Out:


Page 50

CONCEPTUAL DIAGRAM

Presentation slot DateTime

Research

TopicAbstract

TrackResearchBody

StudentName Age

KSU_emailMobileNo

DOB

ReviwerFulName

TrackKSU_emailMobileNOofficeNOlocation

Account

Password

technical chairFulName


Presentation evaluation

grade

steering chairFulName


Conference

MaxNoLocation

TimeDate

DueDate

Attendee

NameEmail

mobileNo

JudgeFulName


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


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)


ChooseResearch(Topic)

EvaluateResearch(Comment,Grade)

RequestCreateEvent()

AddEvent(Name,time,date,sponsor,duedate)

RequestAcceptanceAndRejection()

RequestSendMsg(Comment,grade)

RequestCreateSchedule()

AddScheduleInfo(time,date,trackduration)

ApproveSchedule()


ChoosePresentation(Topic)

EvaluatePresentation(Grade)

RequestToShowWinner(Event)

StartManage()

AddInfo(Location,atendeeNo,day)

RequestToAttend()

AddInfo(Name,Email,Pno,Date)

RequestCreateProceeding()

ChooseProceedDay(Day)

RequestLeaveSystem()


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

.


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


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


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

.


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)


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


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)


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


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


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


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


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


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

Documents

IT322 Software Engineering I Student Scientific … Engineering I Student Scientific Symposium ... Software Requirements Specification SRS Page 4 1. INTRODUCTION Student ... characteristics