Search

Software systems are increasingly regulated. Software engineers therefore must determine which requirements have met or exceeded their legal obligations and which requirements have not. Requirements that have met or exceeded their legal obligations are legally implementation ready, whereas requirements that have not met or exceeded their legal obligations need further refinement. In this paper, we examine how software engineers make these determinations using a multi-case study with three cases. Each case involves assessment of requirements for an electronic health record system that must comply with the US Health Insurance Portability and Accountability Act (HIPAA) and is measured against the evaluations of HIPAA compliance subject matter experts. Our first case examines how individual graduate-level software engineering students assess whether the requirements met or exceeded their HIPAA obligations. Our second case replicates the findings from our first case using a different set of participants. Our third case examines how graduate-level software engineering students assess requirements using the Wideband Delphi approach to deriving consensus in groups. Our findings suggest that the average graduate-level software engineering student is ill-prepared to write legally compliant software with any confidence and that domain experts are an absolute necessity. [ABSTRACT FROM PUBLISHER]

In this paper, we describe research results arising from a technology transfer exercise on agent-oriented requirements engineering with an industry partner. We introduce two improvements to the state-of-the-art in agent-oriented requirements engineering, designed to mitigate two problems experienced by ourselves and our industry partner: (1) the lack of systematic methods for agent-oriented requirements elicitation and modelling; and (2) the lack of prescribed deliverables in agent-oriented requirements engineering. We discuss the application of our new approach to an aircraft turnaround simulator built in conjunction with our industry partner, and show how agent-oriented models can be derived and used to construct a complete requirements package. We evaluate this by having three independent people design and implement prototypes of the aircraft turnaround simulator, and comparing the three prototypes. Our evaluation indicates that our approach is effective at delivering correct, complete, and consistent requirements that satisfy the stakeholders, and can be used in a repeatable manner to produce designs and implementations. We discuss lessons learnt from applying this approach. [ABSTRACT FROM PUBLISHER]

This paper presents a computational method that employs Natural Language Processing (NLP) and text mining techniques to support requirements engineers in extracting and modeling goals from textual documents. We developed a NLP-based goal elicitation approach within the context of KAOS goal-oriented requirements engineering method. The hierarchical relationships among goals are inferred by automatically building taxonomies from extracted goals. We use smart metering system as a case study to investigate the proposed approach. Smart metering system is an important subsystem of the next generation of power systems (smart grids). Goals are extracted by semantically parsing the grammar of goal-related phrases in abstracts of research publications. The results of this case study show that the developed approach is an effective way to model goals for complex systems, and in particular, for the research-intensive complex systems. [ABSTRACT FROM PUBLISHER]

The process of Requirements Engineering (RE) includes many activities, from goal elicitation to requirements specification. The aim is to develop an operational requirements specification that is guaranteed to satisfy the goals. In this paper, we propose a formal, systematic approach for generating a set of operational requirements that are complete with respect to given goals. We show how the integration of model checking and inductive learning can be effectively used to do this. The model checking formally verifies the satisfaction of the goals and produces counterexamples when incompleteness in the operational requirements is detected. The inductive learning process then computes operational requirements from the counterexamples and user-provided positive examples. These learned operational requirements are guaranteed to eliminate the counterexamples and be consistent with the goals. This process is performed iteratively until no goal violation is detected. The proposed framework is a rigorous, tool-supported requirements elaboration technique which is formally guided by the engineer's knowledge of the domain and the envisioned system. [ABSTRACT FROM PUBLISHER]

Modeling is a fundamental activity within the requirements engineering process and concerns the construction of abstract descriptions of requirements that are amenable to interpretation and validation. The choice of a modeling technique is critical whenever it is necessary to discuss the interpretation and validation of requirements. This is particularly true in the case of functional requirements and stakeholders with divergent goals and different backgrounds and experience. This paper presents the results of a family of experiments conducted with students and professionals to investigate whether the comprehension of functional requirements is influenced by the use of dynamic models that are represented by means of the UML sequence diagrams. The family contains five experiments performed in different locations and with 112 participants of different abilities and levels of experience with UML. The results show that sequence diagrams improve the comprehension of the modeled functional requirements in the case of high ability and more experienced participants. [ABSTRACT FROM PUBLISHER]

