IS315 Systems Analysis &

Design Project

Systems Proposal
Student Record Management
System – For PNG Schools

Jeremiah Miall
ID Number: 22201254
BBIT/3

Subject Coordinator: Ms. Pambel

 IS315 | Systems Analysis & Design Project
Systems Proposal – Student Record Management System (SRMS)

Table of Contents
1. Executive Summary............................................................................................................ 2
2. System Request................................................................................................................... 3
3. Work Plan – Project Plan.................................................................................................... 4
A. Plan Explanation ......................................................................................................... 5
4. Feasibility Analysis ............................................................................................................ 7
A. Technical, Economical & Organizational Feasibility ................................................. 7
B. Alternative Systems Comparison Analysis ................................................................. 9
5. Requirements Definition................................................................................................... 11
A. Business Requirements ............................................................................................. 11
B. User Requirements .................................................................................................... 11
6. System Requirements ....................................................................................................... 12
A. Functional Requirements; ......................................................................................... 12
B. Non – Functional Requirements ................................................................................ 12
7. Use Case ........................................................................................................................... 13
A. Use Case # 1 .............................................................................................................. 13
B. Use Case # 2 .............................................................................................................. 14
C. Use Case # 3 .............................................................................................................. 14
D. Use Case # 4 .............................................................................................................. 15
E. Use Case Diagram ..................................................................................................... 15
8. Process Model................................................................................................................... 16
A. Context Diagram ............................................................................................................. 16
B. Level 0 Data Flow Diagram (DFD) ................................................................................ 17
9. Data Model ....................................................................................................................... 18
10. Interface Design ............................................................................................................ 20
A. Login Interface .......................................................................................................... 20
B. Main Dashboard Interface ......................................................................................... 20
C. Add Student Interface................................................................................................ 21
D. View Records Interface ............................................................................................. 21
E. Help Interface ............................................................................................................ 22
F. Logout Interface ............................................................................................................ 22
11. Appendix ....................................................................................................................... 23
A. References ................................................................................................................. 23
B. Other Information ...................................................................................................... 23

1
 IS315 | Systems Analysis & Design Project
Systems Proposal – Student Record Management System (SRMS)

1. Executive Summary
The objective of this proposal is to introduce a comprehensive Student Record
Management System tailored for Secondary Schools in Papua New Guinea. Currently, there
is a notable absence of a structured system for capturing and administering student data,
presenting a significant opportunity for resolution. Bugandi Secondary School in Lae,
Morobe Province will be used as a case study for this system proposal.
Furthermore, it has become evident that the absence of a formal system for managing student
records in Secondary Schools creates numerous challenges and inefficiencies. Provided
below is a brief overview of the challenges being faced which were already covered in the
Problem Definition Documentation. The challenges are;
1. Absence of a formal system
2. Time Consumption
3. Safety Concerns
4. Untimely Updates
5. Data Redundancy & Inaccuracies
As mentioned earlier, the challenges provide a window of opportunity that is possible to
solve. An opportunity to develop a user – friendly desktop application to automate record
keeping processes, replacing manual methods and ultimately provide an efficient record
management system. A desktop application can be developed to automate this manual
process to make it more efficient and reliable. This proposal will capture all the required and
needed information on how to successfully implement a Student Record Management
System (SRMS).
The proposal will cover a range of insightful information ranging from;
1. System Request: A document that initiates the process of developing/enhancing a
system within an organization outlining the business need / problem, constraints and
the benefits the system will bring.
2. Work Plan: An outline or plan on the tasks and activities that needs to be carried out
to develop a working system.
3. Feasibility Analysis: Covers technical, economical and organizational feasibilities of
the system along with comparisons of different record management systems.
4. Requirements Definition: Covers the business requirements (what the business
needs) and the user requirements (what the user needs to do).
5. System Requirements: Covers functional & non – functional requirements of the
system.
6. Use Case: Composed of diagrams that outline various scenarios or sequences of
interactions between users and the system.
7. Process Models: Models that explain the relationship of functions/ processes to the
system users and how they relate to each other
8. Data Models: Diagrams that describe the data that will be captured and maintained.
9. Interface Design: Outlines how the system should look
10. Appendix: All additional information will be provided in this section.

2
 IS315 | Systems Analysis & Design Project
Systems Proposal – Student Record Management System (SRMS)

