NSIT SAD lab FILE

USE CASES

1.LOGIN

1.1 BRIEF DESCRIPTION This use case describes how a user logs into University Automation System.

1.2 ACTORS The following actors(s) interact and participate in this use case:Data Entry Operator, Administrator, Faculty, Student.

1.3 FLOW OF EVENTS1.3.1 BASIC FLOW This use case starts when the actor wishes to Login to the University Automation System.♦ The system requests that the actor enter his/her name, password and role. ♦ The actor actor enters his/her name, password and role.♦ The system validates the entered name, password, role and logs the actor into

the system.

1.3.2 ALTERNATIVE FLOWS1.3.2.1 INVALID NAME / PASSWORD / ROLE If in the basic flow, the actor enters an invalid name, password and role, the system displays a error message. The actor can choose to either return to the beginning of the Basic Flow or cancel the login, at which the use case ends.

1.4 SPECIAL REQUIREMENTS None.

1.5 PRE-CONDITIONS All the user 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.

1.6 POST-CONDITIONS If the use case is successful, the actor is logged into the system. If not, the system state is not changed.♦ If the actor has the role ‘Data Entry Operator’ he/she will have access to only

screens corresponding to the Student Info Maintenance, School Info Maintenance, Programme Info Maintenance, Faculty Info Maintenance, Paper details, Scheme details modules of the system.

♦ If the actor has the role ‘Student’, he/she will only be able to maintain registration details and view the various reports generated by the system.

♦ If the actor has the role ‘Administrator’ he/she will have access to only screens corresponding to Issue of registration card,Report view, Issue of Login-ID, User Account Maintenance module of the system.

1.7 EXTENSION POINTS None.

2. MAINTAIN STUDENT INFORMATION2.1 BRIEF DESCRIPTION This use case allows the actor with role ‘Data Entry Operator’ to maintain student information. This includes adding, changing and deleting student information from the system.

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

2.3 FLOW OF EVENTS2.3.1 BASIC FLOW This use case starts when the Data Entry Operator wishes to add, change, or delete student information from the system.● The system requests that the Data Entry Operator specify the function he/she

would like to perform.● Once the Data Entry Operator provides the requested information, one of the sub-

flows is executed.✓ If the Data Entry Operator selected “Add a Student”, the Add a Student

sub-flow is executed.✓ If the Data Entry Operator selected “Update a Student”, the Update a

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

Student sub-flow is executed.

2.3.1.1 ADD A STUDENT● The system requests that the Data Entry Operator enter the student information.

This includes:Name.Enrollment Number – should be unique for every student.Year of Enrollment.

● Once the Data Entry Operator provides the requested information, the student is added to the system and an appropriate message is displayed.

2.3.1.2 UPDATE A STUDENT● The student requests the Data Entry Operator enters the student enrollment

number.● The Data Entry Operator enters the student enrollment number. The system

retrieves and displays the student information.● 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.

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

2.3.1.3 DELETE A STUDENT● The system requests that the Data Entry Operator enters the student enrollment

number.● The Data Entry Operator enters the student enrollment number. The system

retrieves and displays the student information.● The system prompts the Data Entry Operator to confirm the deletion of the

student.● The Data Entry Operator confirms the deletion.● The system deletes the student record.

2.3.2 ALTERNATIVE FLOWS2.3.2.1 STUDENT NOT 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.5 PRE-CONDITIONS The Data Entry Operator must be logged onto the system before this use case begins.

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

2.7 EXTENSION POINTS None.3. MAINTAIN SCHOOL INFORMATION3.1 BRIEF DESCRIPTION This use case allows the actor with role ‘Data Entry Operator’ to maintain school information. This includes adding, changing and deleting school information from the system.


3.3 FLOW OF EVENTS3.3.1 BASIC FLOW This use case starts when the Data Entry Operator wishes to add, change, or delete School information from the system.● The system requests that the Data Entry Operator specify the function he/she


flows is executed.✓ If the Data Entry Operator selected “Add a School info”, the Add a School

sub-flow is executed.✓ If the Data Entry Operator selected “Update a School info”, the Update a

School sub-flow is executed.✓ If the Data Entry Operator selected “Delete a School info”, the Delete a

School sub-flow is executed.

3.3.1.1 ADD A SCHOOL INFO● The system requests that the Data Entry Operator enter the School information.

This includes:Name of the School.School Code – should be unique for every School.

● Once the Data Entry Operator provides the requested information, the School is added to the system and an appropriate message is displayed.

3.3.1.2 UPDATE A SCHOOL INFO● The student requests the Data Entry Operator enters the School code.● The Data Entry Operator enters the School code. The system retrieves and

displays the School information.● The Data Entry Operator makes the desired changes to the School information.

