OMER-BINU-KADAB SCHOOL MANAGEMENT SYSTEM

ABDIKANI AHMED ISMA’IL

13082

AMOUD UNIVERSITY

JANUARY,2022
 ABDIKANI AHMED ISMAI’IL
(13082)

Report submitted to fulfill the partial requirements for the bachelor of business
iCT Amoud University

January,2022
 DECLARATION

I declare that this is my original work and all references have been cited adequately
as required by the university

Data :12/01/2022 signature

ABDIKANI AHMED ISMA’IL
ID:13082

ii
 APPROVAL

We have supervised and examined this report and verify that it meets program and
university requirement for the bachelor

Data :12/01/2022 signature…………………….

Abdiwahab Yousef Abdillahi
.

Data :12/01/2022 signature……………….

Edwin okech

iii
 ACKNOWLEDGMENT

I would like to express my special thanks to my supervisor (Mr. Abdiwahab Yousef)

who guided me throughout this project. I would also like to thanks my friend and
family who support me and offered deep insight into study

iv
 CHAPTER ONE: INTRODUCTION

1.0 introduction

This chapter consist of background of the study, followed by problem statement,

purpose of the study objective of the study research question, scope of the study,
significance of the study.

1.1 background

Omer Binu Kadab secondary school is one of the private schools in

Borama. It’s a historical schools and was established early in 1999’s and the
school has played an indispensable role in the revival of primary education at
a time security was very fragile and later on intermediate and highly schools.
The school is now viewed by many to be of the few best schools in
Somaliland when it comes to quality education, discipline and academic
excellence a fact that this year’s leaving exam results can reflect. Omer binu
kadab schools provide educational opportunities to thousands of students
who go to the chain of school that are scattered throughout the regions of
Awdal salal in SomalilandThis school is also one of the main suppliers to
Amoud university whereby a large number of student who have completed
their high school at Omer binu kadab join Amoud very year as freshman

1.2 Problem statement

The Main problem in omer binu kadab secondary school is didn’t have systematic
data arrangement. Using manual system to manage the student which are record
all information and in the book or paper was causing the job of the teachers become
more and troublesome.

1.3 Project objectives

1.3.1 General objectives

The main objective of the school management system is to manages all the
information about school and to maintaining student details and information,
registering students, employee and teacher’s information.
1.3.2 specific objectives

 To manage the details of schools, student, classes.

 To generate the report of schools
 To increase efficiency of managing the school
 Save time and make the work easy for desk user
 To get actual number of students will register in school
 To facilities various report generation

1.4 Research question

1. How to manage the details of school, students and classes?

2. How to generate the report of schools?
3. How to increase efficiency of managing the school?
4. How to save the time and make the work easy?
5. How to get the actual number of student will register?
6. Ho to facilitate the various report generation?

1.5 significance of the project

The staffs and student will benefit in the system. the will find it easier to
transact about their record since searching in the system is faster than tracing
in the record book or big book. The software will give them an easier time
either them the power to:

 Manage the data

 Manage employee information efficiently
 Maintain student data efficiently

1.6 scope of the project

This project will be conducted in Borama town, Awdal region. The project will
be carry out in omer binu kadab secondary school. School management system is
intended to help the any institute that wants to store their students and management
records into the computer. It will also store the fee information of the students and
parent’s information this software will also help the management to store Teachers
information including their personal information or information salary

2
 CHAPTER TWO: LITERATURE REVIEW
2.1 Introduction to School Management Information System

According Silva (2004) system is group of interrelated components working

together toward a common goal by accepting input and producing output in an
organized transformation process According to (Alba, 2008) Information System is
set of people procedures and resource that collect transform and disseminates
information in an organization. Information system knowledge is essential for
manager because most organizations need information system can help company
extend their reach to faraway location. According (2007) Management Information
System (MIS) deal with the planning for development management and use of
information technology but the body of management system defined into two types
according the definition of Donald and the definition of Sergio.

2.2 The Definition of Donald

According Donald (2010) School Management Information System should use

both knowledge in the world and knowledge in the head where a knowledge in the
world is overt which in the same time users do not have to overload their short term
memory by having to remember too many things (icons, buttons, and menus provide
them with knowledge in the world - They do not have to remember the command for
printing; it is there in front of them). On the other hand, while knowledge in the head
may be harder to retrieve and involves learning, it is more efficient for tasks which
are used over and over again (providing a command key sequence like Control P for
Print is an example for this).

2.3 Definition of Sergio.

School Management Information System (SMIS) consist of tasks such as

registering students, attendance record keeping to control absentees, producing
report cards, producing official transcript, preparing timetable and producing different
reports for teachers, parents, officials form educations bureaus and other
stakeholders. Students will able to check their results, time tables and routines by
going through their student dashboard. Administration will able to send direct
messages to the parent’s inbox by using their id and parents will check those
messages and apply directly to them (Sergio, 2006)

3
2.4 Current Omor binu khadab Management Information System

