system analysis and requirements
DESCRIPTION
making SARTRANSCRIPT
System Requirements Specifications for Foundation College Enrollment System
Table of Contents 1. Introduction . . . . . . . . . . 3
1.1 Document description . . . . . . . . 3
2. Project drivers . . . . . . . . . . 3
2.1 The purpose of the product . . . . . . . 32.2 Users of the product . . . . . . . . 3
3. Project environment constraints . . . . . . . . 3
3.1 Mandated constraints . . . . . . . . 3
4. Procedures, naming conventions, and definitions . . . . . 4
4.1 Procedures . . . . . . . . . 44.2 Naming conventions and definitions . . . . . . 5
5. Functional requirements . . . . . . . . . 6
5.1 The Contextual Data Flow Diagram (DFD) of the ES . . . 65.2 The Level 0 DFD of the ES . . . . . . 75.3 The Use Case Diagram of the ES . . . . . 85.4 Requirements narratives . . . . . . . . 95.5 Hardware and network architecture . . . . . . 135.6 Hardware and software specifications . . . . . . 13
6. Data requirements . . . . . . . . . 14
6.1 ERD1. Student/Subject Report (Appendix A) . . . . . 146.2 ERD 2. Subject/Instructor Report (Appendix B) . . . . . 14
7. Security requirements . . . . . . . . . 15
8. Backup and recovery . . . . . . . . . 15
9. Requirements and modifications . . . . . . . . 15
10. Final software requirements specifications agreement . . . . 15
APPENDIX A – Student/Subject Report . . . . . . . 16
APPENDIX B – Subject/Instructor Report . . . . . . 17
2
1. Introduction
1.1 Document description
This document contains the software requirements and specifications of Foundation College Enrollment System (FCES). This is based on the information gathered from observation and interview of the current enrollment process and the people involved in it. This document also gives a clear view of the data and information needed to automate the enrollment process of FCES.
By signing the agreement included herein the system developers and the foundation agrees that the systems capability is only limited as to what is stated in this paper.
2 Project drivers
2.1 The purpose of the product
The ES will be used to monitor the number of enrollees for each level in every semester, easy evaluation of grades; capture students’ personal information, subjects enrolled, number of units and store it in a centralized database. This system will also serve as a replacement for the current manual system of enrollment.
2.1.1.1 Allow the office of the registrar to easily evaluate students’ grades for the purpose of giving academic awards or enrolling prerequisite subjects.
2.1.1.2 Allows other systems such as the cashiering system, guidance system and others to access the database and view/edit students’ record/information as needed.
2.2 Users of the product
2.2.1 FC Office of the registrar personnel’s will be the main user of the ES software since they belong to the primary office involved in the enrollment process and it is at their end that the students’ information(ie. Subjects enrolled) is captured.
2.2.2 Guidance system, Accounting system SSC, and DSBO system and cashiering system which will access the systems database for their respective adding, checking and editing of students’ financial and behavioral records.
3 Project environment constraints . 3.1 Mandated constraints
3.1.1 As derived from the result of interview and observation of the current system of enrollment, a solution has been found which are the analysis, design, development and implementation of software that practically fits the situation and therefore will make the enrollment process faster and create reliable results.
3
3.1.2 The means of capturing data from the student is encoding students’ info. to the systems’ UI and store it in a centralized database.
3.1.3 The customized software must run under Windows XP operating system3.1.4 The customized software must run under the current local area network of ACD.3.1.5 ES shall be installed installed at various computers inside the registrars’ office.3.1.6 Students’ info. (ie. personal info. and subjects enrolled) shall be registered into the
system during the enrollment and at the end of the semester (ie. grades) for the full implementation of the system.
3.1.7 ES shall be installed and tested one month before the enrollment and be fully implemented during the first enrollment after it has been tested for bugs.
4 Procedures, naming conventions, and definitions
4.1 Procedures
4.1.1 Data Flow Diagram
Data flow diagram is a process model used to depict the flow of data through a system and the work or processing performed by the system. Synonyms are bubble chart, transformation graph, and process model.
This part of the document contains pictures with its corresponding explanations that are used to diagram the flow of data through the ES.
Rectangle – a square that represents a person, department, organization which provides inputs to or receives outputs from the system being studied. These define the beginning and the end of the data flow.Process - a rounded rectangle with a horizontal line near its top base, which represents work that is performed in, by, or for the system. This includes work performed by people and machines.
Data Store - an open-ended rectangle with two lines on the other end represents data storage (temporary or permanent). This includes students’ personal information, subjects enrolled and number of units and other student related information.Data Flow - an arrow that represents the actual flow of information, and reports through the system. Each arrow can contain more than one type of information.System – a circle containing the abbreviated name of other systems that interacts with the ES
4
4.1.2 Use-Case Diagram
Use-case diagram is a diagram that depicts the interactions between the system, external systems and users. It graphically describes who will use the system and in what ways the user expects to interact with the system, the symbols are in the table below.
Use Case – an ellipse that represents sequence of steps (a scenario), both automated and manual, for the purpose of completing a single business task. This ellipse shall contain the names of processes which will occur in the system.
Actor - Anything that needs to interact with the system to exchange information. Could be a human, an organization, another information system, an external device, or even time. Time actor is called temporal event, a system event triggered by time where the actor is time.
Association - Relationship between an actor and a use case in which an interaction occurs between them. Association modeled as a solid line connecting the actor and the use case. Association with an arrowhead touching the use case indicates that the use case was initiated by the actor. Association lacking arrowhead indicates a receiver actor. Associations may be bidirectional or unidirectional.
4.2 Naming conventions and definitions
This part of the document gives the definitions terms used in the project.
FC Foundation College ID Number An identification number given to a student as he/she enrolls to the
foundation college which serves as the primary information used for locating student information in the database.
Department Refers to the individual departments in the college (Graduate Studies, College of Education, Agriculture, ICT, High School and Elementary).
DFD Data Flow DiagramES Foundation College Enrollment System.ERD Entity-Relationship Diagram. Used to model data requirements of a
system.CS Cashiering SystemGS Guidance SystemAS Accounting SystemSSCS Student Supreme Council SystemDSBOS Department Student Body organization SystemUI User interface
5
5 Functional requirements
5.1 The Contextual Data Flow Diagram (DFD) of the ES
6
Students’ copy of matriculation
ES
Student
Registrars’ office
Students’ personal information (name, id number), Subjects Enrolled
Students’ personal information (name, id number), Subjects Enrolled
Students’ personal information (name, id number), Subjects Enrolled
CS
AS
GS
SSCS
DSBOS
Students’ personal information (name, id number), financial record
Students’ personal information (name, id number), Subjects Enrolled
Students’ personal information (name, id number),
Students’ personal information (name, id number),
Students’ personal information (name, id number)
5.2 The Level 0 DFD of the ES
7
Subjects Enrolled
ES
Students’ copy of Subjects Enrolled
Student
Students’ personal information (name, id number), Subjects Enrolled
Enrollment Form and ID number
Students’ personal information (name and other info.)
P1
Encoding of Student’ Personal
Information
P2
Encoding of Enrolled Subjects
Centralized
Database
D1
Students’ personal information (name, ID number and other info.)
Students’ personal information (name, ID number and other info.)
GS
Students’ personal information (name, ID number)
CS
AS
Students’ personal information (name, id number), financial record
Students’ personal information (name, id number)
SSCS
Students’ personal information (name, id number),
Centralized
Database
D1
Students’ payment and balance
DSBOS
Students’ payment and balance
Students’ payment and balance
Students’ personal information (name, id number), financial record
Students’ entrance exam result, behavioral record
5.3 The Use Case Diagram of the ES
8
Encoding/saving of Students’ personal info
and giving of ID number
Encoding/saving of subjects enrolled
Listing of Subjects to enroll
Giving entrance exam,Encoding/saving
entrance exam result
Encoding/saving Students’ financial
record
Student
Office of the Registrar Personnel
CS
GS
SSC
DSBO
5.4 Requirements narratives
5.4.1 AES 1Requirement No. ES - 1 Event/Use Case IDRequirement Name Listing of Subjects to enroll ES 1Priority High Requirement TypeSource New, old and transferee StudentsRationale To be able to easily capture subjects enrolled by the studentPrimary Business Actors
New students of Graduate Studies, College of Education, Agriculture, ICT, High School and Elementary Departments
Other Participating Actors
Office of the Registrar Personnel
Other Interested StakeholdersDescription The student must list the subject that he/she will enroll after evaluation or
after taking entrance exam for new and transferee students Precondition The subjects enrolled have been listed on the enrollment formTrigger This event is initiated when a new/transferee student will enroll in the
collegeTypical Course of Events
Actor Action System Response
Step 1: The student will list the subjects to be enrolled after the evaluation of grades for the old students and after taking the entrance exam for the new students
Step 2:
Conclusion This event is concluded when the subjects to be enrolled have been successfully listed to the enrollment form
Post Condition The subjects to be enrolled have been listed to the enrollment formBusiness RulesImplementation Constraints and Specifications
The use of enrollment forms is preferred for it will make the encoding of subjects enrolled to the ES a lot easier
5.4.2 ES 2Requirement No. ES - 2 Event/Use Case IDRequirement Name Encoding/saving of Students’ personal info and
giving of ID numberES 2
Priority High Requirement TypeSource New/Transferee StudentsRationale To be able to easily access students’ information in the databasePrimary Business Actors
Office of the Registrar personnel and new students of Graduate Studies, College of Education, Agriculture, ICT, High School and Elementary Departments
9
Other Participating ActorsOther Interested Stakeholders
Guidance Personnel
Description The system must capture and store to a database the students’ personal information and the new ID number given
Precondition The new/transferee students’ personal information and new given ID Number have been registered to the database.
Trigger This event is initiated when a new/transferee student will enroll in the college
Typical Course of Events
Actor Action System Response
Step 1: The Office of the Registrar personnel will encode the new/transferee student’s personal information and save it to the database including the given ID number.
Step 2: The system verifies if there are no duplicate records, if there is, the system will prompt the personnel. If there is none, the system will then store the new data to the database.
Conclusion This event is concluded when the system prompts the personnel that the new data is successfully saved
Post Condition The encoded data has been stored to the centralized database.Business RulesImplementation Constraints and Specifications
The use of Automated Enrollment System is preferred especially because it will make the enrollment process faster. The systems database must be centralized so that other related systems can access it and it should be installed to the Office of the Registrar.
5.4.3 ES 3Requirement No. ES - 3 Event/Use Case IDRequirement Name Encoding/saving of subjects enrolled ES 3Priority High Requirement TypeSource New, old and Transferee StudentsRationale To be able to easily access students’ information in the database
and evaluate grades for prerequisite subjects for the next enrollment
Primary Business Actors
Office of the Registrar personnel and new students of Graduate Studies, College of Education, Agriculture, ICT, High School and Elementary Departments
Other Participating ActorsOther Interested StakeholdersDescription The system must capture and store to a database the subjects enrolled by
the students Precondition The new, old and transferee students subjects enrolled have been saved to
10
the database Trigger This event is initiated when a new, old and transferee student will enroll
in the collegeTypical Course of Events
Actor Action System Response
Step 1: The Office of the Registrar personnel will encode the new, old and transferee student’s enrolled subjects
Step 2: The system will store the enrolled subjects to the database and prompts the personnel if the enrolled subjects have been successfully saved
Conclusion This event is concluded when the system prompts the personnel that the new subjects have been successfully saved
Post Condition The encoded subjects have been stored to the centralized database.Business RulesImplementation Constraints and Specifications
The use of Automated Enrollment System is preferred especially because it will make the enrollment process faster. The systems database must be centralized so that other related systems can access it and it should be installed to the Office of the Registrar.
5.4.4 ES 4Requirement No. ES - 4 Event/Use Case IDRequirement Name Encoding/saving Students’ financial record ES 4Priority High Requirement TypeSource New, old and Transferee StudentsRationale To be able to easily evaluate the students financial status in every
examination or every time a student will payPrimary Business Actors
Cashiering System and new students of Graduate Studies, College of Education, Agriculture, ICT, High School and Elementary Departments
Other Participating Actors
SSCS and DSBO
Other Interested StakeholdersDescription The system must capture and store to a database the financial information
of the student, although this process does not occur in the ES but in the Cashiering System (CS), the two systems are related since a student cannot take new subjects if it is discovered by the Office of the Registrar Personnel find out through the ES students financial status section that the student has a back account.
Precondition The new, old and transferee students new payment have been saved to the
Trigger This event is initiated when a new, old and transferee student will pay/inquire on their account balance
Typical Course of Events
Actor Action System Response
11
Step 1: The cashiering system and other related systems will save every students’ payment information to the database
Step 2: The ES will get the financial information of a student incase the Office of the Registrar personnel will access the students’ financial status.
Conclusion This event is concluded when the Cashiering System saves the students payment information to the database
Post Condition The students’ payment information has been stored to the centralized database.
Business RulesImplementation Constraints and Specifications
The use of Automated Enrollment System associated to the Cashiering System is preferred especially because it will make the enrollment process faster.
5.4.5 ES 5Requirement No. ES - 5 Event/Use Case IDRequirement Name Giving entrance exam, Encoding/saving
entrance exam resultES 5
Priority High Requirement TypeSource New/Transferee StudentsRationale To be able to easily identify to which course the student should be
enrolled inPrimary Business Actors
Guidance System and new students of Graduate Studies, College of Education, Agriculture, ICT, High School and Elementary Departments
Other Participating ActorsOther Interested StakeholdersDescription The system must capture and store to a database the result of the entrance
examination of a new or transferee student, although this process does not occur in the ES but the Guidance System is related to the ES since the entrance exam result can be seen in the students’ information section to ensure that the student really fits to course that he/she is taking
Precondition The new/transferee students entrance exam result has been saved to the centralized database
Trigger This event is initiated when a new/transferee student takes an entrance examination
Typical Course of Events
Actor Action System Response
Step 1: The Guidance System will store the result of entrance examination to the centralized database for access of the ES
Step 2: The ES will get the entrance exam result of a new student incase the Office of the Registrar personnel will access the students’ information
12
section.
Conclusion This event is concluded when the Guidance System saves the entrance examination result to the database
Post Condition The students’ entrance examination result has been stored to the centralized database.
Business RulesImplementation Constraints and Specifications
The use of Automated Enrollment System associated to the Guidance System is preferred especially because it will make the enrollment process faster.
5.5 Hardware and Network Architecture
5.6 Hardware and software specifications
5.6.1 Office of the Registrar and other offices work stations
5.6.1.1 Pentium IV or higher processor5.6.1.2 At least 40 GB Hard Disk5.6.1.3 At least 512 MB of RAM or higher5.6.1.4 Operating System: Windows XP or higher
5.6.2 Database Server
13
Student Office of the Registrar Personnel
ES Software(Office of the Registrar)
Database Server
Guidance System
Cashiering System
Accounting System
SSC System
DSBO System
Backup Database Server
5.6.2.1 Server Processor: Pentium IV Quad Core or higher5.6.2.2 120 GB Hard Disk or higher5.6.2.3 120 GB Hard Disk or higher for backup5.6.2.4 4 GB RAM or higher5.6.2.5 Network Operating System: Windows 2000 Server or higher5.6.2.6 DBMS: MySQL 5.1
5.6.3 Backup Database Server
5.6.3.1 Server Processor: Pentium IV Quad Core or higher5.6.3.2 120 GB Hard Disk or higher5.6.3.3 120 GB Hard Disk or higher for backup5.6.3.4 4 GB RAM or higher5.6.3.5 Network Operating System: Windows 2000 Server or higher5.6.3.6 DBMS: MySQL 5.1
6 Data requirements
This part of the document shows the data requirements that shall be captured by the ES.
6.1 ERD 1. Student/Subject Report (Appendix A)
Description
This report shows Course Number, Descriptive title, prerequisites and the number of units the student has taken. This information will be viewed by the cashier in the cashiering system to determine how much will the student pay for the current semester.
Student SubjectID NumberName
Course NumberDescriptive TitlePrerequisitesNumber of Units
6.2 ERD 2. Subject/Instructor Report (Appendix B)
Subject InstructorCourse NumberDescriptive TitlePrerequisitesNumber of Units
ID NumberNameDepartment
7 Security requirements
14
This part of the document entails the ES security requirements especially with the user access concerns. 7.1 The work stations in which the ES must be accessible only to the Office of the Registrar
personnel’s.7.2 The workstations where ES are installed and the ES itself must be password protected
and passwords must only be known to authorized personnel’s.7.3 The place in which the database servers can be found must be secured properly and only
the system developer or network administrator has the access.7.4 Other record systems must not be able to alter information’s that only the Office of the
Registrars’ Personnel are allowed to alter. 7.5 Users can change their password anytime.
8 Backup and recovery
8.1 Incase the database server fails, it shall be replaced by the backup database server immediately
8.2 Backing up of the database should be done every day.
9 Requirements modifications
Should there be any Software Requirements Specifications Modifications not included in this document is subject to the system developers investigation and if found out that the end users have violated the statements under this document might be given considerations by the developer and may result to additional payment of the client depending on the overall impact of the change to the system.
By signing this Contract of Agreement, the client agrees that the Developer has the full rights to either consider any modifications that are not included in this Software Requirements Specifications document or enter into separate Contract of Agreement regarding the modifications not included unto this document.
10 Final software requirements specifications agreement
We hereby agree to the Final Software Requirements Specifications contained in this document.
Project Manager School PresidentDate Signed: ________________ Date Signed: ________________
15
16