KAUDHA SCHOOL STUDENT
MANAGEMENT SYSTEM
20/00555
NABIL OTIENO OMONDI
SUPERVISOR: GLADYS MANGEE
DIPLOMA IN INFORMATION
TECHNOLOGY
(DIT )
1
TABLE OF CONTENT
Contents
DECLARATION ON ORIGINALITY.................................................................................................................... 6
BACKGROUND ............................................................................................................................................... 7
INTRODUCTION ............................................................................................................................................. 8
PROBLEMS STATEMENTS .............................................................................................................................. 9
PROPOSED SOLUTION ................................................................................................................................. 10
PROJECT OBJECTIVES .................................................................................................................................. 11
LITERATURE REVIEW ................................................................................................................................... 12
METHODOLOGY .......................................................................................................................................... 13
BUDGET AND RESOURCES........................................................................................................................... 14
PROJECT SCHEDULE .................................................................................................................................... 15
1.0
SYSTEM REQUIREMENT SPECIFICATION(SRS) ................................................................................. 16
INTRODUCRION........................................................................................................................................... 16
1.1 Purpose ................................................................................................................................................. 16
1.2 Intended audience ................................................................................................................................ 16
1.3 Aims of SRS............................................................................................................................................ 16
1.4 PROJECT SCOPE ..................................................................................................................................... 17
1.5 Reference .............................................................................................................................................. 17
1.6 Overall Description................................................................................................................................ 17
1.8 User classes and characteristics............................................................................................................ 18
1.9 Operating Environment ........................................................................................................................ 18
Functional requirements ........................................................................................................................... 18
INPUT .......................................................................................................................................................... 18
PROCESS ...................................................................................................................................................... 18
OUTPUT ....................................................................................................................................................... 18
1.10 Design and Implementation constraints ............................................................................................. 19
1.11 User Documentation ........................................................................................................................... 19
1.12 Assumptions and Dependencies ......................................................................................................... 20
2
1.13 System features .................................................................................................................................. 20
1.14 External Interface Requirements ........................................................................................................ 20
GRAPHICAL USER INTERFACE (GUI) ............................................................................................................ 20
1.16 Software Interfaces ............................................................................................................................. 21
1.17 Communication Interfaces .................................................................................................................. 21
1.18 Other Non-functional Requirements .................................................................................................. 21
1.19 Security requirements......................................................................................................................... 21
1.20 Software Quality and Attributes ......................................................................................................... 22
1.17 Conclusion to SRS ................................................................................................................................ 22
SYSSTEM REQUIREMENT SPECIFICATION(SRS) ........................................................................................... 23
1.1 Purpose ................................................................................................................................................. 24
1.2 Scope ..................................................................................................................................................... 25
1.3 System Design Constraints .................................................................................................................... 26
1.4 Design Goals and objectives ................................................................................................................. 27
1.5 Overview of Document ......................................................................................................................... 28
2.0 System Architecture .............................................................................................................................. 29
2.1 Introduction .......................................................................................................................................... 29
2.2 The client-server model ........................................................................................................................ 29
2.3 Design Approach ................................................................................................................................... 29
2.4 Architectural Design .............................................................................................................................. 30
2.5 Logical Design........................................................................................................................................ 30
2.6 Use case Diagrams ................................................................................................................................ 30
2.6.1 Actors ................................................................................................................................................. 31
2.7 Deployment Diagram ............................................................................................................................ 32
2.8 Database Design.................................................................................................................................... 33
2.9 Normalization........................................................................................................................................ 34
3.0 Entity Relationship Diagram.................................................................................................................. 34
3.1 User Interface Design ............................................................................................................................ 34
3.2 Internal machine interfaces .................................................................................................................. 35
3.3 External system interfaces .................................................................................................................... 35
3.4 Human Interface ................................................................................................................................... 35
3.5 Description of the user interface .......................................................................................................... 35
3
Login form ................................................................................................................................................... 37
Home page .................................................................................................................................................. 37
Student Registration ................................................................................................................................... 38
Lectures/Teachers....................................................................................................................................... 38
Programs ..................................................................................................................................................... 39
Department ................................................................................................................................................. 39
Finance ........................................................................................................................................................ 40
Library ......................................................................................................................................................... 40
3.7 Software context ................................................................................................................................... 40
3.8 Expected software response ................................................................................................................. 41
3.9 Packaging and installation issues .......................................................................................................... 41
4.0 conclusions to SDS ................................................................................................................................ 42
4.1 References to SDS ................................................................................................................................. 43
PROJECT TEST PLAN .................................................................................................................................... 44
OBJECTIVES ................................................................................................................................................. 44
Testing Methods ......................................................................................................................................... 44
White Box Testing ....................................................................................................................................... 45
Black box Testing......................................................................................................................................... 45
TEST ITEMS .................................................................................................................................................. 46
APPROACH .................................................................................................................................................. 46
4.1 UNIT TESTING ........................................................................................................................................ 46
4.2 INTERGRATION TESTING ....................................................................................................................... 47
4.3 VALIDATION TESTING............................................................................................................................ 47
4.4 ACCEPTANCE TESTING .......................................................................................................................... 47
4.5 SYSTEM TESTING ................................................................................................................................... 48
TEST CASES .................................................................................................................................................. 48
TEST CASE 1-USER LOGIN ............................................................................................................................ 48
PASS AND FAIL CRITERIA ............................................................................................................................. 48
SUSPENSION AND RESUMPTION REQUIREMENTS ..................................................................................... 48
SUSPENSION CRITERIA ................................................................................................................................ 48
RESUMPTION REQUIREMENT ..................................................................................................................... 49
TEST DELIVERABLES .................................................................................................................................... 49
4
6.6 USER MANNUAL .................................................................................................................................... 50
6.7.2 System Overview................................................................................................................................ 51
6.7.3 Document Overview .......................................................................................................................... 51
6.8 SOFTWARE SUMMARY .......................................................................................................................... 51
6.8.0 Assistance and Problem Reporting .................................................................................................... 52
6.9 ACCESSS TO THE SOFTWARE................................................................................................................. 52
6.9.0 First Time User of the Software ......................................................................................................... 52
6.9.1 Installation and Setup ........................................................................................................................ 52
7.0 GUIDE .................................................................................................................................................... 53
7.0.0 Login form .......................................................................................................................................... 53
7.0.1 Home Page ......................................................................................................................................... 54
7.0.2 Students details.................................................................................................................................. 54
7.0.3 Teachers Details ................................................................................................................................. 55
7.0.5 Finance ............................................................................................................................................... 56
7.0.5 E- library ............................................................................................................................................. 57
CONCLUSION............................................................................................................................................... 58
REFERENCES ................................................................................................................................................ 59
5
DECLARATION ON ORIGINALITY
I hereby confirm that I am the sole author of the written work here enclosed and
that I have compiled it in my own words.
Kaudha Student Management system represents my original work and that I have
used no other sources except those that I have indicated in the references. All data,
tables, figures and citations which have been reproduced from any other source
including the internet have been explicitly acknowledged as such. I am aware
of the consequences of noncompliance of my above declaration.
6
BACKGROUND
Kaudha Secondary School is a government school located in South West Gem
Location in Gem Constituency within Siaya County and is a mixed day school,
providing convenient access to the students within the local geographical area.
Kaudha School has been serving the community for a period of 25years, offering a
variety of education services .The school has been performing well when it comes
to good results. Despite its success, Kaudha School has been facing several
challenges, including outdated registration system, manual fee payment systems,
lack of access to the online academic materials, and limited student information.
7
INTRODUCTION
A Student Management System is an environment that manages all the data of the
students who are studying in an educational institution. This data is computerized
through an automated system. Here, computerization is more advantageous than
the usual method. Thus, a student management system offers many benefits to an
educational institution. It allows teachers to easily change and access student data,
and parents can easily focus on children with a clear environment to meet state
level compliance and other regulatory requirements.
This system I have created also facilitates the entry, maintenance and viewing of
all authorized student details. Here we mainly focus on the examination of
students, their subjects, the registration department which conducts the registration
process, the examination department which conducts the examinations, the IT
division which is important component of the result and the smart ID components.
The special thing is that I have given all the students a unique ID and the program
they are involved in has also focused on age, gender and contact number. Each
department has a unique ID. For convenience, a designated location and e-mail
address are also used.
8
PROBLEMS STATEMENTS
Despite its success, Kaudha School faces several challenges, including:
• A lot of paper work.
• Manual registration of new students.
• Manual records for fee payment history and financial management.
•
Difficulty in searching records and limited student’s information. These
challenges result in long wait times, loss of data and dissatisfaction among
teachers, student and the parents.
• Lack of access to the online learning materials and the online library
9
PROPOSED SOLUTION
The design of the student information management system contains the home page
which is the first page of the system. The home page provides the login page using
which user can login in the system using their unique login credentials. The login
page provides the registration form for the new users through which they can
register themselves in the system.
At present, everyone is looking for a system that is superior to the facilities
provided by higher education institutions such as universities, without being
limited to the basic facilities. The purpose of this student management system is to
create a user-friendly management system. This system makes it easy to manage
student administration, school administration, as well as other internal affairs such
as student exams, fee payments, library, etc.
I suggested better techniques to get high output. For an example I used Database
function for this system. It is very efficient and useful system to keep all the data
accurately and can be accessed just in seconds.
10
PROJECT OBJECTIVES
All the information of the students can be managed as the main objective of a
student management system. For example, information about the students' exams,
their exam fees, courses as well as the personal profile of the students can be
obtained by creating such a system.
• Using such a student management system enables students to maintain their
information, as well as easy access and secure information over a long period of
time without any changes.
• Also, when retrieving a book from a library, students' data can be easily entered,
and in some cases, such a system helps to obtain information about the students
who obtained the books or who the students are. Managing a library using such a
system also makes it easier to manage time.
• The system will maintain the data accuracy.
11
LITERATURE REVIEW
Existing systems
According to student records manual created by most universities like KCA
University and Maseno University, the creation and maintenance of records
relating to the students of an institution are essential to:
 Managing the relationship between the institution and the student.
 Controlling the student’s academic progress and measuring their
