Syntax
<Variable Declarations>
Generic
Rule syntax <Dependency Declarations>
-> <Action Declarations>
X={a} or X={a|b}
Variable
declaration X/AB or X/{AB/CD}
Dependency root(X)
Declaration
dep_name(X, ?)
dep_name(X, Y)
dep_name(X, ?/{AB|CD})
dep_name(X, {a|b})
Action
Declaration
not dep_name(X, Y)
ignore(X)
Explanation & Example(s)
The syntax of a rule contains 3 parts: variables need to be declared first, then a list of
dependencies to specify the matching conditions of the rule, then a list of actions to be
executed if the rule is matched.
Example:
X={design|aim}
Y/VB
root(X)
nsubjpass(X, {system|project})
auxpass(X, {be|is|are})
xcomp(X, Y)
-> root(Y);
Variable X has the value of a, or one of the values in a, b… Example: X={design|aim}
Variable X has the POS tag of AB, or one of the POS tags in AB, CD… Example:
X/{NN|NNS}
Specify that X is the root of the dependency tree (a root has no dependency link pointing to
it)
There is a dep_name dependency between X and any node. Example: dobj(X, ?)
There is a dep_name dependency between X and Y. Example: xcomp(X, Y)
There is a dep_name dependency between X and any node having one of the POS tag of AB,
CD, … Example: nsubj(X, ?/{NN|NNS})
There is a dep_name dependency between X and any node that has one of the POS tag of AB,
CD, … Example: nsubjpass(X, {system|project})
There is no dep_name dependency between X and Y. Example: not xcomp(X, Y)
Ignore the sub-tree whose root is X. If X is the root of the entire dependency tree, then the
whole sentence is ignored.
Example:
X/{VB|VBD|VBG|VBN|VBP|VBZ}
Y={list}
root(X)
nsubj(X, Y)
amod(Y, {follow})
-> ignore(X);
root(X)
Using this rule, a sentence such as “the following list shows the categories of books” shall be
ignored.
Move the root to node X, consider only the sub-tree whose root is X, ignore the rest of the
tree.
Example:
X={design|aim}
Y/VB
root(X)
nsubjpass(X, {system|project})
auxpass(X, {be|is|are})
xcomp(X, Y)
-> root(Y);
Using this rule, a sentence such as “the system is designed to automate the review process”
shall be extracted as “automate the review process”.
sub_goal(goal(X), goal(Y))
Establish a sub-goal (or relevant) relationship between the goal extracted from the sub-tree
relevant_goal(goal(X), goal(Y)) whose root is X and the one from Y. Goals are relevant if they are known related to each
other but more detailed relationship cannot be inferred from the text.
Example:
X/{VB|VBD|VBG|VBN|VBP|VBZ}
Y/VBG
root(X)
prepc_by(X, Y)
-> sub_goal(goal(Y), goal(X));
Using this rule, a sentence such as “System shall improve the editor’s productivity by
automating the review process” shall be extracted into two goals “System shall improve the
editor’s productivity” and “automate the review process” with a “sub-goal” relationship
between them.
split_sibling(X, Y)
split_alternative(X, Y)
preceed(statement(X),
statement(Y))
alternative_path(statement(X),
statement(Y))
Used in case coordinating conjunction (and/or) is found in the sentence. The action means
splitting the sentence into two separated ones (based on the conjunction), build goals based
on these sentences and establish a sibling (if and is used) or alternative (if or is used) between
these goals.
Example:
X/{NN|NNS|NNP|JJ|JJR|RB}
Y/{NN|NNS|NNP|JJ|JJR|RB}
inferred_conj_and(X, Y)
not prep_between(?/{NN|NNS|NNP}, X)
not prep_between(?/{NN|NNS|NNP}, conj_and(X))
-> split_sibling(X, Y);
Using this rule, a sentence such as “Improve the editor’s productivity and efficiency” shall be
extracted into “Improve the editor’s productivity” and “Improve the editor’s efficiency” with
a “sibling” relationship between them. Sibling relationship is not a modeled relationship. It is
used to support the elicitation process with the indication that the two goals may share the
same parent goal.
Used to split use case steps combined in one step. One action extracts two steps at a time. In
case of multiple steps, more than one iteration of applying rules are involved.
Example:
X/{VB|VBD|VBG|VBN|VBP|VBZ}
Y/{VB|VBD|VBG|VBN|VBP|VBZ}
inferred_conj_and(X, Y)
not prep_between(?/{NN|NNS}, X)
not prep_between(?/{NN|NNS}, Y)
not mark(X, {if})
not mark(Y, {if})
-> preceed(statement(X), statement(Y));
extension_condition(X, Y),
extension_condition(neg(X)),
extension_step(Z), uc_step(Y)
Using this rule, a use case step such as “The editor fills the form and submits the form” shall
be extracted into two steps: “The editor fills the form” and “The editor submits the form”
Used to extract use case’s extension described/implied in a sentence in a use case description.
These actions are normally used together to determine the components of the extracted
extension (i.e., condition, step).
Example:
X/{VB|VBD|VBG|VBN|VBP|VBZ}
Y={step}
Z/CD
W/{VB|VBD|VBG|VBN|VBP|VBZ}
root(X)
prep_in(X, Y)
num(Y, Z)
advcl(X, W)
mark(W, {if})
-> extension_condition(W, Y), uc_step(Z), extension_step(X, W);
resume(Z)
Using this rule, the sentence “In step 2, if the user hasn’t filled out the form, the system
should raise an error” shall be extracted as an extension with the following information:
• Condition: “the user hasn’t filled out the form”
• Extension’s start step number: 2
• Extension step: “the system raise an error”
This is used to identify the resuming step of an extension.
Example:
X={return}
Y={step}
Z/CD
root(X)
prep_to(X, Y)
num(Y, Z)
-> resume(Z);
Using this rule, a sentence such as “Return to step 3” included in an extension specification
shall be extracted as a resuming relationship between the extension being described and step
number 3 in the use case’s main scenario.
uc_data_constraint(statement(Y)) This is used to recognize data constraint in use case specification.
Example:
X={choice|option|alternative}
Y/{NN|NNS|NNP}
Z/{NN|NNS|NNP}
nsubj(Y, X)
cop(Y, {are|be})
root(Y)
conj_and(Y, Z)
-> uc_data_constraint(statement(Y));
uc_include(X);
uc_include(X);
Using this rule, a sentence such as “The search options are keyword, author and date” shall be
extracted as a use case data constraint.
This is used to extract include/extend relationship between use cases.
Example:
X={case}
Y={use}
Z={perform}
W/{VB|VBD|VBG|VBN|VBP|VBZ|NN|NNP|NNS}
nn(X, Y)
nsubjpass(Z, X)
ccomp(Z, W)
auxpass(Z, {is|be})
root(Z)
-> uc_include(W);
repeating_step_con(X),
repeating_step_start(Y),
repeating_step_end(Z)
Using this rule, a use case step such as “Use case ‘User Registers’ is performed” shall be
extracted as an “include” relationship between the use case being described and the use case
‘User Registers’.
These actions are used together to identify “repeating use case steps”.
Example:
X={repeat}
Y={step}
Z/CD
W/CD
T/{VB|VBD|VBG|VBN|VBP|VBZ}
nsubj(X, ?/{NN|NNS|NNP})
root(X)
dobj(X, Y)
num(Y, Z)
conj_and(Y, W)
mark(T, {until})
advcl(X, T)
-> repeating_step_con(T), repeating_step_start(Z),
repeating_step_end(W);
Using this rule, a use case step such as “repeat step 3 and 4 until the form inputs are
validated” shall be extracted as a repeating step with the following information
• Condition: the form inputs are validated
• Start step number: 3
• End step number: 4