This includes any of the information specified in the Add a School sub-flow.● Once the Data Entry Operator updates the necessary information, the system

updates the student record with the updated information.

3.3.1.3 DELETE A SCHOOL INFO● The system requests that the Data Entry Operator enters the Programme code.● The Data Entry Operator enters the Programme code. The system retrieves and

displays the Programme information.● The system prompts the Data Entry Operator to confirm the deletion of the

Programme.● The Data Entry Operator confirms the deletion.

● The system deletes the School record.

3.3.2 ALTERNATIVE FLOWS3.3.2.1 SCHOOL NOT FOUND If in the Update a School or Delete a School sub-flows, a School with the specified School code does not exist, the system displays an error message. The Data Entry Operator can then enter a different School code or cancel the operation, at which point the use case ends.

3.3.2.2 UPDATE CANCELLED If in the Update a School sub-flow, the Data Entry Operator decides not to update the School 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 School sub-flow, the Data Entry Operator decides not to delete the School information, the delete is cancelled and the Basic Flow is re-started at the beginning.



3.6 POST-CONDITIONS If the use case was successful, the School information is added, updated, or deleted from the system. Otherwise, the system state is unchanged.


4. MAINTAIN FACULTY INFORMATION4.1 BRIEF DESCRIPTION This use case allows the actor with role ‘Data Entry Operator’ to maintain faculty information. This includes adding, changing and deleting faculty information from the system.


4.3 FLOW OF EVENTS4.3.1 BASIC FLOW This use case starts when the Data Entry Operator wishes to add, change, or delete faculty information from the system.

● The system requests that the Data Entry Operator specify the function he/she would like to perform.

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

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

✓ If the Data Entry Operator selected “Update a Faculty”, the Update a Faculty sub-flow is executed.

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

4.3.1.1 ADD A FACULTY● The system requests that the Data Entry Operator enter the faculty information.

This includes:Faculty Id.Faculty Name.Department.

● Once the Data Entry Operator provides the requested information, the faculty is added to the system and an appropriate message is displayed.

4.3.1.2 UPDATE A FACULTY● The faculty requests the Data Entry Operator enters the faculty Id.● The Data Entry Operator enters the faculty Id. The system retrieves and displays

the faculty information.● The Data Entry Operator makes the desired changes to the faculty information.

This includes any of the information specified in the Add a Faculty sub-flow.● Once the Data Entry Operator updates the necessary information, the system

updates the faculty record with the updated information.

4.3.1.3 DELETE A FACULTY● The system requests that the Data Entry Operator enters the faculty Id.● The Data Entry Operator enters the faculty Id. The system retrieves and displays

the faculty information.● The system prompts the Data Entry Operator to confirm the deletion of the

faculty.● The Data Entry Operator confirms the deletion.● The system deletes the faculty record.

4.3.2 ALTERNATIVE FLOWS4.3.2.1 FACULTY NOT FOUND If in the Update a Faculty or Delete a Faculty sub-flows, a faculty with the specified Id does not exist, the system displays an error message. The Data Entry Operator can then enter a different Id or cancel the operation, at which point the use case ends.

4.3.2.2 UPDATE CANCELLED

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

4.3.2.3 DELETE CANCELLED If in the Delete a Faculty sub-flow, the Data Entry Operator decides not to delete the faculty information, the delete is cancelled and the Basic Flow is re-started at the beginning.



4.6 POST-CONDITIONS If the use case was successful, the faculty information is added, updated, or deleted from the system. Otherwise, the system state is unchanged.


5. MAINTAIN PROGRAMME INFORMATION5.1 BRIEF DESCRIPTION This use case allows the actor with role ‘Data Entry Operator’ to maintain programme information. This includes adding, changing and deleting programme information from the system.


5.3 FLOW OF EVENTS5.3.1 BASIC FLOW This use case starts when the Data Entry Operator wishes to add, change, or delete programme information from the system.● The system requests that the Data Entry Operator specify the function he/she


flows is executed.✓ If the Data Entry Operator selected “Add a Programme”, the Add a

Programme sub-flow is executed.✓ If the Data Entry Operator selected “Update a Programme”, the Update a

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

Programme sub-flow is executed.

5.3.1.1 ADD A PROGRAMME● The system requests that the Data Entry Operator enter the programme

information. This includes:Programme Code.Programme Name.Duration.Fees.

● Once the Data Entry Operator provides the requested information, the programme is added to the system and an appropriate message is displayed.

5.3.1.2 UPDATE A PROGRAMME● The programme requests the Data Entry Operator enters the programme code.● The Data Entry Operator enters the programme code. The system retrieves and

displays the programme information.● The Data Entry Operator makes the desired changes to the programme

