Curriculum Manage System Chapter I I I

Student Information System
Chapter III
3.1 Software Requirements Specification

3.1.1 Introduction Curriculum Management System requires the specific role of a user onto system. This chapter represents on how the requirements describe as will to easy comprehend, to illustrate on how the flow and portrait different diagram like relationship, activity diagram, state chart diagram, and use case diagram to be clearly understand what system is. From this chapter, it will help the end-users to know the usage and those scenarios, the acknowledgement, the intention, the purpose and admission to the system. 3.1.1.1 Goal and Objectives The purpose of this document is to describe the requirement of the school that will include the revision of their existing system to become accelerate with accurate reports. It is important that the project must meet or reached the expectation and achieve the good transaction to be attaining the satisfactory of client. This document uses written descriptions as well as various types of different diagrams to illustrate the high level structure of the application. Although some of the diagrams may seem ti convey similar information they typically do so from an alternate perspective. This give different stakeholder a view of the requirements that is better suited to their area of responsibility. 3.1.1.1.2 General Objective 3.1.1.1.2.1 To develop an existing curriculum management system in managing school year. The Curriculum Management System helps Grace Montessori School of Novaliches to input/transfer immediately data and information process or transactions on that day to be done soon as possible.
Grace Montessori School of Novaliches (Curriculum Management System)
Page 3- 1
Student Information System 3.1.1.2 Statement of Scope To explain the user requirement and are those needed things to consider in creating a system and considered as necessary because it guides how the system will make and to consider the needs of the users. Illustrate the various types of different diagram show the different function and explanation how the system for. Those diagrams help the users to understand the function and to help the user to manipulate the system by them. A complete and descriptive detail of system requirement and a complete scenario of the system process with the use of different diagram to illustrate the structures of the application. Thus, the management of the data and transaction will be all computerized. Before gaining access to the Curriculum management system, user will be required to enter their user name and password. A user access privileges within the system are determined by their job classification. The Administrator will have unlimited access whereas registrar and student will have fewer privileges below. The following table groups are user requirements and segregate this into various categories. The requirement is assigned priority requirements to indicate whether it must be implemented (high) or (medium) and (low). High priority requirements are essential requirement of the system. Medium priority requirements are not essential or didnt totally focus just fulfilling to become or called a whole system. And low priority is requirements may be eliminated if it helps meet the scheduled delivery date.
Page 3- 2
Student Information System Req. No. Access Privileges R1 High Program There have been three character or access designations: one for administrator, the second user is registrar and the last can access the system those students have account.
Priority
Reference
Description
R2
High
Administrator
The administrator capable to edit all account information, system data and implement new update in system.
R3
Medium
Administrator and Registrar
Administrator and Registrar are allowed to print those request reports.
R4
High
Student
Viewing
and
updating
an
account
information and daily reminder of school or system
R5
High
Administrator
The administrator has authorizations to change the registrar setting privileges.
R6
High
Administrator
The administrator is allowed to add new account, subject, event calendar and those memorandums of DepEd.
Page 3- 3
Student Information System Security R5 High Program All users have a unique User ID and password required to log onto system. R6 Medium Code Access Access granted if account is valid when after third attempt the user account will be locked. R7 High Administrator An account shall be assigned by administrator to each user. R8 High User The account user shall contain 10-12 alphanumeric characters. R9 High Administrator After five unsuccessful attempts to enter, the account shall be locked out until 12hrs retrieve. R10 High Administrator A new password shall be
assigned by administrator if users forget his/her password. R11 Low User If there is no activity or idle for 15 minutes the user automatically shall be logged off onto the system. R12 High Program Log-in form of weve made system have user Designation before gain to access the system.
Page 3- 4
Student Information System Account Information R13 High Program Store, keeping and update record like, subject information, student information, and curricular
information. As well for; new curricular implemented, subjects, grade level, time, room, section, assign teacher, schedule and other detail. The users account record shall contain information: R15 High Student User ID User Password Email address Access level the following
R14
High
User
The student account record shall contain information: Name Photo Gender Age Date of birth Address Email address Phone number the following
Page 3- 5
Student Information System R16 High Database The table subject record shall contain information: Subject ID Subject Name Subject time implemented Subject date implemented Subject Description the following
R17
High
Database
The table grade level record shall contain information: Grade level ID Grade level name the following
R18
High
Database
The table grade level record shall contain information: Set subject ID Set subject name Set subject description the following
R19
High
Database
The table schedule record shall contain information: Grade level ID Section ID Room ID Set subject ID Day ID Time ID Page 3- 6 the following
Student Information System Teacher ID Description ID
R20
High
Database
The table curricular activities record shall contain the following information: Activities ID Activities name Date Time Event place Event Description
R21
High
Database
The table section record shall contain information: Section ID School year Section name Number of student the following
R22
High
Database
The table time and date record when login shall contain the following information: TimeID DateID Status
R23
High
Program
User log notes shall store the date and time.
Page 3- 7
R24
High
Database
The table section record shall contain information: Teacher ID Teacher name the following
R25
High
Program
Student reports shall be print all of the information of the student including the name, age, birth date, contact information and their scheduled.
R26
High
Program
Master list report shall alphabetically list the name of the student categorized by male and female.
Page 3- 8
Reminders R27 High Administrator Administrator shall only allow setting the daily reminders in system.
R28
Medium
Administrator
The administrator limit enters 60 character messages only for the reminders.
R29
Medium
Code Access
The time/date of reminder or event shall be show and we selected from calendar.
R30
Low
User
When user log onto the system, the first that can saw in
displaying in screen are those reminders.
R31
Low
User
The user can view the current and recently event by selected or click date at calendar.
R32
Medium
Administrator And Registrar
Administrator and registrar are allowed to print those reminders and event description.
Page 3- 9
Student Information System 3.1.1.3 Software context However, the functionalities of Curriculum Management Information Systems (CMS), have lagged significantly behind the capacities of current hardware and software technologies, while the complexity of the information produced by school has been increasing over time and will soon undergo rapid expansion with the use of new, high-throughput and high-dimensionality language. In the broadest sense, CMS are essential to manage the flow of information between the curricular provide by DepEd, should be designed to optimize not only school managing but also personalized student welfare when it comes curricular. In order to cope the project the proponents will be using different types of software O.S Windows 7 Professional Service pack 1 32 bit 1Gb(RAM) for document purposes & O.S Windows 7 ultimate 64Bit Processor AMD ATHLON 1.60 GH,3.6 GB(RAM) & Eclipse Indigo 3.7, MySQL Version 5.6 11MySQLyog Ultimate XAMPP win32version 1.8.3 XCII MSWord 2010 this are the software were going to use in able to perform the project. 3.1.1.4 Major Constraints All new code shall be documented using the BCP be documented using BCPians journey to project study documentation system. The Student information system, language will be use java eclipse 3.7 environment which requires a database like MySQL supporting this technology.
Page 3- 10
3.1.2 Usage Scenario

