SOFTWARE REQUIREMENT SPECIFICATION

for

CONFMAN
v1.1
CREATED BY CENGIZOVER
Birand Koray Eren Ahmet Anl Pala Mustafa Yavuz Burak n

CONTENTS

1. Introduction .................................................................................................................................. 5 1.1 Problem Definition ................................................................................................................. 5 1.2 Purpose ................................................................................................................................... 7 1.3 Scope ...................................................................................................................................... 7 1.4 Market Survey ........................................................................................................................ 7 1.5 Abbreviations & Acronyms ................................................................................................... 8 1.6 References ............................................................................................................................ 10 1.7 Overview .............................................................................................................................. 10 2. Overall Description .................................................................................................................... 11 2.1 Product Perspective .............................................................................................................. 11 2.1.1 User Interfaces ............................................................................................................... 11 2.1.2 Hardware Interfaces ...................................................................................................... 13 2.1.3 Software Interfaces ........................................................................................................ 14 2.1.4 Memory Constraints ...................................................................................................... 14 2.2 User Classes ......................................................................................................................... 14 2.2.1 STANDARD (Unassigned) Member ............................................................................ 14 2.2.2 System Administrator .................................................................................................... 14 2.2.3 Conference Supervisor .................................................................................................. 14 2.2.4 Conference Chair(s) ...................................................................................................... 15 2.2.5 Program COMMITTEE (PC) Member ......................................................................... 15 2.2.6 Author............................................................................................................................ 16 2.2.7 Reviewer........................................................................................................................ 16 2.2.8 Participant...................................................................................................................... 17 2.3 Constraints ............................................................................................................................ 17 2

3.SPECIFIC REQUIREMENTS .................................................................................................... 17 3.1 functonal requrements ........................................................................................................ 17 3.1.1 Conference Recover ...................................................................................................... 18 3.1.2 Create New Conference ................................................................................................ 20 3.1.3 Conference Backup ....................................................................................................... 21 3.1.4 Chair Assignment .......................................................................................................... 22 3.1.5 Assignment of Reviewers .............................................................................................. 24 3.1.6 Author invitation ........................................................................................................... 26 3.1.7 Program Committee(PC) Formation ............................................................................. 28 3.1.8 Author Request .............................................................................................................. 29 3.1.9 Paper Submission .......................................................................................................... 31 3.1.10 Review Papers ............................................................................................................. 32 3.1.11 Sign-in ......................................................................................................................... 34 3.1.12 Approval or Disapproval of the Papers and Abstracts Submitted ............................... 35 3.1.13 Login and authenticaton ............................................................................................. 36 3.1.14 Conference Program Scheduling ................................................................................. 37 3.2 Software System Attributes .................................................................................................. 38 3.2.1 Performance Requirements ........................................................................................... 39 3.2.2 Reliability Requirements ............................................................................................... 39 3.2.3 Security Requirements .................................................................................................. 39 4. Planning ...................................................................................................................................... 40 4.1 Team Structure ..................................................................................................................... 40 4.2 Estimation............................................................................................................................. 41 4.3 Process Model ...................................................................................................................... 41 5. Conclusion .................................................................................................................................. 42 3

PREFACE
This document contains requirement specifications for CONFMAN(Conference Management and Hosting System). The document is prepared by using the IEEE Recommended Practice for Software Requirements Specification 1998.

This document has been prepared as an assignment of Computer Engineering Design course, CENG491. This course aims to make students practice analysis, requirement specification, design phases of a computer system, issues related to project design and presentation and engineering ethics. Projects will be inspired from real life hardware/software problems and students are expected to come up with a professional quality design solution by applying computer and software engineering methods.

Change History

Date

DocumentID

Version Comment

Writers

10.11.2012

CENGIZOVER_CON FMAN_SRS

1.0

Created

CENGIZOVER

16.01.2013

CENGIZOVER_CON FMAN_SRS

1.1

Section 3.1.13 and Section 3.1.14 has been added

CENGIZOVER

16.01.2013

CENGIZOVER_CON FMAN_SRS

1.1

Section 4.2 has been updated

CENGIZOVER

1. INTRODUCTION

This SRS document is about a new conference management and hosting system.

1.1 PROBLEM DEFINITION