information. This includes any of the information specified in the Add a Programme sub-flow.

● Once the Data Entry Operator updates the necessary information, the system updates the programme record with the updated information.

5.3.1.3 DELETE A PROGRAMME● The system requests that the Data Entry Operator enters the programme code.● The Data Entry Operator enters the programme code. The system retrieves and

displays the programme information.● The system prompts the Data Entry Operator to confirm the deletion of the

programme.● The Data Entry Operator confirms the deletion.● The system deletes the programme record.

5.3.2 ALTERNATIVE FLOWS5.3.2.1 PROGRAMME NOT FOUND If in the Update a Programme or Delete a Programme sub-flows, a programme with the specified code does not exist, the system displays an error message. The Data Entry Operator can then enter a different code or cancel the operation, at which point the use case ends.

5.3.2.2 UPDATE CANCELLED If in the Update a Programme sub-flow, the Data Entry Operator decides not to update the programme information, the update is cancelled and the Basic Flow is re-started at the beginning

5.3.2.3 DELETE CANCELLED

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



5.6 POST-CONDITIONS If the use case was successful, the programme information is added, updated, or deleted from the system. Otherwise, the system state is unchanged.


6. MAINTAIN PAPER/SUBJECTS INFORMATION6.1 BRIEF DESCRIPTION This use case allows the actor with role ‘Data Entry Operator’ to maintain information about the choice of papers available in various programmes to 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.


6.3 FLOW OF EVENTS6.3.1 BASIC FLOW This use case starts when the Data Entry Operator wishes to update students’ subject choice information from the system.● The system requests that the Data Entry Operator specify the semester and the

enrollment year of students, for which the students’ subject choices have to be updated.

● Once the Data Entry Operator provides the requested information, the system displays the list of available choice for Elective 1 & Elective 2 subjects for that semester and the list of students enrolled in the given enrollment year (along with their existing subject choices, if any).

● The system requests that the Data Entry Operator specify the information regarding Students’ Subject Choices. This includes:Students’ Enrollment Number.Students’ Choice for Elective 1 subject (the corresponding subject code).Students’ Choice for Elective 2 subject (the corresponding subject code).

● Once the Data Entry Operator provides the requested information, the information regarding students’ subject choices is added/ updated in the system and an appropriate message is displayed.

6.3.2 ALTERNATIVE FLOWS6.3.2.1 SUBJECT INFORMATION DOES NOT EXISTIf no or incomplete subject information exists in the system for the semester specified by the Data Entry Operator, system displays an error message. The Data Entry operator can enter a different semester or cancel the operation, at which point the use case ends.

6.3.2.2 STUDENT INFORMATION DOES NOT EXISTIf no or incomplete student information exists in the system for the enrollment year specified by the Data Entry Operator, system displays an error message. The Data Entry operator can enter a different enrollment year or cancel the operation, at which point the use case ends

6.3.2.3 INCORRECT CHOICE ENTERED FOR ELECTIVE1/ELECTIVE2 SUBJECTSIf the subject code entered by the Data Entry Operator for Elective1/Elective2 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.

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



6.6 POST-CONDITIONS If the use case was successful, the information about the students’ choices for opting different Elective subjects is added/updated in the system. Otherwise, the system state is unchanged.


7. MAINTAIN SCHEME INFORMATION7.1 BRIEF DESCRIPTION This use case allows the actor with role ‘Data Entry Operator’ to maintain schemes of programme’s information. This includes adding, changing and deleting schemes of programme’s information from the system.


7.3 FLOW OF EVENTS7.3.1 BASIC FLOW This use case starts when the Data Entry Operator wishes to add, change, or delete schemes of programme’s information from the system.● The system requests that the Data Entry Operator specify the function he/she


flows is executed.✓ If the Data Entry Operator selected “Add a Schemes of programme’s”, the

Add a Schemes of programme’s sub-flow is executed.✓ If the Data Entry Operator selected “Update a Schemes of programme’s”,

the Update a Schemes of programme’s sub-flow is executed.✓ If the Data Entry Operator selected “Delete a Schemes of programme’s”,

the Delete a Schemes of programme’s sub-flow is executed.

7.3.1.1 ADD A SCHEMES OF PROGRAMME’S● The system requests that the Data Entry Operator enter the programme scheme

information. This includes:No. of schemes

Code

● Once the Data Entry Operator provides the requested information, the schemes of programme’s is added to the system and an appropriate message is displayed.

7.3.1.2 UPDATE A SCHEMES OF PROGRAMME’S● The schemes of programme’s requests the Data Entry Operator enters the schemes

of programme’s code.● The Data Entry Operator enters the schemes of programme’s code. The system

retrieves and displays the schemes of programme’s information.● The Data Entry Operator makes the desired changes to the schemes of