3.1.2.1 User profiles There have (3) three characters can access the system; one for the registrar and their assistant then for student and one for administrator. The following definition describes the actor in the system. Administrator or Principal The one capable or allowed to edit all data like account/user information and those old/new subjects that have availability to add a new user and curriculum implemented by DepEd.and etc. Creating and Updating with setting and activating a current school year activities and subjects with the use of the computerized system the user can easily filter and print all the student request When DepEd has contract a new subject or change it their subject name, the administrator shall be allowed to create or add subjects at subject list, that will create an new description for new subject. So, the old subjects become now fix but can edit by administrator and can gathered data or subject report of those alumni that can browse and printable. The present subject lists will process continuously keeping stored a data.
Registrar or Assistant The registrar is the one is accountable for keeping the good maintenance of the previous and current data and files of each student. The system provide the registrar to update those student account information and reminders to can generate a print reports. Viewing, updating, browser, editing data those not fix like subject description, subject list and etc. The things that cant act are didnt allowed to edit those old subjects taken by the alumni and no access to create other new users or account.
Page 3- 11
Student Only viewing and updating his/her old/current info.
System The system refers to the computer hardware and software that control the application. The system can also generates reports, provide user access, store data into the database and have the features of add information, editing, saving and printing.
Web-Based The Web server is a remote computer system that maintains the database and serves Web pages to the System. WEB based with all students to update easily will communicate with Web server on the internet through a high speed network connection WEB based is designed for those clients who are busy and doesnt have time to go to school?
Lan-Based Is a computer network that interconnects computers in a limited area such as a home, school, computer laboratory, office building, for walk in transaction.
Page 3- 12
Student Information System 3.1.2.2 Use-cases The following use-cases are interaction between the external environment and the internal software system. Each use-case are all described in 3.2.2.1 Student log onto system Administrator or Registrar log onto system View and Update account information Subject implemented onto system Print/view reports Subject teacher assign Grade level/ Set subject scheduled Set a calendar New / Set User Display daily reminder Searching Diagram Sign out onto system
Page 3- 13
Student Information System 3.2.2.1 Use-Case Diagram The use-case diagram, shows 3 (three) actors with different job description maybe theyre a little bit comparison but each of them have limited cant do in system; every use -cases will typically involve an interaction with the system wave made. The principal can be administrator.
Page 3- 14
Student Information System 3.2.2.2 Use-Case Descriptions Use-case: Primary actor: Goal in context: Preconditions: Log on to System Student To gain access to the System. The student has a valid user name and password. The account of student cant be use or log by the other user. Trigger: A student needs to access to the system to update his/her current scheduled and subject information. Scenario: 1. The Student logs onto the web server System. 2. The Student selects user designation. 3. The Student enters the Login ID and Password. 4. The system verifies the Login ID and password 5. If Student enters (3) three times attempt incorrect the account has been locked. 6. Only administrator can retrieve student account. 7. Access granted invalid account enter. 8. Message box will show saying ACCESS GRANTED 9. The Student is given access to view/update. 10. The Student views the daily reminders. 11. The Student click Update button. 12. Viewing student information. 13. Viewing student scheduled. 14. Viewing Curricular Activity. 15. Viewing Calendar event Activity. 16. The System will displayed the suggest info. 17. The Student is given access to view/update. Exceptions: The user name and password cannot be verified.
Page 3- 15
Student Information System Use-case: Primary actor: Goal in context: Preconditions: Trigger: Log on to System Administrator or Registrar To gain access to the System. The Administrator or Registrar has a valid user name and password. Administrator or Registrar needs to access to the system to update the scheduled and current subject information. Scenario: 1. Logs onto the System.
2. Select user designation. 3. Enters the Login ID and Password. 4. Verify the account. 5. System will displayed message prompt. 6. If administrator enters (3) three times attempt incorrect the account has been locked out on 12hrs. 7. Access granted invalid account enter. 8. Message box will show saying ACCESS GRANTED 9. Record the time and date logged. 10. Given access to manage system base in their job description.
Exceptions:
The user name and password cannot be verified.
Use-case:
Update account Information Page 3- 16
Student Information System Primary actor: Goal in context: Preconditions: Administrator/Registrar The administrator updates the account information. Administrator is only allowed to update all account information while Registrar is only allowed to update all Student account information onto system. Trigger: Administrator needs to access to the system to edit and update the changes of account information. Scenario: 1. Administrator logs onto the System. 2. Administrator enters the Login ID and Password. 3. Verify the administrator/Registrar account. 4. Access granted invalid account enter. 5. Administrator/Registrar time and date logged. 6. Click the button of account information. 7. Administrator/Registrar views the old and current account. 8. Administrator can view all account information while Registrar only allowed to all student account. 9. Select Account information. 10. Enter student/registrar ID number. 11. Edit and update the student account. 12. Click the save button to be changes. 13. System will displayed message prompt. 14. Successfully update the account information. 15. Logged out to the system.
Exceptions:
Only student can update by registrar account information while administrator can edit all user account setting.
Page 3- 17
Student Information System Use-case: Primary actor: Goal in context: Preconditions: Trigger: Implementing Subject Administrator The Administrator implements a new subject onto system. Administrator is only allowed to add new subject onto system. Administrator needs to access to the system to add new subject implemented by DepEd going implement to the system. Scenario: 1. Administrator logs onto the System. 2. Administrator enters the Login ID and Password. 3. Verify the administrator account. 4. System will displayed message prompt. 5. If administrator enters (5) five times attempt incorrect the account has been locked out on 24hrs. 6. Access granted invalid account enter. 7. Administrator time and date logged. 8. Administrator Access to add and edit. 9. Administrator updates the subject list. 10. Administrator add new subject to the system. 11. Administrator enter subject name. 12. System will displayed message prompt. 13. When have same subject name, re-enter again. 14. Administrator set a subject description <100character. 15. When >100character subject description the system will display prompt message that the description is too long. 16. Administrator click save button to implement. 17. New subject display and stored in system. 18. System, record the time and date subject implemented. 19. Successfully implemented new subject. 20. Administrator time and date log out.
Exceptions:
Other users cannot access to implement except administrator.
Page 3- 18
Student Information System Use-case: Primary actor: Goal in context: Preconditions: Set a calendar activities Administrator/Registrar The Administrator/Registrar set events on the calendar of activities. The Administrator/Registrar is the only allowed setting the upcoming events and activities for the students. Trigger: The Administrator/Registrar needs to access to the system set the upcoming events and activities for the students. Scenario: 1. Logs onto the System. 2. Administrator/Registrar enters the Login ID and Password 3. Administrator/Registrar time and date logged. 4. Select Calendar date to view. 5. Shows categories, View required number of days, view makeup classes, view suspension of class. 6. System will determine user authorization. 7. Student has limited to access to be print. 8. Administrator and Registrar are allowed to view the information with categories 9. Administrator and Registrar will set the events or activities in a specific date. 10. Save changes made by the Admin/Registrar. 11. Post and display. 12. Admin/Registrar successfully set events or activities on calendar of activities.
Exceptions:
Students are not allowed to set upcoming events on the calendar of activities. Page 3- 19
Use-case: Primary actor: Goal in context: Preconditions: Trigger:
Subject teacher assign Administrator The Administrator/Registrar set Subject Teacher Assign. Administrator/Registrar is only allowed to assign the subject teacher. Administrator/Registrar needs to access to the system to assign the subject teacher.
Scenario:
1. Administrator/Registrar logs onto the System. 2. Administrator/Registrar Password. 3. Administrator/Registrar time and date logged. 4. Select teachers information and achievements. 5. Select another teacher if teacher is not qualified for the subject. 6. The selected teacher is suitable for the subject 7. Waiting for the date of seminar about the subject to be taught. 8. Teacher attended the seminar. 9. Administrator/Registrar successfully assign the subject teacher. enters the Login ID and
Exceptions:
Other
users
cannot
access
to
implement
except
Administrator/Registrar. Grace Montessori School of Novaliches (Curriculum Management System) Page 3- 20
Use-case: Primary actor: Goal in context: Preconditions:
View/Print Administrator/Registrar The Administrator/Registrar prints those student requests. The Administrator/Registrar allowed printing those reports, reminders, scheduled, event calendar activities and curricular activities.
Trigger:
The Administrator/Registrar needs to access to the system to print those student request.
Scenario: 1. Administrator/Registrar logs onto the System. 2. Administrator/Registrar enters the Login ID and Password 3. Verify the administrator/Registrar account. 4. Access granted invalid account enter. 5. Administrator/Registrar time and date logged. 6. Select categories information of student request to be print. 7. View the reports, reminders, subjects, curricular activities, calendar event activities and their scheduled. 8. User does want to print the choosing information. 9. System will determine user authorization. 10. Student has limited to access to be print. 11. Administrator and Registrar are allowed to print those student requests. 12. Administrator and Registrar view the student request to be print. 13. Prompt to be print and not to print. 14. Enter the number to be print. 15. Student request has been successfully print.
Exceptions:
Students are not allowed to print that report. Page 3- 21
View Set Calendar Administrator/Registrar The Administrator/Registrar prints those student requests. The Administrator/Registrar allowed printing those reports, reminders, scheduled, event calendar activities and curricular activities.
Trigger:
The Administrator/Registrar needs to access to the system to print those student request.
Page 3- 22
Student Information System Scenario: 1. Administrator/Registrar logs onto the System. 2. Administrator/Registrar enters the Login ID and Password 3. Verify the administrator/Registrar account. 4. Access granted invalid account enter. 5. Administrator/Registrar time and date logged. 6. Select categories information of student request to be print. 7. View the reports, reminders, subjects, curricular activities, calendar event activities and their scheduled. 8. User does want to print the choosing information. 9. System will determine user authorization. 10. Student has limited to access to be print. 11. Administrator and Registrar are allowed to print those student requests. 12. Administrator and Registrar view the student request to be print. 13. Prompt to be print and not to print. 14. Enter the number to be print. 15. Student request has been successfully print.
Exceptions:
Students are not allowed to print those report.
Page 3- 23
Use-case: Primary actor: Goal in context: Preconditions: Trigger: Scenario:
New / Setting User Administrator To create new user and their user setting The administrator has valid user name and password. Create new user and to set a user setting.
1. The Administrator logs onto the System. 2. The Administrator clicks the system set-up User setting button and edits setting or add new user. 3. The administrator create new user. 4. The administrator encodes the set user information. 5. Set the setting access to the system. 6. Tha administrator saves the changes. 7. The Administrator Edit the setting user. 8. The Administrator view the setting information. 9. The Administrator set changes in user setting. 10. The administrator saves the changes. 11. The administrator has been done in task.
Exceptions:
If the user does not log in as an administrator.
Page 3- 24
Use-case: Primary actor: Goal in context: Preconditions: Trigger: Scenario:
Searching User's To be accelerate the search information. All users are allowed to use search bar to be search. User needs to access or use the search bar on system.
1. The Users logs onto System. 2. The Users selects user designation. 3. The Users enters the Login ID and Password. 4. Access granted invalid account enter. 5. The Users click the search bar. 6. The Users enter to be search in search bar. 7. Press enter or click magnifying glass to be search. 8. System Data search loading. 9. System found show on screen. 10. The Users logged out.
Exceptions:
Page 3- 25
Log out onto system Users To Logged out in system. The users are allowed to log out. When users idle more 25 minute the account auto logged out.
Trigger: Scenario:
User needs to log out to the system.
1. The Users onto System. 2. If the Users idle more 25 minute the account auto logged out. 3. The Users idle less 25 minute are still in system. 4. The Users click the main menu.
5. The Users choose to click Sign out. 6. System message prompt "are you sure to sign out" 7. System message prompt " continue, cancel" 8. The Users has been Logged out.
Exceptions:
Page 3- 26
3.1.2.3 Special usage considerations 3.1.2.4 Activity diagrams