Scalability is a critical concern for many software systems. Despite the recognized importance of considering scalability from the earliest stages of development, there is currently little support for reasoning about scalability at the requirements level. This paper presents a goal-oriented approach for eliciting, modeling, and reasoning about scalability requirements. The approach consists of systematically identifying scalability-related obstacles to the satisfaction of goals, assessing the likelihood and severity of these obstacles, and generating new goals to deal with them. The result is a consolidated set of requirements in which important scalability concerns are anticipated through the precise, quantified specification of scaling assumptions and scalability goals. The paper presents results from applying the approach to a complex, large-scale financial fraud detection system. [ABSTRACT FROM AUTHOR]

The Next Release Problem (NRP) aims to optimize customer profits and requirements selection for the software releases. The research on the NRP is restricted by the growing scale of requirements. In this paper, we propose a Backbone-based Multilevel Algorithm (BMA) to address the large scale NRP. In contrast to direct solving approaches, the BMA employs multilevel reductions to downgrade the problem scale and multilevel refinements to construct the final optimal set of customers. In both reductions and refinements, the backbone is built to fix the common part of the optimal customers. Since it is intractable to extract the backbone in practice, the approximate backbone is employed for the instance reduction while the soft backbone is proposed to augment the backbone application. In the experiments, to cope with the lack of open large requirements databases, we propose a method to extract instances from open bug repositories. Experimental results on 15 classic instances and 24 realistic instances demonstrate that the BMA can achieve better solutions on the large scale NRP instances than direct solving approaches. Our work provides a reduction approach for solving large scale problems in search-based requirements engineering. [ABSTRACT FROM PUBLISHER]

To estimate software code size early in the development process is important for developing cost-efficient embedded systems. We have applied the COSMIC Functional Size Measurement (FSM) method for size estimation of embedded software components in the automotive industry. Correlational studies were conducted using data from two automotive companies. The studies show strong correlation between functional size and software code size, which is important for obtaining accurate estimation results. This paper presents the characteristics and results of our work, and aims to provide a practical framework for how to use COSMIC FSM for size estimation purposes. We investigate the results from our earlier correlational studies, and conduct further studies to identify such a framework. Based on these activities, we conclude that a clear purpose of the estimation process, a well-defined domain allowing categorization of software, consistent content and quality of requirements, and historical data from implemented software are key factors for size estimation of embedded software components. [ABSTRACT FROM PUBLISHER]

The Verifying Compiler (VC) project is a core component of the Dependable Systems Evolution Grand Challenge. The VC offers the promise of automatically proving that a program or component is correct, where correctness is defined by program assertions. While several VC prototypes exist, all adopt a semantics for assertions that is unsound. This paper presents a consolidation of VC requirements analysis (RA) activities that, in particular, brought us to ask targeted VC customers what kind of semantics they wanted. Taking into account both practitioners' needs and current technological factors, we offer recovery of soundness through an adjusted definition of assertion validity that matches user expectations and can be implemented practically using current prover technology. For decades, there have been debates concerning the most appropriate semantics for program assertions. Our contribution here is unique in that we have applied fundamental software engineering techniques by asking primary stakeholders what they want and, based on this, proposed a means of efficiently realizing the semantics stakeholders want using standard tools and techniques. We describe how support for the new semantics has been added to ESC/Java2, one of the most fully developed VC prototypes. Case studies demonstrate the effectiveness of the new semantics at uncovering previously indiscernible specification errors. [ABSTRACT FROM AUTHOR]

