Bo

ee

Software Requirements ; Analysis and Specifications 97

9 STUDENT RESULT MANAGEMENT Sycerer AT

3.9 STUDENT RESULT MANAGEMENT SYSTEM—EXAMPLE ,

A university has decided to engage a software company for the automation of.student
result
management system of its M. Tech. Programme. The following documents are required
to be
prepared. —- ;
(¢) Problem statement
(ii) Context diagram
(iii) Data flow diagrams
Gv) ER diagrams
(v) Use case diagram
(vt) Use cases
(vii) SRS as per IEEE std. 830-1993
These seven documents may provide holistic view of the systme to be developed. The
SRS will act as contract document between developers (software company) and client
(University). :

3.9.1 Problem Statement

The problem statement is the first document which is normally prepared by the
client. It only,
gives superficial view of the system as per client’s perspective and expectations.
It is the input
to the requirement engineering process where final product is the SRS.

The problem statement of student result management system of M. Tech. (Information

Technology) Programme of a University is given below:

“A University conducts a 4-semester M. Tech. (IT) program. The students are offered
four theory papers and two Lab papers (practicals) during Ist, IInd and IIIrd
semesters. The
theory papers offered in these semesters are categorized as either ‘Core’ or
‘Elective’. Core
papers do not have an alternative subject, whereas elective papers have two other
alternative
subjects. Thus, a student can study any subject out of the 3 choices available for
an: elective
paper.

In Ist, IInd and IIrd semesters, 2 core papers and 2 elective papers are offered to
each
student. The students are also required to submit a term paper/minor project in
IInd and IIIrd
semesters each. In IVth semester the students have to give a seminar. and submit a
dissertation
on a topic/subject. area of their interest. .

The evaluation of each subject is done out of 100 marks. During the semester, minor
exams are conducted for each semester. Students are also required to submit
assignments as
directed by the corresponding faculty and maintain Lab records for practicals.
Based on the
students’ performance in minor exams, assignments, Lab records and their
attendance, marks

out of 40 are given in each subject and practical paper. These marks out of 40
account for ,

internal evaluation of the students. At the end of each semester major exams are
conducted in
each subject (theory as well as practical). These exams are evaluated out of 60
marks and
account for external evaluation of the students. Thus, the total marks of a student
in a subject
are obtained by adding the marks obtained in internal and external evaluation.

Scanned with CamScanner

PuapetteDnimieennne nat 2 at
98 oe ~— en a : ; _ 7 7 | ; | | |
" Softwar Engineering |

— Frac yntieet has some credit points assigned to it. If the total marks of a cea
or
Fail’ in that cuvieet hk ‘ bs pale ‘Pass in that subject otherwise the student is
consic or
63 that. cubioct —_ - , stu ent passes ina subject, he/she earns all the credit
points assignec
Sei cutiiene NI a na patents fails in a subject he/she does not earn any credit
point in
fas and their eran eae atest information about subjects being offered in various
semes-
scan be obtained from university's website.
_ It is required to develop a system that will manage information about subjects
offered in
; a hens Semesters, students enrolled in various semesters, elective (s) opted by
various students
m different semesters, marks and credit points obtained by students in different
semesters.
the system should also have the ability to generate printable mark-sheets for each
student.
Semester-wise detailed mark lists and student performance reports also need to be
generated.”

OAK

(¢

2 miaw ;}
Context Diagram

The context diagram is given below:

Data entry : Marks entry

operator operator
|
| Student info |
entry |
yy .
Student info | , ——N Marks entry
entry / \
{ Student result |
Administrator | management a
. . / :
| User account \ , /
{ maintainence ia Generate
Lo - Pc reports
v
—_——_ Co-ordinator
| a
o 7 v
Student info jas Student
raports g performance
generated reports
generated

‘ t; a ”
4 £ a r ?
> o * 4 py 4) Vv 8 udent result management sy stem

(i) Administrator
(ii) Marks entry operator
(iii) Data entry operator

(iv) Co-ordinator

Scanned with CamScanner

ws APRA
a

[pe Requirements : Analysis and Specifications

Level-t

The Level-1 DFD is given below:

—— : ———------ Enter user id, password, role

Marks details Co-ordinator
_T
f : . View
Marks entry Marks info, Stuent performance reports reports
Marks entry clerk —--- —— >| manage. f- )
| \ ment / | Mark-sheets if |
poi es | |
_ CL gS Report hy}
a | generation |
—— > "Student a
ai subject choice i
details
~~ wen
| 7 ———
Student info / Student \ —
_eny info | 7 |
[ \ manage- | > | H
| Soment. / Student stud ‘ H
——— jant into
Data entry operator - -—-- = -—» Sub. choice _ ae
| | Enter subject choices of students \ Manage- p
Enter user id, | _ ‘ment |
ee rale| | ea _ ———
| Subject info nin / Student \,
i ——_—_——», info |
) | \ manage- /
YW»? Login = }4—-— . ment”
. |
| + ae _
a
Enter Subject info
user id, ee %
password, -
role |
' User account
info
a
Soa
account \

Administrator user info entry — > manage- /

Namen /

Level 1 DED of. result management system

Scanned with CamScanner

1uu
ee

Level-2 DFDs

1. User account maintenance

Access User Info

|
van

_ Administrator —~~

\. Retrieve User Info

/
Display User’ ;
Account Info /""

: . User Account Info

Enter/Update/Delete User Info _ —S— oF

ae

“ ~
Validate/ \
Process User }4—
Info _ Update/Delete
QO User Info
_

2. Login
The Level 2 DFD of this pr ocess is given below:

User Account Info

Retrieve User Info

Enter User Id,

Enter User Id, ia

Password, Role . ’ Password, Role .
Data Entry Operator ‘»/ Login \e : Co-ordinator
“A :

Enter User Id, |

Password, Role i

Marks Entry Clerk

Enter User Id, Password, Role. _ |

Adnamstratos
3. Student information management
The Level 2 DFD of this process ‘is given below:

-_ Access User Info

Data Entry Operator- — 71
Retrieve Student Info

Display
Student Info

Student Info"
_Enter/Update/Delele ‘User Info ude

Validate/
Process
Student Info

Updaterbelete
Student Info

Scanned with CamScanner

, [ Sotware Requirements : Analysis and Specifications ag |

4. Subject information management

The Level 2 DFD of this process is given below:

Access subject i
Data entry operator ——-—-----— UIE nfo —

i
|
|

[ Display | , Retrieve subject info

\ Student info [SF
| \ / |
| a |
i Enter/Update/Delete subject info Subject info

:
aN

( Validate/ \
Process }_—____________-
subject info Update/Delete

\ . subject info
— mt

i
|
|
|
|

5. Students’ subject choice management

The Level 2 DFD of this process is given below:

“Subject info.

Retrieve subject to |

“Student info.

| |
Display

student ~
details

Data entry operator is

Display
subject
choices
|
_ . . >
| Access subject details [

|
|
|

Access student details

Retrieve student info

| ~~

| Enter/Update/Delete ‘Validate/ .

students' choices of subjects Process Update/Delete choices ;

aa — - students’ = }--— as
° subject. /

choices /

_
Students’ subject’

Student choice details

reports
generated

Scanned with CamScanner

a. ee en

am Software Engineering |

6. Marks information management

The Level 2 DED of this process is piven below:

Marks entry Display

Cork 7 . ' ,
‘ Access marks ints marks info Retrieve mark info

Marks details

marks s

Enter Update/Dolote

Student |

Update/Delete ‘Mark-sheets Se eecor

Retrieve student info Validate/ \ marks 4 n
» Process ee J
marks info , SEE
> . 1
Retrieve subject info i Retrieve students
| 7 subject choices
Student details Subject into Students’ subject
_ choice details
3.9.4 Entity Relationship Diagram
The ER diagram of the system is given below:
any -( No.ofsemesters ,
M.Tech course ;
ee ee |
« No. of subjects in each semester) |
ae a eee |
Admits }
nome) 4
_4, Credit points ;
; ne
es oe _ P
e — - | ; b Y
Student ————— a
" 7 S ee | Subject > a
<< x ™ | i Va Type
aoe ill /| \ \
Pass/Fail f \ May.
f \ . ~~ ,
f | 2
. ~ a f | | \ \
Name . Batch year ) ! \ . - a gee
7 } al ~ a ~
— / \ ¢ , ( Semester /
ya { — Code Sal } XQ Name | “ \ Te a
Enrofiment no.) !
( Credit earned } | (External marks }