In a conference, researchers present and discuss what they have done. Conferences provide exchange of information between researchers through scientific journals. Conferences are composed of presentations. The work may be bundled in written form as the conference proceedings. abstracts are peer reviewed by members of the program committee or referees chosen by them. Abstracts include the hypothesis, tools used in research, data collected and a summary of interpretation of data. They undergo peer review after which they are accepted or rejected by the conference chair or referees chosen by them. In some cases, submission of full paper may be required before final acceptance. The whole process up to here is called abstract management. Since abstract management was time consuming, web-based conference management softwares have evolved to automate the process. These function around typical conference workflows. Although it varies in details, there exist a submission phase, reviewing, decision making, building of conference programme and publishing of the programme and abstract papers. Submission phase involves the authors in preparing their abstracts and sending them to the conference organizers through an online form. The abstracts are either uploaded as documents or plain texts unless tables and figures are required. The software acknowledges the email of the author to inform him whether or not his abstract has been accepted after decision making. Reviewing phase is more complex than submission as the process is frequently blinded or anonymised. Reviewers have particular interests or specialisations which should be taken into account when assigning abstracts to them, and they may have conflicts of interest. Reviewers

should not be able to see other reviews before they have submitted their own. Abstract management software must provide this for independency. The programme committee will require extensive reporting and access to the abstracts and reviews. Software will usually support ranking of reviews and setting an acceptance threshold. Some software products provide further functionality for the conference organisers. This often includes an email facility to report reviewers' comments and committee decisions to authors, programme building tools and online publishing. Although the current conference management systems software try to maintain some desired features up to a level, there are still some limitations. The existing systems lack of some desired features mentioned below: A person may have more than one role in a conference. To accomplish his jobs, he has to login to the one roles account, perform the tasks of that role, log out, login to the account for the other role. In other words, there is no synchronization between the accounts owned by the same user. At the stage of evaluation, the user does not know which referee will evaluate his paper. Moreover the referee does not whose paper he is evaluating. The user has no information about the attitude of the referee, leading to blind review. After the conference, papers used in the event are published. However, the publisher has no idea about the format of the paper to be printed. There is no mechanism to make the process of publishing convenient. Before the conference, presentations to be presented are scheduled to avoid conflicts as much as possible. Nonetheless, scheduling process may be put into systematically, including some criteria such as importance.

In CONFMAN, a comprehensive conference management system that can host multiple conferences and their all web based activities will be developed.

1.2 PURPOSE

The purpose of this document is to describe the requirement specifications for CONFMAN. However, there may be non-described specifications in this document or existing ones can change later. This document is living and open to update later. The intended audience of this document is developers and customers of CONFMAN.
1.3 SCOPE

This software will be a conference management system that manages all administrative and organizational tasks of a conference. Expected features include: multi-role authentication paper submissions paper reviewer assignments periodical announcements reviewer evaluations final manuscript submissions, publisher relations conference rooms presentation schedule web page & announcement registrations

Additionally, electronic payment property is planned to be used in the software so that participants of the conference will be able to pay for signing into the system and accommodation. The decision about this feature will be made after negotiations with banks and tourist agencies. This project is expected to be GPL and later be used by METU organizations.
1.4 MARKET SURVEY

Currently on the market, we examined a few conference management system. OpenCONF: It is a web-based conference management software system used extensively in computer science and other disciplines. It has been adapted for journals, grants & books. The software is provided as a hosted service and for download by Zakon Group LLC. It requires keycode to sign up a reviewer/ program committee member account that is unnecessary. An author cannot reach his uploaded file without knowing the files id number. The most important thing about the system is that his user interface is poor. EasyCONF: The developers of this system claim that it can be adopted to specific features of any conference. However, its customizable nature is somewhat limited because it has a number of options allowing conference organizers to choose a model suitable for their conference. Some features of this software are management & monitoring of program committee, automatic paper submission, online discussion of papers, list of latest events, payment and multilanguage support. CMT: This is an ongoing project of Microsoft rather than consumer product. Developers work upon requests of users to generate the specific conference tool just for consumers conference. Its fundamental functionalities are setting & publishing schedules, defining submission & review criteria, adding reviewer to the system, managing reviewer bidding and paper assignment, facilitating review discussions, creating & managing sessions for presentations. Roles of agents are defined such as Chair, Author, Reviewer, Associate Chair etc. However, it is also clearly specified that it does not manage conference fees or logistics(accommodations, transportation, Visa issues) which seems to be one drawback of CMT.

General limitations of the conference management softwares at the market are explained in Section 1.1. CONFMAN will combine the features of the existing systems with the new features in a web based application on enriched user interface.