achievements, both at institution and subsequently.
My system
 My system will ensure the students can get access to the online
learning materials and e-library through a single system and enhance
secondary education just like the universities mentioned in a better
way since the institutions mentioned above uses separate systems to
access different services.

Providing support to the student after they leave the institution .In
addition, student record contain data which the institution can
aggregate and analyze to inform future strategy, planning and service
provision. Educational Schools and agencies are required to confirm
to fair information practices. This means that person who is subjects
of data systems must.
12
METHODOLOGY
Research Methodology
• As far as data collection tools were concerned, I used the observation
method since Kaudha School is found in my area of locality. I further
involved the use of semi-structured questionnaire, which was used as an
interview guide for the researcher. Some certain questions were prepared, so
as for the researcher to guide the interview towards the satisfaction of
research objectives.
Development Methodology
•
The Student Management System will be developed using an agile
methodology, which involves collaboration between the development team
and stakeholders to ensure the product meets requirements and expectations .
Steps of agile methodology
The diagram below illustrates the steps of agile methodology:-
13
BUDGET AND RESOURCES
The estimated budget for this project is 60,000 Kenyan shillings, which includes
the cost of development, testing, deployment, and maintenance.
The table below illustrates full budgeting report for the project.
REQUEREMENT ESTIMATED
ACTUAL
VARIANCE
Computer
Machines
25,000
30,000
5,000
Printing Services
1,500
1,000
500
Printer
20,000
18,000
2,000
Binding
500
350
150
Antivirus
5,000
3,500
1,500
Programming tool
Free
Free
Free
Internet Services
10,000
10,500
500
Total
62,000
63,350
9650
14
PROJECT SCHEDULE
Tas
k
No.
Description
1
Project
proposal
design
Requirement
specification
2
Tas
k
No.
Of
Hrs
72
Subtas
k
No. of
Hrs
Planned
Start Date
12
15/05/2023 15/05/2023 18/05/2023 20/05/2023 Project
proposal
72
24
21/05/2023 21/05/2023 24/05/2023 24/05/2023 System
requireme
nts
document
25/05/2023 25/05/2023 28/05/2023 28/05/2023 Design
specificati
on
document
28/05/2023 28/05/2023 29/05/2023 29/05/2023 Presentati
on done
3
System Design
Specification
72
24
4
Preparation of
progress
report
Test Plan
design
System Coding
and compiling
12
12
72
24
168
72
7
System Testing 168
72
8
User Manual
Design
120
72
9
Project
120
Documentation
72
10
Project
Presentation
6
5
6
12
Actual
start date
Planned
completio
n date
Actual
completio
n date
Deliverabl
es
31/05/2023 31/05/2023 03/06/2023 04/06/2023 Test plan
document
05/06/2023 05/06/2023 12/06/2023 15/06/2023 Progress
presentati
on
16/06/2023 16/06/2023 23/06/2023 26/06/2023 Test
Results
27/06/2023 27/06/2023 02/07/2023 02/07/2023 User
manual
document
03/07/2023 03/07/2023 08/07/2023 08/07/2023 Final
project
document
and
compiled
system.
Project
15
1.0 SYSTEM
REQUIREMENT SPECIFICATION(SRS)
INTRODUCRION
1.1 Purpose
Student management system gives all the services that must be provided to a student over
the internet to find fee details provided by that administrator of the college.
This product contains each and every data regarding student, payment etc., personal details
which can be updated by the student and viewed by the administrator. It provides the
detailed information about the fee details and the location of the school..
1.2 Intended audience
The intended audience for this Student Management System document is the internal
guides of the organization where the team has developed the project. Further modifications
and reviewing will be done by the organization and deliver a final version. The final version
of this document is reviewed by the Internal Guides and Head of the Department of the
school.
The SRS can be used in any case regarding the requirement of the project and the solutions
that have been taken. The document would final provide a clear idea about the system that
is build.
1.3 Aims of SRS
The aims of SRS are;
1) Provide a basis for estimating costs and schedules
The description of the product to be developed as given in the SRS is a realistic basis for
estimating project costs and can be used to obtain approval for bids or price estimates
2) Reduce the development effort
The preparation of the SRS forces the various concerned groups in the users students system
to consider rigorously all the requirements before design begins and reduces later redesign,
recoding and retesting.
3) Provide a baseline for validation and verification
16
The Kaudha School will develop validation and verification plans much more productively
from a good SRS.
1.4 PROJECT SCOPE
This document covers the requirement specification for the Kaudha Student management
System.
Kaudha student management System was developed for general purposes to replace old
paper work system and to enhance the digital registration system
Kaudha Student Management System product usage makes work done at the faster way the
software is applicable to view the fee details provided by the administrator of the
organization and student can edit his personal details which can be viewed by the
administrator.
The scope of the SRS is for everyone to understand and have an idea about how the system
will be running and this will be used in the illustrations of having a diagram and Graphical
User Interface (GUI) where everyone will understand without much struggle.
Maintenance
to
production
Application
after
Support
deployment
&