‘Internal marks }
Scanned with CamScanner
| Software Requirements : Analysis and Specifications

| 403 |
3.9.5
| aaa
_~ oe 4 -
() LO Login —
| ee
i a | -
. an a Pp
Marks entry clerk a ee, ae ne a

wa

oa

Maintain Result Details

Entry/Updation of marks,
calculation of student
result, generation of

_ Reset System

Deletion of all existing

information from the

backend database Pa

} a
; mark-sheet H ar a
on : a | LJ
[---—— ~& |
. 5 > C : i
oN '
Data entry ° Maintain Subject Information Maintain User Accounts | a a
operator Add/moadify/delete Subject Add/modity/delete a Co-ordinator

‘for different semesters user accounts

= oe

a,
Maintain Student Information .

Generate Reports
Add/modify/delete 1. Student list report
student details

2. Students’ subject choices

list report”

3. Marks list report

4. Rankwise list report

|
|

; i

3 |

‘ |

Maintain Students' Subject |

Choice Information
Add/modify/delete .

Students’ Choices for

Elective Subjects

Use Case Diagram

—"
on
w
oO
tb
w
oO
=
a
o
a

This use case describes how a user logs into the Student Result Management System.

1.24

Aciors
The following actor(s) interact and participate in this use case:
Data Entry Operator, Marks Entry Clerk, Administrator, Co-ordinator.

Scanned with CamScanner

104 Software Engineering

This use case starts when the actor wishes to Login to the Student Result
Management System.
1. The system requests that the actor enter his/her name, password and role. The
role

can be any one of Data Entry Operator, Marks Entry Clerk, Co-ordinator, and
Administrator.

. The actor enters his/her name, password and role.

” .
. The system validates the entered name, password, role and logs the actor into the

to

If in the Basic Flow, the actor enters an invalid name, password and/or role, the
system dis-
plays an error message. The actor can choose to either return to the begining of
the Basic Flow

or cancel the login, at which point the use case ends.

None

1.5 Pre-Conditions

wf

All users must have a User Account (i.e., User ID, Password and Role) created for
them in the

system (through the Administrator), prior to executing the use cases.

ok

a ves
6 Post-Conditions

If the use case was successful, the actor is logged into the system. If not, the
system state is

unchanged.
_ If the actor has the role ‘Data Entry Operator’ he/s
g to the Subject Info Maintenance, Student Info Maintenance and Students’ Subject

he will have access to only screens

correspondin
Choice Info Maintenance modules of the system,
If the actor has the role ‘Marks Entrey Clerk’, he/she will have access to only
screens

Marks Info Maintenance module of the system. If the actor has the role

be able to view/print the various reports enerated by the system.

P . .
y screens
corresponding to the
‘Co-ordinator’, he/she will only

If the actor has the role ‘Administrator’ he/she will have access to onl
and Reset System feature of the system.

corresponding to User Account maintenance module

1.7 Extension Points

Scanned with CamScanner

ree rrr

caitware Roquifoments — Analysis and Specifications 105 |

J
J” phe i
A —_
|

This use case allows the actor with role ‘Data Entry Operator’ to maintain student
information.
This includes adding, changing and deleting studnet information from the system.

Data Entry ( Iperator,

243 F) of Events
997% PRacie Fie
2.3.1 &: Fioy

]. The system requests that the Data Entry Operator specify the function he/she
would
like to perform (either Add a Student, Update a Student, or Delete a Student).

2 Onee the Data Entry Operator provides the requested information, one of the sub-
flows
is executed. et es
* Ifthe Data Entry Operator selected “Add a Student”, the Add a Student sub-flow is
executed.
* Ifthe Data Entry Operator selected “Update a Student”, the Update a Student sub-
flow is executed.
* Ifthe Data Entry Operator selected “Delete a Student”, the Delete a Student sub-
flow is executed.

Student
Siudent

1. The system requests that the Data Entry Operator enter the student information.
This
includes:
ig) Name
(4) Enrollment Number-should be unique for every student

fe) Year of Enrollment

Once the Data Entry Operator provides the requested information, the student is
added

to

ty the system and an appropriate message is displayed.

16 Cretan?
a ouGEerh

4
2 tt

Update a

1. The system requests that the Data Entry Operator enters the student enrollment
number.

2. The Data Entry Operator enters the student enrollment number. The system
retrieves
and displays the student information.

3. The Data Entry Operator makes the desired changes to the student information.
This
includes any of the information specified in the Add a Student sub-flow.

4. Once the Data Entry Operator updates the necessary information, the system
updates
the student record with the updated information.

Scanned with CamScanner

406 ee Software Engineering |

1. The system requests that the Data Entry Operator enters the student enrollment
number.

2. The Data Entry Operator enters the student enrollment number. The system
retrieves
and displays the student information.
4. The system prompts the Data Entry Operator to confirm the deletion of the
student.
4. The Data Entry Operator confirms the deletion.
5. The system deletes the student record.
2.3.2 Alternative Flows
2.3.2.1 Student fot Found

If in the Update a Student or Delete a Student sub-flows, a student with the

specified
enrollment number does not exist, the system displays an error message. The Data
Entry
Operator can then enter a different enrollment number or cancel the operation, at
which point
the use case ends.

2.3.2.2 Update Cancelled

If in the Update a Student sub-flow, the Data Entry Operator decides not to update
the
student information, the update is cancelled and the Basic Flow is re-started at
the beginning.

2.3.2.3 Delete Cancelled

If in the Delete a Student sub-flow, the Data Entry Operator decides not to delete
the student
information, the delete is cancelled and the Basic Flow is re-started at the
beginning.

2.4 Special Requirements

None
2.5 Pre-Conditions

The Data Entry Operator must be logged onto the system before this use case begins.

If the use case was successful, the student information is added, updated, or
deleted from the _
system. Otherwise, the system state is unchanged.

| Maintain Subject Information _

3.1 Brie? Description

This use case allows the actor with role ‘Data Entry Operator’ to maintain subject
information.
This includes adding, changing and deleting subject information from the system.

Scanned with CamScanner

al

b.

[ Sotware Recuirements : Analysis and Specifications : 107 |

3.2 Aciors

The following actor (s) interact and participate in this use case:
Data oe Operator

Flow of Events
pwd Nes Lee with

Oo»
i

oe

-+ Lon] ain Blase

ot asic iow

©)

This use case starts when the Data Entry Operator wishes to add, change, and/or
delete sub-
ject information from the system.

1. The system requests that the Data Entry Operator specify the function he/she
would
like to perform (either Add a Subject, Update a Subject, or Delete a Subject).

"2. Once the Data Entry Operator provides the requested information, one of the
sub-flows
is executed.

e If the Data Entry Operator selected “Add a Subject”, the Add a Subject sub-flow
is
executed.

