The treatment of non-functional requirements in MIKE

... this paper it is shown how non-functional requirements are modelled in MIKE, an approach to the development of knowledge-based systems. A semi-formal hypermedia-based model is used to describe the results of the elicitation and interpretation of non-functional requirements and their relationships. Non-functional requirements are the driving force behind the decisions taken in the design phase of MIKE. The impact of non-functional requirements on design decisions and interdependencies between design decisions are explicitly recorded in an additional model in MIKE, thus resulting in a rich documentation of the rationale of design decisions and also providing an important contribution to the traceability of these requirement

Traceability for Model Driven, Software Product Line Engineering

Traceability is an important challenge for software organizations. This is true for traditional software development and even more so in new approaches that introduce more variety of artefacts such as Model Driven development or Software Product Lines. In this paper we look at some aspect of the interaction of Traceability, Model Driven development and Software Product Line

Requirements traceability in model-driven development: Applying model and transformation conformance

The variety of design artifacts (models) produced in a model-driven design process results in an intricate relationship between requirements and the various models. This paper proposes a methodological framework that simplifies management of this relationship, which helps in assessing the quality of models, realizations and transformation specifications. Our framework is a basis for understanding requirements traceability in model-driven development, as well as for the design of tools that support requirements traceability in model-driven development processes. We propose a notion of conformance between application models which reduces the effort needed for assessment activities. We discuss how this notion of conformance can be integrated with model transformations

A design recording framework to facilitate knowledge sharing in collaborative software engineering

This paper describes an environment that allows a development team to share knowledge about software artefacts by recording decisions and rationales as well as supporting the team in formulating and maintaining design constraints. It explores the use of multi-dimensional design spaces for capturing various issues arising during development and presenting this meta-information using a network of views. It describes a framework to underlie the collaborative environment and shows the supporting architecture and its implementation. It addresses how the artefacts and their meta-information are captured in a non-invasive way and shows how an artefact repository is embedded to store and manage the artefacts

Traceability and AOSD - From Requirements to Aspects

The traceability question is addressed through the development of a framework to go from requirements to aspects using the Design by Contract methodology. It is demonstrated that by starting at the requirements stage, and specifying an early aspect in the same semi-formal language as the system's existing requirements, we have the basis from which to design the aspects at the implementation stage. The language of pre- and post-conditions is shown to match closely that of aspects, in that pre-conditions match the aspect's pointcut, and the post-condition matches the advice part of the aspect. This thus gives us traceability from 'early aspects' to 'late aspects'. This approach will shed some light on the relationship between requirements and their refinements to pre- and post conditions, and the traceability of requirements in the face of reuse over time. The addition of a new crosscutting requirement is investigated in terms of the framework, demonstrating the relationship between early and late aspects and traceability. The framework promises to help with the design of the late aspects. We propose the concept of relevancy: information in a requirement beyond its specification as pre- and post-conditions, as a way of identifying join points

Knowledge re-use for decision support

Effective decision support has already been identified as a fundamental requirement for the realisation of Network Enabled Capability. Decision making itself is a knowledge-intensive process, and it is known that right decisions can only be reached based on decision maker's good judgement, which in turn is based on sufficient knowledge. It is not unusual for decision makers to make incorrect decisions because of insufficient knowledge. However, it is not always possible for decision makers to have all the knowledge needed for making decisions in complex situations without external support. The re-use of knowledge has been identified as providing an important contribution to such support, and this paper considers one, hitherto unexplored, aspect of how this may be achieved. This paper is concerned with the computational view of knowledge re-use to establish an understanding of a knowledge-based system for decision support. The paper explores knowledge re-use for decision support from two perspectives: knowledge provider's and knowledge re-user's. Key issues and challenges of knowledge re-use are identified from both perspectives. A structural model for knowledge re-use is proposed with initial evaluation through empirical study of both experienced and novice decision maker's behaviour in reusing knowledge to make decisions. The proposed structural model for knowledge re-use captures five main elements (knowledge re-uers, knowledge types, knowledge sources, environment, and integration strategies) as well as the relationships between the elements, which forms a foundation for constructing a knowledge-based decision support system. The paper suggests that further research should be investigating the relationship between knowledge re-use and learning to achieve intelligent decision support

The documentation of design decisions in engineering projects: A study in infrastructure development

In most design projects, the documentation of design decisions is considered important. Among others, documentation of design decisions contributes to the traceability of decisions that shape a project’s development process, helps deal with changes in the project and prevents the recurrence of old discussions. Yet, little attention is given to documenting design decisions in civil engineering literature. In this study, a theoretical framework for the key elements of this documentation process was developed. Four road infrastructure projects were studied and compared to this framework by means of pattern matching. This method compares theoretical and empirical patterns and determines whether they match or do not match. The findings demonstrate that accessibility of documentation for all involved project parties and division of documentation tasks are in accordance with literature. However, the documentation of design decisions and their rationale is not done as completely as is recommended in theory. Literature states that the documentation of interrelations and context of decisions should be described thoroughly, but that is barely done in practice. In addition, the findings show that neither immediate documentation, nor periodical monitoring of documentation is applied. Based on these findings, this research proposes a strategy for improving the documentation of design decisions

Extended requirements traceability: results of an industrial case study

Contribution structures offer a way to model the network of people who have participated in the requirements engineering process. They further provide the opportunity to extend conventional forms of artifact-based requirements traceability with the traceability of contributing personnel. In this paper, we describe a case study that investigated the modeling and use of contribution structures in an industrial project. In particular, we demonstrate how they made it possible to answer previously unanswerable questions about the human source(s) of requirements. In so doing, we argue that this information addresses problems currently attributed to inadequate requirements traceability