Srs

Structure/ Format of an SRS
1. Introduction
1.1 Purpose - the basic objective of the system
1.2 Scope - what the system is to do , not to do
1.3 Definition, Acronyms & abbreviations
1.4 References
1.5 Overview
2. Overall description
2.1 Product perspective

General factors that
2.2 Product functions affect the product &
its requirements
2.3 User characteristics
2.4 Assumptions & dependencies
2.5 General Constraints
3. Specific requirements
3.1 External interfaces requirements
3.1.1 UI
All the details the
3.1.2 H/W interfaces
developer should
3.1.3 S/W Interfaces know for designing
& developing the
3.1.4 Communication Interface
system
3.2 Functional requirements
product & its
3.3 Performance requirements requirements
3.4 Design constraints
3.5 Attributes
3.6 Logical database requirements
3.7 Other requirements
This standardization of the SRS was done by IEEE.
SRS Case
Problem statement: University conducts a 4-semester M.Tech(IT) program. The students are
offered 4 theory & 2 Lab papers during 1st,2nd, 3rd semester. The theory subjects are categorized
as core (do not have alternative subject) or elective (other 2 alternatives) Thus student studies any
subject out of 3 choices available for elective papers.
Page 1 of 21
 In 1st, 2nd, 3rd semester - 2 core & 2 elective are offered to each student. They have to appear for
term paper / minor project in1st, 2nd & 3rd semester. In 4th semester, students have to give a
seminar & submit a dissertation on a topic/subject area of their interest.
 In evaluation – total marks out of 100 ( internal + external)
Internal evaluation - marks out of 40 for each paper = minor exams are conducted for each
semester. Students have to submit assignments to respective faculty, also their lab records & their
attendance.
 External evaluation – at semester end – major exams are conducted for theory & practical.
( Marks out of 60 )
 Credit points – every subject has some credit points
If in any subject, total marks >= 50, student passes( else fail) earns all credit points (else no credit
pts). All the latest info. can be obtained from university website.
 You are required to develop a system to manage information of subject offered in various
semester, students enrolled in various semesters, elective(s) opted by various student in diff
semesters., marks & credit points obtained by students in different semester. System should
generate the printable mark sheet , semester wise detailed mark list , student performance reports.
Software Requirement Specification
1. Introduction : This document aims at defining the overall s/w requirement for ‘Student Result
Management System’.
The final product will be having features/functionalities mentioned in this document & assumptions for
any additional functionality/feature should not be made by any of the parties involved in developing
/testing /implementing/ using this product.
In case it is required to have some additional features, a formal change request will need to be raised and
subsequently a new release of this document and/or product will be produced.
1.1 Purpose - The basic objective of the system.
This specification document describes the capabilities that will be provided by the s/w Application
“Student Result Management System”.
It also states the various required constraints which the system will abide.
The intended audience for this document are the development team, testing team & end users of the
product.
1.2 Scope - What the system is to do, not to do.
The product will be an MIS & reporting application that will be used for result preparation &
management of M.Tech Students.
The application will manage the information of various students enrolled in this course in different years,
the subjects offered during different semesters, the students choices for opting different subjects & marks
obtained .
Printable reports- registered student list, marks obtained, performance (rank wise, division wise, pass/fail,
%wise) will be generated.
Page 2 of 21
Printable mark sheet for every student will be generated.
The application will simplify the result preparation & management process
M.Tech - Master of Technology
IT : Information Technology
DBA : Database Administrator
1.4 References
University website : for information & course structure of M.Tech
IEEE recommended Practice for SRS – IEEE Standards
1.5 Overview
The rest of the document describes
 various system requirements
 interfaces
 features & functionalities in detail.
 M.Tech Programme is a 4-semester course.
 The students are offered 4 subjects (theory) 2 labs (practical) during 1st, 2nd, 3rd semester.
 The 4th semester consists of seminar & dissertation.
 Each subject/lab/term paper /seminar /dissertation has credits associated with it.
 When a student secures pass marks in paper he earns all credits assigned to that paper.
 The system will have a capability to maintain info of student enrolled in the course, subjects
offered to them during different semesters, the students choices for opting different elective
subjects (from available) and marks are obtained in different subs in various semesters.
 The s/w will also generate the summary reports reg. stud. Info. , semester wise mark sheet,
