Showing papers in "Requirements Engineering in 1995"
TL;DR: It is argued that the results of requirements monitoring can be of benefit to the designers, maintainers and users of a system-alerting them when the system is being used in an environment for which it was not designed, and giving them the information they need to direct their redesign of the system.
Abstract: We propose requirements monitoring to aid in the maintenance of systems that reside in dynamic environments. By requirements monitoring we mean the insertion of code into a running system to gather information from which it can he determined whether, and to what degree, that running system is meeting its requirements. Monitoring is a commonly applied technique in support of performance tuning, but the focus therein is primarily on computational performance requirements in short runs of systems. We wish to address systems that operate in a long lived, ongoing fashion in nonscientific enterprise applications. We argue that the results of requirements monitoring can be of benefit to the designers, maintainers and users of a system-alerting them when the system is being used in an environment for which it was not designed, and giving them the information they need to direct their redesign of the system. Studies of two commercial systems are used to illustrate and justify our claims.
319 citations
TL;DR: The objective of the paper is to assess the strengths and weaknesses of one of these methodologies on a nontrivial benchmark; and to illustrate and discuss a number of challenging issues that need to be addressed for such methodologies to become effective in supporting real, complex requirements engineering tasks.
Abstract: Recently a number of requirements engineering languages and methods have flourished that not only address 'what' questions but also 'why', 'who' and 'when' questions. The objective of the paper is twofold: to assess the strengths and weaknesses of one of these methodologies on a nontrivial benchmark; and to illustrate and discuss a number of challenging issues that need to be addressed for such methodologies to become effective in supporting real, complex requirements engineering tasks. The problem considered here is that of a distributed meeting scheduler system; the methodology considered is the KAOS goal directed language and method. The issues raised from this case study include goal identification, the "deidelization" of unachievable goals, the handling of interfering goals, the impact of early formal reasoning, the merits of early reuse of abstract descriptions and categories, requirements traceability and the need to link requirements to retractable assumptions, and the potential benefits of hybrid acquisition strategies.
290 citations
TL;DR: A field study to formulate recommendations to practitioners for improving requirements engineering processes, and to provide directions for future research on methods and tools indicates that there are seven key issues of greatest concern in requirements engineering practice.
Abstract: To make recommendations for improving requirements engineering processes, it is critical to understand the problems faced in contemporary practice. We describe a field study whose general objectives were to formulate recommendations to practitioners for improving requirements engineering processes, and to provide directions for future research on methods and tools. The results indicate that there are seven key issues of greatest concern in requirements engineering practice. These issues are discussed in terms of the problems they represent, how these problems are addressed successfully in practice, and impediments to the implementation of such good practices.
187 citations
TL;DR: A class of formal analysis called consistency checking that mechanically checks requirements specifications, expressed in the SCR tabular notation, for application independent properties, for domain coverage, type correctness, and determinism is described.
Abstract: The paper describes a class of formal analysis called consistency checking that mechanically checks requirements specifications, expressed in the SCR tabular notation, for application independent properties. Properties include domain coverage, type correctness, and determinism. As background, the SCR notation for specifying requirements is reviewed. A formal requirements model describing the meaning of the SCR notation is summarized, and consistency checks derived from the formal model are described. The results of experiments to evaluate the utility of automated consistency checking are presented. Where consistency checking of requirements fits in the software development process is discussed.
142 citations
TL;DR: A case study of a systems development organization employing a comprehensive view of traceability, a model describing the traceability practice in the organization, perceived benefits of such a scheme and lessons learnt from implementing it are presented.
Abstract: Many standards that mandate requirements traceability as well as current literature do not provide a comprehensive model of what information should be captured and used as a part of a traceability scheme. Therefore, the practices and usefulness of traceability vary considerably across systems development efforts, ranging from very simplistic practices just aimed at satisfying the mandates to very comprehensive traceability schemes used as an important tool for managing the systems development process. We present a case study of a systems development organization, employing a comprehensive view of traceability. A model describing the traceability practice in the organization, perceived benefits of such a scheme and lessons learnt from implementing it are presented.
135 citations
TL;DR: The requirements engineering research and consulting communities are not serving the interests of software developers who build off-the-shelf application software, and some alternative priorities are suggested that would address these shortcomings.
Abstract: The requirements engineering research and consulting communities are not serving the interests of software developers who build off-the-shelf application software. Most of our models and methods evolved with the aid of funding from organizations interested in obtaining unique systems under contract and in which there is a clear interface between "customer" and "developer". These origins have spawned many assumptions about what requirements are. Through several design scenarios I illustrate how these assumptions break down in the case of off-the-shelf software. I then suggest some alternative priorities that would address these shortcomings. My aim is to provoke and stimulate thought, not to propose a developed solution.
133 citations
TL;DR: The idea of usage oriented requirements engineering, an extension of use case driven analysis, is presented, resulting in a model which captures both functional requirements and system usage aspects in a comprehensive manner.
Abstract: The paper presents the idea of usage oriented requirements engineering, an extension of use case driven analysis. The main objective is to achieve a requirements engineering process resulting in a model which captures both functional requirements and system usage aspects in a comprehensive manner. The paper presents the basic concepts and the process of usage oriented requirements engineering, and the synthesized usage model resulting from this process. The role of this model in system development, and its potential applications are also discussed.
127 citations
TL;DR: This work focuses on developing a novel approach to the presentation of ethnographic material based on the use of number of viewpoints and is embodied within a general hypertext tool.
Abstract: We argue that the industrial development of interactive systems has to recognise the social dimension of work if these systems are to fully meet the real needs of their users. Under current approaches this depends on whether an individual requirements engineer implicitly applies a user centred approach, recognises the importance of cooperation and is sufficiently sympathetic and intuitive to understand the work and reflect this in the system requirements. We wish to move beyond this by allowing for the provision of a more systematic incorporation of the social dimensions of work. To this end we focus on developing a novel approach to the presentation of ethnographic material. Our approach is based on the use of number of viewpoints and is embodied within a general hypertext tool.
108 citations
TL;DR: This work explicitly recording relationships between partial specifications (ViewPoints), representing both resolved and unresolved inconsistencies, assumes that ViewPoints will often be inconsistent with one another, and ensures that a complete work record is kept.
Abstract: In an evolving specification, considerable effort is spent handling recurrent inconsistencies. Detecting and resolving inconsistencies is only part of the problem: a resolved inconsistency might not stay resolved. Frameworks in which inconsistency is tolerated help by allowing resolution to be delayed. However, evolution of a specification may affect both resolved and unresolved inconsistencies. We address these problems by explicitly recording relationships between partial specifications (ViewPoints), representing both resolved and unresolved inconsistencies. We assume that ViewPoints will often be inconsistent with one another, and we ensure that a complete work record is kept, detailing any inconsistencies that have been detected, and what actions, if any, have been taken to resolve them. The work record is then used to reason about the effects of subsequent changes to ViewPoints, without constraining the development process.
99 citations
TL;DR: It is shown how a historical record of the treatment of NFRs during the development process can also serve to systematically support evolution of the software system.
Abstract: Non-functional requirements (or quality requirements, NFRs) such as confidentiality, performance and timeliness are often crucial to a software system. Our NFR-framework treats NFRs as goals to be achieved during the process of system development. Throughout the process, goals are decomposed, design tradeoffs are analysed, design decisions are rationalised, and goal achievement is evaluated. This paper shows how a historical record of the treatment of NFRs during the development process can also serve to systematically support evolution of the software system. We treat changes in terms: of (i) adding or modifying NFRs, or changing their importance, and (ii) changes in design decisions or design rationale. This incremental approach is illustrated by a study of changes in banking policies at Barclays Bank.
89 citations
TL;DR: This paper presents an approach based on modelling the dynamic contribution structures underlying requirements artifacts, which shows how these structures can be defined, using information about the agents who have contributed to artifact production, in conjunction with details of the numerous traceability relations that hold within and between artifacts themselves.
Abstract: The invisibility of the individuals and groups that gave rise to requirements artifacts has been identified as a primary reason for the persistence of requirements traceability problems. The paper presents an approach based on modelling the dynamic contribution structures underlying requirements artifacts, which addresses this issue. It shows how these structures can be defined, using information about the agents who have contributed to artifact production, in conjunction with details of the numerous traceability relations that hold within and between artifacts themselves. It further outlines how the approach can be implemented, demonstrates the potential it provides for "personnel-based" requirements traceability, and discusses issues pertinent to its uptake.
TL;DR: A number of essential problems of software requirements engineering, related to management, organisations, users, stakeholders, methodology, tools, and education are discussed.
Abstract: We discuss a number of essential problems of software requirements engineering, related to management, organisations, users, stakeholders, methodology, tools, and education. Most of the problems seem to have their roots in how requirements engineering is appreciated at the business management and IT management levels.
TL;DR: It is contention that requirements documentation need to break away from the fixation with purely textual documents to ones that are media rich, such as the hypermedia Scenario Manager.
Abstract: A study of requirements elicitation and validation within an industrial environment is reported. The key features in this part of the requirements process are: scenarios, as the prime means of elicitation; identification of domain objects, to capture the language of the domain and Fagan inspections for scenario validation by stakeholders. The process has been evaluated from both the requirements engineer's perspective and the viewpoint of the various stakeholders. The findings highlight a number of issues, both positive and negative, which are discussed. The deficiencies identified have stimulated our research. In particular it is our contention that requirements documentation need to break away from the fixation with purely textual documents to ones that are media rich. Examples of this research, such as the hypermedia Scenario Manager are described.
TL;DR: A proposal for organizing requirements statements as a model, where change and evolution are taken into consideration, is reported, which uses natural language statements as its basic representation, which helps the communication between clients and software engineers.
Abstract: Traceability, a major issue in software engineering, is seldom present at the initial requirements engineering process. The paper reports a proposal for organizing requirements statements as a model, where change and evolution are taken into consideration. The model uses natural language statements as its basic representation, which helps the communication between clients and software engineers. The model is supported by a customized software system for which a prototype was built and used in an industrial setting.
TL;DR: Evidence is presented demonstrating that the instrument developed consists of 32 indicators that cover the two most important dimensions of requirements engineering success, and has desirable psychometric properties, such as high reliability and validity.
Abstract: Central to understanding and improving requirements engineering processes is the ability to measure requirements engineering success. The paper describes a research study whose objective was to develop an instrument to measure the success of requirements engineering processes. The instrument developed consists of 32 indicators that cover the two most important dimensions of requirements engineering success. These two dimensions were identified during the study to be: quality of requirements engineering products and quality of requirements engineering service. Evidence is presented demonstrating that the instrument has desirable psychometric properties, such as high reliability and validity.
TL;DR: The article proposes and justifies a trial classification scheme for requirements engineering that addresses the heterogeneity of the topics usually considered part of requirements engineering, and settles on two dimensions.
Abstract: The article proposes and justifies a trial classification scheme. An earlier version was used to organize the papers submitted to this symposium, and the scheme has been refined somewhat in response to inadequacies discovered during the process of selecting the program. The first issue to be tackled is the heterogeneity of the topics usually considered part of requirements engineering. They include: tasks that must be completed; problems that must be solved; solutions to problems; ways of contributing to knowledge; and types of system. There seems to be a need for several orthogonal dimensions of classification. While multiple dimensions certainly help us cope with the heterogeneity of concerns, there is a danger of making the classification scheme too complex to use. I have compromised by settling on two dimensions.
TL;DR: An approach to deriving and applying human error tolerance requirements and uses a software engineering notation to provide the bridge between operator models and systems engineering concerns to capture a more complex set of human error forms.
Abstract: We put forward an approach to deriving and applying human error tolerance requirements. Such requirements are concerned with the response of a system to errors introduced by human operators. The approach provides a means by which operators' tasks can be described and analysed for likely errors and the impact of these errors on system safety can be explored. The approach, based on previous work by the same authors (P. Wright et al., 1994), uses a software engineering notation to provide the bridge between operator models and systems engineering concerns. The approach is extended to include a more refined understanding of the processes that contribute to human error. The operators' process in achieving goals is understood in terms of structured tasks. With this additional apparatus we are able to capture a more complex set of human error forms.
TL;DR: Requirements, specifications, and programs are distinguished by the phenomena they concern and describe properties of the domain that the machine is required to bring about and maintain.
Abstract: Requirements, specifications, and programs are distinguished by the phenomena they concern. Requirements are about phenomena of the application domain and describe properties of the domain that the machine is required to bring about and maintain. The application domain is informal, and serious difficulties are encountered both in describing it and in reasoning about it. Requirements are complex, so they must be decomposed. Decomposition is based on the recognition of simple subproblems, characterised by problem frames.
TL;DR: Emphasis is given to the way in which requirements traceability interacts with the key features of the environment: generic, fine-grained design information management that permits users to quickly integrate new tools, and version control/ configuration management.
Abstract: Good development environment support is essential for good requirements traceability. The paper describes how requirements traceability is supported in Bell-Northern Research's Integrated Development Environment, an internally developed version control and configuration management environment. Emphasis is given to the way in which requirements traceability interacts with the key features of the environment: generic (tool independent), fine-grained design information management that permits users to quickly integrate new tools, and version control/configuration management.
TL;DR: Card sorts were used to acquire software engineers' mental categorisations of these domains to inform categorization of a set of formal, reusable problem abstractions intended to assist requirements engineers.
Abstract: This paper reports a knowledge acquisition exercisewhich elicited experienced somare engineer' s knowledge about domains for which requirements engineering takes place. Card sorts were used to acquire software engineers' mental categorisations of these domains to inform categorization of a set of formal,reusable problem abstractions intended to assist requirements engineers.
TL;DR: An evaluation of the inquiry cycle model and a support tool, Tuiqiao, in the requirements analysis phase of a real project, a proposed commercial consumer information service based on Internet, and some recommendations for tool support are concluded.
Abstract: The inquiry cycle is a generic process model for conducting requirements elaboration. It consists of three activities: requirements expression, discussion and commitment. The paper describes an evaluation of the inquiry cycle model and a support tool, Tuiqiao, in the requirements analysis phase of a real project, a proposed commercial consumer information service based on Internet. The extent to which the discussion of requirements follows the inquiry cycle is analyzed using quantitative measures and qualitative classification schemes, and effects of adopting an inquiry-based strategy on patterns of collaboration among the team members are analyzed. The project gradually shifted from synchronous meetings to asynchronous and individual work patterns. A shift also occurred from an emphasis on discussion to an emphasis on commitment and expression. The requirements elaboration process was consistent with most aspects of the inquiry cycle, but analysts did not record reasons for requirements. The paper concludes with some recommendations for tool support.
TL;DR: This work looks specifically at the means and implications of combining Checkland and Wilson's Soft Systems Methodology with formal specification in LOTOS, a new requirements engineering method for software.
Abstract: Broadly, the paper argues for a soft systems approach to initial requirements definition and for the use of formal techniques as a means of strengthening that approach. In detail, the paper looks specifically at the means and implications of combining Checkland and Wilson's Soft Systems Methodology (SSM) with formal specification in LOTOS (P.B. Checkland, 1981; B. Wilson, 1990). Formal descriptions give precise meaning to the largely informal SSM models and help establish a bridge to traditional computing oriented analysis techniques. The use of tools to support the development, linking and maintenance of SSM and LOTOS models is also examined. The discussion is illustrated with a simple book ordering data processing example. Overall, this work is part of a larger research effort into the development of RACE, a new requirements engineering method for software.
TL;DR: In this paper, the authors present guidelines for specification and follow-up of requirements on industrial control systems based on an extensive study of experiences from a number of major users and vendors of these kinds of computer systems.
Abstract: An appropriate industrial control system is a prerequisite for being competitive in the process, manufacturing, and power industries. As for most software systems, the technical possibilities provided by industrial control systems have grown dramatically during the last ten years. However, the techniques to specify customer and user requirements in terms of functionality, performance, etc. are not very well developed. This often leads to systems which do not fulfil user needs and customer expectations, and/or which are unnecessarily expensive. Guidelines for specification and follow-up of requirements on industrial control systems are given. The guidelines are based on an extensive study of experiences from a number of major users and vendors of these kinds of computer systems. They should be useful for customers and consultants working in procurement projects.
Journal Article•
Journal Article•
TL;DR: In developing software for safety critical systems, it is necessary to carry out both requirements analysis and safety analysis; the requirements analyst is responsible for identifying and documenting the system safety requirements that pertain to the system's software.
Abstract: Summary form only given. In developing software for safety critical systems, it is necessary to carry out both requirements analysis and safety analysis. During requirements analysis, the behavioural and functional requirements of the system's software components are defined, documented, and reviewed. In addition, the requirements analyst is responsible for identifying and documenting the system safety requirements that pertain to the system's software. Safety analysis techniques are used to determine whether or not the safety requirements are satisfied. Traditionally, safety analysis has been performed on designs of the system's software, including a high level design, and not on the system's software requirements specification. However, if the requirements are described in terms of an operational model, a safety analysis of the requirements is possible. Are there any requirements techniques that help with the problems of developing safety critical software? Are there any requirements techniques that hinder development of such software? Is it effective to perform parts of a safety analysis on the requirements specification, as opposed to delaying analysis until design or implementation? If so, what parts of a safety analysis should be done on the requirements specification, and what parts should be done on the design description?.
TL;DR: This study is a rigorous assessment of GLIDER's designers' decision to include features which enhance legibility in the language, thus forbidding some texts to be processed on the first step of processing: the parsing of terms.
Abstract: Ideally, a requirement specification language should lead to highly readable text while being implementable. Unfortunately, current technology does not offer good support for features which enhance legibility such as elisions, flexible syntaxes, and more generally incomplete texts. GLIDER's designers have deliberately included those features in the language, thus forbidding some texts to be processed. This study is a rigorous assessment, both qualitative and quantitative, of this decision on the first step of processing: the parsing of terms.