Showing papers on "Software requirements specification published in 1984"

Generalization/Specialization as a Basis for Software Specification

Abstract: This paper describes a software specification methodology based on the notion of concept specialization. The methodology, which is particularly useful for Information Systems, applies uniformly to the various components of such systems, such as data classes, transactions, exceptions, and user interfaces (scripts), and its goal is the systematic and structured description of highly detailed world models, where concepts occur in many variations. An example from the domain of university information systems is used to illustrate and motivate the approach.

Criteria for Software Reliability Model Comparisons

Abstract: A set of criteria is proposed for the comparison of software reliability models. The intention is to provide a logically organized basis for determining the superior models and for the presentation of model characteristics. It is hoped that in the future, a software manager will be able to more easily select the model most suitable for his/her requirements from among the preferred ones.

SLAN-4-A software specification and design language

Abstract: SLAN-4 ("Software Language-4") was developed to meet the need for a formal tool for specifying and designing large software systems. It provides language constructs for algebraic and axiomatic specifications and also pseudocode constructs for the design step. A major design goal was to ease subsequent refinements of a (given) specification. The design can start with a very informal specification, which can be implemented later using lower level concepts. This paper gives an overview of the SLAN-4 syntax and semantics. It concentrates on the most important aspects of: abstract data types, algebraic specification of abstract data types, and axiomatic specification of modules. Because the pseudocode part of SLAN-4 consists mainly of control structures similar to those in modern high-level programming languages, this element of the language is not separately described. The paper includes an example of how to use SLAN-4, and also the experiences gained in using the language to formally specify a real-world software product of about 18 000 lines of code written in an IBM internal high-level language.

On what exactly is going on when software is developed step-by-step

Abstract: In this paper we present a (necessarily) informal and brief description of formal concepts which lend mathematical support to a paradigm of software development Some important obligations which must be met by the software developers are pointed out Correspondences between widely adhered to practices and their mathematical counterparts are identified and explained

Logic Programming in the Fifth Generation

Abstract: The Japanese Fifth Generation Computer Systems (FGCS) project has chosen logic programming for its core programming language. It has recognized the major contribution that logic programming has to make not only in artificial intelligence but in database systems and software specification as well. It has recognized and intends to exploit the greater potential that logic programming has to offer for taking advantage of the parallelism possible with innovative multiprocessor computer architectures.

Principles for computer-aided information systems development

Abstract: This dissertation describes partial requirements for the Plexsys Development Environment (DE) for developing and implementing Management Information Systems (MIS) A DE is a complete and unified set of concepts, techniques, and tools (methods) that aid in normative requirements analysis, elicitation and ideation of unique requirements, modeling, analyzing, and performing design transforms A framework is proposed as an aid for evaluating existing MIS analysis and design methods, and for developing a complete DE A MIS produces decision support information and performs the transaction processing task Part of this dissertation is to formalize the analysis and modeling of transaction processing As part of this process, a modeling language and processing requirements are proposed A design transform is proposed that develops logical system requirements given a set of decision support and transaction processing information requirements This transform uses a formalization of the output decomposition process In order to automate the transform, functional data types are defined Further, constant data processing requirements are defined Using the Plexsys software base as a model, the concept of the Enterprise Software Development Library (ESDL) is proposed This library contains software tools specifically for the extension of programming languages for the business data processing environment

Control Software Specification and Design: An Overview

Abstract: Current control system design for industrial applications corresponds essentially to stating the process requirements, specifying the functions to be performed, then implementing them in software. This article surveys techniques in the field of control software and design, noting particularly the need for clear specifications and engineering methods. It provides the basis for predicting the general direction of improvements in control system design allowed by the developments in computer technology and artificial intelligence. 14 references.

A user's approach to requirements analysis of a large software system

Abstract: Arriving at all the requirements of a large software system is a very difficult task, whose success or failure significantly affects the system design and implementation. A user oriented approach is suggested in this paper, that expands the definition of a user and allows hierarchal decomposition of users. Requirements are formed at the elementary level of the users and then composed to upper levels and checked. The checks are done against the real needs of the user community rather then among the requirements themselves. A possible use of automated tools in this process is suggested.

Specification of data restructuring software based on the attribute method

Abstract: The idea that abstract software specification is an essential phase in developing large and complex software has been widely accepted. In this paper, we specify in an abstract, but precise way, software for restructuring data structures based on the flat file and hierarchical data models. Our specification contains also the case that a target data structure is constructed from many source data structures. In data restructuring data structures are transformed. We propose the use of the attribute method for these kinds of translation oriented specification situations in the data base area. We apply the attribute method in the context of abstract syntax instead of a concrete one.

