Programming a Software Requirements-Specification Process

Software-process programming is a comparatively new approach to the speci cation of software processes. It has attracted widespread interest but has not yet received general acceptance. For process programming to be accepted the issues involved must be better understood and its feasibility must be demonstrated. To these ends we have undertaken the development of REBUS, a prototype process program for the speci cation of software requirements. Through the development of REBUS we hoped to acquire knowledge about basic issues in process programming. In the REBUS program we hoped to o er an example of a plausible process program. In this introduction we review the advantages of process programming and argue that prototyping is an appropriate way to advance the state of the art; in the remainder of the paper we report on REBUS. A software-process program is the encoding of a software process in a formal, process-programming language [Ost87]. Software-process programming is the activity of developing software-process programs from requirements, through design, to code, followed by testing, analysis, use, and maintenance. Process programming is thus modeled after conventional programming. Processprogramming languages (i.e. process coding languages) are analogous to conventional programming languages, and process programs are analogous to conventional application programs. The di erence is that processprogramming languages and process programs apply to the domain of software processes and products. Software processes present new and challenging aspects not found in most conventional applications, for example, the need to accommodate both manual and automated activities and the need to manage highly complex, diverse, and interrelated persistent objects. The goal of process programming is to bring increased rigor and consistency to the representation and application of software development methodologies. Software development methodologies are intended to improve software development by specifying the products to be created, describing the activities to be performed, and guiding the execution of these activities and the use of the products. Examples include the Waterfall model [Roy70], Spiral model [Boe88], Jackson System Development [Jac83, Cam86], Booch Object-Oriented Design [Boo83, Boo86], Structured Analysis and Modeling [RJ77, GS86, BBD77, EFRV86], and Structured Design [Mye78, Ber78]. Several problems prevent current software methodologies from being fully and generally successful. The speci cations of software processes and products are too often semi-formal or informal (if speci ed at all), the processes rely on manual interpretation and control, and the products may be managed and accessed haphazardly. A process may not be clearly understood, and to the extent that it is understood it may be di cult to modify e ectively. Consequently, software processes are often executed uncertainly and inconsistently, and software products are more likely to be incomplete, invalid, or incorrect. The potential advantages of process programming derive from the formality of process-programming languages and process programs. Process-programming languages are de ned by formal syntax and precise semantics; process programs are thus amenable to analysis and veri cation and should facilitate communication and education. Process programs are also potentially machine-executable. This would enable them to be executed in a consistent way, and allow them to be e ectively tested, debugged, and reused. Finally, it may be possible to apply conventional tools and techniques to