Professional Documents
Culture Documents
3.1 Software Requirements Specification 3.1.1 Introduction Nowadays, in a highly technology society, human productivity is made more efficient through the development of electronic gadgets. Now with the advance of such modernization in education, one way to globalize the process of research is to realize that technology is advancing in the incredibly fast face. The system caters the monitoring part of the faculty. The system can help the school to easily identify who did not teach in the class and the systems can help monitor the reports of every teacher and schools such as performance attendance and the teachers class that he/she not attended. The system focus on monitoring the faculty of the school this system is best used to be able to know if each of the persons involved in the faculty really doing its job or not and to be able to monitor the faculty staffs late and absences and the performance of the faculty staff. And to monitor faculty staff, faculty scheduling and faculty advising. 3.1.1.1 Goals and objectives The proposed Faculty Monitoring System aims to improve Schools to monitor the faculty staff. By having computerized record of students and uniform monitor of different subject will be easier. Redundancies of work and manual computations will become seldom and capability of handling, organizing, securing and disposing of relevant data will be improved and strengthen.
Page 1
3.1.1.2 Statements of scope A faculty access privileges within the system are determined by its job description. The administrator will have unlimited access in the system where as faculty teachers will have fewer privileges as described below. Administrators are responsible for registering new user in the system. It is responsible to create, view, edit or update all account information. In faculty teachers department, the assistant act as the administrator in monitoring the faculty teachers attendance, faculty schedules, and the advising is the one that given by the principal. As the faculty arrives to the school the faculty teachers has a account to the system to input the time of their arrival and has access to view their schedules and the administrator or assistant will view the date and time of their arrival to the system. To monitor the late of the teachers. Administrators can access a reporting feature in the system. Those reports can be view and print by the administrator. There are important reports in monitoring the teachers such as Report of late and absences, Report of performance, promotions. The following table groups user requirements into various categories. Each requirement is assigned a priority to indicate whether it must be implemented (High) or may be left out (Low). Low priority requirements may be eliminated. Medium priority requirements are not essential and their implementation will be determined as program progresses. User Requirements for the Faculty monitoring System Req. No. Access Privileges R1 High Teacher There shall be two levels of access; one for the administrator and one for the assistant. Priority Reference Description
Page 2
R2
High
Teacher
R3
Med
Teacher
Only the administrator and assistant shall be allowed to view or print reports.
R4
Med
Teacher
Only the administrator and assistant shall be allowed to view or print invoices.
R5
High
Teacher
Only the administrator and assistant shall be allowed to view the monitored reports of the faculty teachers.
R6
High
Teacher
All teachers shall be allowed to view daily reminders on their account to the system.
Security R7 High Teacher Each user shall be required to log on with a unique user name and password before using the system the password does not need to be unique. R8 Low Code Works The username shall be the first four characters of the employees last name followed by the three characters of its first name.
Page 3
R9
High
Teacher
R10
Med
Code Works
After two unsuccessful attempts to enter a password the user shall be locked out of the system until its password is reset.
R11
High
Teacher
R12
Low
Teacher
If there is no activity for 10 minutes the user shall be logged of the system.
Account Information R13 High Teacher The users account shall contain the following: 1.User ID 2.User name 3.Password 4.First name 5.Middle name 6.Last name 7. User Privileged
Page 4
R14
High
Teacher
The software shall support the ability to create, store, edit and update users account.
R15
High
Teacher
User Interface R16 High Teacher The system shall respond to all users within few seconds. R17 Low Teacher The background color of all windows shall be blue.
3.1.1.3 Software context The faculty monitoring system is efficient in terms of monitoring the faculty teachers performance schedules assigning faculty teachers who can substitute for the absent faculty teachers and also it can monitors the contract expiry date of each faculty members 3.1.1.4 Major constraints The proposed Collection System used Java application which is netbeans-7.3.1-javasewindows. This software is used in developing the design of user interfaces which required jdk-6-
Page 5
windows-i586 installer. The proponent used MySQL and mysql-connector-java-5.1.22-bin to support its database. 3.1.2 Usage scenario 3.1.2.1 User profiles The following definitions describe the actors in the system. Administrator Administrator has the responsibility to view important reports. It has
unrestricted access to the system including viewing and updating accounts. It is also responsible for creating schedules for the faculty members. Faculty member Faculty member is teaching personnel who is employed in the school to teach students. System System refers to the computer hardware and software that controls the application.
Page 6
3.1.2.2 Use-cases The following use-cases are typical interactions between the external environment and internal software system. Each use-case is described in section 3.1.2.2.2. 1. Log onto the system. 2. Time-in / out 3. View and print reports 4. View and update user account information 5. Create schedules 6. View schedules 7. Input data of the faculty member
Page 7
3.1.2.2.1 Use-case Diagram The use-case diagram in Figure 1 shows six actors that were described in section 3.1.2.1. In order to minimize the complexity of this diagram several connection were left out. The employee could be an administrator, assessor or tellers. Instead of drawing separate connections to each of these actors, the employee was added to make the diagram easier to read.
Time out
Time in
Faculty member
Create schedules
View schedules
Administrator
Account managemen t
Display reports
System
Display information
Input data
Faculty
Page 8
3.1.2.2.2Use-case Descriptions Table 1: Use-case Description Use-case: Primary actor: Goal in context: Preconditions: Trigger: Scenario: Log on to the System Employee To gain access to the system The employee has a valid username and password. An employee needs access to the System to perform its job. 1. The system prompts the employee for their username and password. 2. The employee enters their username and password. 3. The system verifies the entered. Username and password. 4. The system sends back the password registered to the username. 5. The System verifies the password and sets the users authorization. 6. The employee is given access to the System to perform its job. Exceptions: The username and password cannot be verified.
Page 9
Time in /out Faculty member To record attendance The faculty member has its own username and password Administrator needs to monitor the faculty members attendance 1. Faculty member logs onto system. 2. The faculty member input data of its arrival(log-in) in or departure(log out) 3. The system records arrival or departure of the faculty member.
Exceptions:
View and print reports Administrator To view reports Information required for the reports has previously been entered. An administrator decides to view Reports of Career Portal which is about the contact and skills of the faculty member or schedules.
Page 10
Scenario:
1. The Administrator logs onto System. 2. The Administrator selects View Reports from the Main menu. 3. The Administrator selects the name of the report from the Report Menu. 4. The System requests the report from the database.. 5. The report is displayed on the screen. 6. The Administrator is given the option to close or print the report. 7. The report is closed or printed.
Exceptions:
Input faculty members data Assistant To create record for the faculty member The administrator hired the teacher give information about the faculty member.
Trigger: Scenario:
Administrator wants a teacher to have records in the system 1. The Assistant logs onto system. 2. The assistant selects career portal and record contract details or may select create schedules to record schedules of an employee to determine the availability of the faculty member during school days.
Page 11
3. The assistant may input the data. 4. The assistant records the data. 5. The system store the data. Exceptions:
Display Reports System To provide a particular report for the administrator. The data required in the report has already been entered. The administrator want to view a particular reports 1. The administrator logs onto system. 2. The administrator selects report from the main menu. 3. The system will get report information from database. 4. The system will display the report on the screen.
Exceptions:
View and update user account Administrator To view or to update information contained in a user account. The account exists and the exact spelling of the name is known. 1. Administrator needs to issue new password 2. Account information has changed and needs to be updated.
Page 12
Scenario:
1. The administrator logs onto system. 2. The administrator select view account information from the main menu. 3. The system prompts for the name or ID of employee. 4. The system will search from its records. 5. A report of the record or information is displayed on the screen. 6. If the administrator wants to edit account information the administrator selects Edit Account Information. 7. The administrator edits appropriate fields. 8. The administrator selects save. 9. The system sends the updated record to the database. 10. The administrator receives confirmation that the information was saved.
Exceptions:
View schedules Employee To view schedules Schedules have already been entered in the system. An employee wants to view schedules. 1. The teller logs onto system.
Page 13
2. The employee selects view schedules from the main menu. 3. The employee input its ID. 4. The system search and display schedules details 5. The report is closed. Exceptions:
Create schedules Administrator To create a schedule The faculty member is hired. A faculty must have schedules. 1. The administrator logs on to system. 2. Administrator selects create schedules from the main menu. 3. The administrator saves the input data. 4. The system stores the data.
Exceptions:
Page 14
3.1.2.3 Special usage consideration 3.1.2.4 Activity Diagrams The following activity diagrams show the actions that occur during a particular use-case. The Figure 1 shows the steps taken as an employee logs on to the computer system. Access is only granted if the correct user ID/password combination is entered within the first three attempts. After the third attempt, the user ID will be locked out and an administrator will need to issue new password. Once access is granted the employee can use the system according to their level of authorization.
[<3]
Verify password
[<3]
Check number of bad entries
[Incorrect]
[correct]
Access
Page 15
Employee Data Object User ID User name Password First Name Last Name A unique number assigned to the employee the employees user name The employees password The employees first name The employees last name
Designation The job classification of the employee limited to the users only. Change Data Object Users ID User Name First Name Last Name The number of the employee changing the record. The employees username. The employees first name. The employees last name.
Page 16
Schedule Data Object Time in Time out Schedule the employee time in arrival the employee time out in school the employee schedule in of teaching in school
3.1.3.2 Relationships
ACADEMIC KEY
Academic Year Key Academic Year Acad Year Begin Term Begin Year End Year
Page 17
Student class
Page 18
3.1.4.2.1 External machine interfaces Table 2 :External Machine Interfaces Processor Pentium 4/Intel(R) Dual CPU 1.60GHZ and above (for better performance) Memory Not less than 512 MB RAM Minimum of 80GB HDD / 160 HDD(Hard Disk Drive) up to 500 GB HDD for larger storage
The system will be capable of printing reports on a local printer. 3.1.4.2.2 External System Interfaces Table 3: External System Interfaces Database Software Operating System MySQL Windows 32bits/64bits XP, Windows
Page 19
3.1.4.2.3 Human Interface The system interface shall permit to complete navigation using mouse and keyboard combinations and a printer for printing of receipt. 3.1.4.3 Reports
3.1.4.3.1 Inventory of Reports Reports of faculty schedules who can substitute absent faculty members Faculty performance Faculty promotions salaries and designation
3.1.5 Behavioral Model Description 3.1.5.1 Description for software behavior 3.1.5.1.1 Events 3.1.5.1.2 States 3.1.5.2 State chart Diagram
Page 20
3.1.6 Restrictions, Limitations, and Constraints The proponent use MySQL for the database. An employee must have an account to gained access to the system. The users interfaces accessibility will be based on the designation of the employee. Deleting and altering of data from the database is restricted. The administrator should not make an account with the same username while password is allowed to be the same. Entry of username and password does not exceed in three trials. The proposed system focuses on monitoring the faculty teachers only. The system did not cater the enrollment system and all enrolled students. The system did not cater the payroll system of the student. The system also not cater the grading system.
3.1.7 Validation Criteria Software validation will ensure that the system responds according to the users expectation; therefore it is important that the end users be involved in some phases of the tests procedures. 3.1.7.1 Classes of test Unit testing will be conducted on all software subsystems including: Log on to the System Generating and viewing of reports
Page 21
3.1.7.2 Expected software response It should also display an error message when password is incorrect. The system is not capable in deleting of records or altering of data in the database. 3.1.7.3 Performance Bounds The system shall support up to as many users will logon to the system in the whole day.
Page 22