2. System Request
System Request – Student Record Management System
Project Sponsor: Jeremiah Miall - Developer
Business Need:
The Student Record Management System is essential to streamline the process of
managing student records efficiently within Secondary Schools. It aims to replace manual
record-keeping methods with a digital solution to improve data accuracy, accessibility, and
overall management of student information.
Business Requirements:
Using the System, users (teachers) will be able to;
• Enter, Record and update student information efficiently.
• View student records from all grades with a single click
• Delete records accordingly
• Login and logout of the system securely
Business Value:
• Enhanced Data Accuracy: Minimizing manual errors and ensuring data validation
will improve the accuracy and reliability of student records.
• Increased Accessibility: Providing easy access to student records from any location
will facilitate better collaboration and decision-making among stakeholders such as
parents.
• Enhanced Security: Implementing robust security measures will protect sensitive
student data and ensure compliance with data privacy regulations.
• Improved Stakeholder Satisfaction: Offering a user-friendly interface and timely
access to information will enhance satisfaction among staff, teachers, students, and
parents.
Special Issue / Constraints:
• Limited time and resources for system development and implementation.
• Need to ensure compatibility and integration with existing systems and processes.
• Consideration of data privacy and security regulations in handling student
information.
• Requirement for user training and change management to facilitate system adoption
and usage.

3
 IS315 | Systems Analysis & Design Project
Systems Proposal – Student Record Management System (SRMS)

3. Work Plan – Project Plan

The work plan section gives insight on the activities and tasks to develop a working record
management system for schools. It covers a range of tasks that are derived from the systems
development life cycle which includes 4 phases namely; planning, analysis, design &
implementation. For this project, under the planning & analysis phase problem definition
and project research was carried out to ensure the possibilities of implementing a working
system. This includes countless interviews and observations along with questionaries that
were being sent/ conducted to gather information from the school’s perspective. A work
plan/project plan was developed to cater and outline the tasks and sub tasks that were needed
to complete. For the design and implementation phase, numerous activities were conducted
to develop the system. Activities that were carried out range from project setup &
environment configuration, database design & integration, user interface design &
development, functionality implementation, testing & debugging and lastly documentation of
user manuals.
Attached below is a simple project plan, the rest will be attached at the appendix section;

4
 IS315 | Systems Analysis & Design Project
Systems Proposal – Student Record Management System (SRMS)

A. Plan Explanation
This is an overview explanation of each of the tasks within the plan captured earlier.
1. Planning Phase:
• Project Initiation & Research
o Problem Definition: Involves Defining the specific issues or challenges that
the student record management system aims to address.
o Define Project Objectives: Clearly stating the goals and objectives of the
project, outlining what needs to be achieved.
o Project Plan: Developing a comprehensive plan outlining the approach,
timeline, and resources required to complete the project successfully.
2. Analysis Phase:
• Requirements Gathering & Interface Modelling
o Create Functional & Non-Functional Requirement Documentation: Gathering
and documenting the functional requirements specifying what the system
should do and non-functional requirements specifying constraints and quality
attributes.
o Create Wireframes for User Interface: Develop visual representations
(wireframes) of the user interface to illustrate the layout and structure of the
system.
3. Design Phase:
• Process Model & Data Model
o Define & Design Process Models: Involves establishing and designing of the
processes and workflows involved in managing student records.
o Define & Design Data Model: Designing the structure and relationships of the
data entities involved in the student record management system.
• Project Setup & Environment Configuration
o Install Visual Studio IDE: Installing the Integrated Development Environment
required for software development.
o Create New Project in Visual Studio: Setting up a new project in Visual Studio
for developing the student record management system.
o Configure Project Settings: Customizeing project settings such as windows
forms & its properties.
• Database Design & Integration
o Design Database Schema: Defining the structure of the database to store
student records efficiently.

5
 IS315 | Systems Analysis & Design Project