performance reports.
 Printable mark sheets of individual student are also generated.
2.1 Product perspective:
 The application will be windows based & independent s/ w product.
Page 3 of 21
Front end client
application
Backend
database
(with data entry/update

/del./view
The & reporting
major functions performed will be :
facility)
2.2 Product functions
1) Login facility to enable only authorized users to access the system
2) User ( with role data entry operator) will able to add/modify/delete information of different students
who are enrolled for the course in different years.
3) User ( with role data entry operator) will able to add/modify/delete information of different subjects
that are offered in a particular semester.
The semester-wise subjects with their credit points & type ( elective / core / lab / term paper/dissertation)
will also be displayed
4) User ( with role data entry operator) will able to add/modify/delete information of the elective
subjects opted by different students in different semesters.
5) User (with role marks entry clerk ) will be able to add/mod/del information register. The marks
obtained by different students in different semesters.
6) User ( with role marks entry clerk) will also be able to print mark-sheets of the student.
7) User ( with role coordinator) will be able to generate printable reports
8) User ( with role Admin.) will be able to “Reset “ the system-leading to deletion of existing
information from the database.
9) User (with role admin.) will able to create/modify/del new/existing user accounts.
 Educational level : Graduate should be comfortable with English language
 Experience : should be well versed about the info. and the course structure of M.Tech. program
of University.
 Entry of marks /modification can be done only by user who is authorized for this job by the
result preparation committee of University.
 Tech. Expertise : Should be comfortable using general-purpose applications on the computer.
 The no. of subjects to be taken up by a student in each semester does not change
Page 4 of 21
 The subject types ( i.e. elective, core, term paper, dissertation ) do not change
 The no. of semesters in the M.Tech. programme does not change.
 Since the DBMS being used is MS Access 2000, which is not very powerful DBMS, it will not be
able to store a very large no. of records.
 Users at University will have to implement a security policy to safeguard the mark related
information from being modified by unauthorized users
 This section contains the s/w requirement to a level of detail sufficient to enable designers to
design the system, & testers to test that system.
3.1.1 User Interfaces
The following screens will be provided
1. Login screen : This is the first screen that will be displayed.
It will allow user to access diff. screens based upon the user’s role.
Various fields available on this screen will be
1) User Id : alphanumeric of length up to 10 char.
2) Password : alphanumeric length up to 8 char.
3) Role : will have the following values - administrator, marks entry

clerk, coordinator, data entry operator
4) Button for Signin
2.Subject information Parameter screen
Screen will be accessible only to user with role administrator.
It will allow the user to enter the semester no. for which the user wants to access the subject
information
3. Subject info. Screen :
Screen will be accessible only to user with role administrator.
It will allow the user to add/mod./del info. @ existing/new subs for the semesters that was selected in
the “subject info. Parameter screen.”
The list of available subs for that semester, will also be displayed.
Various fields available on this screen will be :
1) Subject code,
Page 5 of 21
2) Subject Name
3) Category/ Type (elective1/elective2/core/lab/term paper/seminar/ dissertation)
4) Credits ( any value from 0 to 20)
4. Student information parameter screen : accessible to admin.
Allow the user to enter the batch yr. for which the stud wants to access the student information.
5.Student information screen : for admin.
1) Student Enrollment no
2) Student Name
3) Batch yr.
6. Student subject choice parameter screen
7. Student subject choice information screen
8.Marks entry parameter screen
9. Marks entry screen
10. Mark sheet parameter screen
11. Student list report parameter screen
12. Mark list report parameter screen
13. Stud sub choices list report para. Screen
3.1.2 H/w interface
1)Screen resolution of atleast 800 X 600 required for proper & complete viewing of the screens .
Higher resolution would not be a problem
2) Support for printer ( any–dot matrix, laser, inkjet) appropriate drivers are installed & printer
connected properly. It is required for mark list & reports printing
3) Standalone system or network based – possible to run the application on any of these.
3.1.3 S/w Interfaces
1) Any windows-based OS
2) MS Access 2000 as the DBMS- for database.
Future release of the application will aim at Oracle 10i as DBMS
3) Crystal reports 8 – for generating & viewing reports
4) Visual Basic 6 – for coding developing s/w