The
Admin
Module
can
which
be
reused
have
formany
projects
users
as with
well
centrDeliver
Electronic
Workplace
Provide
Bi-lingual
Application
Support
& Maintenance
after
deployment
to production
The
Admin
Module
can
be reused
foris
projects
asthe
well
which
have
with
Any
college
can
usesupport
this
system
as it
not
client
centric.
All
admission
and
examination
related
work
for
student
can
bemany
done users
using
this
Deliver
Electronic
Workplace
1.5 Reference
» www.100projects.com
» https://www.med.unc.edu/it/guide/operating-systems/how-do-i-find-the-host-name-ipaddress-or-physical-address-of-my-machine/
1.6 Overall Description
System Perspective
The users of the system will have a unique username and password that will be secret. The
home page contains a login form through which an existing/authorized user can login to
the system by entering the username and password. A new user can also create an account
after clicking the “create account button/link”.
17
1.8 User classes and characteristics
The Student Management System software is designed in such a way that the user can easily
interact with the screen because of GUI. The students are the main users who use the
project. The student inserts the student’s details and the fee details that he/she has paid.
User/ student can view his/her details, update if required and check the fee details.
1.9 Operating Environment
SPECIFIC REQUIREMENTS
Functional requirements
The system should allow user to login in




Insert in new records
Ability to delete a record
Ability to update a record
Allow more than one user to access the system
INPUT
The main input is log in phase that will be used by the students
The system prompts the user to enter the user name and password required to have full
access of his or her services.
PROCESS
The system, like any other normal system it will validates the username and password for
security purposes.
If the details entered by the client or the admin are valid the user logs into the system
If the details are invalid the system displays invalid message
OUTPUT
After successful login, the system should be able to display the home page, where the user
can select multiple services e.g. the registration menu. The teachers Details and the fee
18
balance is also displayed. The user is also able to view the available online learning
materials upon clicking the e-library link.
1.10 Design and Implementation constraints




