Search

Since the 1980s, requirements engineering (RE) for information systems has been performed in practice using techniques (rather than the full method) from Information Engineering (IE) such as business goal analysis, function{ and process modeling, and cluster analysis. Recently, these techniques have been supplemented with portfolio management, which looks at sets of IT projects and offers fast quantitative decision-making about continuation of IT projects. Today's networked world, though, poses challenges to these techniques. A major drawback is their inability to adequately specify the requirements for IT systems used by businesses that provide services to each other in a value web. In this paper, we analyze this problem, and propose a solution by coupling IE and portfolio management with value-based RE techniques at the business network level. We show how these techniques interrelate, and illustrate our approach with a small example.

This paper presents a two-site case study on requirements-based effort estimation practices in enterprise resource planning projects. Specifically, the case study investigated the question of how to handle qualitative data and highly volatile values of project context characteristics. We counterpart this challenge and expound upon the integration of portfolio management concepts and simulation concepts into a classic effort estimation model (COCOMO II).

In the current practice of designing software for user organizations, as experienced by the authors, designers often produce design knowledge again and again for every decision: They re-invent the wheel. We want to improve the quality, predictability and efficiency of the software design process by reusing design knowledge. Our proposed solution consists of Reusable Rationale Blocks (RRBs). An RRB is a schema and a notation to write down decision rationale. To manage RRBs, we introduce a generalized design space, that consists of a collection of RRBs. And to use RRBs, we define a process that can be added to any design process, as well as a set of heuristics to be used in applying this process. We illustrate our solution by a few examples taken from our own experience.

Having developed, used and evaluated some of the early IBIS-based approaches to design rationale (DR) such as gIBIS and QOC in the late 1980s/mid-1990s, we describe the subsequent evolution of the argumentation-based paradigm through software support, and perspectives drawn from modeling and meeting facilitation. Particular attention is given to the challenge of negotiating the overheads of capturing this form of rationale. Our approach has maintained a strong emphasis on keeping the representational scheme as simple as possible to enable real time meeting mediation and capture, attending explicitly to the skills required to use the approach well, particularly for the sort of participatory, multi-stakeholder requirements analysis demanded by many design problems. However, we can then specialize the notation and the way in which the tool is used in the service of specific methodologies, supported by a customizable hypermedia environment, and interoperable with other software tools. After presenting this approach, called Compendium, we present examples to illustrate the capabilities for support security argumentation in requirements engineering, template driven modeling for document generation, and IBIS-based indexing of and navigation around video records of meetings.

Customers, product managers, project leaders, architects, engineers, and other stakeholders are negotiating requirements throughout the software lifecycle. Even-though fundamental for understanding requirements engineer-ing, negotiation has not been as thoroughly studied as other facets of this engineering discipline. This paper casts requirements engineering into the landscape of negotiation by describing a framework for selecting tactics and methods for various negotiation constellations that can be encountered in a software organization. The framework opens perspectives that are essential for understanding the behavior of people involved in development projects, for understanding how development teams and stakeholders create mutually satisfactory solutions, and for giving tactical advice to practitioners.