Requirements engineering (RE) is a key discipline in software development and several methods are available to help assess and improve RE processes. However, these methods rely on prescriptive models of RE; they do not, like other disciplines within software engineering, draw directly on stakeholder perceptions and subjective judgments. Given this backdrop, we present an empirical study in RE process assessment. Our aim was to investigate how stakeholder perceptions and process prescriptions can be combined during assessments to effectively inform RE process improvement. We first describe existing methods for RE process assessment and the role played by stakeholder perceptions and subjective judgments in the software engineering and management literature. We then present a method that combines perceptions and prescriptions in RE assessments together with an industrial case study in which the method was applied and evaluated over a three-year period at TelSoft. The data suggest that the combined method led to a comprehensive and rich assessment and it helped TelSoft consider RE as an important and integral part of the broader engineering context. This, in turn, led to improvements that combined plan-driven and adaptive principles for RE. Overall, the combined method helped TelSoft move from Level 1 to Level 2 in RE maturity, and the employees perceived the resulting engineering practices to be improved. Based on these results, we suggest that software managers and researchers combine stakeholder perceptions and process prescriptions as one way to effectively balance the specificity, comparability, and accuracy of software process assessments. [ABSTRACT FROM AUTHOR]

Information practices that use personal, financial, and health-related information are governed by US laws and regulations to prevent unauthorized use and disclosure. To ensure compliance under the law, the security and privacy requirements of relevant software systems must properly be aligned with these regulations. However, these regulations describe stakeholder rules, called rights and obligations, in complex and sometimes ambiguous legal language. These "rules" are often precursors to software requirements that must undergo considerable refinement and analysis before they become implementable. To support the software engineering effort to derive security requirements from regulations, we present a methodology for directly extracting access rights and obligations from regulation texts. The methodology provides statement-level coverage for an entire regulatory document to consistently identify and infer six types of data access constraints, handle complex cross references, resolve ambiguities, and assign required priorities between access rights and obligations to avoid unlawful information disclosures, We present results from applying this methodology to the entire regulation text of the US Health Insurance Portability and Accountability Act (HIPAA) Privacy Rule. [ABSTRACT FROM AUTHOR]

This paper presents a framework for security requirements elicitation and analysis. The framework is based on constructing a context for the system, representing security requirements as constraints, and developing satisfaction arguments for the security requirements. The system context is described using a problem-oriented notation, then is validated against the security requirements through construction of a satisfaction argument. The satisfaction argument consists of two parts: a formal argument that the system can meet its security requirements and a structured informal argument supporting the assumptions expressed in the formal argument. The construction of the satisfaction argument may fail, revealing either that the security requirement cannot be satisfied in the context or that the context does not contain sufficient information to develop the argument, In this case, designers and architects are asked to provide additional design information to resolve the problems. We evaluate the framework by applying it to a security requirements analysis within an air traffic control technology evaluation project. [ABSTRACT FROM AUTHOR]

Like any other quality attribute, usability imposes specific constraints on software components. Features that raise the software system's usability have to be considered from the earliest development stages. But, discovering and documenting usability features is likely to be beyond the usability knowledge of most requirements engineers, developers, and users. We propose an approach based on developing specific guidelines that capitalize upon key elements recurrently intervening in the usability features elicitation and specification process. The use of these guidelines provides requirements analysts with a knowledge repository. They can use this repository to ask the right questions and capture precise usability requirements information. [ABSTRACT FROM AUTHOR]

Requirements engineering is an important component of effective software engineering, yet more research is needed to demonstrate the benefits to development organizations. While the existing literature suggests that effective requirements engineering can lead to improved productivity, quality, and risk management, there is little evidence to support this. We present empirical evidence showing how requirements engineering practice relates to these claims. This evidence was collected over the course of a 30-month case study of a large software development project undergoing requirements process improvement. Our findings add to the scarce evidence on RE payoffs and, more importantly, represent an in-depth explanation of the role of requirements engineering processes in contributing to these benefits. In particular, the results of our case study show that an effective requirements process at the beginning of the project had positive outcomes throughout the project lifecycle, improving the efficacy of other project processes, ultimately leading to improvements in project negotiation, project planning, and managing feature creep, testing, defects, rework, and product quality. Finally, we consider the role collaboration had in producing the effects we observed and the implications of this work to both research and practice. [ABSTRACT FROM AUTHOR]

