SRS -EMS- V2

34
1 Copy right © 2011 of MoE and eDruk Consultancy Software Requirements Specification for Education Portal (Event Management System) SRS-EMS-V2 Version 2 29/ 03 /2011

Transcript of SRS -EMS- V2

Page 1: SRS -EMS- V2

1

Copy right © 2011 of MoE and eDruk Consultancy

Software Requirements

Specification

for

Education Portal (Event

Management System)

SRS-EMS-V2

Version 2

29/ 03 /2011

Page 2: SRS -EMS- V2

2

Copy right © 2011 of MoE and eDruk Consultancy

1 Revision History

Sl.No Version Name Date Remarks

1 1 Babul Subba 24/ 03 / 2011 -

1 2 Babul Subba 29 / 03 /2011 As the project manager

recommended us to change the

format of the document

Page 3: SRS -EMS- V2

3

Copy right © 2011 of MoE and eDruk Consultancy

2 Sign-Off

Project Name: Event Management System

Project Manager: Karma Dorji

Sponsor(s): Ministry of Education, DIT, MoIC

Date:

The Approver’s signature below indicates that the contents of the attached document have been reviewed

and accepted subject to the following categories.

Deliverable Version Description

SRS 2 Software Requirement Specification Document for event

management system.

Categories:

A Agree with contents

B Agree, subject to incorporation of comments

C Disagree, comments included

Approver

Name/Title

Signature Sign Date Subject to

category

Comments

Sponsor

Project Manager

Page 4: SRS -EMS- V2

4

Copy right © 2011 of MoE and eDruk Consultancy

3 Owners and List of Contacts

Name Email Phone Role

Karma Dorji [email protected] 332277 Project Manager / System Analyst /

Lead Developer / Code Reviewer

Tenzin Zangmo [email protected] 332277 Asst. Project Manager / Developer

Lam Penjor [email protected] 332277 Developer / Designer

Babul Subba [email protected] 332277 Developer / Designer

Tenzin Norgay [email protected] 332277 Developer / Designer

Kuenley [email protected] 332277 Project Leader / Developer /

Designer

Sonam Dhendup [email protected] 332277 Graphic Designer

4 Definitions, Acronyms, and Abbreviations

SRS-software requirement specification

TOR- Terms of reference

UC EMS- Use Case for Event Management System

DEO- Dzongkhag Education Officer

HRD- Human Resource Department

JAVA/SUSE/LINUX- these are the operating system on which this vacancy database system will

run

EMS-DIC- event management system design and implementation constraints

EMS-UD- even management system user documentation

EMS- AD- event management system assumption and dependency

EMS-SF-DP-event management system -system feature-description and priority

EMS-SF-SR- event management system-system features-stimulus and response.

HTTP-hyper text transfer protocol

Page 5: SRS -EMS- V2

5

Copy right © 2011 of MoE and eDruk Consultancy

5 References

The following documents were referred to, while specifying the SRS document:

RFP

TOR

D2-Existing Scenario Report, Survey on Education Service Portal, 12-02-2010, by iTechnologies

D3-Future Plan Study Report, Survey on Education Service Portal, 12-02-2010, by iTechnologies

D4- Gap Analysis Report, Survey on Education Service Portal, 12-02-2010, by iTechnologies

D5- Portal / Future Requirements, Survey on Education Service Portal, 12-02-2010, by

iTechnologies

D6 – Hardware and Infrastructure Requirements, Survey on Education Service Portal, 12-02-

2010, by iTechnologies

D7- Portal and ETL framework, Survey on Education Service Portal, 12-02-2010, by

iTechnologies

Requirement Gathering Report, by eDruk

Requirement Validation Report, by eDruk

Study Report, by eDruk

Meetings with stakeholders, and clients by eDruk.

MoE website.

Page 6: SRS -EMS- V2

6

Copy right © 2011 of MoE and eDruk Consultancy

6 Document Conventions

This document is written using the following document conventions with its own special meaning:

Font Meaning

Times New Roman: size 11 Normal Text

Times New Roman (Bold) Specifies that the point is being stressed and