e Ifthe Data Entry Operator selected “Update a Subject”, the Update a Subject sub-
flow is executed.

e If the Data Entry Operator selected “Delete a Subject”, the Delete a Subject sub-
flow. is executed.

3.2.1.1 Add a Subject

1. The system requests that the Data Entry Operator enters the subject information.
This
includes:
(a) Name of the subject
(6) Subject Code-should be unique for every subject
(c) Semester
(ad) Subject Type-can be Core 1/Core.2/Dissertation/Elective 1/Elective 2/Lab 1/Lab
2/
Minor Project/Seminar/Term Paper.
(e) Credits.

2. Once the Data Entry Operator provides the requested information, the subject is
added
"to the system and an appropriate message is displayed.

1. The system requests that the Data Entry Operator enters the subject code.

2. The Data Entry Operator enters the subject code. The system retrieves and
displays the
subject information.

3. The Data Entry Operator makes the desired changes to the subject information.
This
includes any of the information specified in the Add a Subject sub-flow.

4. Once the Data Entry Operator updates the necessary information, the system
updates
the subject record with the updated information. ,

Scanned with CamScanner

—_ Software Engineering -.
7 ae ene = ae

ee yes
rae

108 7

3.3.1.3 Delete a Subject

yde.

ata Entry Operator enter the subject ce

The system retrieves and displays

1. The system requests that the D

2. ~The Data Entry Operator enters the subjects code.

the subject information. :

3. The system prompts the Data Entry operator to confirm the deletion of the
subject.
The Date Entry Operator confirms the deletion.

5. The system deletes the subject record.

3.3.2 Alternative Flows

3.8.2.1 Subject Not Found

If in the Update a Subject or Delete a Subject sub-flows, a subject with the

specified sub-
ject code does not exist, the system displays an error message. The Data Entry
Operator can
then enter a different subject code or cancel the operation, at which point the use
case ends.

3.3.2.2 Update Cancelled

If in the Update a Subject sub-flow, the Data Entry Operator decides not to update
the
subject information, the update is cancelled and the Basic Flow is re-started at
the beginning.

3.3.2.3 Delete Cancelled ;

If in the Delete a Subject sub-flow, the Data Entry Operator decides not to delete
the subject
information, the delete is cancelled and the Basic Flow is re-started at the
beginning.

3.4 Special Requirements

None =

3.5 Pre-Conditions
The Data Entry Operator must be logged onto the system before this use case begins.

3.6 Post-Conditions
If the use case was successful, the student information is added, updated, or
deleted from the
system. Otherwise, the system state is unchanged.

3.7 Extension Poinis

None
Ss Maintain Students’ Subject Choice Infromauun

4.1 Brief Description

This use case allows the actor with role Data Entry Operator’ to maintain
information about
the choice of different Elective subjects opted by various students. This includes
displaying the .

various available choices of Elective subjects available during a particular

semester and
updating the information about the choice of Elective Subject (s) opted by
different students of

that semester. ;

Scanned with CamScanner

| Software Requirements : Analysis and Specifications 109 |

The following actor (s) interact and participate in this use case:
Data Entry Operator

: r
ania Clay;

a 4
4,34 Pasic mivowss

This use case starts when the Data-Entry Operator wishes to update students’
Subject Choice
information from the system.

1. The system requests that the Data Entry Operator specify the semester and
enrollment
_year of students, for which the Students’ Subject Choices have to be updated.

2. Once the Data Entry Operator provides the requested information, the system
displays
the list of available choices for Elective I and Elective II subjects for that
semester and
the list of students enrolled in the given enrollment year (alongwith their
existing sub-
ject choices, if any).

3, The system requests that the Data Entry Operator specify the information
regarding
Students’ Subject Choices. this includes
(a) Student's Enrollment Number
(b) Student's Choice for Elective I subject (the corresponding subject code)

(c) Student’s Choice for Elective I subject (the corresponding subject code).
-4. Once the Data Entry Operator provides the requested information, the
information
regarding Student's Subject Choices is added/updated in the system and an
appropriate

message is displayed.
4.3.2. Alternative Flows

43.2.1 Subject Information Does Not Exist

sts in the system for the semester specified by the

ssage. The Data Entry Operator can
at which point the use case ends.

If no or incomplete subject information exi

Data Entry Operator, the system displays an error me
then enter a different semester or cancel the operation,

4.3.2.2 Student Information Does Not Exist -

s in the system for the enrollment year specified by the Data

If no student information exist:

entry Operator, the system displays an error message. The Data Entry Operator can
then
ch point the use case ends.

enter a different enrollment year or cancel the operation, at whi

4.3.2.3 Incorrect Choice Entered for Elective Elective 1] Subjects

If the subject code entered by the Data Entry Operator for Elective L/Elective II
subject does

not exist in the system, the system displays an error message. — ;

The Data Entry Operator can then enter the correct subject code or cancel the
operation,

at which ‘point the use case ends.

- 4,3.2.4 Update Cancelled .

If in the Basic Flow, the Data Entry Operator decides not to update the subject
information,
the update is cancelled and the Basic Flow is re-started at the beginning.

Scanned with CamScanner

110 ee Software Engineering

None

A5 Dra-Cawniian-n
“2.0 5 re-Conditions

The Data Entry Operator must. be logged onto the system before this use case
begins.

>

AGS Daact.- cliktrane

3.9 SOStelOondaiiion

Ifthe use case was successful, information about students’ choices for opting
different Elective
Subjects is added/updated in the system. Otherwise, the system state is unchanged.

4.7 Extension Points

None
fb Maintain Result Details

5.1 Brief Description

This use case allows the actor with role ‘Marks Entry Clerk’ to maintain subject-
wise marks
information of each student, in different semesters. This includes adding, changing
and delet-
ing marks information from the system.

5.2 Actors
The following actor (s) interact and participate in this use case:
Maks Entry Clerk. °

5.3 Flow of Events

5.3.1 Basic Flow
This use case starts when the Marks Entry Clerk wishes to add, change, and/or
delete marks
information from the system.
1. The system requests that the Marks Entry Clerk specify the function he/she would
like
to perform (either Add Marks, Update Marks, Delete Marks, or Generate Mark-sheet).
2. Once the Marks Entry Clerk provides the requested information, one of the sub-
flows is
executed.
e Ifthe Marks Entry Clerk selected “Add Marks”, the Add Marks sub-flow is executed.
° Ifthe Marks Entry Clerk selected-““Update Marks”, the Update Marks sub-flow is
executed. a
e Ifthe Marks Entry Clerk selected “Delete Marks”, the Delete Marks sub-flow is
executed. _
e Ifthe Marks Entry Clerk selected “Generate Mark-sheet”, the Generate Mark-sheet
sub-flow is executed.

5.3.1.1 Add Marks Record

1. The system requests that the Marks Entry Clerk enters the marks information.
This
includes: :

PROTIRT ye essen eee ecatemereay sore

Scanned with CamScanner

-_