The following activity diagrams show the actions that occur during a particular use-case. Figure 1 shows the steps taken as a student to log on to the web server system. Access granted if account has correctly entered given by administrator to student when the combination is entered within the first three attempts their must will be locked out and an administrator will need to issue a massage warning or notification to student.
Figure 1 Activity diagram for Student logging on the system.
Page 3- 27
Student Information System In figure (2) two, show the steps taken as a administrator to log on to the computer system. An admin has capable main person can access the whole system. The administrator will first check the security to maintain the good transaction of a system.
Figure 2 Activity diagram for Admin logging on the system.
Page 3- 28
Student Information System In figure (3) three, show the steps how to implement a subject in system by an administrator to log on to the computer system.
Figure 3 Activity diagram for Implementing Subject on the system.
Page 3- 29
Student Information System In Figure 4 (four), shows the activity of updating account and viewing as in the diagram all users will be able to view their account information or reports displayed but only administrators is capable allowed to edit for updating all account while registrar only allowed to all student account information.
Figure 4 Activity diagram for Updating Account on the system.
Page 3- 30
Student Information System In Figure 5 (Five) show all user can access to view a report that displayed by administrator. Administrator and staff the only allowed to printing some report as need to print just inform or noted them.
Figure 5 Activity diagram for View with Print on the system.
Page 3- 31
Student Information System In figure (6) six, steps to show the set subject per grade level to the computer system.
Figure 6 Activity diagram for Grade level/set subject to the system.
Page 3- 32
Student Information System In figure (7) seven, show the steps to set a teacher Assign to per subject on the system.
Figure 7 Activity diagram for Teacher assign to the system. Page 3- 33
Student Information System In figure (8) eight, show the steps how to view the calendar of activities and how to create new description per date calendar on the system.
Figure 8 Activity diagram for View Set Calendar to the system. Grace Montessori School of Novaliches (Curriculum Management System) Page 3- 34
Student Information System In figure (9) nine, show the steps how to change the setting user and how to create new user on the system.
Figure 9 Activity diagram for New Set User to the system.
Page 3- 35
Student Information System In figure (10) ten, show the steps to view the Reminders on the system.
Figure 10 Activity diagram for Reminders to the system.
Page 3- 36
Student Information System In figure (11) eleven, show the steps taken as User to be search in computer system.
Figure 11 Activity diagram for searching to the system.
Page 3- 37
Student Information System In figure (12) twelve, show the steps taken as user to log out to the computer system.
Figure 12 Activity diagram for log out to the system.
Page 3- 38
Student Information System 3.1.3 Data Model Description 3.1.3.1 Data Object Subject Data Object Subject ID, An identifier assigned to the subject. Name, The subject name. Date Implement, The subject implemented date. Description, A description of the subject. Student Data Object Student ID, A code number assigned to the student. Password, An account password of a student. Name, The Student full name. Address, The Address of the student. Phone, The guardian and student phone number. Email, The email address of a student. Classification, The job description of the student are limited can viewing and updating his/her old and current info. Grade level subject Data Grade level ID, A code identifier assigned to the grade level subeject. Set subject, The subject list that set per grade level. Description, The set schedule list of subject. Administrator Data Object
Page 3- 39
Student Information System Admin ID, The account name of the Administrator. Password, The account password of the Administrator. Description, Has the authorization in all transactions of system. Registrar Data Object Username, The account ID name of the registrar. Password, The account password of the registrar. Description, The assistant of administrator in system. Change Data Object Change Data ID, The number of the changing record onto system. Time, The time of chance. Date, The date of chance. Description, The Data record chance. User Data Object Access level, The role of the user to be access the system. Name, The name of the User. Password, The password to secure the un-authorized alternation. Schedule Data Object Day, Pertaining to the daily assigned day schedule. Time, Pertaining to the indicated to the daily schedule time. Room, Pertaining to the room indicated where the schedule shall be taken. Reminder Data Object Page 3- 40
Student Information System ReminderID , A unique identifier for the reminder StudentID, The ID numbers of a student give an reminder. Date, The date of the reminder weve post Time, The exact time of the reminder weve post Message, The reminder message to be displayed
Login/Logout history Data Object Login ID, A unique number of log history. Logged Date, Date of logged. Logged Time, Exact time of logged. Logged Out, Exact time and date to be logged out to the system.
Page 3- 41
Student Information System 3.1.3.2 Relationships In order for a student to access the system, the students must go first to the administrator to create their account. Since admin is the only one that capable of creating new account for many students, one-to-many relationship exists.
Registrar manages the information of every student so one-to-many relationship exists. At the same time, the registrar makes schedule of every section so one-to-many relationship exists.
Every students has many schedules so one-to-many relationship exists. These schedules are not just the everyday subjects that they are taking but the curricular activities and events are also included on the schedules.
Administrator is the only one that capable of implementing new curriculum so one-to-one relationship exists. Only one curriculum is followed by every school and it is given by the memorandum of Dep-Ed.
Administrator has also a power to tamper the schedule made by the registrar for the students so one-to-many relationship exists. Administrator has also capable of making the schedule of every student thats why this relationship exists.
Reminder depends on the upcoming events of every student. Every student will receive a reminder if there are events or activity is near on the date. So zero-to-one relationship exists.
Page 3- 42
Student Information System 3.1.3.3 Complete data model The relationships between the data objects describe in 3.1.3.2 Relationships are shown in this figure (13) thirteen.
Figure 13 Relationship diagram for the Curriculum Management System.
Page 3- 43
Student Information System 3.1.4.1 Class Diagram The association between the diffent classes are shown in figure 14. The access functions to get and set private data attributes.
Figure 14 Curriculum Management System Class Diagram.
Page 3- 44
Student Information System 3.1.4.2 Data Dictionary of class diagrams Data Dictionary of Student Field Username Length 12
Type
Description Unique username of the student that can be a combination of letters and numbers only.
Varchar
Password
15
Varchar
Password of the user with variable length that may consist of letters and numbers.
Field STUD_ID STUD_ FNAME STUD_ LNAME STUD_MINITIAL STUD_GENDER STUD_AGE STUD_ADDRESS STUD_CONTACTNO STUD_EMAIL STUD_DOB STUD_POB STUD_PHOTO STUD_STATUS STUD_RELIGION Int Text Text Text Text Int Varchar Int Varchar
Type
Description Unique ID of the student Given name of the student Family name of student Mothers surname of the student Student sex How old is the student Location where student currently lives Contact no. of the student Student email address Date of birth of student Birth place of the student 1x1 photo of student The Student state Religion of the student
Date/Time Text Image Text Text
Page 3- 45
Data Dictionary of Administrator Field Username Length 12