should be given more importance

Fonts color : black The color of the text

Cambria : Size 14 Heading

Cambria : Size 13 Sub heading

Line Spacing Size : 1.5

Footer with Page no. and Copy right Times New Roman: Size 11

7 Abstract

Even management system is a system that collects agenda online, prioritize agenda and record

proceedings of events. This system will provide or have followings:

This system will allow all concerned to submit agenda online and view agenda from other

agencies

Bulk mailing facilities for mailing to participants will be there in the system

The recordings of all the events, meetings, workshops and conferences will be available in the

portal in different formats like MoMs, video recordings, etc

Each document and recordings will be attached to particular event, meeting etc.

Page 7: SRS -EMS- V2

7

Copy right © 2011 of MoE and eDruk Consultancy

8 Table of Contents

1 Revision History ................................................................................................................................... 2

2 Sign-Off ................................................................................................................................................ 3

3 Owners and List of Contacts ................................................................................................................. 4

4 Definitions, Acronyms, and Abbreviations ........................................................................................... 4

5 References ............................................................................................................................................. 5

6 Document Conventions ......................................................................................................................... 6

7 Abstract ................................................................................................................................................. 6

9 Introduction ........................................................................................................................................... 9

9.1 Purpose ................................................................................................................................................ 9

9.2 Intended Audience and Reading Suggestions ................................................................................... 9

9.3 Project Scope .................................................................................................................................. 10

9.4 Portal goals and Objectives ............................................................................................................. 10

9.5 Document overview ........................................................................................................................ 11

10 Overall Description ......................................................................................................................... 12

10.1 Product Perspective ....................................................................................................................... 12

10.2 Product Features ............................................................................................................................ 12

10.3 User Classes and Characteristics ................................................................................................... 14

10.4 Operating Environment ................................................................................................................ 14

10.5 Design and Implementation Constraints ....................................................................................... 16

10.6 User Documentation ..................................................................................................................... 17

10.7 Assumptions and Dependencies ...................................................................................................... 17

11 System Feature ..................................................................................................................................... 18

11.1 System Feature 1 (submit agenda) ................................................................................................. 18

11.1.3.1 Detail Use Case: .................................................................................................................... 19

11.2 System Feature 2 (prioritization) .................................................................................................. 21

11.3 System Feature 3 (mailing to participants) ..................................................................................... 23

11.4 System Feature (categorization) ...................................................................................................... 25

11.5 System Feature 5(publish)............................................................................................................... 27

12 External Interface Requirements ..................................................................................................... 29

12.1 User Interfaces .............................................................................................................................. 29

12.2 Software Interfaces ......................................................................................................................... 31

12.3 Communications Interfaces............................................................................................................. 31

13 Other Nonfunctional Requirements ................................................................................................ 32

13.1 Performance Requirements ............................................................................................................. 32

13.2 Safety Requirements ....................................................................................................................... 32

Page 8: SRS -EMS- V2

8

Copy right © 2011 of MoE and eDruk Consultancy

13.3 Security Requirements .................................................................................................................... 32

13.4 Data requirement ......................................................................................................................... 33

13.4.1 Data requirement for event management system is shown in the following table .............. 33

14 Other Requirements ........................................................................................................................ 34

14.1 Activity diagram for event management system ......................................................................... 34

Page 9: SRS -EMS- V2

9

Copy right © 2011 of MoE and eDruk Consultancy

9 Introduction

9.1 Purpose

This is the first draft of SRS, revision 1.0, for event management system.

The purpose of this document is to define the SRS for Education Portal on the topic event management

system, to be developed for the Ministry of Education, as per the RPF documents being provided, and as

per our proposal.

The document covers

Interfaces

Functional Capabilities

Performance Levels

Data Structures/Elements

Safety

Security/Privacy

Quality

Constraints and Limitations

9.2 Intended Audience and Reading Suggestions

Sl No Audience Description

1. Project Manager Project Manager can use this document to update the project

plan. The document also gives the project manager the overall

software, broken down to smaller parts, so that the whole

picture of the whole application ca be derived from the

modules within the application.