Systems Proposal – Student Record Management System (SRMS)
o Create Tables for Student Records: Involves creating database tables to
represent student information, grades, etc.
o Establish Connection to Database in Projects: Configuring the application to
connect and interact with the database.
• User Interface Design & Development
o Design All Form Layout: Planning and designing the layout of the user
interface forms for entering and displaying student information.
o Create UI Elements: Developing the graphical elements (buttons, text boxes,
labels) that compose the user interface.
o Implement Dashboard Menu: Involves merging navigation elements to create
a user-friendly dashboard for accessing different functionalities.
4. Implementation Phase:
• User Authentication & Database Development
o Implement User Authentication & Authorization: Developing mechanisms to
authenticate users and control access to system resources.
o Setup Database & Schema Tables: Creating the database environment and
tables required for storing student data.
• Functionality Implementation
o Coding to Implement Functions: Writing code to implement the various
features and functionalities of the student record management system.
o Implement Functionality to Add, View, Record Student: Develop features to
add new student records, view existing records, and record student
information.
o Develop Features for Editing & Updating Records: Implementing
functionality to edit and update student records as needed.
o Implement Data Validation and Search Functionality: Validate user input and
create search capabilities for retrieving student records.
• Testing & Debugging
o Conduct Testing to Identify Bugs: Performing testing to identify and fix any
bugs or issues in the system.
o Perform User Acceptance Testing: Involves end-users to test the system and
ensure it meets their requirements and expectations.
• Documentation of User Manuals
o Develop User Manuals: Create comprehensive user manuals or guides to assist
users in understanding and using the student record management system
effectively.

6
 IS315 | Systems Analysis & Design Project
Systems Proposal – Student Record Management System (SRMS)

4. Feasibility Analysis
A. Technical, Economical & Organizational Feasibility
The feasibility analysis section covers the technical, economical and organizational
feasibility. The technical feasibility inspects whether the software can be built at all with
available tools. The economic feasibility examines the costs and financial benefits of the
project. On the other hand, organizational feasibility assesses the organization's ability to
support the new venture of the system.
Technical Feasibility
• Availability of Tools and Resources:
- Visual Studio IDE: Visual Studio provides a comprehensive set of tools for designing,
coding, testing, and deploying software applications. It offers features like code
editing, debugging, version control integration, and a wide range of project templates
and libraries
- Windows Forms: Windows Forms is a graphical user interface (GUI) framework
provided by Microsoft for developing desktop applications on the Windows platform.
It offers a set of controls and components that can be easily dragged and dropped onto
forms to create the user interface for the application.
- C# Programming Language: C# is a powerful and versatile programming language
that is widely used for developing desktop, web, and mobile applications on the .NET
framework. It offers features such as object-oriented programming, type safety,
automatic memory management, and extensive standard libraries.
• Compatibility with existing systems:
- Visual Studio and C# are widely compatible with various Windows operating systems,
ensuring that the developed student record management system can be installed and
run on most Windows-based computers commonly used in secondary schools.
- Windows Forms applications can also integrate with other Microsoft technologies and
services commonly used in educational institutions, such as Microsoft Office.
• Scalability and Performance:
- Visual Studio provides tools and features for optimizing the performance of
applications developed using C#. Developers can use profiling tools, performance
diagnostics, and code optimization techniques to ensure that the student record
management system performs efficiently, even as the volume of data and user load
increases.
- Windows Forms applications built with C# can be designed with scalability in mind,
allowing for future expansion and enhancements as the needs of secondary schools
evolve.
• Security and Privacy:
- Visual Studio and C# offer capabilities for implementing robust security features in the
student record management system, such as encryption, authentication, access control,
and secure communication protocols.

7
 IS315 | Systems Analysis & Design Project
Systems Proposal – Student Record Management System (SRMS)

Economical Feasibility
• Resource Allocation:
Time has been allocated accordingly to the project plan. Time and resources have been
allocated. Additionally, resources such as access to necessary tools, technologies, and expertise
have been accounted for. While there may not be direct financial costs, the allocation of time
and resources represents an investment in the project's success.
• Potential Savings:
The implementation of the student record management system has the potential to generate
savings in various areas. For instance, by streamlining administrative processes and reducing
paperwork, the system can save time for teachers and administrators, allowing them to focus
more on delivering quality education. Furthermore, improved data accuracy and accessibility
can lead to cost savings associated with reduced errors and improved decision-making.
• Return on Investment (ROI):
While the initial investment may not involve monetary costs, the return on investment for
implementing the student record management system can be measured in terms of improved
operational efficiency, enhanced data management, and better educational outcomes. The
system's impact on reducing administrative burden, improving teacher productivity, and
enhancing student engagement can contribute to the overall success and effectiveness of the
school.
• Cost-Benefit Analysis:
A qualitative cost-benefit analysis can be conducted to assess the overall value proposition of
the student record management system. By comparing the benefits of the system, such as
improved data accuracy, streamlined processes, and enhanced decision-making capabilities, to
the investment of time and resources, the school can determine whether the implementation of
the system outweighs the associated costs. Additionally, intangible benefits such as improved
teacher morale, increased parent satisfaction, and enhanced reputation can also be considered in
the analysis. This can be conducted at a later date.
Organizational Feasibility
• User Acceptance:
- The user-friendly design of the system ensures high acceptance among teachers,
administrators, and other stakeholders within secondary schools.
• Training & Support:
- Adequate training programs and ongoing support mechanisms are available to ensure users
are equipped with the necessary skills to effectively utilize the student record management
system. For instance, the development of a user manual will assist users to understand how
to use the system.
• Alignment with Organizational Goals:
- The implementation of the student record management system aligns with the school’s
mission of providing quality education for students, enhancing the efficiency of data
management processes, and supporting teachers in their administrative tasks. Moreover, by
streamlining administrative tasks and minimizing paperwork, the system frees up valuable
time and resources for teachers and administrators to focus on delivering impactful
educational experiences.

