Alon Ravid, a Master's degree candidate working with Berry has explored the use of prototypes as a requirements elicitation tool and methods for formalizing these requirements.

Normally, in a contracted software development, the requirements are captured in a number of documents, including a Software Requirements Specification document (SRS), a prototype of the system user interface, and a document called Occupation Analysis Document (OAD) written by the human engineering group; this last document resembles a draft version of a tutorial and user's manual.

In a typical requirements engineering situation these days, a prototype may be developed in order to answer questions, primarily about user interfaces. Once the prototype is developed and agreed upon, how is the information that it contains transmitted to the programmers? Part of the information appears explicitly in the SRS, part is expressed indirectly by other statements in the SRS, part appears in the OAD, and part does not appear anywhere even though it is known, understood, and agreed upon by all the people involved in the project, by virtue of their having worked together to produce the prototype.

The question is ``What is the right way to formalize and present requirements which were elicited and presented using the prototype?'' It is clear from talking with managers using prototyping as a method of requirements engineering shows that this problem is widespread. A thorough search of the literature shows that the problem has not been solved.

Typically, the information implicit in the prototype is left in the prototype simply because a lot of information in it is not known until the prototype is used to answer questions. The proposed research is an attempt to get a good answer to this question.

The process of creating a prototype involves some difficulties. Given an informal problem description, it is not obvious how to systematically and efficiently construct a prototype. It is hard to distinguish between requirements and design details. After completing the prototype, a method is needed to integrate it to other models of the system. A method is needed to capture the prototype's requirements, and state them formally, in order that they will provide a suitable and traceable base for further development and testing.

This research has examined various types of prototypes, especially user interface prototypes, compared them and has tried to estimate how they influence the development process. It has examined different approaches to prototype development, including approaches which are used by engineers from other disciplines, such as human engineering. We looked at methods to identify, extract, and state formally requirements which were attributed within a prototype in order that the prototype provide a suitable and a traceable base for further development and testing. We lookd for a method to integrate a prototype to other models of the system and create links to these models.

The research has concluded that there is no way to extract this information from a previously written prototype in the absence of knowledge of how it was developed. This is because there are aspects of the prototype's behavior that are artifacts of the prototyping process, often rapid, that are not intended as specified behavior. Just examining a prototype does not allow distiguishing intended from non-intended behavior. The problem is the same as that of reverse engineering from code. Therefore, it is necessary to have carried out prototyping explicitly as part of a fully traced requirements elicitation process in which it is decided and documented ahead of time what behavioral aspects, usually in the user-interface, are being modeled in the prototype. The tracing links allow easy access to the documentation of this decision so that in the future, when one is following the trace links to track down an answer to a requirements issue, one sees the explicit decision and knows whether to consult the prototype or another document in the requirements specification suite.

Ravid based this method on the experience gained during the development of a particular software-based system at Rafael, the Target Scene Generator, which allows its operator to work with infra-red images of a target area. His Master's thesis describes how the prototype was developed and how issues were traced. It describes specific instances of resolving issues using the prototype, other specifications, and the traceability information.

Alon Ravid's M.Sc. Thesis   FTP

Ravid, A. and Berry, D.M., ``A Method for Extracting and Stating Software Requirements that a User Interface Prototype Contains,'' Requirements Engineering, 2000 (To appear) PDF   ps.Z