Umeå University
Jürgen Börstler
Department of Computing Science
Umeå University
S-901 87 Umeå, Sweden
e-mail: jubo@cs.umu.se
phone: +46 (90) 16-67 35
fax: +49 (90) 16-61 26
URL: http://www.cs.umu.se/~jubo/
Use cases and similar notions (like task scripts) are well-suited to describe a system from the user's point of view. In this paper we'll show how use case based tools can support requirements capturing, the derivation of an object model, and the traceability between requirements and design.
In RECORD (REquirements COllection, Reuse, and Documentation, [Bör96]) we tried to follow an user-oriented approach. According to [Car+94] do people appear to understand the world in terms of specific situations. Since use cases are well-suited to describe such situations they are a natural way to describe a system in terms of specific uses. To make the RECORD system usable by end-users we provide a form-based user interface to support structured input of requirements.
The forms are analyzed according to the heuristics described in [SHE89] to identify objects, their properties, behaviors, and interrelationships. This information is used to generate an initial object model. This object model is documented in HTML and interlinked with HTML versions of the use cases. Goal of the whole process is to produce a hypertext based requirements model, supporting the traceability between external and internal views of the system.
Every use case form contains a list of fields. Users are not forced to complete a form in one step, the only thing required by our system are unique names for all use cases. This makes it very easy to switch back and forth between forms.
REGISTER_NEW_CARD describes a typical use case in an access control system (for more details see [BoSi96]). Simultaneously to the use case construction a dictionary is constructed to resolve misunderstandings.
name: Register_new_card
actor: System administrator
summary: The system administrator registers a new card. The
user of the card then registers a code for the card by
herself.
rationale: Users can only access the controlled area with a
registered card. A card must have a registered code.
preconditions: The system is idle.
description: 1. {Enter_supervisor_mode}
2. The {system administrator} {enters} a new {card}
into the {cardreader}.
3. The {system} {validates} the {card} with the
{cardreader}.
4. The {system} {registers} the {card} in the
{database}.
5. {Enter_new_code}
postcondition: The system is idle.
exceptions: 3. Card invalid.
Exceptions are described as simplified use cases in separate forms.
The system marks known terms with curly brackets. Known terms may be
entries in the dictionary or other use cases, as for example
ENTER_NEW_CODE in the use case above. A known term is classified as
a simple word, an actor, an abstract use case, or a concrete use case.
Unlike [Jac+92] and [Reg+95] we do not succsessively refine and formalize use cases manually to derive an object model. In our approach use cases are semi-automatically transformed into object models. This has the advantage of a very short analysis/design cycle and can be seen as a kind of design prototyping. We therefore do a simple textual analysis to identify subject, predicate, and object of each sentence. We then use the heuristics described in [SHE89] to determine objects, attributes, and methods.
From our example use case we get the objects system administrator, cardreader, system, and database from the subject and object of the actions. From the predicates of the actions we get the verb phrases enters_card, validates_card, and registers_card, which are transformed into methods in the object class CARDREADER. The nouns in the compound method names are transformed into instance variables.
In a last step a set of interlinked HTML documents is produced. We generate HTML documents for actors, use cases, the dictionary, and the object model. The object model is structured according to the classes identified during use case analysis. The outcome of this last "phase" is a fully traceable documentation of the functional requirements of the system.