A Requirements Analyst's Apprentice: A Proposal

The Requirements Analyst's APprentice (RAAP) partially automates the modeling process involved in creating a software requirement. It uses knowledge of the specific domain and general experience regarding software requirements to guide decisions made in the construction of a requirement. RAAP assists the analyst by maintaining consistency, detecting redundancy of description, and analyzing completeness relative to a known body of requirements experience. RAAP is a tool to be used by an analyst in his dealings with the customer. It helps him translate the customer's informal ideas into a requirements knowledge base. RAAP will have the ability to present its internal representation of the requirement in document form. Document-based requirements analysis is the state of the art. A computer-based, knowledge-based analysis system can provide improvement in quality, efficiency and maintainability over document-based requirements analysis and thus advance the state of the art towards automatic programming. RAAP takes a new approach to automating software development by concentrating on the modeling process involved in system construction (as opposed to the model translation process). By supporting the intelligent creation of perspicuous models, it is hoped that flaws will become self revealing and the quality of software can be improved. Assistance is proved for the creation of "correct" models and for the analysis of the implications of modeling decisions.

[1]  Ali Mili,et al.  Workshop on Models and Languages for Software Specification and Design , 1985, Computer.

[2]  James M. Neighbors,et al.  The Draco Approach to Constructing Software from Reusable Components , 1984, IEEE Transactions on Software Engineering.

[3]  Charles Rich.  Knowledge Representation Languages and Predicate Calculus: How to Have Your Cake and Eat It Too , 1982, AAAI.

[4]  Martin S. Feather,et al.  Language support for the specification and development of composite systems , 1987, TOPL.

[5]  Valdis Berzins,et al.  Analysis and Design in MSG.84: Formalizing Functional Specifications , 1985, IEEE Transactions on Software Engineering.

[6]  Robert Balzer.  Automated Enhancement of Knowledge Representations , 1985, IJCAI.

[7]  Robert Balzer,et al.  Informality in Program Specifications , 1899, IEEE Transactions on Software Engineering.

[8]  Ernest A. Hershey,et al.  PSL/PSA: A Computer-Aided Technique for Structured Documentation and Analysis of Information Processing Systems , 1976, IEEE Transactions on Software Engineering.

[9]  Thomas E. Bell,et al.  An Extendable Approach to Computer-Aided Software Requirements Engineering , 1976, IEEE Transactions on Software Engineering.

[10]  Janis A. Bubenko,et al.  Information Modeling in the Context of System Development , 1980, IFIP Congress.

[11]  Martin S. Feather,et al.  Implementing Specification Freedoms , 1986, Sci. Comput. Program..

[12]  James J. Horning,et al.  The Larch Family of Specification Languages , 1985, IEEE Software.

[13]  Brian Cantwell Smith,et al.  The limits of correctness , 1985, CSOC.

[14]  Robert Balzer,et al.  Principles of good software specification and their implications for specification languages , 1981, AFIPS '81.

[15]  Ernest A. Hershey,et al.  A computer-aided technique for structured documentation , 1976, DATB.

[16]  Mark Stefik,et al.  The Next Knowledge Medium , 1986, AI Mag..

[17]  Pamela Zave,et al.  The operational versus the conventional approach to software development , 1984, CACM.

[18]  Thomas E. Cheatham,et al.  Software Technology in the 1990's: Using a New Paradigm , 1983, Computer.

[19]  Robert Balzer,et al.  Report on a knowledge-based software assistant , 1986 .

[20]  Richard C. Waters,et al.  KBEmacs: A Step Toward the Programmer''s Apprentice , 1985 .

[21]  Russ Abbott.  Program design by informal English descriptions , 1983, CACM.

[22]  David R. Barstow,et al.  Who needs languages, and why do they need them? or no matter how high the level, it's still programming , 1983, ACM SIGPLAN Notices.

[23]  Sol Jaffe Greenspan,et al.  Requirements modeling: a knowledge representation approach to software requirements definition , 1984 .

[24]  Robert Balzer,et al.  Transformational Implementation: An Example , 1981, IEEE Transactions on Software Engineering.

[25]  S. Smoliar,et al.  Who needs languages, and why do they need them? or no matter how high the level, it's still programming , 1983, SIGPLAN '83.

[26]  Douglas B. Lenat,et al.  CYC: Using Common Sense Knowledge to Overcome Brittleness and Knowledge Acquisition Bottlenecks , 1986, AI Mag..

[27]  Douglas T. Ross,et al.  Structured Analysis for Requirements Definition , 1977, IEEE Transactions on Software Engineering.

[28]  John Mylopoulos,et al.  Capturing more world knowledge in the requirements specification , 1982, ICSE '82.

[29]  Alan M. Davis,et al.  PLP: an automated tool for the processing of requirements , 1979, COMPSAC.

[30]  Pamela Zave,et al.  An Operational Approach to Requirements Specification for Embedded Systems , 1982, IEEE Transactions on Software Engineering.

[31]  Zohar Manna,et al.  Synthesis: Dreams - Programs , 1979, IEEE Trans. Software Eng..

[32]  Douglas T. Ross,et al.  Structured Analysis (SA): A Language for Communicating Ideas , 1977, IEEE Transactions on Software Engineering.

[33]  James Milne Neighbors,et al.  Software construction using components , 1980 .

[34]  Bertrand Meyer,et al.  On Formalism in Specifications , 1985, IEEE Software.

[35]  Mehdi T. Harandi,et al.  Workshop on software specification and design , 1988, SOEN.

[36]  Charles Rich,et al.  The Layered Architecture of a System for Reasoning about Programs , 1985, IJCAI.