Omar binu Khadab School The primary school was established in 1996, the
primary school enrolment is around 500 students, the middle school was established
in 2000, the number of middle school students is 669 teachers and the high school
was established in 2013 with about 600 students dropping out. Our Omar binu
Khadab School was established in 1996 in the town of Borama in the Awdal
Somaliland region. The number of students is 1769 students. The number of
teachers is 34 We that will be managed by students at Omor bin Khadab School
Student Management System. Omor binu Khadab School consist tasks such as
registering students, attendance record keeping to control absentees, producing
report cards, producing official transcript. Also you can modified this system as per
your requirements and develop a perfect advance level project. Project is used to
provide facilities to user to perform their jobs quickly and accurately. That is why
project is used in most organizations to maximize the efficiency and performance of
the organization. The objectives of the latest technology are to speed up the system,
to reduce the errors and to develop error free inputs, as invalid inputs are the main
cause of computer mistakes and a computer never makes mistakes of its own
Middle school is a primary part of Omor binu khadab School it begging level 6 up to
level 8, it teaching middle age student and they learning Arabic, English, Somali,
Math, Islamic studies and ETC. And they have many teachers with different
knowledge. Omor binu khadab school have higher education and knowledge and
they produce student have full skills, education and knowledge High school is a
highest part of Omor binu khadab School and it begins Form One up to Form Four
and it teaching the student with under graduating of school and they learning
different language and they are modern then the two part that we discuss in top page
and they have allot of teachers with different skills knowledge and country

4
 CHAPTER THREE METHODOLOGY
3.1 SDLC Methods

Systems Development Life Cycle (SDLC) adheres to important phases that

are essential for developers, such as planning, analysis, design, and implementation,
and are explained in the section below. There are several Systems Development Life
Cycle Models in existence. The oldest model, that was originally regarded as "the
Systems Development Life Cycle" is the waterfall model: a sequence of stages in
which the output of each stage becomes the input for the next. These stages
generally follow the same basic steps but many different waterfall methodologies
give the steps different names and the number of steps seems to vary between 4
and 7. There is no definitively correct Systems Development Life Cycle model, but
the steps can be characterized and divided in several steps.

A Data Flow Diagram (DFD) is a graphical representation of the "flow" of data

through an information system, modelling its process aspects. A DFD is often used
as a preliminary step to create an overview of the system, which can later be
elaborated. DFDs can also be used for the visualization of data processing
(structured design).The Data flow Diagram will explain how data is processed and
transferred in a system. The graphical depiction identifies each source of data and
how it interacts with other data sources to reach a common output.

SDLC works by lowering the cost of software development while

simultaneously improving quality and shortening production time. SDLC achieves
these apparently divergent goals by following a plan that removes the typical pitfalls
of software development projects. That plan starts by evaluating existing systems for
deficiencies.

Next, it defines the requirements of the new system. It then creates the
software through the stages of analysis, planning, design, development, testing, and
deployment. By anticipating costly mistakes like failing to ask the end-user or client
for feedback, SLDC can eliminate redundant rework and after-the-fact fixes.

It’s also important to know that there is a strong focus on the testing phase.
As the SDLC is a repetitive methodology, you have to ensure code quality at every

5
cycle. Many organizations tend to spend few efforts on testing while a stronger focus
on testing can save them a lot of rework, time, and money. Be smart and write the
right types of tests.

Figure 1: Waterfall Model

3.1.1 Spiral Model

The spiral model of the software process has been evolving for several years,
based on experience with various refinements of the waterfall model as applied to
large government software projects. As will be discussed, the spiral model can
accommodate most previous models as special cases and further provides guidance
as to which combination of previous models best fits a given software situation.
Development of the TRW Software Productivity System (TRW-SPS), described in
the next section, is its most complete application to date.

3.1.2 Waterfall

Some experts argue that the Waterfall model was never meant to be a
process model for real projects (check out the discussion on this topic on Stack
Exchange). Regardless, the Waterfall model is widely considered the oldest of the
structured SDLC methodologies. It’s also a very straightforward approach: finish one
phase, then move on to the next. No going back. Each stage relies on information
from the previous stage and has its own project plan.

6
 The downside of Waterfall is its rigidity. Sure, it’s easy to understand and
simple to manage. But early delays can throw off the entire project timeline. With
little room for revisions once a stage is completed, problems can’t be fixed until you
get to the maintenance stage. This model doesn’t work well if flexibility is needed or
if the project is long term and ongoing Even more rigid is the related Verification and
Validation model - or V-shaped model. This linear development methodology sprang
from the Waterfall approach. It’s characterized by a corresponding testing phase for
each development stage. Like Waterfall, each stage begins only after the previous
one has ended. This SDLC model can be useful, provided your project has no
unknown requirements.

Waterfall Model is one of the most widely used Software Development

Process. It is also called as "Linear Sequential model" or the "classic life cycle" or
iterative model. It is widely used in the commercial development projects. It is called
so because here, we move to next phase (step) after getting input from previous
phase, like in a waterfall, water flows down to from the upper steps.

3.1.3 V-Shaped Model

Also known as the Verification and Validation model, the V-shaped model
grew out of Waterfall and is characterized by a corresponding testing phase for each
development stage. Like Waterfall, each stage begins only after the previous one
has ended.

This model is useful when there are no unknown requirements, as it’s still
difficult to go back and make changes.

3.1.4 Rapid Model

Rapid application development (RAD) is an agile project management

strategy popular in software development.

The key benefit of a RAD approach is fast project turnaround, making it an

attractive choice for developers working in a fast-paced environment like software
development. This rapid pace is made possible by RAD’s focus on minimizing the
planning stage and maximizing prototype development. By reducing planning time
and emphasizing prototype iterations, RAD allows project managers and

7
stakeholders to accurately measure progress and communicate in real time on
evolving issues or changes. This results in greater efficiency, faster development,
and effective communication.

3.1.5 Waterfall SDLC