S/w mentioned in point 3 & 4 above , will be required only for the development of the application.
The final application will be packaged as an independent setup program that will be delivered to the
client (University in this case)
Page 6 of 21
3.2.1 Sub Info. Maintenance
Description : This module will maintain information of various sub being offered during different
semester of the course.
The following information would be maintained for each subject:
subject code, name, type , semester, credits.
The system will allow creation /mod/del of subjects & also have the ability to list all subjects for
particular semester.
Validity checks
Only user with Data Entry Operator will be authorized to access this module.
2) 1st,2nd,3rd semester will have 2 core papers,2elective papers, 2 lab papers & 1 term/mini project
3) 1st,2nd & 3rd semester will have 3 choices (sub) each of type elective1 & elective 2.
4) 4th semester will have only 1 dissertation & 1 seminar
5) No two semesters will have the same sub i.e. the sub will be offered only in a particular semester.
6) Subject code will be unique for every subject
7) Subject code, subject name cannot be blank
8) Credits cannot be blank and can have values from 0 to 209 Sub type , semester can not be blank
Sequencing Information Subject
Information for a 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
Description : This module will maintain information of various students
The following information would be maintained for each student
Student enrollment no., Student name, Batch yr
The system will allow creation /mod/del of students & also have the ability to list all the students
semester wise
3.2.3 Student subject choices Information Maintenance
3.2.4 Marks Information Maintenance
3.2.5 Mark-sheet generation
Page 7 of 21
3.2.6 User accounts Information Maintenance
3.2.7 Report generation
1) Student List report : report for each year list of students enrolled in that batch.
University Name
M.Tech Programme
List of the students enrolled in the academic year XXXXX
Date
Page No.
Sr. No. Students Enrollment Number Student Name
Other Reports
2)Stud subject choice list report
Report format ( Ist, IInd & IIIrd sem) Report format for IVth sem
3) Semester mark list
4) Rank-wise list report
3.3 Performance requirements: None
3.4 Design constraints: None
3.5 Attributes
3.5.1 Security:
The application will be password protected. Users will have to enter that correct username, password &
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 requirement in the individual modules. (i.e subject
information., student information, student subject choices, marks information etc.)
The application will be easily portable on any windows-based system that has Ms Access2000 installed.

Logical database requirement: following information will be placed in the database.
1) sub info.
2) stud. Info.
Page 8 of 21
3) stud. Sub. Choice info.
4) Marks info.
5) Users a/c info.
3.7 Other Requirements: None
Case 2
The management of GETWELL hospital has decided to computerize their operations. The following
information is provided by the management.
There are many consulting doctors associated with the hospital, their name, contact number and
specialization are important information item to be recorded for the doctors. Their charges are levied as
per charge slips admitted by the doctors with respect to the patients.
Patients are admitted to the hospital and their particulars, main course of admission, history(medical) and
treatment are recorded. A patient is admitted into a room which has certain category and is with fixed
charge per day. If an accident case patient comes then FIR has to submitted to the hospital for getting
treatment.
Prepare SRS for the above & also write the system specification.
SRS
1. Introduction : This document aims at defining the overall s/w requirement for ‘GETWELL
Hospital Management System’.
subsequently a new release of this document and/or product will be produced
This specification document describes the capabilities that will be provided by the s/w application
‘GETWELL Hospital Management System’.
product.
1.2 Scope - What the system is to do, not to do.
The product will be an MIS system that computerize the operations of the hospital
 The application will manage the information of various doctors serving the hospital.
 The patients are charged for the treatments as per the charge slips admitted by the doctors.
 The Patients record ( particulars, main course of admission, medical history, treatment given )
will be maintained (the case record)
Page 9 of 21
 Room allocation to the patients is also done through the system
 Printable reports- doctors list, discharge report(patient wise, day wise, monthly etc) , room
allocation report, patient record, accident case record , bills etc. will be generated
The application will simplify hospital management.
FIR: First Investigation Report
IEEE: Institute of Electrical and Electronics Engineers
1.4 References
1.5 Overview
 interfaces
 The system will give information about doctors available.
 Patients can make appointment with a doctor through the system
 Patients are charged according to the charge slips admitted by the doctors
 Those patients admitted to the hospital can avail the rooms of the hospital
 The system will have a capability to maintain the records of the patients
 The patient diagnosis and medical history is maintained.
 Treatment & prescription will be suggested based on the diagnosis & medical history of the