programme’s information. This includes any of the information specified in the Add a Schemes of programme’s sub-flow.

● Once the Data Entry Operator updates the necessary information, the system updates the schemes of programme’s record with the updated information.

7.3.1.3 DELETE A SCHEMES OF PROGRAMME’S● The system requests that the Data Entry Operator enters the schemes of

programme’s code.● The Data Entry Operator enters the schemes of programme’s code. The system

retrieves and displays the schemes of programme’s information.

● The system prompts the Data Entry Operator to confirm the deletion of the schemes of programme’s.

● The Data Entry Operator confirms the deletion.● The system deletes the schemes of programme’s record.

7.3.2 ALTERNATIVE FLOWS7.3.2.1 SCHEMES OF PROGRAMME’S NOT FOUND If in the Update a Schemes of programme’s or Delete a Schemes of programme’s sub-flows, a schemes of programme’s with the specified code does not exist, the system displays an error message. The Data Entry Operator can then enter a different code or cancel the operation, at which point the use case ends.

7.3.2.2 UPDATE CANCELLED If in the Update a Schemes of programme’s sub-flow, the Data Entry Operator decides not to update the schemes of programme’s information, the update is cancelled and the Basic Flow is re-started at the beginning

7.3.2.3 DELETE CANCELLED If in the Delete a Schemes of programme’s sub-flow, the Data Entry Operator decides not to delete the schemes of programme’s information, the delete is cancelled and the Basic Flow is re-started at the beginning.



7.6 POST-CONDITIONS If the use case was successful, the schemes of programme’s information is added, updated, or deleted from the system. Otherwise, the system state is unchanged.


8. GENERATE REPORTS8.1 BRIEF DESCRIPTION This use case allows the actor with the role ‘Administrator’ to generate various reports. The following reports can be generated:♦ Students List Report.♦ Students’ Subject /Paper/scheme List Report♦ Registration slips♦ Schools List♦ Programmes List♦ Faculty List

8.2 ACTORS The following actor(s) interact and participate in this use case: Administrator.

8.3 FLOW OF EVENTS8.3.1 BASIC FLOW This use case starts when the Administrator wishes to generate reports.

1. The system requests the Administrator specify the report he/she would like to generate.

2. Once the Co-ordinate provides the requested information, one of the sub-flows is executed:

● If the Administrator selected “Student List Report”, the Generate Student List Report sub-flow is executed.

● If the Administrator selected “Students’ Subject/Paper/Scheme List Report”, the Generate Students’ Student Choices List Report sub-flow is executed.

● If the Administrator selected “Registration Slips”, the Generate registration slip sub-flow is executed.

● If the Administrator selected “Schools List”, the Generate School List Report sub-flow is executed.

● If the Administrator selected “Faculty List”, the Generate Faculty List Report sub-flow is executed.

● If the Administrator selected “Programme List”, the Generate Programme List Report sub-flow is executed.

8.3.1.1 GENERATE STUDENT LIST REPORT➢ The system requests that the Administrator provide the enrollment year for which

the Student List report is to be generated.➢ Once the Administrator provides the requested information, the system generates

the Student List Report, containing the list of students enrolled in the given year.➢ The Administrator can then issue a print request for the report to be printed.

8.3.1.2 GENERATE STUDENT’S SUBJECT /PAPER/SCHEME LIST REPORT

➢ The system requests that the Administrator provide the enrollment year for which the Students’ Subject Choices List report is to be generated.

➢ Once the Administrator provides the requested information, the system generates the Students’ Subject Choice List Report, containing the choices for Elective 1 & Elective 2 subjects, opted by the students of the given enrollment year and semester.

➢ The Administrator can then issue a print request for the report to be printed

8.3.1.3 GENERATE REGISTRATION SLIPS➢ The system requests that the Administrator provide the enrollment year for which

the Student Registration slips is to be generated.

➢ Once the Administrator provides the requested information, the system generates the Students registration slips containing the list of students enrolled in the given year.

➢ The Administrator can then issue a print request for the report to be printed

8.3.1.4 GENERATE SCHOOL LIST REPORT➢ The system requests that the Administrator provide the code and enrollment year

for which the School List report is to be generated.➢ Once the Administrator provides the requested information, the system generates

the School List Report, containing all information about the school.➢ The Administrator can then issue a print request for the report to be printed.

8.3.1.5 GENERATE PROGRAMME LIST REPORT➢ The system requests that the Administrator provide the code and enrollment year

for which the programmes List report is to be generated.➢ Once the Administrator provides the requested information, the system generates

the Programmes List Report, containing all information about the programmes.➢ The Administrator can then issue a print request for the report to be printed.