This model is used only when the requirements are very well known, clear
and fixed.

 Product definition is stable.

 Technology is understood.
 There are no ambiguous requirements
 Ample resources with required expertise are available freely
 The project is short.

In Waterfall model, very less customer interaction is involved during the

development of the product. Once the product is ready then only it can be
demonstrated to the end users. Once the product is developed and if any failure
occurs then the cost of fixing such issues are very high, because we need to update
everything from document till the logic. In today’s world, Waterfall model has been
replaced by other models like iterative, agile etc.

3.2 Planning and Requirements Collection Methods

Planning and requirements methods are in preparing a questionnaire, it is

important to pilot test forms designed for the interviews. The best attempt to clarify
and focus by the designer cannot anticipate all possible respondent interpretations

3.2.1 Interview

Interviewing is probably the most widely used fact-finding technique; a well-

structured interview with a right member of staff will enable the necessary facts to be
gathered. It can provide required information from staff’s perspective. If I can find the
staff who manages the current system, some system’s technical details may also be
gathered. However, it is also the one that requires the most skill and sensitivity,
therefore, enough preparation before the interview is crucial to the success.

8
Guidelines should also be followed. Bennett et al (2002) provide useful and detailed
guidelines for interviewer to adopt before, at the start of, during and after the
interview. Due to the distance barriers, some interviews should also be done through
e-mail or telephone. Core questions will be asked, answered and understood for
each system. Details about interviewees who were involved in the system
investigation as well as the questions asked will be provided in appendix B interview
scripts.

3.2.2 Observation

Observation, as the name implies, is a way of collecting data through

observing. Observation data collection method is classified as a participatory study,
because the researcher has to immerse herself in the setting where her respondents
are, while taking notes and/or recording.

Observation as a data collection method can be structured or unstructured. In

structured or systematic observation, data collection is conducted using specific
variables and according to a pre-defined schedule. Unstructured observation, on the
other hand, is conducted in an open and free manner in a sense that there would be
no pre-determined variables or objectives. Advantages of observation data collection
method include direct access to research phenomena, high levels of flexibility in
terms of application and generating a permanent record of phenomena to be referred
to later. At the same time, observation method is disadvantaged with longer time
requirements, high levels of observer bias, and impact of observer on primary data,
in a way that presence of observer may influence the behaviour of sample group
elements.

It is important to note that observation data collection method may be

associated with certain ethical issues. Fully informed consent of research
participant(s) is one of the basic ethical considerations to be adhered to by
researchers. At the same time, the behaviour of sample group members may change
with negative implications on the level of research validity if they are notified about
the presence of the observer.

9
 3.3 Requirement Analysis and Specification methods

Requirements analysis encompasses those tasks that go into determining the

needs or conditions to meet for anew or altered product or project, taking account of
the possibly conflicting requirements of the various stakeholders, analysing,
documenting, validating and managing software or system requirements.
Requirements analysis is critical to the success or failure of a systems or software
project. The requirements should be documented, actionable, measurable, testable,
traceable, related to identified business needs or opportunities, and defined to a level
of detail sufficient for system design.

3.3.1 Requirements Specifications

The requirement specifications from first phase are studied in this phase and
the system design is prepared. This system design helps in specifying hardware and
system requirements and helps in defining the overall system architecture. After
analysing the data collected, we formulated a number of requirements namely user
requirement, system hardware software attribute. These were grouped as user,
functional, non-functional and systems requirements

3.3.2 User Requirement

Requirements analysis involves frequent communication with system users to

determine specific feature expectations, resolution of conflict or ambiguity in
requirements. Energy should be directed towards ensuring that the final system or
product conforms to client needs rather than attempting to meld user expectations to
fit the requirements. Requirements analysis is a team effort that demands a
combination of hardware, software and human factors engineering expertise as well
as skills in dealing with people.

Structure System Analysis is a development method that allows the analyst to

understand the system and its activities in a logical way. It is a systematic approach,
which uses graphical tools that analyze and refine the objectives of an existing
system and develop a new system specification which can be easily understandable
by user. It has following attributes −It is graphic which specifies the presentation of
application. It divides the processes so that it gives a clear picture of system flow. It
is logical rather than physical i.e., the elements of system do not depend on vendor

10
or hardware. It is an approach that works from high-level overviews to lower-level
details. During Structured Analysis, various tools and techniques are used for system
development. They are –Flow chart, DFD, ERD

3.3.3 Functional Requirement

The following is the desired functionality of the new system. The system
should accept have submissions in form of raw library, staff, and book supply at the
submitting point. The system should perform analysis of HR management. The
system should authenticate the users of the system. The system should generation
of reports on request. The system should only allow the administrator to delete
records in the database.

3.3.4 Non-Functional Requirement

The system should must verify and validate all user input and users must be
notified in case of errors detected in the course of using the system. The system
should allow room for expansion. A system should have a high performance and
reliability level

3.4 System Design

The requirement specifications from first phase are studied in this phase and
the system design is prepared. The system design helps in specifying hardware and
system requirements and helps in defining the overall system architecture. The user
requirements document will typically describe the system’s functional, interface,
performance, data, security, etc. requirements as expected by the user. It is used by
business analysts to communicate their understanding of the system to the users.
The users carefully review this document as this document would serve as the
guideline for the system designers in the system design phase. The user acceptance
tests are designed in this phase. There are different methods for gathering
requirements of both soft and hard methodologies including; interviews,
questionnaires, document analysis, observation, throw-away prototypes, use cases
and static and dynamic views with users. The requirement documentation will be
referred throughout the rest of the system development process to ensure the
developing project along with the need and requirements. Systems design is the
phase where system engineers analyses and understand the business of the