The system must be user-friendly
Only administrator will access the whole system
Each user should have ID and password
System is only accessible within the school premises only
1.11 User Documentation
In order for the system to be optimally used and the project in it’s entirely to become success
the users will need to be trained so that they can maximise the utility of the developed
software.
As part of the training of this system the following documentations is at the user’s disposal;
. Knowledge base
-Designed and compiled by the vendor.
-Good for quick reference
-Assumes user knows what to look for
. Command prompts
-Provide information about correct usage when error occurs
-Good for syntactic errors
-Also assumes knowledge of the command.
. User manual
-This is a document that will be provided by the developer
-It is easy to understand
. On-line documentation
-Documentation is made available online
-Continually available in common medium
19
-can be difficult to browse
1.12 Assumptions and Dependencies
. It is assumed that the test data provided is reliable
. A dedicated server will be availed for optimum functioning of the system
. It is assumed that the users can competently use the system
. The current and the future staff will always be IT literate
1.13 System features
The data in the student management system application will perform major functions;




Storing and keeping students information
Each student reports
Billing details
Management records
The software will help to calculate the fee much quicker and simpler way. This
enables the organization to keep the information in efficient and systematic way.
1.14 External Interface Requirements
The interface requirement will indicate how the system interacts with other software
products or users for input or output process. The Kaudha student management System will
have an interface; the user forms that are developed by the system developer.
GRAPHICAL USER INTERFACE (GUI)
The normal users will access the database using GUI interface.it will display objects that
convey information and represented actions that can be taken by the user
20
1.15 Hardware Interfaces
Laptop
Core i5 processor
8GB RAM
1TBHDD
1.16 Software Interfaces
Operating System
The system to be used can either be installed in windows or Linux system. For this
particular client the product application and database server will be installed, MS.Net 3.5
and C#.Net 3.5 Programming language for writing the code for the project
The product will run on MYSQL database which will be installed to serve as the database.
1.17 Communication Interfaces
The communication function required by this system is a LAN connection within the whole
institution so that the Admin and other staff members can interact with each other. We use
TCP/IP protocol.
1.18 Other Non-functional Requirements
PERFORMANCE REQUIREMENTS
Conformity; the system must conform to the Microsoft Accessibility
Capacity; the system must support over 500 people at a time
Response time; the system will give responses within fastest time possible after checking
information about both staff and clients
1.19 Security requirements
Username and password
21
To use the system and access database the user will have to have a username and password
.The password must comply with the password policy.
. Back up facility
To ensure clients data are safe and can be recovered a backup mechanism should be in
place, regular backups should be done to ensure the backups are up to date.
1.20 Software Quality and Attributes
Maintainability
Changes can be made on the system in future such as upgrading and adding more features
to it.
Scalability
The system can be upgraded and downgraded and still be in operation.
1.17 Conclusion to SRS
The requirement of the system specification was an important input to the
requirement specification.
22
2.0 SYSSTEM DESIGN SPECIFICATION (SDS)
The software Design Document is a document that provides the documentation of
the System Design Specification which will be used to aim and aid in software
development by providing the details on how the system needed to be designed and
built. Narrative and graphical documentation of the software design for the project
includes the use cases of models, sequences diagram, activity diagram, class
diagram, and other supportive requirements information.
The SDS also provides the inner details of the Kaudha School Student System. It
can trace clients’ requirements and at the same time assess for quality against a set
of predefined criteria for a good design.
At the end of the designing the system, it should ensure that:
 Both the school management and students should be able to use the system
