Showing papers on "Software requirements specification published in 1986"

Functional programming, formal specification, and rapid prototyping

Abstract: Functional programming has enormous potential for reducing the high cost of software development. Because of the simple mathematical basis of functional programming, it is easier to design correct programs in a purely functional style than in a traditional imperative style. It is argued that functional programs combine the clarity required for the formal specification of software designs with the ability to validate the design by execution. As such they are ideal for rapidly prototyping a design as it is developed. An example is presented which is larger than those traditionally used to explain functional programming. This example is used to illustrate a method of software design which efficiently and reliably turns an informal description of requirements into an executable formal specification.

System for generating software source code components

Abstract: A system has been devised that allows commonly used software components to be designed and developed only once, and reused many times in different applications with different operational contexts and requirements. The system includes a language for the specification of software components in a context-­ independent generic fashion, a compiler l02 for the specification language and a program for l0l, l03, l05-­ l09 for generating concrete software components to work in a specific context.

Multirate real time control system code generator

Abstract: An automatic computer software code generator for multirate real time control systems uses a functional library to define a multiplicity of functional blocks for building a functional description of a control system. For each functional block there is a software template for generating a set of software statements for performing one or more computations each time the software associated with that functional block is executed. A functional description of the control system software to be generated is provided in the form of a catalog database, and the computational relationships to be implemented by the software generated by the invention are defined by specified combinations of the functional blocks in the functional library. A linking software module organizes the catalog database into a plurality of separate subsystems, each subsystem including all the specified functional blocks with a given repetition rate and skew. Finally, a code generation software module generates software for use in the specified control system. The software routines generated generally include: a subsystem software routine for each subsystem, a scheduler program for initiating the execution of the subsystem software routines in accordance with the repetition rate and skew specified for each corresponding subsystem; and a software interface for holding input, output and temporary data values.

Graph Grammar Engineering: A Software Specification Method

Abstract: Graphs as conceptual data models are accepted and used in a wide range of different problem areas. Giving some examples we outline common aspects for modeling complex structures by graphs. We present a formal frame-work based on graph grammars to specify graph classes and the corresponding graph manipulations. We show that such a specification can be written in a systematic, engineering-like manner. This is achieved by an extension of the known programmed, attributed graph grammars. Node-set operators are introduced to facilitate graph queries. Concepts like abstraction, decomposition, refinement, parameterization, and integration have been adopted from software engineering to yield a comprehensive specification method. This method has successfully been applied to specify the central data structures in a software development environment project.

Specification of modular systems

Abstract: A modularity concept for structuring large software systems is presented. The concept enforces an extreme modularity discipline that goes considerably beyond the one found in modern programming languages such as MODULA-2 or Ada. The concept is meant to be used to tightly control side effects in the execution of systems that are constructed of independently developed modules. A family of specification languages is introduced whose members are all based on the modularity concept and thus support the uniform monolinguistic specification of software systems at all development stages. The languages have been defined to enable matching informal, semiformal, and formal specifications and thus to make formal specification of modular systems practicable. The construction of large software systems as interconnections of modules is shown to lead to manageable system structures and to new degrees of freedom in the structuring of the software development process. The suitability of the modularity concept has been evaluated in a large software project for the development of a database management system. The concept and specification languages are explained with the aid of sample specifications.

An Integrated Approach to Software Development

Abstract: REQUIREMENTS. Requirements Discussion. Requirements Document Outline. SYSTEM SPECIFICATION. Discussion. Behavioral Specification Outline. Procedures Manual. Administrative Manual. DESIGN. Design Discussion. System Design Documentation. Component Documentation: Specification and Design. Abstraction and Specification. Appendixes. References. Index.

Kestrel Institute: REPORT ON A KNOWLEDGE-BASED SOFTWARE ASSISTANT

