System Requirements Document for Course-Planning
- Problem
The Administration performs following functions like managing Professors and managing Students and managing Subjects and managing Streams and managing Schedules. Administration manages time schedule to the Professors for teaching. Suppose when add a new professor Administration checks all the Professors schedules and assign subjects to new professor. Suppose change in schedule of any professor may or may not collapse other professors schedule so every time Administration need to check all the professors schedules and this same issue may occur at Student level also, which makes problem to Professors and Student schedule.
This problem can be overcome through using Course-Planning software. Which automatically arrange Professors and Student schedule. Course-Planning software also saves time it provides accuracy, reduce work, save cost , improve performance, requires less time to plan.
Implementation Module:
- Course-Planning/Schedule management.
Course-Planning/Schedule management:-
Course-Planning/Schedule is designed to offer time-saving services:
- Add / Update / Delete professors.
- Add / Update / Delete students.
- Add / Update / Delete subjects.
- Add / Update / Delete streams.
- Add / Update Schedules for Course-Planning in this manage professors to teach their subjects and students to assign their subjects.
- Objectives
- Improve the speed of managing schedule.
- Improve the accuracy of the schedule.
- Improve the accuracy of the schedule during update or deleting schedule.
- Improve managing professors or subjects or students or streams or subjects.
- Reduce the time and work to managing schedule to Professors.
- Reduce the time and work to managing schedule to Students.
- Reduce cost and faster performance.
- Existing system
Administration manages time schedule to the Professors for teaching. Today any new Professor or Student add to Course-Planning Administration checks all the Professors schedules and assign subjects to new professor. Suppose change in schedule of any professor may or may not collapse other professors schedule so every time Administration need to check all the professors schedules and this same issue may occur at Student level also, which makes problem to Professors and Student schedule.
The Administration has identified these problems:
- Administration makes errors entering a new Professor time schedule.
- Administration makes errors entering a new Student time schedule.
- Administration makes errors determining and giving out change.
- Administration takes more time to check out other Professors time schedules.
- Director does not have a way to check all the Professors schedules.
- Director also takes more time to check out other Professors time schedules if update time schedule of any professor.
- Functional Requirements
- Maintain Professors information (add, update, delete)
- Professor First Name
- Professor Last Name
- Professor Email-Id
- Maintain Student information (add, update, delete)
- Student First Name
- Student Last Name
- Student Email-Id
- Maintain Subject information (add, update, delete)
- Subject Name
- Subject Description
- Maintain Stream information (add, update, delete)
- Stream Name
- Maintain Schedule information (add, update, delete)
- Professor Schedule
- Professor First Name
- Professor Last Name
- Professor Email-Id
- Courses per semester
- Semester
- Professor Schedule
- Maintain Schedule information (add, update, delete)
- Student Schedule
- Student First Name
- Student Last Name
- Student Email-Id
- Courses per semester
- Semester
- Control access to all management functions (maintenance)
- Identify specific user either Administration/Director
- Ensure the user either Administration/Director login in is who they say they are (single password is sufficient)
- Non-Functional Requirements
- Usability
- The system must be easy to use so that Administrator can quickly make schedule. There are often new professors or students so it is important for the system to be quick to create a new schedule.
- Administrator should be able to maintain new schedule after enter any new professor or student.
- Administrator should be able to effectively operate the functions.
- Reliability
- The system must be highly reliable since, if the system is not available, the Administrator can’t easily make schedules.
- Performance
- All schedules should be performed in under 1 second.
- All functions look ups should be performed in under 1 second.
- The system must be easy to use so that Administrator can quickly make schedule. There are often new professors or students so it is important for the system to be quick to create a new schedule.
- Supportability
- The system will be able to automatically install updates received from the software development team.
- Training
- The system should provide a training mode that can be used by Administrator/Director being trained. In training mode, the system does not log actual tasks.
- The system should provide on screen help.
- The system should come with training documentation.
- Target Environment
The system must normally function on a standalone Windows 10 based PC with 4G of memory and 200 GB hard drive.
Software Requirements:
Languages: | Java Swings |
Operating Systems: | Window7 |
Databases Server: | MySql 5.0 |
Tools/IDE : | Eclipse SDK |
- Use Cases
This is a list of use cases identified for this system. The definition of each use case follows.
- Sign in
- Sign out
- Add Professor
- Update Professor
- Delete Professor
- Add Student
- Update Student
- Delete Student
- Add Subject
- Update Subject
- Delete Subject
- Add Stream
- Update Stream
- Delete Stream
- Add Schedule
- Delete Schedule
- Update Schedule
- View Professors
- View Students
- View Subjects
- View Streams
- View Schedules
System Authorization Use Cases
- Sign In
- Sign Out
Name | Sign in |
Description | Grant a user access as an authorized user either Administrator/Director |
Actor(s) | Administrator/Director |
Flow of Events | 1. Administrator/Director wants to use the system.
2. Administrator/Director selects to Log in 3. Administrator/Director enters credentials 4. System tests the credentials and grant access or shows and error. |
Special Requirements | Require credentials (username and password)
|
Pre- Conditions | Administrator/Director has previously be set up in the system |
Post- Conditions | Administrator/Director is authorized to the system if requirements and exceptions are met. |
Exceptions | Credentials do not match shows error/exception |
Name | Sign out |
Description | Remove a Administrator/Director access to the System |
Actor(s) | Administrator/Director |
Flow of Events | 1. Administrator/Director wants to end using the system.
2. Administrator/Director selects to log out. 3. System logs out the Administrator/Director. |
Special Requirements | |
Pre- Conditions | Administrator/Director is currently authorized to the system |
Post- Conditions | No Administrator/Director is currently authorized if requirements and exceptions are met. |
Exceptions | There must be a Administrator/Director authorized before a use can be logged out. |
Professors Maintenance Use Cases
- Add Professor
- Update Professor
- Delete Professor
Name | Add Professor |
Description | Add the information for a new Professor to the Course-Planning. This happens when new Professor arrive in the system. For the newProfessor, first name and last name and email-id added. |
Actor(s) | Admin |
Flow of Events | 1. A new Professor arrives in the Course-Planning.
2. Admin selects to add a new Professor 3. Admin enters information about the Professor 4. Admin selects to save the Professor |
Special Requirements | Require Professor first name and last name and email-id.
|
Pre- Conditions | Admin has be authorized to the system |
Post- Conditions | Professor is added to system if requirements are met and there are not special exceptions. |
Exceptions | Do not add if Professor exists in system |
Name | Update Professor |
Description | Update the information for an existing Professor in the system. This happens when a correction is required. |
Actor(s) | Admin |
Flow of Events | 1. A change in Professor information is detected.
2. Admin selects to update a Professor. 3. Admin selects Professor to update. 3. Admin enters information about the Professor. 4. Admin selects to update the Professor. |
Special Requirements | Require first name and last name and email-id
|
Pre- Conditions | Admin has be authorized to the system |
Post- Conditions | Professor is updated in system if requirements and exceptions are met. |
Exceptions | Validation must follow for first name and last name and email-id when update Professor. |
Name | Delete Professor |
Description | Delete the information for an existing Professor in the system. |
Actor(s) | Admin |
Flow of Events | 1. Professor is identified that needs deletion.
2. Admin selects to delete a Professor. 3. Admin selects Professor to delete. 4. Admin deletes Professor. |
Special Requirements | |
Pre- Conditions | Admin has be authorized to the system |
Post- Conditions | Professor is deleted from system if requirements and exceptions are met. |
Exceptions | Do not delete when exception occur.
|
Students Maintenance Use Cases
- Add Student
- Update Student
- Delete Student
Name | Add Student |
Description | Add the information for a new Student to the Course-Planning. This happens when new Student arrive in the system. For the new Student, first name and last name and email-id added. |
Actor(s) | Admin |
Flow of Events | 1. A new Student arrives in the Course-Planning.
2. Admin selects to add a new Student 3. Admin enters information about the Student 4. Admin selects to save the Student |
Special Requirements | Require Student first name and last name and email-id.
|
Pre- Conditions | Admin has be authorized to the system |
Post- Conditions | Student is added to system if requirements are met and there are not special exceptions. |
Exceptions | Do not add if Student exists in system |
Name | Update Student |
Description | Update the information for an existing Professor in the system. This happens when a correction is required. |
Actor(s) | Admin |
Flow of Events | 1. A change in Student information is detected.
2. Admin selects to update a Student. 3. Admin selects Student to update. 3. Admin enters information about the Student. 4. Admin selects to update the Student. |
Special Requirements | Require first name and last name and email-id
|
Pre- Conditions | Admin has be authorized to the system |
Post- Conditions | Student is updated in system if requirements and exceptions are met. |
Exceptions | Validation must follow for first name and last name and email-id when update Student. |
Name | Delete Student |
Description | Delete the information for an existing Student in the system. |
Actor(s) | Admin |
Flow of Events | 1. Student is identified that needs deletion.
2. Admin selects to delete a Student. 3. Admin selects Student to delete. 4. Admin deletes Student. |
Special Requirements | |
Pre- Conditions | Admin has be authorized to the system |
Post- Conditions | Student is deleted from system if requirements and exceptions are met. |
Exceptions | Do not delete when exception occur.
|
Subject Maintenance Use Cases
- Add Subject
- Update Subject
- Delete Subject
Name | Add Subject |
Description | Add the information for a new Subject to the Course-Planning. This happens when new Subject arrive in the system. For the new Subject, subject name and subject description. |
Actor(s) | Admin |
Flow of Events | 1. A new Subject arrives in the Course-Planning.
2. Admin selects to add a new Subject 3. Admin enters information about the Subject 4. Admin selects to save the Subject |
Special Requirements | Require Subject fields subject name and subject description.
|
Pre- Conditions | Admin has be authorized to the system |
Post- Conditions | Subject is added to system if requirements are met and there are not special exceptions. |
Exceptions | Do not add if Subject exists in system |
Name | Update Subject |
Description | Update the information for an existing Subject in the system. This happens when a correction is required. |
Actor(s) | Admin |
Flow of Events | 1. A change in Subject information is detected.
2. Admin selects to update a Subject. 3. Admin selects Subject to update. 3. Admin enters information about the Subject. 4. Admin selects to update the Subject. |
Special Requirements | Require subject name and subject description |
Pre- Conditions | Admin has be authorized to the system |
Post- Conditions | Subject is updated in system if requirements and exceptions are met. |
Exceptions | Validation must follow for subject name and subject description when update Subject. |
Name | Delete Subject |
Description | Delete the information for an existing Subject in the system. |
Actor(s) | Admin |
Flow of Events | 1. Subject is identified that needs deletion.
2. Admin selects to delete a Subject. 3. Admin selects Subject to delete. 4. Admin deletes Subject. |
Special Requirements | |
Pre- Conditions | Admin has be authorized to the system |
Post- Conditions | Subject is deleted from system if requirements and exceptions are met. |
Exceptions | Do not delete when exception occur.
|
Stream Maintenance Use Cases
- Add Stream
- Update Stream
- Delete Stream
Name | Add Stream |
Description | Add the information for a new Stream to the Course-Planning. This happens when new Stream arrive in the system. For the new Stream, stream name. |
Actor(s) | Admin |
Flow of Events | 1. A new Stream arrives in the Course-Planning.
2. Admin selects to add a new Stream 3. Admin enters information about the Stream 4. Admin selects to save the Stream |
Special Requirements | Require Stream fields stream name.
|
Pre- Conditions | Admin has be authorized to the system |
Post- Conditions | Stream is added to system if requirements are met and there are not special exceptions. |
Exceptions | Do not add if Stream exists in system |
Name | Update Stream |
Description | Update the information for an existing Stream in the system. This happens when a correction is required. |
Actor(s) | Admin |
Flow of Events | 1. A change in Stream information is detected.
2. Admin selects to update a Stream. 3. Admin selects Stream to update. 3. Admin enters information about the Stream. 4. Admin selects to update the Stream. |
Special Requirements | Require stream name |
Pre- Conditions | Admin has be authorized to the system |
Post- Conditions | Stream is updated in system if requirements and exceptions are met. |
Exceptions | Validation must follow for stream name when update Stream. |
Name | Delete Stream |
Description | Delete the information for an existing Stream in the system. |
Actor(s) | Admin |
Flow of Events | 1. Stream is identified that needs deletion.
2. Admin selects to delete a Stream. 3. Admin selects Stream to delete. 4. Admin deletes Stream. |
Special Requirements | |
Pre- Conditions | Admin has be authorized to the system |
Post- Conditions | Stream is deleted from system if requirements and exceptions are met. |
Exceptions | Do not delete when exception occur.
|
View Professors/Students/Subjects/Streams/Schedules Maintenance Use Cases
- Update Schedule
- View Professors
- View Students
- View Subjects
- View Streams
View Schedules
Name | View Professor |
Description | View Professors to see all the Professors data. |
Actor(s) | Admin / Director |
Flow of Events | 1. Admin / Director selects to View Professors |
Special Requirements | No requirements |
Pre- Conditions | Admin / Director has be authorized to the system |
Post- Conditions | At least one professor is there in the System. |
Exceptions | No Exceptions |
Name | View Student |
Description | View Student to see all the Students data. |
Actor(s) | Admin / Director |
Flow of Events | 1. Admin / Director selects to View Student |
Special Requirements | No requirements |
Pre- Conditions | Admin / Director has be authorized to the system |
Post- Conditions | At least one student is there in the System. |
Exceptions | No Exceptions |
Name | View Subject |
Description | View Subjects to see all the Subjects data. |
Actor(s) | Admin / Director |
Flow of Events | 1. Admin / Director selects to View Subjects |
Special Requirements | No requirements |
Pre- Conditions | Admin / Director has be authorized to the system |
Post- Conditions | At least one subject is there in the System. |
Exceptions | No Exceptions |
Name |
View Streams |
Description | View Streams to see all the Streams data. |
Actor(s) | Admin / Director |
Flow of Events | 1. Admin / Director selects to View Streams |
Special Requirements | No requirements |
Pre- Conditions | Admin / Director has be authorized to the system |
Post- Conditions | At least one stream is there in the System. |
Exceptions | No Exceptions |
Name | View Schedules |
Description | View Schedules to see all the Schedules data in this to see Professors and Students schedules. |
Actor(s) | Admin / Director |
Flow of Events | 1. Admin / Director selects to View Schedules to see all the Schedules data in this to see Professors and Students schedules |
Special Requirements | No requirements |
Pre- Conditions | Admin / Director has be authorized to the system |
Post- Conditions | At least one schedule is there in the System. |
Exceptions | No Exceptions |
Name | Update Schedule |
Description | Update the Schedule information for an existing Schedule. It contains Professor Schedule and Student Schedule. Professor schedule contains Professor First name and Last name and Courses per semester and Semester and Student schedule contains Student First name and Last name and Courses per semester and Semester. |
Actor(s) | Admin / Director |
Flow of Events | 1. A change in Schedule information is detected.
2. Admin / Director selects to update a Schedule. 3. Admin / Director Schedule Stream to update. 3. Admin / Director enters information about the Schedule. 4. Admin / Director selects to update the Schedule. |
Special Requirements | Require stream name |
Pre- Conditions | Admin / Director has be authorized to the system |
Post- Conditions | Schedule is updated in system if requirements and exceptions are met. |
Exceptions | Validation must follow for Schedule at backend. |
Subject Maintenance Use Cases
- Add Schedule
- Delete Schedule
Name | Add Schedule |
Description | Add the Schedule. It contains Professor Schedule and Student Schedule. Professor schedule contains Professor First name and Last name and Courses per semester and Semester and Student schedule contains Student First name and Last name and Courses per semester and Semester. |
Actor(s) | Admin |
Flow of Events | 1. A new Schedulearrives in the Course-Planning.
2. Admin selects to add a new Schedule
|
Special Requirements | In the database must contain professors and students and subjects data and backend run automatically create a new Schedule by the Course-Planning software
|
Pre- Conditions | Admin has be authorized to the system |
Post- Conditions | At least one professor or student or subject data exists. |
Exceptions | Do not add if no Subjects or Professors or Students data exists in Database. |
Name | Delete Schedule |
Description | Delete the information for an existing Schedulein the system. |
Actor(s) | Admin |
Flow of Events | 1. Scheduleis identified that needs deletion.
2. Admin selects to delete a Schedule. 3. Admin selects Scheduleto delete. 4. Admin deletes Schedule. |
Special Requirements | |
Pre- Conditions | Admin has be authorized to the system |
Post- Conditions | Scheduleis deleted from system if requirements and exceptions are met. |
Exceptions | Do not delete when exception occur. |
Glossary
Term | Definition |
Admin | Admin employee who is responsible for the Add/Update/Delete Professors or Add/Update/Delete Students or Add/Update/Delete Subjects or Add/Update/Delete Streams or Add/Update/Delete Schedules data. |
Director | A Director employee who is responsible for the View Professors / Students / Subjects/ Streams/ Schedules data and Update Schedule data. |
Professor | Professor employee who is responsible for the teaching Subjects according to his/her schedule. |
Student | Student who is responsible for studying subjects according to his/her schedule. |
Stream | Stream is dividing Courses/Streams like Electronics / Computers/Software/Mechanical |
Schedule | A schedule or a timetable, as a basic time-management tool, consists of a list oftimes at which possible tasks, events, or actions are intended to take place, or of a sequence of events in the chronological order in which such things are intended to take place. |
System | In this document System means Course-Planning |
Subject | A branch of knowledge studied or taught in university |
Download Course Planning System Java Project.
Can you please send me the source code of course planning project in Java at maanikgoyal@gmail. Urgent please
Can you please send me the source code of course planning project in Java.
can you send me the code of this course planning project.
hi
Can you please send me the source code of course planning project in Java.
thanks