Malpractice Management System

Software Requirements Specification

Draft Version

Satish.C.J

Page 1 of 13
Contents

1. Introduction ......................................................................................................................................... 4
2. Purpose ................................................................................................................................................ 4
3. Scope .................................................................................................................................................... 4
4. Definitions, Acronyms and Abbreviations............................................................................................ 4
5. References............................................................................................................................................ 5
6. Overall Description............................................................................................................................... 5
7. External Interface Requirements ......................................................................................................... 7
8. Functional Requirements ..................................................................................................................... 8
9. Non Functional Requirements ........................................................................................................... 11
9.1 Usability ...................................................................................................................................... 11
9.2 Security ....................................................................................................................................... 11
9.3 Performance ............................................................................................................................... 12
9.4 Capacity ....................................................................................................................................... 12
9.5 Recovery...................................................................................................................................... 12
9.6 Availability ................................................................................................................................... 13
9.7 Reliability..................................................................................................................................... 13
9.8 Maintainability ............................................................................................................................ 13
9.9 Portability .................................................................................................................................... 13
9.10 Privacy ......................................................................................................................................... 13

Page 2 of 13
Revision History
Name Date Reason For Changes Version

Page 3 of 13
1. Introduction

Every educational institution focuses on reduction of malpractices during examinations and there by
establish good standards that contribute towards optimized evaluation processes for their students. As a
result the institution can gain credibility in the eyes of the industry by reducing the gap in terms of
identifying the right candidate for the various opportunities available. The Malpractice Management
System is one such system that focuses on effective utilization of resources towards malpractice
management thereby catering towards evaluation process optimization for students and faculty.

2. Purpose

The purpose of this Software Requirements Specification (SRS) document is to describe the overall
behavior of Malpractice Management System(MMS). This SRS defines and describes the operations,
performance, and quality assurance requirements of the MMS that is to be developed. This
document also describes the nonfunctional requirements. It also describes the design constraints and
technologies that are to be considered when the system is to be designed, and other factors
necessary to provide a complete description of the requirements for the system. This Software
Requirements Specification (SRS) captures the complete software requirements for the system.
Requirements described in this document will be used as guidelines to develop the Malpractice
Management System

3. Scope

The Malpractice Management System will automate the following processes.

Malpractice Registration by faculty members

Assignment and communication of enquiry committee members
Status tracking of Reported malpractices by students
Auto email Generation about the reported malpractice to the proctors and parents of the
concerned students
Report Generation on the malpractices reported for measuring the effectiveness of the
examination conduction process.

4. Definitions, Acronyms and Abbreviations

Abbreviation Designation
MMS Malpractice Management System

Page 4 of 13
 CS Chief Superintendent
ACS Assistant Chief Superintendent
COE Controller of Examinations
SRS Software Requirements
Specification

5. References

Malpractice Report COE office

6. Overall Description

6.1 Product Perspective

Malpractice Management system will help track malpractice incidents and give updates about
the status of the incidents to all stake holders through auto emails. It aids the efficient
generation of reports thereby contributing towards effective malpractice management in the
organization

Faculty

COE Student

MMS

Registrar Parent

Overview of the proposed system

Page 5 of 13
6.2 Product Functions

The following are the user requirements for the system

6.2.1 Faculty members who are in charge of the room where the malpractice incident happened
can report malpractices by entering the following details

6.2.1.1 Name of the Student

6.2.1.2 Registration Number

6.2.1.3 Semester

6.2.1.4 Exam

6.2.1.5 Slot

6.2.1.6 Date of Examination

6.2.1.7 Exam Hall Number

6.2.1.8 Type of Malpractice ( Copying/Discussions/Exchange of information/Written

Materials/Carrying prohibited devices/others)

6.2.1.9 Contents(answer script/Cellphone /Bit paper/Xerox/photo of writing /written

materials)

6.2.1.10 Report on Malpractice

6.2.1.11 Faculty Employee ID

6.3 User characteristics

The Graphical User Interface and online help must be sufficient to educate the users on how to use
the system without any problems. End users without any basic knowledge of computer systems will
be able to adapt to the form based user interfaces offered by the system with sufficient
documentation and end user training,

6.4 Constraints

6.4.1 Migration of all existing malpractice data on paper to the database

Page 6 of 13
 6.4.2 Integration of the student and faculty management systems with the Malpractice
management system for data synchronization

6.5 Assumptions and dependencies

6.5.1 Proctors and Parents are communicated about the malpractice only after the
malpractice incident is confirmed by the malpractice committee members
6.5.2 Only faculty members who are professors can be appointed to enquire a malpractice
incident
6.5.3 A student who involves in more than three incidents of malpractices will be dismissed
from the institution
6.5.4 Faculty and student information should be in sync with the student and faculty
databases

7. External Interface Requirements

7.1 User Interfaces

7.1.1 The system will provide GUI for the users.

7.2 Hardware Interfaces

7.2.1 The system will have an interface with the a scanner to scan copies of the materials
used for malpractices

7.3 Software Interfaces

7.3.1 The system will have an interface with the existing student and faculty management
systems for synchronization and validation of data

7.4 Communications Interfaces

7.4.1 The system will use click once deployment technology of the windows .net framework
where in windows form based applications can be accessed through http over the
internet.