[Sottare Requirement : Analysis and Specifications 1114

(a) Selecting a semester

(b) Selecting a subject code

(c) Selecting the student enrollment number

(d) pide the internal/external marks for that semester, subject code and enrollment
number,

2. Once the Marks Entry Clerk provides the requested information, the system saves
the
marks and an appropriate message is displayed.
5.3.1.2 Update Marks Record

1. The system requests the Marks Entry Clerk to make following entries:
(a) Selecting the semester

(6) Selecting the subject code for which marks have to be updated
(c) Selecting the student enrollment number.

2. Once the Marks Entry Clerk provides the requested information, the system
retrieve
and displays the corresponding marks details. ;

The Marks Entry Clerk makes the desired changes to the internal/external marks
details.
The system updates the marks record with the changed information.

m=

. 5.3.1.3 Delete Marks Record

1. The system requests the Marks Entry Clerk to make following entries:
(a) Selecting the semester :

(6) Selecting the subject code for which marks have to be updated

(c) Selecting the student enrollment number.

-9. Once the Marks Entry Clerk provides the requested information, the system
retrievs
and displays the corresponding marks record from the database. :

3. The system verifies if the Marks Entry Clerk wishes to proceed with the deletion
of the
record. Upon confirmation, the record is deleted from the system.

5.3.1.4 Compuie Result

1. Once all the marks are added to the database, the result is computed for each
student. .

2. Ifthe student has scored more than 50% in a subject, the associated credit
points are -
allotted to that student.
3. The average percentage marks are claculated for the student and his/her division
is also
derived based ‘on the percentage.

5.3.1.5 Generate Mark-Sheet

1. The system requests that the Marks Entry Clerk specify the Enrollment Number of
the
student and the semester for which mark-sheet is to be generated.

2. Once the Marks Entry Clerk provides the requested information, the system
generates
a printable mark-sheet for the specified student and displays it. a

3. The Marks Entry Clerk can then issue a print request for the mark-sheet to be
printed.- -~

Scanned with CamScanner

Sottware Enginiteterinies

wnt
ont
[ob

Hin the Update Marks, Delete Marks or Generate Mark-sheet sub-flows, @ record

gr
with the specified information does not exist, the svetem displays an error
message. I'he Marks
Entry Clerk can then enter different information for retrieving the record or
cancel the opera.

tion, at which point the use case ends

ifin the Update Marks sub-flow, the Marks Entry Clerk decides not to update the
marks, the update is cancelled and the Basie Flow is re-started at the beginning.

rane 2

BO? SF

Ifin the Delete Marks sub-flow, the Marks Entry Clerk decides not to delete the
marks,
the delete is cancelled and the Basic Flow is re-started at the beginning,

5.4 Special Requirements

None

5.5 Pre-Conditions

The Marks Entry Clerk must be logged onto the system before this use case begins.

§.6 Post-Conditions

If the wse case was successful, the marks information is added, updated, or deleted
from the

system. Otherwise, the system state is unchanged.

5.7 Extension Points

a
O
ia)
poe
ie]
4
ist)
~-
ia)
me]
i)
U
o
st
2)
6.1 Brief Description
This use case allows the actor with role ‘Co-ordinator’ to generate various
reports, The following
reports can be generated:
ig) Student List Report
(b) Students’ Subject Choices List Report
ic) Marks List Report
fd) Rank-wise List Report
6.2 Actors

The following actor(s) interact and participate in this use case:

Co-ordinator

Scanned with CamScanner

aaftware Requirements | Analysis and Specifications ad

suse case starts when the Co-ordinator wishes to generale report

‘his }

1, The system requests the Co-ordinator specify Lhe report levehe woLG oe yews
2 Onee the Co-ordinator provides the requested information, one of tae sue fi
executed:

e If the Co-ordinator ‘selected “Student Liat Report”, the Generate Student

List Report sub-flow is executed.

e If the Co-ordinator selected “Students’ Subject Choices List Report”, the

Generate
Students’ Subject Choices List Report sub-flow is executed

e If the Co-ordinator selected “Marks List Report”, the Generate Marks List Report
sub-flow is executed.

e Ifthe Co-ordinator selected “Rank-wise List Report”, the Generate Rank-wise List
Report sub-flow is executed.

6.3.1.1 Generate Student List Report

1. The system requests that the Co-ordinator provide the enrollment year for which
the
Student List report is to be generated.

2. Once the Co-ordinator provides the requested infromation, the system generates
the Student List report, containing the list of students enrolled tn the given
year.

3. The Co-ordinator can then issue a print request for the report to be printed

foo)
&
a

.2 Generate Student's Subject Choices List Rez

1. The system requests that the Co-ordinator provides the enrollment year and the
semester
for which the Students’ Subject Choices List report is to be generated.

Once the Co-ordinator provides the requested information, the system generates the
Students’ subject Choices List report, containing the choices for Elective I and
Elective
Il subjects, opted by the students of the given enrollment vear and semester.

3. The Co-ordinator can then issue a print request for the report to be printed.
6.3.1.3 Generate Marks List Report

1. The system requests that the Co-ordinator provides the enrollment year and the
semester
for which the Marks List report is to be generated.

2. Once the Co-ordinator provides the requested information, the system generates
the
‘Marks List report, containing the marks details of various students in all the
subjects
for the given enrollment year and semester.

3. The Co-ordinator can then i issue a print rages for the report to be printed.
6.3.1. 4 Generate Rank-wise List Report

1. The system requests that the Co-ordinator provide the enrollment year and the
semester
for which the Rank- wise List report is to be generated.

Scanned with CamScanner

Jt Maintain User Accounts

unchanged.

—— a ye

114 . Software Engineering

2. Once the Co-ordinator provides the requested information, the system ge

Rank-wise List report, containing the percentage wise and rank-wise list of al]
students
(alongwith their total marks and division) for the given enrollment year and
semester.

3. The Co-ordinator can then issue a print request for the report to be printed.

nerates the

6.3.2 Alternative Flows

6.3.2.1 Student Not Found

If no student information exists in the system for the enrollment year spe
Co-ordinator, the system displays an error message.
a different enrollment year or cancel the operation, at

cified by the
The Co-ordinator can then enter
which point the use case ends.

6.4 Special Requirements

None

6.5 Pre-Conditions
‘The Co-ordinator must be logged onto the system before this use case begins.
6.6. Post-Conditions .

If the use case was successful, the desired report is generated. Otherwise, the
system state is

6.7 Extension Points

None.

_ 7.1 Brief Description

This use case allows the actor with role

‘Administrator to maintain User Account. This includes

adding, changing and deleting user ac

count information from the system.

7.2 Actors - |

The following actor (s) interact and Participate in this use case: -
Administrator. :

7.3 Flow of Events

7.3.1 Basic Flow , , .

This use case starts when the Administrator wishes to add, change, and/or ‘delete
use account
information from the system. :

1. The system requests that the Administrator Ss

_ perform (either Add a User Account, Update a

.| 2. Once the Administrator provides the reques

~ executed. °

pecify the function he/she would like to

User Account, or Delete a User Account).
ted information, one of the sub-flows is

OR NESTE III es +

Joe

Scanned with CamScanner

_—D

[sotware Requirements : Analysis and Specifications

————— ae

116 |

e Ifthe Administrator selected “Add a User Account”,

; the Add a User Account sub-

flow is executed.

e Ifthe Administrator selected “Update a User Account”, the Update a User Accouat
sub-flow is executed.

e Ifthe Administrator selected “Delete a User Account”, the Delete a User Account
sub-flow is executed.

73.4.1 Add a User Account

1. The system requests that the Administrator enters the user information. This
includes:
(a) User Name.
(6) User ID-should be unique for each user account
(c) Password:
(d) Role

2. Once the Administrator provides the requested information, the user account
information
is added to the system and an appropriate message is displayed.

7.3.1.2 Update a User Account

1. The system requests that the Administrator enters the User ID.

2. The Administrator enters the User ID. The system retrieves and displays the user
account
information. | ~ ,

3. The Adiministrator makes the desired changes to the user account information.
This
includes any of the information specified in the Add a User Account sub-flow.

4, Once the Administrator updates the necessary information, the system updates the
user account record with the updated information.

7.3.1.3 Delete a User Account

1. The system requests that the Administrator enters the-User ID.

2. The Administrator enters the User ID. The system retrieves and displays the user
account
information.

The system prompts the Administrator to confirm the deletion of the user account.
The Administrator confirms the deletion.
The system deletes the user account record.
mm Oo

ot

' 7.3.2 Alternative Flows

7.3.2.1 User Not Found , -

Ifin the Update a User Account or Delete a User Account sub-flows, a user account
with
the specified User ID does not exist, the system displays an error message. The
Administrator
can then enter a different User ID or cancel the operation, at which point the use
case ends.

7.3.2.2 Update Cancelled

If in the Update a User Account sub-flow, the Administrator decides not to update
the user account information, the update is cancelled and the Basic Flow is re-
started at the
beginning.

Scanned with CamScanner

~¥

7 : - Software Engineering
116 . penn)”, |