patient.
 In accident case, FIR is checked before treatment given to the patient.
 2.1 Product perspective:
 The application will be web based & independent s/ w product.
Front end client

application
Backend
database
Page 10 of 21
(with data
entry/update /del./view
& reporting facility)
2.2 Product Functions
The major functions performed will be :
1)Login facility to enable only authorized user (clerks ) to access the system
2) User ( with role clerk) will able to add/modify/delete information of different doctors .
3) User ( with role clerk) will able to add/modify/delete information of different patients.
4) User ( with role clerk) will able to add/modify/delete information of different rooms
available.
5) User ( with role clerk) will be able to generate printable reports
 Educational level : Should be comfortable with English language
 Experience : acquaintance with online systems
 A patient can consult a doctor only if he/she has an appointment
 In case of accident or emergency, the consultation can be through causality.
 Since SQL Server is used there are no database constraints
 Only authorized users can access the system
 This section contains the s/w requirement to a level of detail sufficient to enable designers to
design the system, & testers to test that system.
1. Login screen
This is the first screen that will be displayed.
Page 11 of 21
3) Role: will have the following values - administrator, clerk
4) Button for Sign in
2.Doctors info screen
Screen will be accessible to the clerk
It will allow the clerk to enter create/modify/ delete doctors
1. Doctor’s Id
2. Doctor’s Name
3. Specialization
4. Doctor Type
5. Date of Birth
6. Age
7. Contact No
8. Address
9. Email Id
10. Experience
3. Case Sheet Form
It will allow the patient to make an appointment with the doctor
The list of available doctors as per specialization will also be displayed.
1) Specialization
2) Doctor’s name
3) Relative’s name
4) Past Disease
5) Relation with patient
6) Reference Name
7) Type of admission
8) FIR No. (disabled field initially, will become active if admission type is accident)
4. Patient Info Screen
Page 12 of 21
1. Patient ID
2. Patient name
3. Date of birth
4. Age
5. Sex
6. Address
7. Date of appointment
3. Doctor’s Id
4. Disease id
5. Bill Screen
1. Patient Name
2. Doctor Consulted
3. Consulting Fee (disabled field)
4. Room id
5. No. of days admitted
6. Treatment given
7. Other Charges
5. Room Allocation Screen
1. RoomAllocID
2. Room type
3. Patient ID
4. Avail Room
6. Room Information Screen
1. Room ID
2. Room Type
3. Category
4. Room Rent (Rate)
3.1.2 H/w interface
Page 13 of 21
1)Screen resolution of at least 800 X 600 required for proper & complete viewing of the screens .
Higher resolution would not be a problem
2) Support for printer ( any–dot matrix, laser, inkjet) appropriate drivers are installed & printer
connected properly. It is required for mark list & reports printing
3) Stand alone– possible to run the application on internet
2) SQL Server as the DBMS- for database.
3) Crystal reports – for generating & viewing reports
4) VB 6.0– for coding developing s/w

S/w mentioned in point 2 & 4 above will be required only for the development of the application.
client
3.1.4 Communication Interface: None
3.2.1 DoctorModule
Description : This module will maintain information of various doctors
The following information would be maintained for each doctor
Doctor’s Id, Doctor’s Name, Specialization, Doctor Type, Age, Contact No, Address, Email Id,
Experience
The system will allow creation /mod/del of doctor & also have the ability to list all doctors according to
specialization, seniority etc.
Validity checks
Only clerk will be authorized to access this module.
1) Doctor id will be unique for every item
2) Doctor name, Specialisation cannot be blank.
3) check digit for Contact No.
Sequencing Information
Doctor’s Id, Doctor’s Name, Specialization, Doctor Type, Age, Contact No, Address, Email Id,
Experience
Page 14 of 21
3.2.2 Patient Module
Description : This module will maintain information of various patients
The following information would be maintained for each patient
Patient ID, Patient name, Age, Sex, Address, Date of appointment, Doctor’s Id, Disease id
The system will allow creation /mod/del of patient
3.2.3 Room module
3.2.4 Case Form module
3.2.5 Disease Module
3.2.6 Bill Module
1) Specialization wise report :
GETWELL HOSPITAL
NIGDI
Specialization wise report generated on Page no.
Specialization: --------------------
Sr. No Doctors Name Experience in years
Other reports
 Room availability report
 Discharge report (patient wise)
 Discharge report (daily basis, monthly basis)
 Bill
