In this paper we explore the notion of problem reduction as a systematic transformation from requirements to specifications. We adopt the notion of problem as a requirement in a real-world context for which a software solution is sought, and view the process of software development as a problem solving process, leading ultimately, and hopefully, to a solution which satisfies the requirement in its context. In this paper, we focus on how a solution specification can be derived from a requirement, and introduce problem reduction as a systematic transformation to achieve this. We reflect on how problem reduction captures requirements engineering practices, express it in the context of Problem Frames and provide a set of rules for its application. The intention of the work is to increase the understanding of the problem solving process as well as to provide techniques to support sound engineering practices.

Using patterns to preserve common problem-solving knowledge is a very popular approach. Each computer science community applies its own techniques to document engineering principles for the handling of recurring software development questions using patterns. Thus various pattern collections were evolved for dealing with specific problems of the respective community. As a result comparable patterns or redundant pattern descriptions exist in different collections leading unintentionally to a “reinvention of the wheel” time and again. Taking the development of a chat application as an example, we present an approach for integrating patterns from different software engineering disciplines. We transform problem patterns (problem frames) into solution patterns (design patterns) by using a case-based reasoning methodology to achieve a pattern-based software development process which systematically leads from natural language requirements to semi-formal near code level descriptions. We particularly consider non-functional software properties by combining design patterns of human-computer interaction (HCI) with software engineering (SE) patterns in order to support the systematic development of user-friendly software applications.

Requirements for product families are expressed in terms of commonality and variability. This distinction allows early identification of an appropriate software architecture and opportunities for software reuse. Feature diagrams provide intuitive notations and techniques for representing requirements in product line development. In this paper, we observe that feature diagrams tend to obfuscate three important descriptions: requirements, domain properties and specifications. As a result, feature diagrams do not adequately capture the problem structures that underlie variability, and inform the solution structures of their complexity. With its emphasis on separation of the three descriptions, the problem frames approach provides a conceptual framework for a more detailed analysis of variability and its structure. With illustrations from an example, we demonstrate how problem frames analysis of variability can augment feature diagrams. 1

We give an enumeration of possible problem frames, based on domain characteristics, and comment on the usefulness of the obtained frames. In particular, we investigate problem domains and their characteristics in detail. This leads to fine-grained criteria for describing problem domains. As a result, we identify a new type of problem domain and come up with integrity conditions for problem frames. Taking a complete enumeration of possible problem frames (with at most three problem domains) as a basis, we find 8 new problem frames, 7 of which we consider as useful in practical software development. 1

Active research is being done in how to go from requirements to architecture. However, no studies have been attempted in this area despite a long history of empirical research in software engineering (SE). Our goal is to establish a framework for the transformation from requirements to architecture on the basis of a series of empirical studies. The first step is to collect evidence about practice in industry before designing relevant techniques, methods and tools. As part of this step, we use an interview-based multiple-case study with a carefully designed process of conducting the interviews and of preparing the data collected for analysis while preserving its integrity. In this paper, we describe the design of this multiple-case study, delineate the evidence trail, discuss validity issues, outline the data analysis focus, discuss meta issues on evidence-based SE particularly on combining and using evidence, describe triangulation approaches, and present two methods for accumulating evidence. 1.

It is critical to decompose problem context of real world problems in order to understand requirements and specifications for IT systems. However, this is far from trivial. In this paper, we present an example problem domain contextual decomposition that provides a means of ensuring high-level requirements, such as business requirements, are met by lower-level requirements that are closer to the software to be delivered. We use Jackson’s Problem Frames approach to describe organisational context, and apply Architectural Frames (AFrames) to simultaneously decompose and simplify the problem context and hence requirements. Through AFrame application, and problem decomposition and projection, we show how socio-technical elements can also be described in our solution. We validate our approach through a case study taken from the literature of Seven-Eleven Japan. 1.

Inresponsetochangingrequirementsandotherenvironmental influences, software systems are increasingly developed incrementally. Successful implementation of new featuresinexistingsoftwareisoftendifficult,whilst manysoftware systems simply ‘break ’ when features are introduced. Size and complexity of modern software, poor software design, and lack of appropriate tools are some of the factors that often confound the issue. In this paper, we report on asuccessfulindustrialexperienceofevolvingafeature-rich programanalysistoolfordependablesoftwaresystems. The experience highlights the need for a development frameworktomaintainrichtraceabilitybetweendevelopmentartifacts, and to satisfy certain conditions of artifacts during andafterthe implementationofanewfeature. 1.

and other research outputs On the structure of problem variability: From feature diagrams to problem frames

and other research outputs