|
||||||
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. |
||||||