Type
Description Unique username of the Administrator that can be a combination of letters and numbers only.
Varchar
Password
15
Varchar
Field ADMIN_ID ADMIN_FNAME ADMIN_LNAME ADMIN_MINITIAL ADMIN_GENDER ADMIN_AGE ADMIN_ADDRESS Int Text Text Text Text Int Varchar
Type
Description Unique ID of the Administrator Given name of the Administrator Family name of Administrator Mothers surname of the Administrator The Administrator sex How old is the Administrator Location where Administrator
currently lives ADMIN_CONTACTNO ADMIN_DOB ADMIN_POB ADMIN_PHOTO ADMIN_STATUS ADMIN_RELIGION Int Date/Time Text Image Text Text Contact no. of the Administrator Date of birth of Administrator Birth place of the Administrator 1x1 photo of Administrator The Administrator state Religion of the Administrator
Page 3- 46
Data Dictionary of Registrar Field Username Length 12

Type
Description Unique username of the Registrar that can be a combination of letters and numbers only.
Varchar
Password
15
Varchar
Field REG_ID REG_FNAME REG_LNAME REG_MINITIAL REG_GENDER REG_AGE REG_ADDRESS Int Text Text Text Text Int Varchar
Type
Description Unique ID of the Registrar Given name of the Registrar Family name of Registrar Mothers surname of the Registrar The Registrar sex How old is the Registrar Location where lives Registrar currently
REG_CONTACTNO REG_DOB REG_POB REG_PHOTO REG_STATUS REG_RELIGION
Int Date/Time Text Image Text Text
Contact no. of the Registrar Date of birth of Registrar Birth place of the Registrar 1x1 photo of Registrar The Registrar state Religion of the Registrar
Page 3- 47
Student Information System Data Dictionary of Scheduled Field SCHED_CURRACTIVITIES SCHED_CALENDAR SCHED_GRADELEVEL SCHED_SECTION SCHED_ROOM SCHED_DAY SCHED_TIME SCHED_SUBJECT SCHED_TEACHER Varchar Varchar Int Int Text Date Time Date/Time Date/Time Type Description Set schedule for curricular activities Event schedule in calendar Unique ID of Grade Level Unique ID for sectioning Unique number for room name The exact day of schedule The exact time of schedule The set subject of schedule The teacher schedule assigned
Data Dictionary of Implement Curricular Field IMPLE_SETSUBJECT IMPLE _SUBNAME IMPLE _DATEIMPLE IMPLE _TIMEIMPLE IMPLE _SUBDES Int Text Date Time Text Type Description Unique ID for set subject The subject name Exact date implemented subject Exact Time implemented subject The subject description
Data Dictionary of Reminder Field REM_CURRENTDATE REM _RECENTDATE REM _DATE/TIME REM _MESSAGE Varchar Varchar Date/Time Text Type Description Current Reminder message Recent Reminder message Exact Date and Time reminders The create reminder messages
Page 3- 48
Student Information System 3.1.4.2 Software interface Description A computer language whereby computer programs can communicate with each other and one language can call upon another for assistance.
3.1.4.2.1 External machine interfaces The software will be capable to print those scheduled, curricular activities, Event calendar activities, student information and reports. 3.1.4.2.2 External system interfaces The researcher will design and develop an automated system which is LAN based at the same time, WEB based with all students to update easily will communicate with Web server on the internet through a high speed network connection WEB based is designed for those clients who are busy and doesnt have time to go to school? By using an automated system, it can lessen the exertion of effort at the same time; the process will be fast while LAN based is designed for the walk-in clients who decided to go at school for their question and other personal issues. 3.1.4.2.3 Human interface The actual system will only navigate by keyboard alone, in addition to use mouse and keyboard combination.
Page 3- 49
Student Information System 3.1.4.3 Reports 3.1.4.3.1 Inventory of reports Curricular Implemented reports -Memorandum of DepEd -K12 program -New subject Calendar activities reports -Required days of classes -Make-up class -Suspension of classes -Holiday -Extracurricular activities -School Event calendar Information date/time changes reports Login/Logout history reports
3.1.4.3.2 Layout of Reports 3.1.4.3.3 Data Dictionary of reports.
Page 3- 50
Student Information System 3.1.5 Behavioral Moral Description 3.1.5.1 Description for software behavior 3.1.5.1.1 Events Admin Class Events Admin logs on to system Admin updates school year Admin logs off the system
Registrar Class Events Registrar logs onto system Registrar keeps and maintains records
Students Class Events Student logs onto system Student view his/her information Schedule Class Events Admin updates schedules Registrar posts schedules Student view schedules
Page 3- 51
Classroom/Sectioning Class Events Student added to section Student removed from section Student added to new section
Subject Implement Class Events Admin Adds new Subject Admin posts implemented Subject
Edit/Update Class Events View File List Choose file to be change Edit selected file Information Changed
Page 3- 52
Student Information System 3.1.5.1.1 States Administrator State Memorandum of DepEd Onto system Access Log-in/out User setting Create account Subject Curricular activity Calendar activity Teacher assign Reports Book Required Maintenance The administrator has been log into system. The administrators have access to update school year. History the history of user log-in/log-out onto system The administrator have access of setting of users. The administrator one capable to create user. The administrators have access of setting of subject. The administrator have access of setting of curricular activity. Administrator set a schedule of upcoming events of the school. Principal chosen person who is teaching every subjects of a student. The administrator has access to post and distribute those reports. References that is suitable per grade level set subjects The administrator must do to maintain the security. Description
Registrar State Onto system Waiting Student info Subject info
Description The Registrar has been log into system. The Registrar has been waiting to be want to access. The Registrar have access to update all student info. The Registrar maintained the good description of each subject. Page 3- 53
Student Information System Curricular activity Schedule Book required Report Event The Registrar have access of setting of curricular activity. The Registrar has to set a student schedule. The Registrar have access to give a reminder to all student. The Registrar has access to post and distribute those reports. The Registrar must do to set Event at calendar.
Student State Onto system Waiting Reminder Report Request Curricular activity Event Student schedule Subject Student info. Print
Description The Student has been log into system. The Student has been waiting to be want to access. The message is being displayed for the student to acknowledge. The student has to set a message for report request. The student view the Curricular activity to be updated. The student must do to view the Event at calendar. The set schedule for a student. View the description of subject to be acknowledge. The Student data. The report suggest to administrator and registrar to be print.
Page 3- 54
Student Information System Calendar State Onto system Access Setting Extracurricular Required class Make-up class Suspension classes Event Holiday Waiting Changes Save Post/display Description The user has been log into system. The administrators have access to update school year. The setting of calendar selected categories of calendar activities per date. Administrator set the upcoming curricular activities for the students. The recommended number of days of the school. Set a arranged class to cope up the previous past classes. The postponement of the classes due to specific reasons and events. The principal create an additional activities for curricular managing The day set aside by custom or by law in which normal activities. The administrator select want to change. Set a changes. Save the changes Post to the system what changes is, to update all user.
Subject implemented onto System State Encode Subject Subject Description Description Length is too long
Description
To input new subject implemented Description of the new subject implemented. Exceed to the assigned maximum characters > 100 character.
New Subject has been implemented The subject successful implemented and post onto system.
Page 3- 55
Student Information System Edit/Update Class States Select file Edit Selected File Save Time/date Description User will choose what file he/she wants to change. User will now edit the file he/she has chosen Save changes made by the user. Change this will track the exact date and time when the changes made. Success data store The information that administrator changes has been success. Current Information changes Shows the current changes made by authorize user.
Page 3- 56
3.1.5.1 Statechart Diagram