8
 IS315 | Systems Analysis & Design Project
Systems Proposal – Student Record Management System (SRMS)

B. Alternative Systems Comparison Analysis

This section analyses two student record management software’s along with the proposed
system that is planned to develop. The two systems that will be used for this analysis are;
1. eSkooly - eSkooly is a comprehensive school management software managing
everything from admission to attendance and exams.
2. Original School System – This refers to digital tools such as MS Excel and MS
Access in which the school originally use to record data.
The main aspects or criteria used for this comparative analysis are;
• Features and Functionalities
• Technical Support and Training
• Cost
Analysis Table
Aspects eSkooly Original School Student Record
System Management
System (Proposed
Idea)
Features & Criticized for its Original School Customized to suit
Functionalities limited functionality, System consisting of the specific needs of
particularly poor tools like MS Excel secondary schools in
customer support and MS Access, lack Papua New Guinea.
(Software, 2022). the integration of It includes all
specialized features features and
requiring manual functionalities
method for data necessary for daily
entry. (Paita, 2024) tasks that teachers
actually use and
need
Technical Support Criticized for very Lack dedicated Offers dedicated
& Training poor customer technical support technical support
support. (Software, and structured and training,
2022) training, relying ensuring that staff
instead on general members can easily
user knowledge of learn and use the
tools like MS Excel system effectively.
and Access. Users
might need to
troubleshoot issues
themselves, leading
to longer downtimes
and potential
frustrations. (Paita,
2024)
Cost Cloud-based and MS Excel and Cost effective
may incur costs, but Access, may seem solution – Free to
its limited cost-effective use Desktop
functionality and initially since these Application.

9
 IS315 | Systems Analysis & Design Project
Systems Proposal – Student Record Management System (SRMS)
Poor customer tools are often
support may not readily available.
justify the However, the long-
investment. (G2, term costs can
2022) accumulate due to
potential lack of
dedicated support,
and the need for
manual
workarounds.

Supporting Ideas
• Tailored to Local Needs: Unlike eSkooly and the usage of digital tools, which are
generic solutions, the proposed SRMS is specifically customized to meet the unique
needs of secondary schools in Papua New Guinea.
• Comprehensive Features: The SRMS includes all essential features and
functionalities required for daily tasks, ensuring that teachers have access to tools they
need without dealing with glitches or missing features.
• Dedicated Support and Training: With dedicated technical support and training
provided, staff members can quickly learn and effectively use the system, minimizing
disruptions and maximizing productivity.
• Cost-Effectiveness: Unlike the cloud-based alternatives, which may involve high
setup and maintenance costs including the expensive internet costs in PNG, the SRMS
offers a cost-effective solution with a user – friendly desktop application.

10
 IS315 | Systems Analysis & Design Project
Systems Proposal – Student Record Management System (SRMS)

5. Requirements Definition
This section defines the requirements for the business/organization and the user. The business
requirements simply talk about what the business needs and help clarify the contributions the
system will make to the organization’s success by achieving its goals if built will fulfill. On
the other hand, user requirements explain what the user needs by describing tasks that the
users perform as an integral part of the business. Below is an overview of the business
requirements and user requirements of the newly proposed system.

