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

Arguing security: validating security requirements using structured argumentation

This paper proposes using both formal and structured informal arguments to show that an eventual realized system can satisfy its security requirements. These arguments, called 'satisfaction arguments', consist of two parts: a formal argument based upon claims about domain properties, and a set of informal arguments that justify the claims. Building on our earlier work on trust assumptions and security requirements, we show how using satisfaction arguments assists in clarifying how a system satisfies its security requirements, in the process identifying those properties of domains that are critical to the requirements

Arguing satisfaction of security requirements

This chapter presents a process for security requirements elicitation and analysis, based around the construction of a satisfaction argument for the security of a system. The process starts with the enumeration of security goals based on assets in the system, then uses these goals to derive security requirements in the form of constraints. Next, a satisfaction argument for the system is constructed, using a problem-centered representation, a formal proof to analyze properties that can be demonstrated, and structured informal argumentation of the assumptions exposed during construction of the argument. Constructing the satisfaction argument can expose missing and inconsistent assumptions about system context and behavior that effect security, and a completed argument provides assurances that a system can respect its security requirements

Implicit thinking knowledge injection framework for Agile requirements engineering

Agile has become commonly used as a software development methodology and its success depends on face-to-face communication of software developers and the faster software product delivery. Implicit thinking knowledge has considered as a very significant for organization self-learning. The main goal of paying attention to managing the implicit thinking knowledge is to retrieve valuable information of how the software is developed. However, requirements documentation is a challenging task for Agile software engineers. The current Agile requirements documentation does not incorporate the implicit thinking knowledge with the values it intends to achieve in the software project. This research addresses this issue and introduce a framework assists to inject the implicit thinking knowledge in Agile requirements engineering. An experiment used a survey questionnaire and case study of real project implemented for the framework evaluation. The results show that the framework enables software engineers to share and document their implicit thinking knowledge during Agile requirements documentation

Hypermedia support for argumentation-based rationale: 15 years on from gIBIS and QOC

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

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

An Ontological Framework for Knowledge Management in Systems Engineering Processes

ISBN:978-953-7619-94-7, pp.149-168Systems Engineering (SE) processes comprise highly creative and knowledge-intensive tasksthat involve extensive problem-solving and decision-making activities amonginterdisciplinary teams (Meinadier, 2002). SE projects involve the definition of multipleartifacts that present different formalization degrees, such as requirements specification,system architecture, and hardware/ software components. Transitions between the projectphases stem from decision making processes supported both by generally available domainand design knowledge.We argue that Knowledge about engineering processes constitutes one of the most valuableassets for SE organizations. Most often, this knowledge is only known implicitly, relyingheavily on the personal experience background of system engineers. To fully exploit thisintellectual capital, it must be made explicit and shared among project teams. Consistentand comprehensive knowledge management methods need to be applied to capture andintegrate the individual knowledge items emerging in the course of a system engineeringproject