easily.
 It should be reliable and secure for both the users using the system.
 It should be in a position where it can be integrated into another system.
 It should be able to provide the correct function of the end- users
23
1.1 Purpose
The purpose of the software Design Document is to provide a description of the
design of a system fully enough to allow for software development to proceed with
an understanding of what is to be built and how it is expected to build .The
software Design Document provides information necessary to provide description
of the details for the software and system to be built.
24
1.2 Scope
The SDS is for a base level system which will work as a proof of the concept for
the use of building a system that provides a base level of functionality to show
feasibility for large scale production use.
This Document contains a complete description of the design the student
management system .The basic architecture is application server from a
client/server paradigm. The basic forms will be in MySQL and coded using visual
studio.
25
1.3 System Design Constraints
The system design is directly constrained by the user requirement specification,
which has been as a result of system analysis .This will describe the functions that
are required by the user which must be implemented as part of the design, as well
as the environmental constraints on design which are a result of the hardware and
software environment of implementation .These include;
. Integrating data from the existing system to the new system
. Interfacing with other application may be difficult to implement
. The system is going to be tested internally the users may not know what is
required of them during testing phase
26
1.4 Design Goals and objectives
The goal is to design a system which delivers the functions required by Kaudha
Student management system to support the students.
. Design is the place were quality is fostered in software development
.Design provides us with the representations of software that can be assessed for
quality
Objectives
Flexibility-The system design should enable future requirements of the cooperative
society to be incorporated without too much difficulty
Ease of use-The system design should enable implementation of system that is user
friendly and ease to use
Secure-The system design should incorporate methods that will restrict access to
authorized users only.
27
1.5 Overview of Document
The SDS is a document that divides into different sections, which include:
 Section 2, is where the architectural design is specified entities, which
collaborate to perform all the functions, required.
 Section 3, which includes the files and the data structure design
 Section 4, contains the design activities that are used to optimize the logical
storage of the data within the database.
 Section 5, where the conclusion of the SDS is illustrated, shows how the
system will fulfill the user requirement.
28
2.0 System Architecture
2.1 Introduction
Software architecture is the blueprint of a software system.it provides an overview
of the composition and functionality of the given system software system. Just like
a structural architect, software architecture needs to analyze the requirements,
determine components that should be used to build a system, and support the
project by guiding and solving problems all along the execution cycle.
2.2 The client-server model
This model majorly distributed as a system model and show how the data and
processing distributed across a range of processor. It includes:
 To have a network that allows the client to access the services.
 A set of the stand- alone servers that offers services to other sub systems.
 To have a set of clients that call on the serves offered by the servers, mostly
