Indonesian
J
our
nal
of
Electrical
Engineering
and
Computer
Science
V
ol.
40,
No.
2,
No
v
ember
2025,
pp.
1059
∼
1073
ISSN:
2502-4752,
DOI:
10.11591/ijeecs.v40.i2.pp1059-1073
❒
1059
De
v
elopment
and
e
v
aluation
of
a
generalized
ontology
framew
ork
f
or
softwar
e
r
equir
ement
specication
Soura
v
K
undu
1
,
Soumay
Kanti
Das
1
,
Ab
u
Rafe
Md
J
amil
1
,
Md
Kamrul
Islam
1
,
SK.
Shalauddin
Kabir
1
,
Mostajur
Rahman
Akhond
1,2
1
Department
of
Computer
Science
and
Engineering,
Jashore
Uni
v
ersity
of
Science
and
T
echnology
,
Khulna,
Bangladesh
2
Department
of
Electrical
Engineering
and
Computer
Science,
Y
ork
Uni
v
ersity
,
Ontario,
Canada
Article
Inf
o
Article
history:
Recei
v
ed
No
v
21,
2024
Re
vised
Aug
3,
2025
Accepted
Oct
15,
2025
K
eyw
ords:
Kno
wledge
base
Ontology
Prote
ge
Softw
are
requirement
specication
SP
ARQL
ABSTRA
CT
This
paper
presents
an
ontology
de
v
eloped
to
address
challenges
such
as
com-
munication
g
aps,
risks
of
e
rrors,
and
inconsistencies
during
the
m
anual
process
of
creating
softw
are
requirement
specications
(SRS).
The
proposed
ontology
of
fers
a
systematic
and
formal
depict
ion
of
the
requirements,
enhancing
consis-
tenc
y
and
communication
among
stak
eholders.
The
ontology
has
been
de
v
el-
oped
from
the
softw
are
requirements
documents
to
f
acilitate
the
de
v
elopment
process.
This
paper
discusses
the
process
of
creating
the
ontology
and
demon-
strates
using
Pellet
Reasoner
for
inference
and
Prot
´
eg
´
e
for
ontology
construction
to
sa
v
e
and
reuse
information.
The
ontology
seems
to
be
ef
cient
in
manag-
ing
comple
x
soft
w
are
projects,
enabling
accurate
requirement
retrie
v
al
through
SP
ARQL
queries.
This
study
emphasi
zes
ho
w
incorporating
ontologies
into
re-
quirement
engineering
can
signicantly
enhance
the
quality
and
reliability
of
SRS.
This
is
an
open
access
article
under
the
CC
BY
-SA
license
.
Corresponding
A
uthor:
Mostajur
Rahman
Akhond
Department
of
Computer
Science
and
Engineering,
Jashore
Uni
v
ersity
of
Science
and
T
echnology
Jashore,
Khulna,
Bangladesh
Email:
mr
.akhond@just.edu.bd
1.
INTR
ODUCTION
In
recent
years,
semantic
technologies
ha
v
e
adv
anced
rapidly
.
The
adoption
of
semantic
data
model
s
lik
e
ontologies
and
kno
wledge
graphs
has
increased
substantially
.
Ontologies
are
considered
as
the
foundation
of
the
semantic
web
[1].
An
ontology
is
a
formal
and
e
xplicit
description
of
concepts
within
a
specic
area
of
discourse
(classes/concepts),
attrib
utes
of
each
concept
that
characterize
distinct
qualities
(slots/roles/properties),
and
constraints
on
these
attrib
utes
(f
acets/role
limitations)
[2].
A
kno
wledge
base
consists
of
an
ontology
and
a
collection
of
disti
nct
instances
of
classes.
As
the
pro
v
erb
goes,
a
kno
wledge
base
b
e
gins
where
the
ontol-
ogy
ends
[2].
Requirement
engineering
(RE)
describes
the
process
of
g
athering,
analyzing,
and
v
alidating
the
features
and
constraints
of
a
softw
are
system.
The
nal
output
of
the
RE
is
a
written
document
kno
wn
as
the
softw
are
require
ment
specication
(SRS)
[3].
The
softw
are
de
v
elopment
team,
including
softw
are
engineers,
will
follo
w
the
SRS
document
when
de
v
eloping
the
intended
softw
are.
One
of
the
challenges
in
softw
are
en-
gineering
is
de
v
eloping
and
managing
t
he
SRS
report.
The
reports
must
be
cl
ear
to
reect
the
specications
[4].
Ho
we
v
er
,
manually
de
v
eloping
requirements
specications
can
l
ead
to
inconsistencies,
ambiguity
,
and
errors
[5].
Lack
of
domain
kno
wledge
among
non-technical
customers
complicates
accurately
communicating
the
requirements
with
e
xperienced
analysts.
F
ailing
to
identify
and
address
the
ambiguities
on
time
can
ha
v
e
se
v
ere
consequences
[6].
T
o
o
v
ercome
the
kno
wledge
g
ap
and
the
ambiguity
of
the
SRS
document,
we
ha
v
e
J
ournal
homepage:
http://ijeecs.iaescor
e
.com
Evaluation Warning : The document was created with Spire.PDF for Python.
1060
❒
ISSN:
2502-4752
proposed
this
w
ork
representing
a
generalized
kno
wledge
database
frame
w
ork.
One
w
ay
to
describe
it
is
as
a
machine-processable
“W
eb
of
Data”
[7].
W
e
ha
v
e
used
the
core
concept
of
kno
wledge
databases
kno
wn
as
ontology’
[8].
Se
v
eral
studies
use
ontologies
in
man
y
aspects
of
requirements
engineering
issues,
such
as
the
elicitation
process,
handling
inconsistencies,
dealing
with
incomplete
requirements,
reducing
ambiguities,
and
reusing
requirements
[9]
b
ut
most
of
the
ontologies
are
‘domain-specic’
ontologies.
Se
v
eral
ontologies
ha
v
e
been
de
v
eloped
for
this
because
t
here
is
no
accurate
methodology
for
constructing
an
ontology
.
De
v
eloping
an
ontology
for
the
SRS
report
can
f
acilitate
softw
are
de
v
elopers
,
testers,
and
other
stak
eholders.
This
paper
proposed
a
generalized
frame
w
ork
that
enables
the
sharing
and
reusing
of
kno
wledge
from
the
e
xisting
SRS
reports
and
is
also
usable
for
dif
ferent
types
of
domains.
In
this
thesis,
we
construct
an
ontology
that
enables
the
sharing
and
storing
the
kno
wledge
related
to
the
SRS
for
all
types
of
softw
are.
W
e
follo
w
the
IEEE
830-1998
format
of
SRS
and
the
softw
are
engineering
body
of
kno
wledge
(SWEBOK)
pro
vided
by
IEEE.
The
proposed
frame
w
ork
can
guide
the
users
to
follo
w
the
standard
IEEE
format
of
the
SRS
while
de
v
eloping
their
SRS
report,
and
it
can
help
in
sharing
the
data
of
the
SRS
with
the
community
to
reuse
in
the
future
and
reduce
the
communication
g
ap.
T
able
1
summarizes
the
comparison
of
signicant
related
w
orks.
T
able
1.
Comparison
of
pre
vious
ontologies
and
the
proposed
one
Reference
Domain-specic
Reduces-ambiguity
Generalized
Ev
aluation
method
Haridy
et
al.
[10]
Y
es
Y
es
No
Manual
and
application
Bencharqui
et
al.
[5]
Y
es
P
artial
No
Manual
Ahmed
et
al.
[6]
Y
es
Y
es
No
Application
Ahmed
and
Ahmed
[11]
Y
es
Y
es
No
Expert
and
application
T
an
et
al.
[12]
Y
es
P
artial
No
Expert
and
application
Proposed
ontology
No
Y
es
Y
es
Manual,
e
xpert,
and
application
Creating
a
document
that
can
be
methodically
re
vie
wed,
assessed,
and
appro
v
ed
is
what
is
usually
meant
by
“softw
are
requirements
specication”
in
softw
are
engineering.
The
signicant
contrib
utions
of
the
w
ork
are
listed
as:
−
Designing
an
ontology
that
can
standardly
represent
the
SRS
document
using
the
IEEE
830-1998
format.
−
De
v
eloping
the
ontology
to
represent
the
kno
wledge
of
the
SRS
in
a
generalized
w
ay
and
reducing
the
g
ap
of
kno
wledge
sharing
among
the
stak
eholders.
−
De
v
eloping
the
frame
w
ork
that
can
change
the
unstructured
requirements
to
a
structured
class-based
model
so
that
the
ambiguities
of
the
specications
can
be
identied
clearly
.
Our
methods
include
the
follo
wing:
−
An
ontology
that
we
ha
v
e
constructed
enables
formal
denitions
of
concepts
and
connections
within
the
system.
−
W
e
ha
v
e
follo
wed
the
standard
format
of
the
SRS
document
according
to
IEEE
830-1998
format
[13].
−
W
e
ha
v
e
then
populated
the
SRS
document
for
tw
o
real-time
systems.
−
Then,
we
ha
v
e
tested
the
results
using
Reasoner
and
SP
ARQL
queries.
The
rest
of
the
paper
is
structured
as
follo
ws:
section
2
pro
vides
the
earlier
w
ork
in
order
to
obtain
a
summary
of
pre
viously
proposed
w
ork
and
to
determine
ho
w
to
come
up
with
ne
w
solutions.
Section
3
describes
our
model’
s
design
and
the
recommended
methods
we
ha
v
e
used
thus
f
ar
.
Section
4
outlines
the
requirements
and
procedures
for
e
v
aluation
and
section
5
pro
vides
an
o
v
ervie
w
of
the
potential
for
future
research
as
well
as
the
conclusion
section,
which
pro
vides
an
outline
of
our
thesis.
2.
LITERA
TURE
REVIEW
Softw
are
engineering
is
the
application
of
fundamental
engineering
principles
to
de
v
elop
cost
ef
fec-
ti
v
e
and
reliabl
e
softw
are
that
functions
ef
ciently
on
actual
de
vices
[14].
Sommerville
added
that
softw
are
engineering
is
an
engineering
w
ork
in
v
olv
ed
with
all
aspects
of
softw
are
de
v
elopment,
from
the
early
stages
of
system
specication
to
system
maintenance
after
the
release
for
use
[15].
Requirement
specication
is
a
crucial
phase
of
RE
where
functional
requirements
and
non-functional
requirements
are
detected,
which
af-
fects
the
de
v
elopment
of
softw
are.
Generally
,
S
oftw
are
requirements
depend
on
the
stak
eholders;
in
softw
are
de
v
elopment,
the
requirements
are
di
vided
into
tw
o
main
parts:
i)
functional
requirement
and
ii)
non-functional
Indonesian
J
Elec
Eng
&
Comp
Sci,
V
ol.
40,
No.
2,
No
v
ember
2025:
1059–1073
Evaluation Warning : The document was created with Spire.PDF for Python.
Indonesian
J
Elec
Eng
&
Comp
Sci
ISSN:
2502-4752
❒
1061
requirement
[16].
Requirement
engineering
is
crucial
to
all
softw
are
de
v
elopment
life
c
ycles
(SDLC),
b
ut
be-
cause
de
v
elopment
processes
dif
fer
,
it
is
frequently
ne
glected
or
underv
alued
[11].
A
frequently
used
reference
guide
for
the
SRS
report
writing
is
IEEE
Std.
830-1998
[13].
I
n
recent
yea
rs
ontologies
are
being
used
suc-
cessfully
in
the
RE
phase.
Ontologies
may
reduce
the
ambiguity
,
inconsistenc
y
,
and
incompleteness
of
those
requirements.
An
ontology
refers
to
a
structured
and
precise
representation
of
concepts,
slots
and
f
acets
within
a
specic
do
main
of
discussion
[2].
An
ontology
frame
w
ork
is
presented
in
the
study
by
W
ongthongtham
et
al.
[15]
to
resolv
e
communica-
tion
issues
in
multi-site
softw
are
de
v
elopment.
The
y
emphasize
ho
w
important
it
is
for
managers,
stak
eholders,
and
de
v
elopers
to
communicate
ef
fecti
v
ely
to
reduce
errors
in
softw
are
products,
especially
when
the
require-
ment
engineering
phase
is
underw
ay
.
Through
the
use
of
diagrams,
the
suggested
frame
w
ork
f
acilitates
the
sharing
of
domain
and
instance
kno
wledge
by
utilizing
ontology
as
a
communication
tool.
The
writers
hope
to
reduce
language
barriers
in
the
sector
by
of
fering
an
editable
o
wchart
diagram
and
a
case-b
uilding
frame
w
ork.
T
o
impro
v
e
softw
are
projects
and
address
common
issues
lik
e
ambiguous
and
insuf
cient
require-
ments
Y
ue
[17]
suggest
a
tw
o-step
procedure
for
consistenc
y
checking
in
ontology-based
requirements
elicita-
tion
methodologies.
This
approach
combines
rule-dri
v
en
completeness
tests
with
ontology
consistenc
y
checks.
In
2021,
Khair
and
Meziane
[18]
published
a
re
vie
w
study
on
the
application
of
ontologies
to
the
elicitation
of
softw
are
requirements.
The
study
is
considered
one
of
the
best
in
this
eld.
According
to
the
analysis,
83.6%
of
the
research
supported
specications.
According
to
the
surv
e
y
,
52.24%
of
respondents
support
functional
re-
quirements,
2.99%
support
non-functional
requirements,
and
44.78%
support
both
when
it
comes
to
the
usage
of
ontologies
to
e
xpress
requirements.
F
or
writing
softw
are
requirements
specications
that
use
requirements
engineering
data
elements
sug-
gested
by
the
SWEBOK,
Elliott
and
Allen
[19]
de
v
eloped
an
approach
with
automated
support.
It
consists
of
se
v
en
use
cases,
an
ontological
frame
w
ork,
and
three
empirical
retrospecti
v
e
case
studies
that
demonstrate
the
utilization
of
the
methodology
.
The
case
studies
also
demonstrated
the
ease
with
which
the
ontology
may
be
useable
for
other
application
domains.
The
y
conclude
that
ontological
support
can
enhance
procedures
that
lead
to
the
specication
of
softw
are
requirements
and
the
subsequent
creation
of
ontologies.
An
approach
for
e
v
aluating
ho
w
well
an
e
xisting
ontology
meets
the
needs
of
kno
wledge
stak
ehold-
ers
in
requirement
elicitation
w
as
created
by
Ermolaye
v
[20].
The
comprehensi
v
eness
and
precision
of
the
interpretation
are
guaranteed
by
this
methodology
,
and
the
e
v
aluation
of
these
requirements
for
ontology
is
crucial
for
ontology
engineering.
The
basis
of
the
strate
gy
emplo
yed
in
the
published
research
is
the
ontology
renement
methodology
and
the
OntoElect
ontology
process,
which
consists
of
three
stages:
feature
e
xtraction,
requirements
conceptualization,
and
ontology
e
v
aluation.
In
a
research
study
on
the
automatic
identication
and
updating
of
softw
are
requirement
specicat
ions
using
ontology-dri
v
en
softw
are
de
v
elopment,
Bhatia
et
al.
[21]
described
ho
w
the
ontology
will
automatically
nd
the
requirements
that
ha
v
e
been
added,
remo
v
ed,
or
changed
to
the
curr
ent
softw
are
requirements
speci-
cation
on
a
particular
case
study
.
F
or
e
v
aluating
the
ontology
,
the
y
used
the
Result
management
system
of
a
specic
uni
v
ersity
.
Jones
et
al.
[22]
descri
be
that
there
are
four
important
methodologies
for
ontological
engineering
named:
T
O
VE
(T
oronto
virtual
enterprise),
enterprise
model
approach,
METHONT
OLOGY
,
KBSI
IDEF5.
Jones
et
al.
[22]
introduced
some
other
non-comprehensi
v
e
methodologies,
named:
Ontolingua,
CommonKADS
and
KA
CTUS,
PLINIUS,
ONIONS,
Mikrok
osmos,
MENELAS,
PHYSSYS,
and
SENSUS.
Raad
and
Cruz
[23]
carried
out
a
surv
e
y
on
ontology
assessment
techniques.
This
paper
pres
ents
the
current
ontology
e
v
aluation
techniques
and
discusses
their
benets
and
limitations
in
order
to
address
the
problem
of
nding
an
ef
fecti
v
e
ontology
e
v
aluation
method.
The
methods
for
e
v
aluating
ontologies
that
are
of
fered
can
be
di
vided
into
four
groups:
approaches
based
on
criteria,
tasks,
corpuses,
and
gold
standards.
Bhatia
et
al.
[7]
conducted
a
study
on
ontologies
for
softw
are
engineering:
past,
present,
and
future.
The
s
tudy
talks
about
dif
ferent
kinds
of
ontologies
which
are
used
in
a
softw
are
life-c
ycle.
The
study
cate
go-
rized
the
ontologies
ag
ainst
each
step
of
the
softw
are
life-c
ycle.
Moreo
v
er
,
it
sho
ws
the
application
scope
of
the
ontologies
as
well
as
it
sho
ws
the
application
scope
of
ontologies
in
t
h
e
softw
are
engineering
area.
The
study
sho
ws
in
which
softw
are
de
v
elopment
phase
which
ontology
ha
v
e
been
used
as
well
as
in
future
in
which
phases
will
be
able
to
use
ontology
in
softw
are
engineering.
Bencharqui
et
al.
[5]
created
an
ont
ology-based
procedure
for
requirement
specication,
in
which
system
domain
kno
wledge
is
described
using
a
requirement
description
ontology
,
common
domain
kno
wledge
is
g
athered
using
ontoReq,
and
requirement
s
are
controlled
and
impro
v
ed
using
ReqDL,
which
the
y
de
v
eloped
De
velopment
and
e
valuation
of
a
g
ener
alized
ontolo
gy
fr
ame
work
for
...
(Sour
av
K
undu)
Evaluation Warning : The document was created with Spire.PDF for Python.
1062
❒
ISSN:
2502-4752
in
earlier
research.
In
this
w
ork
the
y
used
Methontology
and
their
w
ork
is
domain
specic
and
the
y
used
competenc
y
questions
for
ontology
e
v
aluation
and
for
implementation,
the
y
used
Porte
ge
as
a
tool.
Ov
erall
the
research
enhances
the
requirement’
s
specication
process.
T
an
et
al.
[12]
described
the
de
v
elopment
and
e
v
aluation
process
of
a
softw
are
requirement
ontology
.
In
this
thesis,
the
y
designed
an
ontology
for
a
vionics
softw
are
de
v
elopment
that
is
strongly
domain-specic.
F
or
e
v
aluation
of
ontology
,
the
y
talk
ed
about
tw
o
methods:
e
v
aluation
by
user
and
application-based
e
v
aluation
and
the
y
prefer
e
v
aluation
by
user
method
as
it’
s
cost-friendly
and
user
-friendly
.
These
w
orks,
ho
we
v
er
,
can
be
considered
independent
ontologies
because
the
y
w
ork
with
problem-
specic
to
a
softw
are
project
or
product.
As
a
result,
we
require
a
method
that
can
handle
a
maximum
number
of
softw
are
projects
while
reducing
ambiguities
in
the
RE
process
and,
ultimatel
y
,
sa
ving
the
cost
of
future
softw
are
de
v
elopment
and
maintenance.
3.
METHOD
This
chapter
co
v
ers
the
proposed
ontology’
s
design
process,
required
tools,
and
the
de
v
elopment
pro-
cess.
F
or
ontology-based
RE,
we
generally
need
four
major
actors.
The
y
are:
requirement
engineers,
stak
e-
holders,
an
ontology
system,
and
a
reasoner
system.
Requirements
are
obtained
through
elicitation,
analysis,
specication,
v
erication,
v
alidation,
and
creation
of
a
softw
are
requirements
document
[24].
3.1.
Resear
ch
design
The
design
process
of
the
suggested
ontology
,
which
includes
class
and
subclass
identication,
object
property
identication,
and
data
property
identication,
will
be
co
v
ered
in
this
section.
Figure
1
depicts
the
proposed
methodology
.
The
follo
wing
subsections
pro
vide
a
detail
e
xplanation
of
each
steps.
Though,
there
is
no
accurate
process
or
model
for
de
v
eloping
an
ontology
,
we
will
follo
w
the
steps
of
Figure
1
for
our
proposed
ontology
.
Figure
1.
Proposed
methodology
Indonesian
J
Elec
Eng
&
Comp
Sci,
V
ol.
40,
No.
2,
No
v
ember
2025:
1059–1073
Evaluation Warning : The document was created with Spire.PDF for Python.
Indonesian
J
Elec
Eng
&
Comp
Sci
ISSN:
2502-4752
❒
1063
3.1.1.
Identication
of
classes
and
subclasses/concepts
W
e
ha
v
e
follo
wed
the
top-do
wn
de
v
elopment
process
to
b
uild
the
ontology
,
which
starts
with
the
most
general
conce
pts
(classes)
and
subsequent
specializations
of
the
concepts
(subclasses).
The
list
of
required
classes
and
subclasses
is
sho
wn
in
T
able
2.
W
e
ha
v
e
g
athered
the
classes
and
subclasses
list
for
b
uilding
SRS
ontology
from
IEEE
std.
830-1998
format
[13],
SWEBOK
[16]
and
the
book
entitled
“Soft
w
are
engineering:
a
practitionar’
s
approach”
[25]
by
Pressma
and
Maxim.
−
SRS
document:
will
be
the
main
class
(concept)
for
our
ontology
.
All
sections
will
be
sub
classes
of
this
class.
−
Requirement:
indi
vidual
requirements
and
their
descriptions
are
captured
in
a
requirement.
−
Requirement
Artef
act:
e
xtra
requirements
information
that
may
be
connected
to
a
requirement
is
captured
by
a
requirement
Artef
act.
−
Requirement
Elicitation
T
echnique:
is
a
process
of
eliciting
a
requirement.
−
Stak
eholder:
is
an
indi
vidual,
group,
or
entity
that
has
an
interest
or
concern
in
a
par
ticular
process,
project,
or
g
anization,
or
system.
W
e
ha
v
e
got
the
subclasses
from
the
book
of
Pressma
and
Maxim
[25].
−
External
interf
aces:
capture
dif
ferent
kinds
of
interf
aces
that
are
required
for
the
softw
are
system.
System
requirement
is
the
equi
v
alent
class
of
it.
−
System
other
non-functional
requirement:
captures
all
the
non-functional
requirements
that
are
needed
for
the
softw
are
system.
−
System
feature:
refers
to
a
specic
capability
or
functionality
of
a
system
or
softw
are
components
w
orking
together
to
achie
v
e
a
particular
goal.
−
Document’
s
section:
is
an
important
class
that
holds
the
main
section’
s
of
a
SRS
document.
−
Appendix:
is
a
supplementar
y
section
at
the
end
of
a
document
or
book
that
pro
vides
additi
onal
information,
details,
or
supporting
documentation.
T
able
2.
Classes
and
subclasses
list
Classes
Sub-classes
SRS
Document
Appendix,
Document
s
Section,
External
Interf
ace,
Requirement,
Require-
ment
Artef
act,
Requirement
Elicitation
T
echnique,
Stak
eholder
,
System
Feature,
System
Requirement,
Systems
Other
Non-Functional
Requirement
Appendix
-
External
Interf
ace
Communication
Interf
ace,
Hardw
are
Interf
ace,
Softw
are
Interf
ace,
User
Interf
ace
Requirement
Functional
Requirement,
Non-Functional
Requirement,
Other
Requirements
Requirement
Artef
act
Goal,
Limitation,
Obstacle,
Source,
Story
,
T
estCase
Requirement
Elicitation
T
echnique
-
Stak
eholder
Business
Operation
Managers,
Consultants,
Customers,
End
Users,
Mark
et-
ing
People,
Other
Stak
eholders,
Product
Engineers,
Product
Managers,
Soft-
w
are
Engineers,
Support
and
Maintenance
Engineers
System
Feature
-
System
Requirement
-
System’
s
Other
Non-
Functional
Requirement
BusinessRule,
PerformanceRequirement,
SafetyRequirement,
SecurityRequire-
ment,
Softw
areQualityAttrib
ute
Story
Scenario,
UseCase
Customers
ExternalCustomers,
InternalCustomers
3.1.2.
Identication
of
object
pr
operties
When
the
subject
and
object
are
entities
(i.e.,
indi
viduals),
a
binary
predicate
kno
wn
as
an
object
prop-
erty
is
emplo
yed
to
e
xpress
f
acts
in
the
subject-predicate-object
form.
The
classes
in
the
requirements
ontology
are
interrelat
ed
using
the
object
properti
es
listed
in
T
able
3.
The
ability
to
relate
requirements
kno
wle
d
ge
to
the
object
properties
mak
es
it
easier
to
deri
v
e
suggestions
for
soluti
on
s
,
such
as
alternati
v
e
requirements.
The
domains
and
ranges
of
the
object
properties
in
the
requirements
ontology
are
listed
in
T
able
3.
3.1.3.
Identication
of
data
pr
operties
Data
properties
generally
refer
to
the
characteristics
or
attrib
utes
of
data
that
describe
its
v
arious
as
-
pects.
These
properties
help
to
dene
and
understand
the
data,
making
it
possible
to
or
g
anize,
analyze,
and
utilize
it
ef
fecti
v
ely
.
The
specications
as
indicated
in
T
able
4,
ontology
currently
of
fers
tw
o
data
properties
to
specify
in
addition
to
the
requirements’
v
alidation
status.
De
velopment
and
e
valuation
of
a
g
ener
alized
ontolo
gy
fr
ame
work
for
...
(Sour
av
K
undu)
Evaluation Warning : The document was created with Spire.PDF for Python.
1064
❒
ISSN:
2502-4752
T
able
3.
Object
properties
list
Domain
Object
property
Range
Requirement
belongsT
oFeature
System
Feature
Appendix
belongsT
oSection
Document
s
Section
System’
s
Other
Non-Functional
Requirement
belongsT
oSection
Document
s
Section
Story
describesRequirement
Requirement
SRS
Document
hasExternalInterf
ace
System
Requirement
SRS
Document
hasFeature
System
Feature
Requirement
hasGoal
Goal
Requirement
hasObstacle
Limitation
Requirement
hasObstacle
Obstacle
SRS
Document
hasRequirement
Requirement
Requirement
hasScenario
Scenario
Requirement
hasSource
Source
Requirement
hasUseCase
UseCase
Requirement
isAlternati
v
eOf
Requirement
System
Feature
isConictW
ith
System
Feature
Requirement
isElicitedByT
echniqueOf
Requirement
Elicitation
T
echnique
Requirement
isPositi
v
eContrib
utionT
oGoal
Goal
System
Feature
renesT
o
Requirement
External
Interf
ace
belongsT
oSection
Document
s
Section
System
Feature
belongsT
oSection
Document
s
Section
Other
Requirements
belongsT
oSection
Document
s
Section
SRS
Document
hasAppendix
Appendix
SRS
Document
hasExternalInterf
ace
External
Interf
ace
System
Feature
hasFunctionalRequirement
Functional
Requirement
System
Feature
hasNonFunctionalRequirement
Non-Functional
Requirement
Requirement
hasObstacle
Limitation
System
Feature
hasRequirement
Requirement
Story
hasScenario
Scenario
SRS
Document
hasSection
Document
s
Section
Requirement
hasT
estCase
T
estCase
Requirement
isAuthoredBy
Stak
eholder
Requirement
isConictW
ith
Requirement
Requirement
isNe
g
ati
v
eContrib
utionT
oGoal
Goal
Requirement
renesT
o
System
Feature
3.2.
Implementation
This
section
on
implementation
will
co
v
er
the
en
vironment
that
ontologies
run
in,
the
softw
are
and
tools
needed
to
b
uild
ontologies,
and
the
process
of
ac
tually
creating
the
suggested
ontology
.
F
or
testing,
we
will
use
tw
o
SRS
documents
from
real-w
orld
s
ystems
that
were
founded
by
uni
v
ersity
students.
The
y
are
titled:
i)
“Under
graduate
Final
Admission
System
of
JUST”
and
ii)
“Online
Job
Application
of
JUST
.
”
3.2.1.
Necessary
tools
and
softwar
es
RDF/RDFS:
a
l
anguage
for
kno
wledge
representation
of
resources
on
the
Internet
is
called
the
re-
source
description
frame
w
ork.
The
majority
of
data
stored
on
the
internet
is
contained
in
ontologies,
and
a
lar
ge
portion
of
that
data
is
referenced
using
RDF
[24].
An
e
xtension
of
RDF
is
called
the
RDF
v
ocab
ulary
description
language
schema,
or
RDF(S).
RDF(S)
gi
v
es
language
users
greater
freedom
to
dene
e
v
ery
term
that
will
be
used
when
dening
web
resources.
Users
can
dene
resources
as
instances
in
multiple
classes,
and
it
of
fers
the
ability
to
create
hierarchical
class
relationships
[24].
W
eb
ontology
language
(O
WL):
created
by
the
W3C,
the
O
WL
allo
ws
applications
to
do
more
than
just
display
the
data
found
in
documents;
it
also
allo
ws
them
to
process
the
content
of
that
data.
O
WL
has
a
lar
ger
v
ocab
ulary
than
XML,
RDF
,
and
RDF(S),
which
enhances
the
de
gree
to
which
machines
can
process
and
interpre
t
that
dat
a.
In
support
of
the
Semantic
W
eb,
this
language
is
the
most
recent
language
specication
appro
v
ed
by
the
W3C
[24].
SP
ARQL:
the
common
protocol
and
query
language
for
RDF
and
link
ed
open
data
databases
is
SP
ARQL.
B
ecause
it
is
made
to
query
a
wide
range
of
data,
it
can
ef
fecti
v
ely
retrie
v
e
information
that
is
hidden
in
data
that
is
not
uniform
and
is
stored
in
dif
ferent
formats
and
sources
[26].
T
o
put
it
simply
,
SP
ARQL
is
to
kno
wledge
graphs
and
the
Semantic
W
eb
what
SQL
is
to
relational
databases
[27].
Indonesian
J
Elec
Eng
&
Comp
Sci,
V
ol.
40,
No.
2,
No
v
ember
2025:
1059–1073
Evaluation Warning : The document was created with Spire.PDF for Python.
Indonesian
J
Elec
Eng
&
Comp
Sci
ISSN:
2502-4752
❒
1065
Prot
´
eg
´
e:
for
creating
and
managing
ontologies,
Prot
´
eg
´
e
has
emer
ged
as
the
most
popular
tool.
T
o
f
acilitate
the
creation
and
administration
of
O
WL
ontologies,
a
desktop
system
called
Prot
´
eg
´
e
5
of
fers
a
wide
range
of
sophisticated
functionalities
[28].
Prot
´
eg
´
e
5.5.0
will
be
used
to
construct
the
soft
w
are
requirement
ontology
.
Pellet,
‘an
intelligent
reasoner’:
Pell
et
is
an
open-source
O
WL-DL
reasoner
b
uilt
on
Ja
v
a
that
can
be
used
for
ontology
classication,
consistenc
y
checks,
and
ontology
v
alidation.
Additionally
,
the
reasoner
establishes
if
it
is
possible
to
conrm
classes
and
relationships
within
ontologies
as
consistent
or
satisable.
Pellet
can
also
be
used
to
access
class
hierarch
y
information,
which
serv
es
as
a
visual
aid
for
descri
bing
the
ontology
[24].
T
able
4.
Data
properties
list
Domain
Data
property
Range
Requirement
content
xsd:string
System
Requirement
content
xsd:string
External
Interf
ace
content
xsd:string
System
Feature
content
xsd:string
Stak
eholder
content
xsd:string
External
Interf
ace
descriptionOfCharacteristics
xsd:string
Requirement
elicitedDate
xsd:dateT
ime
Requirement
hasDescription
xsd:string
Requirement
hasInput
xsd:string
Requirement
hasPriorityLe
v
el
xsd:string
System
Feature
hasV
alidationState
xsd:string
Requirement
isV
alidated
xsd:boolean
Requirement
Artef
act
label
xsd:string
Requirement
label
xsd:string
Document
Section
label
xsd:string
System
Requirement
label
xsd:string
Stak
eholder
lastName
xsd:string
SRS
Document
operatingEn
vironment
xsd:string
SRS
Document
purposeOfSystem
xsd:string
Requirement
Elicitation
T
echnique
content
xsd:string
Document
Section
content
xsd:string
Requirement
Artef
act
content
xsd:string
Appendix
content
xsd:string
Document
Section
descriptionOfCharacteristics
xsd:string
Stak
eholder
designation
xsd:string
Stak
eholder
rstName
xsd:string
System
Feature
hasDescription
xsd:string
Requirement
hasOutput
xsd:string
SRS
Document
hasScope
xsd:string
Requirement
hasV
alidationState
xsd:string
Appendix
label
xsd:string
Stak
eholder
label
xsd:string
System
Feature
label
xsd:string
Requirement
Elicitation
T
echnique
label
xsd:string
External
Interf
ace
label
xsd:string
Stak
eholder
middleName
xsd:string
SRS
Document
productPerspecti
v
e
xsd:string
Requirement
v
alidationDate
xsd:dateT
ime
3.2.2.
Ontology
de
v
elopment
The
ontology
must
be
constructed
in
real-w
orld
applica
tions
once
the
class
hierarch
y
,
object
proper
-
ties,
and
data
properties
are
located
in
T
ables
2
to
4.
W
e
will
use
Prot
´
eg
´
e
[28]
5.5.0
v
ersion
to
construct
the
softw
are
requirement
ontology
.
−
Classes
and
subclasses:
we
should
run
the
Prot
´
eg
´
e
application
and
gi
v
e
name
of
the
ontology
as
SRS
ontology
.
Then
we
ha
v
e
to
incorporate
the
class
hiera
rch
y
founded
on
T
able
2.
SRS
Document,
the
subclass
of
the
thing
class
on
Figure
2,
is
our
primary
class.
All
the
other
classes
will
be
the
sub-class
of
it.
All
of
the
classes
and
subclasses
listed
in
T
able
2
ha
v
e
been
added
correspondingly
.
De
velopment
and
e
valuation
of
a
g
ener
alized
ontolo
gy
fr
ame
work
for
...
(Sour
av
K
undu)
Evaluation Warning : The document was created with Spire.PDF for Python.
1066
❒
ISSN:
2502-4752
−
Object
properties:
the
ne
xt
step
is
to
add
object
properties,
which
are
listed
in
T
able
3
and
will
be
a
subclass
of
topObjectProperty
.
The
graphical
form
in
Figure
3
can
be
identied.
The
domain
and
ranges
for
each
object
property
must
be
dened
after
creating
as
Figure
3
by
adhering
to
T
able
3,
which
will
lat
er
create
relationships
between
v
arious
classes
in
the
ontology
.
−
Data
properties:
the
ne
xt
step
is
to
incl
ude
the
data
properties,
which
are
liste
d
in
T
able
4
and
will
be
a
subclass
of
topDataProperty
.
The
data
for
an
y
indi
vidual
will
be
represented
by
T
able
4,
so
after
creating
as
Figure
4,
we
must
dene
the
domain
and
ranges
for
each
object
property
.
The
term
“data
type”
refers
to
the
ranges
for
data
properties.
Onto
graph
allo
ws
us
to
create
taxonomies
for
classes
after
the
ontology
is
created
on
Prote
ge.
Re-
quirement,
requirement
artef
act,
and
stak
eholder
taxonomy
are
depict
ed
in
Figures
5
to
7,
respecti
v
ely
.
The
requirement
class
is
di
vided
into
three
other
sub
classes
as
sho
wn
in
Figure
5.
The
system
has
some
require-
ments.
Requirement
Artef
act
class
has
also
some
subclasses.
From
them,
the
story
class
has
ag
ain
tw
o
sub-
classes,
and
the
limitation
class
is
equal
to
the
obstacle
class,
as
sho
wn
in
Figure
6.
The
stak
eholder
may
be
an
indi
vidual
or
a
compan
y
.
The
class
stak
eholder
has
subclasses.
Ag
ain,
the
customers
class
has
tw
o
subclasses
as
sho
wn
in
Figure
7.
Figure
2.
Class
heirach
y
in
Prote
ge
Indonesian
J
Elec
Eng
&
Comp
Sci,
V
ol.
40,
No.
2,
No
v
ember
2025:
1059–1073
Evaluation Warning : The document was created with Spire.PDF for Python.
Indonesian
J
Elec
Eng
&
Comp
Sci
ISSN:
2502-4752
❒
1067
Figure
3.
Object
properties
in
Prot
´
eg
´
e
Figure
4.
Data
properties
in
Prot
´
eg
´
e
Figure
5.
Requirement
taxonomy
Figure
6.
Requirement
artef
act
taxonomy
De
velopment
and
e
valuation
of
a
g
ener
alized
ontolo
gy
fr
ame
work
for
...
(Sour
av
K
undu)
Evaluation Warning : The document was created with Spire.PDF for Python.
1068
❒
ISSN:
2502-4752
Figure
7.
Stak
eholder
taxonomy
4.
EV
ALU
A
TION
AND
DISCUSSION
W
e
will
discuss
the
e
v
al
uation
procedures,
the
proposed
ontology’
s
e
v
aluation
process,
and
ho
w
to
ensure
that
our
research
goals
are
met
in
this
section.
4.1.
Ev
aluation
A
set
of
criteria
is
e
xamined
using
measurements
and
techniques
in
ontology
e
v
aluation.
The
main
dif
ferences
between
the
ontology
e
v
aluation
approaches
are
the
number
of
criteria
the
y
tar
get
and
the
rationale
behind
their
assessment
of
the
taxonomy
[23].
Numerous
methods
of
e
v
aluation
e
xist;
ho
we
v
er
,
the
four
most
feasible
and
ef
fecti
v
e
methods
are
listed
as:
gold-standard-based,
corpus-based,
task-based,
and
criteria-based
[23],
[29].
Competenc
y
questi
ons
(CQs)
are
a
common
process
used
in
ontology
v
alidation
[5].
W
e
can
declare
ontology
to
be
v
alidated
if
the
approaches
described
abo
v
e
satisfy
the
CQs.
CQs
can
be
easily
completed
with
softw
are-dependent
or
task-based
approaches
using
SP
ARQL
queries
or
reasoning
[30].
A
fe
w
competenc
y
questions
for
our
suggested
ontology
are
displayed
in
T
able
5.
Our
ontology
will
be
consistent
if
we
recei
v
e
answers
to
those
questions
[8].
T
able
5.
Competenc
y
questions
list
Q.
No.
Competenc
y
questions
(CQs)
CQ
1
Gi
v
en
a
feature,
what
are
the
functional
requirements
related
to
it?
CQ
2
Is
the
SRS
unambiguous?
CQ
3
Can
an
y
requirement
artef
act
be
determined
with
a
requirement?
CQ
4
Can
it
represent
the
kno
wledge
correctly?
4.1.1.
Reasoner:
P
ellet
Pellet
w
orks
with
the
Prote
ge
frame
w
ork
and
can
accomplish
all
of
the
aforementioned
tasks
on
O
WL
ontologies
[24].
It
is
compatible
with
Prote
g
e.
T
o
initiate
the
reasoner
,
click
“Reasoner
,
”
choose
“Pellet,
”
and
then
click
“Start
Reasoner
.
”
Ne
xt,
switch
from
asserted
mode
to
inferred
mode,
choose
an
y
indi
vidual,
and
if
a
ne
w
connection
is
formed
by
ontology
,
it
will
turn
yello
w
.
F
or
a
clear
er
understanding,
see
Figure
8.
Whereas
the
ontology
infers
v
e
ne
w
relations
in
Figure
8.
In
addition,
a
reasoner
can
identify
ontology
inconsistencies.
It
pro
vides
recommendations
for
the
ontology
to
address
issues
if
it
is
inconsistent
or
the
class
hierarch
y
is
incorrect.
The
reasoner
runs
our
ontology
error
-free,
indicating
consistenc
y
in
our
ontology
.
4.1.2.
SP
ARQL
queries
The
common
protocol
and
query
language
for
RDF
and
li
nk
ed
open
data
databases
is
SP
ARQL
[26].
It
is
utilized
in
the
semantic
web
to
retrie
v
e
information
from
ontologies
in
relation
to
a
le
gitimate
relationship
between
the
ontology’
s
instances.
He
re,
we
present
some
results
from
SP
ARQL
queries
on
both
systems.
The
successful
retrie
v
al
of
system
features
related
to
the
uni
v
ersity
admission
system
is
demonstrated
by
the
SP
ARQL
query
in
Figure
9.
The
query
sho
wn
in
Figure
10
retrie
v
es
e
v
ery
system
feature
related
to
the
online
job
application
system.
Functional
requirements
are
displayed
in
relation
to
system
features
in
Figure
11.
4.1.3.
Metric
based
e
v
aluation
An
additional
e
v
aluation
that
is
predicated
on
the
computation
of
ontology
quality
measures
is
feasi-
ble.
OntoMetrics
[10],
a
free
online
tool
for
metric
denition
and
computation,
is
pro
vided
by
the
author
of
Indonesian
J
Elec
Eng
&
Comp
Sci,
V
ol.
40,
No.
2,
No
v
ember
2025:
1059–1073
Evaluation Warning : The document was created with Spire.PDF for Python.