Program transformation and programming environments : report on a workshop directed by F.L. Bauer and H. Remus

Abstract: I: Digest of the Discussions.- 0. Introduction: What Industry Needs - What Research Offers.- 1. Life Cycle Models and Programming Environments.- 1.1 Life Cycle.- 1.2 Programming Environments.- 2. Management & Organization.- 2.1 Quality and Productivity.- 2.1.1 What is "Quality"?.- 2.1.2 How Do We Measure Quality?.- 2.1.3 How Do We Measure Productivity?.- 2.2 Management of Software Development.- 2.2.1 Methods.- 2.2.2 The Role of Domain Knowledge.- 2.2.3 Programmers' Expertise.- 2.3 Maintenance and Version Management.- 3. Formal Methods In Program Development.- 3.1 The Role of Abstraction and (Mathematical) Notation.- 3.2 What Can Be Formally Specified?.- 3.2.1 Expression of Constraints.- 3.2.2 Performance Requirements.- 3.2.3 "Niceness" Properties.- 3.3 Programming as a Formal Activity.- 4. Software Specification.- 4.1 Specifications as a Contract.- 4.2 Real-World Modelling and Requirements Engineering.- 4.2.1 Open vs. Closed Systems.- 4.2.2 Requirements Engineering and Transformations.- 4.3 Equivalence of Specifications.- 4.3.1 Transitions Between Informal and Formal Specifications.- 4.3.2 Changes of Specifications.- 4.4 Methodology of Specification.- 4.4.1 Top-down vs. Bottom-up and Other Dichotomies.- 4.4.2 The Influence of Existing Environments.- 4.4.3 The Role of Design Decisions.- 4.4.4 Impact on Implementations.- 4.4.5 Incomplete Specification vs. Overspecification.- 4.5 Specification Tools and Languages.- 4.5.1 Adequacy of Specification Languages.- 4.5.2 A Need For Several Specification Languages.- 4.5.3 Partially Formalized Specifications.- 4.5.4 Exception Handling.- 4.5.5 The Impact of Semantics.- 5. Program Development by Transformations.- 5.1 Usage of Transformations.- 5.1.1 Understanding and Explaining Algorithms.- 5.1.2 Transformation and Documentation.- 5.1.3 Families of Programs.- 5.1.4 Transformations and Compilers.- 5.2 Language (Independence of Transformations.- 5.2.1 "Transformational" vs. "Active" Programming.- 5.3 Transformation Systems.- 5.3.1 Performance of Transformation Systems.- 5.3.2 Size of Rule Bases.- 5.4 Development Strategies.- 5.5 Managerial Problems of Transformational Programming.- 6. Acceptance of Formal Methods.- 6.1 Range of Application of Formal Methods.- 6.2 Impact on Quality and Productivity.- 6.2.1 Effect of Good and Bad Products.- 6.2.2 Expected Impact of Formal Methods.- 6.3 Social Aspects: Education.- 6.4 How Can Formal Methods Be Brought to Industry?.- 7. Outlook.- 8. Conclusion.- II: Position Statements and Papers.- Coherent Development Methods in an Industrial High-Level Language Environment.- A Systematics of Software Engineering: Structure, Terminology, and Classification of Techniques.- Assessment of Software Quality.- Measuring Software Technology (together with D. N. Card, V. E. Church, G. Page, F. E. McGarry).- Organizational Means to Increase Software Quality.- The Role of Configuration Management.- Understanding and Expressing Software Construction.- Structure-Oriented Programing.- Algebraic Methods for Program Construction: The Project CIP.- Specification and Transformation: Automated Implementation.- Algebraic Techniques for Program Specification.- Verification of Processes Using Program Transformation.- Exception Handling: Formal Specification and Systematic Program Construction (together with M. Bidoit, B. Biebow, C. Gresse, G. Guiho).- Programming with Continuations (together with Ch. T. Haynes, E. Kohlbecker).- Inferential Techniques for Program Development.- Lisp to Fortran - Program Transformation Applied.- Language Comparison by Source-to-Source Translation.- The CIP Transformation System.- Transformation-Based Software Development.- Supercompilers.- Software Development and Inferential Programming.- Program Transformation in the ALICE Project.- From Geological Knowledge to Computational Relationships: A Case Study of the Expertise of Programing (together with R. D. Duffey II).- List of Participants Glossary.

