Abstract. Changes in requirements are inevitable in the context of socio-technical systems (STS) that involve human organizations with their rules, as well as in-.
Evolving Requirements in Socio-Technical Systems: Concepts and Practice Anna Perini, Nauman Qureshi, Luca Sabatucci? , Alberto Siena, and Angelo Susi Fondazione Bruno Kessler - IRST, Center for Information Technology (CIT) Via Sommarive, 18, 38050 Trento, Italy {perini,qureshi,sabatucci,siena,susi}@fbk.eu
Abstract. Changes in requirements are inevitable in the context of socio-technical systems (STS) that involve human organizations with their rules, as well as individuals and software systems. In these complex systems need for changes may emerge once software components come into operation, due to undesirable behavior of the STS, or due to variations in organization rules, laws, resources and STS’s components themselves. This leads to a problem of continuous analysis of evolving requirements in a traceable way. Our work is motivated by experience in a real project in the health-care domain, and in analysis practices based on participatory design methods (scenarios and personas) and on techniques for law-compliant requirements analysis. We revisit this experience and generalize it into a novel framework that provides concepts and practices to support an evolutionary and “participatory” process for requirements evolution in STS.
Keywords: Evolving Requirements, Participatory Design, Law Compliance
1
Introduction
The increasing use of software systems in our daily life results into stronger and stronger integration of human and systems tasks, leading to form the so called socio-technical systems (hereafter, STS). Such systems incorporate different components, such as application domain’s stakeholders (humans and organization), software system and resources, each playing its own roles to achieve common objectives. For instance, in the health-care domain, a Social Residence STS is defined by the patients and their relatives, doctors, nurses and software systems, each playing pre-defined roles and collaborating to support patients lives. In STS, requirements do change overtime. Such changes may be caused by a variety of factors, which may be broadly classified as changes in: the operational environment (e.g. new or alternative technology or new usage conditions); in the organization within which the system is used (e.g. new organizational structure and procedures, new regulations); and in user’s needs (e.g. new functional feature, new class of users as well ?
L. Sabatucci has been partially supported by the ACube project founded by the Autonomous Province of Trento, Italy
as new users’ preferences or way to do things). This leads to the problem of managing changes in requirements that emerge once the STS is in operation, and to the more general problem of software evolution. A rich research agenda for requirements evolution has been recently proposed [2]. It includes the need of (i) defining infrastructures for requirements evolution that accommodate other kinds of artifacts beside code; (ii) revising taxonomies for root causes for change, taking into account new challenges posed by today socio-technical systems; (iii) defining evolution mechanisms, both manual and automated; (iv) defining new viable frameworks at support of design for evolution and (v) evolutionary design. Our work builds around the points (i), (iii) — (v), and is motivated by experience in a real project in the health-care domain, called Ambient Aware Assistance - ACube1 and by experience in analysis practice based on participatory design methods for the active involvement of stakeholders in design decisions [1, 6] and on techniques for the analysis of law-compliant requirements [10]. Needs for requirements change and system evolution in ACube emerged when focusing on the trade-off between having the STS behaving in a law-compliant way and satisfying the ultimate goal of the Social Residence STS itself, that is to create an environment which is more responsive and appropriate to their inhabitants’ and users’ cultural, emotional, spiritual and practical needs. We investigate methods that can be used to support the analysis of these types of requirements changes and ultimately on system evolution, with the involvement of key stakeholders. In this paper, we revisit this experience and generalize it into a novel framework, we call it CAFfE (Concepts and Analysis Framework for Evolving requirements), which provides concepts and analysis techniques to support an evolutionary and “participatory” process for requirements evolution in STS. Novelty in our framework stems from the fact that: (i) we adopt a participatory design approach as process backbone, to enable the participation of stakeholders in design activities [1, 6, 5], including the software systems (within the STS). Participatory design provides peculiar techniques for engaging participants, such as scenarios and of “persona” (sort of fictional user) or ethnographic study techniques; (ii) we allow for the integration of specialized techniques, which are suitable for the analysis of particular concerns, as for instance law-compliance; and (iii) we aim at ensuring traceability across heterogeneous artifacts. The rest of the paper is organized as follows: in Section 2, we present the context of our work. In section 3, we detail our conceptual analysis framework for evolving requirements. In section 4, we instantiate this framework using participatory design methods (e.g. focus group workshops) and the law-compliant requirements modeling framework Nomos [10]. Related work is discussed in section 5. Conclusion and future work are outlined in section 6.
2
Context
Ambient Aware Assistance: ACube is an ambient aware middleware, which is integrated into a Social Residence STS. It provides monitoring and event detection capa1
See http://acube.fbk.eu/ for details about the project.
bilities, which support the caregivers activities in the physical environment of the social residence, where patients with cognitive problems (some more severe than others, namely Alzheimer) live, assisted by caregivers. The Social Residence STS is characterized by the strong integration of social and technological dimensions. The social dimensions encompass the organizational setting with rules and humans, each one playing a role (patients, caregivers, nurses, doctors and managers). The technological dimension concerns software and hardware systems of the ACube middleware, e.g. sensors, video cameras, automatic doors. A first version of ACube system (ACube1 hereafter) is currently in operation. Emerging requirements: there are particular situations where, in spite of ACube1, human efforts to perform activities and relative time consumption are still relevant. For example, in case of emergencies, where a patient requires an immediate medication and caregivers or nurses are not authorized unless the doctor is present, or, in cases of monitoring, when crucial issues related to law compliance (e.g. privacy) can arise. More generally, undesirable behaviors of the Social Residence STS may occur, leading to the emergence of new requirements that call for an evolution of the technological components (ACube1), or of the whole STS.
3
Towards a Conceptual and Analysis Framework for Evolving Requirements (CAFfE)
Elaborating our experience in the ACube project, we identified a set of concepts, analysis methods and process steps that all together define a general framework for requirements evolution in STS, called CAFfE. CAFfE aims at supporting the analysis of the problem and of the solution space for the purpose of enabling requirements evolution. When need for requirements change emerges, the system analysts are involved for understanding causes of changes (by analyzing the problem space) and to identify possible evolutions of system requirements and associated solutions (within the solution space), through a “participatory” process that involves all the STS elements and the engineers who developed the technological elements. Being a fragment of a real world, STS are characterized by many dimensions which need to be abstracted into a lower number along with analysis may be feasible. For instance in the case of our Social Residence STS, we consider three dimensions (or perspectives), namely end-users perspective, which includes goals and preferences; the technological (hardware/software) perspective, which can be characterized along the objectives i.e. the reason they have been designed for or the features these devices can control, and the legal perspective that governs the overall STS e.g. norms, policies or regulations that determines the roles and procedures in an STS. This abstraction provides the reference dimensions with respect to the problem space and the solution spaces can be defined. The solution space will include instances of artifacts produced exploiting specific analysis techniques, such as requirements models and scenarios. As depicted in Fig. 1, this process is shaped in consecutive iterations in which exploring and filtering phases alternate until converging towards an ultimate solution spaces analysis. The process is composed as a sequence of iterations in which we distinguish two different phases: exploration and filtering. During the exploration the ana-
Technology
Iden,fy
ac,vi,es
for
change
Process
of
Evolu,on
Why?
When?
What?
Wheel
of
Evolu,on
Where ?
Who?
is
ho ?
W lved o Inv
Filtering
Iden,fy
Process
Ar,fact
to
change
Wh pp en
it
en
ed ?
Ra,onal
behind
change
at
?
Wh ened pp Ha
Exploring
Why
it
Happened?
Detect
Change
How?
How
it
Happened?
W Ha her pp e
it en
ed ?
LAW
Ha
USER
Wheel
of
Evolu,on
Fig. 1. Process for Evolution and Wheel of Evolution
lysts study the “problem space” opening the analysis to all details including significant and less significant features of the domain. During the filtering phase, the analysis is restricted by selecting only the significant aspects for leading the following design sessions, by returning a restricted space as output in which some research directions are drafted. The “wheel of evolution” (right part of Fig. 1) guides the analysis of the problem and solution spaces. It is composed of “why” and “how” questions whose answers address real domain instances, in the case of problem space analysis, and respectively instances of the solution space. Main concepts of the CAFfE framework are grounded on questions (why, when, who, what, how, where) from the “wheel of evolution”. Those concepts are used to define a set of guidelines, recommendations and activities for generating the evolution process. The participatory design techniques have a relevant role in the process: domain experts own the (often implicit) knowledge to be considered in the study. Their involvement is fundamental in the exploration phase for defining boundaries of the space under analysis. The identification of relevant elements, during the “filtering”, involves the participation of domain experts, who validate the value of the selected elements e.g. new scenarios. The following iteration starts on a smaller problem space, with respect to the previous one, thus ensuring a convergence driven by the validation of the participating stakeholders. Below we summarize activities that are typically performed in these phases: Exploration. Observing: aims at identifying the need for the evolution. Changes are detected as chain of events that the STS monitors during its execution at runtime by logging the information. This provides a proof of external changes that helps the analyst in exploring the context, in which the evolution is necessary by addressing the (WHEN) question along the (WHO) question. Analysis and Envisioning: relates the reasoning over the monitored data i.e. reading through the logs maintained by the STS. Decision criteria help in addressing the (WHAT)
and (WHY) questions. Addressing such questions provides rationale to evolve the existing requirements. The activities related to the decision are supported by taxonomy of changes, such as those described in [4],which proposes four main contexts of changes, namely environment, requirements, viewpoints and design. Filtering. Assessing: is a direct consequence of the decision analysis conducted in previous activity. It contains a set of activities and guidelines, from which it is possible to restrict and select the candidate solution by addressing the (HOW) question. Activities may regard different threads of specific analysis to evolve the overall STS. Participatory Filtering and Validation: leads to decisions for selecting candidate artifacts to be changed/evolved. The target artifacts that are required to be evolved in order to satisfy the required external changes enable to answer (WHERE) questions. The situational context for the changes are closely linked with the artifacts to be affected. During this activity, the main concern is to keep the traceability among the key artifacts that were produced before the system was introduced in an operational environment. Revising/Adapting: leads to mechanisms that enable the STS to alter its behavior during its execution.
4
Instantiating the Framework
The evolving requirements of ACube1 system to ACube2 were discussed with project managers, requirement engineers, directors of social residences, lawyers and developers. Three workshops took place for envisioning, assessing, filtering and validating the results. In Table 2, we summarize the application of the CAFfE framework along four aspects: Process phases, Process activity, Who is involved and Process artifacts. Observing. The need for evolution arises from real situations in the environment. These were partly observed by the stakeholders and analysts and by the running system that monitors deviations between expected behavior and concrete flows of events, e.g., interventions made by nurses out of the control of the system, thus dis-aligned with the designed course of actions. Analysis and Envisioning. Episodic knowledge (collected as logs) about the critical situations mentioned in section 2 was collected and organized before the meetings. To motivate the discussion during the workshop this knowledge was presented as scenarios/personas and models depicting the system as it is. The scenario/persona technique is used in interaction design to engage domain stakeholders during analysis [1]. Personas are concrete representations of fictional users, with their names, characteristics, aptitudes, and motivations. A scenario with personas may be easily presented to non technical people. Nomos [10] is a goal-oriented approach that provides the capability to model law prescriptions and the link between intentional elements and legal elements models to analyze their impact with respect to law compliance (e.g. regulations and norms). During the first exploratory workshop, contributors discussed shortcoming of the existing system. Scenarios highlights situation in which the system could be evolved. Participation of personnel of social residence was critical, such as the director, who prospected legal issues of evolution. For instance, the authorization management for health care interventions (what, who, why) were identified as cause of change. In this situation, the patient depends on the nurse to receive life-critical assistance. The
Filtering
Exploration
Phases
Process Activity
Who is Involved
Process Artifact Used
Observing (when)
The system monitors changes with respect to designed courses of actions (as shown in initial Nomos Models [7]) For instance, real situation in the environment i.e. interventions made by nurses out of the control of the system, so, out of the designed course of actions (when)
ACube1 Tracking Subsystem
Analysis & Envisioning (what, who, why)
Early analysis of changes in the domain envisioning of the causes of change are detected by the system. Later during the exploratory workshop individual analysis sessions (user, technology and legal analysis); for instance the authorization management for health care interventions (what, who, why) were identified as cause of change. New envisioned personas were identified.
Stakeholders (Director of the Social Residence, Lawyer) Designers (Project Manager, Requirements engineer, Software architect)
Personas & Scenarios (describing the functionalities of ACube1)
Assessing (how, where)
In response to the changes, among several candidate alternatives for ACube1 evolution. Scenarios related to authorization management were assessed during second workshop [7] (How and where)
Stakeholders (Director of the Social Residence, Lawyer) Designers (Project Manager, Requirements engineer, Software architect)
Personas & Scenarios (describing the functionalities of ACube2)
Participatory Filtering and Validation (how)
Possible alternatives were discussed to understand the impact on the current system of the chosen solutions via Nomos models informal analysis techniques; Personas and Scenarios related to authorization management were filtered. Solutions for authorization management during the third workshop. Early validation was obtained during this session.
Stakeholders (Director of the Social Residence, Lawyer) Designers (Project Manager, Requirements engineer, Software architect)
Personas & Scenarios (describing the functionalities of ACube2)
Revising/ Adapting (how)
Iterative revision of the requirements models via Nomos modeling. By incorporating new persona and scenarios.
Designers (Project Manager, Requirements engineer, Software architect)
System Log reports Nomos Models
Nomos Models - to analyze the impact of the changes on the ACube1 models
Nomos Models - to analyze the impact of the changes on the ACube2 models
Nomos Models - to analyze the impact of the changes on the ACube2models Evovled Nomos Models Acube 2 Tracking Subsystem (Role management subsystem)
Fig. 2. Activity, artifacts and responsible stakeholder, in the process of requirements evolution between two system versions: from ACube1 to ACube2. They are detailed in [7].
nurse is able to provide the assistance, but she has to comply with the law, which protects the rights of the patient: the nurse has to be legally entitled to decide about the right assistance, or she must receive a proper authorization from a doctor. This is represented in the Nomos model by a “realization relationship” between the law Authorization to intervene and the goal Have Authorization . Consequently, the nurse depends on the doctor to have the authorization, although she has the experience to provide the assistance autonomously. This solution can fail if the stakeholders do not own the necessary rights. For example, if the nurse is not able to obtain the authorization (the doctor could be not reachable or is not possible for a doctor to give the authorization remotely), she fails in providing assistance to the patient, and the patient could die. As post-analysis of the meeting, new envisioned personas were identified and consequently scenarios were evolved. For example, the manager Carla is one of the personas identified when analyzing possible evolutions of the system. The identified scenarios and personas describe hypothesis for evolving the existing ACube1 system and its short comings. Assessing. New personas/scenarios (i.e. those related to authorization management) were assessed during second workshop (How and where). We discussed several candidate alternatives for ACube1 evolution, analyzing the legal impact, which can support identifying possible cause of change in the environment and ultimately help in identifying causes for system requirements evolution (we follow here the change taxonomy proposed in [4]). This leads to produce a set of revised models, on which selection upon critical review, will be operated during the “Filtering” phase. For example, a possible change in the requirements set is identified, to incorporate an answer to the above men-
tioned law-compliance problem. In the revised Nomos model (see [7]), since the nurse’s goal Have authorization can not be removed (since a law prescribes it). It is further refined into the sub-goal Have direct authorization , which enables nurse the responsibility to obtain the authorization by the doctor, if present. Alternatively, if this goal fails, the nurse can ask for authorization remotely by using the multimedia services. This way, the achievement of the main goal is not inhibited, and assistance can be given. Participatory Filtering and Validation. After the selected solutions are exploited via Nomos models informal analysis techniques, a third workshop was organized. The selected solution were presented via personas/scenarios and discussed to understand the impact on the current domain, including a risk and cost/benefit analysis. The goal of the workshop was to validate the analysts’ work. For instance some scenarios were filtered during the meeting, whereas the Authorization management scenarios obtained a general consensus. Revising/Adapting. During this activity, Nomos models and the requirements were updated to include new scenarios; new personas are transformed into new roles in the system e.g. Manager.
5
Related Work
The importance of requirements evolution is investigated, both theoretically and empirically, and a state-of-the art is provided in [3]. Evolution is considered inherent to software production but it is recognized that requirements engineering methodologies provide limited support to capture it. As a result, the need for Requirements Evolution Engineering is outlined, which involves analysis, modeling and practice of requirements evolution. Among the theoretical works, Zowghi and Offen [12] propose a model of requirements evolution based on a combination of monotonic and nonmonotonic reasoning. Requirements evolve through a systematic process that starts from an incomplete set of sentences and ends with a complete requirements model, validated through the intervention of stakeholders. Considering approaches that aim at defining practices for evolution, in [4] it is illustrated the EVE (EVolution Engineering) project that proposes a framework for evolution based on a meta-model and an associated process model. The EVE meta-model includes the concepts of change (4 types: environment, requirements, design, viewpoint), impact, risk, violation, etc. The process aims at supporting the analysis of changes in either user’s needs (requirements changes or R-Changes) or the environment (E-Changes). In [11] two quantitative techniques are presented, for dealing with requirements change in a maintenance environment based on data collected from one organization on several product releases. Several types of analysis are described.
6
Conclusion & Future Work
We proposed the CAFfE framework that aims at facilitating the evolution of requirements, with the involvement of key stakeholders, including the software system itself. Key elements of our framework are the adoption of participatory design techniques (e.g. workshop, ’persona’), which can be integrated with specialized analysis techniques (e.g.
law-compliant requirements modeling). Another peculiarity of CAFfE is the evolution process that mixes exploratory phases, in which all possible alternatives are identified and analyzed, with filtering phases in which a subset of the alternatives are selected. This form of process helps managing evolving requirements and satisfying changing needs in a continuous way by revising and adapting the designed solutions. We illustrated the framework on a real case study in the health-care domain, i.e. a Social Residence STS, in which the main problem consisted in managing the evolution of the software system artifacts (requirements and law models, personas, scenarios) corresponding to the current version of the system, into new artifacts describing the requirements of an new version of the system, in a continuous manner. Further instantiation of CAFfE on other scenarios of requirements evolution, which concern other specific aspects, will be necessary to consolidate and validate the framework. A formalization of the framework is ongoing, as well as the investigation of its integration with the recently proposed approach for supporting requirements engineering at run-time for self-adaptive systems [9, 8].
References 1. Cooper, A., Reimann, R., Cronin, D.: About Face 3. Wiley (2007) 2. Ernst, N., Mylopoulos, J., Wang, Y.: Requirements Evolution and What (Research) to Do about It. In: Design Requirements Engineering: A Ten-Year Perspective. Design Requirements Workshop, Cleveland, OH, USA, June 3-6, 2007, Revised and Invited Papers. vol. 14, pp. 186 – 214 (2009) 3. Felici, M.: Observational Models of Requirements Evolution. Ph.D. thesis, University of Edinburgh (2004) 4. Lam, W., Loomes, M.: Requirements Evolution in the Midst of Environmental Change: A Managed Approach. In: CSMR ’98. IEEE Computer Society (1998) 5. Leonardi, C., Sabatucci, L., Susi, A., Zancanaro, M.: Design as intercultural dialogue: coupling human-centered design with requirement engineering methods. In: Proceedings of INTERACT 2011 (2011), to appear 6. Nielsen, L.: Engaging personas and narrative scenarios. A study how a user-centered approach influenced the perception of the design process in the e-business group at AstraZeneca. Copenhagen Business School Editor, Fredriksberg, Denmark (2004) 7. Perini, A., Qureshi, N.A., Sabatucci, L., Siena, A., Susi, A.: On evolving requirements in socio-technical systems: Concepts and practice (2011), SE Research Group Technical Report (TR-FBK-SE-2011-6), FBK, Trento, Italy. http://se.fbk.eu/files/TR-FBK-SE-2011-6.pdf 8. Qureshi, N.A., Jureta, I., Perini, A.: Requirements engineering for self-adaptive systems: Core ontology and problem statement. In: Mouratidis, H., Rolland, C. (eds.) CAiSE’11: Conference on Advanced Information Systems Engineering. LNCS, vol. 6741, pp. 33–47. Springer, London, UK (2011) 9. Qureshi, N.A., Perini, A.: Requirements engineering for adaptive service based applications. In: 18th IEEE Int. Requirements Eng. Conf. pp. 108–111. Sydney, Australia (2010) 10. Siena, A., Mylopoulos, J., Perini, A., Susi, A.: Designing law-compliant software requirements. In: Conceptual Modeling (ER’09). pp. 472–486 (2009) 11. Stark, G.E., Oman, P., Skillicorn, A., Ameele, A.: Journal of Software Maintenance: Research and Practice 11(5), 293–309 (1999) 12. Zowghi, D., Offen, R.: A Logical Framework for Modeling and Reasoning About the Evolution of Requirements. In: RE. pp. 247–. IEEE Computer Society (1997)
