Information Technology Reference
In-Depth Information
categorization, e.g., “Security”. Typically, these categories can be defined based on a
project glossary that contains important project-specific terms.
2)
Provide input data
to be categorized: Requirements are represented as tickets in
Trac
. For our research prototype we export these requirements (the small grey circles
in Fig.
1
) via CSV from
Trac
and import them into the instance fetcher.
3)
Remove irrelevant stop-words
, like “and”, “any”, “but”, which cannot be used for
categorization. This step is performed automatically using a standard stop-word list
4
.
4)
Bring all remaining words into their root form
: this process is called “stem-
ming” based on a well-known algorithm, like the “Porter Stemmer” algorithm [19].
An example is to stem “jumping” to “jump”.
5)
Get all synonyms and hyponyms
of the analyzed words in the requirements by
using the natural language processing library “WordNet” [17]. For example, “house”
is a synonym for “building”, “dog” is a hyponym of “animal”. Further check all rele-
vant substrings of a word like “net” as a substring of “network”.
6)
Heuristic-based assignment of each requirement to the defined categories
de-
pending on the number of hits for 1) synonyms, 2) hyponyms and 3) substring
matches. The heuristic checks if the hits for synonym, hyponym and substring
matches meet the given threshold values. So the number of met thresholds is between
0 and 3. If this number is equal of higher than the number of thresholds that must be
met, the word will be related to that category, otherwise not. If several categories
reach these thresholds, the requirement will be categorized into all of these categories
(multi-dimensional categorization is allowed)
7)
Save the element as an individual of the ontology class
, if it is not already in the
class. This can only be checked if one or more of the elements attributes have been
declared as primary keys (uniquely identifying the element). If the element has al-
ready been saved in another class as well (which could be the case), declare that the
new element is the same as the already existing one with the
“owl:sameAs”
property.
8)
Semantic requirements conflict analysis:
If the requirements are formally de-
scribed using a specified grammar (e.g., EBNF), the information contained in the
textual requirement descriptions can be semantically analyzed in order to identify
possible inconsistencies and/or conflicts, see subsection 3.2.
3.2 Semantic Conflict Analysis
In the second phase, analysis and reporting approaches build on the mapping of re-
quirements to semantic categories. For formally specified requirement semantics, in
our case following an EBNF template (see Fig. 2), semantic analysis can identify
inconsistencies and conflicts using a set of assertions that should hold true for all
available facts. These assertions are based on the available requirements, while the
available facts are based on the environment and properties of the target system.
Fig. 3 depicts examples for conflicts between requirements (the CRR conflict type
explained in section 4), e.g. the third conflict contains an inconsistency between
requirements nr. 16 and nr.13: The “thing to be processed” part of requirement nr. 16
contains a value of 30 for “number of index updates”, whereas requirement nr. 13
contains the value 20 for “number of index updates, which finally is a requirements
conflict.
4
http://www.textfixer.com/resources/common-english-words.txt
