+ All Categories
Home > Documents > Software Requirements Specifications · Introduction ... Intended Audience of the SRS ... In this...

Software Requirements Specifications · Introduction ... Intended Audience of the SRS ... In this...

Date post: 05-Apr-2018
Category:
Upload: vankhue
View: 217 times
Download: 0 times
Share this document with a friend
45
1 Software Requirements Specifications Umbrella Enterprises Umut AKIN-1745652 Güneş SUCU-1679190 Eren METE-1679109 Merve AK-1678622 11.11.2012
Transcript

1

Software Requirements Specifications

Umbrella Enterprises

Umut AKIN-1745652

Güneş SUCU-1679190

Eren METE-1679109

Merve AK-1678622

11.11.2012

2

Table of Contents 1. Introduction ............................................................................................................................ 4

1.1 Problem Definition ............................................................................................................ 4

1.2 Purpose ............................................................................................................................ 4

a) Purpose of the SRS ........................................................................................................ 4

b) Intended Audience of the SRS ........................................................................................ 4

1.3 Scope ............................................................................................................................... 4

1.4 Definitions, Acronyms and Abbreviations .......................................................................... 5

1.5 References ....................................................................................................................... 6

1.6 Overview .......................................................................................................................... 6

2 Overall Description .................................................................................................................. 7

2.1 Product Perspective ......................................................................................................... 7

2.2 Product Functions ............................................................................................................. 7

2.3 Constraints ....................................................................................................................... 7

2.4 Assumptions and Dependencies ...................................................................................... 8

3 System Features ..................................................................................................................... 8

3.1 Interface Requirements .................................................................................................... 8

3.2 Functional Requirements .................................................................................................. 9

3.2.1 Sign Up .....................................................................................................................10

3.2.2 Sign in .......................................................................................................................12

3.2.3 Manage Account Settings .........................................................................................13

3.2.4 Create New Conference ............................................................................................15

3.2.5 Paper Upload ............................................................................................................17

3.2.6 Configure PC Members .............................................................................................19

3.2.7 Assign referee to paper .............................................................................................21

3.2.8 Acceptance and Rejection .........................................................................................23

3.2.9 Email Notification ......................................................................................................25

3.2.10 Select Language Option ..........................................................................................26

3.2.11 Create Conference Schedule ..................................................................................28

3.2.12 Transportation and Accommodation Services .........................................................30

3.2.13 Display Announcements ..........................................................................................32

3.2.14 Sign out ...................................................................................................................33

3.2.15 Objection Right Of Author .......................................................................................35

3

3.2.16 Submission of Final Copies of Paper .......................................................................37

3.3 Non-functional Requirements ..........................................................................................38

3.3.1 Performance requirements ........................................................................................39

3.3.2 Security requirements ...............................................................................................39

3.3.3 Design constraints .....................................................................................................39

4 Behavioral Model and Description ..........................................................................................39

4.1 Description for Software Behavior ...................................................................................39

4.2 State Transition Diagram .................................................................................................40

4.2.1 Paper Submission State Diagram .............................................................................40

4.2.2 Paper Acceptance/Rejection State Diagram ..............................................................41

..........................................................................................................................................41

4.2.3 Referee Assignment State Diagram ..........................................................................42

4.2.4 Evaluation by Referee State Diagram .......................................................................43

5 Planning .................................................................................................................................44

5.1 Team Structure ................................................................................................................44

5.2 Estimation ........................................................................................................................44

5.3 Process Model .................................................................................................................44

6 Conclusion .............................................................................................................................45

4

1. Introduction

1.1 Problem Definition

In this project, the main problem is to develop a conference management system that manages

the papers which are submitted according to correct hierarchies and arranges a schedule for the

conferences in a web application. Database management and user-friendly interfaces will be

main priorities. It will have the same functionalities as the ones already exists and have some

additional features. Language support will be added as Turkish, English and German. One ID

system will be integrated and thus users will not need different user IDs and passwords for each

conference. Blind Review functionality will be added and referees will not see the author of the

paper. The approved papers will be listed and automatically sent to technical program

committee chair. After that, a tourism agency support will be added for attendees to reserve

hotel rooms and flight tickets.

1.2 Purpose

a) Purpose of the SRS

The purpose of this SRS is to show a detailed explanation of the web based conference