11
proposed system by studying the user requirements document. They figure out
possibilities and techniques by which the user requirements can be implemented. If
any of the requirements are not feasible, the user is informed of the issue.

3.4.1 Logical design

Logical database design is the process of determining the logical data

structures needed to support school information resource. The logical design
process helps you to implement a database that satisfies the requirements of your
business organization.

3.4.2 Physical design

Logical database design is the process of determining the Physical data

structures needed to support school information resource. The Physical design
process helps you to implement a database that satisfies the requirements of your
business organization. The physical design is the process of transforming a circuit
description into the physical layout.

3.4.3 Architectural design

The requirement specifications from first phase are studied in this phase and
the system design is prepared. This system design helps in specifying hardware and
system requirements and helps in defining the overall system architecture.

3.4.4 Date Flow Diagram

Data Flow Diagrams It is a technique developed by Larry Constantine to

express the requirements of system in a graphical form. It shows the flow of data
between various functions of system and specifies how the current system is
implemented. is an initial stage of design phase that functionally divides the
requirement specifications down to the lowest level of detail. Its graphical nature
makes it a good communication tool between user and analyst or analyst and
system designer. It gives an overview of what data a system processes, what
transformations are performed, what data are stored, what results are produced and
where they flow.

12
3.4.5 Entity Relationship (E-R)

In the following diagram we have two entities Student and College and their
relationship. The relationship between Student and College is many to one as a
college can have many students however a student cannot study in multiple colleges
at the same time. Student entity has attributes such as Stu_Id, Stu_Name &
Stu_Addr and College entity has attributes such as Col_ID & Col_Name.

3.4.6 Use case Diagrams

Figure 2: flowchart diagram

3.5 System Implementation

System Implementation uses the structure created during architectural

design and the results of system analysis to construct system elements that meet
the stakeholder requirements and system requirements developed in the early life
cycle phases. These system elements are then integrated to form

13
intermediate aggregates and finally the complete system. See System Integration.
Implementation is the process that actually yields the lowest-level system elements
in the system hierarchy (system breakdown structure). System elements are made,
bought, or reused. Production involves the hardware fabrication processes of
forming, removing, joining, and finishing, the software realization processes of
coding and testing, or the operational procedures development processes for
operators' roles. If implementation involves a production process, a manufacturing
system which uses the established technical and management processes may be
required. The purpose of the implementation process is to design and create (or
fabricate) a system element conforming to that element’s design properties and/or
requirements. The element is constructed employing appropriate technologies and
industry practices. This process bridges the system definition processes and the
integration process. Figure 1 portrays how the outputs of system definition relate to
system implementation, which produces the implemented (system) elements
required to produce aggregates.

3.5.1 Front End

Introduction to the JAVA Programming Language: This book visual studio

Express is a fast and easy way to create programs for Microsoft Windows. Even if
you are new to Windows programming, with visual studio you have a complete set of
tools to simplify development. Visual studio Recipes: A Problem-Solution Approach
is written by Alexander Salas, Allen A, Kieran and Arturo This book is intended for
busy vb.net programmers who need practical solution while doing their job. This
book is published by A press. Vb.net 2012Recipes: A Problem-Solution Approach
teaches you new.vb.net technologies, windows presentation framework (WPF),
Language integrated query (LINQ), database access, XML manipulation, multimedia,
security and vb.net2010 network programming, etc. This book contains dozens of
code examples for solving common problems while doing vb.net projects.

3.5.2 Back end

SQL Server 2015 was released to manufacturing on March 18, 2014, and
released to the general public on April 1, 2015 and the build number was
12.0.2000.8 at release. Until November 2013 there were two CTP revisions, CTP1
and CTP2. SQL Server 2015 provides a new in-memory capability for tables that can

14
fit entirely in memory also known as Heaton. Whilst small tables may be entirely
resident in memory in all versions of SQL Server, they also may reside on disk, so
work is involved in reserving RAM, writing evicted pages to disk, loading new pages
from disk, locking the pages in RAM while they are being operated on, and many
other tasks. For disk-based SQL Server applications, it also provides the SSD Buffer
Pool Extension, which can improve performance by cache between and spinning
media. SQL Server 2014 also enhances the Always on (HADR) solution by
increasing the readable secondary’s count and sustaining read operations upon
secondary-primary disconnections, and it provides new hybrid disaster recovery and
backup solutions with Microsoft Azure, enabling customers to use existing skills with
the on-premises version of MYSQL Server to take advantage of Microsoft's global
datacenters. In addition, it takes advantage of new Windows Server 2012 and
Windows Server 2012 R2 capabilities for database application scalability in a
physical or virtual environment. Microsoft provides three versions of MYSQL Server
2014 for downloading: the one that runs on Microsoft Azure, the SQL Server 2014
CAB, and SQL Server 2014 ISO. SQL Server 2014 SP1, consisting primarily of bug
fixes, was released on May 15, 2015. SQL Server 2014 is the last version available
on x86/IA32 architecture. SQL Server is the best back end program because he is
good in database creating special in hospital and other database creating.

3.6 System Testing