3.3 Performance requirements (Non-functional ) : None
3.4 Design constraints: None
3.5 Attributes
3.5.1 Security :
 The application will be password protected .
 User (clerk) will have to enter that correct username & password in order to access the
application.
Page 15 of 21
3.5.2 Maintainability :
 The application will be designed in a maintainable manner.
 It will be easy to incorporate new requirement in the individual modules.
3.5.3 The application will be easily portable on any windows-based system that has VB 6.0 installed.

Logical database requirement: following information will be placed in the database.
1) Patient info.
2)Doctor Info.
3)Room info.
4) Bill info.
5) Users a/c info.
6) Disease info
3.7 Other Requirements: None
Case 3
A company dealing with spare parts would like to change the existing sales system to a web based
application. The company has their products listed on the website through which they receive enquiries.
Then enquiries are processed online the Delivery Note & Invoice also sent by mail which is used for cross
verification by the clerk.
Prepare SRS for the above & also write the system specifiaction.
SRS
1. Introduction : This document aims at defining the overall s/w requirement for “ Online Sales
System.”
subsequently a new release of this document and/or product will be produced.
This specification document describes the capabilities that will be provided by the s/w application
“Online Sales System”
product.
Page 16 of 21
GRN : Goods Return Note
IEEE: Institute of Electrical and Electronics Engineers
1.4 References
1.5 Overview
 interfaces
 The website will give information about various spare parts available.
 The customer (registered) can through the website enquire for spare parts of his/ her choice
 Then enquiries are processed online
 The Delivery Note & Invoice also sent by mail to the customer
 Clerk verifies the Invoice against the items
 The system will have a capability to maintain stock of spare parts,
 From enquiries the demand for particular spare part can be identified
 From the GRN the reasons for rejection can be identified
The s/w will also generate the sales summary report.
2.1 Product perspective:
The application will be web based & independent s/ w product.
Front end client

application Backend
database
2.2 Product Functions
The major functions performed will be :

(with data
1) Registration is entry/update
mandatory /del./view
& reporting facility)
Login facility to enable only authorized users ( customer ) to access the system
2) User ( with role clerk) will able to add/modify/delete information of different spare part items .
Page 17 of 21
3) Customer will be able to add/modify/delete information about him/her.
4) Customer will be able to send enquiries about spare parts online
5) Delivery note and Invoice can be send through email.
6) User ( with role clerk) will be able to generate printable reports
 Educational level : Should be comfortable with English language
 Experience : acquaintance with online systems
 After Customer places enquiry PO is generated automatically
 Clerk verifies the PO against the items
 Payment can be partial if orders pending
 Since SQL Server is used there are no database constraints
Only registered customers can place orders.
This section contains the s/w requirement to a level of detail sufficient to enable designers to design the
system, & testers to test that system.
1. Registration Screen : This screen is useful for new users to register to the site
3) Button for Sign up
2. Login screen :
It will allow user to access diff. screens based upon the user’s role.

Page 18 of 21
3) Button for Signin
2.Spare part items screen
Screen will be accessible to the registered customer, clerk
It will allow the clerk to enter create/modify/ delete new spare part item
3. Enquiry Form
Screen will be accessible to registered customer
It will allow the customer to select spare part items for which he wants information.
The list of available spare parts, will also be displayed.
1) Item Name
2) Rate
3) Quantity Required
4) Mode of Transport
4. Delivery Screen
1. Customer name
2. Delivery Date
3. Quantity
4.Invoice Screen
1. Customer Name
2. Quantity Ordered
3. Rate
4. Amount (disabled field)
5. Discount
6. Date of delivery (disabled field)
5.Rejection Analysis Screen
3.1 Item Name
Page 19 of 21
3.2 Reason for rejection
3.3 Quantity rejected
6. Sales Information
1. Item name
2. Customer Name
3. Date of Sale
4. Region
5. Quantity sold
6. Rate
7. Amount
3.1.2 H/w interface
1)Screen resolution of at least 800 X 600 required for proper & complete viewing of the screens . Higher
resolution would not be a problem
2) Support for printer (any–dot matrix, laser, inkjet) appropriate drivers are installed & printer connected
properly. It is required for mark list & reports printing
3) Network based – possible to run the application on internet
2) SQL Server as the DBMS- for database.
3) Crystal reports – for generating & viewing reports
4) C #. NET – for coding developing s/w