management system. This document will introduce the system with its purposes and help

understand the system features, input systems and interfaces smoothly.

b) Intended Audience of the SRS

The intended audience of this document is both the users and the developers since both will

gain the required knowledge about conference management system.

1.3 Scope

This system uses a web application as interface and SQL for database management purposes.

It will have extra features compared to existing open source conference management websites.

Other than that, the core functionalities which already exist are registration of authors , paper

submission, reviewer assignments , group e-mailing , collecting grades given by reviewers , and

5

collecting final accepted papers. Extra functionalities are multi-language support, openID

functionality, blind review option and tourism agency support.

1.4 Definitions, Acronyms and Abbreviations

WORD MEANING

JDK Java Development Kit which

contains numerous programming tools for

java.

JRE Java Runtime Environment which

runs the program by using the libraries and

other supporting files.

JVM Java Virtual Machine which

interprets the byte codes to machine code.

PC Personal Computer which is used

for general purposes.

UC Use case

IEEE Institute of Electrical and

Electronics Engineers

MVC-MVP Model-View-Controller (or Model-View-

Presenter) model is a software pattern

generally used for building user interfaces

DBMS Database Management System is a set of programs

that enables you to store, modify, and extract

information from a database

PC Member, PC Chair Program Committee member that evaluates papers

6

and Program Committee chair that assigns PC

members, accepts the papers that are selected and

arranged the schedule for the conference.

1.5 References

IEEE. IEEE Std 830-1998 IEEE Recommended Practice for Software Requirements

Specifications. IEEE Computer Society, 1998.

1.6 Overview

The next chapter, the Overall Description section, of this document gives an overview of the

functionality of the product. It describes the informal requirements and is used to establish a

context for the technical requirements specification in the next chapter. The third chapter,

System Features section, of this document is written primarily for the developers and describes

the technical terms and the details of the functionality of the product.

Both sections of the document describe the same software product entirely, but are intended for

different audiences and thus use different language. The Overall Description part

is meant for users, meanwhile the System Features section focuses on developers. Behaviour

Model and Description part contains the major events and features. Planning section contains

the estimated times for reports, prototype and demos. Lastly, the Conclusion section briefly

summarizes and concludes the overall project.

7

2 Overall Description

2.1 Product Perspective

This system is a server side multi-layer web application. External relational database

management system is used as a data layer by this system. In order to connect to the system

as a client, every user uses only a web browser. The system and its business logic should be

based on Vaadin UI Framework technology that provides platform. Vaadin provides also rapid

application development.

2.2 Product Functions

A conference management system that manages all administrative and organizational tasks of a

conference. The main tasks the system will perform are to:

● registrations

● single log-in authentication

● create a new conference

● paper submissions

● paper referee assignments

● periodical announcements

● referee evaluation

● final manuscript submissions, publisher relations

● conference rooms presentation schedule

● web page and announcement

● select language option

● transportation and accommodation services

2.3 Constraints

Firstly, web server should be reliable. Server uptime is critical around author and reviewer

deadlines. Web server and DBMS should be capable of receiving a large number of requests

simultaneously.

8

The user should not be required to accept cookies in a web browser on user’s machine.

2.4 Assumptions and Dependencies

Users just need the latest Java to be installed on the computer and developers need to include

vaadin.jar and h2.jar to use Vaadin and h2. Vaadin is an open source Java Based UI

Framework for web applications. No HTML,XML or JavaScript is required. All Java libraries are

at your disposal. Also h2 is an open source database management system. Vaadin and h2 are

already included in the project library but if they do not exist, the project should not work. If h2 is

not open at the moment, database operations will not commence.

3 System Features

The following sections identify the features that will be available to users in conference

management system.

3.1 Interface Requirements

User interface should be provided through a web browser. In main page, there exist sign up and

sign in buttons. A new author will register into the database as a user. If user already exists in

database, it will display the error then author should try again with new username. When user

signs in, personal information page opens and user can reach existing conferences and

conferences that is registered by clicking their buttons. Moreover, at first opening of the page

sign out button is also seen. In existing conference page, user can choose any conference

which he/she wants and he/she submits the paper. Every user sees different menus according

to access right of the user for that conference.

9

3.2 Functional Requirements

This section outlines the use cases for user.

10

3.2.1 Sign Up

