Problem Frames for Sociotechnical Systems

This chapter introduces Problem Frames as a framework for the analysis of sociotechnical problems. It summarizes the Problem Frames approach, its techniques and foundations, and demonstrates, through theory and examples, how it can be applied to simple sociotechnical systems. The chapter continues with the description of an extended Problem Frame framework that allows the treatment of more general sociotechnical problems. This extension covers social components of a system — individuals, groups or organisations — bringing them within the remit of the design activity. The aim of the chapter is to make the Problem Frames framework more accessible to the software practitioner, especially those involved in the analysis of sociotechnical problems, as these problems have so far received only scant coverage in the Problem Frames literature.

Collaborative Requirements Definition Processes in Open Source Software Development

This chapter discusses typical collaborative requirements definition processes as they are performed in open source software development (OSSD) projects. In the beginning, some important aspects of the entire OSSD approach are introduced in order to enable an understanding of the subsequent description of the feedback-based requirements definition processes. Since the OSSD model seems to represent a successful way of dealing with the significant distribution and heterogeneity of its actors, some opportunities to adapt this approach also in other (software) industries are discussed. Nevertheless the entire OSSD model still exhibits several improvement opportunities that also are addressed in this chapter. In order to overcome possible weaknesses, several approaches to improve the described requirements definition approach are introduced. These improvements help to assure a higher level of efficiency and quality assurance for both processes and the developed artifacts, and furthermore also enable the consideration and acceptance of this approach in other domains and industries.

Requirements Engineering for Courseware Development

Technology-enabled learning using the Web and the computer and courseware, in particular, is becoming more and more important as an addition, extension, or replacement of traditional further education measures. This chapter introduces the challenges and possible solutions for requirements engineering (RE) in courseware development projects. First the state-of-the-art in courseware requirements engineering is analyzed and confronted with the most important challenges. Then the IntView methodology is described as one solution for these challenges. The main features of IntView RE are: support of all roles from all views on courseware RE; focus on the audience supported by active involvement of audience representatives in all activities; comprehensive analysis of the sociotechnical environment of the audience and the courseware as well as of the courseware learning context; coverage of all software RE activities; and development of an explicit requirements specification documentation.

Requirements Engineering

This chapter introduces requirements engineering for sociotechnical systems. Requirements engineering for sociotechnical systems is a complex process that considers product demands from a vast number of viewpoints, roles, responsibilities, and objectives. This chapter explains the requirements engineering terminology and describes the requirements engineering process in detail, with examples of available methods for the main process activities. The main activities described include system requirements development, requirements allocation and flow-down, software requirements development, and continuous activities, including requirements documentation, requirements validation and verification, and requirements management. As requirements engineering is the process with the largest impact on the end product, it is recommended to invest more effort in both industrial application as well as research to increase understanding and deployment of the concepts presented in this chapter.

RESCUE

This chapter describes RESCUE (Requirements Engineering with Scenarios for a User-centred Environment), a method for specifying requirements for complex sociotechnical systems that integrates human activity modeling, creative design workshops, system goal modeling using the i* notation, systematic scenario walkthroughs, and best practice in requirements management. This method has been, and is being applied in, specifying requirements for three separate systems in the domain of air traffic control. In this chapter we present examples showing how the method can be applied in the context of a case study involving the specification of requirements for Countdown, a system to provide bus passengers with information about expected bus arrival times. While this system shares some important similarities with systems used in air traffic control, we hope it is small and familiar enough to readers to provide meaningful insights into the application of the RESCUE process.

Requirements Engineering for Technical Products

Over the last few years the functionality and complexity of technical products has increased dramatically. This is reflected in the complexity of the development process. In this chapter we discuss in detail the resulting challenges that have to be faced by requirements engineering. We identified these challenges in interviews conducted at a German car manufacturer. The main part of this chapter presents the QUASAR requirements engineering process that faces all identified challenges. In particular, it supports: (1) a set of views and abstraction levels tailored to the stakeholders, (2) communication about these views through understandable notations, (3) efficient access based on tools and traces that make relationships between views explicit, (4) explicit feedback based on inspection and simulation, and (5) overall quality by integrating a formal specification technique with informal, textual specification techniques as well as through guidelines, checklists and tailored review techniques.

Combining Requirements Engineering and Agents

The concept of Agent is being used with different meanings and purposes in two separate fields of software engineering, namely Requirements Engineering and Agent-Oriented Software Engineering. After an introduction to Goal-Oriented Requirements Engineering (GORE) and its evolution into Agent-Oriented Requirements Engineering (AORE), this chapter provides a review of some of the main Agent-Oriented Software Engineering (AOSE) methodologies, focusing on their support for requirements modeling. Then the chapter analyzes how both approaches to Agents relate to each other, what the differences are among them, and how they could benefit from each other. Problems are identified and discussed that need to be addressed for a successful integration of both fields, and recommendations are provided to advance in this direction.

Capture of Software Requirements and Rationale through Collaborative Software Development

This chapter explains how natural language processing (NLP) and participatory design can aid in identifying system requirements. It argues that getting a complete list of requirements is often an iterative process in which some requirements are elicited only when users react to the system’s design. Costs of iterative requirements identification can be reduced by discovering new requirements during the design process, before implementation begins. This is facilitated when users participate in design, reacting to features as they are proposed. As users evaluate proposals, they often mention requirements not previously documented. Transcripts of participatory design sessions thus provide a rich source of new requirements for developers. The chapter explains how semantic grammars can be used to simplify the extraction of requirements from such transcripts. The authors hope that an understanding of the value of participatory design and NLP will aid in the creation of better tools for support of software development.

Elicitation and Documentation of Non-Functional Requirements for Sociotechnical Systems

This chapter describes how non-functional requirements (NFR) can be elicited and documented in the context of sociotechnical systems. An approach is presented based on use cases and on quality models derived from ISO 9126, as well as general problems and challenges when working with NFR. Requirements in general and NFR in particular are subjective, have many stakeholders and are often conflicting. The approach presented includes processes for prioritizing quality attributes that are important to a specific context, eliciting NFR, and identification and analysis of dependencies among the NFR. The aim is to provide an experience-based approach that facilitates efficient and effective elicitation and documentation of NFR. Having a structured method that aims at providing measurable, traceable, and focused requirements rather than having ad-hoc and ambiguous ones achieves this. The approach uses use cases as the main technique, though the general principle of having a structured and experience-based process is applicable to other techniques as well.

Using Scenarios and Drama Improvisation for Identifying and Analysing Requirements for Mobile Electronic Patient Records

This chapter presents two different techniques for elicitation and analysis of requirements for a mobile electronic patient record (EPR) to be used in hospital wards. Both techniques are based on human-centred and participatory design principles. The first technique uses observational studies as a basis for identifying and analysing requirements for a mobile EPR. The observations are structured and systematised through a framework. The second technique is named “Creative system development through drama improvisation”, and it enables users (in this case healthcare professionals) to contribute to the requirements engineering (RE) process by acting out everyday work situations in one-day workshops. Both techniques presented in this chapter focus on user requirements elicitation, and we believe that they are promising and complementary contributions to more traditional requirements elicitation and analysis methods, not only for hospital information systems but for a wide variety of complex, sociotechnical systems.