System testing takes, as its input, all of the integrated components that have
passed integration testing. The purpose of integration testing is to detect any
inconsistencies between the units that are integrated together (called assemblages).
System testing seeks to detect defects both within the "inter-assemblages" and also
within the system as a whole. System testing is performed on the entire system in
the context of a Functional Requirement Specification(s) (FRS) and/or a System
Requirement Specification (SRS). System testing tests not only the design, but also
the behaviour and even the believed expectations of the customer. It is also intended
to test up to and beyond the bounds defined in the software/hardware requirements
specification. The common types of the system testing are Unit testing, Integration
testing, System testing, Sanity testing, Smoke testing, Interface testing, Regression
testing.

15
3.6.1 Unit Testing

Unit testing is the first level of testing and is often performed by the
developers themselves. It is the process of ensuring individual components of a
piece of software at the code level are functional and work as they were designed to.
Developers in a test-driven environment will typically write and run the tests prior to
the software or feature being passed over to the test team. Unit testing can be
conducted manually, but automating the process will speed up delivery cycles and
expand test coverage. Unit testing will also make debugging easier because finding
issues earlier means they take less time to fix than if they were discovered later in
the testing process.

3.6.2 Integration Testing

Is defined as a type of testing where software modules are integrated logically

and tested as a group. A typical software project consists of multiple software
modules, coded by different programmers. The purpose of this level of testing is to
expose defects in the interaction between these software modules when they are
integrated Integration Testing focuses on checking data communication amongst
these modules.

3.6.3 Acceptance Testing

Acceptance testing is associated with the business requirement analysis

phase and involves testing the product in user environment. Acceptance tests
uncover the compatibility issues with the other systems available in the user
environment. It also discovers the non-functional issues such as load and
performance defects in the actual user environment.

3.7 Development and maintenance

Development is, hypothetically, simply work done by developers. However,

more likely it is being used as shorthand for 'new development', which is the creation
of new features/functionality in the product. Maintenance is the process of providing
upkeep on an existing product.

16
 CHAPTER FOUR: IMPLEMENTATION
4.1 Omar binu khadab school management system Secondary School Project Chart

Principle /head

Vice Principle

Administration Staffs Exams Sallary

Subjects Finance
Students Teachers
Figure 3: Omor binu Khadab

4.1.1 Admin Requirements Specification

i) To make registration the admin

ii) To Mange Department
iii) To Add/delete and edit Department

4.1.2 Student Record Requirements Specification

i) To manage Student
ii) To view student record
iii) To Add/Update Student Record
iv) To Delete Student Record

17
4.1.3 Staff Requirements Specification

i) To manage Staff
ii) To make Record Staff
iii) To make Reports of all Staff
iv) To delete/Update Staff

4.1.4 Salary Requirements Specification

i) To Manage Salary
ii) To Update and Delete Salary
iii) To make report of all Salary
iv) To make Record Salary

4.1.5 Course Requirements Specification

i) To make register Course

ii) To manage all Course
iii) To Add/Edit/Delete Course
iv) To Update Course

4.1.6 Exam Requirements Specification

i) To make register all Exam

ii) To manage all Exam
iii) To Add/Edit/Delete Exams
iv) To Update Exam

4.1.7 Fee Record Requirements Specification

I) To view Fee record

ii) To Add/Update Fee Record
iii) To Delete teacher Record
iv) To manage fee Students

4.1.8 Parent Record Requirements Specification

II) To manage Parent record

v) To Add/Update Parent Record

18
 vi) To Delete Parent Record
vii) To view parent record

4.2 Requirement Analysis and Design

4.2.1 Student Requirement Analysis and Design

4.2.1.1Form Students Logical Design

STEP 1 START
STEP 2 Enter Student ID
Enter Student name
Enter Gender
Enter Phone
Enter Address
Enter Class
Enter Subject ID
STEP 3 IF VALID GO TO STEP 4
ELSE
GO TO STEP 2
STEP 4 CONFIRM / CANCEL
STEP 5 STOP
4.2.1.2 Detailed Logical Design

Start

Students Details

N Valid Y

Confirm
Stop

19
 4.2.1.3 Students Field Analysis

Table 1: Students Field Analysis

Fields Student ID Student Gender Phone Address Class
Analysis Name

Data Type Integer Varchar Varchar Integer Varchar Varchar

Size 20 50 15 20 50 50
Required Not null Not null Not null Not null Not null Not null
Auto field Yes No No No No No
Key PK
description

4.2.1.4 User Interface Design

FORM students

Student
SAVE ID Search
Student
UPDAT Name
Gender
EXIT
DELETE
BACK
RESET
phone
Address
Class

Figure 4: department form students User Interface Design

4.2.1.5 UI Analysis

Table 2: Students UI Analysis

Control Property Value

20
 Form2 Name frm Form Students
Caption Students
Label1 Name lbl student ID
Caption student ID
Label2 Name Label2
Caption Student name
Label3 Name Label3
Caption Gender
Label4 Name Label4
Caption Phone
Label5 Name Label5
Caption Title
Label6 Name Label6
Caption Address
Button1 Name btnSave
Caption Save
Button2 Name btnUpdate
Caption Update
Button3 Name btnReset
Caption Reset
Button4 Name btnClose
Caption Close
Button5 Name btnDelete
Caption Delete
Label7 Name Label7
Caption Search
List view Name lst Form Students
Caption
Texbox1 Name txt Student ID
Texbox2 Name txt Student name
Combobox1 Name cmpGender
Texbox3 Name txtPhone
Texbox4 Name txt Address
Texbox5 Name txt Class

4.2.2 Teacher Requirement Analysis and Design