7.3.2.8 Delete Cancelled

If in the Delete a User Account sub-flow, the Administrator decides not to delete
the
user account information, the delete is cancelled and the Basic Flow is re-started
at the
beginning.

7.4 Special Requirements

None

7.5 Pre-Conditions

The Administrator must be logged onto the system before this use case begins.
7.6 Post-Conditions

If the use case was successful, the user account information is added, updated, or
deleted from

the system.. Otherwise, the system state is unchanged.

7.7 Extension Points

None

J 8. Reset System

- 8.4 Special Requ

8.1 Brief Description

‘This Use case allows the actor with role ‘Administrator’ ‘to reset the system by
deleting all
existing information from the system. -

8.2 Actors: ~

_ The following-actor (s) interact and participate in this use case:

Adiministrator

8.3 Flow of Events

8.3.1 Basic Flow

This use case starts when the Administrator wishes to reset the system: - .

1. ‘The system requests the Administrator to confirm if he/she wants to delete all
the exist-
ing information from the system. : :

2. Once the Administrator provides confirmation, the system deletes all the
existing infor-
mation from the backend database and displays an appropriate message.
8.3.2 Alternative Flows —

~ 8.3.2.1 Reset Cancelled -

If in the Basic Flow, the Administrator decides not to delete the entire existing
information
the reset is cancelled and the use case ends. = Sr ‘
irements. » 2 ~

; La,
None - i

Scanned with CamScanner

8.5 pre-Conditio

The

ns

8.6 Bost-Conditions

If the use case was successful, all the existing information is deleted from the }

_ |-Software Requirements : Analysis and Specifications

-. pase of the system. Otherwise, the system state is unchanged.

3.7 Extension Points

None .

3.9.7 SRS Document

|» Administrator must be logged onto the system before this.use case beging
ry . 5 a

ackend data-

4
1.2
1.3
14
1.5

2.2
2.3.
247
2.5
2.6

1 Introduction

Purpose

Scope

Definitions, Acronyms, and Abbreviations

References

2.1.3
2.1.4

2.1.5 —

2.1.6

2.1.7

2.1.8

_ Overview
2 Overall Description

2.1. Product Perspective

211
Pee

System Interfaces

User Interfaces

Hardware Interfaces

Software Interfaces
Communications Interfaces
Memory Constraints
Operations

Site Adaptation Requirements _

Product Functions

User Characteristics
Constraints _
Assumptions and Dependencies
Apportioning of Requirements

3.1.1

3 Specific Requirements
3.1 External Interface Requirements

User Interfaces
Login Screen:

* Subject Info Parameters Screen:

. , Subject Information Screen: -

Student Info Parameters Screen:

Student Information Screen:

Students’ Subject Choice Parameteis Screen:

Students’ Subject Choice Information Screen:

(Contd.)...

—er

Scanned with CamScanner

118

Software Engineering

3.3
3.4
3.5

3.6
3.7

3.2
8.2.1

Marks Entry. Paraineters Screen:

Marks Entry Screen:
Mark-sheet Parameters Screen:

i]

. Students List Report Parameters Screen:

3.1.2

3.1.3 -
3.1.4

‘Marks List Report Parameters Screen:

Rank-wise. List Report Parameters Screen:

_ Students’ Subject Choices List st Report Patameters Screen: '

Hardware Interfaces a
Software Interfaces -

_ Communications Interfaces

‘Software Product Features

3.2.2

3.2.3

3.2.4
B25

Subject: Information Maintenance

Validity Checks

Sequencing Information

Error Handling/ Response to Abnormal situations

Student Information Maintenance
Validity’Checks ‘ .

Sequencing Information

Error Handling / Response to Abnormal sitdations

Marks Info Maintenance , yt)
, Validity Checks -

Sequencing Information

Error Handling/ Response to Abnormal us

Mark sheet Generation

Report Generation

Student List Reports

Students’ Subject Choices List Reports

Semester-wise Mark lists

Rank-wise List Report

Performance Requirements

Design Constraints
Software System Attributes

“3.5.1

Security

3.5.2 Maintainability _
3.5.3 Portability

Logical Database Requirements

Other Requirements .

1 Introduction

This document aims at defi

Management System, Effort:

ning the overall software requirements for ‘Student Result.

s have been made to define the requirements exhaustively and

Scanned with CamScanner |

é |
‘software Requirements : Analysis and Specifications 419

accurately. The final product

will be having only features/functionaliti ‘oned in this

document and assumptions for § only ures/functionalities mentioned in this

any additional functionality/feature should not be made b

a ; y any

of the arene involved in developing/testing/implementing/using this product. In

case it is

require ‘ ave some additional features, a formal change request will need to be
raised and
subsequent y a new release of this document and/or product will be produced. 7 .

4.1 Purpose

This specification document describes the capabilities that will be provided by the
software
~ application ‘Studer:t Result Management System’. It also states the various
required constraints
_by which the system will abide. The intended audience for this document.are the
development
_ team, testing team and end users of the product. —

7.2. Scope

The software product ‘Student Result Management System’ will be an MIS and
Reporting
application that will be used for result preparation and management of M. Tech.
Program of a
University. The application will manage the information about various students
enrolled in
this course in different years, the subjects offered during different semesters of
the course, the -
students’ choices for opting different subjects, and the marks obtained by various
students in
various subjects in different semesters. Printable reports regarding list of
students, marks
obtained by all students in a particular semester and’ performance of students
(rank-wise,,.
percentage-wise, pass/fail, division-wise.) will be generated: The system will also
generate
printable mark-sheets for individual students. a
The application will greatly simplify and speed up the result preparation and
management
process.

1.3. Definitions, Acronyms, and Abbreviations

Following abbreviations have been used throughout this document:
_M.Tech: Master of Technology
IT: Information Technology
DBA: Database Administrator

1.4 References
, (i) University website: For information about course structure of M.Tech. Program
(ii) IEEE Recommended Practice for Software Requirements Specifications-IEEE Std
830-1993 . :

7.5 Overview

~ The rest of this SRS document describes the various system requirements,
interfaces, features
and functionalities in detail.

2 Overall Description

M.Tech. Program is a 4-semester course. The students are offered 4 subjects

(theory) and 2
Labs (practical) during first, second and third semesters. Students also have to
submit a term
paper/minor project in 2nd and 3rd semesters. The fourth semester consists of a
seminar and

ee ate |
Scanned with CamScanner
120 ~ . Software Engineering

disseratation. Each subject/lab/term paper/seminar/dissertation has credits

associated with it,
When a student secures pass marks in a paper he/she also earns all the credit (s)
assigned to
that paper.

The ‘Student Result Management, System’. will have capability to maintain

information about-

students enrolled in the course, the subjects offered to students during different
semesters,
the students’ choices for opting different Elective subjects (out of the available
ones) and the
marks obtained by students in different subjects in various semesters. The software
will also
generate summary reports regarding student information, semester-wise mark lists
and per-
formance reports. Printable mark-sheets of individual students will also be
generated by the
application.