a sub- system in their own right.
2.3 Design Approach
Software architecture entails modularity, software that divided into separate names
and addressable components called modules that satisfy problem requirements.
Monolithic software cannot be easily be held by the reader, the number of span
reference, number of variability and overall complexity that would be understood.
Those can lead to divide and conquer conclusion, it is easy to solve a complex
problem when breaking into managing pieces.
29
2.4 Architectural Design
It molds a program structure and data structure, when defining interface that can
enable the data to flow through the program.
The system that is proposed will be developed by using two architecture designs.
The application that runs on the workstation will be a larger program containing all
the application logical and display code. It will be able to retrieve data from the
separate database server.
2.5 Logical Design
The Logical Design illustrates the function that is required of the system to
perform and, what is done. The logical design is not concerned with the hardware
and the software that is required but rather with the processes to perform.
2.6 Use case Diagrams
A use case diagram is a diagram that shows a set of use cases actors and their
relationships.
30
2.6.1 Actors
It is a role that user play with the respect to the system. There are two actors in the
system to be design: The Kaudha School Management and The Students.
31
2.7 Deployment Diagram
This a diagram that is used to provide a solid blue print for the hardware, the
database and the client and the management will communicate using the Local
Area Network (LAN) that is in place.
Object database
LAN
Server
Object client
Workstation
32
2.8 Database Design
A database provides a consistency of the data and at times, it provides access for
the many users at once, independent of programs that are used.
The standard user and application program interface to a relational database is
MySQL.
A reliable and adequate database system has the following properties;
Atomicity; that is result of a transactions executional are either all committed or
rolled back
Consistency; the database is transformed from one valid state to another valid state.
Isolation; the results of a transaction are invisible to other transactions until the
transaction is complete thus is increasing the security on data.
Durability; the results of a transaction are permanent and survive future system.
33
2.9 Normalization
It is a design activities used to optimize the logical storage of the data within a
database, it normally simplify the entities and removal of duplication of data.
When it became to its main purpose, the data normalization is a group data items
accumulative in the database
3.0 Entity Relationship Diagram
3.1 User Interface Design
The aim of interface design is to specify how to build portioned applications from
software components. The interaction of these components through defined
34
interfaces results in the desired behavior of the system as a whole. The rules for
communicating between components are defined by interaction standards: what a
component does and how it communicates are major considerations in physical
design.
3.2 Internal machine interfaces
There is an existing client/server network and the system will be installed on the
server.
The users would access the information through the network on their local
machines.
Anytime a user updates a record the system is automatically updated on the server.
3.3 External system interfaces
The server should be installed with antivirus to protect it from any viral attack.
Internet should be installed in to the school to ensure that there is online antivirus
update.
3.4 Human Interface
The server room allowed to be access by the technical staff hence ensuring that
slight errors does not occur without the staff knowledge. Other users are allowed to
the system through the local machines but only if after they have authenticated,
and accepted by the system. The authenticated members might include the School
Staff.
3.5 Description of the user interface
 Command Buttons- this will act as a way of issuing commands to the system
to do a certain task such as Save, Cancel, And Exit.
 Use drop-down menu- user commands that are in words and can often if
needed.
 Icons – these are images that represent a certain function like a printer icon
 Command line- the user can write the command line in Access.
35
36
Login form
Home page
37
Student Registration
Lectures/Teachers
38
Programs
Department
39
Finance
Library
3.7 Software context
The system to be designed will include several modules, a relationship that will be
able to connect all the tables so that they can be able to relate and share the data to
40
accomplish the entire task expected for the bills to be reflected and to appear clear
for the clients.
3.8 Expected software response
The software is expected to respond normally with no or minimal errors because
the system has undergone through testing before handing over to team of testers.
These errors which might occur should be corrected before the system is delivered
to the client
3.9 Packaging and installation issues
The system should be packaged in a copyrighted compact disk and accompanied
by its documentation.
41
4.0 conclusions to SDS
The system requirement specification was an important input to the design
specification.
From the design it is concluded that the system will be able to fulfill the described
user requirements and tests plan document will be designed to help in verification
of this argument.
42
4.1 References to SDS
1. https://www.coursehero.com/file/56357962/SDSdocx/
2. https://www.studocu.com/in/document/st-josephs-collegeautonomous/bachelors-of-commerce/student-management
43
PROJECT TEST PLAN
The testing process focuses on the logical intervals of the software ensuring that all
statements have been tested and on functional interval is conducting tests to
uncover errors and ensure that defined input will produce actual results that agree
with the required results. Program level testing, modules level testing integrated
and carried out.
A test plan is done to test whether the system is fully functional and can be used by
the clients. Kaudha student management system will be tested to determine
whether it can be used by the clients without any problems.
OBJECTIVES
The main objectives of the test plan for the Kaudha Student management system
are as follows:
 To identify the features of the system that will be tested.
 To define the pass/fail criteria of each item that will be tested
 Define any suspension criteria and resumption techniques
 To identify the deliverables of the testing phase
 To discuss the testing techniques being used to test the Kaudha student