4.2.2.1 Teacher Process Analysis

STEP 1 START
STEP 2 Enter Teacher_ID

21
 Enter Teacher_Name
Enter Gender
Enter Nationality
Enter Passport
Enter E_mail
Enter Tell_Phone
Enter Subject ID
STEP 3 IF VALID GO TO STEP 4
ELSE
GO TO STEP 2
STEP 4 CONFIRM / CANCEL
STEP 5 STOP

4.2.2.2 Detailed Logical Design

Start

Teacher Details

N Y
Valid

Stop Confirm

4.2.2.3 Teacher Field Analysis

Table 3: Teacher Field Analysis

22
 Fields Teacher_I Teacher_Nam Gende Nationalit Passpor E_mail Tell_Phon
Analysis D e r y t e
Data Type Integer Varchar Varcha Varchar Integer Varcha Integer
r r
Size 20 50 15 20 20 20 20
Required Not null Not null Not null Not null Not null Not null Not null
Auto field Yes No No No No No No
Key PK
descriptio
n

4.2.2.4 Form Design

FORM teacher

Search
Teacher_ID
Teacher_Name Update
Gender Save
Nationality
Passport
E_mail
Tell_Phone Delete

Reset
Exist

Back

Figure 5: department form teacher User Interface Design

4.2.2.5 UI Analysis

Table 4: UI Analysis
Control Property Value
Form2 Name frm Teacher
Caption Teachers
Label1 Name lbl Teacher_ ID
Caption Teacher_ ID

23
Label2 Name Label2
Caption Teacher_Name
Label3 Name Label3
Caption P Teacher_Name

Label4 Name Label4

Caption Gender
Label5 Name Label5
Caption Title
Label6 Name Label6
Caption Nationality
Label7 Name Label4
Caption Passport
Label8 Name Label5
Caption Title
Label9 Name Label6
Caption E_mail
Labe20 Name Label6
Caption Tell_Phone
Button1 Name btnSave
Caption Save
Button2 Name btnUpdate
Caption Update
Button3 Name btnReset
Caption Reset
Button4 Name btnClose
Caption Close
Button5 Name btnDelete
Caption Delete
Label7 Name Label7
Caption Search
List view Name lst Teacher
Caption
Texbox1 Name txt Teacher_ID
Texbox2 Name txt Teacher
Combobox1 Name Txt Teacher_Name
Texbox3 Name Txt Gender
Texbox4 Name txt Nationality
Texbox5 Name Txt Teacher_Name
Texbox6 Name Txt Passport

24
 4.2.3 Fee Requirement Analysis and Design

4.2.3.1 Fee Process Analysis

STEP 1 START
STEP 2 Enter StudentsID
Enter StudentsName
Enter Class
Enter Gender
Enter Mothed
Enter Balance
Enter Amount
Enter Subject ID
STEP 3 IF VALID GO TO STEP 4
ELSE
GO TO STEP 2
STEP 4 CONFIRM / CANCEL
STEP 5 STOP

4.2.3.2 Detailed Logical Design

Start

FEE Details

N Y
Valid

Stop Confirm
25
 4.2.3.3 FEE Field Analysis

Table 5: FEE Field Analysis

Fields StudentsID StudentsName Class Gender Mothed Balance
Analysis

Data Type Integer Varchar Varcha Varchar Varchar Integer

r
Size 20 50 15 20 20 20
Required Not null Not null Not null Not null Not null Not null
Auto field Yes No No No No No
Key PK
descriptio
n

4.2.3.4 Form Design

FORM fee

26
StudentsID Search
StudentsName
Class
Gender
Mothed
Balance
Amount

Figure 6: department form fee User Interface Design

4.2.3.5 UI Analysis

Table 6: FEE UI Analysis

Control Property Value
Form2 Name frm Fee
Caption fee
Label1 Name lbl StudentsID
Caption StudentsID
Label2 Name Save Label2
Caption Update StudentsName
Label3 Name Label3
Caption Delete P StudentsName
Reset
Label4 Name Exist Label4
Caption Class
Back
Label5 Name Label5
Caption Title
Label6 Name Label6
Caption Mothed
Label7 Name Label4
Caption Mothed
Label8 Name Label5

27
 Caption Title
Label9 Name Label6
Caption Balance
Labe20 Name Label6
Caption Amount
Button1 Name btnSave
caption Save
Button2 Name btnUpdate
caption Update
Button3 Name btnReset
caption Reset
Button4 Name btnClose
Caption Close
Button5 Name btnDelete
Caption Delete
Label7 Name Label7
Caption Search
List view Name lst Fee
caption
Texbox1 Name jStudentsID
Texbox2 Name txt Fee
Combobox1 Name jStudentName
zTexbox3 Name jClass
Texbox4 Name jGender
Texbox5 Name jStudentsName
Texbox6 Name jClass

4.2.4 Parents Requirement Analysis and Design

4.2.4.1 Parents Process Analysis

STEP 1 START
STEP 2 Enter Student ID
Enter Parents
Enter Phone
Enter Address

Enter Subject ID
28
STEP 3 IF VALID GO TO STEP 4
ELSE
GO TO STEP 2
STEP 4 CONFIRM / CANCEL
STEP 5 STOP

4.2.4.2 Detailed Logical Design

Start

Parents Details

N Y
Valid

Stop Confirm

4.2.4.3 Parents Field Analysis

Table 7: Parents Field Analysis