A large system evaluation of SREM

Abstract: A comprehensive evaluation of the Software Requirements Engineering Methodology (SREM) was performed to assess its capabilities for specifying the software requirements of large, embedded computer systems and to recommend improvements which would enhance its effectiveness. Specific evaluation criteria were developed to judge the effectiveness of the methodology, its support tools and user training. The approach included attending a SREM training course and using SREM to specify the software requirements for two Air Force systems. The relatively small number of errors uncovered indicates the effectiveness of disciplined requirements analysis techniques and the capabilities of SREM for exposing subtle problems.In general, it was found that the SREM was an effective vehicle for specifying and analyzing the software requirements of large embedded computer systems, especially descriptions of real world objects, data requirements and message processing. However, deficiencies were noted in the specification language, in the “friendliness” of the user interfaces to the analysis and simulation tools, in the performance of these tools and in the effectiveness of the training. Appropriate improvements to all of the functional deficiencies are recommended.

Concepts and Requirements

Abstract: This chapter goes into the meaning of the word “leasing” and into the distinction between financial and operating leases (Section 2.2). It also discusses five requirements that lease evaluation models have to meet (Section 2.3).

High-level testing and example-directed development of software specifications

Abstract: A testing-based approach for constructing and refining very high-level software functionality representations such as intentions, natural language assertions, and formal specifications is presented and applied to a standard line-editing problem as an illustration. The approach involves the use of specification-based (black-box) test-case generation strategies, high-level specification formalisms, redundant or parallel development and cross-validation, and a logic programming support environment. Test-case reference sets are used as software functionality representations for the purposes of cross-validating two distinct high-level representations, and identifying ambiguities and omissions in those representations. In fact, we propose the use of successive refinements of such test reference sets as the authoritative specification throughout the software development process. Potential benefits of the approach include improvements in user/ designer communication over all life cycle phases, and an increase in the quality of specifications and designs.

Use of Software Engineering Practices at a Small MIS Shop

Abstract: This paper describes the software engineering practices used by the MIS Department at United Technologies Microelectronics Center (UTMC). It describes the life cycle of a software change and the controls established to implement the change. Several software tools used by UTMC to develop and control software development and integration are described as well as methods used to integrate vendor software packages with in-house developed software. A computerized system for tracking and controlling users' modification requests has been developed. Software requirements for a small MIS shop are examined and compared to the requirements for large software development projects.

Flow sketch methodology: A practical requirements definition technique based on data flow concept

Abstract: This paper discusses a new simple methodology for defining software system requirements. We have developed a practical approach which we call FS (Flow Sketch) methodology. This methodology, based on the data flow concept, has been developed to provide the precise means of user's requirements. Actually, the user's requirements are presented in data form by particular format cards. Data are classified and the relationships between data are decided through brainstorming. Then, a requirement definition model is defined. FS methodology employs diagrammatic notation. This notation is suitable for the visual and the interactive description of the dynamic system data flow. As a result, misunderstandings of the software system between the software producer and software user will decrease.

A requirement model for the 5th generation

Abstract: A requirement specification model suitable for the next generation of software development tools is presented. The model uses frames for each entity and relations between entities. The model includes levels and meta-information. The entity-relationship-level of abstraction (E-R-L) viewpoint is explained. Some current requirement methodologies are compared and evaluated in terms of classroom experience. Features of the proposed model are discussed. The relationship between the model and an information base for the whole software life cycle is discussed. An example is presented.

Automatic Generation of Data Flow Diagrams From A Requirements Specification Language

