Quick Student Information

Database

Anamitra Ghorui (201800468), Sumiran Pradhan (201800291),

Ashish Dev Nagar (201800482)

Abstract
Collection of information by positions of authority often involves students
submitting redundant information that may be already available in a
previously submitted form. Multiple authorities may ask for forms
requesting the same information again and again.

This project attempts to eliminate such redundancy and inconvenience by

creating a web service that allows teachers to generate reports of student
information at will, and notify students before such a report is generated in
order to check their information.

1
 Table of Contents
1. Introduction..................................................................................................................................3
2. Feasibility Study..........................................................................................................................4
2.1 Summary...............................................................................................................................4
2.2 Component Identification......................................................................................................4
2.3 Manpower.............................................................................................................................5
2.4 Communication and Transport..............................................................................................5
3. Software Requirements Specification of the Project...................................................................6
3.1 Introduction...........................................................................................................................6
3.1.1 Purpose..........................................................................................................................6
3.1.2 Scope.............................................................................................................................6
3.1.3 Overview of the Specification.......................................................................................7
3.2 Overall Description of the System........................................................................................7
3.2.1 Product Perspective.......................................................................................................7
3.2.2 Interfaces to the system.................................................................................................7
3.2.3 Use Case Diagram of the System..................................................................................8
3.2.4 Characteristics of the Users...........................................................................................8
3.2.5 Assumptions and Constraints on the System.................................................................8
3.3 Specific Requirements of the System...................................................................................9
3.3.1 External Interface Description.......................................................................................9
3.3.2 Data Flow Diagrams....................................................................................................10
3.3.3 Functional Requirements.............................................................................................13
3.3.4 Non Functional or Optional Requirements..................................................................13
3.3.5 Logical Database Requirements..................................................................................13
3.3.6 Project Module Breakdown and Development Time Estimation................................15
3.3.7 Maintenance, Security and Risk Analysis...................................................................17

2
1. Introduction
Students often have to frequently submit redundant information that is otherwise
readily available in previously submitted forms that may have been collected.
Secondly, information of a student may change frequently, for which an authority will
have to make more and more forms to collect this information. Authority may also
overlook whether or not this information has been collected before or not.

For example:

• Teacher A has collected names and Email IDs of students. Teacher B may also
require the Email IDs of students as well as phone numbers. Teacher A is not
in contact with Teacher B and therefore doesn’t know the emails have already
been collected. Hence another form is issued by Teacher B, collecting
information in a redundant manner.

• A field omission may have been made in a given form by a Teacher, which may
lead to the Teacher making another form with the exact same fields
All of these cases create unnecessary and inconvenient work both for the Teacher and
Student in question.
This software attempts to solve this problem by creating a facility which creates
requests for Students to update or check desired information already present in the
database for submission. These requests are issued by a Teacher.

The interface then allows the Teacher to generate a report in the desired format, such
as comma-separated variables (CSV), in excel sheets, simply in PDF format with the
values listed in tables etc.

Teachers may also create private fields for updating private information specific to the
class. For example, a teacher may require the Github accounts of all the students, all
the teachers do not want it. These fields can be promoted to public status as required
or certain private fields may be merged. This may cause conflicts and mitigation for
this is explained in detail later in the document.

To update new or existing fields, a dynamic form interface is available for

automatically generating forms for the data fields specified.

3
2. Feasibility Study

2.1 Summary
Since this is mostly a small scale, organic project with most components well tested
and freely available in the ecosystem at no cost, this project is feasible with little
investment aside from manpower, methodology and maintenance.

2.2 Component Identification

The following components have been identified for the system:
• Web Interface: In order to be available to as many people as possible, a web
interface is recommended.

• Programming/Server Side Scripting Language: In order to achieve the

project’s results, a server side scripting language is needed. Python is
suggested.

• Web Server: A web server and server side scripting is required for
communicating with the user and the database. Flask is suggested.