Name of the Project Conference Management and Hosting System

Use Case No UC1

Name of the Use Case Sign up

Created By Güneş Sucu

Date Created 09.11.2012

Last Updated By

Date Last Updated

Actors Off-system users

Description The user registers to the system by entering required

information.

Preconditions 1. The user should not have an existing account.

Postconditions 1. The registration request of the user is sent to admin for

approval.

2. Until the registration request is accepted, the user should

not be allowed to enter the system.

3. Until the registration request is rejected, the request should

11

be kept in the system.

Priority High

Frequency of Use Very often

Normal Flow: 1. Main page

2. Click on the sign up button

3. Fill in the registration form

4. Display the information message

Alternative Flows: If user has already signed up the system, system will sent the

existing user information to the user.

Exceptions: In step 3 of the normal flow , if user do not fill the registration

form properly

1. Display message to the user to re-enter information

2. Customer enters the proper information

Includes: -

Special Requirements: Security controls should be made carefully. Malicious people

might try to get someone else’s account. In order to avoid this,

user information must be tested before it is parsed.

Assumptions: 1. User should has basic computer knowledge.

2. User understands either English,German or Turkish.

Notes and Issues: What is the maximum size of the username and password?

12

3.2.2 Sign in

Name of the Project Conference Management and Hosting System

Use Case No UC2

Name of the Use Case Sign in

Created By Eren Mete

Date Created 09.11.2012

Last Updated By

Date Last Updated

Actors Conference Chair, Technical PC Chair, Publication Chair,

Registration Chair, PC Member , Author

Description The user logs in to the system by entering username and

password.

Preconditions 1. The user should have an existing account in the system.

Postconditions User enters the system

1. Main page is opened

In case of non-existent username or username-password

mismatch user cannot enter the system

Priority High

13

Frequency of Use Very often

Normal Flow: 1. Main page

2. Click on login button

3. Enter username, password fields

4. Display the information message

Alternative Flows: -

Exceptions: In step 3 of the normal flow , if user enters non-existent

username

1. Display username does not exist message

2. Return to login page

In step 3 of the normal flow , if user enters wrong password for

given username

1. Display wrong password entered message

2. Return to login page

Includes: 1. Sign Up

Special Requirements: -

Assumptions: 1. User should has basic computer knowledge.

2. User understands either English,German or Turkish.

Notes and Issues: OpenID issue should be determined

3.2.3 Manage Account Settings

14

Name of the Project Conference Management and Hosting System

Use Case No UC3

Name of the Use Case Manage account settings

Created By Eren Mete

Date Created 09.11.2012

Last Updated By

Date Last Updated

Actors Conference Chair, Technical PC Chair, Publication Chair,

Registration Chair, PC Member , Author

Description The user manages all account information.

Preconditions 1. The user must have an existing account in the system.

2. User must be logged in.

Postconditions 1.a. User edits information

1.a.1. Old values are replaced with changed values in

database.

1.b User deletes account.

1.b.1. User data is deleted from database.

2. Send e-mail notification

Priority Medium

Frequency of Use Often

Normal Flow: 1. Main page

15

2. Enter login information

3. Select manage account settings

4.a. Select edit account

4.b. Select delete account

Alternative Flows: -

Exceptions: In step 4.a of the normal flow , if changes could not be done,

1. Display “changes could not be done” message

2. Return to edit account page

In step 4.b of the normal flow , if account could not be deleted

from database,

1. Display “account could not be deleted” message

2. Go to edit account page

Includes: 1. Sign In

2. E-mail Notification

Special Requirements: -

Assumptions: -

Notes and Issues: Which settings can be changed?

3.2.4 Create New Conference

Name of the Project Conference Management and Hosting System

16

Use Case No UC4

Name of the Use Case Create New Conference

Created By Umut Akın

Date Created 09.11.2012

Last Updated By

Date Last Updated

Actors Conference Chair, Technical PC Chair, Publication Chair,

Registration Chair, PC Member , Author

Description User applies to admin to organize a conference

Preconditions 1. The user must be logged in to the system.

Postconditions User’s conference request is accepted by admin

1. Conference information is created in system.

2. Conference request form is deleted from server

3. Conference request acceptance message is sent to

applicant via e-mail.

4. The applicant user is granted access as Conference

Chairman for that created conference