S/w mentioned in point 2 & 4 above and IIS (Internet Information Server) server, will be required only
for the development of the application.
client
3.1.4 Communication Interface: None
3.2.1 Spare Parts Information Maintenance
Description: This module will maintain information of various spare items provided
The following information would be maintained for each spare part
item code, name, category, type, rate, unit of measure,
The system will allow creation /mod/del of items & also have the ability to list all items according to
type, category etc
Page 20 of 21
Validity checks
Only clerk will be authorized to access this module.
1) Item code will be unique for every item
2) item name, rate cannot be blank
Sequencing Information
item code, name, category, type, rate, unit of measure
3.2.2 Customer Information Maintenance
Description: This module will maintain information of various customer
The following information would be maintained for each customer
Customer name, address, phone no, mail id1, mail id 2
The system will allow creation /mod/del of customer
3.2.3 Enquiry module
3.2.4 Invoice module
1) Product wise sales report :

XYZ Co. Ltd
Product wise sales report for the period --------------------

Date
Page no.
Product name: --------------------
Sr. No Date of sale Quantity Amount

Sold
Page 21 of 21

Srs

Uploaded by

Copyright:

Available Formats

Srs

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Srs

Uploaded by

Copyright:

Available Formats

Structure/ Format of an SRS

1.1 Purpose - the basic objective of the system

1.2 Scope - what the system is to do , not to do

1.3 Definition, Acronyms & abbreviations

2.1 Product perspective

2.4 Assumptions & dependencies

2.5 General Constraints

3.1 External interfaces requirements

3.6 Logical database requirements

3.7 Other requirements

This standardization of the SRS was done by IEEE.

 In evaluation – total marks out of 100 ( internal + external)

 Credit points – every subject has some credit points

Software Requirement Specification

1.1 Purpose - The basic objective of the system.

1.2 Scope - What the system is to do, not to do.

1.3 Definition, Acronyms & abbreviations

M.Tech - Master of Technology

DBA : Database Administrator

University website : for information & course structure of M.Tech

IEEE recommended Practice for SRS – IEEE Standards

The rest of the document describes

 various system requirements

 features & functionalities in detail.

 M.Tech Programme is a 4-semester course.

 The 4th semester consists of seminar & dissertation.

 Printable mark sheets of individual student are also generated.

2.1 Product perspective:

 The application will be windows based & independent s/ w product.

(with data entry/update

1) Login facility to enable only authorized users to access the system

7) User ( with role coordinator) will be able to generate printable reports

2.3 User characteristics

 Educational level : Graduate should be comfortable with English language

 Tech. Expertise : Should be comfortable using general-purpose applications on the computer.

2.4 Assumptions & dependencies

 The no. of semesters in the M.Tech. programme does not change.

2.5 General Constraints

3.1 External interfaces requirements

3.1.1 User Interfaces

The following screens will be provided

1. Login screen : This is the first screen that will be displayed.

Various fields available on this screen will be

1) User Id : alphanumeric of length up to 10 char.

2) Password : alphanumeric length up to 8 char.

3) Role : will have the following values - administrator, marks entry

4) Button for Signin

2.Subject information Parameter screen

Screen will be accessible only to user with role administrator.

3. Subject info. Screen :

Screen will be accessible only to user with role administrator.

Various fields available on this screen will be :

3) Category/ Type (elective1/elective2/core/lab/term paper/seminar/ dissertation)

4) Credits ( any value from 0 to 20)

4. Student information parameter screen : accessible to admin.

5.Student information screen : for admin.

6. Student subject choice parameter screen

7. Student subject choice information screen

8.Marks entry parameter screen

9. Marks entry screen