This paper elucidates problems with communication about requirements in a complex program in a large organization. Our insights are rooted in experiences we, as industrial practitioners, have had in our extensive involvement in a specific program in which we delivered software consultancy services to an industrial client. Throughout this involvement, we encountered significant problems, which caused insufficient requirements engineering. Our efforts to communicate effectively about requirements proved to be inadequate. Although some problems could have been addressed with established requirements engineering techniques, we have not been able to convince key stakeholders to allow us to apply such techniques to the desired extent. The main contribution of this paper is five lessons about our insufficient understanding of key stakeholders' interests and about the impact both the program organization and the overall company organization had on the possibilities for and limitations of effective communication about requirements.

During the last four years, Mjølner Informatics has developed mobile banking apps for 11 Danish banks on the two major platforms iOS and Android, in total 22 apps. We make two contributions with this industrial practice paper. In the first place, we describe the development of these apps with emphasis on issues regarding variability handling and maximizing reuse. Secondly, we discuss a number of lessons learned from this process. This includes consideration of how ready we are to possible future challenges regarding variability and observation of significant differences between the two platforms.

In August 2013, our company started work for an industrial customer. First, we developed a prototype and conducted field studies in small-scale projects. This was successful and the basis for a larger project about development of a new user interface for healthcare equipment. A main aim for us was to use this project as starting point for establishing a strategic, long-term relationship with this customer. However, we were not successful. In November 2014, our customer chose to take over the development themselves. We were too expensive, used too many hours and were not able to provide useful estimates, they said. In this paper, we describe the project and analyze causes to our customer's decision. We also look at possible alternatives to the actions we took in the project and discuss whether we could have done better. A root cause to our customer's dissatisfaction is related to requirements and handling of requirements.

Bankdata and Mjølner have cooperated in the development of a new feature for 12 Danish mobile banking apps. Bankdata is the main system provider and Mjølner is subcontractor. Different teams from Bankdata have collected requirements, developed the necessary backend and middleware software, and designed the user interface. One team from Mjølner has implemented the app feature. The cooperation between the teams was centered around design-level requirements. Our contribution is to describe and discuss a number of lessons learned regarding requirements representations, requirements tools, and cooperation process; we have faced challenges, which were amplified by our distributed teams set-up. We also briefly describe a number of initiatives we have launched recently to alleviate the problems and improve the handling of design-level requirements in our future cooperation.

Abstract: To address a frame concern in Jackson's problem frames, we must make appropriate descriptions of (1) the problem domain; (2) the requirements; (3) the specification of the machine. Based on these descriptions, we must give a convincing argument that the given domain properties and the machine specification together entail that the requirements are fulfilled. In this paper, we demonstrate how to address certain frame concerns with the use of the formal modelling language coloured Petri nets (CPN). Problem domain description and machine specification are brought together in a CPN model, which is augmented with a graphical animation. The CPN model is executable and we simulate it to address frame concerns. We illustrate the approach on the elevator controller example.

This paper presents a model-based approach to requirements engineering for reactive systems; we use an elevator controller as case study. We identify and justify two key properties that a model which we construct must have, namely: (1) controller-and-environment-partitioned, which means constituting a description of both the controller and the environment, and distinguishing between these two domains and between desired and assumed behaviour; (2) use case-based, which means constructed on the basis of a given use case diagram and reproducing the behaviour described in accompanying scenario descriptions. For the case study, we build an executable model in the formal modelling language coloured Petri nets. We demonstrate how this model is useful for requirements engineering, since it provides a solid basis for addressing behavioural issues early in the development process, for example regarding concurrent execution of use cases and handling of failures.

A context-descriptive prototype is an interactive graphical animation, driven by a formal, executable engine, implemented in some programming or modelling language. The two main properties of a context-descriptive prototype are: (1) it is an integrated description that describes system, work processes, and context of use; (2) it is a formal description. Because of (1), designers, including users, are provided with a means to investigate the system in the context of the envisioned work processes. Because of (2), investigations into questions of formalisation and automation, not only of the system, but also of the work processes, can be made explicitly and become subject for discussions and further elaboration. We describe a concrete context-descriptive prototype of the hospital work process medicine administration and its support by a new pervasive system. We discuss findings from evaluation of the prototype in cooperation with nurses, and finally compare context-descriptive prototypes with other kinds of prototypes.

We describe requirements engineering for a new pervasive health care system for hospitals in Denmark. The chosen requirements engineering approach composes iterative prototyping and explicit environment description in terms of workflow modelling. New work processes and their proposed computer support are represented via a combination of prose, formal models, and animation. The representation enables various stakeholders to make interactive investigations of requirements for the system in the context of the envisioned work processes. We describe lessons learned from collaboration between users and system developers in engineering the requirements for the new system.

In this paper, we present a computer tool for verification of distributed systems. As an example, we establish the correctness of Lamport's Fast Mutual Exclusion Algorithm. The tool implements the method of occurrence graphs with symmetries (OS-graphs) for Colored Petri Nets (CP-nets). The basic idea in the approach is to exploit the symmetries inherent in many distributed systems to construct a condensed state space. We demonstrate a significant increase in the number of states which can be analyzed. The paper is to a large extent self-contained and does not assume any prior knowledge of CP-nets (or any other kinds of Petri Nets) or OS-graphs. CP-nets and OS-graphs are not our invention. Our contribution is the development of the tool and verification of the example, demonstrating how the method of occurrence graphs with symmetries can be put into practice.