2. Developers /

Designers

Developers and designers can use the SRS to design and

develop the software. It has specified the business process,

Page 10: SRS -EMS- V2

10

Copy right © 2011 of MoE and eDruk Consultancy

data requirements, validated process flow, data flow diagram,

use case diagrams, and interfaces.

3. Testers Testers can use the SRS to design their test case from the use

cases in the SRS, they can also come out with the required

inputs to get particular outputs from the application.

4. Documentation

Writers

Documentation writers can use the SRS to write the

Administrator and User Documents. All the required business

process and data flow are clearly mentioned from which the

documentations can be done.

5. Users Users can also get an overall picture of the whole application,

as users would be confined to particular module of the

system, when used, and would be difficult to get the whole

picture. The SRS document can help users understand the

whole application.

9.3 Project Scope

Since this system is a web-base system and design to run all over Bhutan, people can view the events

that have held earlier if there is internet connection available.

9.4 Portal goals and Objectives

Main Objectives of the event management system are:

Improve systemic efficiency in service delivery mechanism

Widen access to high quality, relevant and diverse resources

Bulk mailing facilities

Page 11: SRS -EMS- V2

11

Copy right © 2011 of MoE and eDruk Consultancy

9.5 Document overview

The first section of the document gave a brief description about the education portal on the topic event

management system and what it should establish. And also we will describe the requirements,

assumptions, dependencies, constraints and other such concepts about the software.

Page 12: SRS -EMS- V2

12

Copy right © 2011 of MoE and eDruk Consultancy

10 Overall Description

10.1 Product Perspective

Event management system is a new web based application that is being developed completely as a new

system for Ministry of Education as the system will be accepting agenda online from different agencies

and also bulk mailing facilities is there in this system.

10.2 Product Features

Event management system is a web based application, whereby the application is accessed via web

browser, without the need to have any client software installed on the users to access the application.

Some of the features of the products are highlighted as use case diagrams as follows:

Page 13: SRS -EMS- V2

13

Copy right © 2011 of MoE and eDruk Consultancy

submit agenda

participants

approval person

priritization

portal administrator

mailing to

participants

catagorization

publish

UC EMS-1

UC EMS-2

UC EMS-3

UC EMS-4

UC EMS-5

USECASE FOR EVENT MANAGEMENT

SYSTEM

«uses»

«uses»

«uses»

«uses»

«uses»

USE CASE

Figure 1: use case diagram for event management system

Page 14: SRS -EMS- V2

14

Copy right © 2011 of MoE and eDruk Consultancy

10.3 User Classes and Characteristics

Name Description

Educational institutions Will be organizing events like sport day, annual concert day, quiz

etc.

Departments/divisions/agencies Here they will be sending mails to all the concerns with regard to

the event that is to be held. Event may be of a kind meetings,

workshops, conferences etc.

Portal administrator He will view the events that were held and also agenda that was

sent online and then he will categorize the events. He then prioritize

the agenda and publish on the portal.

10.4 Operating Environment

The Specification is very generic.

The servers are for the core infrastructure, where it will be hosted centrally. If certain applications are to

be run in remote schools, the hardware requirement to be computed on the basis of services that would be

run in that location.

Item

Sl.

Item Qty. Configuration Remarks

1. Database Server 1 2 x Quad core Itanium proc / 16

GB memory / 4 x 146 GB SAS

internal disk / RAID controller /

redundant power supply / 2 x

1Gbps network ethernet port /

cluster

(Minimum Requirement)

Database servers

(Running mysql

server as Database

server, on Linux

Platform)

Will host all the

database for

Education Portal

Page 15: SRS -EMS- V2

15

Copy right © 2011 of MoE and eDruk Consultancy

Item

Sl.

Item Qty. Configuration Remarks

2. Web server 1 2 x Quad core Itanium proc / 32

GB memory / 2 x 146 GB internal

disk / redundant power supply / 2

x 1Gbps network ethernet port.

This will run the Web

Server (Apache, on

Linux Platform)

Will host Content

Management System,

Java Framework

3. Web Conference

Server

1 2 x Quad core Itanium proc / 32