A statechart diagram for the entire system is shown in figure 13.
Figure 13 Overall System State Chart Diagram Grace Montessori School of Novaliches (Curriculum Management System) Page 3- 57
Student Information System Administrator Class State chart Diagram.
Registrar Class State chart Diagram.
Page 3- 58
Student Information System Student Class State chart Diagram.
Calendar Activity State Chart Diagram.
Page 3- 59
Student Information System Subject Implement onto system Class State Chart Diagram.
Edit/Update Class State Chart Diagram.
Page 3- 60
Student Information System 1.1.6 Restriction, Limitation and constraints. This are those cant tackled or our knowledge limitation at system weve made.
Cant change the name of those past year curriculums subject taken with an alumni
graduate if already taken or change it in present if want to retrieve some data, just fix.
We didnt allow changing the other related module that entering or connecting in our
system.
1.1.7 Validation Criteria Software validation will ensure that the system responds according to the users expectations; therefore it is important that the end users be involved in some phases of the test procedure. All test will be traced back to the requirements in section 3.1.1.2.
1.1.7.1 Classes of test Unit testing will be conducted on all of software subsystems including. 1. 2. 3. 4. 5. 6. 7. Logging on to the system Viewing and editing Information Viewing Curricular Activity Viewing Event Calendar Viewing and setting Student schedule Implemented curriculum Viewing and posting with printing of report
Acceptance testing will be conducted at the Lan and Web server.
Page 3- 61
Student Information System 1.1.7.2 Expected software response The software should display an suitable error message when a value outside the accepted limits is entered. The software should not be capable of deleting an implemented subject inside and those account information at system weve made.
1.1.7.3
Performance bounds
The system will provide good and accurate performance for the accelerate transaction to the process of implement curricular and schedule managing. The system will provide access to the database system in immediate response.
Page 3- 62

