Attempts to utilize information retrieval techniques to fully automate the creation of traceability links have been hindered by terminology mismatches between source and target artifacts. Therefore, current trace retrieval algorithms tend to produce imprecise and incomplete results. In this paper we address this mismatch by proposing an expert system which integrates a knowledge base of domain concepts and their relationships, a set of logic rules for defining relationships between artifacts based on these rules, and a process for mapping artifacts into a structure against which the rules can be applied. This paper lays down the core foundations needed to integrate an expert system into the automated tracing process. We construct a knowledge base and inference rules for part of a large industrial project in the transportation domain and empirically show that our approach significantly improves precision and recall of the generated trace links.

Early modeling languages have focused on the analysis and the design of systems under construction, but not on requirements elicitation. Consequently, a wide variety of approaches exists for the early phases of requirements engineering, modeling various concepts as stakeholders, goals, features, product lines, systems, processes, risks, and requirements. The purpose of Unified Requirements Modeling Language (URML TM) is to combine these concepts in a single modeling language. In addition, it strengthens support for danger modeling. URML is implemented as an add-in to the Enterprise Architect CASE tool. This tool demo will showcase the URML implementation.

During model-driven requirements elicitation sessions for several commercial products, weaknesses were identified with available modeling languages such as UML and SysML. Continued frustration when attempting to use the UML for requirements capture eventually resulted in collaboration between Siemens and Technische Universität München (TUM) to define a new visual requirements language called the Unified Requirements Modeling Language (URML). This paper describes some of the rationale behind the development of the URML, highlights some of the more unusual features of the language, and, finally, describes its use on a commercial project.

Requirements engineering (RE) for complex industrial systems can defy traditional processes and tooling. Some topics, such as managing requirements for contract based and regulated systems are rarely mentioned in the literature. Market forces such as increased staff turnover and reduced development times are changing the way products and services are defined. Other issues, such as eliciting, analyzing, and managing tens or hundreds of thousands of requirements effectively and efficiently, remain, to a large extent, intractable. Some RE activities, such as the tracing of cross-cutting requirements are a conundrum looking for a solution. In some cases, the techniques that do work have evolved over time through trial and error. In general, however, RE processes and tooling on large industrial projects, such as major infrastructure works, have a ways to go before they can be considered standard practices. Described below are some of the more intractable problems in the engineering of industrial systems.

A research has studied different views of suppliers and customers have of solution projects that include both provided goods and rendered services. The goal of the research is to help the suppliers and customers to understand each other better, and therefore make solution projects more profitable for the suppliers and be more effective for the customers. We are involved in an infrastructure improvement project that shares many characteristics of a solution project. Our early experience suggests introducing a contractor view that is different from the supplier and customer views. Our experience also indicates that effective requirements engineering, under the constraint of lengthy and complex contractual requirements is of great importance for the project success.

In 2003, the Software & Engineering department (S&E) at Siemens Corporate Research (SCR) initiated the training of Siemens employees worldwide in requirements engineering (RE). The first courses taught were customized for the target audience and taught onsite. In 2005, a standardized foundation course was created; the first course in a suite of offerings. To date, the course has been taught to over 200 Siemens professionals worldwide. In order to determine the impact of the training at Siemens, and to improve the course, a survey was conducted and the results are reported in this paper, along with an analysis of our findings.

Successful software development involves the elicitation, implementation, and management of critical systemic requirements related to qualities such as security, usability, and performance. Unfortunately, even when such qualities are carefully incorporated into the initial design and implemented code, there are no guarantees that they will be consistently maintained throughout the lifetime of the software system. Even though it is well known that system qualities tend to erode as functional and environmental changes are introduced, existing regression testing techniques are primarily designed to test the impact of change upon system functionality rather than to evaluate how it might affect more global qualities. The concept of using goal-centric traceability to establish relationships between a set of strategically placed assessment models and system goals is introduced. This paper describes the process, algorithms, and techniques for utilizing goal models to establish executable traces between goals and assessment models, detect change impact points through the use of automated traceability techniques, propagate impact events, and assess the impact of change upon systemic qualities. The approach is illustrated through two case studies.

Empirical studies have shown that the use of a product line approach to software development can result in shorter time to market and improved productivity. Outsourcing and distributed development has added a new dimension to product management, exacerbating problems associated with transitioning from marketing studies to product definition to analysis and design. Communication problems can arise when requirements for products are captured on a regional or international basis. This half day tutorial provides an introduction to global product line requirements engineering from the perspective of project and product management. Topics covered include geographically distributed product lines including organizational and technical issues of globalization, distributed requirements elicitation, feature modeling, the role of the product line manager, and the use of meta-models to define global/distributed processes.

In global development projects, different modeling techniques are used to create and manage the requirements, analyze the problem domain, identify potential hazards and develop the system design. For each modeling technique, separate tools (e.g. UML case tool, requirements database, Word) are used. Each tool comes with its own meta-model, which hinders the interchange of models across tools and makes automated traceability and quality analysis across all models unmanageable. We propose the integration of different modeling techniques by adding new relationships. The integrated requirements model supports complete traceability across feature modeling, use case modeling, requirements and hazard analysis, detailed requirements and system design. We propose design rules and metrics for a formal and automated quality assurance, project monitoring and control. The model is implemented in a central repository, accessible from distributed sites. Synchronous online collaboration, asynchronous offline access and model-based configuration management is supported for the entire unified requirements model.

