Showing papers on "Software requirements specification published in 1996"

Automated consistency checking of requirements specifications

Abstract: This article describes a formal analysis technique, called consistency checking, for automatic detection of errors, such as type errors, nondeterminism, missing cases, and circular definitions, in requirements specifications. The technique is designed to analyze requirements specifications expressed in the SCR (Software Cost Reduction) tabular notation. As background, the SCR approach to specifying requirements is reviewed. To provide a formal semantics for the SCR notation and a foundation for consistency checking, a formal requirements model is introduced; the model represents a software system as a finite-state automation which produces externally visible outputs in response to changes in monitored environmental quantities. Results of two experiments are presented which evaluated the utility and scalability of our technique for consistency checking in real-world avionics application. The role of consistency checking during the requirements phase of software development is discussed.

Goal-based requirements analysis

Abstract: Goals are a logical mechanism for identifying, organizing and justifying software requirements. Strategies are needed for the initial identification and construction of goals. We discuss goals from the perspective of two themes: goal analysis and goal evolution. We begin with an overview of the goal-based method we have developed and summarize our experiences in applying our method to a relatively large example. We illustrate some of the issues that practitioners face when using a goal-based approach to specify the requirements for a system and close the paper with a discussion of needed future research on goal-based requirements analysis and evolution.

Identifying quality-requirement conflicts

Abstract: Without a well-defined set of quality-attribute requirements, software projects are vulnerable to failure. The authors have developed QARCC, a knowledge-based tool that helps users, developers, and customers analyze requirements and identify conflicts among them.

Model checking large software specifications

Abstract: In this paper we present our results and experiences of using symbolic model checking to study the specification of an aircraft collision avoidance system. Symbolic model checking has been highly successful when applied to hardware systems. We are interested in the question of whether or not model checking techniques can be applied to large software specifications.To investigate this, we translated a portion of the finite-state requirements specification of TCAS II (Traffic Alert and Collision Avoidance System) into a form accepted by a model checker (SMV). We successfully used the model checker to investigate a number of dynamic properties of the system.We report on our experiences, describing our approach to translating the specification to the SMV language and our methods for achieving acceptable performance in model checking, and giving a summary of the properties that we were able to check. We consider the paper as a data point that provides reason for optimism about the potential for successful application of model checking to software systems. In addition, our experiences provide a basis for characterizing features that would be especially suitable for model checkers built specifically for analyzing software systems.The intent of this paper is to evaluate symbolic model checking of state-machine based specifications, not to evaluate the TCAS II specification. We used a preliminary version of the specification, the version 6.00, dated March, 1993, in our study. We did not have access to later versions, so we do not know if the properties identified here are present in later versions.

Beyond the black box: open implementation

Abstract: Encapsulation, informally known as black-box abstraction, is a widely known and accepted principle. It is a basic tenet of software design, underlying approaches to portability and reuse. However, many practitioners find themselves violating it in order to achieve performance requirements in a practical manner. The gap between theory and practice must be filled. Open implementation is a controversial new approach that claims to do just that. The paper provides some ideas to spark further debate on black-box abstraction.

A design environment and a design method for hardware/software co-design

Abstract: A hardware and software co-design environment and design methodology based on a data-model that allows one to specify, simulate, and synthesize heterogeneous hardware and software architectures from a heterogeneous specification. The environment and methodology of the invention allow for the interactive synthesis of hardware and software interfaces. The environment defines primitive objects to represent a specification of an essentially digital system. The primitive objects are defined by describing the specification of the system in one or more processes, each process representing a functional aspect of the system. Further, each of the processes have ports which are connected to ports of other processes with a channel. The ports structure communication between the processes.

Software requirements prioritizing

Abstract: The importance of candidate software requirements can vary by orders of magnitude, yet most software providers do not have accurate and efficient means for selecting among them. The paper describes a case study at Ericsson Radio Systems AB of two techniques for software requirements prioritizing as a means for determining the importance of candidate requirements, a pairwise comparison technique and a numeral assignment technique. The results from the case study indicate that the pairwise comparison technique is an efficient informative and accurate means for finding the candidate requirements importance. We therefore recommend the pairwise comparison technique for software requirements prioritizing. At Ericsson we have extended its use in other development projects.

Communication Problems in Requirements Engineering: A Field Study