• Database: Information is abstract, varying and can range between images,

numbers, short paragraphs etc. Such abstract information is a good fit for
MongoDB. For Example, a record may look like this:
{
"database_custom_id": 12321312321,

"READONLY" : { /* Fields set by the administrator/teacher directly. */

"name" : "ABC",
"reg" : "123456",
"sem" : 5,
"sec" : "B",
"roll" : 123,
"GPA" : "1.23",
"password" : "PASSWORD_HASH"
},

"PUBLIC" : {
"email": [
"abc@def.gh",
"ghi@jkl.mno"
],

"mobile": [
"123456789",
"987654321"
]
},

"PRIVATE" : {
"teacher_213" : {

4
 "github_account": "github.com/abcd"
},

"teacher_234" : {
"telegram_account": "t.me/abcd"
}
}
}

• User Hierarchy: There will be 3 users in the hierarchy, the website

administrator, the teacher/position of authority, and the student. Website
administrator can add or remove accounts.

• Format Conversion Tools: One of the many features of the system is

producing a report from generated data. Large number of libraries are available
for conversion between csv, excel and other formats. Generation of PDFs of
given data can be done easily using existing python libraries.
All of these components are freely available for use by both non commercial and
commercial firms. Therefore there is negligible cost, aside from hosting the web server
that comes in the technology requirements.

2.3 Manpower
Since this is a small scale project and most of the components are freely available,
well tested and well documented, not much man power is required for this project
provided that the staff has the knowledge of using the above technologies.

2.4 Communication and Transport

All communication can be done online between the team members. No transport is
required as communication tools are well advanced enough to not require any sort of
movement by the staff, provided they have the communication and work devices.

5
3. Software Requirements Specification of the Project

Version Primary Author(s) Description of Version Date

Completed

1 Anamitra Ghorui, Initial Version 21 Oct 2020

Ashish Dev Nagar,
Sumiran Pradhan

3.1 Introduction
This software implements a database system that allows for convenient access to
student details for people of authority. It allows convenient report generation of
student data for official work.

3.1.1 Purpose
The purpose of this project is to reduce the substantial amount of inconvenience that
a person of authority has to go through to collect student information, as well as
reduce the inconvenience of the student who has to fill in redundant information again
and again.

3.1.2 Scope
The scope of the project is to:

• Produce and deploy a full stack of a MongoDB database, Flask/Python, Nginx

on a Linux or Linux like system.

• Allow a teacher to prompt student for a form requiring new and existing
information.

• Allow a teacher to gather and generate reports from student information.

• For non-essential or non-mandatory activities, information will only be sent to

a teacher if the student approves it.

• Accounts are only created by a trusted authority: the sysadmin, once.

6
3.1.3 Overview of the Specification
This SRS details the components and functions of the whole system, as well as the
requirements of the whole system.

Section 3.2 provides a detailed description of the whole system.

Section 3.3 provides the specific, technical requirements of the system.

3.2 Overall Description of the System

This system, due to its nature requires network infrastructure to be present,
maintenance personnel to be present and sufficient hardware capability to manage a
database and requests from the whole population of the given institution.

This also requires the concerned personnel as well as the users to have internet
connectivity to their devices, which is likely considering the present scenario.

3.2.1 Product Perspective

One can say that the idea of this project is similar to Aadhar, as in the fact that both
of these systems provide credentials of the account bearer. However, unlike Aadhar,
information can be added to a user's individual record as per request by the
authority, and can be retrieved by the teacher and reports can be generated.

There is also a system for getting consent from a specific user. Each user will have to
input a specific PIN or password in order to give their consent to a teacher to use
their information. This will prevent bad actors from using unauthorised information
and sign up a user to an event he or she may not want to attend.

3.2.2 Interfaces to the system

The main interface used to interact with the system is the web one. An optional
interface for phones may be implemented. Web interfaces can work on any system
that has a web browser. Responsive design practices must be followed so that the
system works as expected on all devices.

