2009 Third International Conference on Advances in Semantic Processing 2009
DOI: 10.1109/semapro.2009.11
|View full text |Cite
|
Sign up to set email alerts
|

Ontologies in Checking for Inconsistency of Requirements Specification

Help me understand this report

Search citation statements

Order By: Relevance

Paper Sections

Select...
2
2
1

Citation Types

0
13
0

Year Published

2014
2014
2021
2021

Publication Types

Select...
5
1
1

Relationship

0
7

Authors

Journals

citations
Cited by 21 publications
(13 citation statements)
references
References 16 publications
0
13
0
Order By: Relevance
“…Rules (17) specifies conditions when a requirement is lacking descriptions of the agents, but the mapped ontology node has specified them. Other rules (18)(19)(20)(21)(22)(23)(24)(25)(26)(27) for checking when, where, why, how, and NFR attributes are similar to rules (16) and (17).…”
Section: Rules Definitionmentioning
confidence: 99%
See 2 more Smart Citations
“…Rules (17) specifies conditions when a requirement is lacking descriptions of the agents, but the mapped ontology node has specified them. Other rules (18)(19)(20)(21)(22)(23)(24)(25)(26)(27) for checking when, where, why, how, and NFR attributes are similar to rules (16) and (17).…”
Section: Rules Definitionmentioning
confidence: 99%
“…Some works focused on early stage-the construction of ontology [10]- [12], and some others supported requirements elicitation [13]- [19], and some works related to checking the quality of requirements [20]- [22].…”
Section: Related Workmentioning
confidence: 99%
See 1 more Smart Citation
“…To observe whether the software is as indicated by clients' necessities or not, the requirements should be appropriately confirmed and approved [19]. As these stakeholders are from diverse domains therefore issues emerge when the engineers can't understand and clients can't pass on their requirements appropriately [10]. Therefore requirements representation is an issue in software requirements [9].…”
Section: Introductionmentioning
confidence: 99%
“…A key purpose behind why this is still so difficult to meet client requirements is that the larger part of requirements report is casual, composed in common dialect, though the last objective (code) is formal [10]. Because of this reason all clients should have the same domain learning to handle the issues raised by having a diverse understanding of the same thing [7].…”
Section: Introductionmentioning
confidence: 99%