what-when-how
In Depth Tutorials and Information
implementation proposal of a design task is defined as a logical sequence of actions/
objects, combined with necessary resources including time and staff. For example,
regarding the example task “define quality attributes,” a possible implementation
proposal can be specified as:
{Objects: performance, security, and versatility; actions: define performance,
security, and usability as quality attributes according to the functional require-
ments; resources: the design teamwork for one day.}
herefore, if there are different decisions, objects, or resources in the stakeholders'
proposals for a specific design task, the team will declare a decision conflict. A typical
conflict could be, for example, that the stakeholders are choosing different objects. Just
like the example mentioned at the beginning of this section, the stakeholders' choice
of objects (i.e., quality attributes) are different for the task. In case of a conflict, the
process will continue on to the negotiation phase where arguments will be generated,
exchanged, and evaluated for conflict resolution. Otherwise (i.e., if there is no con-
flicting decision), the process will move forward directly to the post-negotiation phase
(see Section 3.4.3) with mutual agreements on how to implement all design tasks.
8.3.4.2 Negotiation: Utilizing Structured Arguments
In this phase, the participating stakeholders are guided to negotiate with each other
based on structured arguments until a mutual agreement is reached. In most of the
existing practices, an argument-based negotiation process is generally undertaken
according to the following two stages:
◾
Stakeholders generate argument claims (or counter claims) for concerned
issues and provide supporting data.
◾
Stakeholders exchange and respond to others' claims (or counter claims) and
their associated supporting data [Sierra et al. 1998].
However, these practices have not resolved the challenges of analyzing how argu-
ments relate to other arguments for reining conflicting arguments or how best to
evaluate the arguments [Zeleznikow 2002]. In addition, most of them provide little
guidance in how to generate arguments based on the decision-making process. As
mentioned, what is in need is an operational negotiation process built that is based
on the arguments to support group decision making. he novelty of our approach
is to resolve this challenge by utilizing the structured arguments to design a collab-
orative negotiation process referencing the sociotechnical co-construction process,
where these arguments can be generated, exchanged, and evaluated based on the
synthesis between the structured arguments and the objective hierarchy. his phase
consists of four steps (4, 5, 6, and 7). Steps 4 and 5 guide the stakeholders to build-
ing the objective hierarchy and declare stakeholders' perspectives. Steps 6 and 7
discuss how the perspectives can be analyzed and the arguments evaluated, based
on the information collected in Steps 4 and 5.