The problem of relating state-based intraagent (or intraobject) behavioral descriptions with scenario-based interagent (interobject) descriptions has recently focused much interest among the software engineering community. This paper compiles the results of our investigation of this problem. As interagent formalism, we adopt a simple variant of Live Sequence Charts. For the intraagent perspective, we consider a game-theoretic foundation, looking at agents as "strategies," which encompasses the popular "state-based" paradigm. Three classes of relationships between models are studied: scenario checking (called eLSC checking), synthesis, and verification. We set a formally defined theoretical stage that allows us to express these three problems very simply, to discuss their complexity, and to describe optimal solutions. Our study reveals the intrinsic high computational difficulty of these tasks. Consequently, many related problems and solutions are surveyed, some of which can be the basis for practical solutions. In this, we also offer a panorama of current research and directions for the future. [ABSTRACT FROM AUTHOR]

Requirements traceability is intended to ensure continued alignment between stakeholder requirements and various outputs of the system development process. To be useful, traces must be organized according to some modeling framework. Indeed, several such frameworks have been proposed, mostly based on theoretical considerations or analysis of other literature. This paper, in contrast, follows an empirical approach. Focus groups and interviews conducted in 26 major software development organizations demonstrate a wide range of traceability practices with distinct low-end and high-end users of traceability. From these observations, reference models comprising the most important kinds of traceability links for various development tasks have been synthesized. The resulting models have been validated in case studies and are incorporated in a number of traceability tools. A detailed case study on the use of the models is presented. Four kinds of traceability link types are identified and critical issues that must be resolved for implementing each type and potential solutions are discussed. Implications for the design of next-generation traceability methods and tools are discussed and illustrated. The development of large software systems consists of a sequence of modeling tasks. It requires the modeling and description of the application domain, software requirements, software architecture, software components, their internal structure, and their implementation. Technically, in software engineering, we work with a development method and description techniques with modeling, refinement, and implementation concepts. Today, much of the modeling is carried out by informal text and graphical description techniques. The development is organized in a development process and supported by CASE toots. In this paper, we show how mathematics can provide a scientific foundation for the modeling aspects, description techniques, and development methods of software engineering. Such a scientific foundation leads to a deeper understanding of the development process and to a basis for a more powerful tool support. [ABSTRACT FROM AUTHOR]

Management of performance requirements is a major challenge for information systems as well as other software systems. This is because performance requirements (e.g., "a student records system should have good response time for registering students") can have a global impact on the target system. In addition, there are interactions and trade-offs among performance requirements, other nonfunctional requirements (NFRs, or software quality attributes, e.g., accuracy), and the numerous alternatives for the target system. To provide a systematic approach to managing performance requirements, this paper presents a "Performance Requirements Framework" (PeRF) It integrates and catalogues a variety of kinds of knowledge of information systems and performance These include performance concepts, Software Performance Engineering (SPE) principles for "building performance into" systems, and information systems development knowledge (including requirements, design, implementation, and performance). In addition, layered structures organize performance knowledge and the development process. All this knowledge is represented using an existing goal-oriented approach, the "NFR Framework," which offers a developer-directed graphical treatment for stating NFRs, analyzing and interrelating them, and determining the impact of decisions upon NFRs. This approach allows customized solutions to be built, taking into account the characteristics of the particular domain. The use of PeRF in managing performance requirements is illustrated in a study of performance requirements and other NFRs for a university's student records system. This paper concludes with a summary of other studies of information systems, tool support, and directions for future work. [ABSTRACT FROM AUTHOR]