Abstract: The requirements engineering phase of software development projects is characterized by the intensity and importance of communication activities. During this phase, the various stakeholders must be able to communicate their requirements to the analysts, and the analysts need to be able to communicate the specifications they generate back to the stakeholders for validation. This paper describes a field investigation into the problems of communication between disparate communities involved in the requirements specification activities. The results of this study are discussed in terms of their relation to three major communication barriers: (1) ineffectiveness of the current communication channels; (2) restrictions on expressiveness imposed by notations; and (3) social and organizational barriers. The results confirm that organizational and social issues have great influence on the effectiveness of communication. They also show that in general, end-users find the notations used by software practitioners to model their requirements difficult to understand and validate.

Applying formal specification in industry

Abstract: Industrial software developers confront a bewildering array of software engineering techniques, each with its own promised benefits. The authors introduced formal methods into the specification and modeling activities of a security-critical system's development. They gauged the methods' effectiveness by comparing the results of the group that used them with those of the group that did not. They present their results in this paper.

Software package requirements and procurement

Abstract: This paper outlines the problems of specifying requirements and deploying these requirements in the procurement of software packages. Despite the fact that software construction de novo is the exception rather than the rule, little or no support for the task of formulating requirements to support assessment and selection among existing software packages has been developed. We analyse the problems arising in this process and review related work. We outline the key components of a programme of research in this area.

Processing natural language software requirement specifications

Abstract: Ambiguity in requirement specifications causes numerous problems; for example in defining customer/supplier contracts, ensuring the integrity of safety-critical systems, and analysing the implications of system change requests. A direct appeal to formal specification has not solved these problems, partly because of the restrictiveness and back of habitability of formal languages. An alternative approach, described in the paper, is to use natural language processing (NLP) techniques to aid the development of formal descriptions from requirements expressed in controlled natural language. While many problems in NLP remain unsolved, we show that suitable extensions to existing tools provide a useful platform for detecting and resolving ambiguities. Our system is demonstrated through a case-study on a simple requirements specification.

Linguistic Instruments in Requirements Engineering

Abstract: From the Publisher: The book discusses a new approach to requirements engineering. The goal of the method described is to facilitate the requirements engineering process and to improve the quality of its results. The focus of the book is on how linguistic instruments can be used profitably in this process, in order to reach this goal. The book gives a rather complete overview of the current status of requirements engineering, including (object-oriented) software analysis, and of applications of natural language to information systems in general. The improvements to the requirements engineering process include a better understanding of the problem and its domain, expressed by abstract models upon the contents of which the users (i.e. the 'owners' of the problem) have agreed. The process of collecting, specifying, verifying and validating the contents of the models is elaborated extensively. The linguistic meaning and definition of the words and concepts, that are selected from the Universe of Discourse description by a natural language- and scenario-based analysis approach, provides a semantically correct base for both the requirements specification and requirements validation. Some well-known problems with natural language texts, like ambiguity and incompleteness, are avoided by this semantic approach. The word meanings are retrieved from a lexicon that is interactively consulted during the requirements engineering process. The formal language that has been introduced as the underlying representation formalism for the lexicon, the models, as well as the original natural language sentences gives possibilities for verification activities, because of its logic foundation. Two models are introduced that arevalidated by the users by checking natural language sentences that are equivalent to the models' contents, and by evaluating a prototype that simulates the modeled behaviour of the system. Summarizing, the book introduces a requirements engineering method which makes heavily use of linguistic instruments. The method is described from several viewpoints, which includes its philosophy (the way of thinking), its techniques (the way of modeling), its use (the way of working) and a sketch of its supporting environment, (the way of supporting).

Specifying software quality with the extended ISO model

Abstract: Specifying the quality of software products is a valuable addition to functional specification, clarifying product properties such as learnability and availability. Specifying such properties is considered difficult due to the different parties involved and the implicit nature of the requirements. The QUINT project gathered experience with product specification by means of the Extended ISO model: an extension to the ISO 9126 model of software quality. By defining indicators and specifying how they should be measured, quality specifications can make requirements explicit. Recommendations and pitfalls for composing a specification are grouped by the context in which quality specifications can be used.

Software qualification of selected TOUGH2 modules