8.3.1.6 GENERATE FACULTY LIST REPORT➢ The system requests that the Administrator provide the enrollment year for which

the Faculty List report is to be generated.➢ Once the Administrator provides the requested information, the system generates

the Faculty List Report, containing the list of faculty enrolled in the given year.➢ The Administrator can then issue a print request for the report to be printed.

8.3.2 ALTERNATE FLOWS8.3.2.1 NOT FOUND If no information exists in the system for the enrollment year specified by the Administrator, the system displays an error message. The Administrator can then enter a different enrollment year or cancel the operation, at which point the use case ends.


8.5 PRE-CONDITIONS The Administrator must be logged onto the system before this use case begins.

8.6 POST-CONDITIONS If the use case was successful, the desired report is generated. Otherwise, the system state is unchanged.


9. MAINTAIN USER ACCOUNTS9.1 BRIEF DESCRIPTION This use case allows the actor with the role ‘ Administrator’ to maintain User Accounts. This includes adding, changing, and deleting user account information from the system.

9.2 ACTORS The following actor(s) interact and participate in this use case:Administrator.

9.3 FLOW OF EVENTS9.3.1 BASIC FLOW This use case starts when the Administrator wishes to add, change and/or delete user account information from the system.

➢ The system requests that the Administrator specify the function he/she would like to perform.

➢ Once the Administrator provides the requested information, one of the sub-flows is executed.

❖ If the Administrator selected “Add a User Account”, the Add a User Account sub-flow is executed.

❖ If the Administrator selected “Update a User Account”, the Update a User Account sub-flow is executed.

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

9.3.1.1 ADD A USER ACCOUNT1. The system requests that the Administrator enters the user information. This includes:User Name.User ID – should be unique for each user account.Password.Role.2.Once the Administrator provides the requested information, the user account information is added to the system and an appropriate message is displayed.

9.3.1.2 UPDATE A USER ACCOUNT1. 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 Administrator 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.

9.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.3. The system prompts the Administrator to confirm the deletion of the user account.4. The Administrator confirms the deletion.5. The system deletes the user account record.

9.3.2 ALTERNATIVE FLOWS9.3.2.1 USER NOT FOUNDIf in 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.

9.3.2.2 UPDATE CANCELLEDIf 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.

9.3.2.3 DELETE CANCELLEDIf 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.


9.5 PRE-CONDITIONS The Administrator must be logged onto the system before this use case begins.

9.6 POST-CONDITIONS If the use case was successful, the desired report is generated. Otherwise, the system state is unchanged.


USE CASE DIAGRAM

SRS DOCUMENT FORUNIVERSITY AUTOMATION SYSTEM

♦ INTRODUCTION

This document aims at defining the overall software requirements for the ‘University Automation System’. Efforts are made to define the requirements exhaustively and accurately. The final product will be having only features/ functionalities mentioned in this document and assumptions for any additional functionality/features 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.8 PURPOSE

This specification document describes the capabilities that will be provided by the software application ‘University Automation 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. The software to be designed will control the information flowing in the university. There is already a manual process which control the counseling, registration, issuing of admission slips, providing roll numbers to registered students, allotting name of school, programme etc. This system is being designed for automating all these facilities by eliminating some problems of the existing system, which include slow processes, error-prone processing of system, files maintenance, space & time complexities etc.

1.9 SCOPE

The software project provides information related to personnel, students and examination papers etc. So, the application will perform the following functionalities—♦ Issue of Login Id and password to the members i.e. students and faculty.♦ Maintain the personal details of the student.♦ Maintain the details of various papers-- Theory & Practical as per the

scheme of the programme.♦ Issue of registration card to the student in every semester.♦ Maintain list of registered students.

♦ Maintain list of programmes offered by the university.♦ Maintain list of papers offered in a particular semester for a particular

programme.♦ Maintain list of faculty in a school. Etc.

1.10 DEFINITIONS, ACRONYMS & ABBREVIATIONS

Following abbreviations have been used throughout this document :

➢ ID : Identification Number of the user.♦ Prog. : Programmes offered by the university.

1.11 REFERENCES

♦ IEEE Recommended Standard for Software Requirement Specifications – IEEE Standard 830-1993.

● Given Problem Statement.

1.12 OVERVIEW

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

2.OVERALL DESCRIPTION

A university is organized in different teaching schools and each school conducts a variety of programmes. Admissions to the various programmes offered by each school are done through counseling. Admission slips are issued to the admitted students giving their roll numbers, name of the school and name of the programme. Students are registered in various schools manually based on the admission slips. Students are assigned papers (compulsory, elective and practical) depending upon the scheme of the selected programme. Every school is responsible for its registration process and following are prepared and maintained manually. The ‘University Automation System’ will have capability to maintain following information--- ♦ List of students registered in a programme.● List of students registered for a particular paper.● List of papers offered in a particular semester.

