SRS-OCERSWDE-V2

8/3/2019 SRS-OCERSWDE-V2

1/27

1

Copy right 2011 of MoE and eDruk IT Consultancy

Software Requirements

Specification

For

Education Portal (Online

Centralized ExaminationRegistration System with Data

Export)

SRS-OCERWDE-V2

Version: 2

Date: 29/03/2011.


2/27

2


1 Revision Table

SL # Version Author Date Remarks

1 1 Tenzin Norgay 24/03/11

2 2 Tenzin Norgay 29/03/11 Project Manager have recommend for the

iteration of SRS format.


3/27

3


2 Sign-Off

Project Name: Education Portal

Project Manager: Karma Dorji

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

Date:

The Approvers 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 Online

Centralized Examination Registration System with data export.

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


4/27

4


3 Owners and List of Contacts

4 Definitions, Acronyms, and Abbreviations SRS: Software Requirement Specification. E-Portal: Education Portal, Client/Users: BBE, SCHOOLS, DEO, Internet user at the Internet access point UC OCER: Use Case for Online Centralized Examination Registration System with data export. Server: A system that runs in Linux always monitoring the actions. HTTP: Hyper Text Transfer Protocol User-ID: Unique username issued to each user on login. Password: Unique word given to each user as a secret code. OCER-DIC: Design and implementation constraints. OCER-UD: User documentation. OCER-AS: Assumption. OCER-DS: Dependencies.

OCER-SF: System Features. OCER-SF-DP: Description and Priority. OCER-SF-S/R: Stimulus/Response Sequence. Priority Level:1- low priority

5- Medium priority.

9- High Priority.

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
mailto:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]


5/27

5


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

D6Hardware 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, byiTechnologies

Requirement Gathering Report, by eDruk Requirement Validation Report, by eDruk Study Report, by eDruk Meetings with stakeholders, and clients by eDruk.

6 Document Conventions

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

Font Meaning

Times New Roman Normal Text

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

should be given more importance

Times New Roman (Italic) Special cases, where the system is not catered

to, or is something that should be thought for


6/27

6


future development

Cambria : Size 14 Heading

Cambria : Size 13 Sub heading

Line Spacing 1.5

7 Abstract

Bhutan Board of Examination will have an interface for online centralized examination registration

system with data export mechanism. Here the students can register online and access their register number

or index number directly from the system. School can upload and access students information from the

system. BBE focal person will extract and export the data in the system for results processing.


7/27

7


Table of Contents1 Revision Table ....................................................................................................................................... 2

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

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

4 Definitions, Acronyms, and Abbreviations ........................................................................................... 45 References ............................................................................................................................................. 5

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

8 Introduction ................................................................................................................................................ 8

8.1 Purpose ................................................................................................................................................ 8

8.2 Brief Scope of Project ..................................................................................................................... 8

8.3 Project Scope ...................................................................................................................................... 8

8.4 Portal Objectives ............................................................................................................................. 9

8.5 Intended Audience and Reading Suggestions ..................................................................................... 9

8.6 Document overview .......................................................................................................................... 10

9 Overall Description ............................................................................................................................. 10

9.1 Product Perspective ........................................................................................................................... 10

9.2 Product Features ................................................................................................................................ 11

9.3 User Classes and Characteristics....................................................................................................... 11

9.4 Operating Environment ..................................................................................................................... 11

9.5 Design and implementation constraints ............................................................................................ 13

9.6 User Documentation: ........................................................................................................................ 14

9.7 Assumptions and Dependencies: ....................................................................................................... 14

9.7.1 Assumptions: .................................................................................................................................. 14

9.7.2 Dependencies: ................................................................................................................................ 14

9.8 User view of the software ................................................................................................................. 14

10 System Features .............................................................................................................................. 15

10.1 Business Process: ........................................................................................................................ 15

10.2 System Feature 1 (Register for the Examination) ........................................................................... 16

10.3 System Features 2 (Schools/Principal will upload the student data in the System) ........................ 18

10.4 System Features 3 (Export the Data in the system) ........................................................................ 20

11 External Interface Requirements ......................................................................................................... 2211.1 User Interfaces ................................................................................................................................ 22

11.2 Communications Interfaces ............................................................................................................. 23

12 Non-functional Requirements ......................................................................................................... 24

12.1 Data Requirement for Online Centralized Examination Registration System ................................ 24

6 Other Requirements ................................................................................................................................. 27


8/27

8


8 Introduction

8.1 Purpose

This is the first draft of SRS, revision 1.for online centralized examination registration system.

The purpose of this document is to define the SRS for online centralized examination registration 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 Training Requirements Safety Reliability

Security/Privacy

Quality Constraints and Limitations