User’s conference request is rejected by admin

1. Conference request form is deleted from server

2. Conference request rejection message is sent to

applicant via e-mail.

Priority High

17

Frequency of Use Sometimes

Normal Flow: 1. Main page

2. Enter login information

3. Click new conference request button

4. Admin accepts new conference request

5. Conference is created

6. Send e-mail notification to user

Alternative Flows: 4.b Admin rejects new conference request

5. Conference is not created

6. Send e-mail notification to user

Exceptions: -

Includes: 1. Sign In

2. E-mail Notification

Special Requirements: -

Assumptions: -

Notes and Issues: What is the type of the conference?

3.2.5 Paper Upload

Name of the Project Conference Management and Hosting System

Use Case No UC5

18

Name of the Use Case Paper upload

Created By Eren Mete

Date Created 09.11.2012

Last Updated By

Date Last Updated

Actors User

Description Author uploads paper to be accepted to conference

Preconditions 1. The user must be logged in to the system.

Postconditions Uploaded file is saved to file system

1. Upload successful message displayed

2. Go to main page

File could not be uploaded

Priority High

Frequency of Use Very often

Normal Flow: 1. Main page

2. Enter login information

2. Select conference for paper to be uploaded

3. Click upload button

4. File type check is done

5. File uploaded to server

6. Display the information message

Alternative Flows: -

Exceptions: In step 3 of the normal flow , if user tries to upload

19

unsupported file type

1. Upload failed

2. Unsupported file type message is displayed

3. Return to paper upload page

In step 3 of the normal flow , if upload fails

1. Upload failed

2. Upload failed message is displayed

3. Return to paper upload page

Includes: 1. Sign In

2. E-mail Notification

Special Requirements: Uploaded file type must be one of determined file types

Assumptions: -

Notes and Issues: Upload fail conditions will be determined

3.2.6 Configure PC Members

Name of the Project Conference Management and Hosting System

Use Case No UC6

Name of the Use Case Configure PC Members

Created By Eren Mete

20

Date Created 09.11.2012

Last Updated By

Date Last Updated

Actors Technical PC Chair

Description Technical PC Chair determines and adds PC Members to

conference

Preconditions 1. The user must be logged in to the system.

2. User must have Technical PC Chair rights.

3. User must have chosen conference.

Postconditions 1. Chosen users are added to specified conference

2. Chosen users are granted access as PC member for that

conference

3. E-mail notification is sent to chosen users

Priority High

Frequency of Use Very often

Normal Flow: 1. Main page

2. Enter login information

3. Select conference

4. Select configure PC Members

5.a. Select add PC Members

5.a.1 Enter the username of user that determined as PC

Member to be added

5.b. Select delete PC Members

5.b.1 Enter the username of user that will be deleted from

21

PC Members for that conference

Alternative Flows: -

Exceptions: In step 5.a.1 of the normal flow , if Technical PC Chair enters

non-existent user in the system

1. User does not exist message is displayed

2. “Go to add PC Members page

In step 5.a.1 of the normal flow , if Technical PC Chair enter

a name that is already PC Member

1. User is already PC Member message is displayed

2. Go to add PC Members page

In step 5.b.1 of the normal flow , if Technical PC Chair enter

a name that is not PC Member

1. Given PC Member does not exist message is displayed

2. Go to delete PC Member page

Includes: 1. Sign In

2. E-mail Notification

Special Requirements: -

Assumptions: -

Notes and Issues: assign PC member deadline

3.2.7 Assign referee to paper

22

Name of the Project Conference Management and Hosting System

Use Case No UC7

Name of the Use Case Assign referee to paper

Created By Umut Akın

Date Created 09.11.2012

Last Updated By

Date Last Updated

Actors Technical PC Chair

Description Technical PC Chair assigns PC Members to papers

Preconditions 1. The user must be logged in to the system.

2. User must have Technical PC Chair rights.

3. User must have chosen conference.

Postconditions 1. Papers are sent to assigned PC Members

Priority High

Frequency of Use Very often

Normal Flow: 1. Main page

2. Enter login information

3. Select conference

4. Select assign PC Members to papers

5.a. User assigns PC members to the papers manually

5.b. User assigns PC members to the papers according to

interested areas.

23

Alternative Flows: -

Exceptions: When deadline has passed assignment is done