There are 3 main actors on the system:

1. The User: This is the student. The student gives and updates required
information, and is also given options to supply one-time alternate information

7
 when prompted.

2. The Teacher/Position of Authority: A teacher is assigned to several

classrooms. The teacher can ask for existing or new information. New
information that is not visible to other teachers, and/or is specific to the
teacher is kept in private fields specific to the teacher.

3. The System Administrator: The System Administrator or Sysadmin creates

and manages accounts on the system.

3.2.3 Use Case Diagram of the System

Quick Student Information Database

Obtain Update
Consent from Existing
Student Information

Internal System
View List
Get Student of Filled Login
Login Details Forms

Teacher
«extend»
Student
Consent to
Give
Generate Infotmation
Formatted
Report

3.2.4 Characteristics of the Users

We assume that the users are comfortable in reading and writing in the English
language, and are able to operate computers with a moderate level of confidence.

3.2.5 Assumptions and Constraints on the System

We assume that not much is to be spent on the hardware to host this service. Hence
we will assume a traffic of 45 users per hour, and a total userbase of 500 students.
This thus can be implemented with a sufficiently modern and powerful computer,
with at least 500 GB to 1 TB of disk space. This needs to be present in the Intranet
of the college campus, and be deployed on the WAN through a Domain name.

We also assume that the given computer runs a system with Linux deployment

8
capability, since the entire stack is built there.

3.3 Specific Requirements of the System

This section lists more technical details regarding the system, the structure of the
software and approaches used to develop and maintain the software.

3.3.1 External Interface Description

The web interface shall be divided amongst the following pages:

1. Home Page/Landing Page: This is the first page that a user sees. This
interface allows either a teacher or student to log into their respective
dashboard pages.

2. Teacher Dashboard Page: This page is accessible is only to the teacher.

This page will show the Teacher's profile information, and list all the
classrooms the Teacher has been assigned to. The teacher then can select a
classroom.

3. Classroom Dashboard Page: This lists the students in the given classroom
and the data fields that have been collected from these users. The interface
allows the teacher to select all students or a number of students and send
notifications to them to update their information. It then allows a teacher to
generate a tabulated report from the information. Any number of students can
be added to a classroom by a teacher via a browsing pane present.

4. Student Dashboard Page: This allows the student to update his or her
information in a preliminary manner and view pending forms and notifications
as well as forms that have been consented to and submitted.

5. System Administration Page: This interface allows the sysadmin to

perform addition and deletion of accounts of the system as well as other
miscellaneous management.

6. Form Input Page: This page dynamically generates forms as per Teacher
request, which is then filled up by the user.

9
3.3.2 Data Flow Diagrams
Level 1 DFD:

10
Level 2 DFD:

11
Level 3 DFD:

12
3.3.3 Functional Requirements
The system must satisfy the following objectives:

1. Allow the Teacher to look up the list of students, and assign them a form to be
filled up upto a certain time limit.

2. The system must in some way notify the student that a form needs to be filled
up, and also notify them about the time limit or deadline.

3. The system must allow the student to fill up and update new and existing
system information respectively, as well as give consent to the information
being filled. The system must store these consents.

4. The system must get the student data and present it to the teacher in a concise
manner, and then allow the teacher to generate a report out of it, such as in
the form of a table.

3.3.4 Non Functional or Optional Requirements

The system can have other optional objectives

1. The system can have the facility of generating reports in a wide variety of
formats.

2. The system may send automated email notifications to the students for the
forms.

3. There may be a facility of doing statistical analysis over the acquired data.
Such as the mean, response rate etc.

3.3.5 Logical Database Requirements

The type of data that we are trying to represent is always changing and abstract,
since teachers can ask for virtually any kind of data. Such pieces of information are
better represented in the form of trees, or "dictionaries" rather than tables.

If we were to implement such a database in SQL the whole database would consist of
nodes and pointers that are filtered and indexed from to generate the information

