An analysis of the requirements traceability problem

In this paper1, we investigate and discuss the underlying nature of the requirements traceability problem. Our work is based on empirical studies, involving over 100 practitioners, and an evaluation of current support. We introduce the distinction between pre-requirements specification (pre-RS) traceability and post-requirements specification (post-RS) traceability, to demonstrate why an all-encompassing solution to the problem is unlikely, and to provide a framework through which to understand its multifaceted nature. We report how the majority of the problems attributed to poor requirements traceability are due to inadequate pre-RS traceability and show the fundamental need for improvements here. In the remainder of the paper, we present an analysis of the main barriers confronting such improvements in practice, identify relevant areas in which advances have been (or can be) made, and make recommendations for research

Information Systems and Web Information Systems: A Methodological Perspective

International audienceThe Development of Information Systems (ISD) is a complex activity that requires methodological support. Current ISD methods are predominantly following an object driven paradigm that allows us to capture the static as well as the dynamic dimensions of real world objects into information objects. However, Web Information Systems have facets such as information presentation, user profile, navigation structure etc. which pose new challenges to ISD methods. The keynote talk will provide an overview of current ISD methods and discuss the new challenges raised by the development of Web Information Systems. This paper is a brief overview of the key points developed in the talk

An Introduction to Requirements Traceability

This report surveys the requirements traceability literature and gives some recommendations for further research and for an approach to consultancy concerning traceability in the 2RARE project. The problem of maintaining traceability in a development project is viewed as the problem of maintaining an information system that maintains the relevant links between items developed during the process. These items may vary from requirements to design and implementation documents. To develop and implement such an information system, we must identify the needs for tracking information, made a model of this information, design usage procedures for the system, and implement the system. Accordingly, the literature on traceability is organized under the headings needs, models and usage. Furthermore, tracking tools are briefly reviewed

From Conceptual Modelling to Requirements Engineering

International audienceConceptual modelling is situated in the broader view of information systems requirements engineering. Requirements Engineering (RE) explores the objectives of different stakeholders and the activities carried out by them to meet these objectives in order to derive purposeful system requirements and therefore lead to better quality systems i.e. systems that meet the requirements of their users. Thus RE product models use concepts for modelling these instead of concepts like data, process, events etc. used in conceptual models. Since the former are more stable than the latter, requirements engineering manages change better. The paper gives the rationale for extending traditional conceptual models and introduces some RE product models. Furthermore, in contrast to conceptual modelling, requirements engineering lays great stress on the engineering process employed. The paper introduces some RE process models and considers their effect on tool support

Using active database for management of requirements change

Software system development projects experience numerous changes during their life cycle. These changes are inevitable and driven by several factors including changes to a system\u27s environment and changes of customers\u27 needs. Requirements change has been reported as the major contributing factor for poor quality or even failures of software projects. This indicates that management of requirements change still remains a challenging problem in software development. A critical part of the requirements change management process is impact analysis. To carry out impact assessment, traceability information is needed. Over two decades, requirements traceability has been an important research topic in software research, but the actual practice of maintaining traceability information is not always entirely successful. In this thesis, a new traceability technique was presented for mapping dynamic behaviors of requirements into Active Databases. The technique keeps requirements and their related artifacts synchronized with respect to their states. It automatically maintains traceability links between requirements and related artifacts when a requirement is changed. This approach can not only efficiently handle basic and necessary traceability functions, but also centralize reactive behavior by using Active Database to ensure no one bypass traceability policies.Dept. of Computer Science. Paper copy at Leddy Library: Theses & Major Papers - Basement, West Bldg. / Call Number: Thesis2005 .G42. Source: Masters Abstracts International, Volume: 44-03, page: 1401. Thesis (M.Sc.)--University of Windsor (Canada), 2005

Benefits of traceability in software development

PhD ThesisFor an engineer to be able to modify successfully a complex computer-based system, he will need to understand the system's functionality. Traceability can help the engineer to gain that understanding, but several surveys have observed that traceability information is poorly recorded. This thesis argues, based on a survey of nine aerospace projects, that one of the main causes of poor recording is that Traceability does not directly benefit the development process. The recording of traceability information is best performed by the engineers directly involved in the development process, yet it is precisely these engineers who seem to obtain no direct benefit in performing this task. This can be summarised as the Traceability Benefit Problem. To overcome this problem the recording of traceability data must provide immediate, tangible benefits to the engineers involved in the current development process. A related problem that occurs in large multi-team projects that follow development processes based on predictive models (such as Waterfall or VModel) is the changing of interface documentation without adequate negotiation (referred to as Throwing the Problem over the Wall). This thesis describes, in detail, how a small automotive sensor project addressed these problems by developing a Requirements Traceability system that enabled the reuse of software and provided a basis for the negotiation of changes with their customer. Analysis of the lessons learnt from the automotive sensor and aerospace projects lead to the definition of the Traceable Development Contract. The contribution of this thesis is the description and discussion of the Traceable Development Contract, a method of coordinating the interaction of related development teams in development process that is based on a predictive development model. The Traceable Development Contract is proposed as a means of controlling the upstream team bias with respect to the imposition of changes, by employing traceability to provide a basis for the negotiation of change. By VI employing traceability in this way, it becomes beneficial to the development engineers and therefore overcomes the Traceability Benefit Problem. Finally, the thesis considers how the Traceable Development Contract traceability information can be exploited further to provide solution maturity and design metrics