automatically

Includes: 1. Sign In

Special Requirements: -

Assumptions: -

Notes and Issues: System suggest PC members to Technical PC Chair

according to their paper selection choices.

3.2.8 Acceptance and Rejection

Name of the Project Conference Management and Hosting System

Use Case No UC8

Name of the Use Case Acceptance and Rejection

Created By Umut Akın

Date Created 09.11.2012

Last Updated By

Date Last Updated

24

Actors Technical PC Chair

Description Technical PC Chair accepts or rejects the papers uploaded

by the authors according to the reviews of referee

Preconditions 1. The author should have an active account

Postconditions 1. In both condition(acceptance or rejection) a notification

mail is sent to the author

Priority High

Frequency of Use Often

Normal Flow: 1. The author signs in the system

2. The author uploads a paper

3. The referee reviews the paper uploaded by the author

4. The technical PC chair accepts or rejects the paper taking

the review of the referee into consideration

Alternative Flows: In step 1 of the normal flow, if the author is not registered to

the system

1. The system redirects the author to the sign up page

2. The author is registered to the system

3. Use case resumes on step 1 of normal flow

Exceptions: In step 1 of the normal flow, if the author enters an invalid

username or password

1. Entering the system is denied

2. Message to the author to re-enter the username or

password

3.The author enters correct username or password

4. Use case resumes on step 1 of normal flow

25

Includes: 1. Sign in

2. Sign up

3. Upload paper

4. E-mail notification

Special Requirements: -

Assumptions: -

Notes and Issues: -

3.2.9 Email Notification

Name of the Project Conference Management and Hosting System

Use Case No UC9

Name of the Use Case Email Notification

Created By Güneş Sucu

Date Created 10.11.2012

Last Updated By

Date Last Updated

26

Actors System Itself

Description When necessary the system automatically sends mails to the

users to notify them

Preconditions 1. There should be a situation that requires to notify users

Postconditions 1. The user obtains necessary information about the

situation

Priority High

Frequency of Use Often

Normal Flow:

1. There arises a situation that user should be notified

2. The system sends an email to the user

Alternative Flows: -

Exceptions: -

Includes: 1. Sign up

2. Acceptance and Rejection

Special Requirements: -

Assumptions: -

Notes and Issues: 1. What should be the content of the notification?

3.2.10 Select Language Option

27

Name of the Project Conference Management and Hosting System

Use Case No UC10

Name of the Use Case Select Language Option

Created By Güneş Sucu

Date Created 10.11.2012

Last Updated By

Date Last Updated

Actors Conference Chair, Technical PC Chair, Publication Chair,

Registration Chair, PC Member , Author and Off-system

users

Description The user can select the language option he wants or he can

use the system in default(English) language.

Preconditions 1. The user should enter the web page of the system

Postconditions 1. The user starts to use the system in the language he has

chosen

Priority High

Frequency of Use Very Often

Normal Flow:

1. The user wants to change the language of the system

2. The user pushes the button of the language he wants

3. The system changes into the language the user has

chosen

Alternative Flows: In step 2 of the normal flow, if the user pushes wrong

28

button(which he doesn’t want to)

1. The system changes into the language which the user

does not want to use

2. Use case resumes on step 1 of normal flow

Exceptions: Defaultly English will be used

Includes: -

Special Requirements: -

Assumptions: -

Notes and Issues: 1. How many languages should be supported?

3.2.11 Create Conference Schedule

Name of the Project Conference Management and Hosting System

Use Case No UC11

Name of the Use Case Create Conference Schedule

Created By Merve Ak

Date Created 09.11.2012

Last Updated By

Date Last Updated

29

Actors Technical PC Chair

Description Technical PC Chair will create conference schedule for the

people whose papers are accepted.

Preconditions 1. Technical PC chair should decide which papers are accepted

or rejected.

2. Authors should be notified of the starting time of the

conference

Postconditions 1. Created schedule is published by technical PC chair.

2. Authors who want to participate in conference approve the

schedule.

3. Authors who do not want to participate in conference refuse

the schedule.

Priority High

Frequency of Use Often

Normal Flow: 1. Conference schedule is created manually by technical PC

chair.

2. This schedule is published.

3. Informing notification is sent to authors whose papers are

accepted.

4. Authors approve or refuse the schedule.

