From cognitive science we know that people appear to understand the world in terms of specific situations ([Car+94]). In object-oriented analysis several authors propose use cases ([Jac+92]), task scripts ([Gra95], [RuGo92]) and similar notions as natural ways to describe a system in terms of its specific uses. Such notations are well-suited to describe a system from the user's point of view.

In the RECORD (REquirements COllection, Reuse, and Documentation, [Bör96]) approach we follow this user-oriented approach. It is our goal to

• enable the end-users to participate in the software development process
• provide use case based tools to support requirements capturing
• reuse existing analysis and design information
• generate object-oriented designs from the information present in the use cases
• use hypertext technology (WWW) to support traceability

Figure 1: Overview over the RECORD approach.

Our current prototype ([BoSi96]) provides a form-based user interface to support structured input of requirements. The filled-in forms are then 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.

Figure 2: A snapshot of our prototype showing four of the five 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.
related use cases:	Enter_supervisor_mode
			Enter_new_code
exceptions:		3. Card invalid

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 (see [BoSi96] for more details).

Figure 3: Interlinked documentation: Summary document.

References

[BoSi96]

T. Boman, K. Sigerud: Requirements Elicitation and Documentation using T-red, Master's Thesis, UMNAD 159/1996, Umeå University, May 1996.

[Bör96]

J. Börstler: User-Centered Requirements Engineering in RECORD - An Overview, Proceedings NWPER'96, the Nordic Workshop on Programming Environment Research, Aalborg, Denmark, May 1996, 149-156.

[Car+94]

J.M. Carrol et al: Binding objects to scenarios of use, Int. Journal of Human-Computer Studies 41, 1994, 243-276.

[Gra95]

I. Graham: Migrating to object technology, Addison-Wesley, 1995.

[Jac+92]

I. Jacobson et al: Object-Oriented Software Engineering, A Use Case Driven Approach, Addison-Wesley, 1992.

[Reg+95]

B. Regnell et al: Improving the Use Case driven Approach to Requirements Engineering, Proceedings of the 2nd Int. Symposium on Requirements Engineering, York, England, Mar 1995, 40-47.

[RuGo92]

K.S. Rubin, A. Goldberg: Object behavior analysis, Communications of the ACM 35(9), September, 1992, 48-62.

[SHE89]

M. Saeki, H. Horai, H. Enomoto: Software Development Process from Natural Language Specification, Proceedings of the 11th Int. Conference on Software Engineering, Pittsburgh, PE, USA, Mar 1989, 64-73.

Downloading our Prototype

The prototype was implemented and tested using Borland Delphi (16 bit version) under Microsoft Windows 95 on an 486 DX66 with 12 MB RAM. The prototype is customized for a minimum resolution of 1024x768.

OOPS! To run the prototype you need a special Dynamic Link Library (DLL) named BIVBX11.DLL, which unfortunately does not ship with Windows. All system data is stored in text files, i.e. you do not need any database software to run the prototype. But, of course you will need a HTML reader for viewing the generated HTML documents. An example session describing the use of the prototype can be found in [BoSi96].

Download prototype (402k).

Back to