1.5 ABBREVIATIONS & ACRONYMS

Mandatory requirements are defined by using the word shall.

CONFMAN

Conference Management & Hosting System

SRS

Software Requirements Specification

METU

Middle East Technical University

CENG

Computer Engineering

IEEE

The Institute of Electric & Electronic Engineers

PC

Program Committee

GB

Gigabyte

HDD

Harddisk

RAM

Random Access Memory

SQL

Structured Query Language

XML

Extensible Markup Language

SVN

Subversion

1.6 REFERENCES

[1] IEEE Std 830-1998. IEEE Recommended Practice for Software Requirements Specification, http://www.math.uaa.alaska.edu/~afkjm/cs401/IEEE830.pdf [2] OpenCONF Home Page, http://www.openconf.com/ [3] EasyCONF Home Page, http://easyconf.sourceforge.net/ [4] Microsoft CMT, http://cmt.research.microsoft.com/cmt/

1.7 OVERVIEW

This document contains a detailed description about senior design project CONFMAN. In the introduction part, it mostly gives a general overview about the project including the definition of a real world problem that project intends to solve, the scope of this project, and the information about similar projects and how they differs from this project. Also in this part, the purpose of the SRS and the scope of the project are explained. Second part of the document is the overall description of the project. This part explains the product perspective of the application, the functions included in the application and the constraints, assumptions and dependencies of the desired application. In the third part of the document specific requirements are explained in details which are Interface requirements, functional requirements and non-functional requirements. 10

 In the fourth part of this document, data models and their descriptions are explained in detail showing the relationship between them. The behavioural model and its descriptions are mentioned in the fifth part. The sixth part is about us. It explains team structure, shows our schedule and explains our process model. The final part is concludes the document.
2. OVERALL DESCRIPTION 2.1 PRODUCT PERSPECT IVE

CONFMAN will be independent and self-contained project, that is, it is not included in a larger system.
2.1.1 USER INTERFACES 2.1.1.1 ADMIN PANEL

This panel appears when CS logins to the system correctly. There are the following components in this panel: 1 New Conference button: A form appears on the screen including following parameters: title of the conference starting & ending dates of the conference area of interests

1 Backup button: A confirmation box appears asking whether or not he would like to continue.

11

2 Recover button: A checklist of backup files or files to be chosen from the personal computer of CS via file browser appears with confirmation button. By a popup window, CS will be informed about the outcomes of the recovery operation later. 3 Delete Conference button: A confirmation box appears asking whether or not he would like to continue. If he confirms deletion, by a popup window, CS will be informed about the outcomes of the deletion operation later. 4 List of conferences: A group of radio buttons of conferences created by CS 5 Add Chair button: Invitation form appears, including following fields: First Name Last Name Email address Area of interest tag(s)

2.1.1.2 CONFERENCE PANEL

1 Assign button: A form appears including the following fields: First Name Last Name Email address Besides the fields, a list of roles appears in the form. 2 Add to PC button: The list of reviewers appear. 3 Papers button: List of all papers submitted associated with a review button

12

4 Review button: Paper text along with downvotes and upvotes displayed at the bottom of the text. See the reviews button 5 Reviews button: Displays all the reviews submitted by the reviewers one above another for the corresponding paper. 6 Paper Submission button: Displays a pop-up with a browse button on it along with Upload button. 7 Configure Conference panel: Displays a big panel featuring a group of checkboxes for chair to stipulate the privileges of the PC members, authors, reviewers.

2.1.1.3 CONFMAN HOME PAGE 1 2

Admin panel button: Displays the admin panel Notification area: Basically a button with a number on it which shows total number of notifications which the user gets. On click it shows a dropdown menu where user can see his notifications in detail.

My Conferences list: Basically a list which docked on the CONFMAN home page responsible for showing the names of the conferences which user has already signed in. All are hyper link to Conference Panel

Account Settings button: Displays an acocunt panel where user can change his personal data. Textboxes for name, surname, phone number, e-mail address along with a check box for specifying the gender. There is a apply setting button at the very button of the panel.

2.1.2 HARDWARE INTERFACES

CONFMAN is supposed to function properly on max. 5-year old servers. Because files will reside in the server, the capacity of HDD shall be at least 1 GB. However, with respect to demand, the capacity shall be able to be incremented. 13

2.1.3 SOFTWARE INTERFACES

