|
||||||
Overview |
||||||
The design goals of the first version of the tool were to
provide a simple and integrated solution to manipulate use
case and rationale models without embedding process specific
assumptions. The tool is a web application that can be
accessed via most popular web browsers. This enables users
to access the tool remotely from a variety of environments
(e.g., lab, home, office) without the installation of
additional software. The main view of the tool presents the
user with three frames: a title/menubar, a requirements
specification view and a rationale view (see
below). |
||||||
Requirements View |
||||||
The requirements view displays the requirements
specification as a hypertext document, structured into
actors, user tasks, use cases, services, and non-functional
constraints [10]. Actors, user tasks, and
non-functional constraints describe the application domain
from the user's point of view and independently from the
system. The services describe the features of the system,
independently from the user. Finally, the use cases describe
how user tasks are realized in terms of services and provide
traceability from the problem statement to the
specification. The user can also provide examples in terms
of actor instances and scenarios and define important terms
using a glossary. The tool provides templates for each
requirements element. The tool recognizes known terms and
highlights them automatically in text fields (e.g., the flow
of events of a user task or a use case). This provides the
user a simple way for including references to other
requirements elements. For example, the figure below
displays the detailed view of a use case. |
||||||
Rationale view |
||||||
In the rationale view, information is structured
according to the Questions, Options, Criteria (QOC) paradigm
[14] and displayed as tables and hyperlinks, thus
maximizing the density of information that the user can read
in a single screen (see Fig. 3.). A single page describes
the question under consideration, the decision (if any) that
resolves the question, and a table describing the trade-offs
that were evaluated. The rows of the table are the options
that were considered and discarded. The columns of the table
are the criteria relevant to the question that were used to
evaluate the options. The table cells contain the
assessments of each option against each criteria. Displaying rationale as text is a different approach than other well-known rationale-based tools (e.g., gIBIS[7], SYBIL[12], QuestMap[18]), which display rationale as a graph. In addition to the QOC structured information, users can annotate questions with informal comments or arguments (with the [Post Comment] feature) to provide reference information or negotiate various aspects of the question. |
||||||
Integration |
||||||
An important assumption behind our process is that requirements and rationale must be tightly integrated for decreasing the overhead of rationale capture and increasing its utility. This integration is visible in the tool in two ways: the interlinking of requirements elements and questions, and the interlinking of non-functional constraints and criteria. Linking of requirements and rationale elements. The user can create questions in two ways: by challenging a specific requirements element with the [Question] feature or by justifying a requirements element with the [Justify] feature (see buttons at the top of the use case view above). By clicking on [Question], the user is presented a series of forms to enter a question, its relevant criteria, one or more options, an the assessments of the options against the criteria. Users use [Question] to request a clarification, express a disagreement, or more generally, to initiate a discussion. Once other users have contributed to the question and a consensus is reached, the user can close the question with a decision. By clicking on [Justify], the user is presented with a similar series of forms, except that the resulting question is closed and the current alternative is described and used as a decision. The resulting question can only be discussed if it is first reopened. [Question] is used to open a discussion with multiple users and hence collaboratively building a rationale behind one or more evolving requirements element; while [Justify] is used (usually by a single user) to enter the justification of the current version of a requirements element. When creating questions, either with [Question] or [Justify], the tool stores a bidirectional link between the questioned requirements element and each of its corresponding questions. This enables the user to navigate and update related questions or related elements quickly. Linking of non-functional constraints and criteria. Non-functional constraints are treated as criteria in the rationale view (Fig. 3.). This enables the user to select non-functional constraints that are relevant to a given question. These non-functional constraints are then included as columns in the assessment table as a regular criteria. Each option can thus be evaluated according to its degree of satisfaction of non-functional constraints. Links between the columns in the rationale view and the non-functional constraints in the requirements view enables the user to view detailed descriptions of non-functional constraints and their context. Note that, while all non-functional constraints are criteria, not all criteria are nonfunctional constraints. Some criteria, for example, can originate from other tools (e.g., design goals during system design). |
||||||
Planned Improvements |
||||||
Refined requirements model:
Refined rationale model:
Integration:
|
||||||
Availability |
||||||
We plan to release REQuest as an open source project, after the next series of improvements, in late 2001 or early 2002. If interested, send mail to Allen Dutoit or Barbara Paech. |
||||||