A. Business Requirements
• Improvment in streamlining of data entry.
This means making the process of entering data faster and smoother. For example,
reducing the time it takes for staff to input information into the system.
• Improved accessibility to student record.
This requirement emphasizes making it easier for authorized individuals to access
student information when needed.
• Automate record keeping processes.
This involves automating tasks related to maintaining records, such as generating
reports or updating databases. By automating these processes, the system can save
time and reduce the potential for human error.
• Reduced downtime in producing record cards.
Records can be produced within a short period of time with just the push of a button.
• Improved data management practices.
This requirement focuses on implementing better practices for organizing, storing,
and maintaining data.

B. User Requirements
• Access student records: Users need to be able to access student records quickly and
efficiently. This may involve searching for specific student records by name, or other
identifiers, and viewing relevant information such personal details.
• Enter and update student data: Users should have the ability to enter new student
data into the system and update existing records as needed.
• Generate record cards: Users must be able to generate record cards for students.
This involves compiling relevant information from the student records and presenting
it in a standardized format for printing or digital distribution.
• Manage data efficiently: Users require tools and functionalities to manage data
efficiently. This may include features such as data validation to ensure accuracy, the
ability to organize and categorize records effectively, and tools for data analysis and
reporting.

11
 IS315 | Systems Analysis & Design Project
Systems Proposal – Student Record Management System (SRMS)

6. System Requirements
This section covers all the system requirements inclusive of the functional and non-
functional requirements. The functional requirements basically talk about what the
system should do or the tasks it should perform. The non- functional requirements however
talk about the behavior of the system or how the system should behave.

A. Functional Requirements;
• User Authentication and Authorization: Access to student records should be
restricted to authorized users only.
• View Records: The system should enable users to view detailed information within
student records, including personal details and other essential details of a student.
• Search Records: Users should be able to search for and retrieve student records using
various search criteria such as name, surname or class.
• Add Students: The system should allow authorized users to create new student
records and edit existing ones.

B. Non – Functional Requirements

• Data Integrity: The system should ensure the integrity and consistency of student
data, preventing loss, corruption, or unauthorized modifications.
• Usability: The system should be user-friendly and intuitive, requiring minimal
training for users to navigate and perform tasks effectively.
• Security: The system should implement robust security measures to protect student
data from unauthorized access, tampering, or breaches.
• Reliability: The system should be reliable and available whenever needed, with
minimal downtime for maintenance or unexpected issues.
• Performance: The system should respond to user requests promptly, with minimal
latency, even during peak usage periods.

12
 IS315 | Systems Analysis & Design Project
Systems Proposal – Student Record Management System (SRMS)

7. Use Case
The Use Case section shows diagrams that outline various scenarios or sequences of
interactions between users and the system. The users of the system are teachers / academic
staff. All use cases were derived from the functions the system will play. There are a total of
four use cases;
• Use Case # 1: Student Registration
• Use Case # 2: View Student Records
• Use Case # 3: Search & Retrieve Student Record
• Use Case # 4: Edit Student Record

A. Use Case # 1
Use Case Name: ID: Priority:
Student Registration UC1 High
Actor: Teacher / staff
Description:
This use case describes the process of logging into the system, recording student data and
saving the information collected
Trigger:
The teacher/staff initiates the student registration process.
Pre – Conditions:
1. The teacher has a valid account and is logged into the system.
2. The teacher has access rights to perform student enrollment.
Normal Course:
1. The teacher logs into the system using their credentials.
2. The system verifies the teacher's credentials.
3. The system loads up the dashboard if the credentials are valid.
4. The teacher selects the "Add new student" option.
5. The system presents a form for the teacher to input student data.
6. The teacher submits the student data to the system by completing the form.
7. The system validates the data for completeness and accuracy.
8. If the data is valid, the system generates a dialog box saying “data saved
successfully” otherwise “data not saved, fill in all details”
9. The system adds the student's information to the school's database.
10. The teacher receives a confirmation message that the student has been successfully
Post – Conditions:
1. The student's information is stored in the school's database.
2. The newly added student is now accessible within the system for future reference
and management.
Exceptions:
1. If the teacher's login credentials are invalid, the system displays an error message
and does not allow access to the enrollment process.
2. If there are missing or invalid data fields on the student enrollment form, the system
displays an error message and prompts the teacher to correct the data.
3. In the event of a database error or system failure, the system displays an error
message and advises the teacher to contact technical support.

13
 IS315 | Systems Analysis & Design Project
Systems Proposal – Student Record Management System (SRMS)