All the information related to the conference shall be written in tables, that reside in a database. Therefore, database management system shall be needed to make control of tables convenient. Information entered by the user shall be fetched and processed by the scripting language behind the system. Moreover, the system is desired to have a user-friendly interface. A powerful framework can handle these operations without dealing with configuration settings.
2.1.4 MEMORY CONSTRAINTS

For proper functioning of CONFMAN, 1 GB RAM shall be sufficient. Depending on the size of the conference, the amount of memory should be increased.
2.2 USER CLASSES

2.2.1 STANDARD (UNASSIGNED) MEMBER

In CONFMAN System, every user is essentially a standard user except for system administrator and conference supervisor. During conferences, some of the current users will be designated as chair by conference supervisor, some other can be invited to conceive a specific role such as author, reviewer, PC member and participant or they can either make a request to have a specific role for a conference instance to be approved by chair depending on conference features this functionality or not (this will be set by conference supervisor)
2.2.2 SYSTEM ADMINISTRATOR

Only responsibility of The System Administrator is providing technical assistance to Conference Supervisor. He shall be able to be reachable by the any visitor of the CONFMAN through the contact address specified on the bottom of the web application.
2.2.3 CONFERENCE SUPERVISOR

The role of a conference supervisor is to administer, regulate and govern all scientific functionalities of all upcoming and ongoing conferences. He shall be able to introduce new conferences to the system and specify the settings of it. Moreover, he shall be able to back up 14

and recover database settings. Furthermore, he shall be able to assign chair(s) to the conferences. Just as system administrator he will be able to back up the databases. He is also authorized to ban the users reported by the conference chairs

Figure 1: Conference Supervisor

2.2.4 CONFERENCE CHAIR(S)

A number of chairs(one in case of single-track conference) will be designated by conference supervisor. There is no hierarchical relation between chairs, all are of same level. Moreover, lifetime of an user as a chair come to an end when conference is finished. That is to say, chair allocation for conferences will be made by Conference Supervisor for each individual conference instance.
2.2.5 PROGRAM COMMITTEE (PC) MEMBER

15

Program Committee consists of people assigned by chair of the conference. Committee member may be reviewer or any other expert in an area of interest. The aim of the committee is to help chair in approval of paper, which are presumed to be presented in the conference program by voting up or voting down for a final manuscript or abstract submitted by authors. Furthermore, conceiving a role by assignment process applies for an unassigned member. As for, already assigned members, this only a supplementary role along with his initially assigned role.

2.2.6 AUTHOR

Standard members can make a request for becoming an author for a conference instance. This can happen through two ways. First, they can be invited by any assigned member of the conference except participant or a standard member can apply for becoming an author if become an author by request feature is enabled. In the former case, if the invited person does not have account, an invitation mail will be sent to his email account. Otherwise, both an invitation e-mail and a notification to appear on his user panel on our system will be fired. Next, standard member will be able to see the invitation in his notifications list. Immediately after he accepts the invitation, a sign in form will pop up. His application after filling in the form will be on pending after chair rejects or accepts the request. In the second case, same routine apples after the standard user submits the application form. After a standard user conceives this role, he can submit papers to be submitted or rejected by chair later.

2.2.7 REVIEWER

Standard members can conceive this role almost same as conceiving the role of chair. Reviewers shall not be asked to pay for the conference, either. However, they are assigned by chair unlike 16

chairs with respect of to their area of interest tag(s). Just as chairs, they dont need to sign in a conference. They can go directly to conference panel from my conferences list on their CONFMAN home. Moreover, reviewer shall be able to browse and download all the submitted material assigned him to review. His basic role is to rank the submitted material according to predefined criteria. Ranking scale is also predefined associated with the criteria definition. To illustrate, number 1 represents Excellent while 5 means Poor.

2.2.8 PARTICIPANT

Regarding signing in, Standard members can become participant through filling in sign in form after clicking the name of the conference on announcements panel. Unlike authors, their application doesnt need to be approved by chair. However, only information they can see on conference panel will be schedule of the conference, payments and accommodation details

2.3 CONSTRAINTS

We will obey the laws in Turkey and ethics in the world related to copyright & patent issues. In case of payments, the agreements between us and banks will be valid. Moreover, the relationship between us and the tourism agency for accommodation will base on deals. Since CONFMAN will be developed under GPL license, we obey the implications mentioned in the context of the license.

3.SPECIFIC REQUIREMENTS 3.1 FUNCTIONAL REQUIREMENTS