Abstract: The purpose of this package of reports is to provide all software baseline documents necessary for the software qualification of the single-phase Gas (EOS1G), Effective Continuum Method (ECM), Saturated/Unsaturated Flow (EOS9), and Radionuclide Transport (T2R3D) modules of TOUGH2, a numerical simulation code for multi-dimensional coupled fluid and heat flow of multiphase, multicomponent fluid mixtures in porous and fractured media. This report contains the following sections: (1) Requirements Specification, (2) Design Description, (3) Software Validation Test Plan and Report, (4) Software User Documentation, and (5) Appendices. These sections comprise sequential parts of the Software Life Cycle, and are not intended to stand alone but should be used in conjunction with the TOUGH User`s Guide (Pruess, 1987), TOUGH2--A General Purpose Numerical Simulator for Multiphase Fluid and Heat Flow (Pruess, 1991), and the above-referenced TOUGH2 software qualification document. The qualification package is complete with the attached Software Identification Form and executable source code for the single-phase Gas, Effective Continuum method, Saturated/Unsaturated Flow, and Radionuclide Transport modules of TOUGH2.

An analytic framework for specifying and analyzing imprecise requirements

Abstract: There are at least three challenges with requirements analysis. First, it needs to bridge informal requirements, which are often vague and imprecise, to formal specification methods. Second, requirements often conflict with each other. Third, existing formal requirement specification methodologies are limited in supporting trade-off analysis between conflicting requirements and identifying the impact of a requirement change to the rest of the system. In this paper, an analytic framework is developed for the specification and analysis of imprecise requirements. In this framework, the elasticity of imprecise requirements is captured using fuzzy logic and the relationships between requirements are formally classified into four categories: conflicting, cooperative, mutually exclusive and irrelevant. This formal foundation facilitates the inference of relationships between requirements for detecting implicit conflicts, to assess the relative priorities of requirements for resolving conflicts, and to assess the effect of a requirement change.

Object-oriented technology for real-time systems

Abstract: 1. Introduction. Real-time Systems. Object-Oriented Methods. Concurrency in a Real- time System. Object-Oriented Concurrency Models. Levels of Concurrency. Design Criteria of OCTOPUS. Introduction to Case Studies. 2. Overvoew of the Octopus Method. Roadmap and Structuring the Development Process. System Requirements Phase. System Architecture Phase. Subsystem Analysis Phase. Subsystem Design Phase. Subsystem Implementation Phase. 3. Requirements Specification. Use Cases. Use Case Diagram. System Context Diagram. 4. System Architecture. Modular Structure. Early Division into Subsystems. Subsystems Diagram. Incremental Development. Interfaces. Example. 5. Analysis Phase. Object Model. Functional Model. Dynamic Model. Analysis of the Hardware Wrapper. Summary. 6. Design Phase. Design Objects. Interaction of Objects. Class Outlines. Design of Concurrency. Outlines of Processes and Messages. Design of the Hardware Wrapper. Summary. 7. Process Priorities and Timing. Basic Concepts. Deriving Process Priorities. Timing and Concurrency Behavior. 8. Transition from Design to Implementation. C++ and C Interpretability. Member Access Control. Visibility. Memory and Performance Optimization. Synchronization. Implementing Statecharts. Constructing Global Objects. Development Environment. 9. Case Study: Subscriber Line Tester. System Requirements Specification. SLT Application Subsystem Analysis. SLT Application Subsystem Design. Exercise: Hardware Wrapper. 10. Case Study: Cruise Control. Recapped System Requirements Specification. Application Subsystem Analysis. Analysis and Design of the Hardware Wrapper. Design of Application Subsystem. 11. Referemce Manual. Notation Summary. Case Tools. OCTOPUS Roadmap. References. Glossary. Index.

Feasibility of model checking software requirements: a case study

Abstract: Model checking is an effective technique for verifying properties of a finite specification. A model checker accepts a specification and a property, and it searches the reachable states to determine if the property is a theorem of the specification. Because model checking examines every state of the specification, it is a more thorough validation technique than testing executable specifications. However, some researchers question the feasibility of model checking, because the size of a specifications state-space grows exponentially with respect to the number of variables in the specification. This paper demonstrates the feasibility of symbolically model checking a non-trivial specification: the software requirements of the A-7E aircraft. The A-7E requirements document lists five properties that the designers manually derived from the requirements. Using McMillan's (1992) Symbolic Model Verifier, we were able to verify or find a counterexample to each property in less than 10-15 CPU minutes. In particular, we found that an important safety property did not hold.

A logic-model semantics for SCR software requirements

Abstract: This paper presents a simple logic-model semantics for Software Cost Reduction (SCR) software requirements. Such a semantics enables model-checking of native SCR requirements and obviates the need to transform the requirements for analysis. The paper also proposes modal-logic abbreviations for expressing conditioned events in temporal-logic formulae. The Symbolic Model Verifier (SMV) is used to verify that an SCR requirements specification enforces desired global requirements, expressed as formulae in the enhanced logic. The properties of a small system (an automobile cruise control system) are verified, including an invariant property that could not be verified previously. The paper concludes with a discussion of how other requirements notations for conditioned-event-driven systems could be similarly checked.

From specification validation to hardware testing: a unified method

Abstract: With the great advancement in the design automation field, actual tools allow to describe hardware systems as software programs using high-level hardware description languages such as VHDL or VERILOG. Consequently, a design fault which affects the system specification can be considered as a software fault. To test the system specification against (software) design faults, we propose in this paper an adaptation of the mutation analysis, originally proposed for software testing, to test VHDL functional descriptions. The resulted test set is applied on the gate-level structure of the system to measure its capacity to uncover hardware faults such as the stuck-at faults. Heuristics to enhance the test set in order to be sufficient for testing hardware faults are presented and results are compared to traditional ATPGs. Accordingly, this paper presents a unified method for testing both the system specification and the hardware implementation.

Software requirements specification database based on requirements frame model

Abstract: The author proposes a method to build a relational database of software requirements specifications (SRSs) from textual SRSs automatically. The author has been developing a requirements model called requirements frame and a text-base requirements language based on the model in order to improve the quality of SRSs. Since requirements frame can be transformed into a relational data model, each of the requirement sentences can be regarded as a tuple of a relational table. The author has been developing both a query language and a relational database management system for on SRS database. One of the features of the SRS DB system is to give an answer with a requirement sentence as an example/counter-example. This feature contributes to verification of the SRS from a developer's own viewpoint. Another feature is detecting changed requirements in modification of the SRS. This feature contributes to effective maintenance of the SRS.

Synthesis of communications protocols: an annotated bibliography

Abstract: Protocol synthesis attempts to formalize and automate the process of designing communications protocols. Protocol design is an important step in the communications software or protocol engineering development process. Protocol synthesis has been addressed extensively by many researchers around the world, and various approaches have been proposed: from the stepwise refinement of a high level requirements specification to the automatic generation starting from a formal service specification. In this paper, we introduce protocol synthesis in the context of the protocol engineering process, and we briefly describe and survey the main features of the proposed synthesis methods. Tables summarizing this survey are also provided.

Executing formal specifications need not be harmful

Abstract: The various arguments that have been advanced for and against the use of executable specifications are reviewed. Examples are provided of the problems that may arise in applying this technique and of the benefits which may accrue. A case study is reported in which execution is used to validate the published specification of a commercially available package. It is concluded that there are circumstances when executable specifications can be of high value but that execution must be used together with, and as a supplement to, other methods of validating specifications such as inspection and proof.

A model for a causal logic for requirements engineering

Abstract: The language of causation is natural for the specification of requirements for complex systems. The paper provides a vocabulary of causal specification expressions, suitable for describing and analysing such systems. The notation is given a syntax and partial semantics. It covers many of the commonly used modes of causal language including necessary and sufficient cause, prevention and enabling conditions. The concept of condition splitting is introduced, enabling a specification at an abstract level to treat two conditions as identical, while a concrete refinement of it may view them as separate. A number of other issues are examined, including: repetitive, probabilistic and hidden causes; causal agents; the validation of causal descriptions; and concurrency. Possible approaches to development of causal specifications are discussed. The work is placed in the context of related work in artificial intelligence and philosophy. The detailed framework of the paper is supported by a realistic example.

An Introduction to Requirements Capture Using PVS: Specification of a Simple Autopilot

Abstract: This paper presents an introduction to capturing software requirements in the PVS formal language. The object of study is a simplified digital autopilot that was motivated in part by the mode control panel of NASA Langley''s Boeing 737 research aircraft. The paper first presents the requirements for this autopilot in English and then steps the reader through a translation of these requirements into formal mathematics. Along the way deficiencies in the English specification are noted and repaired. Once completed, the formal PVS requirement is analyzed using the PVS theorem prover and shown to maintain an invariant over its state space.

Nonfunctional Requirements of Real-Time Systems

Abstract: A requirements specification typically contains both functional and nonfunctional requirements. Whereas functional requirements address the system's inputs, outputs, and their behavioral interrelationships, nonfunctional requirements define the general qualities of the intended product. The properties of six of the most important nonfunctional requirements for real-time systems are analyzed: timing, reliability, safety, security, usability, and maintainability. For each type of requirement, we define the term, contrast it to other nonfunctional requirements, define how to measure it, define techniques of how to assure its presence, and discuss how to specify the requirement in a requirements specification.

The configuration design ontologies and the VT elevator domain theory

Abstract: In the VT/Sisyphus experiment, a set of problem solving systems were being built against a common specification of a problem. An important hypothesis was that the specification could be given, in large part, as a common ontology. This article is that ontology. This ontology is different than normal software specification documents in two fundamental ways. First, it is formal and machine readable (i.e. in the KIF/Ontolingua syntax). Second, the descriptions of the input and output of the task to be performed include domain knowledge (i.e. about elevator configuration) that characterize semantic constraints on possible solutions, rather than describing the form (data structure) of the answer. The article includes an overview of the conceptualization, excerpts from the machine-readable Ontolingua source files, and pointers to the complete ontology library available on the Internet.

Architecture-based software testing

Abstract: Jn recent years the study of So&are Architecture emerged as an autonomous discipline in the software engineering field which requires its own concepts, formalisms, methods and tools [9, 3, 4, 7, 81. The softwze architecture of a large complex system supplies information about how the software is structured in parts and how those parts interact. Besides the static characteristics of a system, Software Architectures require the ability to describe dynamics at a relevant level of abstraction as well as the ability of expressing extra-functional requirements. As the complexity of software systems increases, the importance of Software Architectures becomes evident for the analyis, design and construction of the overall system structure. Testing is one of the most expensive activity in the development of complex software systems and represents a mandatory activity to improve the dependability of complex software systems. Traditionally, the testing of large software systems proceeds in subsequent steps following the well-known V model: unit, integration and system test, which correspond in bottom-up order to the code, design and specification stages of the development part of the lifecycle, (proceeding conversely in top-down fashion). This model, descending directly from the functional decomposition principle, allows testers to master the inherent complexity of the task, by subdividing the testing activity into smaller, more manageable pieces, and also enforces a rigorous, disciplined procedure. However, this approach suffers of some drawbacks:

Signature and specification matching

Abstract: Large libraries of software components hold great potential as a resource for software engineers, but to utilize them fully, we need to be able: (1) to locate components in the library; (2) to organize the library in a way that facilitates browsing and improves e ciency of retrieval; and (3) to compare the description of a library component to the description of what we want. A key requirement in all of these problems is to be able to compare two software components to see whether they match. In this dissertation, we consider two di erent kinds of semantic descriptions of components to determine whether components match: signatures (type information) and speci cations (behavioral information). Semantic descriptions o er advantages over either textual descriptions, such as variable names, or structural descriptions, such as control ow graphs. Using semantic information focuses on what the components do rather than how they do it. Signatures and speci cations are natural ways of describing software components and have well-understood properties, such as type equivalence and logical relations between formal speci cations, that enable us both to de ne matches precisely and to automate the match. This dissertation makes the following contributions: Foundational. Within a general, highly modular, and extensible framework, we de ne matching for two kinds of semantic information (signatures and speci cations) and two granularities of components (functions and modules). Each kind of matching has a generic form, within which all of the matches are related and may, in some cases, be composed. The orthogonality of the matches allows us to de ne match on modules independently of the particular match used on functions in the modules. Applications. We show how the de nitions of matching can be applied to the problems of retrieval from libraries, indexing libraries, and reuse of components. We demonstrate the various signature and speci cation matches with examples of typical uses in each application. Engineering. We describe our implementations of function and module signature match, function speci cation match, function signature-based indexing, and function signaturebased retrieval. These implementations demonstrate the feasibility of our approach and allow us to illustrate the applications with results from a moderately-sized component library.

A Web-based requirements analysis tool

Abstract: The Goal Based Requirements Analysis Tool (GBRAT) is designed to support goal based requirements analysis. We discuss the GBRAT prototype which provides procedural support for the identification, elaboration, refinement and organization of goals to specify the requirements for software based information systems. GBRAT employs interactive Web browser technology to support the collaborative nature of requirements engineering. We illustrate the features of the tool and close the paper with a discussion of future anticipated research.