8.2 Brief Scope of Project

The main scope of the portal project is:

Online centralized examination registration system with data export mechanism

8.3 Project Scope

The main scope of the online registration system is to ensure all the schools to have a systematic

registration system and to access the index number and results of the examination online in the system.

There will an interface for schools and teachers to export and upload the examination data in the system

and published the results of examination online in the system.


9/27

9


8.4 Portal ObjectivesMain Objectives of the Education Portal are:

Improve systemic efficiency in service delivery mechanism Widen access to high quality, relevant and diverse resources and learning opportunity to teachers

and students

Expose all learners, in advantaged and disadvantaged, to enriched educational experiences. Provide to all learners and teachers the means of communications and collaborations Information sharing, communication and collaboration among agencies

8.5 Intended Audience and Reading Suggestions

Sl No Audience Description

1. Project Manager Project Manager can use this document to update the projectplan. 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,

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 usecases in the SRS, they can also come out with the required

inputs to get particular outputs from the application.

4. DocumentationWriters

Documentation writers can use the SRS to write the

Administrator and User Documents. All the required business


10/27

10


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.

8.6 Document overview

The first section of SRS builds a brief idea what the proposed System of online centralized examination

registration is and what is the need behind having it. Along with this background information it also

provides the reference information for further study, design and implementation.

The second section shows the way to overall description of application, functions, perspective, operating

environment, design and implementation constraints, data inputs required.

The third section explores the various descriptions of external interfaces such as user interface, hardware

interface, communication interface and software interface.

The fourth section is written with a goal to show the various system features in detail. The subsections

give an elaborate description of individual features.

The fifth section focuses on details of non-functional requirements such as security requirements, safety

requirements etc.

9 Overall Description

9.1 Product Perspective

Education Portal is a new web based application that is being developed completely as a new system.

Some of its components or modules include integration with existing systems in Ministry of Education


11/27

11


9.2 Product Features

Education Portal 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.

9.3 User Classes and Characteristics

The following are the different user and their role in the system:

Name Responsibilities

Students Student will do register to their examination through the system.

School/Principal Schools will upload the students data in the system for the registration

in examination.

BBE BBE focal person will view and verify the uploaded student data and

process it for the registration through the system.

9.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 / 16GB memory / 4 x 146 GB SAS

internal disk / RAID controller /

redundant power supply / 2 x

1Gbps network ethernet port /

Database servers

(Running mysql

server as Database

server, on Linux

Platform)


12/27

12


Item

Sl.


cluster

(Minimum Requirement)

Will host all thedatabase for

Education Portal

2. Web server 1 2 x Quad core Itanium proc / 32GB 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 ContentManagement System,

Java Framework

3. Web ConferenceServer

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

2 2 x Quad core Itanium proc / 64

GB memory / 6 x 146 GB SAS




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)


13/27

13


Item

Sl.


5. Backup server 1 2 x Quad core Itanium proc / 64GB memory / 8 x 146 GB SAS




cluster

Backup Server

Operating System (OS)

6. Suse Linux 17. Ubuntu 1

Network Infrastructure

8. Switch 1 24 port / Gigabit ethernetSite Related

9. Rack 1 as req.10. UPS 1 2 x 10 KVA dual redundant11. Internet

connectivity

1 At least 1 mbps at the

core location

9.5 Design and implementation constraints

System ID Description

OCER-DIC-1 The school should have the internet access to get register their students online in

the system.

OCER-DIC-2 For ensuring platform independence of the software the implementation will be

JAVA so the end users system must have a JAVA run time environment.


14/27

14


9.6 User Documentation:

A user document should be provided at the end of the development. It should have the following:


OCER-UD-1 A readme file to help the user with the installation of the software.

OCER-UD-2 A well documented user manual.

9.7 Assumptions and Dependencies:

9.7.1 Assumptions:

We have made the following assumptions:


OCER-AS-1 Students registering for their examination online in the system.

OCER-AS-2 Student accessing their index number from the system.

9.7.2 Dependencies:


OCER-DS-1 This software would need JAVA runtime environment and some additional

packages for working.

OCER-DS-2 It will need an internet access point to every school in Bhutan.

OCER-DS-3 It will need a web browser for viewing the published presentation.

9.8 User view of the software

This software will have graphical user interface that are very user friendly. The user will have no

difficulty in working with these user interfaces. The users will import required files into the softwares

window, place these files on the time line and edit the duration these files should be displayed. All these

operations will be made easy by the softwares user interfaces.


15/27

15


10 System Features

10.1Business Process:

Figure1: Process Flow of Online Centralized Examination Registration.

Explanation:

Here the student will be registering for their examination through the system, and then the teachers or the

