System Analysis and Requirements

22
System Requirements Specifications for Foundation College Enrollment System

description

making SAR

Transcript of System Analysis and Requirements

Page 1: System Analysis and Requirements

System Requirements Specifications for Foundation College Enrollment System

Page 2: System Analysis and Requirements

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

Page 3: System Analysis and Requirements

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

Page 4: System Analysis and Requirements

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

Page 5: System Analysis and Requirements

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

Page 6: System Analysis and Requirements

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)

Page 7: System Analysis and Requirements

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

Page 8: System Analysis and Requirements

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

Page 9: System Analysis and Requirements

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

Page 10: System Analysis and Requirements

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

Page 11: System Analysis and Requirements

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

Page 12: System Analysis and Requirements

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

Page 13: System Analysis and Requirements

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

Page 14: System Analysis and Requirements

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

Page 15: System Analysis and Requirements

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

Page 16: System Analysis and Requirements

16