5. Technical PC chair makes the final arrangements about who

will be the participants.

6. Final version of the schedule gets certainty.

7. Final version of the schedule is published.

Alternative Flows: -

Exceptions: If the author changes his/her mind, technical PC chair again

30

arranges the schedule manually.

Includes: 1. Acceptance and Rejection

Special Requirements: -

Assumptions: Authors should be available on time of the conference.

Notes and Issues: 1. What is the number of people attending the conference?

2. Whether the conference dates are flexible or not.

3.2.12 Transportation and Accommodation Services

Name of the Project Conference Management and Hosting System

Use Case No UC12

Name of the Use Case Transportation and Accommodation Services

Created By Merve Ak

Date Created 09.11.2012

Last Updated By

Date Last Updated

31

Actors Author, Travel Agency

Description Transportation and accommodation services are provided to

the participants.

Preconditions 1. The list of the participants should be finalized.

2. Travel agency should has an account to enter the

conference management system.

Postconditions -

Priority Low

Frequency of Use Rare

Normal Flow: 1. The author signs in the system.

2. The author submits the paper.

3. Papers are evaluated by referee.

4. Author gets notification about participation status.

5. If author participates in the conference, “Would you like to

have travel and accommodation services?” question is

asked.

6. If author accepts services, travel agency contacts him/her.

Alternative Flows: If author rejects these services, author arranges

transportation and accommodation.

Exceptions: -

Includes: 1. Sign in

2. Paper Submission

3. Acceptance and Rejection

Special Requirements: -

Assumptions: -

Notes and Issues: How many travel agencies can use this system?

32

3.2.13 Display Announcements

Name of the Project Conference Management and Hosting System

Use Case No UC13

Name of the Use Case Display Announcements

Created By Umut Akın

Date Created 10.11.2012

Last Updated By

Date Last Updated

Actors System

Description System displays announcements about conferences in the

main page

Preconditions -

Postconditions In the main page announcements are displayed.

33

Priority High

Frequency of Use Very often

Normal Flow: System displays the announcements in the main page

Alternative Flows: -

Exceptions: -

Includes: -

Special Requirements: -

Assumptions: -

Notes and Issues: 1. Automation of announcements may be implemented.

3.2.14 Sign out

Name of the Project Conference Management and Hosting System

Use Case No UC14

Name of the Use Case Sign out

Created By Merve Ak

Date Created 10.11.2012

34

Last Updated By

Date Last Updated

Actors Conference Chair, Technical PC Chair, Publication Chair,

Registration Chair, PC Member , Author

Description The user logs out the system by clicking sign out button.

Preconditions 1. The user should have an existing account in the system.

2. The user should enter the conference management

system.

Postconditions The user cannot use the system.

Priority High

Frequency of Use Very often

Normal Flow: 1. The user signs in the system.

2. The user goes to main page.

3. The user clicks the sign out button.

Alternative Flows: -

Exceptions: -

Includes: 1. Sign In

Special Requirements: -

Assumptions: -

Notes and Issues: -

35

3.2.15 Objection Right Of Author

Name of the Project Conference Management and Hosting System

Use Case No UC15

Name of the Use Case Objection Right of Author

Created By Güneş Sucu

Date Created 11.11.2012

Last Updated By

Date Last Updated

Actors Author

Description The author has the right of objecting to the decision made by

the technical PC chair when the paper of the author is

rejected by him/her.

Preconditions 1. The author should have an existing account in the system.

2. The author should sign in the system.

3. The author should upload a paper.

4. The referee should review the paper uploaded by the

author.

5. The technical PC chair should reject the paper taking the

review of the referee into consideration.

36

6. The author should get a notification email about the

rejection.

Postconditions 1. It will be certainly determined whether the author will

participate in the conference or not.

Priority Medium

Frequency of Use Sometimes

Normal Flow: 1. The author sends an objection email to the PC chair.

2. The PC chair revises the paper.

3. The PC chair makes the last decision.

4. The PC chair sends an email to the author about the final

decision (acceptance or reject).

Alternative Flows: -

Exceptions: -

Includes: 1. Sign in

2. Acceptance and rejection

3. Paper upload

4. Email notification

Special Requirements: -

Assumptions: -

Notes and Issues: 1. What will be the duration for the objection?

2. What will be the duration for the response?

