%0 Journal Article
%T Recovering Software Design from Interviews Using the NFR Approach: An Experience Report
%A Nary Subramanian
%A Steven Drager
%A William McKeever
%J Advances in Software Engineering
%D 2014
%I Hindawi Publishing Corporation
%R 10.1155/2014/124701
%X In the US Air Force there exist several systems for which design documentation does not exist. Chief reasons for this lack of system documentation include software having been developed several decades ago, natural evolution of software, and software existing mostly in its binary versions. However, the systems are still being used and the US Air Force would like to know the actual designs for the systems so that they may be reengineered for future requirements. Any knowledge of such systems lies mostly with its users and managers. A project was commissioned to recover designs for such systems based on knowledge of systems obtained from stakeholders by interviewing them. In this paper we describe our application of the NFR Approach, where NFR stands for Nonfunctional Requirements, to recover software design of a middleware system used by the Air Force called the Phoenix system. In our project we interviewed stakeholders of the Phoenix system, applied the NFR Approach to recover design artifacts, and validated the artifacts with the design engineers of the Phoenix system. Our study indicated that there was a high correlation between the recovered design and the actual design of the Phoenix system. 1. Introduction Design recovery in software systems involves obtaining design from artifacts such as code, system documentation, and execution environment, with the primary objectives being reduced maintenance costs, system enhancement, or system reengineering [1¨C3]. Design recovery is especially important for legacy systems where only a few software artifacts exist to aid their understanding: for example, there are systems that are decades old and will serve useful purposes if reengineered but whose only artifacts are limited documentation, a few stakeholders willing to share their experiences with the system, and the executable binary code [4]. Usual techniques for design recovery include code-based and domain knowledge-based techniques. Code-based techniques [4, 5] start with parsing the code and identifying elements and then obtain the design. In doing so an intermediate representation of the code is derived such as the hammock graphs, dependency graphs, or control flow graphs. However, as mentioned in [4], knowledge about architecture, design decisions, and design constraints cannot be fully obtained from code analysis alone. Domain knowledge-based techniques are used for program comprehension [6] that uses knowledge representation such as graphs and trees and apply classical reasoning techniques to retrieve design patterns; they are mostly used to augment
%U http://www.hindawi.com/journals/ase/2014/124701/