● List of faculty in a school.● Personal details of the students.● Registration card for every registered students.● Issue of Login Id and password to the members i.e. students & faculty.

● List of programmes offered by university. Etc.

2.1 PRODUCT PERSPECTIVE

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

2.1.1 SYSTEM INTERFACES None.

2.1.2 USER INTERFACES

The application will have a user-friendly and menu based interface. Following screens will be provided:5. A login screen for entering the username, password and role will be

provided.● There will be screen for capturing and displaying information regarding:

● Personal details of students.● Details of various papers.● Status of issue of registration card to students.● List of registered students.● List of programmes offered by the university.● List of papers offered in a particular semester for a

particular programme.● List of faculty in a school. Etc.

● The following reports will be generated:● Students’ List Report.♦ Students’ Subject Choice List Report.♦ Students’ Roll-No Wise Report.

♦ Students’ Programme Wise Report.♦ Students’ Semester Wise Report.♦ Students’ Paper Wise Report.♦ Programmes Offered Report.♦ Faculty List Report.

2.1.3 HARDWARE INTERFACES

1. Screen resolution of atleast 800 * 600.6. Support for printer.7. Standalone system or network-based system.

2.1.4 SOFTWARE INTERFACES

2 Windows based OS (Windows 95/98/2000/XP/NT).➢ MS Access 2000 as the DBMS for database.➢ Crystal Report 8 – for generating & viewing reports.➢ Visual Basic 6 – for coding/ developing the software.

2.1.5 COMMUNICATION INTERFACES The system need a very reliable, fast, efficient and secure network topology and network protocol for the communication purposes.

2.1.6 MEMORY CONSTRAINTS

At least 64MB RAM & 2GB space on hard disk will be required for running the application.

2.1.7 OPERATIONS

The DBA at the client site (i.e. university) will be responsible for data entry/ update/ delete/ view and reporting facility. Database backup and recovery will also have to be handled by DBA.

2.1.8 SITE ADAPTATION REQUIREMENTS

The terminals at the client site will have to support the hardware and software interfaces specified in above sections.

2.2 PRODUCT FUNCTION

The system will allow access only to authorized users with specific roles (Administrator, Data Entry Operator, Data Update Operator and Coordinator). Depending upon the user’s role, he/ she will be able to access only the specific modules of the system. A summary of the major functions that the software will perform :6. A login facility for enabling only authorized access to the system.➢ User (with role Data Entry Operator) will be able to add / modify/ delete

information regarding –❖ List of registered students.❖ List of programmes offered.❖ List of papers offered in a particular semester for a particular

programme.❖ Personal details of students.❖ Faculty list details. Etc.

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

2.3 USER CHARACTERISTICS

As the product is designed for the university so there will be following kinds of user expectations:8. STUDENTS: They are the basic users of the product. Many of the

functionalities of the product is restricted for these users. They can access the product only for getting the information about their roll numbers, programmes, semesters, papers, examinations and some details about the faculty also.

❖ FACULTY: The second level of the user is the faculty members working in the university. They can access the product to modify their profile or listing the examination or listing the students. They can access the records of all the students also.

❖ ACADEMICS: The final level of the user is the academics level. They will use the product to its full swing. They will use it to generate the admission slips, providing roll numbers, name of the school and name of the programme and also they are also allowed to make the changes in the

stored data. They will decide the papers - semester wise and programme wise.

2.4 CONSTRAINTS

♦ Each user should have its own Login Id and Password.9. Admission slip should not contain duplicate roll numbers.10. All the records must be reliable, correct and error free.11. The speed and performance of the application must be effective.12. The application should be facilitated with security issues.13. Proper validation checks must be provided.14. No user is allowed to access the software over its level.

2.5 ASSUMPTIONS & DEPENDENCIES

➢ The number of subjects to be taken up by a student in each semester does not change.

➢ The subject types (i.e. elective, core, lab, term paper and dissertation) do not change.

➢ The number of semester in each program does not change.➢ All the computer systems must be connected via LAN in a secured fashion.➢ The users are having some knowledge regarding online information

system.➢ University is having all the needed resources like hardware & software

requirements.

2.6 APPORTIONING OF REQUIREMENTS

Not required.

3.SPECIFIC REQUIREMENTS

This section contains the software requirements to a level of detail, sufficient to enable designers to design the system.

3.1 EXTERNAL INTERFACE REQUIREMENTS

3.1.1 USER INTERFACES

The following screen will be provided:

Login Screen: This will be the first screen that will be displayed. It will allow users to access different screens based on the user’s role. Various fields available on the screen will be –● User Id● Password● Role