Requirements engineering is concerned with the elicitation of high-level goals to be achieved by the envisioned system, the refinement of such goals and their operationalization into specifications of services and constraints and the assignment of responsibilities for the resulting requirements to agents such as humans, devices, and software. Requirements engineering processes often result in goals, requirements, and assumptions about agent behavior that are too ideal; some of them are likely not to be satisfied from time to time in the running system due to unexpected agent behavior. The lack of anticipation of exceptional behaviors results in unrealistic, unachievable, and/or incomplete requirements. As a consequence, the software developed from those requirements will not be robust enough and will inevitably result in poor performance or failures, sometimes with critical consequences on the environment. This paper presents formal techniques for reasoning about obstacles to the satisfaction of goals, requirements, and assumptions elaborated in the requirements engineering process. A first set of techniques allows obstacles to be generated systematically from goal formulations and domain properties. A second set of techniques allows resolutions to be generated once the obstacles have been identified thereby. Our techniques are based on a temporal logic formalization of goals and domain properties; they are integrated into an existing method for goal-oriented requirements elaboration with the aim of deriving more realistic, complete, and robust requirements specifications. A key principle in this paper is to handle exceptions at requirements engineering time and at the goal level, so that more freedom is left for resolving them in a satisfactory way. The various techniques proposed are illustrated and assessed in the context of a real safety-critical system. [ABSTRACT FROM AUTHOR]

Managing the development of software requirements can be a complex and difficult task. The environment is often chaotic. As analysts and customers leave the project, they are replaced by others who drive development in new directions. As a result, inconsistencies arise. Newer requirements introduce inconsistencies with older requirements. The introduction of such requirements inconsistencies may violate stated goals of development. In this article, techniques are presented that manage requirements document inconsistency by managing inconsistencies that arise between requirement development goals and requirements development enactment. A specialized development model, called a requirements dialog meta-model, is presented. This meta-model defines a conceptual framework for dialog goal definition, monitoring, and in the case of goal failure, dialog goal reestablishment. The requirements dialog meta-model is supported in an automated multiuser World Wide Web environment, called DEALSCRIBE. An exploratory case study of its use is reported. This research supports the conclusions that: 1) an automated tool that supports the dialog meta-model can automate the monitoring and reestablishment of formal development goals, 2) development goal monitoring can be used to determine statements of a development dialog that fail to satisfy development goals, and 3) development goal monitoring can be used to manage inconsistencies in a developing requirements document. The application of DEALSCRIBE demonstrates that a dialog meta-model can enable a powerful environment for managing development and document inconsistencies. [ABSTRACT FROM AUTHOR]

We describe and analyze the process of requirements development in scenario-based design through consideration of a case study. In our project, a group of teachers and system developers initially set out to create a virtual physics laboratory. Our design work centered on the collaborative development of a series of scenarios describing current and future classroom activities. We observed classroom scenarios to assess needs and opportunities, and envisioned future scenarios to specify and analyze possible design moves. We employed claims analysis to evaluate design trade-offs implicit in these scenarios, to codify the specific advantages and disadvantages in achieving requirements. Through the course of this process, the nature of our project requirements has evolved, providing more information but also more kinds of information. We discuss the utility of managing requirements development through an evolving set of scenarios, and the generality of the scenario stages from this case study. [ABSTRACT FROM AUTHOR]

Scenarios are increasingly recognized as an effective means for eliciting, validating, and documenting software requirements. This paper concentrates on the use of scenarios for requirements elicitation and explores the process of inferring formal specifications of goals and requirements from scenario descriptions. Scenarios are considered here as typical examples of system usage; they are provided in terms of sequences of interaction steps between the intended software and its environment. Such scenarios are in general partial, procedural, and leave required properties about the intended system implicit. In the end such properties need to be stated in explicit, declarative terms for consistency/completeness analysis to be carried out. A formal method is proposed for supporting the process of inferring specifications of system goals and requirements inductively from interaction scenarios provided by stakeholders. The method is based on a learning algorithm that takes scenarios as examples/counterexamples and generates a set of goal specifications in temporal logic that covers all positive scenarios while excluding all negative ones. The output language in which goals and requirements are specified is the KAOS goal-based specification language. The paper also discusses how the scenario-based inference of goal specifications is integrated in the KAOS methodology for goal-based requirements engineering. In particular, the benefits of inferring declarative specifications of goals from operational scenarios are demonstrated by examples of formal analysis at the goal level, including conflict analysis, obstacle analysis, the inference of higherlevel goals, and the derivation of alternative scenarios that better achieve the underlying goals. [ABSTRACT FROM AUTHOR]