17

Figure 1: Conference Management System

3.1.1 CONFERENCE RECOVER

18

Use Case ID

UC1

Actor(s)

Conference Supervisor(CS)

Description

System administrator recovers the conference settings and data(XML file, and archive file) previously backed up

Preconditions

CS shall be able to login to CONFMAN

Postconditions

Conference settings and data will be reverted to their backed up state

Precedence

Mandatory

Normal Flow of Event

1. The system administrator opens the web browser and types the address of the system. CS correctly enters the all necessary information in the login panel. 2. CS presses the Login button. 3. CS is redirected to Admin Panel directly 4. CS chooses the backed up settings and archive file currently on the server where the CONFMAN lies from the archive files and setting files lists respectively 5. Recover system checks the dates of the backed up conference. 6. If the dates are legit (conference didnt end yet), recover system checks the checksum of the archive and settings file and decide if any of them is corrupted or not 7. If files are not corrupted, conference recover system reloads the settings and conference data 8. CS sees a pop-up notifying conference recover is successful.

Alternative Flow(s)

Flow 1:

19

6. If dates are not legit, CS is required to set the dates of the conference to a legit date from the opening window. 7. If dates are legit, apply button is enabled on the newly-opened window 8. CS presses recover button 9. CS sees a pop-up notifying conference recover is successful. Flow 2: 6. If any corruption in files is detected, CS is notified that recovery failed because of the reason of the Checksum mismatch

3.1.2 CREATE NEW CONFERENCE

Use Case ID

UC2

Actor(s)

Conference Supervisor

Description

Conference supervisor creates the conference instances by using the organize a conference button in admin panel

Preconditions

CS shall be able to login to CONFMAN

Postconditions

A new conference will be introduced in the system

20

Precedence

Mandatory

Normal Flow of Event

1. Conference supervisor (CS) logins to the conference environment with username and password provided by the system administrator. 2. CS clicks the admin panel button to go to admin panel 3. CS presses the New Conference button. 4. A form consisting of settings of the conference appears. 5. CS sets the parameters of the conference by this form. 6. CS submits the form by pressing the submit button.

3.1.3 CONFERENCE BACKUP

Use Case ID

UC3

Actor(s)

Conference Supervisor(CS)

Description

CS backups all settings and content(submissions, other data collected in file format specified in the settings)

Preconditions

CS shall login to the conference environment.

Postconditions

CS shall have a backup file that includes all configurations of

21

existing conferences in the conference environment.

Precedence

Mandatory

Normal Flow of Event

1. CS logins to the conference environment with username and password provided by the system administrator. 2. CS clicks the admin panel button to go to admin panel 3. CS presses the Backup button. 4. Confirmation box pops up with options Yes or No 5. CS presses Yes button. 6. The backup file is downloaded to the CSs personal computer and also saved on the server where CONFMAN System is hosted

Alternative Flow(s)

5. CS presses No button. 6. Backup operation is cancelled.

3.1.4 CHAIR ASSIGNMENT

Use Case ID

UC4

Actor(s)

Conference Supervisor(CS)

Description

CS assigns Chair(s) to the conference(s) created by himself.

22

Preconditions

CS shall login to the conference environment.

Postconditions

Chair shall be visit the corresponding conference panel without signing in and manage conference to which he has been assigned to without any payment.

Precedence

Mandatory

Normal Flow of Event

1. CS logins to the conference environment with username and password provided by the system administrator. 2. CS clicks the admin panel button to go to admin panel 3. CS selects the conference he would like to assign chair(s). 4. CS presses the add chair button to assign chair(s) to the conference chosen 5. CS fills in the invitation form for the chair(s) and confirms. 6. Invitation email is sent to the email address(es) specified by CS, including activation link. 7. The person, who is thought to be the chair of corresponding conference, receives invitation email. 8. The person clicks on the activation link. 9. The person is already registered to the system. Hence, he logins to the system with his username and password. 10. He goes to the notification area on his account. 11. He accepts the invitation and becomes the chair of the corresponding conference. 12. Acceptance is notified to the CS.

23

Alternative Flow(s)

Flow 1 8. That person is not registered to the system. Hence, he fills in the registration form. 9. He signs up to the system as chair role by default.

Flow 2 8. He rejects the invitation. 9. Rejection is notified to the CS.

3.1.5 ASSIGNMENT OF REVIEWERS

Use Case ID

UC5

