Sol J. Greenspan

Requirements Engineering and Technology Transfer: Obstacles, Incentives and Improvement Agenda

For many years, research results in requirements engineering (RE) have been developed without much interaction with, or impact on, industrial practice. Why is it so difficult to introduce RE research results into mainstream RE practice? This paper attempts to provide answers to this question by describing obstacles that researchers and practitioners have encountered when they attempted technology transfer. In addition, major incentives for using RE methods are discussed, along with ideas for improving current RE practice. The paper summarises, clarifies and extends the results of two panel discussions, one at the Twelfth Conference on Advanced information Systems Engineering (CAiSE’00) and the other at the Fourth IEEE Conference on Requirements Engineering (ICRE’00).

A requirements modeling language and its logic

This chapter describes aspects of a Requirements Modeling Language (RML) which can be used in the initial phases of software development. RML is based on the idea that a requirements specification should embody a conceptual world model, and that the language for expressing it should provide facilities for organizing and abstracting details, yet at the same time have qualities such as precision, consistency, and unambiguity.

A decision making methodology in support of the business rules lifecycle

The business rules that underlie an enterprise emerge as a new category of system requirements that represent decisions about how to run the business, and which are characterized by their business-orientation and their propensity for change. We introduce a decision making methodology which addresses several aspects of the business rules lifecycle: acquisition, deployment and evolution. We describe a meta-model for representing business rules in terms of an enterprise model, and also a decision support sub-model for reasoning about and deriving the rules. A technique for automatically extracting business rules from the decision structure is described and illustrated using business rules examples inspired by the London Ambulance Service case study. A system based on the metamodel has been implemented, including the extraction algorithm.

Scenario-Based Analysis of COTS Acquisition Impacts

When an enterprise considers the acquisition of a COTS (commercial off-the-shelf) system, the procurement process typically includes consideration of technical criteria such as feature sets and ease of integration with other systems. However, any selected COTS system will also have an impact on how the enterprise runs – how the work of the enterprise gets done and ultimately how the services of the enterprise are delivered to its customers. This paper presents a method for determining these enterprise-level impacts. A notion of enterprise-level impacts is delineated, and a scenario-based technique is presented for uncovering and assessing these impacts. The method is informal and lightweight – it does not require extensive modelling, formal rigour, or management of artefacts. Some insights, experience and lessons are reported. Some comparisons are made with past experience using a more formal, heavyweight method and tool.

Requirements engineering using the SOS paradigm

Service-providing enterprises (SPEs) employ systems composed of people, computer hardware and software, and other mechanisms to perform service actions in the customers environment as well as to carry out internal operations as part of the SPE infrastructure. These systems are termed service-oriented systems (SOSs). The authors address the question of how to reformulate and simplify the requirements engineering process by adopting an SOS paradigm. It is shown that there are advantages to viewing many large, complex systems within the SOS paradigm. This is due to the increasingly service-oriented economy as well as the increased demands for a paradigm for integration of and interoperability between systems across multiple enterprises. The domain of SOSs is described, together with the technique by which SPE forms the context for requirements modeling and analysis. A requirements modeling framework consisting of several viewpoints and their interrelationships is outlined in order to define the SOS requirements analysis task. The context in which the defined requirements modeling task will be useful is explained.<<ETX>>

Structuring software development for reliability

Abstract Software system development is viewed as a series of discrete ordered activities that produce successively more constrained models of the system by binding in additional system aspects. Treating the system aspects as separate concerns allows software engineering techniques that control production cost and enhance reliability to be applied to each step. The greatest gains, however, are due to the reliability and traceability of the system over its lifetime. An essential tool is a structured system description technique.

ACME/PRIME: requirements acquisition for process-driven systems

The paper discusses a requirements gathering methodology and tool support for a class of systems we term service oriented systems. The requirements acquisition methodology that our tools support is, not surprisingly, a process centered methodology, since the processes of the system map to the services provided by our organization. The ACME/PRIME tool to support this methodology is built upon a conceptual modeling platform (ACME) that traces its roots to RML. The paper discusses our approach to one of the fundamental problems of requirements engineering, i.e., dealing with over and under specification of requirements. We also provide some lessons learned from deploying the ACME/PRIME tool in our corporate requirements office.

Why is it so easy to introduce requirements engineering technology transfer panels into mainstream practice

This position paper has summarized conclusions reached by prior panels and has suggested moving on. One suggested focus is attention to the network of research dependencies that must be in place for us to succeed. A second focus is the need for a close working relationship between business and systems concerns.

Recording requirements assumptions and rationale

A discussion on recording requirements assumptions and rationale is summarized. Among the topics discussed by the participants are: incrementality in rational management; grounding argumentations in construction; architecture for integrated design environments; requirements definition in design; representation of rationale; rationale management systems; and incremental formalization of rationale.<<ETX>>

Data and activities: Exploiting hierarchies of classes

We wish to briefly discuss recent work in conceptual modelling from a slightly different point of view in order to highlight the parallels between data and transactions, and then mention some benefits of this view. A time-honoured way of describing a system (portion of the world) is by positing a domain of objects and then inter-relating them through function and predicate symbols. The resulting description is a set of axioms in a FOPC. If the world is dynamic, one usually augments the description with the notion of time or state, in which case axioms can be divided naturally into “general laws” (heretofore constraints ) holding in all states, and state-specific “facts”. Given states, one then also has the ability to describe state transitions ( events ) as predicates on pairs of states or, as shown below, as objects in their own right.