Professional Documents
Culture Documents
Software Engineering Practical File IPU
Software Engineering Practical File IPU
SOFTWARE
ENGINEERING FILE
Submitted By
SUBMITTED TO:
EXERCISE – 1
AIM: -
To write the problem statement of STUDENT RESULT MANAGEMENT SYSTEM.
REQUIREMENTS: -
1. SOFTWARE REQUIREMENT – Microsoft Word
2. HARDWARE REQUIREMENT – Computer, Keyboard, Mouse, CPU
THEORY: -
A university conducts 8 – semester B. Tech program divided into 4 branches namely CSE, IT,
ECE and EEE. The students are offered 6 theory papers and 5 lab papers in all semesters. The
theory papers offered in the 4th year are categorized as either ‘Core’ or ‘Elective’. Core papers do
not have alternative subject whereas elective papers have 2 other alternative subjects. Thus, a
student can take up any subject out of the 3 given choices.
The evaluation of each subject is done out of 100 marks. For theory paper, the division is 75+25
for externals and internals respectively. For lab paper, the division is 60+40 for externals and
internals respectively. 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 attendance, marks are given out of 25 in theory paper and 40 in lab
paper. These marks account for internal evaluation if the students. At the end of each semester
major exams are conducted in each subject (theory as well as practical). The theory papers are
evaluated out of 75 marks and lab papers are evaluated out of 60 marks. Thus, the total marks of
a student in a subject are obtained by adding the marks obtained in internal and external
evaluation.
The students are required to submit a minor project report based on their summer training in 5 th
semester and a major report based in other summer training in 7 th semester. These are evaluated
out of 100 marks based on the report submitted, the presentation given and the viva response.
Every subject has some credits assigned to it. If the total marks of a student are >=50, he/she is
considered ‘PASS’ otherwise ‘FAIL’. If the student is fail in a subject, he/she has to reappear for
the subject next year in order to earn the credits.
It is required to develop a system that will manage information about subjects offered in various
semesters, students enrolled in various semesters, electives opted by the students and marks and
credit points obtained by the students in different semesters. The system should also have the
ability to generate mark sheet for each student semester-wise. Semester-wise detailed marks list
and student performance report also need to be generated.
CONCLUSION:-
Problem statement of STUDENT RESULT MANAGEMENT SYSTEM has been written
successfully.
EXERCISE – 2
AIM:-
To do the requirement analysis and develop Software Requirement Specification Sheet for
STUDENT RESULT MANAGEMENT SYSTEM.
REQUIREMENTS:-
3. SOFTWARE REQUIREMENT – Microsoft Word
4. HARDWARE REQUIREMENT – Computer, Keyboard, Mouse, CPU
THEORY:-
1. INTRODUCTION
This document aims at defining the overall software requirements for STUDENT
RESULT MANAGEMENT SYSTEM. Efforts have been 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/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
This specification document describes the capabilities that will be provided by the
software application STUDENT RESULT MANAGEMENT SYSTEM. It also states
the various required constraints by which the system will abide. The intended
audiences for this document are the development team, testing team and end users of
the product.
1.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 B. 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 the list of students marks
obtained by all students in a particular semester and performance of students (rank-
wise, percentage-wise, pass/fail) will be generated. The system will also generate
printable mark-sheets for individual students.
The application will greatly simplify and speed up the result preparation and
management process.
1.4 REFERENCES
(i) University website: For information about course structure of B. Tech
Program
(ii) IEEE Recommended Practice for Software Requirement Specifications –
IEEE Std 830-1993
1.5 OVERVIEW
The rest of this SRS document describes the various system requirements, interfaces,
features and functionalities in detail.
2. OVERALL DESCRIPTION
B. Tech Program is a 8-semester course. The students are offered 6 theory papers and 5
lab papers in all semesters. The students are required to submit a minor project report
based on their summer training in 5th semester and a major report based in other summer
training in 7th semester. Each subject/lab/term paper has credits associated with it. When
a student secures pass marks in a paper he/she also earns all the credit(s) assigned tothat
paper.
The SRMS will have the capability to maintain information about students enrolled in the
course, the subjects offered to students in 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
performance reports. Printable mark-sheets of individual students will also be generated
by the application.
2.1.7 OPERATIONS
This product release will not only cover any automated housekeeping aspects
of the database. DBA at the client site 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 data from
the database.
2.4 CONSTRAINTS
(i) 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.
(ii) Due to limited features of DBMS being used, database auditing will also not
be provided.
(iii) Users at University will have to implement a security policy to safe-guard the
marks-related information from being modified by unauthorized users (by
means of gaining access to the backend database).
3. SPECIFIC REQUIREMENTS
This section contains the software requirements to a level of detail sufficient to enable
designers to design the system, and testers to test the system.
VALIDITY CHECKS
(i) Only the user with role Data Entry Operator will have authorized
access to Students’ Subject Choice Information Maintenance module.
(ii) Every student will have a unique Enrollment Number.
(iii) Enrollment number cannot be blank
(iv) Name cannot be blank.
(v) Branch cannot be blank.
SEQUENCING INFORMATION
Students’ Subject Choice Information for a particular student can be entered
in the system only after Subject Information has been entered in the system
for given semester and branch and the Student Information for that student has
been entered in the system.
Students’ Subject Choice Information for a particular student will have to be
entered in the system before any marks information can be entered for that
student in the given semester and branch.
ERROR HANDLING/RESPOSE TO ABNORMAL SITUATIONS
If any of the above validations/sequencing flow does not hold true,
appropriate error messages will be prompted to the user to do the needful.
NAME OF UNIVERSITY
NAME OF PROGRAM
SEMESTER <no.>
BRANCH <name>
MARK-SHEET
ENROLLMENT
No.:________________________ NAME:____________________________
S. SUBJEC INTERNA EXTERNA TOTA CREDIT
No. THEORY/LAB T L L L P/F S
1
2
3
4
5
6
7
8
9
10
11
MARKS GRAND TOTAL
TOTAL:_________/600 CREDITS:_____________
_
RESULT:(pass/fail)
DATE:_____________
__
SIGNATURE OF CONTROLLER OF
EXAMINATION
There will be a ‘PRINT’ icon at the top of the mark-sheet for printing it.
VALIDITY CHECKS
(i) Only user with role Marks Entry Clerk will be authorized to access the
Mark-sheet Generation module.
SEQUENCING INFORMATION
Marks-sheet for a particular student can be generated by the system only after
Subject information, Student information, Students’ Subject Choice
information and Marks information has been entered for that student in the
given semester and branch.
ERROR HANDLING/RESPOSE TO ABNORMAL SITUATIONS
If any of the above validations/sequencing flow does not hold true,
appropriate error messages will be prompted to the user to do the needful.
NAME OF UNIVERSITY
NAME OF PROGRAM
BRANCH <NAME>
BATCH YEAR <YYYY>
ENROLLMENT
S. No. NUMBER NAME
1
2
3
STUDENTS’ SUBJECT CHOICES LIST REPORT
For each year, a branch-wise report will be generated containing the list of
students of 4th year and their choices for Elective subjects in 7th or 8th semester.
Report format will be as shown below:-
NAME OF UNIVERSITY
NAME OF PROGRAM
BRANCH <NAME>
SEMESTER <No>
ELECTIVE 1 ELECTIVE 2
S. ENROLLMEN
NAME COD
No. T NUMBER
E NAME CODE NAME
1
2
3
NAME OF UNIVERSITY
NAME OF PROGRAM
BRANCH <NAME>
SEMESTER <No>
GRAN
S. D
ENROLLMEN PERCENTAG RAN DIVISIO
No NAME TOTAL
T NUMBER E K N
. MARK
S
1
2
3
3.5.1 SECURITY
The application will be password protected. Users will have to enter correct
username, password 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 individual modules.
3.5.3 PORTABILITY
The application will be easily portable on any windows-based system that has
Oracle 10g Express Edition installed.
5. DOCUMENT APPROVALS
(i) Anureet Kaur Bhatia
(ii) Anchal Bansal
6. SUPPORTING INFORMATION
For more information, email us at the following address – [email protected].
CONCLUSION:-
Requirement analysis of STUDENT RESULT MANAGEMENT SYSTEM has been done and
its Software Requirement Specification Sheet has been written successfully.
EXERCISE – 3
AIM:-
To draw the ER Diagram for STUDENT RESULT MANAGEMENT SYSTEM.
REQUIREMENTS:-
1. SOFTWARE REQUIREMENT – Microsoft Word, MS Paint
2. HARDWARE REQUIREMENT – Computer, Keyboard, Mouse, CPU
THEORY:-
CONCLUSION:-
ER Diagram forSTUDENT RESULT MANAGEMENT SYSTEM has been drawn successfully.
EXERCISE – 4
AIM:-
To draw the Use Case Diagram for STUDENT RESULT MANAGEMENT SYSTEM.
REQUIREMENTS:-
1. SOFTWARE REQUIREMENT – Microsoft Word, Rational Rose Enterprise Edition
2. HARDWARE REQUIREMENT – Computer, Keyboard, Mouse, CPU
THEORY:-
CONCLUSION:-
Use Case Diagram forSTUDENT RESULT MANAGEMENT SYSTEM has been drawn
successfully.
EXERCISE – 5
AIM:-
To write the Use Case Description of STUDENT RESULT MANAGEMENT SYSTEM.
REQUIREMENTS:-
5. SOFTWARE REQUIREMENT – Microsoft Word
6. HARDWARE REQUIREMENT – Computer, Keyboard, Mouse, CPU
THEORY:-
1. LOGIN
1.1 Brief Description
This use case describes how a user logs into the Student Result Management System.
1.2 Actors
(i) Data Entry Operator
(ii) Marks Entry Clerk
(iii) Administrator
(iv) Coordinator
1.3 Pre – Conditions
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.
1.4 Post – Conditions
If the use case was successful, the actor is logged into the system. If not, the system
state remains unchanged,
If the actor has the role ‘Data Entry Operator’, he/she will have access to only screens
corresponding to the Subject Info Maintenance, Student Info Maintenance and
Students’ Subject Choice Info Maintenance modules of the system.
If the actor has the role ‘Marks Entry Clerk’, he/she will have access to only screens
corresponding to the Marks Info Maintenance module of the system.
If the actor has the role ‘Coordinator’, he/she will only be able to view/print the
various reports generated by the system.
If the actor has the role ‘Administrator’, he/she will have access to only screens
corresponding to the User Account Maintenance module and Reset System feature of
the system.
1.5 Flow of Events
1.5.1 Basic Flow
This use case starts when the actor wishes to log into the Student Result
Management System.
(i) 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, Administrator and Coordinator.
(ii) The actor enters his/her name, password and role.
(iii) The system validates the entered name, password, and role and logs
the actor into the system.
1.5.2 Alternative Flow
1.5.2.1 Invalid Name/Password/Role
If in the basic flow, the actor enters an invalid name, password and/or role,
the system displays an error message. The actor can choose to either return
to the beginning of the basic flow or cancel the login, at which point the
use case ends.
1.6 Special Requirements
None
1.7 Related Use Cases
None
8. RESET SYSTEM
8.1 Brief Description
This use case allows the actor to rest the system by deleting all the existing
information from the system.
8.2 Actors
Administrator
CONCLUSION:-
Use Case Description of STUDENT RESULT MANAGEMENT SYSTEM has been written
successfully.
EXERCISE – 6
AIM:-
To draw the Level – 0 and Level – 1 Data Flow Diagram (DFD) for STUDENT RESULT
MANAGEMENT SYSTEM.
REQUIREMENTS:-
1. SOFTWARE REQUIREMENT – Microsoft Word, MS Paint
2. HARDWARE REQUIREMENT – Computer, Keyboard, Mouse, CPU
THEORY:-
Level – 0 Data Flow Diagram:-
Level – 1 Data Flow Diagram:-
CONCLUSION:-
Level – 0 and Level – 1 Data Flow Diagram (DFD) forSTUDENT RESULT MANAGEMENT
SYSTEM have been drawn successfully.
EXERCISE – 7
AIM:-
To draw the State Chart Diagram for STUDENT RESULT MANAGEMENT SYSTEM.
REQUIREMENTS:-
1. SOFTWARE REQUIREMENT – Microsoft Word, Rational Rose Enterprise Edition
2. HARDWARE REQUIREMENT – Computer, Keyboard, Mouse, CPU
THEORY:-
CONCLUSION:-
State Chart Diagram forSTUDENT RESULT MANAGEMENT SYSTEM has been drawn
successfully.
EXERCISE – 8
AIM:-
To draw the Class Diagram for STUDENT RESULT MANAGEMENT SYSTEM.
REQUIREMENTS:-
1. SOFTWARE REQUIREMENT – Microsoft Word, Rational Rose Enterprise Edition
2. HARDWARE REQUIREMENT – Computer, Keyboard, Mouse, CPU
THEORY:-
EXERCISE – 9
AIM:-
To draw the Activity Diagram for STUDENT RESULT MANAGEMENT SYSTEM.
REQUIREMENTS:-
1. SOFTWARE REQUIREMENT – Microsoft Word, Rational Rose Enterprise Edition
2. HARDWARE REQUIREMENT – Computer, Keyboard, Mouse, CPU
THEORY:-
CONCLUSION:-
Activity Diagram for STUDENT RESULT MANAGEMENT SYSTEM has been drawn
successfully.
EXERCISE – 10
AIM:-
To draw the Sequence Diagrams for STUDENT RESULT MANAGEMENT SYSTEM.
REQUIREMENTS:-
1. SOFTWARE REQUIREMENT – Microsoft Word, Rational Rose Enterprise Edition
2. HARDWARE REQUIREMENT – Computer, Keyboard, Mouse, CPU
THEORY:-
(a) LOGIN
REQUIREMENTS:-
1. SOFTWARE REQUIREMENT – Microsoft Word, Rational Rose Enterprise Edition
2. HARDWARE REQUIREMENT – Computer, Keyboard, Mouse, CPU
THEORY:-
(a) LOGIN
CONCLUSION:-
Collaboration Diagrams for STUDENT RESULT MANAGEMENT SYSTEM has been drawn
successfully.