Scenarios have been advocated as a means of Improving requirements engineering yet few methods or tools exist to support scenario -- based RE. The paper reports a method and software assistant tool for scenario -- based RE that Integrates with use case approaches to object-oriented development. The method and operation of the tool are illustrated with a financial system case study. Scenarios are used to represent paths of possible behavior through a use case, and these are investigated to elaborate requirements. The method commences by acquisition and modeling of a use case. The use case is then compared with a library of abstract models that represent different application classes. Each model is associated with a set of generic requirements for its class, hence, by identifying the class(es) to which the use case belongs, generic requirements can be reused. Scenario paths are automatically generated from use cases, then exception types are applied to normal event sequences to suggest possible abnormal events resulting from human error. Generic requirements are also attached to exceptions to suggest possible ways of dealing with human error and other types of system failure. Scenarios are validated by rule-based frames which detect problematic event patterns. The tool suggests appropriate generic requirements to deal with the problems encountered. The paper concludes with a review of related work and a discussion of the prospects for scenario-based RE methods and tools. [ABSTRACT FROM AUTHOR]

It is well known that requirements engineering plays a critical role in software quality. The use case approach is a requirements elicitation technique commonly used in industrial applications. Software requirements are stated as a collection of use cases, each of which is written in the user's perspective and describes a specific flow of events in the system. The use case approach offers several practical advantages in that use case requirements are relatively easy to describe, understand, and trace. Unfortunately, there are a couple of major drawbacks. Since use cases are often stated in natural languages, they lack formal syntax and semantics. Furthermore, it is difficult to analyze their global system behavior for completeness and consistency, partly because use cases describe only partial behaviors and because interactions among them are rarely represented explicitly. In this paper, we propose the Constraints-based Modular Petri Nets(CMPNs) approach as an effective way to formalize the informal aspects of use cases. CMPNs, an extension of Place/Transition nets, allow the formal and incremental specification of requirements The major contributions of our paper, in addition to the formal definitions of CMPNs, are the development of: 1) a systematic procedure to convert use cases stated in natural language to a CMPN model; and 2) a set of guidelines to find inconsistency and incompleteness in CMPNs. We demonstrate an application of our approach using use cases developed for telecommunications services. [ABSTRACT FROM AUTHOR]

A requirements specification defines the requirements for the future system at a conceptual level (i.e., class or type level). In contrast, a scenario represents a concrete example of current or future system usage. In early RE phases, scenarios are used to support the definition of high level requirements (goals) to be achieved by the new system. In many cases, those goals can to a large degree be elicited by observing, documenting and analyzing scenarios about current system usage, i.e., the new system must often fulfill many of the functional and nonfunctional goals of the existing system. To support the elicitation and validation of the goals achieved by the existing system and to illustrate problems of the old system, we propose to capture current system usage using rich media (e.g., video, speech, pictures, etc.) and to interrelate those observations with the goal definitions. Thus, we particularly aim at making the abstraction process which leads to the definition of the conceptual models more transparent and traceable. More precisely, we relate the parts of the observations which have caused the definition of a goal or against which a goal was validated with the corresponding goal. These interrelations provide the basis for: 1) explaining and illustrating a goal model to, e.g., untrained stakeholders and/or new team members, and thereby improving a common understanding of the goal model; 2) detecting, analyzing, and resolving a different interpretation of the observations; 3) comparing different observations using computed goal annotations; and 4) refining or detailing a goal model during later process phases. Using the PRIME implementation framework, we have implemented the PRIME-CREWS environment, which supports the interrelation of conceptual models and captured system usage observations. We report on our experiences with PRIME-CREWS gained in a first experimental case study. [ABSTRACT FROM AUTHOR]