Actor(s)

Chair

Description

Chair of the existing conference shall assign the reviewer role in his conference to the person he would like to see as reviewer.

Preconditions

Chair shall login to the system.

Postconditions

Reviewer shall be able to visit the corresponding conference panel

24

without signing in and use relevant facilities without any payment.

Precedence

Mandatory

Normal Flow of Event

1. Chair logins to the conference with username and password. 2. Chair chooses the conference which he is the chair of from the my conferences list on his CONFMAN home 3. Chair sees the corresponding conference panel 4. Chair clicks the Assign button. 5. Chair selects the Reviewer role from the list. 6. Chair fills the invitation form for the role and confirms. 7. Invitation email is sent to the email address specified by Chair, including activation link. 8. The person, who is thought to be chosen reviewer in the conference, receives invitation email. 9. The person clicks on the activation link. 10. The person is already registered to the system. Hence, he logins to the system with his username and password. 11. He goes to the notification area on his account. 12. He accepts the invitation and becomes the reviewer of the corresponding conference. 13. Corresponding conference will be seen on my conferences panel of the invited user on his CONFMAN home. 14. Acceptance is notified to the Chair.

Alternative Flow(s)

Flow 1 1. That person is not registered to the system. Hence, he fills in

25

the registration form. 2. He signs up to the system as reviewer role by default. 3. That conference is added to conference list of invited reviewer. 4. Acceptance is notified to the Chair.

Flow 2 1. He rejects the invitation. 2. Rejection is notified to the CS.

3.1.6 AUTHOR INVITATION

Use Case ID

UC6

Actor(s)

Chair, Reviewer, Author,

Description

Relevant actor(s) of the existing conference shall invite people, they would like them to participate in the conference.

26

Preconditions

Relevant actor(s) shall be signed in corresponding conference.

Postconditions

For members of the system who are invited to a conference, a notification will be visible on notifications area of the user. For all author candidates, an invitation mail will be sent to his e-mail address(will be specified by inviter if not a member, or already available on the database of the system)

Precedence

Mandatory

Normal Flow of Event

1. Actor logins to the conference with username and password. 2. Actor clicks on the Invitation button. 3. Actor selects author role from the role list. 4. Actor fills the invitation form for the role and confirms. 5. Invitation email reaches to the email address specified by Actor, including activation link. 6. The person, who is thought to be Author in this conference, receives invitation email. 7. The person clicks on the activation link. 8. The person is already registered to the system. Hence, he logins to the system with his username and password. 9. He goes to the notification area on his account. 10. He accepts the invitation to see sign in screen of the relevant conference. 11. Corresponding conference will be seen on my conferences list of the invited user located on his CONFMAN home. 12. Acceptance is notified to the Chair.

27

Alternative Flow(s)

Flow 1 6. The person is not registered to the system. Hence, he required to fill in the registration form. 7. He signs up for the conference by filling in the form pops up upon acceptance of the invitation 8. Name of the conference which he has an invitation for will be already added to my conferences list on the newlyregistered users CONFMAN home. Flow 2 10. He rejects the invitation. 11. Rejection is notified to the CS. is

3.1.7 PROGRAM COMMITTEE(PC) FORMATION

Use Case ID

UC7

Actor(s)

Chair

Description

Chair shall be able to form a program committee, consisting of reviewer or expert of an area of interest whose area of interest is same as that of chair so that it helps him approve or disapprove the manuscripts or abstracts submitted by authors.

28

Preconditions

Chair shall login to the system.

Postconditions

PC members shall be able to evaluate papers.

Precedence

Mandatory

Normal Flow of Event

1. Chair logins to the conference with his account credentials 2. Chair clicks on the Add to PC button. 3. Chair selects the person from the list he would like to designate him as PC member 4. Chair presses the Add button. 5. Reviewer shall be added to PC.

Alternative Flow(s)

3. Chair clicks Invitation button to invite a person to be as PC member from outside the system. 4. He fills the invitation form and press Confirm button. 5. The person, who is thought to be a PC member, receives an invitation email with an activation link. 6. That person clicks the link and the sign up form appears. 7. He fills this form and confirm it. 8. He will be automatically designated as PC member to corresponding conference.

3.1.8 AUTHOR REQUEST

29

Use Case ID

UC8

Actor(s)

Standard User

Description

Standard users shall make a request to be an author for any conference that will be announced on the announcement panel on the home page.

Preconditions

Standard user shall login to system.