GB memory / 4 x 146 GB internal

disk / redundant power supply / 2

x 1Gbps network ethernet port.

Web Conference

Server

4. Application

Server

2 2 x Quad core Itanium proc / 64

GB memory / 6 x 146 GB SAS

internal disk / RAID controller /

redundant power supply / 2 x

1Gbps network ethernet port /

cluster

Will Run the

following

Applications (Library

System, School

Administration,

ESWS, Procurement

Requisition, Online

E-Learning(moodle),

and all applications,

with Reporting

Application, Data

Integration

Application BUS)

5. Backup server 1 2 x Quad core Itanium proc / 64

GB memory / 8 x 146 GB SAS

internal disk / RAID controller /

redundant power supply / 2 x

Backup Server

Page 16: SRS -EMS- V2

16

Copy right © 2011 of MoE and eDruk Consultancy

Item

Sl.

Item Qty. Configuration Remarks

1Gbps network ethernet port /

cluster

Operating System (OS)

6. Suse Linux 1

7. Ubuntu 1

Network Infrastructure

8. Switch 1 24 port / Gigabit ethernet

Site Related

9. Rack 1 as req.

10. UPS 1 2 x 10 KVA dual redundant

11. Internet

connectivity

1 At least 1 mbps at the

core location

10.5 Design and Implementation Constraints

System ID Description

EMS-DIC-1 The constraint here is the prioritization.

Page 17: SRS -EMS- V2

17

Copy right © 2011 of MoE and eDruk Consultancy

10.6 User Documentation

System ID Description

EMS-UD-1 The system is under development stage and requires a complete implemented

prototype to explain the user documentation. Once the prototype is designed

and implemented administrative manuals, user manuals and training manuals

can be provided

.

10.7 Assumptions and Dependencies

System ID Description

EMS-AD-1 Assumption:

Concern approval person sending mails to the all the participants .

EMS-AD-2 Dependencies:

JAVA,SUSE, Appache, PHP, for runtime environment

Page 18: SRS -EMS- V2

18

Copy right © 2011 of MoE and eDruk Consultancy

11 System Feature

11.1 System Feature 1 (submit agenda)

11.1.1 Description and Priority

System ID Name Description

EMS-SF1-DP-1

Description Here whenever there is an event to be held,

first thing is to fix the kind of event to be

held, date and time and the location where

the event is to be organized. And also find

out who is going to be the guest of that

event. Then the participant will submit the

agenda online so that everyone can view it.

Priority This feature has 9th level priority.

11.1.2 Stimulus/Response Sequences

System ID Description

EMS-SF1(SR-1.1) Stimulus: concern users will click on open button to open the

event/agenda form.

Response: system (event management system) will display the event

form that is to be filled up.

EMS-SF1(SR-1.2) Stimulus: the concern users will view the event form and fill up and

click submit button.

Response: system will then save the data and make it viewable by the

concern authority who will be doing categorization, prioritization etc. .

Page 19: SRS -EMS- V2

19

Copy right © 2011 of MoE and eDruk Consultancy

11.1.3 Functional Requirements

11.1.3.1 Detail Use Case:

Name Description

Use case name Submit agenda

Identification UC EMS-1

Pre-condition Decide what kind of event to organize.

Fix the date and time and the location.

Decide who will be the guest for the event.

Post-condition View the agenda by all the agencies

Basic course of action Decide the kind of agenda

Fix the date, time and the location

Decide the chief guest for the event

Write the agenda for the event.

Submit the agenda online

trigger Open event/agenda form page , fill up and click submit button.

Exceptional path

Alternative path

Page 20: SRS -EMS- V2

20

Copy right © 2011 of MoE and eDruk Consultancy

11.1.3.2 Use case diagram: It is shown below

submit agenda

participants

approval person

priritization

portal administrator

mailing to

participants

catagorization

publish

UC EMS-1

UC EMS-2

UC EMS-3

UC EMS-4

UC EMS-5

USECASE FOR EVENT MANAGEMENT

SYSTEM

«uses»

«uses»

«uses»

«uses»

