SRS -EMS- V2
-
Upload
abhi-sheikh -
Category
Documents
-
view
469 -
download
1
Transcript of SRS -EMS- V2
![Page 1: SRS -EMS- V2](https://reader034.fdocuments.in/reader034/viewer/2022051210/54f648284a7959d76e8b5636/html5/thumbnails/1.jpg)
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](https://reader034.fdocuments.in/reader034/viewer/2022051210/54f648284a7959d76e8b5636/html5/thumbnails/2.jpg)
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](https://reader034.fdocuments.in/reader034/viewer/2022051210/54f648284a7959d76e8b5636/html5/thumbnails/3.jpg)
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](https://reader034.fdocuments.in/reader034/viewer/2022051210/54f648284a7959d76e8b5636/html5/thumbnails/4.jpg)
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](https://reader034.fdocuments.in/reader034/viewer/2022051210/54f648284a7959d76e8b5636/html5/thumbnails/5.jpg)
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](https://reader034.fdocuments.in/reader034/viewer/2022051210/54f648284a7959d76e8b5636/html5/thumbnails/6.jpg)
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](https://reader034.fdocuments.in/reader034/viewer/2022051210/54f648284a7959d76e8b5636/html5/thumbnails/7.jpg)
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](https://reader034.fdocuments.in/reader034/viewer/2022051210/54f648284a7959d76e8b5636/html5/thumbnails/8.jpg)
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](https://reader034.fdocuments.in/reader034/viewer/2022051210/54f648284a7959d76e8b5636/html5/thumbnails/9.jpg)
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](https://reader034.fdocuments.in/reader034/viewer/2022051210/54f648284a7959d76e8b5636/html5/thumbnails/10.jpg)
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](https://reader034.fdocuments.in/reader034/viewer/2022051210/54f648284a7959d76e8b5636/html5/thumbnails/11.jpg)
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](https://reader034.fdocuments.in/reader034/viewer/2022051210/54f648284a7959d76e8b5636/html5/thumbnails/12.jpg)
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](https://reader034.fdocuments.in/reader034/viewer/2022051210/54f648284a7959d76e8b5636/html5/thumbnails/13.jpg)
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](https://reader034.fdocuments.in/reader034/viewer/2022051210/54f648284a7959d76e8b5636/html5/thumbnails/14.jpg)
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](https://reader034.fdocuments.in/reader034/viewer/2022051210/54f648284a7959d76e8b5636/html5/thumbnails/15.jpg)
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](https://reader034.fdocuments.in/reader034/viewer/2022051210/54f648284a7959d76e8b5636/html5/thumbnails/16.jpg)
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](https://reader034.fdocuments.in/reader034/viewer/2022051210/54f648284a7959d76e8b5636/html5/thumbnails/17.jpg)
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](https://reader034.fdocuments.in/reader034/viewer/2022051210/54f648284a7959d76e8b5636/html5/thumbnails/18.jpg)
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](https://reader034.fdocuments.in/reader034/viewer/2022051210/54f648284a7959d76e8b5636/html5/thumbnails/19.jpg)
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](https://reader034.fdocuments.in/reader034/viewer/2022051210/54f648284a7959d76e8b5636/html5/thumbnails/20.jpg)
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](https://reader034.fdocuments.in/reader034/viewer/2022051210/54f648284a7959d76e8b5636/html5/thumbnails/21.jpg)
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](https://reader034.fdocuments.in/reader034/viewer/2022051210/54f648284a7959d76e8b5636/html5/thumbnails/22.jpg)
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](https://reader034.fdocuments.in/reader034/viewer/2022051210/54f648284a7959d76e8b5636/html5/thumbnails/23.jpg)
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](https://reader034.fdocuments.in/reader034/viewer/2022051210/54f648284a7959d76e8b5636/html5/thumbnails/24.jpg)
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](https://reader034.fdocuments.in/reader034/viewer/2022051210/54f648284a7959d76e8b5636/html5/thumbnails/25.jpg)
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](https://reader034.fdocuments.in/reader034/viewer/2022051210/54f648284a7959d76e8b5636/html5/thumbnails/26.jpg)
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](https://reader034.fdocuments.in/reader034/viewer/2022051210/54f648284a7959d76e8b5636/html5/thumbnails/27.jpg)
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](https://reader034.fdocuments.in/reader034/viewer/2022051210/54f648284a7959d76e8b5636/html5/thumbnails/28.jpg)
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](https://reader034.fdocuments.in/reader034/viewer/2022051210/54f648284a7959d76e8b5636/html5/thumbnails/29.jpg)
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](https://reader034.fdocuments.in/reader034/viewer/2022051210/54f648284a7959d76e8b5636/html5/thumbnails/30.jpg)
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](https://reader034.fdocuments.in/reader034/viewer/2022051210/54f648284a7959d76e8b5636/html5/thumbnails/31.jpg)
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](https://reader034.fdocuments.in/reader034/viewer/2022051210/54f648284a7959d76e8b5636/html5/thumbnails/32.jpg)
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](https://reader034.fdocuments.in/reader034/viewer/2022051210/54f648284a7959d76e8b5636/html5/thumbnails/33.jpg)
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](https://reader034.fdocuments.in/reader034/viewer/2022051210/54f648284a7959d76e8b5636/html5/thumbnails/34.jpg)
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.