Student Info Parameters Screen: This screen will be accessible only to users with role Administrator. It will allow the user to access the student’s information.

Student Information Screen: This screen will be accessible only to users with role Administrator. It will allow the user to add/ modify/ delete information about new/ existing students for a particular semester. Semester- wise list of students will also be displayed. Various fields available on these screens will be –● Student Enrollment No.● Student Name.● Batch Year/ semester.

Subject Info Parameter Screen: This screen will be accessible only to users with role Administrator. It will allow the user to enter the semester number for which the user wants to access the subject information.

Subject Information Screen: This screen will be accessible only to users with role Administrator. It will allow the user to add/ modify/ delete information about new/ existing subjects for the semester that was selected in the ‘subject info parameter screen’. The list of available subjects for that semester, will also be displayed. Various fields available on this screen will be –♦ Subject Code.♦ Subject Name.♦ Category/ Type.♦ Credits.

Programme Info Parameter Screen: This screen will be accessible only to users with role Administrator. It will allow the user to enter information regarding the programmes offered by the university.

Programme Information Screen: This screen will be accessible only to users with role Administrator. It will allow the user to add/ modify/ delete information

about new/ existing programmes offered by the university. Various fields available on this screen will be – ♦ Prog. Code♦ Prog. Name♦ Duration♦ Fees

Students’ Subject Choice Parameter Screen: This screen will be accessible only to users with role Administrator. It will allow the user to enter the semester/batch year for which the user wants to access the students’ subject choice information.

Students’ Subject Choice Information Screen: This screen will be accessible only to users with role Administrator. It will allow the user to add/ modify/ delete information about new/ existing students’ subject choice for a particular semester. For the selected semester it will display the list of available choices for electives.

Faculty Info Parameter Screen: This screen will be accessible only to users with role Administrator. It will allow the user to enter the list of faculty in the university.

Faculty Information Screen: This screen will be accessible only to users with role Administrator. It will allow the user to add/ modify/ delete information about new/ existing faculty list in the university. Various fields available on this screen will be –♦ Faculty Id♦ Faculty Name♦ Department

Student List Report Parameters Screen: This screen will be accessible only to user with role Coordinator. It will allow the user to enter the batch year/semester for which the user wants to view/print the students’ list report.

Students’ Subject Choices List Report Parameters Screen: This screen will be accessible only to user with role Coordinator. It will allow the user to enter the batch year/semester for which the user wants to view/print the students’ subject choices list report.

Subject List Report Parameters Screen: This screen will be accessible only to user with role Coordinator. It will allow the user to enter the batch year/semester for which the user wants to view/print the subjects’ list report.

Programmes List Report Parameters Screen: This screen will be accessible only to user with role Coordinator. It will allow the user to enter the details of the programmes for which the user wants to view/print the programmes list report.

Faculty List Report Parameters Screen: This screen will be accessible only to user with role Coordinator. It will allow the user to enter the details of faculties in the university for which the user wants to view/print the faculty list report.

3.1.2 HARDWARE INTERFACES (specified )3.1.3 SOFTWARE INTERFACES (specified)3.1.4 COMMUNICATION INTERFACES (specified)

3.2 SYSTEM FEATURES

3.2.1 SUBJECT INFORMATION MAINTENANCE

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, semester, credits. The system will allow creation/ modification/ deletion of new/ existing subjects also have the ability to list all the available subjects for a particular semester.

Validity Checks: ♦ Only user with role Data Entry Operator will be authorized to access

the Subject Information Maintenance module.♦ Number of papers will be fixed for every semester.♦ No two semesters will have the same subject.♦ Subject code will be unique for every subject.♦ Subject name & subject code cannot be blank.♦ Credits cannot be blank.♦ Subject type & semester cannot be blank.

Sequencing Information: Subject info for a particular semester will have to be entered in the system before the starting of the session.

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 STUDENTS INFORMATION MAINTENANCE

Description: The system will maintain information about the various students registered in the school courses in different years. The following information would be maintained for each student: enrollment no., student name, year of enrollment. The system will allow creation/ modification/ deletion of new/ existing students and also have the ability to list all the available students enrolled in a particular year.


the Student Information Maintenance module.♦ Every student will have a unique Enrollment number.♦ Enrollment Number cannot be blank.♦ Student name cannot be blank.♦ Enrollment Year cannot be blank.

Sequencing Information: Student info for a particular semester will have to be entered in the system before the starting of the session.


3.2.3 STUDENTS’ SUBJECT CHOICES INFORMATION MAINTENANCE

Description: The system will maintain information about choice of different Elective subjects opted by various students of different enrollment years in different semesters. The following information would be maintained: student enrollment number, semester, students’ choice for elective 1& elective 2. The system will allow creation/ modification/ deletion of students’ subjects choices also have the ability to list all the available students’ subjects choice for a particular semester.