2.1 Product Perspective : .

The application will be a windows-based, self-contained and independent software pr
oduct.

_ Front End Client °

Application (with data -

entry/update/delete/ | Backend
view and reporting t : Database
facility) :

2.1.1 System Interfaces

None

2.1.2 User Interfaces

The application will have a user-friendly and menu baced interface. Following
screens will be
' provided: , So

(t) A Login screen for entering the username, password and role (Administrator,
Data

Entry Operator, Marks Entry Clerk, Co-ordinator) will be provided. Access to

different
screens will be based upon the role of the user. .

(it) There will be a screen for capturing and displaying information regarding what
all
subjects are offered during which semester, how many credit points are assigned to

- that subject and whether the subject is an elective, a core paper, a lab paper, a
term
paper or a dissertation.
(iii) There will be a screen for capturing and displaying information regarding
various.
students enrolled for the course in different years. .
(iv) There will be a screen for capturing and displaying’ information regarding
which
student is currently enrolled in which semester and what all-elective subjects
he/she ©
has opted.
(v) There will be a screen that will-capture inform
scored how many marks (internal + external evalu

semester). Credits in each subject will

obtained in that subject. ,

ation regarding which student has

ation) in each subject Gn a particular
be calculated depending upon the marks

Scanned with CamScanner

DAME RES

cyan year
; ; |
SNe [ Sotware Requirements : Analysis and Specifications 121 |

(vi) There will be a screen for capturing and displaying information regarding
which all
user accounts exist in the system, thus showing who all can access the system.
The following reports will be generated:

“(ty Students’ List Report: Printable reports will be generated to show the Ene of
students
enrolled in a particular batch year.

(ii) Students’ Subject Choices List Report: For Ist, IInd and IIIrd semester, there
will be
printable reports showing the different elective subjects opted by various students
' (enrolled in a particular batch year) of the corresponding semester.

(tit) Marks List Report: For each semester there will be a printable report showing
the
subject-wise marks details for all students of that semester.

(iv) Rank-wise List Report: For each semester there will be a printable report
showing
the percentage-wise and rank-wise list of students alongwith the division secured.

(v) Mark-sheet: For each student of each semester,a printable mark-sheet will be

generated, showing the subject-wise marks details, Total marks, total credits,
Percentage, Pass/Fail status for that student.

2.1.3 Hardware Interfaces

(i) Screen resolution of at least 800 x 600-required for proper and complete
viewing of
screens. Higher resolution would not be a problem.

(ii) Support for printer (dot-matrix/deskJ et/inkjet etc.—any will do)-that i is,
appropriate

drivers are installed and printer connected printer will be required for printing
of
reports and mark-sheets.

(iit) Standalone system or network based—not a concern, as it will be possible to

run 1 the
application on any of these.

2 1.4 Software Interfaces

(i) Any windows-based operating system (Windows 95/98/2000/KP/NT)

_ (it) MS Access 2000 as the DBMS—for database. Future release of the application
will
_aim at upgrading to Ora¢le 8i as the DBMS.

(ii) Crystal Reports 8—for generating and viewing reports.

(iv) Visual Basic 6—for coding/developing the software.

Software mentioned in pts. (iii) and (iv) above, will be required only for
development of

the application. The final application will be packaged as an independent setup

program that
will be delivered to the client (University i in | this case).

2.1.5 Communications Interfaces

. None
2.1.6 Memory Constraints: .

et r i ra tion.
At least 64 MB RAM and 2 GB space on hard disk will be required for running the
applicati

We nein ders

Scanned with CamScanner

we
\

422 Software Engineering

No

1.7 Operation

iva)

This product release will not cover any automated housekeeping aspects of the
database. The
DBA at the client site (i.e., University) will be responsible for manually deleting
old/non-required
data. Database backup and.recovery will also have to be handled by the DBA.

However, the system will provide a ‘RESET SYSTEM’ function that will delete (upon
confirmation from the Administrator) all the existing information from the
database.

2.1.8 Site Adaptation Requirements

The terminals at client site will have to su

pport the hardware and software interfaces specified

in above sections.

2.2. Product Functions

The system will allow access only to authorised users with specific roles
(Administrator, Data

Entry Operator, Marks Entry Clerk and Co-ordinator). Depending upon the user’s
role, he/she
will be able to access only specific modules of the system.

A summary of the major functions that the software will perform:

(i) A Login facility for enabling only authorised access to the system.

(iz) User (with role Data Entry Operator) will be able to add/modify/delete
information
about different students that are enrolled for the course in different years.

(tii) User (with role Data Entry Operator) will be able to add/modify/delete
information
' about different subjects that are offered in a particular semester. The semester-
wise

list of subjects along with their credit points and type (i.e.,
elective/core/lab/term
paper/dissertation) will also be displayed. ;

(tv) User (with role Data Entry Operator) will be abl

about the Elective subjects opted by different students in different semesters.

(v) User (with role Marks Entry Clerk) will be able to add/modify/delete
information
regarding marks obtained by different students in different semesters.
(vi) User (with role Marks Entry Clerk) will also be able to print mark-

(vit) User (with role Co-ordinator) will be able to

in section 2.1.2 above).

(viii) User (with role Administrator) will be able to ‘Reset’ the system—leading to
deletion
of all existing information from the backend database.

(ix) User (with role Administrator) will be able to create/mo

accounts.

e to add/modify/delete information

sheets of students.
generate Printable reports (as mentioned

dify/delete new/existing user

2.3° User. Characieristics

° Educational level: At least graduate should be comfortable with English language.

° Experience: Should be well versed/informed about the course structure of M. Tech.

program of University. Entry of marks or their modification can be done only by
user
who is authorised for this job by the result preparation committee of University.

Scanned with CamScanner

. [sotwaro Requirement : Analysis and Specifications 7 —_ CO 123

Technical expertise: Should be comfortable

computer. -

using general-purpose applications on a

24 Consirainis

(i) Since the DBMS being used is MS Access 2000, which is not
it will not be able to store a very huge

(ii) Due to limited features of DBMS being used performance tuning features will
not be

applied to the queries and thus the system may-become slow with the increase in
number of records being stored.

a very powerlul DBMS,

number of records.

(iii) Due to limited features of DBMS being used, database auditing will also not
be
provided.

(iv) Users at University will have to implement a security policy to safeguard the
marks-

related information from being modified by unauthorised users (by means of gaining
access to the Raementd database).

:
4
|

2.5 Assumptions and Dependencies

(i) The number of subjects to be taken up by a student in each semester does not
change.
(it) The subject types (i.e., elective, core, lab, term paper and dissertation) do
not change.
(iit) The number of semesters in the M. Tech. Program does not change.

2.6 Apportioning of Requirements

Not Required.

3 Specific Requiremenis

This section contains the software requirements to a level of detail sufficient to

enable design-
7 ers to design the system, and testers to test that system.

3.7 External Interface Requiremenis

. 3.1.1 User Interfaces

_ The following screens will be provided: .

- Login screen:
This will be the first screen that will be displayed. It will altowru user to
access different screens
‘based upon.the user’s role. Various fields available on this screen will be

(i) User ID: Alphanumeric of length upto 10 characters a

(ii) Password: Alphanumeric of length upto 8 a acters

(vii) Role: Will have the following values:
Administrator, Marks Entry Clerk, Co-ordinator, Data Entry Operator
Subject info parameters screen:

This screen will be accessible only to user with role Administrator. It

enter the semester number for which the user wants to access the subje

will allow the user to

ct information.

ee

Scanned with CamScanner

124 oo BO _ — Software. Engineeting

Subject information screen:

This screen will be accessible only to user with role Administrator. Tt will allow
user to add/
modify/delete information about. new/existing subject (s) for the semester that was
selected in
the ‘Subject Info Parameters’ screen, The list of available subjects for that
semester, will also
be displayed. Various fields available on this screen will be:
(i) Subject Code; of the format I'T-### (# represents a digit)
(i) Subject Name: Alphanumeric, of length upto 50 characters
Git) Category/ Type: Will have any of the following values:-
Elective 1/Elective 2/Core/Lab/Term paper/Seminar/Dissertation
(iv) Credits: Numeric, will have any value from 0 to 20.
Student info parameters screen:
This screen will be accessible only to user with role Administrator. It will allow
the user to
enter the Batch Year for which the user wants to access the student information. .
Student information screen:
This screen will be accessible only to user role Administrator. It will allow the
user to add/
modify/delete information about new/existing student (s) for a particular Batch
Year. Batch
Year-wise list of students will also be displayed. Various fields available on
these screens will
be: . ; ,
(i) Student Enrollment No: of the format ###/M.Tech. (ITVYYYY (# represents a digit
|
and YYYY represents the batch year).
(ii) Student Name: will have only alphabetic letters and length upto 40.
characters.

