Research Papers

ASPECT-ORIENTED REQUIREMENTS ENGINEERING
Session Chair: Michael Goedicke

From Goals to Aspects: Discovering Aspects from Requirements Goal Models, by Yu, Leite, Mylopoulos

Aspect-oriented programming (AOP) has been attracting much attention in the Software Engineering community by advocating that programs should be structured according to programmer concerns, such as `efficient use of memory''. However, like other programming paradigms in their early days, AOP has not addressed yet earlier phases of software development. In particular, it is still an open question how one identifies aspects early on in the software development process. This paper proposes an answer to this question. Specifically, we show that aspects can be discovered during goal-oriented requirements analysis. Our proposal includes a systematic process for discovering aspects from relationships between functional and non-functional goals. We illustrate the proposed process with a case study adapted from the literature.

From Aspectual Requirements to Proof Obligations for Aspect-Oriented Systems, by Katz, Rashid

Aspect-oriented software development (AOSD) techniques support systematic modularization and composition of crosscutting concerns, the so-called "aspects". Though AOSD techniques have been proposed to handle crosscutting concerns at various stages during the software life cycle, there is a gap between the aspects at the requirements level and those at later development stages. It is not clear what proof obligations about an aspect-oriented implementation follow from the initial aspectual requirements. This validation problem is further compounded by the lack of traceability of aspectual requirements and their associated trade-offs through to subsequent design and implementation-level refinements. This paper presents PROBE, a framework for generation of proof obligations for aspect-oriented systems from the initial aspectual requirements and associated trade-offs. The abstract proof obligations are expressed in standard linear temporal logic. Key components of the framework include an extended Ontology with parametric temporal formulas and functions, and extensive treatment of conflicts among requirements. The resultant temporal logic assertions, grouped into specifications of aspect implementations, can then be used as input to formal methods tools such as model-checkers, or in the specification and generation of test cases.

Modeling, Composing and Validating Scenario-Based Requirements with Aspects, by Araujo, Whittle, Kim

There has been significant recent interest, within the Aspect-Oriented Software Development (AOSD) community, in representing crosscutting concerns at various stages of the software lifecycle. However, most of these efforts have concentrated on the design and implementation phases. We focus in this paper on representing aspects during use case modeling. In particular, we focus on scenario-based requirements (both aspectual and non-aspectual) and show how to validate such requirements as part of an iterative validation process. Non-aspectual interactions (scenarios) are modeled as UML sequence diagrams. Aspectual interactions are modeled as Interaction Pattern Specifications (IPSs). In order to validate them, the interactions are transformed into a set of executable state machines using an existing state machine synthesis algorithm. Previous work composed the aspectual and non-aspectual interactions at the sequence diagram level. In this paper, the composition is done at the state machine level. The trade-offs of both approaches are discussed.

VISUALISING AND ANIMATING REQUIREMENTS AND GOALS
Session chair: Dan Berry

Visual Variability Analysis with Goal Models, by Gonzales-Baixauli, Julio Cesar, Mylopoulos

One of the benefits of goal-oriented requirements engineering is the possibility of conducting formal analysis in order to evaluate alternative solutions of goal models. Superficially, goal analysis seems like an optimization problem. There is a fundamental difference from optimization problems in the sense that goal analysis does not aim at optimal solutions, but rather "good enough" ones. Moreover, goal analysis has to blend quantitative with qualitative techniques to account for the fact that the subject matter is software requirements engineering. The analysis of the interplay of non-functional softgoals and functional goals at a high level of abstraction is an important element of goal analysis for the requirements engineer, especially so when dealing with requirements variability. This paper proposes a visual variability analysis technique and describes an implemented tool that supports it.

Fluent-Based Animation: Exploiting the Relation between Goals and Scenarios for Requirements Validation, by Uchitel, Chatley, Kramer, Magee

Scenarios and goals are effective and popular techniques for requirements definition. Validation is essential in order to ensure that they represent what stakeholders actually want. Rather than validating scenarios and goals separately, possibly driving the elaboration of one through the validation of the other, this paper focuses on exploiting the relation between goals and scenarios. The aim is to provide effective graphical animations as a means of validating both.

Goals are objectives that a system is to meet. They are elaborated into a structure that decomposes declarative goals into goals that can be formulated in terms of states controllable by the system. Scenarios are operational examples of system usage. The relation between scenarios and goals is established by means of fluents that describe how events of the operational description change the state of the basic propositions from which goals are expressed. Graphical animations are specified in terms of fluents and driven by a behaviour model synthesised from the operational scenarios.

Goal-Oriented Requirements Animation, by Tran Van, van Lamsweerde, Massonet, Ponsard

Requirements engineers need to make sure that the requirements models and specifications they are building do accurately capture what stakeholders really want. Requirements animation has been recognized to be a promising approach to support this. The principle is to simulate an executable version of the requirements model and to visualize the simulation in some form appealling to stakeholders. Unfortunately, most animation tools available to date visualize simulations of design models. Even when this is not the case the executable models may be far away from the objectives and constraints stated declaratively by stakeholders. Furthermore animators in general require full models to be available making it impossible to incrementally animate partial model views associated with specific properties. The paper describes a tool aimed at overcoming such limitations by animating goal-oriented requirements models. The tool generates parallel state machines from goal operationalizations, instantiates them on specific instances created by users at animation time, executes them from concurrent events input by multiple users, monitors goal violations at animation time and visualizes the concurrent simulation in terms of animated scenes in the domain.

REQUIREMENTS ENGINEERING FOR COTS-BASED SYSTEMS
Session chair: Eric Dubois

When buying COTS-based software, the customer has to choose between what is available. The vendor may add some minor parts, but not everything the customer wants. This means that the customer cannot write down his requirements and expect that they can all be met. A scoring system with soft requirements is necessary rather than traditional hard requirements. The best current approach is to develop selection criteria in an exploratory way through discussions with the vendors and experiments with the products. However, in large public tenders this is not feasible for several reasons.  Requirements for integrating the new COTS system with other systems are particularly hard because vendors may integrate in different ways and with different other systems. A related problem is that once the new COTS system is purchased, the COTS vendor may have a de-facto monopoly. Only he can expand the system or integrate it with other systems. These issues are very serious in large acquisition projects. Experience shows that customers fail to deal with them adequately. As an example they may believe that asking for open interfaces is sufficient to guard them against monopoly. In this paper we analyze the problems and show ways to deal with them. Part of the answer is to use soft requirements that allow the vendors to explain their solutions in such a way that the customer can compare them from a user perspective. We illustrate the problems and solutions with real-life examples from Electronic Patient Recording systems (EPR)

Due to the generality and complexity of enterprise systems, they are challenging to implement and deploy successfully in organizations. Many of these problems are rooted in the way requirements are analyzed and negotiated among the stakeholders. Critical success factors have been used as guidelines for enterprise systems projects, but their applicability depends on the context and the goals and scopes of the projects. We propose a model that explains the success of the requirements engineering model in terms of the project's ability to balance various concerns. This model defines a number of indicators that may expose unbalanced requirements and clarify the use of critical success factors in enterprise systems projects.

Expanding Horizons of Requirements Engineering: Examining Requirements during Groupware Tool Diffusion, by Mark, Bergman, Poltrock

In this paper, we examine how a groupware tool diffusion process can be explained in terms of applied requirements analysis. To do this, we discuss a detailed case study of how a groupware tool was diffused throughout a field site using a "grassroots social worlds" process. To do this, we examine the groupware tool diffusion process in detail while noting where requirements enabled or inhibited tool adoption. We observed that initial diffusion occurred in different social worlds, i.e. internal collectives of people with common work practices, within the organization. We describe how requirements that are present in overlaps between different social worlds accelerate the diffusion of the groupware tool, eventually to the point of reaching "critical mass" acceptance, i.e. adoption of tools by the organizational as a whole. From an examination of the observed process, we determine and discuss seven lessons learned for applying requirements analysis to technology diffusion.

USE CASES IN THE REQUIREMENTS PROCESS
Session chair: Oscar Pastor

Use Case Estimation - The Devil is in the Detail, by Vinsen, Jamieson, Callender

Mission critical and complex software projects habitually exceed budget expectations significantly. Dependable cost estimates are often required by customers long before detailed analysis and design activities would produce this information during a project. A number of estimation methodologies have evolved to produce reliable cost information at an early stage in the software life-cycle, however estimation continues to be a contributor to budget blowouts.

 Contemporary techniques for costing requirements described as use cases are increasingly challenged as the size and complexity of the system expands. In addition object oriented representations of requirements fail to directly map into structures used by project managers, leading to ongoing comparisons of individual costs that are subjective and often unrepresentative of final project expenditure. A case study of a system development for an Australian government department is described to illustrate some of these problems. Possible flaws in the current application of cost estimation methodologies for use cases are exposed and a potential solution is proposed.

Precise Specification and Validation of Transactional Business Software, by Correa, Werner

This paper presents an approach to the specification and validation of transactional business software. The focus of this work is on the production of detailed use case specifications and on the precise definition of all transactions and business rules using a subset of UML class diagrams and statecharts combined with textual specifications written in OCL (Object Constraint Language). We show how to produce and validate such artifacts using a scenario driven approach combined with animation and prototyping techniques in a highly iterative process. The paper also presents PSW (Precise Specification Workbench), a tool that supports the proposed approach.

Customer Experience Requirements for Multi-platform Service Interaction: Bringing Services Marketing to the Elicitation of User Requirements, by Patricio, Cunha, Fisk, Nunes

The commercial use of the Internet for service provision has deeply changed the environment where human-computer interaction takes place, as Web interfaces are now integrated in a multi-platform service provision. This paper presents the results of a study of a multi-channel Portuguese bank, making use of both Marketing and HCI methods and concepts to understand customer usage of the different service platforms. The study involved in-depth interviews, focus groups, a web survey and a telephone survey with bank customers. The study allowed the identification of the most important interaction experience requirements for this multi-platform service, and how they are influenced by user profiles and service characteristics. The results also show that experience requirements have a strong impact on customer choice and usage of the different service platforms and can be better captured with essential use cases, as they are technology independent. Designing a multi-platform service interaction should therefore start with a higher level of abstraction that allows a multi-platform, customer experience and essential use case perspectives. With this integrated approach, the Internet service can therefore be designed in order to best leverage Internet service own capabilities and its complementarity with the other service platforms.

MANAGING REQUIREMENTS CHANGE AND TRACEABILITY
Session Chair: Klaus Pohl

A Heterogeneous Solution for Improving the Return on Investment of Requirements Traceability, by Cleland-Huang, Zemont, Lukasik

This paper describes a best-of-breed approach to traceability, in which the return-on-investment of the requirements traceability effort is maximized through the strategic deployment of a heterogeneous set of traceability techniques, each one optimized to accomplish a specific task. This contrasts with typical traceability practices that tend to utilize a single traceability technique such as a matrix or tool embedded in a requirements management package even though it may not provide the optimal solution for the traceability needs of a diverse set of requirements. The proposed solution, named TraCS (Traceability for Complex Systems), is a risk-driven approach in which the determination for where and when to establish links, and the underlying mechanism for each link is made according to the needs of each requirement within the constraints of project level trace strategies. The paper first provides a rationale for this approach, and then describes an extensible traceability framework for supporting heterogeneous traceability. Finally, it defines a systematic process for selecting and implementing diverse requirements traceability techniques within a single project. The approach is illustrated through requirements taken from a system to control chemical reactions at a catalyst plant.

Using Card Sorting Technique to Classify Requirements Change, by Nurmuliani, Zowghi, Fowell

Requirements Volatility is considered to be a major source of risk to the management of large and complex software projects. The ability to characterise the nature and origins of requirements change during software development is important and can lead organisations towards more effective management of changing requirements. This paper focuses on a study to establish how practitioners classify requirements change requests. We used the Card Sorting method to identify categories of change requests that software developers use in practice. Card sorting is a knowledge elicitation method that is commonly used for capturing information about people's categorisations. This study has allowed us to get valuable insights into the way practitioners classify change requests and to understand their perspectives on classification. This classification is a valuable source of information in prioritizing change requests and assessing their impact. Our findings from the card sorting exercises further reveal that criteria used for categorization is related to the role the practitioner plays in the software development team and the nature and extent of their responsibilities.

Helping Analysts Trace Requirements: An Objective Look, by Huffman Hayes, Dekhtyar, Karthikeyan Sundaram, Howard

This paper addresses the issues related to improving the overall quality of the requirements tracing process for Independent Verification and Validation analysts. The contribution of the paper is three-fold: we define requirements for a tracing tool based on analyst responsibilities in the tracing process; we introduce several new measures for validating that the requirements have been satisfied; and we present a prototype tool that we built, RETRO (REquirements TRacing On-target), to address these requirements. We also present the results of a study used to assess RETRO's support of requirements and requirement elements that can be measured objectively.

IMPROVING REQUIREMENTS PROCESSES
Session chair: Didar Zowghi

Requirements Engineering Process Improvement Based on an Information Model, by Dorr, Paech, Koehler

Requirements Engineering (RE) process improvement methods typically work with explicit process models describing activities and document flow between the stakeholders involved, and with explicit document definitions. In complex, multi-project contexts, however, the RE process is better characterized as intertwining of design, negotiation, and sense-making [1]. In the first part of this paper, we present the concepts of a workshop-based RE process improvement technique suitable for a multi-project context. In the second part, we show the experiences made in an industrial case study conducted with Nokia Smart Traffic Products. The major innovations of our approach are: (i) instead of a process model, an information model is created, which focuses solely on the responsibilities of stakeholders with regard to the major documents; (ii) instead of document details, only the major point of view of the documents is defined. We experienced that focusing on document viewpoints ensures that the group gets a common understanding of the interests and information needs of each stakeholder without too much effort. Focusing on the information model instead of the process model ensures that the stakeholders get a common understanding of the necessary design decisions and the systematic integration of the different viewpoints during negotiation and sense-making. The information model is created in a two-day workshop in moderated discussions with representatives of all involved stakeholder groups.

Architecture-driven Problem Decomposition, by Rapanotti, Hall, Jackson, Nuseibeh

Jackson's Problem Frames provide a means of analysing and decomposing problems. They emphasise the world outside of the computer helping the developer to focus on the problem domain instead of drifting into inventing solutions. The intention is to delay consideration of the solution space until a good understanding of the problem is gained. In contrast, early consideration of a solution architecture is common practice in software development. Software is usually developed by including existing components and/or reusing existing frameworks and architectures. This has the advantage of shortening development time though reuse, and increasing the robustness of a system through the application of tried and tested solutions. In this paper, we show how these two views can be reconciled and demonstrate how a choice of architecture can facilitate problem analysis, decomposition and subsequent recomposition, within the Problem Frames framework. In particular, we introduce Architectural Frames ? combinations of architectural styles and Problem Frames ? and illustrate their use by applying them to two problems from the literature.

Engineering Patterns for RE in Small and Medium Projects, by Hagge, Lappe

This paper presents four engineering patterns which have been successfully used for adopting RE methods and conducting RE activities in projects. The patterns address project leaders. They propose an organizational sub-structure for RE within projects and are covering requirements elicitation, specification and validation. The paper tries to capture engineering knowledge in the format of patterns with the objective to enable knowledge transfer at the level of practical experience.

ORGANISATIONAL AND SOCIO-TECHNICAL SYSTEMS
Session Chair: Colette Rolland

Developing a Domain-Specific Cross-Organizational RE Method, by Gordijn, Kartseva, Schildwacht, Wieringa, Akkermans

Cross-organizational requirements engineering (XRE) is the activity in which several business actors perform a joint problem-solving process in which a cooperative, cross-organizational business solution is designed. In XRE, partially conflicting concerns and views must be reconciled to create a shared vision of the goals and structure of a cooperative process. In this paper we report on the development of an XRE method, BusMod, by means of action research. Each iteration of our action research cycle consisted of a series of consultancy projects in which our method is used, followed by a reflection to draw lessons learned to improve the method. Although BusMod has been developed in the domain of electricity power generation, we hypothesize that it can be generalized to any domain of cooperating actors, and that in any such domain value engineering must be part of requirements engineering.

Defining Early IT System Requirements with Regulation Principles: The Lightswitch Approach, by Regev, Wegmann

In this paper we present the Lightswitch method, a method for defining early requirements for enterprise IT systems. Using the method, engineers can model the way an enterprise regulates its relationships with its environment, identify changing conditions within the enterprise and its environment, and propose options for changing this regulation. The engineers can then define initial IT system goals necessary for the above changes. The use of the method is shown in the real case of a hospital's sterilization department

Human-centred Requirements Engineering, by Gregoriades, Shin, Sutcliffe

This paper describes the influence of human factors in the requirements engineering process of socio-technical systems design. In particular, we examine agents' workloads and the partitioning of system requirements into automated functions, collaborative task support or manual procedures. We assess workload in terms of communication and the task load that each agent is able to handle. We illustrate the application of the approach in complex socio-technical systems such as the command and control rooms of military vessels. A case study is presented that demonstrates the use of a tool, HUCRE (Human-Centred Research Engineering) that assesses workloads of agents and assists the diagnosis of potential system failure. A preliminary evaluation of the HUCRE method and tool is reported, demonstrating that requirements engineers can address human factors issues using the supporting tool.

HANDLING NON-FUNCTIONAL REQUIREMENTS
Session chair: Al Davis

The Effect of Trust Assumptions on the Elaboration of Security Requirements, by Haley, Laney, Moffett, Nuseibeh

Assumptions are frequently made during requirements analysis of a system-to-be about the trustworthiness of its various components (including human components). These trust assumptions can affect the scope of the analysis, derivation of security requirements, and in some cases how functionality is realized. This paper presents trust assumptions in the context of analysis of security requirements. A running example shows how trust assumptions can be used by a requirements engineer to help define and limit the scope of analysis and to document the decisions made during the process. The paper concludes with a case study examining the impact of trust assumptions on software that uses the Secure Electronic Transaction (SET) specification.

Identifying Stakeholders and Their Preferences about NFR by Comparing Use Case Diagrams of Several Existing Systems, by Kaiya, Osada, Kaijiri

We present a method to identify stakeholders and their preferences about non-functional requirements (NFR) by using use case diagrams of existing systems. We focus on the changes about NFR because such changes help stakeholders to identify their preferences. Comparing different use case diagrams of the same domain helps us to find changes to be occurred. We utilize Goal-Question-Metrics (GQM) method for identifying variables that characterize NFR, and we can systematically represent changes about NFR using the variables. Use cases that represent system interactions help us to bridge the gap between goals and metrics(variables), and we can easily construct measurable NFR. For validating and evaluating our method, we applied our method to an application domain of Mail User Agent (MUA) system.

Composing Requirements Using Problem Frames, by Laney, Barroca, Jackson, Nuseibeh

Problem Frames are a systematic approach to the decomposition of problems that allows us to relate requirements, domain properties, and machine specifications. Having decomposed a problem, one approach to solving it is through a process of composing solutions to sub-problems. In this paper, we contribute to supporting such a process by providing a way to compose multiple Problem Frames. We develop a systematic approach to composing inconsistent requirements. We introduce Composition Frames, a requirements construct that models relevant aspects of composition and thus deals with unwanted effects, such as interference of overlapping reactions to events. Throughout the paper we use a simple case study to illustrate and validate our ideas.

STRUCTURING AND TRANSFORMING REQUIREMENTS
Session Chair: Jaelson Castro

RETNA: From Requirements to Testing in a Natural Way, by Mukhopadhyay

Most problems in building and refining a system can be traced back to errors in requirements. Poorly organized requirements most often in natural language are among the major causes of failure of software projects. In this paper, we present a requirements analysis tool called RETNA and the technology behind it. RETNA accepts natural language requirements, classifies them, interacts with the user to refine them, automatically translates natural language requirements to a logical form so that they can be validated and finally generates test cases from the requirements.

OMML: A Behavioural Model Interchange Format, by Hall, Zisman

The number and diversity of existing languages for describing behavioural specifications (models) of systems do not enable the integration, sharing, or reuse of models between tools. Incompatible node models cannot be used to help validate overall combined system behaviour. In this paper, we address this problem by defining an XML-based model interchange format named OpenModel Modelling Language (OMML). It represents behavioural models in a tool-independent way. OMML is a function rich procedural language that expresses functionality in terms of function/object theories. It uses shared ontologies to support standardisation of terminology among model developers. This paper describes OMML and its different document types. We also describe prototype tools we have developed to support bi-directional translation between models expressed in OMML, ISAT's P-EBF, and SCR. We have performed an initial evaluation of the approach, demonstrating interoperability between two validation tools, ISAT and SCR.

Speeding up Requirements Management in a Product Software Company: Linking Customer Wishes to Product Requirements through Linguistic Engineering, by Natt och Dag, Gervasi, Brinkkemper, Regnell

Developing large complex software products aimed for a broad market involves a great flow of wishes and requirements. The former are elicited from customers while the latter are brought forth by the developing organization. These are preferably kept separated to preserve the different perspectives. The interrelationships should however be identified and maintained to enable well-founded decisions. Unfortunately, the manual linkage is cumbersome, time-consuming, and error-prone. This paper presents a pragmatic linguistic engineering approach to how statistical natural language processing may be used to support the linkage between customer wishes and product requirements. An evaluation with real requirements from industry is presented. It shows that in a realistic setting, automatic support could help to identify at least 50% of the correct links. The results, together with the identified enhancement, are promising for improving software quality and saving time in industrial requirements engineering.

Industrial Experience Report Sessions

SELECTING AND MANAGING REQUIREMENTS PROCESSES AND TOOLS

Semantic Normal Form Dramatically Enhances System Quality, by Stamper and Ades

Practical experience revealed the potential for an order of magnitude reduction in system development, support and maintenance costs using a new 'information field' model for requirements engineering. After outlining the theoretical basis of the new MEASUR methods, the paper compares two computer-based systems after about six years serving two quite similar organisations. One, a package of conventional design already implemented at over 200 other sites, the other, the novel NAMAT, outperformed it organisationally at much lower cost. These benefits stemmed mainly from its employing the Semantic Normal Form that enforced increased rigour and completeness on the organisational analysis and system specification.

Requirements Management Process Selection at Hewlett-Packard, by Padula

The requirements management (RM) processes used at Hewlett-Packard (HP) are many and varied. They range from informal to formal on projects that are short, agile, and at internet-speed as well as long and methodical ones. Typically, the RM approach is influenced by business drivers as well as constraints or attributes of the project. Some of the major attributes that affect HP's RM selection process include: level of understanding of the user's domain/needs, project size & complexity, schedule, resources, cost, quality expectations, project personnel expertise, development model (in-house versus outsourced), tolerance for requirements volatility, cost of requirements changes during development and after release, and the speed at which changes can be applied to the product after release. Attributes of the RM approach for two HP projects are examined in this paper. The first project is agile with an internet-speed release schedule. It is based on experience with the web site and consumer award-winning eServices hpshopping.com organization. The other project is large, complex, and makes use of outsourced development. It is based on experience with the development of an HP worldwide (WW) IT customer communications system that cuts across all of HP's businesses. There is no one right way to do RM at HP --- the best one is usually a customized one that most closely fits the business drivers and project attributes.

Requirements for Requirements Management Tools, by Hoffman, Kuhn, Weber and Bittner

Tools for managing systems requirements are especially helpful in development projects involving systems that are large, safety-critical, distributed or all of these. They keep specifications consistent, up-to-date and accessible. Since the requirements for complex systems are themselves complex information structures that must be handled in complex process scenarios, it is not surprising that there are many strong requirements concerning a tool support for suitably managing them. This paper presents a requirements catalog for requirements management tools that is based on substantial project experience (including tool evaluation experiences) in the area of automotive as well as aircraft and defense systems. The purpose of this catalog is to help users compare and select requirements management tools as well as helping tool providers to direct future tool developments.

The Conundrum of Categorizing Requirements: Managing Requirements for Learning on the Move, by Haley, Nuseibeh, Sharp, Taylor

This paper reports on the experience of eliciting and managing requirements on a large European-based multinational project, whose purpose is to create a system to support learning using mobile technology. The project used the socio-cognitive engineering methodology for human-centered design [1] and the Volere shell and template [2] to document requirements. We provide details about the project below, describe the Volere tools, and explain how and why we used a flexible categorization scheme to manage the requirements. Finally, we discuss three lessons learned: (1) provide a flexible mechanism for organizing requirements, (2) plan ahead for the RE process, and (3) do not forget the waiting room.

REQUIREMENTS FOR TRANSPORT AND WEB SYSTEMS

Requirement-Driven Approach To Interoperable Traveller Support System Specification, by Tsuchiya, Matsuoka, Goto, Seki And Ogino

This research is part of the CyberRail project in which we aim to develop itinerary-based, location-sensitive traveler information services for intermodal travelers. This paper covers our approach in which top-down requirements analysis are used effectively to derive interoperable traveller support system specification together with some feedback from experimental system implementations. The derived system specification reflects the requirements of stakeholders of each of mode of transportation, including but not restricting to rail and will be used as a reference model for system developers of various traveler support systems. We believe that by conforming to the common reference model, several alternative implementations of CyberRail will appear in the future that guarantee sufficient level of interoperability.

Experiences in Managing an Automotive Requirements Engineering Process, by Heumesser and Houdek

The specification volume for all software-based systems that are built in a modern car has passed the 20,000 pages mark. Even for a single component, we find specification documents comprising several hundred pages. Clearly, such specification documents cannot be created and changed simply and quickly. We hence need a systematic process to elicit and maintain, negotiate and validate all requirements, i.e. a proper requirements engineering process. In this paper, we present an example for such an automotive requirements engineering process and the instruments we employed to manage this process. The experiences are drawn from projects at DaimlerChrysler Passenger Car Development. The paper sketches the requirements engineering process used, the core management instruments deployed, e.g. a feature list, and observations gained in utilizing this process.

Requirements Engineering in the Development of Innovative Automotive Embedded Software Systems, by Puschnig & Kolagari

The proportion of software systems in the cars of today has increased rapidly, resulting in a considerable boost in value-added in the automotive domain. In the meantime, the vehicular features realized through software have come to represent an integrant differentiating factor between the products of the various car producers. And it is not only comfort functionalities that are concerned, but also security and safety-relevant applications such as ABS or the airbag. Hence the development of customer-oriented software with high and reliable quality now plays a more and more important role. In this contribution our experiences gained in the development of specifications for innovative automotive software systems are presented. Requirements engineering methods and processes in the development of innovations differ from the development of established systems the more the innovative system encompasses different domains: the commitment of domain experts is hence needed. We describe specific challenges in this context and sketch some burning issues open to research to meet the problems we are currently facing.

A Context-Driven Use Case Creation Process for Specifying Automotive Driver Assistance Systems, by Omasreiter and Metzker

Current use case guidelines typically recommend a goal-driven process for use case creation and, in many cases, this approach indeed works sufficiently well. Yet, in our experience, this goal-driven approach does not seem to offer the best fit for every kind of function, e.g. for highly context-sensitive automotive driver assistance systems. For these functions we suggest selecting a context-driven process for use case creation.

In this paper we first show the effectiveness of goal-driven use case creation for a usual car telephone function. Then we demonstrate the limits of this approach for an adaptive vehicle cruise control function (the Distronic system). Finally we present our basic ideas of a context-driven use case creation process and evidence its advantages as compared to the goal-driven approach using the example of the Distronic function.

Developing A Requirements Specification For A Web Service Application, by Gibson

It has been stated that deficiencies in software requirements are the leading cause of failure in software projects. If this is true, then the converse implication is that the opposite is also true. This report presents a case study that supports this implication. The study was made from observation and documentation of the requirements development process used in a Web Service order-entry project. The project focus was the development of a business critical application that would accept our clients' (a music "record label" company) orders over the Internet using Web services. Secondly this report supports the contention that using Web services to provide business-to-business online solutions simplifies application development and reduces risk and process development costs.

Research directions for requirements theories