B. Use Case # 2
Use Case Name: ID: Priority:
View Students Records UC2 High
Actor:
Description: This use case describes how a teacher views detailed information within
student records.
Trigger: The teacher selects the "View Student Records" option from the dashboard.
Pre – Conditions:
The teacher is logged into the system and has access rights to view student records.
Normal Course:
1. The teacher navigates to the "View Student Records" section.
2. The system presents a search interface with various criteria (e.g., name, surname,
class).
3. The teacher enters the search criteria to retrieve student records.
4. The system displays the matching student records with detailed information.
Post – Conditions: The teacher can view student records with personal details and
essential information.
Exceptions:
If the teacher enters invalid or unsupported search criteria, the system notifies them to
refine their search criteria and try again.

C. Use Case # 3
Use Case Name: ID: Priority:
Search & Retrieve Student UC3 High
Record
Actor:
Description: This use case describes how a teacher searches for and retrieves student
records based on specific criteria.
Trigger: The teacher initiates a search for student records from the dashboard.
Pre – Conditions:
The teacher is logged into the system and has access rights to search for student records.
Normal Course:
1. The teacher accesses the search interface from the dashboard.
2. The system presents various search criteria options (e.g., name, surname, class).
3. The teacher enters the search criteria and submits the search request.
4. The system retrieves and displays the matching student records.
Post – Conditions:
The teacher can retrieve student records based on the specified search criteria.
Exceptions:
If the search query submitted by the teacher does not yield any matching student records,
the system notifies them to revise their search criteria or verify the student's information.

14
 IS315 | Systems Analysis & Design Project
Systems Proposal – Student Record Management System (SRMS)

D. Use Case # 4
Use Case Name: ID: Priority:
Edit Student Records UC4 High
Actor:
Description: This use case describes how a teacher edits existing student records.
Trigger: The teacher selects the "Edit Student Records" option from the dashboard.
Pre – Conditions: The teacher is logged into the system and has access rights to edit
student records.
Normal Course:
1. The teacher navigates to the "Edit Student Records" section.
2. The system presents a list of editable student records.
3. The teacher selects a student record to edit.
4. The system displays the student's details in an editable form.
5. The teacher makes the necessary changes to the student's information.
6. The teacher confirms the changes, and the system updates the student record.
Post – Conditions: The teacher successfully edits the student's information, and the record
is updated in the system.
Expectations:
If the teacher attempts to edit a student record without the necessary access rights or
permissions, the system denies the edit request and advises them to contact the system
administrator for assistance.

E. Use Case Diagram

15
 IS315 | Systems Analysis & Design Project
Systems Proposal – Student Record Management System (SRMS)

8. Process Model
The process model provides an overview of how the Student Record Management System
interacts with external entities and manages data flow within the system. The context diagram
illustrates the system's boundaries, showing its interactions with users (in this case, teachers)
and highlighting the main data flows. It serves as a high-level representation of the system's
environment and external interfaces. Additionally, the level 0 DFD (Data Flow Diagram)
delves deeper into the internal processes of the system, breaking down the main functions and
data flows into more detailed components. Together, these diagrams offer stakeholders a
clear understanding of the system's interactions, and data flow mechanisms, laying the
groundwork for further analysis and design.

A. Context Diagram

Source: Visual Paradigm Enterprise (Evaluation Copy)

o The "Student Record Management System" is represented as the main system.

o The "Teacher" is the user (entity) interacting with the system.
o The only data flow from the teacher to the system is "Enter Student Information".
This represents the action of the teacher inputting student data into the system.
o The system's output back to the teacher is represented as “Display student
information”. The system does not produce reports, the specific output to the
teacher is not defined in this context diagram. However, it can be assumed that the
system may display student information or provide feedback on the inputted data.

16
 IS315 | Systems Analysis & Design Project
Systems Proposal – Student Record Management System (SRMS)

B. Level 0 Data Flow Diagram (DFD)

Source: Visual Paradigm Enterprise (Evaluation Copy)

Level 0 DFD:
Entities:
• Teacher/Staff: Represents the primary user who interacts with the system to manage
student records.
Processes:
There are 4 processes in total namely;
1. Login: This process is there to ensure users login using their credentials. A data
store is present to store database of registered users that can access the system. The
“authentication result” is the output as it displays weather the user has access or
not.
2. Add Student: This process shows that when teachers request to add new student
into the system, a “Student Registration Form” comes as the output for teachers to
enter details. The information gathered is stored in the data store “Student
Database”.
3. Search Records: This process shows that when a teacher search for a student,
they get the "search results” as the output. All information from the Student
Database is sent to this process.
4. View Records: This process shows that when a teacher wants to view a student
record via a “Student Record Request”, they get the “Student Record” information
as the output. All information from the Student Database is sent to this process.