Fields
Analysis Student ID Parents Phone Address
Data Type Integer Varchar Integer Varchar
Size 20 50 15 20
Required Not null Not null Not null Not null
Auto field Yes No No No
Key PK
description

29
 4.2.4.4 Form Design

FORM parent

Search
Student ID Save
Parents Update
Phone
Address
Delete

Reset
Back
Exist

Figure 7: department form parents User Interface Design

4.2.4.5 UI Analysis

Table 8: Parents UI Analysis

Control Property Value
Form2 Name frm Parents
Caption Parents
Label1 Name lbl Student ID
Caption Student ID
Label2 Name Label2
Caption Phone
Label3 Name Label3
Caption Phone

Label4 Name Label4

30
 Caption Phone
Label5 Name Label5
Caption Title
Label6 Name Label6
Caption Address
Button1 Name btnSave
caption Save
Button2 Name btnUpdate
caption Update
Button3 Name btnReset
caption Reset
Button4 Name btnClose
Caption Close
Button5 Name btnDelete
Caption Delete
Label7 Name Label7
Caption Search
List view Name lst Parents
caption
Texbox1 Name txt Student ID
Texbox2 Name txt Parents
Combobox1 Name Txt Phone
Texbox3 Name Txt Address

4.2.5 Staffs Requirement Analysis and Design

4.2.5.1 Staffs Process Analysis

STEP 1 START
STEP 2 Enter Staff ID
Enter Staff Name

31
 Enter Gender
Enter Phone
Enter Experience
Enter Subject ID
STEP 3 IF VALID GO TO STEP 4
ELSE
GO TO STEP 2
STEP 4 CONFIRM / CANCEL
STEP 5 STOP
4.2.5.2 Detailed Logical Design

Start

Staff Details

N Y
Valid

Stop Confirm

4.2.5.3 Staffs Field Analysis

Table 9: Staffs Field Analysis

Fields Staff
Analysis Staff ID Name Gender Phone Experience
Data Type Integer Varchar Varchar Integer Varchar
Size 20 50 15 20 50
Required Not null Not null Not null Not null Not null
Auto field Yes No No No No
Key PK
description

4.2.5.4 Form Design

32
 FORM staff

Staff ID SAVE Search

Staff Name UPDAT
Gender
DELETE
Phone
Experience RESET
BACK

EXIT

Figure 8: department form staff User Interface Design

4.2.5.5 UI Analysis

Table 10: staffs UI Analysis

Control Property Value
Form2 Name frm Staffs
Caption Staff
Label1 Name lbl Staff ID
Caption Staff ID
Label2 Name Label2
Caption Staff Name
Label3 Name Label3
Caption Gender
Label4 Name Label4
Caption Phone
Label5 Name Label5
Caption Title
Label6 Name Label6
Caption Experience
Button1 Name btnSave
caption Save
Button2 Name btnUpdate
caption Update

33
Button3 Name btnReset
caption Reset
Button4 Name btnClose
Caption Close
Button5 Name btnDelete
Caption Delete
Label7 Name Label7
Caption Search
List view Name lst Staff
caption
Texbox1 Name txt Staff ID
Texbox2 Name txt Staff Name
Combobox1 Name cmpGender
Texbox3 Name txtPhone
Texbox4 Name txt Experience

4.2.6 Form Course Requirement Analysis and Design

4.2.6.1 Form Course Process Analysis

STEP 1 START
STEP 2 Enter CourseID
Enter CourseName
Enter CreditHour
Enter TeacherName
Enter Subject ID
STEP 3 IF VALID GO TO STEP 4
ELSE
GO TO STEP 2
STEP 4 CONFIRM / CANCEL
STEP 5 STOP
4.2.6.2 Detailed Logical Design

Start

Course Details

34
Valid
 N Y

Stop
Confirm

4.2.6.3 Course Form Field Analysis

Table 11: Course Form Field Analysis

Fields Course ID CourseName Credit Hour Teacher Name
Analysis

Data Type Integer Varchar Varchar Varchar

Size 20 50 15 20
Required Not null Not null Not null Not null
Auto field Yes No No No
Key PK
description

4.2.6.4 Form Design

FORM COURSE

Course ID Search
CourseName SAVE
Credit Hour UPDAT
DELETE
Teacher Name
RESET
EXIT
BACK

35
Figure 9: department form Course User Interface Design

4.2.6.5 UI Analysis

Table 12: Course UI Analysis

Control Property Value
Form2 Name frm FORM COURSE
Caption COURSE
Label1 Name lbl Course ID
Caption Course ID
Label2 Name Label2
Caption Course Name
Label3 Name Label3
Caption Credit Hour
Label4 Name Label4
Caption Teacher Name
Label5 Name Label5
Caption Title
Label6 Name Label6
Button1 Name btnSave
Button1 caption Save
Button2 Name btnUpdate
Button2 caption Update
Button3 Name btnReset
Button3 caption Reset
Button4 Name btnClose
Button4 Caption Close
Button5 Name btnDelete
Button5 Caption Delete
Label7 Name Label7
Label7 Caption Search
List view Name lst FORM COURSE
List view caption
Texbox1 Name txt Course ID
Texbox2 Name cmp Course Name
Combobox1 Name cmp Credit Hour
Texbox3 Name cmp Teacher Name

36
 4.2.7 Sallary Requirement Analysis and Design

4.2.7.1 Sallary Process Analysis

