Requirements Engineering Education in the 21st Century, an Experiential Learning Approach

RE use in industry is hampered by a poor understanding of RE practices and their benefits. Teaching RE at the university level is therefore an important endeavor. This education can ideally be provided at the university level as an integrated part of developing the requisite RE and software engineering technical skills, shortly before students become engineers and enter the workforce. However, much social wisdom is packed into RE methods. It is unrealistic to expect students with little organizational experience to understand this body of knowledge. The course described in this paper uses an active, affective, experiential pedagogy giving students the opportunity of experiencing a simulated work environment that demonstrates the social/design-problem complexities and richness of a development organization in the throws of creating a new product. Emotional and technical debriefing is conducted after each meaningful experience so that students and faculty, alike, can better understand the professional relevancies of what they have just experienced. This includes an examination of the many forces experienced in industrial settings but not normally discussed in academic settings. The course uses a low-tech social simulation rather than software simulation so that students learn through interaction with real people and therefore are confronted with the complexity of true social relationships

Experiential learning approach for requirements engineering education

The use of requirements engineering (RE) in industry is hampered by a poor understanding of its practices and their benefits. Teaching RE at the university level is therefore an important endeavor. Shortly before students become engineers and enter the workforce, this education could ideally be provided as an integrated part of developing the requisite business skills for understanding RE. Because much social wisdom is packed into RE methods, it is unrealistic to expect students with little organizational experience to understand and appreciate this body of knowledge; hence, the necessity of an experiential approach. The course described in this paper uses an active, affective, experiential pedagogy giving students the opportunity to experience a simulated work environment that demonstrates the social/design–problemcomplexities and richness of a development organization in the throes of creating a new product. Emotional and technical debriefing is conducted after each meaningful experience so that students and faculty, alike can better understand the professional relevancies of what they have just experienced. This includes an examination of the many forces encountered in industrial settings but not normally discussed in academic settings. The course uses a low-tech social simulation, rather than software simulation, so that students learn through interaction with real people, and are therefore confronted with the complexity of true social relationships

Modeling Service-Level Requirements: a Constancy Perspective

IT service requirements offer a seemingly classic Requirements Engineering (RE) problem. But, when attempting to solve it with RE methods, we are faced with difficulties. RE methods encourage us to identify the functional and non-functional requirements of a service. Industrial service-management frameworks, however, use a different vocabulary. ITIL, one of the most prominent service-management frameworks, refers to service utilities and service warranties. In this paper, we propose a method for modeling warranties as a function of the service constancy expected by stakeholders and the threats to this constancy. We identify four kinds of warranties: express, implied, tacit and pending. We thereby seek to bridge the gap between service-management frameworks and RE methods and to improve the practice of service management in organizations

Exploring Requirements : Quality Before Design

New Yorkxvii, 290 p.: illus.; 25 cm

Creativity and the Age-Old Resistance to Change Problem in RE

Creativity is about bringing unforeseen change to habitual ways of doing things. Understanding the challenges of introducing innovation in organizations is, therefore, essential during the requirements phase of today’s computer systems design projects. However, there are many legitimate obstacles to creativity. To explain some of them, we explore creativity in terms of change to norms that are well accepted in an organization. These norms are grounded in the worldview of the organization. Creativity is therefore constrained by the amount of change that can be made to norms and worldview. We describe some of the mechanisms that work in favor and against change and offer suggestions on how to make better use of these mechanisms in introducing currently accepted and recently developed RE methodologies into mainstream commercial systems design approaches

Toward a Service Management Quality Model

[Context and motivation] Service Management has been steadily gaining in importance in many organizations and is becoming a major force of change in IT departments. ITIL, one of the main service management frameworks, defines the value of a service for its customers as the sum of the service utilities and service warranties but provides no specific rules for defining them. [Question/problem] Companies, IT departments and their consultants face difficulties defining utilities and warranties, as well as identifying their value for customers. [Principal ideas/results] We propose a general framework for understanding service requirements and for analyzing the quality of a service. The framework is based on General Systems Thinking. We define service utilities as norms created by the service for a given stakeholder. Service warranties then protect the stakeholder from variations of these norms as a result of threats. Value is created when the norms are maintained within the tolerance range of the stakeholder. Risk is defined as the possibility of detrimental consequences for a stakeholder if the norm is pushed outside its tolerance range. [Contribution] We believe that this work has the potential to advance theory and practice of service management in both academia and industry, and to reduce the risk of overlooking important service properties when defining service requirements

Empirical validation of the Classic Change Curve on a software technology change project.

a b s t r a c t Context: New processes, tools, and practices are being introduced into software companies at an increasing rate. With each new advance in technology, software managers need to consider not only whether it is time to change the technologies currently used, but also whether an evolutionary change is sufficient or a revolutionary change is required. Objective: In this paper, we approach this dilemma from the organizational and technology research points of view to see whether they can help software companies in initiating and managing technology change. In particular, we explore the fit of the technology S-curve, the Classic Change Curve, and a technological change framework to a software technology change project and examine the insights that such frameworks can bring. Method: The descriptive case study described in this paper summarizes a software technology change project in which a 30-year old legacy information system running on a mainframe was replaced by a network server system at the same time as the individual-centric development practices were replaced with organization-centric ones. The study is based on a review of the company's annual reports, in conjunction with other archival documents, five interviews and collaboration with a key stakeholder in the company. Results: Analyses of the collected data suggest that software technology change follows the general change research findings as characterized by the technology S-curve and the Classic Change Curve. Further, that such frameworks present critical questions for management to address when embarking on and then running such projects. Conclusions: We describe how understanding why a software technology change project is started, the way in which it unfolds, and how different factors affect it, are essential tools for project leaders in preparing for change projects and for keeping them under control. Moreover, we show how it is equally important to understand how software technology change can work as a catalyst in revitalizing a stagnated organization, facilitating other changes and thereby helping an organization to redefine its role in the marketplace