«uses»

USE CASE

Figure 2: Use case diagram for vacancy database system

Page 21: SRS -EMS- V2

21

Copy right © 2011 of MoE and eDruk Consultancy

11.2 System Feature 2 (prioritization)

11.2.1 Description and Priority

System ID Name Description

EMS-SF1-DP-2

Description As there will be lot of agenda online. The

approval person will see and decide which

event is most important to attend and which

one is not so important to attend. Thus

giving the event as highest priority, medium

and low priority.

Priority This feature has 7th level priority. This is

important as the other concern persons have

to be aware of what kind of event is to be

held and where and at what time etc.

11.2.2 Stimulus/Response Sequences

System ID Description

EMS-SF2 (SR2.1) Stimulus: to see the agenda the user will have to login

Response: the system will display the login form with the option user

name and password.

EMS-SF2 (SR2.2) Stimulus: the user will enter name and password and clicks ok button.

Response: the system will display the incoming agenda/event form only

when the user name and the password is correct or else will display

wrong user name or password and say try again.

EMS-SF2(SR2.3) Stimulus: seeing the events and agenda the user will do prioritization

and click save button.

Response: system will save the data so the it can be viewed by

everyone.

Page 22: SRS -EMS- V2

22

Copy right © 2011 of MoE and eDruk Consultancy

11.2.3 Functional Requirements

10.2.3.1 Detail use case:

Name Description

Use case name prioritization

Identification UC EMS-2

Pre-condition view the agenda online

Prioritize the event as highest, medium and low priority

Post-condition attend the event which has the highest priority first

Basic course of action View all the agenda online.

Prioritize the event as highest, medium and low priority.

trigger User will login and do prioritization and system will save the data

Exceptional path

Alternative path

Page 23: SRS -EMS- V2

23

Copy right © 2011 of MoE and eDruk Consultancy

11.3 System Feature 3 (mailing to participants)

11.3.1 Description and Priority

System ID Name Description

EMS-SF1-DP-3

Description Here the participants will collect the contact

details or email address of the participants.

Then they write the mail to the respective

participants about the kind of event to be

held and should attend it.

Priority This feature has 8th level priority. This is

because the meeting may be of very

importance etc.

.

11.3.2 Stimulus/Response Sequences

System ID Description

EMS-SF3 (SR3.1) Stimulus: user will have all the contact and email id of all the concern

person( who will be attending the meetings, workshops etc) will enters

in the mail list and clicks send button

Response: system will send the mails to all the concern agencies (bulk

mailing facilities available) and display mail send.

EMS-SF(SR3.2) Stimulus: when the user clicks cancel button.

Response: the system will display message not send.

Page 24: SRS -EMS- V2

24

Copy right © 2011 of MoE and eDruk Consultancy

11.3.3 Functional Requirements

11.3.3.1 Detail use case:

Name Description

Use case name Mailing to participants

Identification UC EMS-3

Pre-condition Collect contact details or email address of the respective participants.

Send mail

Post-condition View the mail and decide whether to attend or not

Basic course of action Collect contact details or email address.

Write mail to the participants.

Send the mail.

trigger Write email address of all the concern person and click send the message. the

system will send the mail to all(those whose email id in mentioned)

Exceptional path

Alternative path

Page 25: SRS -EMS- V2

25

Copy right © 2011 of MoE and eDruk Consultancy

11.4 System Feature (categorization)

11.4.1 Description and Priority

System ID Name Description

EMS-SF1-DP-4

Description There will be different kind of events to be

held. The approval person will decide and

categorize the events like workshop,

meetings, conference etc

Priority This feature has 6th level priorities. This is

because it is not so important as the concern

person will attend all the events if they have

no works.

.

11.4.2 Stimulus/Response Sequences

System ID Description

EMS-SF4 (SR2.1) Stimulus: seeing the incoming agenda the concern user will do

categorization of the events and click save button .

Response: the system will save the data that have been edited by the

concern user.

Page 26: SRS -EMS- V2

26

Copy right © 2011 of MoE and eDruk Consultancy

11.4.3 Functional Requirements