Postconditions

Standard user shall wait the response to the request. If the response is affirmative, then he shall be able to visit the relevant conference panel which will appear in his my conferences list on his CONFMAN home.

Precedence

Mandatory

Normal Flow of Event

1. Standard user shall login to the system. 2. He chooses conference he would like to sign in, from announcement panel on home page. 3. He presses the Request button. 4. He fills the sign in form -specifies the area of interest by choosing from the themes that will run through the conference in the case of multi-track conference- for that conference and confirms it. 5. Request appears in notification area of chair of the corresponding conference.

30

6. Chair accepts the request. 7. Acceptance is notified to the Standard User 8. Standard User shall be able to reach conference panel through my conferences tab in his CONFMAN home.

Alternative Flow(s)

6. Chair rejects the request. 7. Rejection is notified to the Standard User.

3.1.9 PAPER SUBMISSION

Use Case ID

UC9

Actor(s)

Author

Description

Author shall be able to upload their papers where he signed in for a conference.

Preconditions

Author shall log in to the conference from my conferences list on his CONFMAN home.

Postconditions

Reviewers whose are of the interest as same as that of the author in corresponding conference, shall be able to see and review authors paper.

31

Precedence

Mandatory

Normal Flow of Event

1. Author shall login to the system. 2. He chooses conference, he would like to log in, from announcement panel on home page. 3. He opens submission form by clicking Submit Paper button. 4. He enters necessary information for paper (e.g. title,authors) and upload file from upload form and submit it.

3.1.10 REVIEW PAPERS

Use Case ID

UC10

Actor(s)

Reviewer

Description

Reviewer shall be able to review papers which assigned to them by Chair or PC

Preconditions

Reviewer shall log in to the conference from my conferences in his CONFMAN home.

Postconditions

Chair(s) or PC(s) shall be able to see the previous reviews for the corresponding paper submitted with a matching area of the interest 32

tag with the that of chair.

Precedence

Mandatory

Normal Flow of Event

1. Reviewer shall login to the system. 2. He chooses conference, he would like to log in, from announcement panel on home page. 3. He chooses and clicks paper, that assigned to him, from his conference panel. 4. He fills the evaluation form for the paper and write comments about the paper on corresponding places in the form. 5. He presses Submit button. 6. A confirmation box appears asking Yes or No question. 7. Pressing Yes, submission process is over.

Alternative Flow(s)

Flow 1 5. He presses Save button. 6. He closes the review form screen. Flow 2 7. Pressing No, submission is cancelled. He returns review form page again.

33

3.1.11 SIGN-IN

Use Case ID

UC11

Actor(s)

Standard User

Description

Standard users shall be able to sign in a conference to take part in it as an author

Preconditions

Become an author by request is enabled in the settings of the conference or a standard user is invited by someone who has signed in or already assigned member.

Postconditions

Application of the standard user for becoming an author is waiting for approval of chair

Precedence

Mandatory

Normal Flow of Event

1. The standard user sees the invitation come from an assigned member of a conference. 2. The standard user accepts the invitation 3. A sign in form pops up 4. Standard user fills in the form and submits it

Alternative Flow(s)

Flow 1

34

1. The standard user sees the announcement of the conference in become an author by request enabled conference 2. After clicking the name of the conference the standard user wishes to participate in, he sees the sign in form 3. Standard user fills in the form and submits it

3.1.12 APPROVAL OR DISAPPROVAL OF THE PAPERS AND ABSTRACTS SUBMITTED

Use Case ID

UC12

Actor(s)

Chair(s)

Description

Chairs will accept or reject the papers or abstracts submitted by authors

Preconditions

Chair(s) and Authors shall log in the system and submitted document is of the same area of interest as that of chair

Postconditions

When submitted work of an author rejected, author will lose his role of author and become a standard member for the conference he submitted his paper to. Hence, he shall not be able to see the name

35

of the corresponding conference in the my conferences list.

Precedence

Mandatory

Normal Flow of Event

1. Chair is notified as soon as author makes his submission. 2. PC members votes the submission and reviewers reviews it 3. Chair accepts the submission 4. A notification regarding the decision of the chair is sent to author.

Alternative Flow(s)