management system.
Testing Methods
There are two major type of testing they are
1) White Box Testing.
2) Black Box Testing.
44
White Box Testing
White box sometimes called “Glass box testing” is a test case design uses the
control structure of the procedural design to drive test case.
Using white box testing methods, the following tests were made on the system
a) All independent paths within a module have been exercised once. In our system,
ensuring that case was selected and executed checked all case structures. The bugs
that were prevailing in some part of the code where fixed
b) All logical decisions were checked for the truth and falsity of the values.
Black box Testing
Black box testing focuses on the functional requirements of the software. This is
black box testing enables the software engineering to derive a set of input
conditions that will fully exercise all functional requirements for a program. Black
box testing is not an alternative to white box testing rather it is complementary
approach that is likely to uncover a different class of errors that white box methods
like..
1) Interface errors
2) Performance in data structure
3) Performance errors
4) Initializing and termination errors
45
TEST ITEMS
The section of the test plan lists all the items of the Kaudha student management
system project that will be tested:
 User login
 Home page
 Student details
 Fee payment
 Teacher’s details

E-library
APPROACH
The testing would be carried out on the System while logging into the system as a
student. The approach followed would ensure the user login, student’s details,
home page, teacher’s details, programs, e-library and check all the aspects are well
tested.
4.1 UNIT TESTING
Unit testing is a software verification and validation method in which a
programmer tests if individual units of source code are fit for use.
A unit is the smallest testable part of an application. In procedural programming a
unit may be an individual function or procedure. Ideally, each test case is
independent from the others: substitutes like method stubs, objects, fakes and test
harnesses can be used to assist testing a module in isolation.
The system interface and functionalities in the visual studio have been tested. The
codes for login form are running without errors, all of the codes written for various
controls are running and functioning well without errors.
46
4.2 INTERGRATION TESTING
This testing is sometimes called Integration and Testing. Integration testing is the
phase in software testing in which individual software modules are combined and
tested as a group. It occurs after unit testing and before system testing. Integration
testing takes as its input modules that have been unit tested, groups them in
larger aggregates, applies tests defined in an integration test plan to those
aggregates and delivers as its output the integrated system ready for system testing.
The login form and other forms, which make up the Kaudha Student management
system, are fully functional when combined together. The performance of all them
is excellent and ready to be used by the students.
4.3 VALIDATION TESTING
Validation Testing can be defined in many ways, but a simple definition is that
validation succeeds when the software functions in a manner that can reasonably
expected by a customer. After validation test has been conducted, one of the
following two possible conditions exists. The functions or performance
characteristics confirm to specification and are accepted.
 In the administrator and marks modules, all the fields must be filled.
 In the student registration, mobile number should contain exactly 10
numbers
4.4 ACCEPTANCE TESTING
User acceptance of a system is a key factor of any system. The system
under consideration is tested for the acceptance by constantly keeping in
touch with the prospective system users at the same time of developing and
marketing changes whenever required. This is done in regard to the following
points:
 Input Screen Design
 Output Screen Design
47
This system is fully functional and it is therefore qualified to be used by students to
manage their studies.
4.5 SYSTEM TESTING
This system meets all the requirements and can be used by the students easily
without any problems.
TEST CASES
TEST CASE 1-USER LOGIN
Incorrect Input: incorrect username
Pass criteria: Appropriate message is generated to indicate invalid username
Correct Input: the correct input would login successfully
Pass criteria: The user should be directed to the webpage that the user is intended
to go after he/she logins
PASS AND FAIL CRITERIA
The test cases executed on the system should pass because they meet all the
requirements of the project.
SUSPENSION AND RESUMPTION REQUIREMENTS
SUSPENSION CRITERIA
Testing for all the dependent features will be suspended if a test case fails.
48
RESUMPTION REQUIREMENT
The test case which is not dependent on the case where the bug is reported will be
executed in parallel with the bug fixing.
TEST DELIVERABLES
The following documents will be produced after the testing phase
 Test plan
 Test cases
 Test log