Curriculum Manage System Chapter I I I

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Curriculum Manage System Chapter I I I

Uploaded by

Copyright:

Available Formats

Student Information System

3.1 Software Requirements Specification

Grace Montessori School of Novaliches (Curriculum Management System)

Grace Montessori School of Novaliches (Curriculum Management System)

Administrator and Registrar

Administrator and Registrar are allowed to print those request reports.

information and daily reminder of school or system

The administrator has authorizations to change the registrar setting privileges.

Grace Montessori School of Novaliches (Curriculum Management System)

Grace Montessori School of Novaliches (Curriculum Management System)

Grace Montessori School of Novaliches (Curriculum Management System)

Grace Montessori School of Novaliches (Curriculum Management System)

Student Information System Teacher ID Description ID

User log notes shall store the date and time.

Grace Montessori School of Novaliches (Curriculum Management System)

Student Information System

Grace Montessori School of Novaliches (Curriculum Management System)

Student Information System

displaying in screen are those reminders.

Administrator And Registrar

Grace Montessori School of Novaliches (Curriculum Management System)

Grace Montessori School of Novaliches (Curriculum Management System)

Student Information System

3.1.2 Usage Scenario

Grace Montessori School of Novaliches (Curriculum Management System)

Student Information System

Student Only viewing and updating his/her old/current info.