the Students’ Subject Choice Information Maintenance module.

♦ The subject choice for elective 1 & elective 2 can be made only from the list of available choices for that semester.

Sequencing Information: Students’ Subject choice info for a particular semester will have to be entered in the system only after subject info and student info has been entered in the system for the given semester.


3.2.4 PROGRAMME INFORMATION MAINTENANCE

Description: The system will maintain the information about various courses offered by the university. The following information would be maintained: prog. Code, prog. Name, prog. Duration. The system will allow creation/ modification/ deletion of new/ existing programmes also have the ability to list all the available programmes in the university.


the Programmes information Maintenance module.♦ The prog. Code will be unique.

Sequencing Information: Programmes offered by the university will have to be entered in the system before the starting of session and its approval in the university.


3.2.5 FACULTY INFORMATION MAINTENANCE

Description: The system will maintain the information about the details of the faculty members in the university. The following information would be maintained: Faculty Id, Faculty name, department. The system will allow creation/ modification/ deletion of new/ existing details of the faculty members and also have the ability to list faculty details.


the Faculty information Maintenance module.♦ The faculty id will be unique.♦ One faculty can belong to only one department.

Sequencing Information: Faculty details in the university will have to be entered in the system after appointment by the university for a particular department.


3.2.6 REPORT GENERATION

Students’ List Report: For each year a report will be generated containing the list of students enrolled.

Name of University Name of the Program List of Students enrolled in year xxxxS.No. Student Enroll. Number Student Name

1.2.

Students’ Subject Choices List Reports: For each batch year a report will be generated containing the list of students and their choices for the elective subjects in the selected semester.

Name of University Name of the Program

S.NO Student Enrollment Number

Student Name

Elective 1 Elective 2 Topic/ Subject Area of

Dis- sertation(for 4

Code Name Code Name

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 system. The following information would be maintained: user name, user ID, password, role.

Validity Checks: ♦ Only user with role Administrator will be authorized to access the user

accounts information maintenance module.♦ User name cannot be blank.♦ User ID cannot be blank.♦ User ID should be unique for every user.♦ Password cannot be blank.♦ 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.


3.3 FUNCTIONAL & NON- FUNCTIONAL REQUIREMENTS

Some other general requirements include:● The system shall generate the admission slips based on the admission

procedure.● The system shall record information about admission.● The system shall provide to instructor record their students’

information.● The system shall allow administrator to add, delete and search student

and faculty information.● The system shall be able to search and record the faculty and students

details.● The system shall report some user requirements.● The system shall give authority according to user id and password.● The system shall support multi-user feature.● The requirements generated and information received should be

conveyed to only authorized personals. Non-functional requirement include quality requirements. They are stated by the developers themselves.

3.4 PERFORMANCE REQUIREMENTS

● Speed – Product will perform any action by the user in minimal span of time.

● Space – System will perform efficient memory allocation.

3.5 USABILITY REQUIREMENTS

Product is expected to be user-friendly and easy to use. The system should behave as expected.

3.6 SOFTWARE SYSTEM ATTRIBUTES

3.6.1 SECURITY

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

3.6.2 MAINTAINABILITY

The application will be designed in a maintainable manner. It will be easy to incorporate new requirements in the individual modules (i.e. subject info. , student info., subject choice etc.)

3.6.3 PORTABILITY

The application will be easily portable on any windows-based system.

3.6.4 AVAILABILITY

Changes in the environment, modifications to service expectations, recent service outages or unplanned downtime can drive the organization to address the availability need. The system will increase the availability of the existing system.

3.6.5 RELIABILITY

The system will correctly deliver the services as expected by the users.

3.7 SOFTWARE ACCEPTANCE CRITERIA

The developer will have to demonstrate that the system works on the data for last few semesters or years. The developer will have to show through test cases that all conditions expected are satisfied.

3.8 LOGICAL DATABASE REQUIREMENTS

The following information will be placed in a database:

➢ Subject Info: Subject Name, Code, Credits, Type and Semester.

➢ Student Info: Student enrollment number, Student Name, Enrollment Year

➢ Students’ Subject Choice Info: Student Enrollment Number, Semester, Choice of Elective 1 & Elective 2.

➢ Programme Info: Prog. Name, Prog. Code, Duration.

➢ Faculty Info: Faculty ID, Faculty Name, Department.

➢ User Account Info: Username, UserID, Password, Role.

3.9 OTHER REQUIREMENTS

None.

CONTEXT DIA-GRAM

LEVEL- 1 DFD

LEVEL- 2 DFD

ERD

CLASS DIAGRAM

NSIT SAD lab FILE

Documents