11.4.3.1 Detail use case:

Name Description

Use case name Categorization

Identification UC EMS-4

Post-condition Make ready the categorized event to publish

Basic course of action View all the events

Decide under which category the event will fall

Categorize the event.

trigger User will see and categorize and the system will say the data to be publish

Exceptional path

Alternative path

Page 27: SRS -EMS- V2

27

Copy right © 2011 of MoE and eDruk Consultancy

11.5 System Feature 5(publish)

11.5.1 Description and Priority

System ID Name Description

EMS-SF5-DP-5

Description The portal administrator will collect all the

events and will upload the events in

different formats like MoMs, video

recording, documents etc and publish the

particular event.

Priority This feature has 9th level priority. This is

because the meeting may be of very

importance etc.

.

11.5.2 Stimulus/Response Sequences

System ID Description

EMS-SF5 (SR2.1) Stimulus: user will click the publish button.

Response: system will display the agenda/event online in the portal so

that everybody can view it.

Page 28: SRS -EMS- V2

28

Copy right © 2011 of MoE and eDruk Consultancy

11.5.3 Functional Requirements

11.5.3.1 Detail use case:

Name Description

Use case name Publish online

Identification UC EMS-5

Pre-condition gather all the events that is held.

Upload the events in different formats.

Attach the documents or recording with the particular event

Post-condition The events that have been uploaded will be seen by all agencies

Basic course of action Collect or gather all the events

Upload the events

Attach all the documents and the recording with the event

Publish the event online

trigger User clicks the publish button and the system creates interface in the portal and

publish it online.

Exceptional path

Alternative path

Page 29: SRS -EMS- V2

29

Copy right © 2011 of MoE and eDruk Consultancy

12 External Interface Requirements

12.1 User Interfaces

Following are the user interface for the event management system:

Figure 3: Form to write the kind of event to be held

Figure 4: To view the incoming event

Page 30: SRS -EMS- V2

30

Copy right © 2011 of MoE and eDruk Consultancy

Figure 5: To upload the event outcome

Figure 6: To view the event that is been publish online

Page 31: SRS -EMS- V2

31

Copy right © 2011 of MoE and eDruk Consultancy

12.2 Software Interfaces

It should be possible for e-learning tools to be implemented in both windows and LINUX operating

system environment.

12.3 Communications Interfaces

Since our system is a web-based system almost all the clients can use the system if the web browser is

included.

HTTP is used as a standard communication tools and also used for transmission of data. Also, the user’s

computer must be able to connect to the internet to access this system.

Page 32: SRS -EMS- V2

32

Copy right © 2011 of MoE and eDruk Consultancy

13 Other Nonfunctional Requirements

13.1 Performance Requirements

The important aspects of vacancy database system is time constrain. Event management system is

real time and hence should be performed in minimum requirements i.e. within 30sec.

13.2 Safety Requirements

The data handled in the event management system is very vital. The server should always be confirmed to

run properly and the data are saved to the database at consecutive intervals. Updating the database is a

significant feature and the power supply should be always

taken care of.

13.3 Security Requirements

Since the portal consists of information gateway and application gateway. The security for the proposed

ePortal shall comply with the following:

Have provide web server configuration guidelines which is acceptable to the client

Run web server processes with appropriate privilege accounts

Configure access rights so that server software cannot modify files being served to users.

Page 33: SRS -EMS- V2

33

Copy right © 2011 of MoE and eDruk Consultancy

13.4 Data requirement

13.4.1 Data requirement for event management system is shown in the following table

Variable Data Data length

Name of

schools/departments/divisions/agencies

string 60

Location string 20

Date Data 10

time integer 6

name of the event String 15

Name String 20

Contact no. integer 8

Designation String 25

Page 34: SRS -EMS- V2

34

Copy right © 2011 of MoE and eDruk Consultancy

14 Other Requirements

14.1 Activity diagram for event management system

submite the agenda

mail the agenda

Categorize the events

meetings

workshops

conferences

publish in different formates

Activity Diagram for Event

Management system

publish

Prioritize

Figure 7: activity diagram for event management system.