3. CodeWar
2Softawre Requirement Specification
Table of Contents
Table of Contents
1 Introduction...................................................................................................3
1.1 Purpose ...................................................................................................4
1.2 Scope ......................................................................................................4
1.3 Definitions, Acronyms, and Abbreviations ...................................................4
1.4 Overview..................................................................................................5
2 Overall Description .........................................................................................5
3 Specific Requirements.....................................................................................6
3.1 Functionality ............................................................................................6
3.1.1 Details of registered students to classes should be maintained................6
3.1.2 Details of available classes and lessons should be maintained. ................6
3.1.3 Details of class allocations for both students and teachers should be
maintained.....................................................................................................6
3.1.4 Administrators should be able to register new students to relevant classes.
7
3.1.5 Students’ attendance should be maintained. ..........................................7
3.1.6 Students’ payments should be maintained.............................................7
3.1.7 Activities and grades of the students must be maintained. ......................7
3.1.8 Students’ progress can be monitored. ...................................................7
3.1.9 Teacher’s attendance and working hours should be maintained...............7
3.1.10 Generate monthly salary for teachers at the end of the month. ................7
3.1.11 Users should be able to have different user based access levels. ..............8
4. CodeWar
3Softawre Requirement Specification
3.2 Non Functional Requirements.....................................................................8
3.2.1 Familiar Interface ................................................................................8
3.2.2 Maintainability....................................................................................8
3.2.3 Security..............................................................................................8
3.2.4 Availability .........................................................................................9
3.2.5 Reliability and Performance..................................................................9
3.2.6 Real Time Feedback.............................................................................9
3.3 Design Constraints....................................................................................9
3.4 Technologies..........................................................................................10
Software Requirements Specification
1 Introduction
“SaRiGaMa” music school requires a complete, comprehensive and integrated
management information system.
5. CodeWar
4Softawre Requirement Specification
1.1 Purpose
The SRS describes the external behavior of the management information system
identified. It also fully describes the functional, non-functional requirements
and design constraints.
1.2 Scope
The scope of the management information system for the “SaRiGaMa” music
school is to;
➢ maintain student records
● student registration
● allocation to classes
● attendance
● progress monitoring
● fee payment
➢ maintain teacher records
● allocation to classes
● attendance
● working hours
➢ generate monthly payments for teachers
➢ provide different user based access levels
1.3 Definitions, Acronyms, and Abbreviations
Student ID - The identification number that each student is given by the Sarigama
musical school.
Instructor ID - The identification number that each records instructor is given.
6. CodeWar
5Softawre Requirement Specification
1.4 Overview
Section 2 contains an overall description of the user’s perspective of the database which describes
the general factors that affect the product and its requirements. Section 3 provides information
about the specific requirements in detail including functional and nonfunctional requirements,
design constraints that are crucial to design the software. The last section includes the supporting
information.
2 Overall Description
The main perspective of the system is to keep track of student data and teacher
details.
This system would be able do the following functions ensuring security and failure
free. Lessons are given via group classes or individual classes. Same student may learn
more than one instrument. Starting from student registration, allocation to classes,
attendance, progress monitoring, fee payment etc will be maintained on the MIS. Also
teacher information and allocation to classes’ attendance and working hours will also
be maintained. Student registration process considers keeping information about
parents and also information about siblings who are students. End of month payments
for teachers will also be generated fromthe system.
7. CodeWar
6Softawre Requirement Specification
Two different access levels should also be provided to the admins and teachers to
access the MIS. Only admins are allowed add new teacher profiles and assign new
resources to the system. They have the right to access the entire application. Teachers
are supposed to track student activities and view their details. students can only
update their profiles, view course contents and do assigned exercises. calculating
teacher payments and progress monitoring will be automated.
3 Specific Requirements
3.1 Functionality
3.1.1 Details of registered students to classes should be maintained.
Details of new students such asstudent id, name, age, address, contactdetails should be maintained
in the database. Other requirements about parents and other siblings who are students should also
be maintained in the database.
3.1.2 Details of available classes and lessons should be maintained.
Details of the classes such as the duration, fee, days, prerequisites, maximum capacity of students,
available capacity of students have to be maintained. These details will have to be checked before
selecting students for particular classes and to update them whenever necessary.
3.1.3 Details of class allocations for both students and teachers should be maintained.
Details of student id, class id (and teacher id, class id) should be maintained in a relationship entity
table to allocate students to classes at the time they register and also to check which student takes
part which classes whenever necessary.
8. CodeWar
7Softawre Requirement Specification
3.1.4 Administrators should be able to register new students to relevant classes.
When registering new students to their preferred classes, administrators will have to access to class
and class allocation details. They will register new students depending on the availability
(vacancies) of particular classes. The classes will be allocating immediately for selected students
at the registration.
3.1.5 Students’ attendance should be maintained.
Attendance on each day for all classes should be maintained in the database.
3.1.6 Students’ payments should be maintained.
Fee payments of the students should be maintaining in the database.
3.1.7 Activities and grades of the students must be maintained.
When an activity is done by a student, the relevant details such as student id, activity id, grade, date
should be maintained in the database.
3.1.8 Students’ progress can be monitored.
Student progress should be generated and displayed from the system based on the details of
students’ activities and grades.
3.1.9 Teacher’s attendance and working hours should be maintained.
3.1.10 Generate monthly salary for teachers at the end of the month.
End of month payments for teachers should also be generated from the system based on the
teacher's’ attendance working hours, and the classes they take part. This will require those details
of relevant classes such as teachers’ allocation to classes etc...
9. CodeWar
8Softawre Requirement Specification
3.1.11 Users should be able to have different user based access levels.
The system should have different access levels to be provided to the admin and teachers to access
the MIS.
3.2 Non Functional Requirements
3.2.1 Familiar Interface
Two different accesslevels will be provided to the admins and teachersto access the
MIS. Teachersmay not be familiar with the automated system. Therefore, new system
should have an interface with necessary optionsfor easy access of information.
3.2.2 Maintainability
Student registration,allocation to classes, progressmonitoring etc.should be
implemented without affecting the other part of the system and should be able to add
new functionality.
3.2.3 Security
End of month paymentsfor teachersshould also be generated from the system and
also payments, attendance, registration etc. should be handle using this new system.
Therefore, system should be use strong authentication mechanism.
10. CodeWar
9Softawre Requirement Specification
3.2.4 Availability
100% of the time available server and enough capacity of database should be needed
to this new MIS.
3.2.5 Reliability and Performance
Less failure of the system, readily available functionality and allow concurrent users.
3.2.6 Real Time Feedback
The new management information system should display the daily attendance,
progressof the students, fee payment etc. and should also show the changesin real-
time as the new entry is added or removed.
3.3 Design Constraints
Domain Integrity
In the SaRiGaMa application’s database attributes will be restricted accordingly with real world
semantics on data. For example,
• Teacher ID, student ID must be unique.
• Teacher’s age should have to be more than 20 years and according to that date of birth attribute
will have some constraints. While it is 11 years (or according to the age given by the Music
school) for the students.
• No zero payments for the teachers
11. CodeWar
10Softawre Requirement Specification
• When registering a student there must be at least one parent or a guardian.
Entity Integrity
• Unique id is given for the student as well as for teachers to recognize them accurately.
• Null values are not accepted for attributes like date of birth, teacher ID, student ID, etc.
Referential integrity
Make sure that there are no orphan records that means there must be a foreign key’s value must be
found in the corresponding entity. For example, consider the following two tables
learned_instrument (student_id, instrument_name)
instrument (instrument_name,[other attributes])
There should be a unique value matched in the instrument table for the foreign key, instrument_name
which is found from the learned_instrument table.
Foreign key rules
Responsible for what will happen for the child rows when the record with the primary key is deleted or
updated. For example,
If a student dropouts from the school the database will not let the student to be deleted if there are other
records such as learned music, attendance,etc. but if there could be found only the registration, deleting
the primary key make the registration record to be deleted (CASCADE)
Cardinality
Focus about the real relationships that the entities possess. For example the relationship between
student and teacher is many to many, student and instrument is many to many likewise focus
on the cardinality.
Concurrent access anomalies
Database is designed accordingly, that two students cannot enroll for one single place for a
particular music lesson.
Atomicity
If a failure occurs this database ensure that the data will restored. Suppose that if a student
unenrolled a music lesson to enroll another music lesson if unenrolling caused a trouble making
the student couldn’t make his/her choice then the state of the data should go back to the
previous state.
Security problems
Not every user of the database system allows to access all the data.
Teachers cannot add or delete the tables. Only the admin can alter or change the tables.
3.4 Technologies
MySQL workbench - to design Entity Relationship diagram