STEP 1 START
STEP 2 Enter SallaryID
Enter Sallary Name
Enter SallaryJob
Enter Typeofmoney
Enter Month
Enter Subject ID
STEP 3 IF VALID GO TO STEP 4
ELSE
GO TO STEP 2
STEP 4 CONFIRM / CANCEL
STEP 5 STOP

4.2.7.2 Detailed Logical Design

Start

Sallary Details

N Y
Valid

Stop
Confirm

4.2.7.3 Sallary Field Analysis

Table 13: Sallary Field Analysis

Fields
SallaryID SallaryName SallaryJob Typeofmoney Month

37
Analysis
Data Type Integer Varchar Varchar varchar Varchar

Size 20 50 15 20 50
Required Not null Not null Not null Not null Not null

Auto field YES No No No No

START 1000

Key PK
description

4.2.7.4 Form Design

SALARY FORM

38
 Search
SallaryID
SallaryName Save
SallaryJob Update
Typeofmoney
Delete
Month
Reset
Exist

Back

Figure 10: department form Sallary User Interface Design

4.2.7.5 UI Analysis

Table 14: Sallary UI Analysis

Control Property Value
Form2 Name frm Sallary
Caption Sallary
Label1 Name lbl Sallary ID
Caption Sallary ID
Label2 Name Label2
Caption Sallary Name
Label3 Name Label3
Caption SallaryJob

Label4 Name Label4

Caption Phone
Label5 Name Label5
Caption Title
Label6 Name Label6
Caption Address
Button1 Name btnSave
caption Save
Button2 Name btnUpdate
caption Update
Button3 Name btnReset

39
 caption Reset
Button4 Name btnClose
Caption Close
Button5 Name btnDelete
Caption Delete
Label7 Name Label7
Caption Search
List view Name lst Sallary
caption
Texbox1 Name txt Sallary ID
Texbox2 Name txt Sallary Name
Combobox1 Name cmp SallaryJob
Texbox3 Name cmdTypeofmoney
Texbox4 Name cmdMonth

4.2.8 Exam Requirement Analysis and Design

4.2.8.1 Exam Process Analysis

STEP 1 START
STEP 2 Enter Student_ID Enter Biology
Enter Student_Name Enter Arabic
Enter Class Enter Islamic
Enter Maths Enter History
Enter English Enter Geography
Enter Total Score Enter Physics
Enter Average Enter Somali
Enter Ranging Enter Chemistry
Enter Subject ID
STEP 3 IF VALID GO TO STEP 4

40
 ELSE
GO TO STEP 2
STEP 4 CONFIRM / CANCEL
STEP 5 STOP
4.2.8.2 Detailed Logical Design
Start

Exam Details

N Y
Valid

Stop Confirm

4.2.8.3 Exam Field Analysis

Table 15: Exam Field Analysis

Fields Stud Stude Clas Mat English Biol Arabic Islami Histo Geogr Physi Somal
ent_I nt_ s hs ogy c ry aphy cs i
D
Analysis Name

Data Integ Varch Varc Var Integer Inte Intege Intege Integ Integer Intege Intege
Type er ar har cha ger r r er r r
r

Size 20 50 15 20 20 20 20 20 50 15 20 20

Required Not Not Not Not Not null Not Not Not Not Not Not Not
null null null null null null null null null null null

Auto field Yes No No No No No No No No No No

Key PK

descripti
on

41
 4.2.8.4 Form Design
EXAM FORM

Search
Student_ID Biology
Student_Name Arabic Save
Class Islamic
Maths History Update
English Geography
Total Score Physics
Average Somali Delete
Ranging Chemistry
Reset

Exit

Back

42
Figure 11: department form Exams User Interface Design

4.2.8.5 UI Analysis

Table 16: Exam UI Analysis

Control Property Value
Form2 Name frm Exam
Caption Exam
Label1 Name lbl Students_ID
Caption Students_ID
Label2 Name Label2
Caption Student_Name
Label3 Name Label3
Caption P Students _Name

Label4 Name Label4

Caption Class
Label5 Name Label5
Caption Title
Label6 Name Label6
Caption Maths
Label7 Name Label4
Caption English
Label8 Name Label5
Caption Title
Label9 Name Label6
Caption Total Score
Labe20 Name Label7
Labe21 Caption Average
Name Label8
Labe22 Caption Ranging
Labe22 Name Label9
Labe23 Name Label10
Caption Biology
Button1 Name btnSave
caption Save
Button2 Name btnUpdate
caption Update
Button3 Name btnReset
caption Reset
Button4 Name btnClose

43
 Caption Close
Button5 Name btnDelete
Caption Delete
Label7 Name Label7
Caption Search
List view Name lst Exam
caption
Texbox1 Name txtStudent_ID
Texbox2 Name txtStudent_Name
Combobox1 Name txtStudent_Name
Texbox3 Name cmdClass
Texbox4 Name txtMaths
Texbox5 Name txtEnglish
Texbox6 Name txtTotalScore
Texbox7 Name txtAverage
Texbox8 Name txtRanging
Texbox9 Name txtBiology
Texbox10 Name txtArabic
Texbox11 Name txtIslamic
Texbox12 Name txtHistory
Texbox13 Name txtGeography
Texbox14 Name txtPhysucs
Texbox15 Name txtSomali
Texbox16 Name txtChemsitry

44
 References

Sergio. (2006, Oct monday). Information System Engineering. Chicago

Silva. (2004). Accounting Information System. Bohalabur.

Donald. (2006). Information Technology. Britain: Vale.

45