(iii) Batch Year: of the format YYYY (representing the year in which the student
enrolled
for the course).

Students’ subject choice parameters screen:

This screen will be accessible only to user with role Administrator. It will allow
the user to
enter the Batch Year and the semester number for which the user wants to access the
students’

subject choice information.

Students’ subject choice information screen:

This screen will be accessible only to user with rele Administrator, It will allow
user to add/
lete students’ choices for elective subjects of the semester and batch year
selected in

modify/de atch ye: |

-arameters” screen. For the selected semester it will display the list

“Students’ Subject Choice mes ispla

of available choices for Elective I and for Elective I. The screen will display the
list of students
enrolled during the selected bate

h year and currently studying in the selected semester and

able to view/add/modily/delete the subject choices for each student in the list.
. ? 4 .

the user will be

Marks entry parameters screen: | . .
only to user with role Marks Entry Clerk. It will allow the user to

This screen will be accessible ies

rand the Subject for which the user wants to access
4 a , 2 A

enter the Batch Year, the semester numbe

the marks information. .

Scanned with CamScanner

hm
ol

~ Fgottware Requirements : Analysis and Specifications —

Marks entry screen:

This screen will be accessible only to user with role Marks Entry Clerk. It will
all
, add/modify/delete information about marks obtained in the ices ae oe “
d -gtudents of that.semester who were enrolled in the Batch Year lesen She Ma
fteren
parameters’ Screen. The screen will display the list of sindents edrolled du ing te
eis
“patch year and currently studying the selected subject in the estentad omester, '
j ee
_ will be able to view/add/modify/delete the marks for each student in the list. er
and anes
Various fields available on this screens will be: _
(i) Student Enrollment No.: will display the enrollment numbers of all students of
tt
selected Batch Year studying the selected subject in the selected pacreben ; .
(ii) Student Name: will display the name of the student .
(iii) Internal Marks: between 0 and 40
(iv) External Marks: between 0 and 60
(v) Total Marks: sum of Internal Marks and External Marks

Mark-sheet parameters screen:

y to user with role Marks Entry Clerk. It will allow the user to

' This screen will be accessible onl

nd the semester number of the student for whom the user

> enter the Enrollment Number a

> wants to view/print the mark-sheet.

‘Students list report parameters screen:

“This screen will be accessible only to user with role Co-ordinator. It will allow
the user to enter

- the Batch Year for which the user wants to view/print the students list report.

‘Marks list report parameters screen:

1 be accessible only to user with role Co-ordinator. It will allow the user to
enter

This screen wil

which the user wants to view/print the marks list report.

the Batch. Year and the semester for

meters screen: 7 -
ih-role‘Co-ordinator. It will allow the user to enter
ser wants to view/print the rank-wise list

Rank-wise list report para

This screen will be accessible 0
the Batch Year and the semes
report.. a

Students’ subject choices list rep

_ This screen will be accessible only to user with role Co-ordinator.
the Batch Year and the semester for which the user wants to view/prin

choices list report.

nly to user Wi
ter for which the u

ort parameters screen:

It will allow the user to enter

t the students’ subject

3.1.2 Hardware Interfaces

As stated in Section 2.1.3. .

3.1.3 Software Interfaces

As stated in section 2.1.4.

———

3.1.4 “Communications Interfaces

None

Scanned with CamScanner

| 126 Software Engineering

VAG

en 4 Sp hieet Intrers
OF OUMETT IN iP

Description

The system will maintain information about various subjects being offered during
different
semesters of the course, The following information would be maintained for each
subject:
Subject code, Subject name, Subject Type (Core/Elective 1/Elective 2/Lab 1/Lab
2/Term Paper/
Minor Project/Dissertation/Seminar), Semester, Credits.

The system will allow creation/modification/deletion of new/existing subjects and

also have
the ability to list all the available subjects for a particular semester.

Validity checks

(t) Only user with role Data Entry Operator will be authorised to access the
Subject
Information Maintenance module.

(i) Ist, IInd and IIIrd semesters will have 2 core papers, 2 Elective papers, 2 Lab
papers
and 1 term paper/Minor Project.

(att) Ist, Und and ILIrd semesters will have 3 choices (subjects) each of type
Elective 1 and
of type Elective 2.

(tv) IVth semester will have only 1 dissertation and 1 seminar.

(v} No two semesters will have the same subject i.e., A subject will be offered
only ina
particular semester.

(vr) Subject code will be unique for every subject.

(vir) subject code cannot be blank.
‘vrit) Subject name cannot be blank.
(1x) Credits cannot be blank.
(x) Credits can have value only between 0 and 20.
(xt) Subject Type cannot be blank.
(xii) Semester cannot be blank.
Sequencing information
Subject info for a particular semester will have to be entered in the system before
any student/
marks information for that semester can be entered.
Error handling/response to abnormal situations
If any of the above validations/sequencing flow does not hold true, appropriate
error messages
will be prompted to the user for doing the needful.

3.2.2 Student Information Maintenance

a.m

Description bjects opted by various

. Tent Blective 8 cts 0

The system will maintain information about choice of different pect nk acien would

students of different enrollment years in different semesters. lhe following :

be maintained:

Scanned with CamScanner

1 27 |

Software Requirements : Analysis and Specifications

’s Choice for Elective 1 subject Stu-

Student Enrollment number, Semester, Student's

dent's Choice for Elective 2 subject.

The system will allow creation/modific

“have the ability to list all the students enrolled in a particular year

ation/deletion of new/existing students and also

Validity checks
(i) Only user with role Data Entry Operator will be authorised to access the
Student

Information Maintenance module.

(i?) Every student will have a unique Enrollment Number.

7 (iii) Enrollment Number cannot be blank.

(iv) Student name cannot be blank.
(v) Enrollment Year cannot be blank.

Sequencing information
Student Info for a particular student will have to be entered in the system before
any marks

info can be entered for that student.

Error handling/response to abnormal situations

If any.of the above validations/sequencing flow does not hold true, appropriate
error messages

will be prompted to the user for doing the needful.

3.2.3 Students’ Subject Choices Information Maintenance -

Description
The system will maintain information about choice of different Elective subjects
opted by vari-

ous students of different enrollment years in different semesters. The following

information

would be maintained:
Student Enrollment number, Semester, Student’s Choice for Elective 1 subject, Stu-

dent’s Choice for Elective 2 subject.

