3rd international workshop on advances and applications of problem frames

Michael Jackson's Problem Frames are a highly promising approach to early life-cycle software engineering. Their focus moves the engineer back to the problem to be solved rather than forward to the software and solving a poorly defined problem. By applying the Problem Frames approach, the software engineer can understand the problem context and how it is to be affected by the proposed software, and ultimately work towards the right solution for the problem. The influence of the Problem Frames approach and related work is spreading in the fields of domain modelling, business process modelling, requirements engineering, software architecture as well as software engineering in general

A roadmap of problem frames research

It has been a decade since Michael Jackson introduced problem frames to the software engineering community. Since then, he has published further work addressing problem frames as well as presenting several keynote addresses. Other authors have researched problem frames, have written about their experiences and have expressed their opinions. It was not until 2004 that an opportunity presented itself for researchers in the field to gather as a community. The first International Workshop on Advances and Applications of Problem Frames (IWAAPF'04) was held at the International Conference on Software Engineering in Edinburgh on 24th May 2004. This event attracted over 30 participants: Jackson delivered a keynote address, researchers presented their work and an expert panel discussed the challenges of problem frames. Featuring in this special issue are two extended papers from the workshop, an invited contribution from Jackson in which he positions problem frames in the context of the software engineering discipline, and this article, where we provide a review of the literature

Requirements Engineering as Creative Problem Solving: A Research Agenda for Idea Finding

This vision paper frames requirements engineering as a creative problem solving process. Its purpose is to enable requirements researchers and practitioners to recruit relevant theories, models, techniques and tools from creative problem solving to understand and support requirements processes more effectively. It uses 4 drivers to motivate the case for requirements engineering as a creative problem solving process. It then maps established requirements activities onto one of the longest-established creative problem solving processes, and uses these mappings to locate opportunities for the application of creative problem solving in requirements engineering. The second half of the paper describes selected creativity theories, techniques, software tools and training that can be adopted to improve requirements engineering research and practice. The focus is on support for problem and idea finding - two creative problem solving processes that our investigation revealed are poorly supported in requirements engineering. The paper ends with a research agenda to incorporate creative processes, techniques, training and tools in requirements projects

Supporting reflection and creative thinking by carers of older people with dementia

This vision paper frames requirements engineering as a creative problem solving process. Its purpose is to enable requirements researchers and practitioners to recruit relevant theories, models, techniques and tools from creative problem solving to understand and support requirements processes more effectively. It uses 4 drivers to motivate the case for requirements engineering as a creative problem solving process. It then maps established requirements activities onto one of the longest-established creative problem solving processes, and uses these mappings to locate opportunities for the application of creative problem solving in requirements engineering. The second half of the paper describes selected creativity theories, techniques, software tools and training that can be adopted to improve requirements engineering research and practice. The focus is on support for problem and idea finding - two creative problem solving processes that our investigation revealed are poorly supported in requirements engineering. The paper ends with a research agenda to incorporate creative processes, techniques, training and tools in requirements projects

Are your lights off? Using problem frames to diagnose system failures

This paper reports on our experience of investigating the role of software systems in the power blackout that affected parts of the United States and Canada on 14 August 2003. Based on a detailed study of the official report on the blackout, our investigation has aimed to bring out requirements engineering lessons that can inform development practices for dependable software systems. Since the causes of failures are typically rooted in the complex structures of software systems and their world contexts, we have deployed and evaluated a framework that looks beyond the scope of software and into its physical context, directing attention to places in the system structures where failures are likely to occur. We report that (i) Problem Frames were effective in diagnosing the causes of failures and documenting the causes in a schematic and accessible way, and (ii) errors in addressing the concerns of biddable domains, model building problems, and monitoring problems had contributed to the blackout

Business goals, user needs, and requirements: A problem frame-based view

Background: It is well known that the analysis of requirements involves several stakeholders and perspectives. Very often several points of view at different abstraction levels have to be taken into account: all these features make requirements analysis a complex task. Such intrinsic complexity makes it difficult to understand several of the basic concepts that underlie requirements engineering. Actually, there is some confusion \u2013especially in industry\u2013 about what really a user requirement is, what are the differences between user requirements and user needs, and what are their relationships with business processes. Objective: The paper aims at clarifying the aforementioned issues, by providing a systematic and clear method for establishing requirements hierarchies. Method: The problem of describing requirements hierarchies is tackled using the problem frames concepts and notation. A case study is used throughout the paper to illustrate the proposed approach. Results: The description of requirements at different levels of abstractions and requirements hierarchies are illustrated. The resulting models are coherent with the reference model for requirements specifications and the problem frames. An analysis process that is aware of the differences between user needs and requirements is also provided, to illustrate the process of refining high-level goals into requirements that can be satisfied by a hardware/software machine. Conclusions: The proposed method appears promising to model, study and evaluate the relationships between business processes and the strategies for achieving business goals based on the usage of information technology

Using problem descriptions to represent variabilities for context-aware applications

This paper investigates the potential use of problem descriptions to represent and analyse variability in context-aware software products. By context-aware, we refer to recognition of changes in properties of external domains, which are recognised as affecting the behaviour of products. There are many reasons for changes in the operating environment, from fluctuating resources upon which the product relies, to different operating locations or the presence of objects. There is an increasing expectation for software intensivedevices to be context-aware which, in turn, adds further variability to problem description and analysis. However, we argue in this paper that the capture of contextual variability on current variability representations and analyses has yet to be explored. We illustrate the representation of this type of variability in a pilot study, and conclude with lessons learnt and an agenda for further work

On the structure of problem variability: From feature diagrams to problem frames

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