Flow 1 3. Chair rejects the submission. 4. A notification regarding the decision of the chair is sent to author. 5. Author becomes a standard member for the corresponding conference(he cannot go to the conference panel through my conferences list

3.1.13 LOGIN AND AUTHENTICATION

Use Case ID

UC13

Actor(s)

System-out user

Description

A user who has role(s) at a conference will be able to authenticate only on the conference(s) at which he has been assigned to at least one role.

36

Preconditions

System-out user shall be able to enter his username and password to the text fields on the login panel and submit the data.

Postconditions

System-out user shall become a system-in user and be redirected to a specific page about conference(s) at which he has role(s) if he gives true username and password combination.

Precedence

Mandatory

Normal Flow of Event

1. System-out user goes to the login panel. 2. He enters his username and password information. 3. The system checks whether or not there is a user record matching with the given data. 4. System-out user becomes system-in with successful login. 5. The system redirects the user to different page on which he can manage conference(s) at which he has role(s)

Alternative Flow(s)

5. The system redirects the user to the login panel with the notification that he could not login to the system successfully.

3.1.14 CONFERENCE PROGRAM SCHEDULING

Use Case ID

UC14

Actor(s)

Chair

37

Description

The chair of the conference should be able to schedule speeches, presentations, panels etc. without causing any conflict by using genetic algorithms(See CENGIZOVER_CONFMAN SDD v1.1)

Preconditions

The chair should be logged into the system before.

Postconditions

The chair shall be able to schedule the conferences to which he has been assigned as chair.

Precedence

Mandatory

Normal Flow of Event

1. The chair goes to the Schedule panel. 2. He enters the parameters(number of participants, weighted importance of the conference element etc.) of the conference elements(speech, presentation) . 3. He submits the data. 4. A time table filled with the scheduled conference elements appears indicating that scheduling has been done successfully.

Alternative Flow(s)

4. The system notifies the user about the situation that an error occurred during scheduling operation.

3.2 SOFTWARE SYSTEM ATTRIBUTES

38

3.2.1 PERFORMANCE REQUIREMENTS

CONFMAN will be a web application that may have hundreds of users in the timeline of the conference. The tasks performed by the members shall be performed in acceptable time(max. 5 seconds). Tables shall have multiple access property so that users can update / insert their entities to the tables at a time.

3.2.2 RELIABILITY REQUIREMENTS

Any system-in user shall not be able to have privileges that he does not have actually. Deliberately or accidentally, any system-in user shall not be able to change the entity of another user in the table although he does not have a right to do that

3.2.3 SECURITY REQUIREMENTS

All, user provided data, which will be part of the SQL query must be preprocessed to put escape character (backslash) in front of a single or double quote or backslash. Otherwise misinterpretation of the SQL query is possible because these characters are part of the SQL syntax. System-out user shall not be able to hijack the account of the person who can login to the system.

39

4. PLANNING 4.1 TEAM STRUCTURE

CONFMAN will be developed by five different teams independently. Our groups name is CENGIZOVER. The team consists of four senior students of METU CENG. Communication between members is extremely important for the rest of the project. We, as CENGIZOVER, have meetings twice a week. In one of them our teaching assistant Mine YOLDA will guide us the way we progress. Furthermore we have a mail group on Google Groups, cengizover@googlegroups, that we use it unless we are in physical touch. We have been using SVN and Trac accounts to see and modify on what our partners have implemented for CONFMAN. In our group, a task will not be performed by one person. A task will be shared among two members, but one of which will be dominant on that topic.

Name

Contact Info

Ahmet Anl Pala

aanilpala@gmail.com

Birand Koray Eren

birandkoray@gmail.com

Mustafa Yavuz

89.yavuz@gmail.com

Burak n

cunburak@gmail.com

40

4.2 ESTIMATION

We will stick to deadlines determined by CENG491 staff and our mentor. The table below shows the steps of progress on CONFMAN for the first semester.
STEP DEADLINE 24th October 2012 11th November 2012 3rd December 2012 18th January 2013 22nd January 2013

Proposal Report
SRS SDD Report Updates Prototype Demo

4.3 PROCESS MODEL

The requirements of CONFMAN are not static and we will talk to faculty members of METU CENG. Therefore, CONFMAN will be developed on agile software development. Agile software development is a group of software development methods based on iterative and incremental development. The steps of this development method are shown right.

41

5. CONCLUSION

In this document, the functional and other requirements of the system are described. Furthermore, the needs of the user are stated through the document. However, all requirements are not defined and some of the requirements needs to be clarified in this document. To sum up, this document is the primary document which upon all of the subsequent design, implementation, test/validation processes will be based.

42