Preserving the Quality of Architectural Tactics in Source Code

In any complex software system, strong interdependencies exist between requirements and software architecture. Requirements drive architectural choices while also being constrained by the existing architecture and by what is economically feasible. This makes it advisable to concurrently specify the requirements, to devise and compare alternative architectural design solutions, and ultimately to make a series of design decisions in order to satisfy each of the quality concerns. Unfortunately, anecdotal evidence has shown that architectural knowledge tends to be tacit in nature, stored in the heads of people, and lost over time. Therefore, developers often lack comprehensive knowledge of underlying architectural design decisions and inadvertently degrade the quality of the architecture while performing maintenance activities. In practice, this problem can be addressed through preserving the relationships between the requirements, architectural design decisions and their implementations in the source code, and then using this information to keep developers aware of critical architectural aspects of the code. This dissertation presents a novel approach that utilizes machine learning techniques to recover and preserve the relationships between architecturally significant requirements, architectural decisions and their realizations in the implemented code. Our approach for recovering architectural decisions includes the two primary stages of training and classification. In the first stage, the classifier is trained using code snippets of different architectural decisions collected from various software systems. During this phase, the classifier learns the terms that developers typically use to implement each architectural decision. These ``indicator terms\u27\u27 represent method names, variable names, comments, or the development APIs that developers inevitably use to implement various architectural decisions. A probabilistic weight is then computed for each potential indicator term with respect to each type of architectural decision. The weight estimates how strongly an indicator term represents a specific architectural tactics/decisions. For example, a term such as \emph{pulse} is highly representative of the heartbeat tactic but occurs infrequently in the authentication. After learning the indicator terms, the classifier can compute the likelihood that any given source file implements a specific architectural decision. The classifier was evaluated through several different experiments including classical cross-validation over code snippets of 50 open source projects and on the entire source code of a large scale software system. Results showed that classifier can reliably recognize a wide range of architectural decisions. The technique introduced in this dissertation is used to develop the Archie tool suite. Archie is a plug-in for Eclipse and is designed to detect wide range of architectural design decisions in the code and to protect them from potential degradation during maintenance activities. It has several features for performing change impact analysis of architectural concerns at both the code and design level and proactively keep developers informed of underlying architectural decisions during maintenance activities. Archie is at the stage of technology transfer at the US Department of Homeland Security where it is purely used to detect and monitor security choices. Furthermore, this outcome is integrated into the Department of Homeland Security\u27s Software Assurance Market Place (SWAMP) to advance research and development of secure software systems

Negotiation of software requirements in an asynchronous collaborative environment

The effect of task structure and negotiation sequence on collaborative software requirements negotiation is investigated. This work began with an extensive literature review that focused on current research in collaborative software engineering and, in particular, on the negotiation of software requirements and the requisite collaboration for the development of such requirements. A formal detailed experiment was then conducted to evaluate the effects of negotiation sequence and task structure in an asynchronous group meeting environment. The experiment tested the impact of these structures on groups negotiating the requirements for an emergency response information system. The results reported here show that these structures can have a positive impact on solution quality but a negative impact on process satisfaction, although following a negotiation sequence and task structure can help asynchronous groups come to agreement faster. Details of the experimental procedures, statistical analysis, and discussion of the results of the experiment are also presented, as are suggestions for improving this work and a plan for future research

Requirements modelling of real-time systems

Real-time systems are characterised by the critical nature of their missions, and the demanding environment with which they interact. Real-time systems are used for dedicated applications. Every application is the subject of special requirements enforced by the customer. Considering the vital role that these systems play, it is imperative that a systematic approach be adopted in modelling their unique requirements. In this thesis I propose such a treatment. Real-time systems are time critical. Temporal requirements are the timing restrictions imposed by the application environment. Previous studies in requirements modelling of real-time systems have focused on adding the notion of time to modelling techniques of traditional systems without regard to the realities of requirements modelling. The information should be presented in the way the user handles it, and not the way which is convenient to the software engineer. I attempt to understand the needs of the users better by modelling the real world as close to the user's perspective as possible, and propose the Real World Model (RWM). RWM is assumed to be developed by users, and requirements engineers. An engineering approach to building the model is provided. A real-time system has a well defined use to its community. A requirements model must rely on the user level activities, and aid the human understanding and communication. In the RWM, a real-time system is viewed as a set of concurrently acting automata, each representing a system entity. This model supports temporal reasoning in easily described ways, for all classes of timing properties. A generalised classification of timing constraints is provided. A requirements modelling language facilitates the description of requirements, and serves as a medium of communication among developers and stakeholders. Jarke et al [Jarke 94] observe that there is a need for a requirements language that manages the relationship between the meta-level domain scheme, and the scenarios that actually instantiate the scheme under development. Here I propose Timed Requirements Language (TRL) to bridge this gulf between the world of stakeholders, and the world of specifiers. TRL has natural looking expressions for formulating the needs. TRL has a number of novel features including the treatment of causality, and the description of static, and dynamic constraints all integrated into one uniform framework. TRL has been used with a number of systems. The generality of the language is validated through its application to specific systems