17
 IS315 | Systems Analysis & Design Project
Systems Proposal – Student Record Management System (SRMS)

9. Data Model
The student record management system stores comprehensive information about students,
their parents or guardians, medical conditions, support fees, and academic attainment. Each
student record includes essential details such as surname, name, sex, class, contact
information, emergency contacts, and parental details, which are linked to the parent or
guardian entity. Additionally, medical conditions and academic achievements are associated
with individual students. Support fees, represented by school receipt numbers, are linked to
students to track support fees. These entities form a relational structure that captures and
organizes the diverse data points essential for managing student records effectively. The data
model below shows the entity relationship diagram for the system.

Source: Visual Paradigm Enterprise (Evaluation Copy)

18
 IS315 | Systems Analysis & Design Project
Systems Proposal – Student Record Management System (SRMS)

Backend configuration of the Database inside Visual

Studio using the data set designer’s view

19
 IS315 | Systems Analysis & Design Project
Systems Proposal – Student Record Management System (SRMS)

10. Interface Design

A. Login Interface

Login Interface – This is the 1st interface that appears. Users use their credentials to log in to
the system.

B. Main Dashboard Interface

Main Dashboard Interface - This is the main dashboard interface which users can use to
navigate to different options.

20
 IS315 | Systems Analysis & Design Project
Systems Proposal – Student Record Management System (SRMS)

C. Add Student Interface

Add New Student Interface – This is the student registration interface where a student detail
is being filled out before it is being saved.

D. View Records Interface

The picture above is the View Records interface, once data is filled, all information is stored
here.

21
 IS315 | Systems Analysis & Design Project
Systems Proposal – Student Record Management System (SRMS)

E. Help Interface
The help interface is accessed through the main dashboard, it is for users to read and
understand how to use the system

F. Logout Interface

Once the logout button is clicked, this appears instantly.

22
 IS315 | Systems Analysis & Design Project
Systems Proposal – Student Record Management System (SRMS)

11. Appendix
A. References
G2. (2022). ConexED Reviews & Product Details. Retrieved from G2.COM:
https://www.g2.com/products/conexed-conexed/reviews
Paita, M. (2024, April 8). Senior Teacher - Academic Team, Bugandi Secondary School. (J.
Miall, Interviewer)
Software. (2022). eSkooly Reviews. Retrieved from Software Advice:
https://www.softwareadvice.com/k-12/eskooly-profile/reviews/

B. Other Information
1.

The above screen shot shows the solution explorer in visual studio. This are all the forms and
database that create the foundational basis for the system. The forms are in .cs format.

23
 IS315 | Systems Analysis & Design Project
Systems Proposal – Student Record Management System (SRMS)
2. Fully Revised Project Plan

24
 IS315 | Systems Analysis & Design Project
Systems Proposal – Student Record Management System (SRMS)
USER MANUAL for Prototype
Adding a student:
1. Navigate to "Add Student" Tab: Click on the "Add Student" tab to begin adding a new
student record.
2. Fill in Student Details: Enter all relevant details of the student in the provided fields. This
may include personal information, academic attainment, medical history, and parent/guardian
details.
3. Save Data: Once all details are filled in, click on the "Save" icon to save the student's
information.

Viewing and Managing Records:

1. Search for a Student: Use the search functionality to quickly find a specific student record
by entering their name or student ID.
2. View/Edit Student Details: Click on a student's record to view or edit their details. Make
necessary changes and click the "Save" icon to update the record.
3. Delete Student: If needed, you can delete a student record by selecting the student and
clicking on the "Delete" icon.

Additional Features:
1. Support and Medical Records: The system also allows you to input support fee and
medical records for each student.
2. Dashboard Navigation: Use the navigation buttons or tabs to switch between different
sections of the application, such as adding students, viewing records, or accessing reports.

Saving Data:
All data entered into the system is saved automatically when you click the "Save" icon.
Ensure that all required fields are filled in correctly before saving.

Troubleshooting:
If you encounter any issues or errors while using the system, refer to the error messages for
guidance. If the problem persists, contact the system administrator for assistance.

Logging Out:
Once you have finished using the system, remember to log out to ensure the security of
student data.

25