A wide range of inconsistencies can arise during requirements engineering as goals and requirements are elicited from multiple stakeholders. Resolving such inconsistencies sooner or later in the process is a necessary condition for successful development of the software implementing those requirements. The paper first reviews the main types of inconsistency that can arise during requirements elaboration, defining them in an integrated framework and exploring their interrelationships. It then concentrates on the specific case of conflicting formulations of goals and requirements among different stakeholder viewpoints or within a single viewpoint. A frequent, weaker form of conflict called divergence is introduced and studied in depth. Formal techniques and heuristics are proposed for detecting conflicts and divergences from specifications of goals/ requirements and of domain properties. Various techniques are then discussed for resolving conflicts and divergences systematically by introduction of new goals or by transformation of specifications of goals/objects toward conflict-free versions. Numerous examples are given throughout the paper to illustrate the practical relevance of the concepts and techniques presented. The latter are discussed in the framework of the KAOS methodology for goal-driven requirements engineering. [ABSTRACT FROM AUTHOR]

Software for safety critical systems must deal with the hazards identified by safety analysis. This paper investigates, how the results of one safety analysis technique, fault trees, are interpreted as software safety requirements to be used in the program design process. We propose that fault tree analysis and program development use the same system model. This model is formalized in a real-time, interval logic, based on a conventional dynamic systems model with state evolving over time. Fault trees are interpreted as temporal formulas, and it is shown how such formulas can be used for deriving safety requirements for software components. [ABSTRACT FROM AUTHOR]

Retrieval, validation, and explanation tools are described for cooperative assistance during requirements engineering and and are illustrated by a library system case study. Generic models of applications are reused as template for modeling and critiquing requirements for new applications. The validation tools depend on a matching process which takes facts describing a new application and retrieves the appropriate generic model from the system library. The algorithms of the matcher, which implement a computational theory of analogical structure matching, are described. A theory of domain knowledge is proposed to define the semantics and composition of generic domain models in the context of requirements engineering. A modeling language and a libraray of models arranged in families of classes are described. The models represent the basic transaction processing or use case for a class of applications. Critical difference rule are given to distinguish between families and hierarchical levels. Related work and future directions of the domain theory are discussed. [ABSTRACT FROM AUTHOR]

Composite systems are generally comprised of heterogeneous components whose specifications are developed by many development participants. The requirements of such systems are invariably elicited from multiple perspectives that over- lap, complement, and contradict each other. Furthermore, these requirements are generally developed and specified using multiple methods and notations, respectively. It is therefore necessary to express and check the relationships between the resultant specification fragments. In this paper, we deploy multiple View- Points that hold partial requirements specifications, described and developed using different representation schemes and development strategies. We discuss the notion of inter-ViewPoint communication in the context of this ViewPoints framework, and propose a general model for ViewPoint interaction and integration. We elaborate on some of the requirements for expressing and enacting inter-ViewPoint relationships-the vehicles for consistency checking and inconsistency management. Finally, though we use simple fragments of the requirements specification method CORE to illustrate various components of our work, we also outline a number of larger case studies that we have used to validate our framework. Our computer-based ViewPoints support environment, The Viewer, is also briefly described. [ABSTRACT FROM AUTHOR]

An approach to specification of requirements and verification of design for real-time systems is presented. A system is defined by a conventional mathematical model for a dynamic system where application specific states denote functions of real time. Specifications are formulas in duration calculus, a real-time interval logic, where predicates define durations of states. Requirements define safety and functionality constraints on the system or a component. A top-level design is given by a control law: a predicate that defines an automaton controlling the transition between phases of operation. Each phase maintains certain relations among the system states; this is analogous to the control functions known from conventional control theory. The top-level design is decomposed into an architecture for a distributed system with specifications for sensor, actuator, and program components. Programs control the distributed computation through synchronous events. Sensors and actuators relate events with system states. Verification is a deduction showing that a design implies requirements. [ABSTRACT FROM AUTHOR]

