Problem frames provide a means of analyzing and decomposing

No abstract

Problem orientation is gaining interest as a way of approaching the development of software intensive systems and yet a significant example that explores its use is missing from the literature. In this paper, we present the basic elements of Problem Oriented Software Engineering (POSE) which aims to bring both non-formal and formal aspects of software development together in a single framework. We provide an example of a detailed and systematic POSE development of a software problem, that of designing the controller for a package router. The problem is drawn from the literature, but the analysis presented here is new. The aim of the example is twofold: to illustrate the main aspects of POSE and how it supports software engineering design, and to demonstrate how a non-trivial problem can be dealt with by the approach.

Government organizations continue to be heavily reliant on legacy systems to support their business-critical functions. When practitioners embark on legacy systems replacement projects, they tend to use the legacy software's features as business requirements for its replacement application. This unnecessarily reproduces the business processes that have often emerged from the very technical limitations of the legacy system that is being phased out -a phenomenon referred to as the "legacy problem." Public agencies are missing opportunities for innovation when they carry out legacy replacement projects in this conservative manner. Overcoming the legacy problem is "wickedly" difficult because of the complex interrelationships of information technology, organizational culture, and government agencies' normative environments. This paper reports on the use of an online survey and qualitative interviews with practitioners in government agencies to explore the legacy problem. The data revealed that public agencies tend to regard legacy system replacement projects as a distinctly technical issue, and that they do not engage in systematic practices to ensure that unnecessary carryover of the business model embedded in legacy technology does not take place. As a result, legacy feature carryover occurs frequently, because practitioners want to minimize business process changes during new system implementation. The study findings single out the procurement of Commercial Off The Shelf (COTS) software as the most common approach to the replacement of legacy systems. When COTS packages are implemented, vendors (technology providers) shape the requirements discussion and the business analysis surrounding feature selection and customization. These study findings can be instrumental when devising solutions to assist agencies in dealing with the legacy problem.

This paper presents a framework for understanding Problem Frames that locates them within the Requirements Engineering model of Zave and Jackson, and its subsequent formalization in the Reference Model of Gunter et al. It distinguishes between problem frames, context diagrams and problem diagrams, and allows us to formally define the relationship between them as assumed in the Problem Frames framework.The semantics of a problem diagram is given in terms of 'challenges', a notion that we also introduce. The notion of a challenge is interesting in its own right for two reasons: its proof theoretic derivation leads us to consider a challenge calculus that might underpin the Problem Frame operations of decomposition and recomposition; and it promises to extend the notion of formal refinement from software development to requirements engineering.In addition, the semantics supports a textual representation of the diagrams in which Problem Frames capture problems and their relationship to solutions. This could open the way for graphical Problem Frames tools.