49
6.6 USER
MANNUAL
This user manual is a technical documentation that is formed to instruct the user on a
software; Kaudha student management System that is introduced in the school, instruction
manual is one of the crucial document that assist the clients or the students to get equipped
with the system implemented faster or by the help of a person who knows how to use the
system better.
Before the user manual is introduced to the students, it should have been made through a
good search and how it’s accessible, it should be comprehensive and accurate, concise and
unambiguous
6.7 GENERAL INSTRUCTION
6.7.0 Purpose and Scope
The main purpose of this document as the user manual is to act as a guiding tool to the new
user. The guidance will comprise of the whole and full of accurate instruction to the user to
avoid confusion of the new user in to the system. The user will be able to understand the main
purpose of coming up with this system.
6.7.1 Organization
The organization that came up with the idea of the billing system is the Kaudha Secondary
school after agreements of entire students and school staffs to have a system that will help
improve the school activities and reduce problems that have been faced by the school for the
past years.
50
6.7.2 System Overview
This is a system with an aim of replacing the manual operations that has been used by the
school since it began operations. The system primary function and purposed to capture the
information of the new and existing students storing their details in the database MySQL, also
to ensure the data are kept in an organized manner and to reduce congestion of students in the
reception during registration.
The System is programmed using Visual Basic Studio as the main interface connected with
MySQL as the database.
6.7.3 Document Overview
The system documentation is a one phase document with only one chapter and with an
intention of giving guidance to the new users or any user who can’t remember the full step.
6.8 SOFTWARE SUMMARY
The software has been made in such a way that it will be compatible in all the OS available, the
programming language being used based on the standards on the programmers to provide
efficiency and standard services to the clients. The programming language used was visual basic
studio and a database of MySQL lite.
51
6.8.0 Assistance and Problem Reporting
The system, after the test and implemented will be put into practice by those users under
training, in case of any correction, it will be submitted to the system admin who will letter
communicate to the system programmers to make clarification.
Assistance to the new users will be provided by the reception office who will at least be
familiar to the system.
6.9 ACCESSS TO THE SOFTWARE
6.9.0 First Time User of the Software
The first time users of the system will be definitely be guided by the experts or by being
given the manual, either the hard copy or softcopy guide.
6.9.1 Installation and Setup
The installation of the system will be accessible through phone app and the website version. For
users who would feel like having the app on the phones will be able to download the app from
play store for users with android phones while on apple store for users with iPhone.
The app is compatible with both phones, similar to the website interface will be friendly to
the new users.
52
7.0 GUIDE
7.0.0 Login form





The user interface is meant for only the registered students who their credential is in
the database and proceeds by clicking the login button. For a new user to have an
access to the system, they will use the create account button to activate their new

accounts so as to be able to access the system and the services available.
The log in interface includes
the user name and the user password textboxes, login
and create account button.
You can also use the checkbox to either view or hide password.
53

7.0.1 Home Page

The home page interface acts as the main stand or bridge between the user and the
services they want to apply for, for the new users will have to start from the student
details button to register them in the button while other users who have been in before

will check with other services listed.

7.0.2 Students details
54


New teachers will 
be able to submit their particulars as required in this interface.
Detail needed are:
Student ID First
name Middle name
Last name Age
Gender Contact
Number Email
Address Year of
intake
Expected completion year
With the detail above, it will be submitted and captured to the database
7.0.3 Teachers Details
55


New Teachers will
be able to submit their particulars as required in this interface.
Detail needed are:
Student ID First
name Middle name
Last name Age
Gender Contact
Number Email
Address
7.0.5 Finance




This interface
 will be used majorly by those who are paying school fees through bank
transfers.
Advance 
payment will be made and the balance will be handed to them in case it is
available
56

Once a successful payment
is made, the system will automatically display the balance in

the balance textbox.


7.0.5 E- library





This interface will be majorly used by students who would wish to borrow books from
the physical library. They
 key in the relevant details required before they are issued
books by the librarian.
In case the students want to access online books, they just click on the online library
button. This
 will enable them to download online materials for strictly learning
purpose.
The user manual being described above carries all the particulars required for the users to have
an easy step to learn about the Kaudha student management system. The user manual will
efficiently help new users to familiarize with this system and enable the do their operations with

minimal or completely no error
57
CONCLUSION
The Student Management System will improve the efficiency and convenience of
Kaudha School, increasing student’s satisfaction and reducing errors. The project
will be implemented using the latest technologies and standards, ensuring a highquality product. The budget and resources are reasonable, providing a good return
on investment in the long run
My project is only a humble venture to satisfy the needs in an Institution. Several
user friendly coding have also adopted. This package shall prove to be a powerful
package in satisfying all the requirements of the organization.
58
REFERENCES
• Information for Kaudha Mixed, Secondary School
retrieved from:
 https://education254.co.ke/secondary-schoolskenya/kaudha-mixed
• Student management system information, retrieved from:
 https://tuiopay.com/blog/what-is-a-student-managementsystem
• Student Management System Modeling Diagram – (Google
Drive Link)
https://drive.google.com/drive/folders/1NcZwCNNsgRdq8
AMlh1MQv82- 7vDSMeF4?usp=sharing
59