Support for various stakeholders involved in soft- ware projects (designers, maintenance personnel, project managers and executives, end users) can be provided by capturing the history about design decisions in the early stages of the systems development life cycle in a structured manner. Much of this knowledge, which we call the process knowledge, involving the deliberation on alternative requirements and design decisions, is lost in the course of designing and changing such systems. Using an empirical study of problem-solving behavior of individual and groups of information systems professionals, we have developed a conceptual model called REMAP (REpresentation and MAintenance of Process knowledge) that relates process knowledge to the objects that are created during the requirements engineering process. This model includes as part of it the Issue Based Information Systems (IBIS) method, which is designed to record the argumentation related to deliberations. We have implemented a prototype of an environment based on our model that can provide assistance to the various stakeholders involved in the design and management of large systems. [ABSTRACT FROM AUTHOR]

Requirements modeling depends on having available the knowledge of what should be modeled. Acquiring, or eliciting, this knowledge is recognized to be a hard problem, and different suggestions have been made to address it. In this paper we examine one such approach-viewpoint resolution. It is based on the fact that software requirements can and should be elicited from different viewpoints, and that examination of the differences resulting from them can be used as a Way of assisting in the early validation of requirements. Our research proposes a language for expressing views from different viewpoints and a set of analogy heuristics to perform a syntacticly oriented analysis of views. This analysis of views is capable of differentiating between missing information and conflicting information, thus providing support for viewpoint resolution. We also present empirical evidence Of the effectiveness of these mechanisms. [ABSTRACT FROM AUTHOR]

Operational requirements are qualities which influence a software system's entire development cycle. The investigation reported here concentrated on three of the most important operational requirements: reliability via fault tolerance, growth, and availability. Accommodation of these requirements is based on an approach to functional decomposition involving representation in terms of potentially independent processors, called virtual machines. Functional requirements may be accommodated through hierarchical decomposition of virtual machines, while performance requirements may be associated with individual virtual machines. Virtual machines may then be mapped to a representation of a configuration of physical resources, so that performance requirements may be reconciled with available performance characteristics. [ABSTRACT FROM AUTHOR]

User-perceived quality of interactive systems is defined in terms of statistically nonoverlapping categories, so-called dimensions or factors. Categories are identified by factor analysis and represent a dimensional concept of the quality of interactive systems as perceived by its users. Each category describes essential user requirements. This paper reports on a method and some initial results in the analysis of user-perceived quality of interactive systems. It is based on research work described in more detail elsewhere [7]. The methodology of approach is suitable for software requirements definition and human-factors engineering. [ABSTRACT FROM AUTHOR]

This paper describes a methodology for the generation of software requirements for large, real-time unmanned weapons systems. It describes what needs to be done, how to evaluate the intermediate products, and how to use automated aids to improve the quality of the product. An example is provided to illustrate the methodology steps and their products and the benefits. The results of some experimental applications are summarized. [ABSTRACT FROM AUTHOR]

The development of system requirements has been recognized as one of the major problems in the process of developing data processing system software. We have developed a computer-aided system for maintaining and analyzing such requirements. This system includes the Requirements Statement Language (RSL), a flow-oriented language for the expression of software requirements, and the Requirements Engineering and Validation System (REVS), a software package which includes a translator for RSL, a data base for maintaining the description of system requirements, and a collection of tools to analyze the information in the data base. The system emphasizes a balance between the use of the creativity of human thought processes and the rigor and thoroughness of computer analysis. To maintain this balance, two key design principles—extensibility and disciplined thinking—were followed throughout the system. Both the language and the software are easily user-extended, but adequate locks are placed on extensions, and limitations are imposed on use, so that discipline is augmented rather than decreased. [ABSTRACT FROM AUTHOR]