J. David Naumann

Determining information requirements: A contingency method for selection of a requirements assurance strategy

If the information requirements for an information system application can be established accurately and completely and then documented clearly and unambiguously, there is a high probability that the application can be successfully designed and implemented. Information requirements determination consists of two major processes: 1.(1) eliciting requirements and 2.(2) requirements assurance. Many techniques, procedures, and methodologies have been proposed for these two processes. This paper describes the selection of a strategy for information requirements assurance. Selection of the appropriate strategy depends on environmental and project contingencies. Contingencies determine the level of uncertainty to be resolved in order to ensure an accurate and complete statement of information requirements. Based on the level of uncertainty, the strategy for assurance may be to accept the requirements as stated or to follow either a linear, iterative, or experimental assurance process. The approach to strategy selection is illustrated by a contingency analysis worksheet for evaluating requirements uncertainty and by examples.

Evolution versus construction: distinguishing user review of software prototypes from conventional review of software specifications

Although prototyping soflware has been highly touted by practitioners engaged in software requirements elicitation, the process of software prototype review by users has rarely been examined directly. The research study described here examines the distinction between users’ review of a software prototype and their review of traditional paperbased software specifications that are presented to them prior to software construction. This study takes the approach that prototype review is a form of conversation between so&are designers and users that is uniquely structured by the user’s interaction with the referent object of the conversation. Two alternate models of the prototype review activity are presented. A research design for testing the models and distinguishing prototype review activity from traditional review of paper-based software specifications is also set forth. Finally, potential implications of the research are discussed. CONCEPTUALBACKGROUND: What is “software prototyping”? Mayhew & Deamley [ 1990, p.2451 define it as: “the process of constructing and evaluating working models of a system in order to LEARN about certain aspects of the required system and/or its potential solution“ In general, software prototyping is part of what has been called the evolutionaty approach to tiormation systems development IDahlbom & Mathiessen, 19931. This approach assumes that the software designers build information systems according to an evolving cooperative learning process that occurs between designers and users. As described by Naumann and Jenkins [ 19821, the approach entails creating an initial working model of the target software system based on a preliminary sketch of the users’ software requirements. Subsequently, the working model is reviewed by users who specify what aspects of the model need to be changed. The working model of the software is them modified by the software designers in accordance with the critique specified by the users. The cycle of revision, critique and enhancement is continued until a functional software component is completed [Krausher & Shirland, 19851. From the standpoint of the business practitioner, .&ware prototyping is a radical departure from classical, construction-based approaches to so&ware creation that emphasize architecturally oriented plans for software and databases as well as static representations of business tasks and processes [Dahlbom k Mathiessen, 19931. There are two levels of analysis through which prototyping activity can be viewed. At one level, so&are prototyping is a business process that unfolds over an extended period of time (weeks or months) during which a series of meetings between soflware designers and users occurs. At each of these meetings a version of the sofiware prototype is demonstrated to the users so that they can experience it and offer critique. Between these meetings (and sometimes during them) the software prototype is revised by the designers in accordance with the users’ critique. At some point a decision is made that the prototype is completed because it meets or captures user requirements. At another level of analysis, software prototyping is not a business process but a alternate form of interaction between designers and users as they engage in software requirements determination. If designers and users were to engage in the determination of functional requirements for the software according to classical, construction-based methodologies, then requirements would be defmed in the abstract, without the benefit of a common referent object as a basis for task accomplishment. Even if a referent object such as a data model or process diagram were to be used as a basis for interaction between designers and users, this object would (a) only be representational of some part of the underlying functionality of the target software system and (b) only be a static representation on paper. In contrast, prototyping engenders interaction about the target software that (a) is demonstrated on a computer screen as a functional software component, that (b) can be manipulated by the users, and that (c) can be revised (at least partially) in direct response to the users’ critique. Although it is tempting to study prototyping at the level of a business process, it is not clear how much could be understood about it without first understanding what transpires during each of the prototype demonstration meetings between designers and users. Furthermore, even as a business process, software prototyping is not necessarily composed of any fixed number of cycles of critique and revision. The optimal number of cycles is contingent on the (a) application environment in which the software is being developed, (b) number and quality of the organizational staff engaged in the process, and (c) existence of deadline and resource constraints upon the process participants. Only by first understanding prototyping as a means of interaction

Conversation about Software Requirements with Prototypes and Scenarios

Determining the functional requirements for new software is a significant problem because it is dependent upon effective conversation between software designers and users. Prototypes and scenarios are two key techniques that have been advocated to improve the specification and communication of software requirements. This paper describes experimental research examining the utilization of prototypes and scenarios during designer-user conversation to determine and validate software requirements. This study is among the first to empirically test the effectiveness of employing scenarios in requirements determination. The results indicate that scenarios can affect user feedback in conversation about software requirements. The results also suggest that software designers should present users with a combination of software prototypes alongside abstract, diagrammatic models when discussing software requirements.