Models are frequently used for illustrations in software design documents. Commonly they are used to show static structure and less often, external dynamic behavior. However, in software engineering, the lack of conceptual models often inhibits creativity and understanding, which may in turn lead to incomplete or poor design. This paper describes our experience using models for the architectural, conceptual and detailed design for software systems, identifies perceived weaknesses in traditional approaches and makes recommendations for future modeling tools and techniques.

One of the problem areas in requirements engineering has been the integration of functional and nonfunctional requirements and use cases. Current practice is to partition functional and nonfunctional requirements such that they are often defined by different teams. Functional requirements are defined by writing text-based use cases or, less frequently, creating a business model, then walking through the use cases, and extracting (often in a haphazard fashion) detailed requirements. The problem is exacerbated when analysts are at different locations. Siemens experience with outsourcing and offshoring has demonstrated that the use of graphical languages significantly reduces cultural and communication problems when teams (e.g. analysis and design) are at different locations. Tracing between functional and nonfunctional requirements, use cases, hazards and features is complicated by the use of different Medias. Introducing new symbols and new relationships allows the creation of a unified model with intrinsic tracing. This, in turn, improves clarity and facilitates communication when teams are at different locations and/or are lacking in domain expertise

The CMMI defines two process areas associated with requirements elicitation: Requirements Development (RD) and Requirements Management (REQM). The Measurements and Analysis process area (MA) requires measurements and quantitative objectives for RD and REQM, but nowhere does it state what those measurements are. Furthermore, in order to extract measurements and evaluate them, a process must enable or otherwise support the taking of measurements. It is especially difficult to do this during requirements development, as it is generally viewed as a writing activity that does not lend itself to quantitative measurements. This paper describes a CMMI compliant formal approach to measurement and analysis during a model-driven requirements development process. It presents a set of metrics that were used successfully on several Siemens projects, describing team dynamics, project size and staffing, how the metrics were captured and used, and lessons learned.

Summary form only given. This talk describes experiences and lessons learned while defining product requirements for small and large companies over a thirty-year period. From 1969 to the present the author has assisted or led teams in the definition of requirements for a wide variety of products and systems, including music information, produce delivery, power and process control, baggage handling, mail sorting, insurance, medical device and information, communications, taxation and even race horse breeding. Often, the success or failure of the projects encountered depended on factors that were not immediately apparent to the project teams involved. At times team members would take the correct steps without realizing the consequences of a misstep. In other cases minor missteps might lead to catastrophe. Finally, the talk presents a rationale for the perceived precipitous drop in software project completion rates since the 1960s and 1970s, and offer suggestions for better preparing computer science students to meet the challenges of 21st century software development

Poirot is a Web-based tool supporting traceability of distributed heterogeneous software artifacts. A probabilistic network model is used to generate traces between requirements, design elements, code and other artifacts stored in distributed 3rdparty case tools such as DOORS, rational rose, and source code repositories. The tool is designed with extensibility in mind, so that additional artifact types and 3rdparty case tools can be easily added. Trace results are displayed in both a textual and visual format. This paper briefly describes the underlying probabilistic model, and the user interface of the tool, and then discusses Poirot's deployment and use in an industrial setting

Requirements elicitation and management has become ever more important as products become more complex and time to market is shortened and the definitions of product lines has significantly increased project complexity. Outsourcing has added a new dimension to requirements management, exacerbating problems associated with transitioning from analysis to design. This half day tutorial will provide an introduction to product line requirements engineering from the perspective of project and product management: how it impacts project managers, quality assurance personnel, requirements analysts, developers and testers. Topics covered will include product line requirements, feature modeling, CMMI compliant requirements management and requirements analysis processes (both UML and text based). Business analysts who are interested in using UML for modeling will also find the course interesting. No formal knowledge of programming is required. developers and testers.

This paper describes techniques for analyzing large UML models. The first part of the paper describes heuristics and processes for creating semantically correct UML analysis and design models. The second part of the paper briefly describes the internal DesignAdvisor research tool that was used to analyze Siemens models. The results are presented and some interesting conclusions are drawn.

Many Siemens operating companies build software products or products with a high software content (e.g. embedded software). Siemens Corporate Research has had the unique opportunity over the last few years to look at the analysis models from which the software products were derived, analyze them, and recommend changes. All the models investigated define commercial products that are or will be in the marketplace in the near future. Because of the size and complexity of the models (some running over a thousand use cases) the internal analysis tool design advisor was created to facilitate their inspection. An analysis was then performed on several models with interesting results.

We have observed that often there is a disconnect between a UML model and the requirements of the modeled processes. This gap tends to widen as models become more complex and the extraction of detailed requirements becomes more difficult. The process by which detailed requirements are extracted from a model is fairly straightforward. Not only can the technique be used to extract requirements, but, interestingly enough, the same information that is extracted can be used to generate the task list part of a project plan, as the concrete use cases identify the pieces of software that need to be implemented. The use case model is basically an acyclic directed graph, with dependencies as vertices and use cases as nodes. In order for the extraction process to work, the use case model needs to be built following certain guidelines. For example: No dependency cycles and model continuity (e.g. a single continuous directed graph).