schools will upload the students data in the system for registration. Once the student submits the

registered form in the system, they will get their index number generated by the system. The BBE will

extract the uploaded data from the system and view and verify the student details before processing for

assigning the index number.


16/27

16


10.2 System Feature 1 (Register for the Examination)

10.2.1 Description and Priority:

System ID Name Description

OCER-SF1-DP-1

Description The student will have an access to register themselves for

their examination. The students will fill up the form given

in the system and will be register by submitting it.

Priority Registration for examination by the student will be in first

priority in the system processes and is in 9th level in

priority.

10.2.2 Stimulus/Response Sequences:

Name Description

OCER-SF1-S/R-1 If the students wants to be register for the examination, they have to fill up

the necessities details in the form, the system will display the registration

form with the option to send or Cancel after the user have finish filling

up the form.

OCER-SF1-S/R-2 After that student can submit the filled up form by clicking the Send

button, then the system will notify the form is send.

OCER-SF1-S/R-3 If the user dont want to send the form, by clicking on cancel button,

system display with the message your form will be cancelled click Yes to

continue cancellation or No to continue sending.

OCER-SF-S/R-4 When filling up the form, if the user has left some of the fields empty and

try to send the form, system will display you cannot leave the field

empty. Fill up the empty Fields.


17/27


18/27


19/27

19


OCER-SF2-DP-1

Priority Verifying and uploading of data will be 9th

level of

priority level.

10.3.2 Stimulus/Response Sequence:

Name Description

OCER-SF2-S/R-1 When the schools/ principal want to verify and upload the student data,

they login to their user account. The system will provide the user interface

to login with their password and user name.

OCER-SF2-S/R-2 If the user has type incorrect username or password, the system shows

validation window with the message your username or password isincorrect, please check your username and password properly and try

again

10.3.3 Functional Requirement

10.3.3.1 Detailed Use Case:

Name Description

Use Case Name Upload Students Data in the system.

Identification UC OCER 2.

Description Teachers and principal from the schools will upload the data in BBE

format in the system.

Pre-Condition Students should be registered. BBE data format should be provided.

Post-Condition Data will be uploaded in the system. BBE will export the data in the system.

Basic Course of Action

Student will register for the examination. Schools will upload the students detail in the system. BBE will verify and export the data in the system.


20/27

20


Trigger Schools will upload the data in the system by clicking in upload button.

Exception Paths

Alternative Paths

10.4 System Features 3 (Export the Data in the system)

10.4.1 Description and Priority:

System ID Name Description

OCER-SF3-DP-1

Description Once the data are uploaded, BBE focal person will

verify and export the data in the system for further

process. Then the system will generate student index

number.

Priority Export of data in the system will be the 6th priority

level.

10.4.2 Stimulus/Response Sequence:

Name Description

OCER-SF3-S/R-1 BBE will enter into the system with their user name and password to

export the uploaded data in the system, the system will provide the user

interface for processing the data in the system.

OCER-SF3-S/R-2 The BBE will verify and approved or reject the registered form for the

students. The system will notify that the registration have been approved

or rejected by BBE.

OCER-SF3-S/R-3 Once the BBE finished processing the registered form by students in a

given interface, the system will generate the Index number and display in

the system.


21/27

21


10.4.3 Functional Requirement

10.4.3.1 Detailed Use Case:

Name Description

Use Case Name Export the data in the system.

Identification UC OCER 3.

Description BBE focal person will export the data in the system.

Pre-Condition Student data should be uploaded and reached to BBE.

Post-Condition Student will get registered and can access their registered number.

Basic Course of Action Student will register for the examination. Schools will upload the students data in the system. BBE focal person will export the data in the system. System will generate the student index/registered number.

Trigger BBE will export the data by clicking export button and cancel by

clicking in cancel button.

Exception Paths

Alternative Paths


22/27

22


11 External Interface Requirements

11.1 User InterfacesThe user interface is an important part of this software and will make the software very user

friendly.

The user interfaces of this software are expected to be as follows:

Figure 3: Student Examination Registration Form


23/27

23


Figure 4: System Generating the Index Number

11.2 Communications InterfacesSince our system is a web-based system almost all the performance can use the system if the web

browser is included.

HTTP can be used as a standard communication tools and in addition to improve to security a

browser supporting SSL is needed. Also, the users computer must be able to connect to the

Internet.


24/27

24


12 Non-functional Requirements

12.1 Data Requirement for Online Centralized Examination Registration

System


25/27

25



26/27

26



27/27

6 Other Requirements

Figure 5: Activity Diagram for Online Examination Registration

SRS-OCERSWDE-V2

Documents

Transcript of SRS-OCERSWDE-V2