37

3.2.16 Submission of Final Copies of Paper

Name of the Project Conference Management and Hosting System

Use Case No UC16

Name of the Use Case Submission of Final Copies of Paper

Created By Güneş Sucu

Date Created 17.01.2013

Last Updated By

Date Last Updated

Actors Author

Description Author submits the final copy of the paper accepted.

Preconditions 1. The author should have an existing account in the system.

2. The author should sign in the system.

3. The author should upload a paper.

4. The referee should review the paper uploaded by the

author.

5. The technical PC chair should accept the paper taking the

review of the referee into consideration.

6. The author should get a notification email about the

acceptance.

38

Postconditions 1. It will be certainly determined whether the author will

participate in the conference or not.

Priority High

Frequency of Use Very Often

Normal Flow: 1. Acceptance notification is sent to author.

2. Author signs in the system.

4. Select conference for paper to be uploaded

5. Click upload button

6. File type check is done

7. File uploaded to server

8. Display the information message

Alternative Flows: -

Exceptions: -

Includes: 1. Sign In

2. E-mail Notification

3. Paper Upload

4. Acceptance and Rejection

Special Requirements: -

Assumptions: -

Notes and Issues: -

3.3 Non-functional Requirements

There are three non-functional requirements that are performance requirements, security

requirements and design constraints.

39

3.3.1 Performance requirements

● This software system does not need specific computer properties. This program can be

run at any computer which has internet connection and any browser.

● This program is also portable so there is no need of setup to execute the system.

● There is no need of high performance hardware to run the program.

3.3.2 Security requirements

● The user is required to enter some information into the system. Especially, username

and password information is very important. These information must be protected

against the malicious users. Password does not keep as entered in the system.

Therefore, when the password is stored in database, hashing method should be used.

● Some user pages should be entered by specific people. For example, only technical PC

chair can enter the technical PC chair’s page. If malicious users access these pages,

unexpected results can occur. In order to avoid that, it is controlled in a better way.

3.3.3 Design constraints

When reporting IEEE standards will be used and when drawing diagrams UML standards will be

used.

4 Behavioral Model and Description

4.1 Description for Software Behavior

After software is deployed to the server, an admin must be created with all accesses. Admin is a

must for accepting conference creation requests. Then users can apply for organizing

conferences. If request is accepted by admin necessary access rights are given to requested

users. For all the users software has a utility to choose the language for the application.

Selecting desired language changes all the text on the buttons, menus, and text fields in the

application. Because users can have different access rights for different conferences, they

should select the conference to be able to use the role for selected conference. Also in a

conference a user may have different roles, so after selecting the conference user should

40

choose the user group that is wanted to be reached as. Then related menus appear for

specified conference. User can log out the system using sign out button.

4.2 State Transition Diagram

4.2.1 Paper Submission State Diagram

41

4.2.2 Paper Acceptance/Rejection State Diagram

42

4.2.3 Referee Assignment State Diagram

43

4.2.4 Evaluation by Referee State Diagram

44

5 Planning

5.1 Team Structure

Team members are specified below, although work sharing between team members are

tentative, the main focus is like that;

● Umut AKIN - Java Developer, Project Review

● Merve AK - Software and Design Document Generation, Tests

● Eren METE - Java Developer, Project Review

● Güneş SUCU - Software and Design Document Generation, Tests

5.2 Estimation

● Submission of the SRS : 11 November 2012

● Submission of the SDD : 22 November 2012

● Requirement and Design Reports Update : 18 January 2013

● Prototype Demo : 22 January 2013

● Submission of the STD : Second Semester

● Demo of the Project : Second Semester

● Submission of the Final Report : Second Semester

5.3 Process Model

The MVC and other object oriented design patterns are going to be used in this application. The

components of MVC model is described below:

● The model is an interface defining the data to be displayed or otherwise acted upon in

the user interface.

● The view is an interface that displays data (the model) and routes user commands

(events) to the presenter to act upon that data.

● The presenter acts upon the model and the view. It retrieves data from repositories (the

model), and formats it for display in the view.

45

6 Conclusion

This SRS is prepared in order to explain the full design and process for the web application. The

aim was to make users and developers keen on the usage of web based conference

management system. By reading this, they will get a knowledge on how and why should they

use it or further develop it for public usage.


Recommended