Grace Montessori School of Novaliches (Curriculum Management System)

Grace Montessori School of Novaliches (Curriculum Management System)

Grace Montessori School of Novaliches (Curriculum Management System)

Grace Montessori School of Novaliches (Curriculum Management System)

The user name and password cannot be verified.

Update account Information Page 3- 16

Grace Montessori School of Novaliches (Curriculum Management System)

Grace Montessori School of Novaliches (Curriculum Management System)

Other users cannot access to implement except administrator.

Grace Montessori School of Novaliches (Curriculum Management System)

Grace Montessori School of Novaliches (Curriculum Management System)

Student Information System

Use-case: Primary actor: Goal in context: Preconditions: Trigger:

Administrator/Registrar. Grace Montessori School of Novaliches (Curriculum Management System) Page 3- 20

Student Information System

Use-case: Primary actor: Goal in context: Preconditions:

Students are not allowed to print that report. Page 3- 21

Grace Montessori School of Novaliches (Curriculum Management System)

Student Information System

Use-case: Primary actor: Goal in context: Preconditions:

Grace Montessori School of Novaliches (Curriculum Management System)

Students are not allowed to print those report.

Grace Montessori School of Novaliches (Curriculum Management System)

Student Information System

Use-case: Primary actor: Goal in context: Preconditions: Trigger: Scenario:

If the user does not log in as an administrator.

Grace Montessori School of Novaliches (Curriculum Management System)

Student Information System

Use-case: Primary actor: Goal in context: Preconditions: Trigger: Scenario:

Grace Montessori School of Novaliches (Curriculum Management System)

Student Information System

Use-case: Primary actor: Goal in context: Preconditions:

User needs to log out to the system.

Grace Montessori School of Novaliches (Curriculum Management System)

Student Information System

3.1.2.3 Special usage considerations 3.1.2.4 Activity diagrams