SEKE 2012 Proceedings - Knowledge Systems Institute

With the GDUC approach, we can model functional and
nonfunctional requirements by extending the use cases while
analyzing the requirements as shown in Figure 2. A goal is
associated to the original use case (U1), and U1 is extended to
more detail use cases having their respective goals to achieve.
These goals carry richer information that will be discussed in
the next section. A goal can be classified with three facets:
competency, view, and content. Looking into competency, we
can model a goal as a rigid goal or a soft goal. A rigid goal is
the goal that needs to be fulfilled fully while the requirement of
a soft goal is more relaxed. The view of requirements can be
actor-specific or system-specific, and the content can be
functional or nonfunctional requirements. The content of a goal
is derived based on functional or nonfunctional
requirements.There are four steps used repeatedly in this
process: identifying the actors, setting goals, constructing a use
case model, and evaluating the goals.
negotiation: a boss, a customer, and a salesperson. The boss
expects to gain the largest benefit from a transaction and has
the control over the pricing activity. He gives the price
guideline to the salesperson while interacts with the customer
for special needs. The customer has a certain habit for purchase
and is looking for a lower price for merchandise. For ordinary
purchase, he interacts with the salesperson, but for some
special requests, he works out with the boss. The salesperson
needs to meet the assigned sales quota by using his ability to
persuade customers. He has some freedom in lowering price,
but the boss has the final say. In a usual setting like in Figure 3,
the customer first encounters with a salesperson, and the
salesperson promotes some merchandise to the customer.
When there is a special purchase request such as large volume
of purchase, the customer may be directly dealing with the boss.
Figure 3. Relationship between participants in selling items
Figure 2. Relationship between goals and use cases
After defining the categories and the relationship among
goals, we now focus on identifying what issues are associated
to the goals [7]. First, we can organize the existing information
among goals, including goal categories, roles, cooperative
goals, conflicting goals, and counterbalanced goals. Goal
categories contain issues that will affect the result of analysis,
and the actors and use cases provide attributes that describe the
actors and their relationships. With such attributes discovered,
we can analyze their relationship to see if they are cooperative,
conflicting, or counterbalancing to each other.
Identifying possible issues based on these attributes, we
need to select which issues are best fit for the negotiation
process. Comparing all issues at once causes heavy
computation, so we use a hierarchical approach in evaluating
issues. Issues are compared in pairs and the resulting scores are
recorded in a matrix. The first step is to define the levels, and
then the matrix with comparison results is constructed.
Proposals containing different set of issues are derived, and the
proposals are compared. Finally, the order of favorable
proposals is determined.
III.
ILLUSTRATION AND EXPERIMENT
A. Scenario and Assumption
For presenting the detail steps of our approach, a scenario
about a market activity is presented below to illustrate how our
method can be used. There are three players in this purchasing
B. Gaol-Driven Analysis
We start from identifying actors as Boss, Customer, and
Salesperson with their corresponding use cases as shown in
Figure 4. For these actors, we define the corresponding goals,
such as boss to get the highest benefit, customer to purchase
necessary items, and salesperson to sell items. Using three
facets (competency, view, and content) to analyze these goals,
we observe that these goals are rigid since they must be
fulfilled. They are also actor-specific and functional. In
enriching the user model, we extend the original use case with
more use cases to provide more information that is embedded
in the requirements. These extended use cases are able to
associate with goals that may be rigid or soft goals with actoror
system-specific and functional or nonfunctional
requirements.
Figure 4. Use case model with associated goals
Identifying the relationship between the use cases and
corresponding goals based on our scenario, we can extend it to
“Whole sales” and “Regular sales” from the original use case,
“Selling Merchandise”. The use case “Purchase Necessity” is
760