Abstract: This report presents a knowledge-based, life-cycle paradigm for the development, evolution, and maintenance of large software projects. To resolve current software development and maintenance problems, this paradigm introduces a fundamental change in the software life cycle — maintenance and evolution occur by modifying the specifications and then rederiving the implementation, rather than attempting to directly modify the optimized implementation. Since the implementation will be rederived for each change, this process must be automated to increase its reliability and reduce its costs. Basing the new paradigm on the formalization and machine capture of all software decisions allows knowledge-based reasoning to assist with these decisions. This report describes a knowledge-based software assistant (KBSA) that provides for the capture of, and reasoning about, software activities to support this new paradigm. This KBSA will provide a corporate memory of the development history and act throughout the life cycle as a knowledgeable software assistant to the human involved (e.g., the developers, maintainers, project managers, and end-users. In this paradigm, software activities, including definition, management, and validation will be carried out primarily at the specification and requirements level, not the implementation level. The transformation from requirements to specifications to implementations will be carried out with automated, knowledge-based assistance. The report presents descriptions for several of the facets (areas of expertise) of the software assistant including requirements, specification validation, performance analysis, development, testing, documentation, and project management. The report also presents a plan for the development of the KBSA, along with a description of the necessary supporting technology. This new paradigm will dramatically improve productivity, reliability, adaptability, and functionality in software systems.

Intelligent Support for Software Specification and Design

Abstract: S oftware design, often regarded as an art, is frequently delegated to expert software engineers. They must interpret requirements and specifications provided by system analysts when designing solutions for new software problems. Interpreting these specifications leads to an internal conceptual model eventually transformed into a software design. To perform these processes successfully, software experts must depend on experiential knowledge gathered while developing similar software products. Al methods can be incorporated into design environments to facilitate specification and design, including

Specification methodology: an integrated relational approach

Abstract: The effectiveness of set theoretic concepts for the purpose of software specification is becoming more and more widely recognized. This paper presents an integrated relational methodology for software specification, and shows its effectivness when applied to a practical example.

Practical Methods and Tools for Specification

Abstract: This is a course on specification. Since it is based on experiences in the field of software engineering. It applies primarily to software specifications. Many observations and reports indicate, however, that, from specification aspects, there is not much difference between information processing systems in general and software in particular. Therefore, most of this course applies also to system specification. In the first chapter, some fundamentals are discussed. These include the life cycle model and the distribution of costs over the various activities, some definitions, and a rationale for semi-formal specification. The second chapter provides a general outline of a specification system, whose desirable properties are deduced from the qualities of good specifications. In the third chapter, we present some typical specification systems. The primary goal is to show some typical features of such systems rather than to describe them in detail. The fourth chapter addresses management aspects. In chapter 5, some general conclusions are drawn. The appendix (chapter 6) contains a bibliography on specification, and a list of suppliers.

The construction of information management system prototypes in Ada

Abstract: The use of a data-flow diagram and data dictionary for the requirements specification of an information management system is described together with the benefits to be gained from using prototypes. Construction of such prototypes in Ada is discussed in detail with a simple example being given. The use of a flexible user interface, generic data-flows, exception handlers for error conditions and a top-down design method that makes use of separate compilation indicates that Ada is an appropriate language for the development of such systems. Consideration is also given to the use of Ada in the construction of actual as well as prototype information systems.

A data model for requirements analysis

Abstract: The use of a proper data model is a way to introduce rigour in requirements analysis, traditionally considered the most informal stage of software development, and responsible for the more costly errors. Several data models have emerged, but their comparative value is unclear. We think that an appraisal is only possible if the nature — and not only the goal — of requirements analysis is clearly perceived. We investigate this point and emphasise that requirements analysis is an activity of acquiring real-world knowledge, thereby forming a theory in which objectives can be stated and a solution specified. A suited language should thus restrict as little as possible the freedom of expression when describing some part of the world. A number of requirements are derived from this statement, such as the possibility to describe individual objects, as well as groups of objects, to explicitly refer to a global continuous time, to handle undefinedness, to allow simultaneous events, etc. When assessing the various existing data models with respect to these requirements, the entity-relationship model is found a suitable basis, but still lacking essential features. We extend it in a model called ERAE (entity, relationship, attribute, event), which is presented informally and illustrated on examples.

Task analysis and the definition of user needs

Abstract: The specification of user requirements for information technology systems is difficult. This paper reports a survey of task analysis methods as used in practice by Ergonomists and outlines an approach developed by the authors which is based on socio-technical analysis and functional analysis. It is an ‘open systems’ approach which seeks to describe functions and roles before attempts are made to define information requirements. In the second part of the paper a series of cases are presented where the use of this approach provided broad based specifications of user requirements and supported the principle of user participation in systems design.

SEED — A DBMS for software engineering applications based on the entity-relationship approach

Abstract: SEED is a database system which supports the data engineering needs of a software engineering environment. It provides information structures that are not incorporated in conventional database systems, but are typical in the software engineering process. This paper describes two principal features of SEED: how to deal with vague and incomplete information without giving up consistency checking, and the management of database versions and variants. A prototype of SEED is used as the database for an existing specification and design tool.

Simulation Model Development: System Specification Techniques

Abstract: A review of software specification techniques and specification languages is described. Special emphasis given to simulation model specification and the degree to which general software techniques are applicable in the modeling domain. The role of specification is examined in terms of existing techniques as well as abstraction permitting the identification of desirable properties unrelated to existing tools. A categorization of specification languages assists in understanding the similarities and differences among current approaches.

Formal specification languages

Abstract: Bugs in computer software are still commonplace. The problem is often due to inadequate specification of the requirements. Formal specification is proposed as a solution, but is it practical?

Software specification and design must “Engineer” quality and cost iteratively

Abstract: I will state my position in terms of.a number of fundamental principles. All critical software quality and cost attributes must be specified measurably and controlled iteratively throughout the entire design, development, and operational life. Software ~r.Jng= languages must be capable of handling engineering problems too. Software alone produces no real-world results. The total systems must be considered for the most effective trade-offs to achieve the overall design objectives. By systems engineering we include hardware, dataware, peopleware and instructionware. ,~L_The principle of ~ ~ of Unambieuous Quality control inspection must be performed on all stages of specification and development. There must be emphasis on the high-level stages because of the lower cost-of-repair of faults found there. A prerequisite for high-level quality control is the use of specification languages. Estimation, prediction and measurement must be applied to critical software and system attributes, and at ntltlIX different stages of specification, development and operation, using a wide

Method for forming software specification

Abstract: PURPOSE:To improve the quality of software demand specification by discovering errors of demand specification at the beginning of software development based on the performance of the demand specification describing system functions and carrying out modifications easily. CONSTITUTION:A test function 13 compares with a previously predicted result given in a test procession 14 after the output of an output talken, discriminates right or wrong of performance and outputs the discriminated result as a performance result 15. If it is impossible to continue the performance, the position of a talken at that time is preserved as a performance condition 16 and outputted as an error in the performance result 15. A test function 13 monitors an action of a performance function 11, the performed work row is registered in the performance condition 16 and the performed work name is left only when right output is obtained, and the process is left when wrong output is obtained. When the results of the test procession are entirely normal, the proportion of performed works is outputted, a user investigates the performance result 15 and selects errors for debug.