Abstract: Escalating manpower costs in developing systems has caused an increasing need for greater productivity in system development particularly in the analysis and design phases. Productivityinthesystemanalysisphasecanbeincreasedwiththeuseofcomputer-aidedtoolssuch as SPSL/SPSA for specifying system requirements and methodologies such as structured analysis. A structured analysis and documentation tool-the data flow diagram-allows an analyst to model and document a system with relative ease; however, the manual production of a data flow diagram is a time consuming process Combining the production of data flow diagrams with SPSL/SPSA produces a synergistic effect on the increases in productivity and ensures the use of standards andthe completenessof the diagram. This paperdescribes the problems and design of the systemMONDRIAN that generates data flow diagrams from an SPSA database. A variety of placement and routing algorithms that address the layout problem are discussed. The resultsof apreliminary studyof the effectivenessofthese algorithms and the adaptations required to improve and refine the prototype version of MONDRIAN are presented Introduction SPSL/SPSA is essentially a subset of the PSL/PSA system that has been developed as part of the ISDOS As improvements in productivity in later phases of the project at the University of Michigan ('Ibichroew and system life cycle are achieved, the need increases for Hershey, 1977). The defined subset was derived based computer-aided analysis *tools which improve produconananalysisofthemostpopularfeaturesofPSL/PSA tivityintheanalysis phase. This paperis concernedwith that were used by practicing systems analysts (Perkins, the development of such a tool 1979; Wig, 1979(a)). Another major project that has stressed the development of computer-aided analysis A structured analysis and documentation aidthe data tools is the PLEXSYS project at the University of flow diagram (DFD)-allows an analyst to model and Arizona (Nunamaker and Konsynski, 1981). Both the document a system easily. However, producing a layout ISDOS and PLEXSYS projects have examined the for a data flow diagram manually is a time consuming problem of integrating structured systems analysis problem. An analyst's productivity can be increased if a methodologies (e.g., Gane and Sarson, 1979, and dataflowdiagramwereautomaticallyproducedfromthe DeMarco, 1979) with their systems. Neither project has logical structure of the requirements definition. One handled the problem of automatically producing data facility for producing such a definition is SPSL/SPSA flow diagrams in a satisfactory manner. meaning Simple Problem Statement Language/Simple Problem Statement Analyzer (Friesen et aL, 1981). This paper addresses the problem of automatically SPSL/SPSA is a structured analysis and documentagenerating a layout for a data flow diagram from an tion aid that allows a user to define formally the logical SPSA database. A system called MONDRIAN (Protsko, structure and requirements of an information system, 1983) accesses an SPSA database to retrieve system store this description in a database, and later produce flowinformationandgeneratesthedataflowdiagramfor from the database various documentsandreports about the system. This paper outlines the design, and implethe system structure and requirements. mentation of placement and routing algorithms to be

Utilizing an executable specification language for an information system

Abstract: This paper describes an approach to software specification development with interpretation as applied to an information storage and retrieval system Machine execution of software specifications is possible with both partial and complete specifications A partial specification is interpreted using abstract execution The Descartes specification language is utilized to describe a functional aspect of an existing information storage and retrieval system, namely, the MADAM (Multics Approach to Data Access and Management) system at the University of Southwestern Louisiana Brief descriptions of both the Descartes language and the MADAM system precede the example specification The paper concludes with a discussion of the expected results that this methodology could have on the pragmatic development and evolution of information systems

The specification of timing requirements for real-time systems using timed petri nets

Abstract: Real-time systems are considered successful by correctly executing their intended functions within critical time constraints. Thus, their requirements specifications must address the execution time requirements for system processes. This dissertation develops a formal methodology for specifying the timing requirements for a real-time system in terms of process execution times. A Petri net model that uses places to represent system processes is extended by augmenting these places with time variables representing process execution times. The concept of "time-safeness" of places is introduced to specify how places not inherently safe by the net structure may be safe in the presence of timing information. The modular modeling methodology permits the hierarchical specification of sequential, alternative, iterative, and parallel activities, as well as the mutually exclusive sharing of system resources. Mathematical representations of the modular transformations are given corresponding to the graphical representations, so that a mathematical model is maintained throughout the graphical modeling process. The modularity of the transformations ensures that the net remains analyzable for timing requirements purposes and guarantees freedom from deadlock. The ability to integrate graphical data flow specifications with the control and timing specifications is also demonstrated. System timing requirements are stated as the conditions under which all places in the net will be time-safe. The modifications to system timing requirements caused by each transformation are precisely stated and rigorously proven, so that a formal specification of timing requirements that is derived from user-stated system level requirements evolves with the system model. The concept of a time-driven system is introduced that includes a special cyclic construction that acts as a master system clock. The utility of the timing requirements specification in the feasibility testing of target process execution times and in the refinement of these targets as some actual execution times become available is illustrated. Several examples of the development of timing requirements are given, including communication protocol and process control system applications. A comprehensive detailed example for a scientific data acquisition system is presented that demonstrates the practicality of the formal methodology for a real-world system.

Components of the system: future design requirements.

Abstract: A few ideas about future design concepts have been outlined and highlighted. Whether anesthetists will accept it or not, automation is the direction of the future, and data processing is increasingly important. Anesthesiology and industry need to initiate total cooperative efforts for appropriate implementation of modern technology.