13
tree, which these dictionary structures represent.

Hence it is decided that we will be implementing the database in MongoDB, where

such data is represented with ease,

The "schema" for the Student and Teacher dictionaries will look something as follows.
The form schema and notification storage is not shown here.:

14
The data that is meant to be represented is written in the form of "datatype strings",
in the schema or "template" dictionaries of each form that is sent out. For example, a
form request may be represented as such:
{
"name": {
"type": "string",
"references" : "READONLY.name" // References user name.
},
"parent_telephone_no": {
"type": "tel",
"entries": 2,
"label": "Parent's Telephone Number",
"visibility": "PRIVATE",
"references": "\0" // References nothing. New entry.
}
}

The student record schema may be represented as such:

{
"READONLY" : {
"name" : "string",
"reg" : "int(10)",
"sem" : "int(1)",
"sec" : "char(UPPERCASE, 1)",
"roll" : "int(3)",
"GPA" : "float(2,2)",
"password" : "string"
}

// ...
}

Technologies such as MongoDB Realms and Stitch have been considered, but
dismissed due to costs.

3.3.6 Project Module Breakdown and Development Time Estimation

We have used the simple COCOMO model over here to estimate the time cost of our
project. The project is dependent on popular and well tested technologies, and
therefore is considered to be an "Organic" project as per the COCOMO Model.

We now estimate the lines of code required to create the project based on the
component description as given above. We will consider the external interface pages
to break down the project into modules as follows:

1. Base Overhead

This consists of the number of lines required to set up the Flask environment
along with the Flask-PyMongo Database library for communicating with the
MongoDB database and the login system. Estimated Lines: 150 (0.15

15
 KLoC)

2. Style Sheets and User Interface design

This is the number of lines in templates that need to be created and the
amount of CSS that needs to be written to style the templates. Estimated
Lines: 200 (0.2 KLoC)

3. Form Generation Logic

Based on the form schema, the logic of how the form is to be generated is
written here. Estimated Lines: 80 (0.08 KloC)

4. Classroom Dashboard

Mainly needs to query the database for students and their info as well as create
new forms for them. Estimated Lines: 200 (0.2 KloC)

5. User Dashboard

Mainly needs to update existing information and accept notifications for forms.

Estimated Lines: 100 (0.1 KloC)

6. Sysadmin Dashboard

Estimated Lines: 100 (0.1 KloC)

7. Landing Page/Home Page

Estimated Lines: 40 (0.04 KloC)

Total Kilo Lines of Code = 0.15 + 0.2 + 0.08 + 0.2 + 0.1 + 0.1 + 0.04

= 0.87 KloC

Therefore, by COCOMO model,

Effort (E) = 2.4 * (Total KLoC)1.05 = 2.4 * 0.871.05

16
 = 2.07 Person Months

Development Time = 2.5 * (E)0.38 = 2.5 * 2.070.38

= 3.29 Months

These development times are considered inflated due to the apparent

simplicity of the project. A lot of the lines encountered in the project will
be in the form of markup or layout language code that is not considered of
much effort. By rough estimation, the development time seems to be 1 to
1.5 months.

3.3.7 Maintenance, Security and Risk Analysis

1. Unauthorised or bogus use of information for enrolling a student in an activity
is prevented with the use of consent clauses. The user has to consent first
before the party is given the information. This happens in the form of a
prompt, which a user has to accept or decline. The system stores this response.

2. Information may be lost due to software bugs. However due to the small size of
the project, these may be solved quickly.

3. Additional verification of consent may be ensured by using public key

cryptography, such that the user has a private key, and uses it to sign consent.
This introduces another element in the system which uses resources and may
have a learning curve.

4. The database may get too big for a hard drive, and therefore must be checked
routinely such that such incidents of data entry failure are avoided.

5. Other general procedures of maintenance and error prevention are to be

followed.

17