Page 7 of 13
8. Functional Requirements

8.1 Use Case Diagrams

1. Register
Malpractice

Faculty

2. View Malpractice
Status

3. Validate
Malpractice Report
ACS/CS

Page 8 of 13
 4. View
Malpractice
Status

5. Give Feedback

Student
Parent
6. Receive Email
Notifications

6. Constitute
Malpractice Enquiry
Committee

7. Update
Registrar Malpractice Status

8. Approve
Malpractice
incident

Z
. 9. Schedule
Enquiry Meetings

Malpractice COE
10. Generation of
Committee
Reports
Member

Page 9 of 13
8.2 Use Case Scenario Description

Use Case ID 1
Use Case name Register Malpractice
Summary Faculty members who are in charge of the room where the
malpractice incident happened can report malpractices by
entering the following details

Name of the Student

Registration Number

Email Id of the Student

Phone Number of the Student

Semester

Exam

Slot

Date of Examination

Exam Hall Number

Type of Malpractice ( Copying/Discussions/Exchange of

information/Written Materials/Carrying prohibited
devices/others)

Contents(answer script/Cellphone /Bit paper/Xerox/photo

of writing /written materials)

Report on Malpractice

Faculty Employee ID

Preconditions Faculty member is in the list of members in charge of invigilation duty for
the room where the malpractice incident was reported
Success End Malpractice Registration Successful Confirmation Message is displayed
Condition to the user
Failed End Please fill in the required fields Message to the User when any of the
Condition given fields is blanks or all zeroes
Primary, Faculty Assigned Invigilation Duty
Secondary Actors
Trigger This use case is initiated based on the request from the Faculty

DESCRIPTION Step Action

Page 10 of 13
 1 The End user clicks on the Malpractice Registration button

2 The malpractice id is auto generated by the system and displayed

to the end user

3 The end user enters the Student Name, Registration Number,

email id of the student and phone number of the student in the text
boxes
4 The End user selects Date of Examination from a calendar display

5 The type of Malpractice, contents and gender of the student is

selected from a list of values in a drop down combo box
6 The malpractice report is entered in a text area

7 The End User Clicks on the Submit Button

EXTENSIONS Step Branching Action
1a The system updates the data into the database.

1b The system retrieves the faculty login id and updates it with the
Malpractice Registration details into the database

The system validates if the faculty reporting the malpractice is in

1c charge of the room where the malpractice happened using an
examination schedule database which is updated by the
Examination management system of the university.

9. Non Functional Requirements

This section describes in detail all the non-functional requirements

9.1 Usability
9.1.1 The system shall allow the users to access the system from the Internet.
9.1.2 online help will be available for the system
9.1.3 The end users will be able to able to adapt to the system with a minimum training of 40
hours
9.1.4 Key board short cuts will be available for all functions of the system

9.2 Security

9.2.1 Login requirements -

Page 11 of 13
 9.2.1.1 Police officers will be provided access to the system after they are registered by their
recruitment officers
9.2.1.2 Police officers will be logging into the system using their ID and one time password
emailed to them.
9.2.1.3 On login they will be asked to change their passwords

9.2.2 Password requirements

9.2.2.1 Passwords must have a minimum length of 8 characters

9.2.2.2 Passwords must meet at least 3 out of the 4 requirements for quality:

o at least 1 lower case letter

o at least 1 upper case letter
o at least 1 number
o At least 1 special character (?, *, %)

9.2.2.3 Password should not contain the users first name, middle name, last name, or
username.
9.2.2.4 Passwords on sensitive IT systems must be changed, at a minimum, every 90 days.

9.2.3 Inactivity timeouts

9.2.3.1 System should timeout when there is no activity for five minutes.

9.3 Performance

9.3.1 Response time

9.3.1.1 The response time will be less than 8 seconds for 95% requests made to the system

9.4 Capacity

9.4.1 Storage

9.4.1.1 Hard disk space

450 GB Content

50 GB Transaction Logs

9.5 Recovery

9.5.1 Recovery time scales

Page 12 of 13
 9.5.1.1 The system will be recovered within four hours from the down time

9.5.2 Backup Frequencies

9.5.2.1 A full back up of MMS data will be done on tapes on the last day of every month
9.5.2.2 The backup is scheduled to run automatically at 10 pm on the scheduled date
9.5.2.3 The backup tapes when removed from the server are stored securely in a locked
fire-proof media safe at COE office in SJT 8th floor

9.6 Availability

9.6.1 Hours of operation

9.6.1.1 The system will be available on all days 24*7

9.7 Reliability

9.7.1 Mean Time between Failures

9.7.1.1 The mean time between failures for the system will be 1000 hours

9.8 Maintainability

9.8.1 Mean Time to Recovery

9.8.1.1 The Mean Time To Recovery (MTTR) shall not exceed one person day.

9.9 Portability

9.9.1 The system will run on windows 95/98/2000/NT/XP/Vista/Windows7

9.10 Privacy

9.10.1 Reports cannot be accessed by end users who are not given access to the reports
9.10.2 Students will not be able to view malpractice details of other students
9.10.3 Malpractice data will be held confidential and only COE will be given the authorization to modify
the data.

Page 13 of 13