The system will allow creation/modification/deletion of students’ subject choices
and
also have the ability to list all the available students’ subject choices for a
particular semester.

Validity checks
(¢) Only user with role Data Entry Operator will be authorised to access the
Students’
Subject Choices Information Maintenance module.
(ii) The subject choice for Elective 1 and Elective 2 can be made only from the
list of

available choices for that semester.

Sequencing information

Students’ Subject Choices Info for a particular student can be entered in the
system only after

Subject Info has been entered in the system for the given semester and the Student
Inlo ©

that student has been entered in the system. . ; in the”

Students’ Subject Choices Info for a particular student will have to be entered 1

system before any marks info can be entered for that student in the given semester.

Scanned with CamScanner

nt —— Software Engineer
128 7 ooo

Error handling/response to abnormal situations

’ i ; ruc é ‘opriate error messag
If any of the above validations/sequencing flow does not hold true approprié gi

will be prompted to the user for doing the needful.

3.2.4 Marks Information Maintenance

Description

The system will maintain information about marks obtained by various students of
different

enrollment years in different semesters. The following information would be

maintained:
Student Enrollment Number, Semester, Subject Code, Internal Marks, External Marks,

Total Marks, and Credits.

The system will allow creation/modification/deletion of marks information and also

have
the ability to list all the available marks information for all students for a
particular subject in
the given semester,

Validity checks
(t) Only user with role Marks Entry Clerk will be authorised to access the Marks
Infor.
mation Maintenance module.
(ii) Internal Marks for any subject cannot be less than 0 and greater than 40.
; (iii) External marks for any subject cannot be less than 0 and greater than 60.

(tv) Total marks in any subject will be calculated as: Internal Marks in that
subject +
External Marks in that subject. .

(v) If the total Marks in a subject are > = 50, all the credit points associated
with that
subject will be given to the student, else the credit points earned by the student
will
be 0 for that subject.

Sequencing information

Marks Info for a particular student can be entered in the system only after Subject
Info has
been entered in the system for the given semester, the Student Info for that
student has been
entered in the system, and the Students’ Subject Choice Info has been entered in
the system
for that student in the given semester. .

Marks imo for a particular student will have to be entered in the system before
that
student’s mark-sheet can be generated.

Error handling/response to abnormal situations

If any of the above validations/sequencing flow does not hold true appropriate
error messages
will be prompted to the user for doing the needful.

3.2.5 Mark-sheeit Generation

Description

The system will generate mark-sheet for every student in different semesters.

Scanned with CamScanner

Software Requirements : Analysis and Specifications 499 :
Mark-sheet will have the following format:

Name of the University

Name of Program
Semester <no.>

Mark-sheet
Student Enrollment No. Student Name:
S.No. Subject Internal External Total Pass/Fail Credits
Marks Marks Marks Earned
(Out of 40) (Out of 60) (Int. + Ext.)
1.
2.
3.
Ay
5.
6. . .
-. Marks Grand Total: -/600 Total Credits:
Result: (Pass/Fail). — -.
Date: _ Signature of Controller of Examinations

There will be a ‘Print’ icon at the top of mark-sheet for printing the mark-sheet.

Validity checks
_ (i) Only user with role Marks Entry Clerk will be authorised to access the Mark-
sheet
Generation module. . :

Sequencing information
Marks-sheet for a particular student can be generated by the system only after
Subject info
has been entered in the system for the given semester, the Student Info for that
student has
been entered in the system, the Students’ Subject Choice Info has been entered in
the system
for that student in the given semester, and the Marks Info has been entered for
that student

for the given semester.

Error handling/response to abnormal situations —

If any of the above validations/sequencing flow does, not hold true appropriate
error messa
will be prompted to the user for doing the needful.

ges

; 3.2.6 Report Generation

Student list reports

. i a h
For each year a report will be generated containing the list of students enrolled
in that batch ,

year.

eT
Scanned with CamScanner
130

Sollware Engineering |
t ‘ +

assassin _— ie ae
Name of University
Name of the Program
List of students entrolled in Year XXNN
Sener en ——,
S.No, Student Enrollment Number Student Name
1.
)
——]
——_—]

Students’ subject choices list reports

For each batch year are

port will be generated containing the li

for Elective subject:

S in the selected semester.

contain the names of elective subje
contain the topic/subject area of di

st of students and their choices

For Ist, Ind and Ilrd semesters the li
cts opted by each student. For IVth semester the |i
ssertation for each student,

Report format ( for Ist, IInd and Wird Seme

st will
st will

sters):

Name of University
Name of the Program

S.No. Student Enrollment Number Student Name Elective 1 Elective 2

Code | Name | Code Name
2. on

Report format (for IVth Semester):

i Name of University

Name of the Program

S.No. Student Enrollment Number Student Name Topic/Subject Area of

Dissertation

Scanned with CamScanner

ee

‘| software Requirements : Analysis and Specifications 131 |

Semester-wise mark lists

For each semester a mark list will be generated that will have the total marks
(internal +
external) of all students (enrolled in the selected Batch Year) of that semester in
all subjects,

Report format:
Name of University
Name of the Program

S.No. | Enrollment | Subject 1 | Subject 2 | Subject 3} Subject 4 | Subject 5 |

Subject 6
Number Total Total Total Total Total Total
Marks Marks Marks Marks Marks Marks

Rank-wise list report

~-'This ‘report will-be generated for each semester of every Batch. Year. It-will
show the Grand
“Total marks, Percentage, Rank and Division secured of all students of that
semester. The

report will be sorted in increasing order of Percentage/Rank.

Report format:
Name of University
Name of the Program
S.No. Enroll. No. Name Grand Total Marks Gage | Rank Division
1.
2.

3.2.7 User Accounts Information Maintenance

Description »

The system will maintain information about various users who will be able to access
the sys-
tem. The following information would be maintained:
User Name, User ID, Password, and Role.

| Validity checks
‘ . t
(t) Only user with role Administrator will be authorised to access the User
Accounts
Information Maintenance module.

Scanned with CamScanner

ae x

= Software Engineering

(ti) User Name cannot be blank.

(7zi) User ID cannot be blank.

(vv) User ID should be unique for every user.

(v) Password cannot be blank.

(vi) Role cannot be blank.

Sequencing information

_User Account for a particular user has to be created in order for the system to be
accessible to
that user. At system startup, only a default user account for ‘Administrator’ would
be present
in the system. “ ,
Error handling/response to ‘abnormal situations
If any of the above validations/sequencing flow does not hold true, appropriate
error messages
will be prompted to the user for doing the needful.
3.3 Performance Requiremenis

&
- None

3.5 Software System Attributes

3.5.7 Security :

The application will be password protected. Users will have to enter correct
username, pass-
word and role in order to access the application. .

3.5.2 Maintainability
The application will be designed in a maintainable manner. It will be easy
to'incorporate new

requirements in the individual modules (z.e., subject info, student info, students’
subject choices
info, marks info, report generation and user accounts info). .

3.5.3 Portability
The application will be easily portable on any windows-based system that has MS-
Access 2000

installed.

3.6 Logical Database Requiremenis

The following information will be placed in a database: =
(t) Subject info: Subject Name, Code, Credit points, Type and Semester |
. - Gi) Student info: Student enrollment number, Student Namevenrollment year” |
(iii) Students’ subject choice info: Student Enrollment No, Semester, Choice 0 |
1 subject, Choice of Elective 2 subject

Scanned with CamScanner

sh
w
Ww

[sotware Requirements : Analysis and Specifications 3 |

(iv) Marks info: Student Enrollment No., Semester, internal Marks in each subject,
External Marks in each subject

(v) User account info: User Name, User ID, Password, Role.

Scanned with CamScanner