Situational Requirements Engineering Processes

Situational Requirements Engineering Processes Methods, Techniques and Tools to Support Situation-Specific Requirements Engineering Processes

The 1st International Workshop Paris, France, 29–30 August 2005 Organized By IFIP WG8.1 Method Engineering Task Group

in Conjunction with 13th IEEE International Requirements Engineering Conference

Proceedings of the First International Workshop on Situational Requirements Engineering Processes: Methods, Techniques and Tools to Support Situation-Specific Requirements Engineering Processes (SREP’05), Paris, France, August 2005, In Conjunction with the Thirteenth IEEE Requirements Engineering Conference (RE’05). Edited by: Jolita Ralyté ([email protected]) University of Geneva, Switzerland Pär J Ågerfalk ([email protected]) University of Limerick, Ireland Naoufel Kraiem ([email protected]) University of Manouba, Tunisia

Printed in Ireland by the University of Limerick ISBN: 1-874653-82-8

This compilation is copyright © 2005 by Ralyté, Ågerfalk and Kraiem. Copyright of each individual article remains with the respective author(s). Permission to copy without fee all or part of this work is granted provided that the copies are not made or distributed for direct commercial advantage.

Preface Engineering situations vary considerably from one software or information system development project to another. A number of different characteristics, such as project objective, application domain, different features of the product to be developed, involved stakeholders, and various technological conditions and constraints have a significant impact on the Requirements Engineering (RE) process. As a consequence, each software or information systems project requires a specific RE method and tool to support the RE process. The question then, is how to select, adapt or construct, and manage (often changing) requirements on an RE method that best suits the situation of the project at hand? The First International Workshop on Situational Requirements Engineering Processes: Methods, Techniques and Tools to Support Situation-Specific Requirements Engineering Processes was organized in conjunction with the 13th IEEE International Requirements Engineering Conference in Paris, France, 29–30 August 2005. The workshop was organized by the IFIP WG8.1 Method Engineering Task Group in collaboration with ENSI, University of Manouba, Tunisia. The organizers are grateful for the support from the Science Foundation Ireland Investigator Programme, B4STEP (Building a Bi-Directional Bridge Between Software ThEory and Practice) which enabled the publishing of these proceedings. The proceedings comprise 12 full papers, three position papers and one industrial experience paper. All papers were selected through a double-blind review process by the international program committee, and we are extremely grateful for the thoroughness of their review work. Altogether, these papers represent an intriguing mixture of different approaches and perspectives on situational aspects of RE processes and tools.

Jolita Ralyté Pär J Ågerfalk Naoufel Kraiem

i

Conference Organisation Program Co-Chairs Jolita Ralyté, University of Geneva, Switzerland Pär J Ågerfalk, University of Limerick, Ireland Naoufel Kraiem, University of Manouba, Tunisia

Program Committee P.J. Ågerfalk, Ireland H. Ben Ghezala, Tunisia S. Brinkkemper, The Netherlands C. Gonzalez-Perez, Australia B. Henderson-Sellers, Australia Y. Jamoussi, Tunisia F. Karlsson, Sweden A. Khalfallah, Tunisia N. Kraiem, Tunisia J. Krogstie, Norway K. Lyytinen, USA N. Maiden, UK J. Ralyté, Switzerland C. Rolland, France M. Rossi, Finland M. Saeki, Japan C. Salinesi, France M. Serour, Australia J.-P. Tolvanen, Finland J. Versendaal, The Netherlands

ii

Proceedings of SREP’05, Paris, France, August 29–30, 2005

Table of Contents Full Papers A Flexible and Pragmatic Requirements Engineering framework for SME ..............................1 Thomas Olsson, Joerg Doerr, Tom Koenig and Michael Ehresmann Situational Requirements Engineering of Web Content Management Implementations .........13 Inge van de Weerd, Jurriaan Souer, Johan Versendaal and Sjaak Brinkkemper Method-User-Centred Method Configuration ..........................................................................31 Fredrik Karlsson and Pär J. Ågerfalk A Framework for Matching Requirements Engineering Techniques to Project Characteristics and Situation Changes...........................................................................44 Toshihiko Tsumaki and Tetsuo Tamai Using the OPEN Process Framework to Produce a Situation-Specific Requirements Engineering Method ......................................................................................................59 Didar Zowghi , Donald G. Firesmith and Brian Henderson-Sellers Conceptual Analysis of Current ME Artifacts in Terms of Coverage: A Contextual Approach.................................................................................................75 Mauri Leppänen Application of Requirements Engineering Techniques to the Analysis of Civil Aviation Security Standards .................................................................................91 Régine Laleau, Sylvie Vignes, Yves Ledru, Michel Lemoine, Didier Bert, Véronique Donzeau-Gouge, Catherine Dubois and Fabien Peureux A New Requirements Template for Scientific Computing ....................................................107 Spencer Smith and Lei Lai A Process Guidance Based on a Heuristic for Controlling Method Use in a Process-Centered Software Engineering Environment.........................................122 Inès Bayoudh Saâdi, Yassine Jamoussi and Henda Ben Ghezala A Lightweight Workshop-Centric Situational Approach for the Early Stages of Requirements Elicitation in Software Systems Development .....................................136 Chad Coulin, Didar Zowghi and Abd-El-Kader Sahraoui Panta Rho: Personal before Business in Changing Requirements Priorities ..........................152 Johan F. Hoorn and Mark E. Breuker More than Psychologists’ Chitchat: The Importance of Cognitive Modeling for Requirements Engineering in Complex and Dynamic Environments....................163 Constanze Pott, Fokie Cnossen and Albert Ballast

Position and Industrial Experience Papers Agile Requirements Definition for Software Improvement and Maintenance in Open Source Software Development ......................................................................176 Stefan Dietze The Challenges of Tool Integration for Requirements Engineering.......................................188 Lisa K. Meisenbacher


iii

Eliciting Requirements Variability for Embedded Real-Time System Family ......................192 Olfa Djebbi A Unified RE Approach for Software Product Evolution: Challenges and Research Agenda................................................................................200 Pnina Soffer, Leah Goldin and Tsvi Kuflik

iv


A Flexible and Pragmatic Requirements Engineering Framework for SME Thomas Olssona, Joerg Doerra, Tom Koeniga and Michael Ehresmann b a

Fraunhofer Institute for Experimental Software Engineering, Fraunhofer-Platz 1, 67663 Kaiserslautern, Germany b insiders technologies, Brüsseler Strasse 1, 67657 Kaiserslautern, Germany

Abstract Convincing organizations to improve their software development processes is difficult. It becomes even more difficult for smaller firms, as they have smaller margins for improvement work and most likely lack the in-house competence to make improvements. Based on the experience from smaller and medium-sized companies, a flexible and pragmatic process improvement framework for the requirements engineering process was developed, specifically focused on the situations of smaller firms. The background and motivation is presented, including why existing methods such as CMM are not appropriate in our context. Initial experience and initial evaluation of the developed framework are also presented. It can be concluded that the developed framework has gained acceptance by our evaluation partners and that we were able to perform a process improvement with a relatively small amount of effort. Keywords: Adaptation and configuration of RE methods, Selection of RE methods, techniques and tools

1

Introduction

Convincing a software developing organization to improve their requirements practices is usually difficult (Hall et al., 2002; Juristo et al., 2002; Rainer et al., 2003). In smaller organizations, this difficulty takes on a further dimension. Not only do you have to face the fact that people are skeptical of requirements, these companies often have a less formal development process, less distinct roles and a smaller overhead to allow process improvement (Kamsties et al., 1998). The introduction of Agile methods, such as Extreme Programming (Beck, 2000), have also meant that there is less focus on the early steps of the development. This paper presents an initiative to provide a pragmatic requirements engineering process framework for small- and medium-sized enterprises (SME). Even though it might at first seem that SME are a homogenous group of companies, this is far from the truth. Smaller firms are often forced to comply with the processes of bigger companies they deliver their solutions to. Also, the domains in which SME operate range from web portal development to safety-critical medical equipment. But what is common to all SME is the need for small and to-the-point solutions, as they do not have the same possibilities to try out and invest money in process improvement. This paper is organized as follows: The background and requirements for the developed framework is presented in Section 2. In Section 3, other relevant requirements process improvement approaches are presented and discussed. Our framework is presented in Section 4, and in Section 5 our early experience in applying it is presented. Future work and a general discussion are found in Section 6, and the paper is concluded in Section 7.

Proceedings of SREP’05, Paris, France, August 29–30, 2005 Eds. Ralyté J, Ågerfalk PJ and Kraiem N

1

A Flexible and Pragmatic RE Framework for SME

2

Background

Large process models like Rational Unified Process (RUP) (Kruchten, 1999) or VModel (Sommerville, 2001) are successfully implemented in many companies. The understanding and tailoring of such models is, however, difficult and demands a lot of experience. SME often lack this knowledge (Nikula et al., 2000; Hall et al., 2002; El Emam et al., 1995). Furthermore, they do not want to employ a consultant with the required knowledge because the cost and structural changes of implementing a large standard process model are not considered justified in their context and there is a lack of faith in the consultants (Paulk et al., 1995). Furthermore, these models focus on the overall process, and are not detailed enough to help a company with specific requirements engineering problems. Solutions cannot be found, with a reasonable amount of effort, with the limited software engineering knowledge of an SME. There is a gap between the theoretical application and tailoring of standard frameworks and the ability and acceptance to apply them in real-life projects at an SME (Nikula et al., 2000). This is a problem, because the expectations on product quality are as high in SME as in other companies. Most SME have very close relationships with their customers and are often forced to react to customer requests immediately. SME have to develop these individual customer requirements, as opposed to developing a standard software product. The risks are often increased as the economic survival of the enterprise can depend on the success of a single project. One lost or cancelled project can be the ruin for the SME. There is a trend among SME towards Agile methods, which are easy to understand and have proven to be practical in their context. Especially the concept of practices, which are easy to understand and intuitive parts that fit well together, makes Extreme Programming (Beck, 2000) attractive to SME. Even though Agile methods can be very helpful, without a systematic improvement process, inappropriate changes can take place. Typically, no assessment is done of the current situation and the applicability of techniques and methods is not evaluated. Hence, the typical situation is that an SME has both an ad hoc development process and a process improvement process (Kamsties et al., 1998; Nikula et al. 2000). There is a need for a lightweight framework that is easy to understand and limits the scope of change to the particular problems. It is necessary to have a small set of practices that can be introduced in a single step. The scope of change needs to be clear so that it can easily be motivated and explained to the SME. The improvements should lead to a simple process adaptation, understood and accepted by all affected stakeholders (Kaindl et al., 2002).

3

Previous Work

There exist several requirements engineering (process) frameworks, focusing on different aspects of process improvement. The “good practice guide” by Sommerville and Sawyer (1997) gives pragmatic guidelines on how to improve the requirements process. The Open Process Framwork (OPF) provides a comprehensive RE process modelling tool (Firesmith, 2005). The R-CMM initiative details an assessment framework, similar to CMM, for RE (Beecham et al., 2005). The pragmatic framework by Sommerville and Sawyer (1997) is focused on providing concrete and simple assessment and improvement suggestions. It consists of a list of good practices for RE activities. The practices are used for assessment as well

2


Olsson, Doerr, Koenig and Ehresmann

as to give improvement suggestions. The practices are categorized into basic, intermediate and advanced. It has been applied and evaluated in several case studies and proven to be useful (Sommerville et al., 2005). However, even though the framework has been shown to be useful, some shortcomings were also identified. The framework was originally developed for the safety-critical domain. It was noted that adaptation to different domains is necessary but is currently lacking (Sommerville et al., 2005). Hence, a practice might be basic in one domain and intermediate in another and so on. Furthermore, the cost-benefit model, with its eight levels, was perceived as too complex. A simpler model could suffice. The OPF provides a rather comprehensive framework for RE process modelling (Firesmith, 2005). It provides a framework with modelling components (e.g., endeavours, languages, processes, stages, etc), list of OPF tools and process notations suggestion. Completeness and flexibility are two important goals of the framework. To achieve the former, a rather large repository is developed and documented with many components. To achieve the latter, a process meta-model underlies the framework. Associated with the framework is an improvement process containing 14 steps (Firesmith, 2004). This rather thorough process does not prescribe the use of OPF, but is built around it. The R-CMM is focused on assessment of the requirements capabilities of software developing companies (Beecham et al., 2005). Through a series of studies, ranging from assessing typical weaknesses of the RE process, through a development of the components of the different levels and empirical evaluations of the selection and positioning of individual practices (Beecham et al., 2005), the development of a well-founded RE assessment framework is well underway. As the name suggests, RCMM is a refinement of CMM with respect to requirements. The goal is to provide a process improvement tool by allowing assessments specifically for RE.

4

The Framework

The framework is developed to support SME in their improvements of the requirements process. As mentioned in Section 2, such a framework has to be easily available to the firms without much investment, neither in time nor in money. It is also important that it is easily understandable to all stakeholders, not just to the person responsible for the development process. 4.1 Background The list of good practices by Sommerville and Sawyer (1997) was a starting point for the framework presented in this paper. It provides a pragmatic framework with many of the features we were looking for. However, as we were developing our framework, we quickly ended up discussing the list of practices, the definition of a practice and how to extend the ideas to support more usage contexts. The problem we struggled with was how to separate a general practice from a concrete solution. As we want to be able to give very concrete improvement suggestions to the SME, this is central to our framework. Furthermore, the good practice guide was developed focusing on the safety-critical domain, which was not our scope. Cost, suitability and availability are central to an SME. The OPF (Firesmith, 2005) fulfils the first and third criteria, as it is free of charge and is available online. However, in our discussions with our application partners, the criticism of OPF was


3


that even though the results from a tailoring effort using OPF might be useful, the framework, which is quite comprehensive, is very difficult to comprehend and would require a large amount of effort to apply. Furthermore, as the OPF is large, the psychological factor of being faced with something that complex intimidates the practitioners. Looking at formal assessment models, such as CMM (Paulk et al., 1995) or RCMM (Beecham et al., 2005), a well-founded assessment of the current situation at a company is possible. However, they often fall short of providing pragmatic guidelines on how to proceed after the assessment and anything close to a formal assessment is intimidating for a SME, as the cost and internal acceptance are often low. As the available and possible frameworks did not provide us with a satisfactory solution for a pragmatic RE process improvement framework for SME, we needed to improve on existing solutions. As a basis for the improvement, we selected the good practice guide, as the intentions there are similar to ours. Our main points of interest to improve are the adaptability to support more domains and to improve support for small, incremental improvements of the RE process. 4.2 Theory The framework is divided into five phases, which are more or less standard for the requirements process: •

Requirements elicitation

•

Requirements analysis

•

Requirements specification

•

Requirements verification and validation

•

Requirements management

In each of these phases, a number of different tasks have to be performed. The phases are refined into practices and techniques. A practice defines an abstract task that should be performed in the requirements engineering process (e.g., elicit functional requirements). A technique describes how a practice can be implemented (e.g., apply Use Cases to elicit functional requirements). An overview of the different practices, arranged according to the phases, can be found in Figure 1. The relationship is depicted in Figure 2.

4



Figure 1 Overview of practices 4.2.1

Practices

A practice is usually an abstract activity (in terms of process modeling), e.g., "elicit functional requirements" which makes sense to perform in most requirements contexts. A practice can also be a principle. A principle is something that should be considered during one or more activities, e.g., "involve all stakeholders". The usage of the framework is, in principle, independent of whether a practice is an activity or principle. Hence, in order to simplify the presentation, the concepts are subsumed under the common name practices. Especially for SME, it is important to keep the presentation and usage as straight-forward as possible. Based on experience and literature studies, we identified an initial set of practices and related techniques that are or might be of use to SME. The list is, of course, something that will always be debated. Our goal with this list is to provide a starting point from where we can refine and distill a list that receives broad support in the community. A practice is associated with one of the five abstract requirements engineering phases. The practices are also categorized into three categories: •

Basic: represents a practice that is relevant in any requirements context.

•

Advanced: represents a practice that is relevant in any requirements context, but requires other, usually basic, practices to be established.

•

Context: represents a practice that is only relevant in certain project context.

As opposed to Sommerville and Sawyer (1997), we make a distinction between the concept of techniques and practices. A practice is an abstraction of the techniques


5


that propose a concrete solution. The motivation was to be able to associate concrete solution proposals to practices and to refine the concept of practice, in order to attain a cleaner set of practices. This was done to improve the adaptability, i.e., the applicability of the framework to more usage contexts. Also, we find, a practice is easier understood by the SME stakeholders. Furthermore, the practices in (Sommerville et al., 1997) are categorized as Basic, Intermediate and Advanced. Basic and intermediate practices are comparable to basic and advanced practices in our framework. However, a distinction can be observed between advanced practices as defined in (Sommerville et al., 1997) and context practices in our framework. The advanced practices cover practices for the domain of safety-critical systems, while our context practices do not focus on any specific domain. The description of a practice should be very short and as simple as possible (e.g., a PowerPoint slide or one page.). The motivation is that the effort spent reading about the different practices should be as low as possible, in order to enable the user of the framework to quickly identify relevant practices. SME usually want information to be accessible as fast as possible as they usually do not have the time to read several pages of text just in order to assess if something is relevant or not. The template in Table 1 is used to describe a practice. The practice "Elicit nonfunctional requirements" is presented. It briefly describes why the activity should be applied and what can be achieved by applying it. Table 1 Excerpt from practice template Practice: Elicit non-functional requirements (NFR) Goal: Elicit non-functional requirements to better support the business process and the goals of the company and the user. Description: To capture the relevant requirements, it is not enough…. Phase: Requirements elicitation Possible techniques to implement practice: Soft-goal notation Required Practices: Elicit functional requirements (FR) Supporting practices: Elicit functional requirements (FR) Supported practices: None Category: Advanced

4.2.2

Techniques

As opposed to practices, which represent abstract activities, techniques represent concrete solutions, describing how a certain practice can be implemented. The relation-

6



ship between practices and techniques is a many-to-many relationship, as a technique can support many practices. Furthermore, a practice might also be covered by more than one technique. Figure 2 shows an excerpt of these relationships for the practices “Elicit non-functional requirements (NFRs)”, “Document rationale”, “Elicit functional requirements (FRs)”, and the techniques “Soft goals” and “Stakeholder Workshop”. The technique “Soft goals” supports the practice “Elicit NFRs” as well as the practice “Document rationales”, as the rationales for the NFR are documented when using the technique. The practice “Elicit NFRs” is not only supported by the “Soft goals”, but also by “Stakeholder workshop”, which in turn also supports “Elicit FRs”.

Figure 2 Relationship between practices and techniques

The practice "Elicit non-functional requirements" is presented in Table 1. As can be seen, it is not described how the practice can be performed. Therefore, techniques are introduced. They describe possible ways of implementing a certain practice, completely or partially. The techniques are described using the template in Table 2. Comparable to the description of practices, the description of a technique should also be compact. The template does not have to provide a complete guide on how to perform a certain activity, but should give a rough overview and contain all necessary information to look up the required information. Table 2 Excerpt from technique template Technique: Soft goals Goal: Elicit, document and analyze non-functional requirements with regards to their relationships to functional requirements and architectural decisions. Description: The following activities have to be executed to apply Soft goals: ... Expert: Please contact ... for further information Context: Not specific


7


Type: Method (Partly) Accomplishes the practices: Include stakeholder Elicit non-functional requirements Determine scope ...

There should be enough information in the technique description for the reader to understand if it can be the solution to their particular problem. The complete description and explanation of the technique is found in references provided. In order to make the information contained in the templates accessible, practices and techniques are collected in a repository, also published on a web portal1. 4.3 Framework usage The framework can be used for different purposes. We identified three usage scenarios: •

Assess company setting - SME may use the framework as a support to assess their own requirements process. Based on the set of practices it is possible to determine how requirements engineering is performed within the firm. That is, which practices are already in place.

•

Solve specific problem - In certain cases, companies want to solve a precise problem regarding the requirements process, e.g., security problems are inadequately handled. To some extent, it is possible to use the practices as a means to identify possible solutions. The title and the goal of a practice give a hint on whether a practice might be of use to assist in solving a certain problem.

•

Process improvement - The framework can also be used for general process improvement of the requirements process.

As the process improvement involves the other uses of the framework, this usage is elaborated on in more detail. 1.

Analyze current situation - Prior to making a decision regarding possible improvement steps, the current situation of the company should be identified in a first step. If an assessment (e.g., CMM (Paulk et al., 1995)) has already been performed, that information can be used. If this has not been the case, it is possible to broadly identify the current setting as presented in the first usage scenario.

2.

Identify required practices - Based on the classification of practices (see Figure 1) the set of practices is prioritised. As a first step, based on the current setting, missing basic practices are identified. The company setting should be considered while identifying basic practices that should be introduced. It could be possible that in a certain setting, even a basic practice will not be suitable. The reason is

1

8

www.re-wissen.de (in German)



that every company is different and even though attention was paid to making the classification generally applicable, there might be situations where a different prioritization is needed. After all relevant basic practices have been identified, all relevant advanced and context practices are to be identified. With regards to context practices, a more detailed assessment of the company setting might be necessary, in order to identify practices appropriate to the company setting. The practice "manage variability", for example, is only relevant for a company that develops a set of similar products, i.e., has a product line type of situation. After identification has been completed, the identified practices need to be prioritized. According to our experience, not more than two to four practices should be introduced at the same time. As with any process improvement, small steps and an iterative improvement are better. Exactly how many practices can be considered at the same time depends on the number of techniques needed to implement the practices. 3.

Identify required techniques - As the practices identified in the previous step do not specify how a certain practice can be introduced, the set of all associated techniques is identified based on the identified practices.

4.

Select and adapt a minimal set of techniques - The identified set of techniques is identified in two steps to identify and eliminate unsuitable techniques. In a first step, all techniques are assessed with respect to the overall company setting. In a second step, all techniques are examined regarding the expected input and preconditions. The remaining set of techniques is then minimized in a concluding step. As one technique may implement or contribute to more than one practice, the goal of this step is to identify a minimal number of techniques that implements all required practices.

5

Experience

The development of the framework is still in its early stages. We are in a continuous dialogue with industry to ensure that our solution is moving in the right direction. Generally, the framework was well received by the different stakeholders of our industry partners. It was also possible for us to identify and tailor process improvement suggestions with a relatively small amount of effort. Using the practices as a mean to assess the current situation worked well. It took less than an hour to explain the concept of practices and to give a first overview of the different practices. Especially the graphical representation of the practices (see Figure 1) and the short description were appreciated. Hence, it was possible for all stakeholders to understand and discuss the current situation. In previous process improvement initiatives, the current situation was assessed by external consultants and by process owners. As all stakeholders could follow and participate in the process, the assessment was more credible to them and they accepted the deficiencies in their current way of working. When it came to identifying and selecting techniques, the framework was perceived as intuitive and very helpful. The explicit modelling of the relationships between practices and techniques, see Figure 2, made it easy to identify techniques with high leverage suited for the context. In this particular case, we were able to identify


9


four techniques that would improve the 7 practices chosen for improvement (see Section 4.2.1). The principle of trying to identify the minimal set of techniques that cover all the desired practices proved suitable and if nothing else, has the psychological effect of being efficient, enhancing the acceptance at the firm. As mentioned in Section 2, a key requirement for the framework was to have a good balance between cost and benefit. The fact that the SME feels good about the improvement is a key success factor. Another key psychological factor was the perception that there was no traditional process improvement as such. Rather, techniques solving a concrete problem were suggested, making the stakeholders see the benefit of introducing it. The process improvement, hence, was implicit, increasing the feel good factor, which is so important in all process improvement situations. The aim is that the framework should empower the SME to participate and to perform many of the decisions themselves. The decision on which techniques to recommend, however, was made by requirements specialists and process owners. The reason is that there is a lack of empirical data supporting this decision. The suitability of specific techniques is judged by experts based on their experience, as this data was missing. This was perceived as a major drawback. Even though the initial experience was positive, more evaluation is necessary. Future case studies are planned, both to evaluate the framework and to gather empirical data in individual techniques.

6

Discussion

The framework presented here tries to provide a comprehensive approach for improving the requirements process. It incorporates improvement suggestions for the requirements process and ease decision making by providing experience data on the improvement suggestions. Our motivation for coming up with a new framework comes from working with small and medium sized enterprises, where existing approaches and methods are not sufficient for their project and product needs. An important internal property as we are developing our framework is the balance of sound scientific basis and a pragmatic and lean solution. We hope that, by introducing the concept of abstract practices and concrete techniques, we achieve a good compromise. The list of practices is, however, important. If this list is not appropriate, then the abstraction is meaningless. This list is also something that different experts always argue over. Our plan is to attack these problems in two ways: By applying the framework in the firms of our partners to get feedback from them, and by letting requirements experts prioritize and optimize the list. The list of techniques is much less troublesome. This list is a collection of existing methods and approaches. Of course, if the aim is to claim completeness, then the challenge grows. But initially we do not aim at having a complete list of techniques. We see this as a basis that will grow as we use the framework and perform process improvement in industry. A central problem in all process improvement is which technique to recommend to a company. Our framework provides an abstraction mechanism through the practices, which helps. This is not the whole answer though. An open issue that we aim to tackle is how to incorporate empirical studies of techniques into our framework. Our

10



hope is by having concrete data on the performance of specific techniques, the selection of what to implement in a specific improvement context will be supported. To further improve the adaptability of our framework, we aim to investigate how to describe different usage contexts. As noted in (Sommerville et al., 2005), a basic practice in one context might be advanced in another. Our framework does generalize when the practices are categorized into basic, advanced and context types. Hence, the open issue is how to describe the context of use and how the categorization of practices can be improved. We believe that it is unrealistic to completely describe any usage context. The question is: Which factors are the determining ones? Furthermore, is it possible to say that a practice is basic in all contexts, or are, in fact, all practices context dependent? Our hypothesis is that there are practices that are important in all contexts. But this is something we need to investigate further. The continued work on the framework will have a strong empirical character. In order to further validate and improve the framework, further case studies in industry are necessary. It is also essential that key empirical data on techniques are gathered and documented, as at the end of the day, any improvement will depend on the identification of appropriate change proposals to the development process.

7

Conclusion

In an attempt to support small and medium-sized enterprises (SME) in their requirements process improvement, we have developed a framework. We want to provide an easy to understand and practical (in the sense that concrete improvement suggestions are delivered) framework, which still has a basis in sound requirements engineering. Based on the experience both from consulting and from being part of the development, many of the existing frameworks and assessment methods are judged to be too big and cumbersome to use, while they often lack the necessary details for the requirements process. The core of the framework is practices and techniques. The former is an abstract activity or principle that makes sense to include in the requirements process. A technique implements, at least partly, one or more practices. Our initial evaluation together with several SME and research institutes shows promise for the framework. The companies could easily understand the framework and we were, with a small amount of effort, able to identify and tailor process improvement suggestions for the SME. The involved companies also reported that due to the intuitive nature of the framework, the developers could themselves understand the need for improvement and follow the arguments for the improvement suggestions, giving that improvement suggestions greater acceptance. Future work involves further evaluation of the framework. Several case studies are planned, on the one hand to evaluate the framework as such, on the other hand to gather empirical data regarding requirements techniques.

Acknowledgements This work is funded by the German Ministry for Education and Research (Bundesministerium für Bildung und Forschung, BMBF), under the grant for the ReqMan project (grant number: 01 IS C02 D). We would like to thank the other members of the ReqMan project as well as the colleagues in the Requirements and Usability department at Fraunhofer IESE and insiders technologies.


11


References AAEN I (2003) Software Process Improvement: Blueprints versus Recipes. IEEE Software 20(5), 86-93. BEECHAM S, HALL T, BRITTON C, COTTEE M and RAINER A (2005) Using an expert panel to validate a requirements process improvement model. Journal of System and Software 76(3), 251-275. BECK K (2000) Extreme Programming Explained. Addison-Wesley FIRESMITH D (2005), Open Process Framework (OPF), www.donald-firesmith.com, last visited 2005-07-20. FIRESMITH D (2004) Creating a Project-Specific Requirements Engineering Process. Journal of Object Technology, 3(5). EL EMAM KE and MADHAVJU NH (1995) A field study of requirements engineering practices in information systems development. In Proceedings of the International Symposium on Requirements Engineering. HALL T, BEECHAM S and RAINER A (2002) Requirements problems in twelve software companies: An empirical analysis. IEE Proceedings Software, 149(5), 153-160. JURISTO N, MORENO AM and SILVA A (2002) Is the European Industry Moving towards Solving Requirements Problems. IEEE Software, 19(6), 70-77. KAINDL H, BRINKKEMPER S, BUBENKO J, FARBEY B, GREENSPAN S, et al. (2002) Requirements Engineering and Technology Transfer: Obstacles, Incentives and Improvement Agenda. Requirements Engineering, 7(3), 113-123. KAMSTIES E, HÖRMANN K and SCHLICH M (1998) Requirements Engineering in Small and Medium Enterprises. Requirements Engineering, 3(2), 84-90. KRUCHTEN P (1999) The Rational Unified Process, An Introduction. Addison Wesley. NIKULA U, SAJANIEMI J and KÄLVIÄINEN H (2000) Management View on Current Requirements Engineering Practices in Small and Medium Enterprises. In Proceedings of The Australian Workshop on Requirements Engineering. PAULK MC, WEBER CV, CURTIS B and CHRISSIS MB (1995) The Capability Maturity Model: Guidelines for Improving the Software Process. Addison-Wesley. RAINER A, HALL T and BADDOO N (2003) Persuading developers to 'buy into' software process improvement: Local opinion and empirical evidence. In Proceedings of the International Symposium on Empirical Software Engineering. SOMMERVILLE I (2001) Software Engineering. 6th edition, Addison-Wesley. SOMMERVILLE I and RANSOM J (2005) An Empirical Study of Industrial Requirements Engineering Process Assessment and Improvement. ACM Transactions on Software Engineering and Methodology, 13(1), 85-117. SOMMERVILLE I and SAWYER P (1997) Requirements Engineering: A Good Practice Guide. Wiley.

12


Situational Requirements Engineering of Web Content Management Implementations Inge van de Weerd a, Jurriaan Souer a, Johan Versendaal b and Sjaak Brinkkemper b a

Wijchenseweg 111, 6538 SW, Nijmegen, The Netherlands Department of Information and Computing Sciences, University of Utrecht, The Netherlands

b

Abstract The development of complex, data-intensive web applications is becoming simpler due to the usage of content management systems. Conventional information systems development methods as well as web application development methods do not cover the needs of a method for web content management implementations. In this research we apply an assembly-based situational method engineering approach to develop a new design method, called WebEngineering Method (WEM). First, implementation situations are identified, then, candidate methods are selected and finally, a new method of useful method fragments is assembled. By using route map configuration, we tune the method fragments to obtain situationality. A meta-modeling technique is proposed that integrates UML activity diagrams and class diagrams for the purpose of analyzing existing methods and assembling the new method. The method developed was validated in a case study, which consisted of a technology testing web application at a large telecommunication organization in the Netherlands. The case study results were very promising, but more case studies are required to refine the method. Keywords: Project situation assessment for RE process, RE for web applications, Method engineering techniques for situational RE methods construction, Experience and case studies of situation-specific RE, Content management

1

Introduction

A large number of information system development methods are available. Next to established methods like entity-relationship modeling (Chen, 1976) and the more recent Unified Process (Jacobson, Booch & Rumbaugh, 1999), several methods and techniques for developing Web applications have been developed. Examples are WebML (Ceri, Fraternali and Bongio, 2000), UWE (Koch, 2001) and W2000 (Baresi, Garzotto, and Paolini, 2001). These methods show significant influences from information systems development methods. This is not surprising since web applications can be seen as a subtype of information systems (Souer, et al. 2005). Gnaho (2001) acknowledges this in his definition of Web applications: a Web application is an Information System providing facilities to access complex data and interactive services via the Web which changes the state of business. Using data-intensive Web applications raised new problems concerning consistency, navigation, data duplication, content audit and control, tracking of content and mapping the website workflows on the business processes (Vidgen, Goodwin and Barnes, 2001). The solution to these problems was found in content management. A content management system (CMS) makes it possible to create, archive, search, control and publish information from within a flexible and integrated environment (Burzagli, et al., 2004). A special type of content management systems


13

Situational RE of Web Content Management Implementations

are CMS-based Web applications, which are defined as Web applications for the management and control of information (Souer, et al., 2005). Examples are GX WebManager, FatWire Content Server and Tridion Web Content Management Edition. In this paper we concentrate on the implementation of CMS-based Web applications. To our knowledge, in academic and professional literature no specific methods on this subject exist. Currently, established information system and Web application development methods are being used, but these methods are not able to cover specific content management aspects. 1.1 Method Engineering Kumar and Welke (1992) state that “there is no detailed information systems methodology which is the best in all situations”. They introduced a solution to this problem, method(ology) engineering, which describes the engineering of information systems development methods, by taking into account the uniqueness of a project situation. In addition, Brinkkemper (1996) defined method engineering as “the engineering discipline to design, construct and adapt methods, techniques and tools for the development of information systems”. Van Slooten and Brinkkemper (1993) introduced route maps, where method fragments are combined to form new methods. Route maps can be used to tune the method into situational methods (Van Slooten and Hodes, 1996; Aydin and Harmsen, 2002). Rossi et al. (2000) mention the development of UML extensions as a reaction to the abundance of variants of UML for special purposes as a prime example of successful situational method engineering. Also Dietsch (2002) showed that situational method engineering can be used as an appropriate approach for solving the problem to finding the right method. Recent research in the method engineering area is done by Ralyté, Deneckère and Rolland (2003). They developed a generic process model for situational method engineering. This process model contains three approaches: (a) the assembly-based strategy, based on the reuse of method components extracted from existing methods and stored in some method base; (b) the extension-based strategy, used for extending a method by applying extension patterns; and (c) the paradigm-based strategy, when a new fresh method must be constructed either by abstracting from a given model or by instantiating a meta-model (Ralyté, Deneckère and Rolland, 2003). Karlsson and Ågerfalk (2004) use method configuration to adapt a particular method to various situated factors. The difference with assembly-based method engineering is that the focus is on one method which is configured in a particular situation, instead of using a set of methods as a base for assembly. 1.2 Existing Web Application Development Methods Since no methods for the development of implementations of CMS-based Web applications exist, we studied the field of web application methods. The first method we describe is the Unified Software Development Process (Unified Process), which is “a generic process framework that can be specialized for a very large class of software systems, for different application areas, different types of organizations, different competence levels, and different project sizes” (Jacobson, Booch & Rumbaugh, 1999). The Unified Process is actually an information systems

14


Van de Weerd, Souer, Versendaal and Brinkkemper

development method, instead of a Web application design method. Nevertheless, we mention it since a) its commercial instance, the Rational Unified Process, has emerged as a de facto standard software development process (Larman, Kruchten and Bittner, 2001); and b) it has had a significant influence on later developed web application design methods. Distinguishing features are captured in the following key words: use-case driven; architecture centric; and iterative and incremental. The lifecycle consists of 4 phases, namely inception, elaboration, construction and transition. In the four phases five core workflows are addressed, which are: requirements, analysis, design, implantation and test. Since 1998, several methods and techniques specifically for designing Web applications have been developed. First of all, in 1998 the Website Design Method was developed by De Troyer and Leune. WSDM is a user-centered method for the design of kiosk Web Sites. A kiosk Web site mainly provides information and allows users to navigate through that information (De Troyer and Leune, 1998). The two basic characteristics of WSDM are the audience driven approach, and the explicit conceptual design phase. The conceptual design can be performed by using techniques like OMT or E-R modeling. Subsequently, Sauer and Engels (1999) proposed the UML Extension for Modeling Multimedia Applications. They define a multimedia application as an application that combines at least two media objects and shows time-dynamic behavior. Aspects of the application which are covered in this extension are: (a) logical structure; (b) spatial presentation; (c) predefined temporal behavior; and (d) interactive control. Another extension was developed by Baumeister, Koch & Mandel (1999). They propose this UML Extension for Hypermedia Design, because the diagrams of UML are not sufficient to model aspects as navigational space and graphical representation. Koch (2001) proposed the UML-based Web Engineering (UWE) approach. This approach is object-oriented, visualized with UML and based on the Unified Process. UWE is a systematic, prescriptive, user-centric, UML-based, iterative and incremental method for adaptive hypermedia systems (Koch, 2001). Brusilovsky, as cited in Koch (2001), provides the following definition of adaptive hypermedia systems: “hypermedia systems which reflect some features of the user in a user model and use this model by adapting various visible aspects of the system to the user”. UWE covers the full development process, divided in requirements analysis, conceptual, navigation and presentation design (Koch, 2001). WebML is a notation for specifying complex web sites at the conceptual level (Ceri, Fraternali and Bongio, 2000). Its specification consists of four perspectives: (a) the structural model; (b) the hypertext model; (c) the presentation model; and (d) the personal model. It is not based on UML, but it is compliant with it. It does not propose a new language for data modeling, but is compatible with existing notations such as E-R modeling and UML. Also, WebML supports XML syntax, which can be used by software generators. Finally, W2000 is a framework for designing web applications based on the preexisting assets UML and HDM (Baresi, Garzotto, and Paolini, 2001). According to the authors, the integration between UML and HDM consists in (1) defining several stereotypes and customizations of diagrams to render HDM with UML; (2) specifying guidelines to use UML as a way to specify some of the dynamic and operational aspects of web applications; and (3) refining use case diagrams to describe high-level


15


user requirements, related to both functional and navigational aspects (Baresi, Garzotto, and Paolini, 2001). 1.3 Research Question Over the years Web applications have evolved in, and make use of, CMS-based Web applications. Since the existing web application development methods do not cover content management aspects, there is a need for methods for developing CMS-based Web applications. This led us to our research question: “How should a design method be constructed for the process of implementation of CMS-based Web applications?” We use assembly-based situational method engineering to develop the new design method. The advantage of this method is that we can reuse relevant, established method fragments of existing methods. In this way, an optimized method for every implementation situation is being developed. A modeling technique that integrates activity diagrams and class diagrams is developed for the purpose of analyzing existing methods and assembling new methods. The primary measure of success of a software system is the degree to which it meets the purpose for which it was intended (Nuseibeh and Easterbrook, 2000). Hence, requirements analysis is an important part of the development process. Also in implementing CMS-based Web applications, requirements analysis is important. Lowe and Henderson-Sellers (2001), for example, highlighted the need for a designdriven requirements process that structures the way in which design activities for Web systems can be linked to the clarification of requirements through an appropriate model of domain uncertainty. Also, Escalona and Koch (2004) state that “Web applications require a more extensive and detailed requirements engineering process due to the number of stakeholders involved and due to the diversity of the requirements including among others requirements on the navigation and on the business processes as well as Web usability”. Therefore, the focus in this article is on the first phases of the development process where requirements are identified, described and validated. The paper is organized as follows. In section two the process of method engineering is described. Then, in section three, we propose our situational method for CMS-based Web applications. In section four, the validation is described and finally, the conclusions are covered in section five.

2

Assembly-Based Situational Method Engineering

2.1 Approach The approach to situational method engineering described in most literature is quite clear. Brinkkemper (1996) recognized the following steps: (1) characterization of the project, (2) selection of method fragments (that are stored in a method base), and (3) assembly of method fragments. The experience gained in this process is new input for the method base. Saeki (2001) states that the simplest way to construct a new method is first to put meaningful method fragments in a method base, then to select useful method fragments from this method base, and finally adapt and integrate them in a new method. Ralyté, Deneckère and Rolland (2003) have developed the assemblybased process model for situational method engineering. This model describes three steps to develop a new situational method. The steps are: (1) specify method requirements, (2) select method fragments and (3) assemble method fragments.

16



In the described research it is either assumed that the method base with method fragments is already filled, or that the methods that are to be stored in the method base are already selected. In case of developing methods for a relatively new information systems field, in this case CMS-based Web applications, the method base needs to be filled first. Therefore, we propose the following steps to develop a new situational method for implementing CMS-based Web applications: 1.

Analyze implementation situations and identify needs.

2.

Select candidate methods that meet one or more aspects of the identified needs.

3.

Analyze candidate methods and store relevant method fragments in a method base.

4.

Assemble a new method from useful method fragments and use route map configuration to obtain situational methods.

This process is supported by a meta-modeling technique, especially developed for method engineering purposes. This technique, in which a process-data diagram is built, is used in analyzing, storing, selecting and assembling the method fragments. First, we will outline the meta-modeling technique that is used to support the selection and assembly process. Then, in the next section, the steps of the process model are exemplified by bringing them into practice. 2.2 Meta-Modeling Technique The technique developed to model the activities and artifacts in the development process is a meta-modeling technique, expressed in process-data diagrams. Saeki (2003) proposed the use of a meta-modeling technique for the purpose of attaching semantic information to the artifacts and for measuring their quality using this information. In this research the meta-modeling technique is adopted and adjusted to reveal the relations between activities (the process) and data (the deliverables that are produced in the process) of the development method. This makes it possible to fragmentize methods and to configure both the process and data part of a (situational) method. A process-data diagram consists of two integrated meta-models. The left-hand side is a meta-process model based on a UML activity diagram (OMG, 2003), and the right-hand side is a meta-data model is based on a UML class diagram (OMG, 2003). In Figure 1 the integration of both meta-models, which results in a process-data diagram, is shown. The dotted arrows indicate which concepts are created or adjusted in the corresponding activities.


17


Figure 1: Process-data diagram Some unique adjustments to the standard UML notation as described by the OMG (2003) in both the activity diagram side and class diagram side have been made. The first adjustment is the use of unordered activities. Unordered activities are used when sub-activities within an activity do not have a pre-defined sequence in which they need to be carried out. This construction is very useful. An example is describing the product vision, which consists of the sub-activities describing the background, goals, assumptions, features and scope. No pre-defined sequence needs to be followed through these sub-activities In Figure 1 activity two is illustrated as containing three sub-activities. Sub-activity four is sequential and sub-activities five and six are unordered. Note that the fragmentation of the method is performed according to the decomposition of activities. Another adjustment is the use of three different types of concepts. We need these different types to indicate whether a concept is standard or complex. The difference between both concepts is that a standard concept does not contain any sub-concepts and a complex concept does. For the purpose of abbreviation it is sometimes better to not depict the sub-concepts of a complex concept. Altogether we use three different types of concepts: •

18

Standard concept, which contains no further (sub)concepts. A standard concept is visualized with a rectangle. An example of a standard concept is visualized in Figure 2, namely the concept actor. This concept contains no further (sub)



concepts. However, it is possible that an actor can possess several attributes. Another example of a standard concept is a term in a glossary. •

Open concept, which is an expanded complex concept that consist of a collection of (sub) concepts. An open concept is visualized with an open shadow. In Figure 2, use case model is represented as an open concept. The use case model is an open concept and consists of one or more actors and one or more use cases. Other examples of open concepts are a domain model, consisting of several terms(or concepts) and relations.

•

Closed concept, which is an unexpanded complex concept that consist of a collection of (sub) concepts. A closed concept is visualized with a closed shadow. Use case in Figure 2 is an example of a closed concept. Note that the context of which it is modeled is important. A use case is detailed in a use case description, which has a flow of events, conditions, special requirements, etc. Also, a use case can have a priority. Because in this case we decided it is unnecessary to reveal that information, the use case is illustrated with a closed concept. Another example of a closed concept is a class diagram. For this concept, the same holds as for the use case diagram.

Figure 2: Example of standard, open and closed concepts

3

GX WebEngineering Method

3.1 Introduction The research described in this work is carried out at GX creative online development, a web technology company in the Netherlands. GX is active in the fields of content management, online application development, and integration of backend systems in portal solutions. The company implements web applications, using GX WebManager, a generic CMS-based web application tool. GX WebManager enables people without a specific technological background in creating, maintaining and integrating several dynamic websites and portals. In addition to their product, the company also provides a service, which is creating a web application ‘around’ the CMS-based Web application. The development of this web application is currently carried out by a proprietary method. However, the need exists to optimize this method in order to save time and money. Also, the need for a standardized web application development method exists, which can be used by implementation partners of the company. Therefore we developed the the GX WebEngineering Method (WEM). In the next sections, the development of WEM is outlined, following the four steps as described in section 2.1.


19


3.2 Implementation situation analysis Brinkkemper (1996) as well as Kumar and Welke (1992) stress the importance of distinguishing development situations. In this research, we use the term implementation situations, since the project deals with the implementation of a CMSbased Web application. Consequently, the first step in the method engineering process is to analyze the projects, categorize them in implementation situations, and identify their specific requirements. The categorization of implementation situations is based on their distinguishing characteristics. Karlsson (2002) followed a similar process as Brinkkemper (1996) and Kumar and Welke (1992) in abstracting projects into development situations, but for the purpose of method configuration. He defined a characteristic of a development situation as: “a delimited part of a development situation, focusing on a certain problem or aspect which the method configuration aims to solve or handle”. We use this definition to define a characteristic of an implementation situation, that is: “a characteristic is a delimited part of an implementation situation, focusing on a certain problem or aspect which the method aims to solve or handle”. In 2004 GX completed about 80 implementations. These projects vary in size, sector and type. The number of employees of the customer organizations ranges from a few to tens of thousands of employees. These implementations have been executed in a range of industries, like services, sports organizations, publishing companies, media, government, education, knowledge centers, and health care. Resulting from artifact research and semi-structured interviews, we concluded that three kinds of implementation situations exist at GX: standard, complex and migration projects. The latter one was easy to identify. When a large amount of content from an existing Web application needs to be migrated to the new Web application, this is classified as a migration development situation. However, the difference between standard and complex implementation situations is more ambiguous. Kumar and Welke (1992) and Van Slooten en Hodes (1996) mention several characteristics for the categorization of development projects that are of importance. In general one can state that these factors are deduced from the context, organization or from technical aspects from the project (Karlsson, 2002). In Table 1 the adopted characteristics per area are described. Table 1: Implementation situation characteristics Area

Characteristic

Context

Dependency (to external activities & conditions) Level of innovation (of the applied technology, methods, tools and techniques)

Organization

Number of stakeholders Uncertainty of customer’s expectations by management team Uncertainty of development activities by customer

Technique

Complexity (of functional components) Number of relationships (to existing systems)

20



The characteristics listed in Table 1 can be used to categorize the development situations. Every characteristic can be labeled with a value: high or low. In general we state that the complexity of an implementation situation depends on the amount of characteristics that is labeled with a high value. When more than three of the values are high, it should be categorized as a complex development situation. Otherwise, it is a standard development situation. In this work we focus on standard and complex development situations. Requirements were obtained by conducting semi-structured interviews with consultants, project managers and software architects; and artifact analysis of existing requirements specifications and project evaluation documents. Several problems were found and translated into overall needs, standard implementation situation needs and complex implementation situation needs. In Table 2 example needs are given for each implementation situation. Table 2: Implementation situation needs Situation

Need

Standard & Complex

The method should deliver a requirements document that is understandable for the customer and informative for the stakeholders at GX.

Standard

Standard project often have a small budget. This implies that the amount of time for specifying the requirements is limited. Therefore, the method should make it possible to translate the requirements quickly into WebManager solutions.

Complex

A solution has to be found to the problem of changing requirements after the contract is signed. Although one can expect the requirements to change during the requirements analysis, the customer often does not understand that this affects the budget.

3.3 Candidate method selection The following step is the selection of candidate methods from which method fragments are extracted and stored in a method base. After conducting a literature research, we chose to make use of Unified Process (Jacobson, Booch & Rumbaugh, 1999) and UML-based Web Engineering (Koch, 2001). In choosing the candidate methods, the following considerations were taken into account: (a) the Unified Process is very suitable to divide into fragments and store in a method base; (b) UWE combines the strengths of the Unified Process with several Web-specific characteristics; (c) consultants who are going to use the method are already familiar with RUP, the commercial variant of the Unified Process; and (d) both methods use UML as modeling language, which is the standard notation for modeling object-oriented systems and widely accepted by the software engineering community (Baresi, Garzotto and Paolini (2000). 3.4 Candidate methods analysis All three methods, GX development process, Unified Process and UML-based Web Engineering, are analyzed by expressing the process in a process-data diagram. From


21


every method main and sub activities are identified. Each of these activities results in a deliverable, which is represented at the data-side of the diagram. In Figure 3 is illustrated how a method fragment is visualized. It represents a fragment of the requirements workflow in UML-based Web Engineering. On the process-side, one activity (use case modeling) and four sub-activities can be found. The first sub-activity, find actors and use cases, results in the concepts actor and use case. Next, a priority is given; the use case is detailed by providing it with a description; and, finally, the use cases are structured, which results in the use case model. The use case description is not expanded in this fragment, since the subconcepts of this complex concept were of no importance in this context.

Figure 3: Implementation situation characteristics All process-data diagrams that are produced form the method base, from which fragments are selected to assemble the new method. The complete method base can be found in Van de Weerd, 2005. 3.5 New Method Assembly Based on the defined implementation situations and requirements, we chose which method fragments to use in the new method. In order to assemble the right method fragments to the implementation situations, the needs of every situation were examined, after which the method fragments were mapped with the implementation situations. We chose to represent the results of the method engineering process as routemaps. The advantage of using routemaps, compared to using different methods per situation, is that it preserves the method from inconsistencies and that updating of the method is easier. The routemaps are static, that is, when an implementation situation is chosen, the route that is followed is definite. However, if usage of WEM indicates that parts of the method are not useful, the routemap can be adapted. Also, when a new implementation situation is identified, a route can be added to the method. The complete method is divided in six project phases: acquisition, orientation, definition, design, realization and implementation. In Figure 4 the process-data diagram of the definition phase of WEM is illustrated.

22



Extensive requirements elicitation Goalsetting

Describe background Describe goals

List features

Describe scope

List assumptions [complex] [standard] User & Domain Modeling

Domain modeling Define important terms

Identify visitors Describe information needs

Identify relations

Identify CMS users

Draw class diagram

Describe CMS needs

Use case modeling Describe actors

Extract use cases from feature list

Draw use case diagram Describe standard use cases Describe custom use cases

Application Modeling

Describe navigation Describe user interface [complex]

[standard] Translate features to components

Describe application implications use cases

Describe complex components Describe CMS adaptations

Describe interfaces other systems Describe migration issues Additional requirements description [complex]

[standard]

Requirements validation

Figure 4: New method - Activities in the definition phase


23


We preferred to show both standard and complex routes in one diagram, to make clear what the differences are between the two implementation situations. Therefore, we omitted the data-side of the diagram. The main activities in the diagram are marked to indicate from which method they origin. A checked pattern indicates that this method fragment originates from the old method at GX; grey indicates that it is a UWE fragment; and, finally, white indicates a Unified Process origin. The main difference between the standard and complex route is, next to the extensive requirements elicitation and validation, the use of use case modeling. In the complex route this is used to describe the people who will interact with the Web application, as well as how they will interact with the system. In the standard route this is partly handled in the user and domain modeling fragment and partly in the application modeling. In the appendix, the process-data diagrams of the definition phase of both the standard (Figure 5) and complex (Figure 6) routes can be found.

4

Validation

We applied two types of validation: expert validation and a case study. Because of scoping issues, only the definition phase is covered. 4.1 Expert Validation WEM was developed with input of the requirements management workgroup. The goal of this workgroup was an overall improvement in the requirements process at GX. Members of the workgroup were consultants and project managers of GX and one external consultant. WEM was assessed in this workgroup. Two route maps of the method were validated, namely the standard and complex route maps. The results were positive, for the following reasons: •

The distinction of standard and complex implementation situations was perceived as very useful.

•

The use of user and domain modeling in the standard route was seen as very practical.

•

Use case modeling the complex route was seen as very useful.

4.2 Case Study The route map for complex implementation situations was tested in a case study. In the case study the method was used in a project that consisted of building a Web application for a large telecommunication organization in the Netherlands. The purpose of the Web application was to support the testing of new products and services that are offered to a limited group of customers in a limited period of time. Employees of the organization should be able to develop and test a new offer with the application, without the help of GX. Several connections with existing back office systems had to be realized. Also, online payment of the products and services had to be supported. Finally, a special application for the Customer Care department needed to be developed, in order to support this department with customer service. The project had an estimated budget of 400 man hours. Several stakeholders were involved in the requirements phase of the project. At the side of GX these were: (a) project manager, (b) consultants, and (c) software architect. Stakeholders of the

24



customer organization were: (a) business project manager, (b) technical project manager, (c) Web department manager, and (d) Customer Care project manager. 4.2.1

Usage of the Method

Before the start of the project, a requirements document template was created. Also, a briefing was given to the consultants and project manager to outline the new method. The requirements analysis was carried out by GX consultants and reviewed by the project manager. The requirements document consisted of thirty-two pages. The use case model consisted of seven actors, who were connected to seventeen use cases. Eight of these use cases were immediately translated to standard GX WebManager components. The others were more complex and were provided with use case descriptions. One part of the method was omitted, namely the drawing of a class diagram to model the domain, since the use was not necessary in this project. In an interview, the consultants responded positive to the new method. In comparison to the old method, WEM was more structured and better able to describe complex functionalities. Also, the domain modeling was commented on as being clarifying and useful. A remark was made on the use of a feature list, which was not recognized as useful. Another comment was that use case modeling is timeconsuming. However, the budgeted hours for this project were not exceeded. 4.2.2

Evaluation of the Requirements Document

The requirements document was send to the all stakeholders at GX and the customer. At GX, the requirements document was perceived as ‘clear, structured, and with the right level of detail’. All stakeholders agreed that this document was an improvement to former requirements documents. However, the project manager expressed the fear that this method was too time-consuming. To the project organization project members a survey was send. The questions were divided in several categories. First, questions on the requirements process were asked in the categories (a) structure, (b) team, and (c) general. Then, questions on the requirements document were asked in the categories (a) understandability, (b) correctness, (c) use case modeling, and (d) general. The answers to the survey appeared to be overwhelmingly positive. On a Likert scale of 1 to 5, where 1 was most negative and 5 most positive, a mean score of 4.4 was received. The given answer ranged from 3 to 5. No significant difference in scores was measured between the “process part” and “document part”. In summary, the requirements document was ‘understandable and logical’, with the right level of detail. Also, the functionalities described in the use cases perfectly matched the functionalities they wanted to be realized. Use cases were considered to be a great way to describe functionalities, since they are understandable for technical and non-technical project members. 4.2.3

Discussion

Summarizing, the results of the case study were positive. Nevertheless, some comments were made. First of all, only the definition phase was covered, which implies that the acquisition phase was done in the ‘old-fashioned’ way. The most obvious consequence was that the feature list, which should have been created in the


25


acquisition phase and used in the definition phase, was seen as redundant by the consultants. The customer, however, did not comment on this. Secondly, all project members at the customer’s organization were familiar with use case modeling. If they were not, the requirements document might have been more difficult to understand. Using the method may lead to new insights. The developed method is not static, but dynamic. Users of the method should adapt it to their own preferences. When it appears that an activity structurally is omitted, the method should be updated.

5

Conclusions

In this paper an improvement is proposed to the existing method engineering process. The described process helps in developing a method base, consisting of candidate methods that are selected based on how they meet the identified implementation situation needs. Secondly, a meta-modeling technique, resulting in a process-data diagram, for method engineering is developed. By modeling the relations between activities and concepts, it is possible to engineer both process and data part of the method. In the future, this technique should be updated, to keep it consistent with the UML standards. Looking at the delivered results of the research, a method has been developed and tested for the process of implementing CMS-based Web applications: the WebEngineering Method. This method can be used for standard and complex implementation situations, by following the described route maps. Since no such method existed, this research is an important addition to the existing information systems and Web development methods. A limitation on WEM is that only the acquisition, definition, orientation and analysis phases are covered. In addition, only the definition phase has been validated. However, the results were promising. In future work, the method should be expanded and refined, based on experiences in executed projects. Also, besides the Unified Process and UML-based Web engineering, other relevant methods can be analyzed to improve the method base. Finally, a challenge lies in the integration of the method in GX WebManager. As the content management system itself is capable to store structured documents, it makes sense to integrate the WEM design method as an extension to the WebManager product. This strategy is similar to the extension of the Oracle DBMS with Oracle CASE tools, or of the Baan ERP software with the Dynamic Enterprise Modeling (DEM) tooling (Brinkkemper, 1998).

Acknowledgements The authors wish to thank Roel Bouwmans, René Janssen and Bob Kennedy for giving input to WEM during its development. We thank Nils ten Broeke, Christiaan Hoogerwerf, Michel Teunissen and the rest of the project team who developed the Web application, as described in the validation, for their contributions on the validation of this paper. Also, the project team members of the customer are thanked for their cooperation in testing and validating WEM. Finally, we would like to thank the anonymous reviewers for their extensive remarks that led to the improvement of this paper.

26



References AYDIN MN and HARMSEN, F (2002) Making a Method Work for a Project Situation in the Context of CMM. Lecture Notes in Computer Science, 2559, 158-171. BARESI L, GARZOTTO F and PAOLINI P (2001) Extending UML for modeling web applications. Proceedings of the 34th Annual Hawaii International Conference on System Sciences, HI, USA. BAUMEISTER H, KOCH N and MANDEL L (1999) Towards a UML extension for hypermedia design. In France, R., Rumpe, B. (eds.), Proceedings «UML» ’99, Lecture Notes in Computer Science, 1723, 614-629. BRINKKEMPER S (1996) Method engineering: engineering of information systems development methods and tools. Information and Software Technology, 275-280. BRINKKEMPER S (1998) Global Process Management. In Dynamic Enterprise Innovation: Establishing Continuous Improvement in Business (Es R, Ed), 4-8 - 4-15, Baan Business Innovation, Putten, The Netherlands. BURZAGLI L, BILLI M, GABBANINI F, GRAZIANI P and PALCHETTI E (2004) The use of current content management systems for accessibility. Proceedings of the 9th International Conference on Computers Helping People with Special Needs (ICCHP 2004), Lecture Notes in Computer Science, 3118, 331-338. CERI S, FRATERNALI P and BONGIO A (2000) A web modeling language (WebML): A modeling language for designing web sites. Computer Networks, 33, 137-157. CHEN PP (1976) The Entity-Relationship Model - Towards a unified view of data. ACM Transactions on Database Systems, 1(1), 9-36. DE TROYER OMF and LEUNE CJ (1998) WSDM : A user-centered design method for web sites. In Proceedings of the Seventh International World Wide Web Conference, Elsevier, 8594. DIETZSCH A (2002) Adapting the UML to business modelling's needs - Experiences in situational method engineering. In 2002 – Proceedings of the Unified Modeling Language; Fifth International Conference (JÉZÉQUEL J-M, HUSSMANN H and COOK S, Eds), Dresden Germany, September 2002. Springer, 73-83. ESCALONA MJ and KOCH N (2004) Requirements engineering for web applications: A comparative study. Journal on Web Engineering, Rinton Press, 2(3), 193-212. GNAHO C (2001) Web-Based information systems development – A user centered engineering approach. Lecture Notes in Computer Science, 2016, 105-118. HARMSEN F, BRINKKEMPER S and OEI JLH (1994) Situational method engineering for informational system project approaches. Proceedings of the IFIP WG8.1 Working Conference on Methods and Associated Tools for the Information Systems Life Cycle, 169194. JACOBSON I, BOOCH G and RUMBAUGH J (1999) The unified software development process. Redwood City, CA: Addison Wesley Longman Publishing Co., Inc. KARLSSON F (2002) Bridging the gap between method for method configuration and situational method engineering. Promote IT, Skövde, Sweden.


27


KARLSSON F and ÅGERFALK PJ (2004) Method configuration: Adapting to situational characteristics while creating reusable assets. Information and Software Technology, (46)9, 619-633. KOCH N (2001) Software engineering for adaptive hypermedia applications (Phd Thesis, Austria, Munich, 2001). Uni-Druck Publishing Company. KUMAR K and WELLKE RJ (1992) Methodology engineering: A proposal for situation specific methodology construction. In Challenges and strategies for research in systems development (COTTERMAN WW and SENN JA, Eds.), 257–269, John Wiley & Sons, Washington, DC. LARMAN C, KRUCHTEN P and BITTNER K (2001) How to Fail with the Rational Unified Process: Seven Steps to Pain and Suffering. Valtech Technologies & Rational Software. LOWE D and HENDERSON-SELLERS B (2001) Characteristics of Web Development Processes. In Proceedings of SSGRR-2001: International Conference on Advances in Infrastructure for Electronic Business, Science and Education on the Internet, (MILUTINOVIC V, Ed), 21, Scuola Superiore Guglielmo Reiss Romoli, Italy. NUSEIBEH R and EASTERBROOK S (2000) Requirements Engineering: A Roadmap. In: A. Finkelstein (ed.), The Future of Software Engineering, ACM and IEEE Computer Society Press. OMG (2003) UML 2.0 Superstructure Final Adopted specification, Document reference ptc/04-10-02 August 2003. Available from the Object Management Group website: www.omg.org RALYTÉ J, DENECKÈRE R and ROLLAND C (2003) Towards a Generic Model for Situational Method Engineering. Lecture Notes in Computer Science, Vol. 2681, SpringerVerlag, 95. ROSSI M, SUBRAMAH M, LYYTINEN K, KAIPALA J and TOLVANEN JP (2000) Method rationale in method engineering, Proceedings of the 33rd annual Hawaii International Conference on Systems Science, IEEE Computer Society Press, USA. SAUER S and ENGELS G (1999) Extending UML for modeling of multimedia applications. Proceedings of the IEEE Symposium on Visual Languages, 80. SAEKI M (2003) Embedding Metrics into Information Systems Development Methods: An Application of Method Engineering Technique. CAiSE 2003: The 15th Conference On Advanced Information Systems Engineering, 374-389. SLOOTEN K VAN and BRINKKEMPER S (1993) A Method Engineering Approach to Information Systems Development. In Information Systems Development Process. (PRAKSH N, ROLLAND C and PERNICI B, Eds). Elsevier Science Publisher B.V. (North-Holland). 167-186. SLOOTEN K VAN and HODES B (1996) Characterizing IS development projects. In Method Engineering: Principles of method construction and tool support, Proceedings of the IFIP TC8, WG8.7/8.2 Working conference on method engineering, Atlanta, USA. SOUER J, WEERD I VAN DE, VERSENDAAL J and BRINKKEMPER S (2005) Developing Situational Content Management System-based Web Applications. To be published in Proceedings of the Sixth International Conference on Web Information Systems Engineering (WISE 2005), New York City, New York. STONEBRAKER M and HELLERSTEIN, JM (2001) Content Integration for E-Business. Proceedings of ACM SIGMOD.PODS 2002, Santa Barbara, California.

28



VIDGEN R, GOODWIN S and BARNES S (2001) Web Content Management. Proceedings of the 14th International Electronic Commerce Conference, Bled, Slovenia, 465-480. WEERD, I VAN DE (2005) Design Methods for WebManager Implementations (technical report). University of Utrecht, Department of Information and Computing Sciences.

Appendix REQUIREMENTS DOCUMENT

1 GOALSETTING

Goalsetting

Describe background

BACKGROUND

List features

FEATURE LIST

List assumptions

ASSUMPTION

Describe goals

ASSUMPTION

Describe scope

SCOPE

1

1

1 1 1..* 1..* 1

USER PROFILE

1

1 User & domain modeling

Identify visitors Describe information needs

VISITOR INFORMATION NEED

1..*

1 has

Identify CMS users Describe CMS needs

1..*

1..*

CMS USER

1..* 1 has

CMS NEED

WEBSITE MODEL

Application modeling Describe navigation Describe user interface

NAVIGATION DESCRIPTION 1

1

1

UI DESCRIPTION

CMS MODEL

Translate features to components Describe complex components

CMS COMPONENT DESCRIPTION

0..1

1..*

1

1

1 has

Describe CMS adaptations

ADAPTATION

Describe interfaces other systems

INTERFACE

Describe migration issues

MIGRATION ISSUE

Additional requirements description

1

1..* 1..* 1..*

ADDITIONAL REQUIREMENT

1..*

Figure 5: Process-data diagram of the standard definition phase


29


REQUIREMENTS DOCUMENT

1 Extensive requirements elicitation Goalsetting

GOALSETTING

Describe background

BACKGROUND

List features

FEATURE LIST

List assumptions

ASSUMPTION

Describe goals

ASSUMPTION

Describe scope

SCOPE

1

1

1 1 1..* 1..* 1

1

DOMAIN MODEL

Domain Modeling

Define important terms Identify relations

1..*

TERM

1

1..* 1 has

RELATION

Draw class diagram

CLASS DIAGRAM

1

Use case modeling Describe actors

ACTOR

Extract use cases from feature list

USE CASE

1

1..*

USE CASE MODEL

1

1..*

Draw use case model Describe standard use cases Describe custom use cases

DESCRIPTION USE CASE DESCRIPTION APPLICATION MODEL 1

Application Modeling Describe navigation

NAVIGATION

1

Describe user interface

USER INTERFACE

1

Describe application implications use cases

APPLICATION IMPLICATIONS

Describe interfaces other systems

INTERFACE

Describe migration issues

MIGRATION ISSUE

Additional requirements description

1

1..* 1..* 1..*

ADDITIONAL REQUIREMENT

1..*

Requirements validation

Figure 6: Process-data diagram of the complex definition phase

30


Method-User-Centred Method Configuration Fredrik Karlssona and Pär J Ågerfalkb, a a

Örebro University, MELAB, Dept of Informatics (ESI), SE-701 82 Örebro, Sweden, [email protected], www.oru.se/esi/melab b Dept of Computer Science and Information Systems, University of Limerick, Limerick, Ireland, [email protected], www.b4step.ul.ie/web/Par.Agerfalk/

Abstract Method engineering approaches are often based on the assumption that method users are able to explicitly express their situational method requirements. However, similar to software requirements, situational method requirements are often vague and hard to explicate. In this paper we address the issue of involving method users early during method configuration. This is done through borrowing ideas from user-centred design and prototyping and implementing them on the method engineering layer in a computerized tool support. This tool has proven useful in eliciting situational method requirements in a continuously ongoing dialog with the method users during configuration work-shops. Keywords: Situational process, adaptation, configuration, method

1

Introduction

Method engineering (including method tailoring and adaptation) has received increased interest among practitioners. Given the trend to implement one commercial or brand-named software/systems development method (method for short) as the organization-wide method, this growing interest is natural since there is no method that fits all situations. As pointed out by Fitzgerald et al. (2003), there are hundreds of methods, although surprisingly little research has focused on how to tailor methods when used as organization-wide standard approaches. In recognition of this, we can also conclude that method requirements vary between individual projects. Projects differ with respect to the development context, delivery, project team, deadline, et cetera. These characteristics constitute method requirements that need to be taken into consideration when tailoring a method. This is one major challenge when working with situational methods: how to handle the method requirements process? Method requirements are often elicited through interviews with project members. The method engineer then uses these requirements to define a situational method, which is introduced to the project team. For example, method requirements can be used in selecting method fragments (Brinkkemper et al., 1999) or method chunks (Rolland et al., 1998) using modular method construction. In such a case, methods’ atomic concepts (e.g. modelling primitives, such as ‘class’ and ‘state’) are seen as minimal method modules, which are selected and included in the situational method. Method fragments are stored in repositories and retrieved based on the characterization that is provided by the meta-language used. Consequently, method requirements need to be formalized and expressed in the meta-language. This type of method engineering approach is anchored in at least two basic assumptions. The first assumption is that it is possible for project members to explicitly specify the required situational method and communicate the requirements to the method engineer. The second assumption is that these requirements do not Proceedings of SREP’05, Paris, France, August 29–30, 2005 Eds. Ralyté J, Ågerfalk PJ and Kraiem N

31

Method-User-Centred Method Configuration

method engineer. The second assumption is that these requirements do not change during the project’s lifetime. Evolutionary method engineering (Rossi et al., 2004) have addressed the latter using MetaEdit+ to change the situational method and corresponding tool support through the course of the project. However, the first assumption is still valid and practical experiences confirm that method requirements are often vague during the initial phases of a project. The problem is similar to that faced in requirements engineering as part of systems development, where knowledge has to be formalized and communicated between different various actors. In the systems development case, system requirements have to be communicated between end users and systems developers. In the method engineering case, method requirements have to be communicated between systems developers and method engineers. When it comes to vague systems requirements, a commonly cited approach to bridge between end-users and system developers is user-centred design and prototyping. In order to make such an approach effective, appropriate tool support is imperative. In this paper we present an approach to situational method engineering that draws on user-centred design. The focus of this paper is mainly on MC Sandbox, a computerized tool support for method configuration that incorporates important design principles of method-user-centred method configuration. To arrive at these design principles, we elaborate on the design of an approach to capturing method requirements through the use of method-user-centred method configuration, hence bridging the gap between project members and method configurators1. The remainder of the paper is organized as follows. Section 2 presents the research method adopted. Section 3 is devoted to ideas from user-centred design and to a theoretical discussion of method configuration concepts. Section 4 presents MC Sandbox, a computerized tool support for method configuration that incorporates the design principles of method-user-centred method configuration. Section 5 reports empirical experiences related to the use of MC Sandbox. Finally, Section 6 concludes the paper with a short summary of the main points.

2

Research Method Adopted

The design of MC Sandbox is part of a larger research project on developing flexible, reusable yet project specific method support. This project includes the development of a theoretical framework and a Method for Method Configuration (MMC). These are operationalized in the MC Sandbox computerized tool, together with design ideals of how best to capture method requirements. The phenomena discussed in this paper are largely artificial ones. This means that they can be both designed and studied. The design concept itself is a duality, it is both a process and a product (Hevner et al., 2004). The purpose of designing a product is to ‘support achievement of goals’ (Walls et al., 1992), in our case a methoduser-centred requirements process for method tailoring. Since we are dealing with artificial phenomena, we have the possibility to affecting the ways of working that are operationalized in MC Sandbox. According to March and Smith (1995) ‘design science products are of four types, constructs, models, methods, and implementations.’ This means that the concepts and models found in MMC (the method) shapes the MC 1

Method configuration is a special kind of method engineering where one specific method is the starting point for tailoring (Karlsson and Ågerfalk, 2004). Consequently, ‘method configurator’ is treated as a specialization of the method engineer role.

32


Karlsson and Ågerfalk

Sandbox implementation. Consequently, in order to achieve method-user-centred method configuration we had to involve qualified practitioners in the design of concepts, models, MMC and MC Sandbox. Based on this fundamental view on knowledge development our choice of research strategy fell on what has been called ‘collaborative practice research’ (Mathiassen, 2002), a strategy often referred to as action research (McKay and Marshall, 2001). Action research can be viewed as collaboration between researchers and practitioners where the researchers share the problems and concerns of the practitioners. The collaborative action research strategy has been operationalized in four action cases where the concepts, models, MMC and MC Sandbox have been designed incrementally. The iterative research process has included three grounding processes: internal, external theoretical and empirical grounding (Goldkuhl and Cronholm, 2003). Internal grounding focuses on internal consistency of concepts, which are included in the meta-method and MC Sandbox. External theoretical grounding means turning to the body of knowledge that exists outside the knowledge developed in the research project. For this paper, external theoretical grounding is to do with how usercentred design can be used in method engineering to facilitate method-user-centred method configuration. Finally, empirical grounding involves application of the developed knowledge, which in our case focuses MC Sandbox. Since practitioners are participating in the design process, application is interpreted in a broad sense, involving analysis, design, implementation and test in the empirical environment. Demarcating ourselves to the design of MC Sandbox, this part of the research project has been performed as a systems development project using an action research strategy. The development process was structured using a situational version of the Rational Unified Process (RUP). The chosen parts focused on requirements, analysis and design, implementation and test. In total, the development process included six iterations with clear milestones. The choice of using RUP as the systems development method during development of MC Sandbox was mainly based on the collaborating partners’ preferences. Thus this was a trade-off for practice collaboration.

3

Theoretical Base

3.1 Why Method-User-Centred? Methods exist for the purpose of supporting project members in systems and software development projects. These people are users of the method in the same sense that end-users are users of information systems created through systems development. In the latter case, the importance of harmonizing the mental models of systems designers with those of end users is often cited (Norman, 1988). These mental models are continuously shaped by experience and through interaction with the information system. However, expressing these mental models as requirements is difficult. When working with requirements in systems development, end-users have to express their requirements and their creativity has to be stimulated during that process (Maiden et al., 2004). Malcolm (2001) states that user-centred approaches, as part of Rapid Application Development, is a rigorous approach to systems development and are appropriate when addressing tacit, semi-tacit and future systems knowledge. The later is by its nature incomplete and can therefore be subject to rapid change. By means of analogous reasoning, we can similarly discuss mental models and tacit knowledge in the realm of method engineering. Stolterman (1991) discusses the


33


importance of creating an understanding of the method creator’s mental model of the method. Stolterman and Russo (1997) use the terms public and private rationality, which, figuratively speaking, could be pictured as two spheres which are possible to move towards each other. Public rationality is inter-subjective understanding about prescribed actions and produced results, or why a specific part of a method is prescribed. This argumentative dimension of methods has been referred to as a method’s rationale (Ågerfalk and Wistrand, 2003; Ågerfalk and Fitzgerald, 2005). Private rationality is expressed, according to Stolterman and Russo (1997), ‘in the skills and in the professional ethical and aesthetic judgments‘ of a person. They argue that in order to make methods valuable the method creator has not only to influence public rationality but he or she has to change the fundamental thinking of the method user, i.e. the method user’s private rationality. Otherwise method users do not find the necessary support during systems development. Consequently, it is important to involve method users early when crafting a situational method. Just as when involving end-users early in systems development, this involvement should focus on, to method users, concrete aspects. 3.2 Transferring User-Centred Ideas to Method Engineering According to Cato (2001) it is possible to view user-centred design as a triad: the user, the use and the information. This triad focuses who is using the technology, how the technology is used and what is required to support that use. Translated into method engineering we thus focus on who the method users are as a team and these users’ needs during a project; i.e. what kinds of challenges are found in the project. Part of that need is the situational method. Storyboarding and prototyping are techniques frequently used in user-centred approaches to create a feel for the proposed solution (e.g. Carroll, 1994; Madsen and Aiken, 1993). The idea is to let use-scenarios and visualization drive the design, thus making it more tangible. Visualization often starts out as simple sketches and a distinction is often made between low-fi and high-fi prototypes. A paper-based storyboard often contains the structure, possible navigation through the parts of the information system, information provided by the system to assist the user, information provided by the user, and the result of the user’s actions (Cato, 2001). Nickols (1993) emphasizes that a prototype is a working model. As such, it does not need to be complete with regard to functionality. Low-fi and high-fi prototypes differ in the degree of technical implementation and the cost of change. Low-fi prototypes have a low degree of technical complexity and hence a low cost of change. On the other hand, they also have a low degree of functionality, which is extended when we move towards high-fi prototypes. When moving these ideas to method engineering we see that visualizing the method design and its parts is essential. This means visualizing the situational method as a prototype during method configuration. Prototyping also involve a continuous evolution of the prototype and its design. Nauman and Jenkins (1982) present prototyping as a four step procedure: identify basic requirements, develop a working prototype, implement and use, and revise and enhance. The two latter activities are performed in an iterative pattern, which to some extent corresponds to evolutionary method engineering (Rossi et al., 2004) and scenario approaches (Rolland et al., 1999). Consequently, it is not surprising that the implementation of evolutionary method engineering in MetaEdit+ shares several characteristics with high-fi prototyp-

34



ing. Methods are implemented incrementally as CASE tools, with a high degree of functionality. However, there is little attention given to the initial requirements and how to provide an initial prototype. The method users are involved when a situational method already exists and is subject for revision. Consequently, evolutionary method engineering should be complemented with an approach where the method user is involved in the initial tailoring of the method. One hurdle in achieving such an involvement is the inherent complexity in method engineering. Method engineering tends to be a tedious process, especially if high-fi prototypes, such as runtime CASE tool implementations of methods, are factored into the equation. Therefore we propose to use the basic idea of low-fi prototypes and storyboarding together with the method users in method configuration. We thus combine the idea of visualizing the situational method as a prototype and reducing the amount of detail. The latter shares similarities with illustrating navigation using a storyboard, and the map construction presented by Rolland et al. (1999). Furthermore, from storyboarding we borrow the idea of visualizing information provided by the method to assist the user, the information provided by the method user, and the results of the method user’s action. The focus during method-user-centred method configuration is on what method parts add value to the development project and the project members as a team. Hence, we move away from the use of complex meta-languages when working together with the method users in the same way prototypes are preferred over complex diagrams in discussions with end users. If we return to March and Smith’s (1995) discussion about design science products we can conclude that these ideas have an affect on the design products found behind MC Sandbox which we intend to use; these design products are the concepts, models, and the meta-method that are implemented in MC Sandbox. Together these design products have to support the simplification of method modules to emulate a low-fi prototype and still provide the information needed for discussing method assistance and potential results of different choices. 3.3 Concepts in MC Sandbox MC Sandbox incorporates three basic concepts for method configuration: the method component, the configuration package, and the configuration template. A method component is a self-contained part of a method that expresses the transformation of one or several artefacts into a defined target artefact together with the rationale of such a transformation. The concept is designed to provide black-boxing of the content of the method component. This means that the concept has two views: one internal view containing all the details and one external view providing a filtered version of these details (Karlsson and Wistrand, 2004). The filter is termed the method component’s interface which contains the input and output artefact of the component, together with the component’s overall goals. The latter thus returns to the idea of achieving rationality resonance. Together these parts of the method component provide a simplified view of the method’s intended assistance and the intended results of prescribed actions it contains. The basic idea behind method configuration in MC Sandbox is to use characteristics and the method rationale, which is expressed by method components, to make choices whether or not to include a method component in the current configuration. A characteristic is a delimited part of a development situation type, focusing on a certain


35


problem or aspect which the method configuration aims to solve or handle. Characteristics are used to narrow the focus to a delimited part of the development situation type, which is an abstraction of similar projects. Each characteristic addresses one or several method components and their purpose of existence in a situational method. In order to facilitate reuse, which improves the possibilities of prototyping situational methods, the concepts of configuration package and configuration templates are introduced and associated to the characteristic concept (Karlsson and Ågerfalk, 2004). A configuration package is a method configuration of the base method suitable for one single value of a characteristic. Thus, a configuration package is a classification of method components based on overall goal relevance for a specific value of a characteristic. For example, a characteristic may be ‘Difficult to elicit requirements?’ and the value is the answer ‘Yes.’ Such a characteristic focuses the requirements part of the base method, and the intention is to select method components that ease communication of requirements between end users and project members, such as prototypes and storyboards. Configuration packages contain demarcated parts of a situational method. However, real world situations are often complex settings that include multiple characteristics. Therefore, there is a need for a combination of characteristics, and consequently configuration packages, to capture many situations. A configuration template does all that. A configuration template is a combined method configuration, based on configuration packages, for a set of recurrent project characteristics. Hence, configuration templates are aggregates of configuration packages. These templates can be reused during method configuration as starting points for retrieving a closer match between the situational method needed in a project and the original base method – configuration templates are reusable pre-tailored versions of the base method (Karlsson and Ågerfalk, 2004). A situational method is a configuration template finetuned and adapted to a specific project, and used in that project. The configuration template selection is based on the project characterization, where the existing set of characteristics is reused as a base for questions to ask to project members. Method configuration in MC Sandbox can have different starting points depending on the possibilities to find existing patterns to reuse. If a suitable configuration template can be found then the configuration process is rather straightforward – it is fine-tuned and used as a situational method. In situations where no matching configuration template can be found, a new one can be constructed based on existing configuration packages. Hence method configuration can involve the selection of configuration packages as well as complementing with new ones.

4

Method Configuration Using MC Sandbox

Method configuration using MC Sandbox is divided into five sub-processes, of which two are purely supportive: define method component and edit base method. In the remainder we will focus on the three core processes of method configuration: define a configuration package, define a configuration template, and define a situational method. We thus assume that method components exist in the MC Sandbox repository as does a base method defined based on these components. The reason for this choice is our focus on how to involve method users in an interactive process of tailoring the base method together with the method configurator.

36



4.1 Define Configuration Package The starting point for defining a configuration package is the base method, and hence each configuration package inherits the structure of the base method. Thus, when we add a method component to the base method in MC Sandbox, it is added also to the configuration packages. Through this approach we have a starting point for a storyboard-inspired discussion about the base method given a specific characteristic. Figure 1 illustrates the graphical user interface (GUI) of MC Sandbox when working with configuration packages. The screen is divided horizontally, where the lower section contains the method modelling area (labelled modelling view), and the upper section contains the status of selected method components (labelled method component status). The right part of the upper section contains the complete set of existing configuration packages based on the base method in use. The tree structure is sorted by the characteristics that the configuration packages belong to. The modelling view makes use of the two views of method components. The external view is used when modelling a configuration package together with method users. A method component is depicted as a rectangle in the modelling view. Arrows connecting method components show the flow of artefacts between the components, which can be one-way or two-way. For example, in Figure 1 the result from the Current State Infrastructure component is recommended as input to the Vision/Scope component. Different colours are used to illustrate the classification of method components (in the current version of MC Sandbox four classifications exist: perform as is, omit from the configuration, exchanges an existing component, not applicable for this characteristic). Hence, the base method is illustrated as a low-fi prototype, useful for discussing effects of suppressing different components as well as introducing new ones, with a minimum of details. Method Component Status

Modelling View

Figure 1. Defining a Configuration Package.

When a method component is selected in the modelling view, the content of that method component’s interface is presented in the upper right section of the GUI. For example, the Vision/Scope component has been selected in Figure 1 and hence its interface is presented. The interface contains information about recommended input,


37


the component’s deliverable (i.e. its output artefacts), the component’s rationale and the current classification (as is means that it is to be performed as prescribed by the base method). Modelling the configuration package begins with specifying the demarcation of the configuration package, that is, defining what parts of the base method is of interest when discussing this specific characteristic. When creating a new configuration package, all of the base method’s components are classified not applicable. This means they are considered to be outside the characteristic’s scope. Subsequently, relevant method components are brought into scope based on the method users’ opinions. This is an iterative process where each method component is discussed based on their method rationale, as expressed in the method components’ interface. Classification of existing method components is done based on the method users’ needs given the constraints of the characteristics. The configuration rationale is documented in MC Sandbox using the upper middle part of the GUI, which means we can always examine the arguments leading to a specific classification. 4.2 Define Configuration Template In Section 3.3 we defined a configuration template as an aggregate of configuration packages. It follows that the selection of relevant configuration packages and their integration are central parts when defining a configuration template. The GUI used for this shares basic structure with the GUI for defining a configuration package. This means that the screen is divided into an upper and lower part. The upper part contains information about selected items. Figure 2 illustrates the lower section, which is vertically divided. The left part contains the functionality to work with the development situation type profile. The right-hand section of the user interface is devoted to the actual modeling of the configuration template’s content. Development Situations’s Profile

Modelling View

Figure 2. Defining Configuration Template.

A development situation type is characterized by means of the configuration packages that are selected for the existing range of characteristics. In Figure 2 we see examples of four characteristics and their affiliated configuration packages. Each characteristic

38



is formulated as a question, and the configuration packages act as possible answers. The method configurator uses the checkboxes to make choices based on the ongoing discussion with the method users. Only one configuration package is possible, but not necessary, to choose per characteristic. Consequently, if a characteristic is found to be irrelevant, it can be left out when selecting configuration packages. When the relevant selection has been made, the method configurator clicks on the build button found in the bottom right corner of the GUI. This causes MC Sandbox to build a configuration template based on the selected configuration packages. If conflicts arise during this build, the tool lists them together with a reason. The method configurator and the method users have to solve these conflicts in each specific case and give priority to one of the configuration packages that are involved in the conflict. Yet again, the method rationale of the method components is matched with the needs of the method users. When the conflict has been resolved, the configuration template can be rebuilt. The result of the building process is a prototype of a situational method, presented in the same low-fi fashion as used when working with configuration packages. If the method users are not satisfied, modifications can be made either through selection of a different set of configuration packages and rebuilding the template, or through manual reclassifications of method components. 4.3

Define a Situational Method As stated above, each situational method is based on a configuration template. The range of characteristics is used once again, in this case to create a project profile. The method configurator and the method users use the checkboxes shown in Figure 3 to indicate these choices.

Figure 3. Create Project Profile and Search a Configuration template.

One configuration package can be selected for each characteristic, if the characteristic is found to be relevant. A project profile contains the criteria for searching in the repository for matching development situation types and corresponding configuration


39


templates. Hence, this approach does not rely on a complex query language, as for example Method Engineering Language (Harmsen, 1997) or SGMLLQL (Ralyté, 1999), for administration and retrieval of reusable method assets. The decreased complexity improves possibilities to perform method configuration interactively together with the method users. The search result is a list of possible candidate configuration templates. The method configurator and the method users can choose from the list of configuration templates and the MC Sandbox then generates a situational method. The situational method is presented in the same type of view as used for presenting a configuration package or template. Adjustments of the situational method are possible since the configuration tool is available at the user interface. Consequently, it is possible to reclassify method components using the classification schema mentioned above. Typically, as the project progresses and the understanding of the method requirements evolve, both characteristics and corresponding configuration packages evolve accordingly.

5

Empirical Experience

The MC Sandbox functionality addressed in this paper has been tried in a small-sized systems development organization and in controlled experiment situations. The tool has been used both during reconstruction of existing situational methods and in building new ones. The former has been a starting point for building the repository content based on existing projects. However, at the same time, adjustments have been made based on post-project experiences. Sub-sets of the project teams have been involved during both construction and reconstruction of reusable patterns (configuration packages and templates). The content of the repositories has been used as the starting point for discussions about specific configurations. For example, we have discussed the options of reusing existing configuration templates based on the profile of the project. The characteristics formulated as questions have been a good starting point. They have helped the method users to formulate characterization of their projects and missing configuration packages. One of the project managers’ comments about a configuration package illustrates this aspect ‘this configuration package looks similar to the one I have in mind, except for …’ Consequently, earlier configuration work was reused and made concrete through visualisation of parts of a situational method. Furthermore, the use of characteristics made the discussion with method users focused, since a smaller part of the base method was addressed. The implementation of configuration packages in MC Sandbox made it possible to quickly sketch a prototype of a configuration, which could later be returned to for further elaboration. During the initial part of the configuration workshop discussions, several characteristics and configuration packages where drafted. They were documented as brief ideas and were later elaborated in more detail using an iterative pattern, similar to the ideas of refining a prototype. For example, such decisions involved moving the demarcation for a configuration package, which also affected related configuration packages. The method users often drove these decisions, based on their experience and needs using the low-fi method prototype as a starting point for analysis. During the method configuration workshops the external view of method components was used to discuss implications of different choices of method components.

40



The storyboard inspired design made it easy to visualize the effects of different classifications. The project manager of one of the projects stated, ‘it [MC Sandbox] is a good idea, it is an easy way to elicit steps to perform.’ For example, the method users discussed the effect of suppressing the usage scenarios in Microsoft Solution Framework when working with requirements engineering. In cases where the requirements are difficult to elicit, the method users preferred the prototype component. The main reason for this decision is found in the rationale behind a prototype, which was interpreted as ‘To express the features needed and their design.’ The main difference compared to a usage scenario is the possibility to express the design in a more concrete way. During this discussion it was also possible to directly address the impact on later parts of the method support. This was made possible through the low-fi prototype view of the base method and visualization of relationships between method components. Subsequently, the method users were, as a team, made aware of the fact that this could give weaker input when writing test cases. The team aspect is important, since it improves the different members’ understanding of why a method component has to be included. This is a major advantage of using a method-user-centred approach to method configuration. Since major sets of actor roles were represented during the method configuration workshops it was easy to receive response on collaboration issues. This provides for the method configurator to work with a multi-role perspective during method configuration and continuously have an ongoing discussion about decisions and consequences. The line of reasoning about specific classifications was included in the configuration rationale, using the configuration rationale textbox. These arguments were later reused when combining different configuration packages into configuration templates. Thus, it is possible to build awareness of how certain classifications could affect other parts of the base method, which are not included in the configuration package. The GUI design used for modelling configuration packages, templates and situational methods has received different opinions depending on the complexity of the base method. When the complexity of the base method increases, these views tend to become cluttered, since the number of relationships between method components increases. This has been reported on by Karlsson and Wistrand (2004).

6

Conclusion

In this paper we have addressed a basic assumption of many method engineering approaches: that it is possible for project members to explicitly specify requirements on a situational method. In order to do so we have turned to user-centred design and specifically prototyping and storyboarding. We have shown that appropriate tool support provides the means to achieve method-user-centred method configuration. Given appropriate high-level modelling concepts, such as the Method for Method Configuration concepts of method components, configuration packages and configuration templates, it is possible for a method configurator to work interactively with method users to construct a suitable situational method by means of collaboratively elicit, negotiate and commit to method requirements. This way, the method users’ and the method configurator’s understanding of the current development practice develops incrementally and rationality resonance is achieved at reasonable cost.


41


Acknowledgements This work has been financially supported by the Knowledge Foundation (KKFoundation) through the programme for the promotion of research in IT at new universities and university colleges in Sweden (IT-Lyftet), and the Science Foundation Ireland Investigator Programme, B4-STEP (Building a Bi-Directional Bridge Between Software ThEory and Practice).

References ÅGERFALK PJ and FITZGERALD B (2005) Methods as Action Knowledge: Exploring the Concept of Method Rationale in Method Construction, Tailoring and Use. In Proceedings of EMMSAD'05: Tenth IFIP WG8.1 International Workshop on Exploring Modeling Methods in Systems Analysis and Design (HALPIN T, KROGSTIE J and SIAU K, Eds), p 413–426, Porto, Portugal. ÅGERFALK PJ and WISTRAND K (2003) Systems Development Method Rationale: A Conceptual Framework for Analysis, In Proceedings of the 5th International Conference on Enterprise Information Systems (ICEIS 2003), Angers, France. BRINKKEMPER S, SAEKI M and HARMSEN F (1999) Meta-Modelling Based Assembly Techniques for Situational Method Engineering, Information Systems, 24(3) 209–228. CARROLL JM (1994) Making Use a Design Representation, Communications of the ACM, 37(12) 29–35. CATO J (2001) User-Centred Web Design, Addison Wesley, Harlow, England. FITZGERALD B, RUSSO NL and O'KANE T (2003) Software Development Method Tailoring at Motorola, Communications of the ACM, 46(4) 65–70. GOLDKUHL G and CRONHOLM S (2003) Multi-Grounded Theory: Adding Theoretical Grounding to Grounded Theory, In European Conference on Research Methods in Business and Management (ECRM 2003), Reading, UK. HARMSEN AF (1997) Situational Method Engineering, Doctoral Dissertation, Moret Ernst & Young Management Consultants, Utrecht, The Netherlands. HEVNER AR, MARCH ST, PARK J and RAM S (2004) Design Science in Information Systems Research, MIS Quarterly, 28(1) 75-105. KARLSSON F and WISTRAND K (2004) MC Sandbox: Tool Support for Method Configuration, In Proceedings of Ninth CAiSE/IFIP8.1/EUNO International Workshop on Evaluation of Modeling Methods in Systems Analysis and Design (EMMSAD’04), Riga, Latvia. KARLSSON F and ÅGERFALK PJ (2004) Method Configuration: Adapting to Situational Characteristics While Creating Reusable Assets, Information and Software Technology, 46(9) 619-633. MADSEN KH and AIKEN PH (1993) Experiences Using Cooperative Interactive Storyboard Prototyping, Communications of the ACM, 36(4). MAIDEN NAM, GIZIKIS A and ROBERTSON S (2004) Provoking Creativity: Imagine What Your Requirements Could Be Like, IEEE Software, 21(5). MALCOLM E (2001) Requirements Acquisition for Rapid Applications Development, Information & Management, 39101-107.

42



MARCH ST and SMITH GF (1995) Design and Natural Science Research on Information Technology, Decision Support Systems 15, pp. 251-266. MATHIASSEN L (2002) Collaborative Practice Research, Information Technology & People, 15(4) 321-345. MCKAY J and MARSHALL P (2001) The Dual Imperatives of Action Research, Information Technology & People, 14(1) 46–59. NAUMANN JD and JENKINS AM (1982) Prototyping: The New Paradigm for Systems Development, MIS Quarterly, 6(3) 29-44. NICKOLS FW (1993) Prototyping: Systems Development in Record Time, Journal of Systems Management, 44(9). NORMAN DA (1988) The Psychology of Everyday Things, Basic Books, New York. RALYTÉ J (1999) Reusing Scenario Based Approaches in Requirement Engineering Methods: Crews Method Base, In The First International Workshop on the Requirements Engineering Process, Florence, Italy. ROLLAND C, PLIHON V and RALYTÉ J (1998) Specifying the Reuse Context of Scenario Method Chunks, In Advanced Information Systems Engineering, 10th International Conference CAiSE'98, Pisa, Italy, June 8-12, (Eds, Pernici B and Thanos C). ROLLAND C, PRAKASH N and BENJAMEN A (1999) A Multi-Model View of Process Modelling, Requirements Engineering, 4(4) 169–187. ROSSI M, RAMESH B, LYYTINEN K and TOLVANEN J-P (2004) Managing Evolutionary Method Engineering by Method Rationale, Journal of the Association of Information Systems, 5(9) 356-391. STOLTERMAN E (1991) Designarbetets Dolda Rationalitet: En Studie Av Metodik Och Praktik Inom Systemutveckling, Doctoral Dissertation in Swedish, Department of Informatics, Umeå University, Umeå, Sweden. STOLTERMAN E and RUSSO NL (1997) The Paradox of Information Systems Methods -Public and Private Rationality, In The British Computer Society 5th Annual Conference on Methodologies, Lancaster, England. WALLS JG, WIDMEYER GR and EL SAWY OA (1992) Building Information System Design Theory for Vigilant Eis, Information Systems Research, 3(1).


43

A Framework for Matching Requirements Engineering Techniques to Project Characteristics and Situation Changes Toshihiko Tsumaki a and Tetsuo Tamai b a b

Nihon Unisys, Ltd. The University of Tokyo

Abstract One of the most difficult jobs for requirements engineers is to select an appropriate RE method for a project at hand. Good engineers make good choice and have skills in applying the selected technique appropriately. Poor engineers usually have a narrow choice range limited by their training and biased by their experience. Once a requirements engineering technique that does not fit the current project is selected, the project is doomed to fail. In this paper, we propose a framework to characterize typical requirements engineering techniques and use it as a base for selecting appropriate techniques at the time of starting a project as well as at the time of recognizing a change in the project nature or encountering an obstacle in defining a suitable set of requirements. Keywords: Requirements engineering techniques, Project characteristics, Situation change, Domain decomposition, Goal oriented, Scenario based, Brainstorming

1

Introduction

One of the major causes for the difficulty of requirements engineering tasks is the wide variety of target domains and project characteristics. As the result, a number of requirements engineering techniques have been created, advocated and practised in their efforts to cover the variety of scope. This brings about another problem of how to select an appropriate requirements engineering technique for a given project. Projects can be characterized by various factors such as target domains, system type and size, and organization cultures, each of which may be further decomposed into more concrete attributes. If a requirements engineering method that does not fit to the character of the project is chosen, the project is doomed to fail. However, most of requirements engineering literature, including papers, textbooks, tutorials and tool manuals are just eager to emphasize merits of some specific techniques without sufficiently mentioning their suitable target areas or their limitations. Admittedly, there are some work dealing with the problem of requirements method selection (Maiden, 1996; Hickey et al., 2003), but we think it is important to have a general framework that relates the requirements method space with the project characteristics space. Another issue in applying requirements engineering methods is how to cope with the project situation changes over time. During the requirements process and even after the requirements specification is completed, the project may go through a substantial change, due to changes in business environments, stakeholders and technologies. In some cases, although the project characteristics themselves have not changed, understanding of the project nature by the requirements engineers changes. We often experience cases when the requirements process runs into obstacles and find that the initial conception of the project properties was in-correct. In such situations, we have to adopt a new requirements engineering method to overcome the obstacles.

44


Tsumaki and Tamai

In this paper, we propose a framework to characterize typical requirements engineering techniques and use it as a base for selecting appropriate techniques at the time of starting a project as well as at the time of recognizing a change in the project nature or encountering an obstacle in defining a suitable set of requirements. The structure of the paper is as follows. In section 2, a classification framework for requirements engineering techniques is introduced. It is represented as a twodimensional space named RE technology map. In section 3, various project characteristics are studied in relation to the RE map and compatibility of techniques with project characteristics are discussed. The problem of situation change in the project is dealt with in section 4 and strategies for re-selecting RE methods according to the situation change are discussed. A case study of a conference management system for corporate in-house software engineering symposiums is explained in section 5. Related work is surveyed in section 6 and our work is concluded in section 7.

2

Classification of RE Techniques

Among a number of requirements engineering techniques, we pick up four typical and widely practised ones: the domain decomposition, goal oriented, scenario based and brainstorming approaches to study requirements engineering method properties. We mainly focus on the early requirements process, dealing with requirements elicitation techniques. Modelling techniques including object-oriented modelling, state based modelling, etc. and their notations are important and some requirements analysis methods are strongly tied with such modelling techniques but we intentionally draw a boundary and concern only with pure requirements elicitation methods. These four techniques are not only important but clearly differ from each other in nature. Let us briefly overview the four approaches. Domain decomposition: The target domain is decomposed into sub-domains in a step by step manner. It is easy to list up requirements without oversight if the subdomains to be handled are decomposed into sufficiently small, manageable size. The process can also be executed in the bottom-up way, composing finer grained sub-domains or requirements into larger ones. The study on such kind of domain analysis methods has a long history. A typical example is the work by Rieto-Diaz (1990), which can be traced back to the Draco project by Neighbors (1984). The approach can be generalized as categorization methods and we may include approaches of classifying other entities related to requirements besides problem domains, e.g. business processes and groups of stakeholders. Goal oriented: A number of goal-oriented approaches have been proposed (Mylopoulos et al., 1992; Dardenne et al., 1993; Anton, 1996; Lamsweerde, 1991). Among them, KAOS (Lamsweerde et al., 1998) is particularly a formal approach, whereas GBRAM (Anton, 1996) is particularly an informal approach. Scenario based: Scenario based approaches are also quite popular (Potts et al., 1994; Holbrook,1990). A use case is considered as an integrated set of scenarios. Thus, use case approaches (Jacobson et al., 1992; Dano etal., 1997) are basically in the same category but more oriented towards the later RE phase.


45

Matching RE Techniques to Project Characteristics

Brainstorming: Brainstorming is effective in eliciting requirements particularly in the area where system development experience is scant or a new kind of soft-ware is expected. The KJ method, for example, a sophisticated brainstorming method, was created by Jiro Kawakita more than 40 years ago and has been widely practised in industries not necessarily in the software industry (Kawakita, 1991). Application to software requirements engineering is reported by Takeda et al.(1993). To characterize the differences, we consider two dimensions, one concerning elicitation operation types and the other concerning target object types. We divide the operation type dimension into two categories: static and dynamic and also divide the object type dimension into closed and open types. Table 1 maps the four techniques on this two dimensional space. Table 1: Techniques and dimensional space. operation

static

dynamic

closed

domain decomposition

scenario

open

goal

brainstorming

object

The first dimension captures how the requirements elicitation and acquisition process is conducted, either focusing on static structures or dynamic behaviours. 1. Static Requirements are elicited from the domain examining its static structure. They are collected and sorted in a structured and systematic way. There are rules or guidance in decomposing/composing or classifying/clustering requirement related objects, including (sub) domains, goals and requirements themselves. 2. Dynamic Requirements are elicited from the domain focusing on their dynamic context. For many stakeholders, it is often easier to think in terms of procedural behaviours or situational changes over time. Requirements can be un-methodically enumerated or generated by stake-holders or by analysts. Thus, the way of eliciting requirements is also regarded as an “dynamic” activity, encouraging inspiration and imagination. The second dimension concerns with the properties of the target space to be analyzed, either relatively closed or open. 1. Closed The object space is relatively stable, known and closed. It can be grasped by focusing mainly on forms. 2. Open The object space is relatively unstable, unknown, changing and open. To explore the space, meanings have to be much considered.

46


Tsumaki and Tamai

Now, other various requirements engineering techniques can also be mapped on this plane. We call the plane RE technology map or RE map in short. Fig. 1 shows the RE map with typical techniques allocated. Some patterns are observed on the map, which are interesting to note.

Figure 1: RE Technology Map.

1.

In the area of the right hand side half plane, a sequence of scenario based techniques can be observed: from top to bottom, MSC (Message Sequence Chart), use case, scenario, story telling and role playing. They share the property of eliciting requirements along the course of dynamic event progress but different in formality. Techniques in the upper region are relatively suitable for investigating a closed space in form or syntax conscious manner, while in the lower region are techniques that are suitable for investigating an open space, thus tending to be more human oriented. Also related is the prototyping approach. Its major objective is to simulate dynamic interaction.


47


2.

Along the diagonal from the upper left to the lower right is observed a sequence of knowledge acquisition and classification type approaches: from upper-left to lower-right, domain decomposition, structured interview, card sorting, abduction, KJ method, brainstorming, and ethnography. The diagonal direction can be interpreted as the convergent (upper-left)/ divergent (lower-right) axis.

3.

Among the goal-oriented approaches, KAOS is for-mal and thus positioned upper, while more informal GBRAM is positioned lower. The i* framework (Yu, 1997) overlaps with the goal oriented approach but extends to the right direction. There are many proposals that unite the goal oriented approach and the scenario based approach (Rolland at al., 1998). They bridge the lower-left quadrant to the upper-right quadrant (, which is not shown in the RE map).

4.

As mentioned before, both the top-down and bottom-up approaches of decomposing/composing entities are included in the upper-left quadrant. The KJ method has a process of clustering cards produced by brain-storming and thus located closer to upper-left. The problem frame approach (Jackson, 2001) can be regarded as an-other way of decomposing the problem domain, al-though the decomposition is not structured in top-down hierarchy but in parallel juxtaposition.

5.

Various techniques of idea generation type can be included in the lower-right quadrant. For example, the abduction based approach such as (Russo et al., 2002) can be allocated here.

Some methods combine techniques classified in different quadrants. For example, multiple viewpoint approaches can be positioned in the structured-closed quadrant in that they elicit requirements based on the classification of various viewpoints but they are usually combined with scenarios, goals or other techniques to handle requirements from each viewpoint (Nuseibeh et al., 1994).

3

RE Techniques Compatibility to Project Characteristics

Requirements engineering techniques have been chosen and applied to projects at hand by requirements engineers according to their intuition or experience. Good engineers make good choice and have skills in applying the selected technique appropriately. Poor engineers usually have a narrow choice range limited by their training and biased by their experience. Once a requirements engineering technique that does not fit the current project is selected, the project will trace the road to failure. The properties of requirements engineering techniques introduced in the last section should be matched with project characteristics and used for guiding the method se-lection process. We capture characteristics of projects from five factors: application domain, requirements engineer types, information resources, user involvement and requirements proper-ties. We will map each factors on the RE technology map basically as one dimensional line that indicates the direction of method fitness. We will show it symbolically by a double-headed arrow in a square like Fig. 2. The topology of the square corresponds to the plane of Fig. 1.

48


Tsumaki and Tamai

3.1 Application Domain The direction shown in Fig. 2 corresponds to application domain stability. On one side is a type of applications that are relatively stable. Knowledge of the target domain and experience of developing similar systems are well accumulated, thus the domain can be perceived as a closed space and can be examined by a mechanical, syntactic means.

Figure 2: Domain Stability Factor.

On the other side is a type of relatively new, unknown or unstable applications. To explore requirements of such applications, analysis handling semantics at a certain deep level is required. The domain is perceived as an open space. In both cases, the static-dynamic dimension is relatively irrelevant. For example, to elicit requirements of an unfamiliar application domain, either the goal-oriented type approach or the brainstorming type approach will do and the choice should be made by considering other factors. 3.2 Requirements Engineers Type The direction of Fig. 3 corresponds to requirements engineers’ disposition. The left hand side engineers tend to like logical and systematic way of thinking. The right hand side engineers tend to prefer imaginative and intuitive way of thinking. Put in another way, the left side people are relatively theory oriented, while the right side people are relatively experiment oriented. To engineers of each group, techniques found in the corresponding half space of the RE map will fit better.

Figure 3: Engineers’ Disposition Factor.

3.3 Information Resource When available information is abundant in the form of documents or knowledge base or through investigating existing systems, the space to be explored can be confined and the closed side techniques may be suitable. Information can be arranged and put


49


in order through a mostly syntax based means. On the other hand, when available information is scarce or implicit, requirements have to be explored in an open space, using the open side techniques.

Figure 3: Information Resource Amount Factor.

3.4 User Involvement The user involvement factor is related to the information resource factor. If information is available as formal knowledge, user involvement is not necessarily required to collect requirements, although it is still desirable to have users’ collaboration. But in order to proceed with methods like goal searching or brainstorming, users’ participation is indispensable.

Figure 4: User Involvement Factor.

3.5 Requirements Quality Quality of requirements is assessed by a number of criteria. The IEEE standard 8301998 lists up correctness, un-ambiguity, completeness, consistency, ranking, verifiability, modifiability and traceability. All these properties are important but the priority between them may vary according to the project nature. Techniques in the static-closed quadrant are suitable for covering the domain in a methodical way, so that completeness in the sense of complete coverage of the target area is attainable. Techniques in the dynamic-closed quadrant, typically the scenario based approach, are suitable for attaining behavioural consistency. Specifically, inconsistency in the order of work flow and data flow can be detected relatively easily. Also, as the requirements are captured in the dynamic context, they can be matched to the behaviour of the implemented system, so that traceability is in general easily attainable. Techniques in the static-open quadrant, typically the goal-oriented approach, are good at detecting conflicts between goals. Together with some conflict resolving method, it can be expected to obtain a logically consistent set of requirements with this type of techniques. Also, they are effective in comparing different goals to set ranking among the requirements. Techniques in the dynamic-open quadrant are good

50


Tsumaki and Tamai

at producing a wide variety of requirements from different angles, which may include prospected future requirements, so that they will help foresee requirements adaptation.

Figure 4: Quality Type.

3.6 Non-Functional Requirements Some of non-functional requirements (NFR) are more easily elicited by specific techniques. A branch of the goal-oriented approach is well-known for covering NFR employing the concept of soft goals (Mylopoulos et al., 1992). Security concerns can be handled effectively by using the scenario based approach, because it is essential for defending system attacks to explore all possible scenarios attackers may take in invading the system. Listing up possible scenarios is also effective in avoiding other kind of risks that may possibly be materialized. Ease of use may be particularly well covered by the prototyping method, giving users opportunities to experience interactions and touch and feel the interface.

4

Coping with Situation Change

A project starts with an appropriate requirements engineering method selected based on analysis explained in the previous section. However, a project goes through transition whenever a new issue is raised and solved (Tsumaki, 2004). A project may encounter obstacles during the requirements analysis phase or the requirements specification may be found inadequate in the later phases. Based on our experience and consulting literature like (Christel et al., 1992), we made a list of problems that may arise in the requirements elicitation activity as shown in Table 2. These are, in a way, negation of requirements quality treated in section 3.5 but here we are interested in the events when such problems are detected. When they are detected, some measures should be taken and changing RE techniques is one of the most effective strategies to consider. We have shown affinity between requirements qualities and groups of elicitation techniques but when requirements problems as listed in Table 1 get exposed, the strategy to take is not necessarily simple application of corresponding techniques in affinity. Below are some cases worth noting. Table 2: Requirements Elicitation Problems. Incomplete requirements incomplete understanding of needs


51


incomplete domain knowledge poor users’ collaboration overlooking tacit assumptions Incorrect requirements ill-defined system boundary misunderstanding of system purpose Ambiguous requirements synonymous and homonymous terms un-testable terms Inconsistent requirements un-solid intentions of requesters different views of different users Unfixed requirements fluctuating requirements continuous acceptance of additional requirements Excessive requirements unorganized bulky information source too many requesters over commitment by sales persons unnecessary design consideration

Completeness: Techniques in the upper left quadrant are effective in detecting incompleteness but not necessarily good in filling in insufficient requirements. To acquire missing requirements, techniques in the lower half of RE map, e.g. the goal-oriented approach and the brainstorming, had better be employed. After collecting new requirements through such methods, it would be desirable to go back to the upper left quadrant to sort and place them under a classification scheme to check completeness. Conflict: When conflicts between requirements are detected, straightforward application of the scenario based approach in case of behavioural conflict and the goaloriented approach in case of logical conflict may be effective. Excessive requirements: Some techniques in the upper left quadrant are used for top-down decomposition while some are used for bottom up clustering. When the problem is requirements excess in amount, such clustering type techniques will be effective. When the problem is how to give priority among them, the goal oriented

52


Tsumaki and Tamai

approach coupled with an evaluation mechanism like AHP (Analytical Hierarchical Process) may be effective. Ambiguity: Ambiguity arising from the way of expressing requirements is basically orthogonal to requirements eliciting techniques but dependent on modelling and representation languages. However, if the problem is lack of concreteness, moving towards the upper direction of the RE map may help. For example, proceeding the goal-oriented approach to obtain operational goals or formalizing scenarios as message sequence charts.

5

Case Study

As a case study, we take a project of developing a conference supporting system. The system is for a series of in-house software engineering symposiums having been held in the first author’s company. At the time of the project, our framework for classifying RE techniques and guiding method selection was not completed and explicitly documented. The project was basically conducted based on the requirements analyst’s experience and skill but our observation and consultation on the project helped us grow and refine the idea described in this paper. 5.1

Overview of the project

The symposium has been held each year, calling for paper submissions from members of the company. It is organized by the secretariat section; actually one person in the section has been in charge of the symposium for the past ten years. As the retirement age of the secretary was approaching, there was an urgent need to preserve his knowledge. Another objective of the system development was to make the symposium management task more efficient. The decision to start the project was made but it was found that the secretary was too busy at the time to participate in the project. Instead, a pile of unsorted documents of the past ten years, including minutes of meetings, exchanged messages, submitted papers and unofficial memos of the secretary, were passed to the requirements analyst. 5.2 Project Characteristics The basic characteristics of this project can be summarized as follows.

•

The target domain is relatively limited and small.

•

On the other hand, the development organization did not have experience of developing similar systems, so that the domain was rather new to them.

•

Stakeholders’ involvement was weak.

•

Available information source was large but knowledge was unorganized.

5.3 RE Process The requirements analysis process was actually taken in four steps.


53


Step 1 – arranging information to capture the domain: The first step was to understand the process of organizing symposiums and tasks to be taken by the secretary. As the secretary’s commitment was not obtained, the only source was the unorganized materials. The classifying technique in the static-closed quadrant fitted well for this purpose. The fact that the domain was relatively small and closed also enhanced its compatibility. As for a criterion for arranging the information, division by action processes was selected, because the work for organizing symposiums naturally flows from planning, calling for papers, paper selection, holding the symposium and to publishing the proceedings. This judgment was corroborated by the fact found by the analyst who examined the materials that an author who has submitted a paper goes through the stages of the general employee, the paper contributor, the accepted contributor, and the speaker. Each process was further divided into sub-processes, e.g. the planning process was divided into setting up the organizing committee, setting up the program committee and assigning reviewers, holding the organizing and program committee meetings and setting schedule. All the documents were arranged based on this process division structure and redundant or unimportant information were discarded. Step 2 – understanding the tasks of organizing symposiums: The documents had been sorted, which helped understanding the structure of the process but the dynamic features of each concrete task were not well grasped yet. To clarify the tasks, the scenario writing method in the dynamic-closed quadrant fitted well. The analyst himself had to write scenarios based on the sorted documents supplemented by some interviews to people who had participated in the past symposiums as committee members. An example of the scenario is:

•

Call for papers 1. Set a theme for the special session. 2. Write a call-for-paper announcement. 3. Send the call-for-paper to the PC members to solicit comments and update the call-for-paper if necessary. 4. Send the call-for-paper to the organizing committee to get approval. 5. Order printing of the call-for-papers. 6. Distribute the call-for-papers with submission forms to all members of the company.

The written scenarios were sent to the secretary to verify its correctness. Some missing information was returned from him. Step 3 – identifying requirements: The preceding steps were for the analyst to understand the target domain and process. Requirements for the system to be built had to be explicitly identified. For this purpose, the classification technique again in the static-closed quadrant was employed. This time, two-dimensional criteria were used to decompose the requirements space; one criterion was the requirement types: functional, performance and quality, the other was the requirement sources: business,

54


Tsumaki and Tamai

operational users, and system. At this stage, the secretary became able to spare some time for the project, so weekly meetings of the analyst with the secretary were held to proceed this step. A highly simplified version of the results is shown in Table 3. Table 3: Requirements Arranged in the Matrix. functional

performance

quality

business

plan schedule, call for papers, select reviewers, review, accept papers, notify authors

data volume: 300 papers

protect authors’ data, protect reviewers’ data, protect from illegal access

operational users

operation by intra-net, use of templates

operation latency: 30 seconds

easy operation, guide & help

system

alternate pass for intra-net

MTBF: 1 day

paper file 1 day

Step 4 – refining requirements: Requirements had been acquired but it was found that the level was not concrete enough. To refine the requirements, the goaldecomposition technique was employed to decompose goals down to the operational level. Some new requirements were discovered through the work, which were allocated in the requirements matrix made in Step 3. Also, the goals were extended to the upper direction through asking “why” questions so that the result was delivered to the management to confirm the project approval. 5.4 Discussion As the target domain of the system is limited and small in size, the requirements elicitation techniques used in this case study project are mostly located in the upper half plane of the RE map. This fact is consistent with the observation presented in section 3.1. While the domain was small and relatively closed, the application type was rather new to the software engineers of the project, which made them perceive the “openness” of the domain. That must have been one of the reasons why the goal-oriented approach was used in the final step. However, the reason for using the goal decomposition was mainly to refine the requirements to the operational level as explained above so that the nature of the goal-oriented technique actually applied was more bent towards the formal or closed direction. Another objective of its use was to show the project justification to the management. For its project size, the requirements analysis process in this case took an elaborate way of going through four steps. The four step process was not planned before starting the project but was the result of ongoing decision making. It gives one example of real requirements elicitation processes transiting through situational changes as discussed in section 4.


55


6

Related Work

There are not so many studies that share similar objectives as ours. Among them, Hickey & Davis (2003) and Maiden & Rugg (1994) are closely related. Hickey & Davis made interviews to nine renowned experts, asking how they perform requirements elicitation. The style of the interviews were open-ended and “differed significantly from interview to interview”, except that four cases of situations intentionally described relatively vaguely in brief sentences were presented to the interviewees to give answers how they would tackle the problem. The results were summarized to: 1) when to use techniques, 2) normalized responses to the four cases and 3) some other information. The survey is interesting and provides useful information. Relations between requirements techniques and project situations are discussed sporadically in an anecdotal style. Maiden & Rugg’s work is more systematic. 12 requirements acquisition methods are selected and they are compared by six facets: purpose of requirements, knowledge types, internal filtering of knowledge, observable phenomena, acquisition context and method interdependencies. The results are given as five tables corresponding to the five facets (excluding interdependencies), each entry to the tables is a check or a symbolized weight. The proposed framework consists of these tables to be used in selecting requirements elicitation methods. They may be useful as checklists for selection but no example of using the framework is reported. Some papers treat similar topics but their objectives or approaches are considerably different from ours. Yadav et al. (1988) proposes a comparison framework for requirements analysis techniques but what they compared were DFD and IDEF0, which are supposed to be used in the later stage of requirements analysis. Hudlicka (1996) compares requirements elicitation techniques from the knowledge engineering and cognitive science viewpoint. Three knowledge elicitation techniques are selected and compared: repertory grid analysis, multidimensional scaling and hierarchical clustering. These techniques are not directly related to requirements elicitation but as they deal with information creation and classification techniques, they can be allocated along the lower-right to upper-left diagonal in our RE map. An experiment of comparing the three techniques in the context of airline safety inspection has been conducted, which is informative, but how they can be employed in acquiring system requirements is not explicitly discussed. Coughlan & Macredie (2002) emphasize communication in the requirements elicitation process. As a result, they compare user participation type methodologies: MUST, JAD (Joint Application Design), ULRC (User-Led Requirements Construction) and SSM (Soft Systems Methodology). The difference of their approach from ours lies not only in the selection of method type but also in their focus on “methodologies” rather than techniques. Techniques at the level of brainstorming, scenarios, etc. are adopted in each methodology, some shared and others not shared. Bergman & Mark (2003) deals with requirements at a yet higher level so that the requirement determines project selection as opposed to the usual case where a project determines requirements. The NASA program is analyzed, where a number of projects are proposed and the problem is to find an appropriate set of projects that satisfy the NASA higher level requirements. Certainly, such higher level requirements have to be analyzed and determined, which is an interesting part of the paper but the objective is different from our case.

56


Tsumaki and Tamai

Padula (2004) reports a real case of selecting requirements engineering processes at Hewlett-Packard. Two projects are compared in terms of RE process, not from the viewpoint of elicitation techniques.

7

Conclusion

We proposed a framework for selecting requirements engineering techniques, considering different factors of the project at hand. A broad view of various techniques is obtained as the RE map and selection factors can be projected on the map. In order to use the framework for selecting techniques systematically, our results may better be summarized as checklists or a set of rules. It is a rather straightforward task to make such checklists or rules but we have not yet done that, because we consider it would be better to take some time in accumulating experience of applying the framework to many real projects.

Acknowledgement This work has been conducted as an activity of the requirements engineering study group Mahoroba. The authors would like to thank to all members of Mahoroba.

References ANTON AI (1996) Goal-based requirements analysis. In Proc. International Conference on Requirements Engineering (ICRE’96), 136–144. BERGMAN M and MARK G (2003) In situ requirements analysis: a deeper examination of the relationship between requirements determination and project selection. In Proc. 11th International Requirements Engineering Conference (RE’03), 11–22. CHRISTEL MG and KANG KC (1992) Issues in requirements elicitation. Technical Report CMU/SEI-92-TR-12. COUGHLAN J and MACREDIE RD (2002) Effective communication in requirements elicitation: a comparison of methodologies. Requirements Engineering Journal, 7:47–60. DANO B, BRIAND H and BARBIER F (1997) An approach based on the concept of use case to produce dynamic object-oriented specifications. In Proc. 3rd International Symposium on Requirements Engineering (RE’97), 54–64. DARDENNE A, LAMSWEERDE AV and FICKAS S (1993) Goal directed requirements acquisition. Science of Computer Programming, 20(1-2):3–50. HICKEY AM and DAVIS AM (2003) Elicitation technique selection: How do experts do it? In Proc. 11th International Requirements Engineering Conference (RE’03), 169– 178. HOLBROOK CH (1990) A scenario-based methodology for conducting requirements elicitation. ACM SIGSOFT Software Engineering Notes, 15(1):95–104. HUDLICKA E (1996) Requirements elicitation with indirect knowledge elicitation technique: Comparison of three methods. In Proc. International Conference on Requirements Engineering (ICRE’96), 4–11. JACKSON M (2001) Problem Frames: Analyzing and structuring software development problems. Addison-Wesley. JACOBSON I, CHRISTERSON M, JONSSON P and OVERGAARD G (1992) ObjectOriented Software Engineering: A Use Case Driven Approach. ACM press.


57


KAKITA J (1996) The Original KJ Method. Kawakita Research Institute. MAIDEN N and RUGG G (1996) ACRE: Selecting methods for requirements acquisition. Software Engineering Journal, 183–192. MYLOPULOS J, CHUNG L and NIXON B (1992) Representing and using nonfunctional requirements: A process-oriented approach. IEEE Transactions on Software Engineering, 18(6). NEIGHBORS J (1984) The draco approach to constructing software from reusable components. IEEE Transactions on Software Engineering, SE-10:564–573. NUSEIBEH B, KRAMER J and FINKELSTEIN A (1994) A framework for expressing the relationships between multiple views in requirements specifications. IEEE Transactions on Software Engineering, 20(10):760–773. PADULA A (2004) Requirements engineering process selection at Hewlett-Packard. In Proc. 12th International Requirements Engineering Conference (RE’04), 296–300. POTTS C, TAKAHASHI K and ANTON AI (1994) Inquiry-based requirements analysis, IEEE Software, 11(2):21–32. ROLLAND C, SOUVEYET C and ACHOUR CB (1998) Guiding goal modeling using scenarios. IEEE Transaction on Software Engineering, 24(12). RRIETO-DI´AZ R (1990) Domain analysis: An introduction. ACM SIGSOFT Software Engineering Notes, 15(2):47–54. RUSSO A, MILLER R, NUSEBEH B and KRAMER J (2002) An abductive approach for analysing event-based requirements specifications. In Proc. 18th International Conference on Logic Programming (ILPC-2002). TAKEDA N, SHIOMI A, KAWAI K and OHIWA H (1993) Requirements analysis by KJ editor. In Proc. IEEE International Symposium on Requirements Engineering, 98–101. TSUMAKI T (2004) Requirements engineering pattern structure. In Proc. Asia-Pacific Software Engineering Conference, 2004, pages 502–509. LAMSWEERDE AV (2001) Goal-oriented requirements engineering: A guided tour. In Proc. 5th IEEE International Symposium on Requirements Engineering (RE’01), 249– 263. LAMSWEERDE AV, DARIMONT R and LETIER E (1998) Managing conflicts in goaldriven requirements engineering. IEEE Transactions on Software Engineering, Special Issue on Managing Inconsistency in Software Development, 24(11):908–926. YADAV SB, BRAVOCO RR, CHATFIELD AT and RA-JIKUMAR TM (1988) Comparison of analysis techniques for information requirement determination. ACM, 31(9):1090–1097. YU E (1997) Towards modelling and reasoning support for earlyphase requirements engineering. In Proc. 3rd International Symposium on Requirements Engineering (RE’97), 226–235.

58


Using the OPEN Process Framework to Produce a SituationSpecific Requirements Engineering Method Didar Zowghia , Donald G. Firesmithb and Brian Henderson-Sellersa a

University of Technology, Sydney, P O Box 123, Broadway, NSW 2007, Australia, {didar, brian}@it.uts.edu.au b SEI, Carnegie Mellon University, Pittsburgh, PA, USA, [email protected]

Abstract Since it is not possible to identify or to create a single method that is appropriate for all situations, the need for a focused requirements engineering method (REM) necessitates the search for a mechanism that will support the flexible creation of a number of tailored REMs from a single base. Using a repository of reusable method components, it is possible to use the techniques espoused by the method engineering community to construct an appropriate REM that is well-suited to the particular system or application development endeavour under consideration. One particular example is used to illustrate this approach – that of the OPEN Process Framework. Keywords: Method engineering; requirements engineering; process construction; OPEN

1

Introduction

“A process model is an abstract definition of an actual or proposed process” (Curtis et al., 1992). A process model, also called a method here, provides the “textbook description” of all the elements that should be enacted on a real project. That enacted process model is called the process and is the focus of, for instance, software process improvement (SPI). In this paper, we focus on a process model/method for requirements engineering. Expanding on the above definition, we can say that a Requirements Engineering Method (REM) is a structured and coherent set of tasks, procedures, work products, policies, organisational structures and technologies needed to identify, analyse, specify, validate and manage a high quality set of requirements. In practice, Requirements Engineering (RE) is an iterative process, whereby requirements emerge and evolve in an iterative incremental rather than a sequential manner (Firesmith, 2002a). A complete REM description should include statements about what tasks are carried out, the structuring or scheduling of these tasks, who is responsible for each task, the inputs and outputs to/from the tasks and the tools used to support the method when it is enacted as a process for a particular project (Sommerville and Sawyer, 1997). In the RE literature, different definitions have been given for this method and its tasks. In some cases, an REM is defined at a very fine level of detail and the steps in the method must be carried out (enacted) exactly as described. However, this form of process model description usually applies to very simple processes; for more complex processes, the description is usually less detailed and it is up to the person or project team who are executing or “enacting” the process to carry it out in their own environment. Furthermore, an REM includes tasks involving individuals as well as groups and, as such, is inherently susceptible to problems arising from human-related issues.


59

Using the OPEN Process Framework to Produce a Situation-Specific RE Method

It is thus difficult to write down a generic sequential plan of tasks that adequately describes the endeavour-specific REM. An REM typically begins with elicitation followed by modelling and analysis. The results are then formalised as different kinds of requirements, which are documented into one or more requirements specifications. This is followed by verification against characteristics of good requirements (e.g., completeness, correctness, lack of ambiguity, and feasibility) as well as by validation against stakeholder needs and desires. Management of requirements is considered as a continuous activity throughout the development lifecycle, within which the integrity and consistency of the requirements model are maintained. An REM thus exploits a number of fundamental elements:

•

RE tasks and techniques – Various techniques and procedures exist within RE research and practice for each of the tasks in the RE method (Davis, 1993).

•

RE tools – In order to perform RE tasks effectively, a number of commercially available tools have been developed (e.g. DOORS, RequisitePro, CaliberRM, and CORE).

•

Organisation and people – RE is carried out by teams of people playing various roles that have to be coordinated and managed within an effective organisational structure (Jirotka and Goguen, 1994; Macaulay, 1996).

•

Programmatic factors – Different tasks of an RE method must be shaped in such a way as to properly take into account the size of software, its complexity and the context where software is supposed to be used (Boehm and Papaccio, 1988).

Viewing the development of requirements work products (e.g., system and software requirements specifications) from a process viewpoint helps to identify the different dimensions of RE and the problems that need to be addressed in order to establish effective RE practices. Indeed, addressing the issues and challenges of REM is not a matter of introducing a new tool and environment or merely selecting or devising a RE process model. Instead, attention should be paid to the complex interplay between a number of organisational, cultural, technological and economical factors impacting the RE process. Very few organisations have an explicitly defined and standardized RE methods and mostly define the product of the process, typically a software requirements specification SRS (Kotonya and Sommerville, 1997). Clearly, organisations will benefit from understanding their RE processes and defining an REM that is appropriate to their organisational needs and specific software projects in which they are engaged. Indeed, it is generally acknowledged (Cockburn, 2000; Hruby, 2000) that, at least at the full lifecycle granularity, it is not possible to identify or construct a single method that results in a process that is appropriate for all situations. Consequently, the approach of method engineering (Kumar and Welke, 1992; Brinkkemper, 1996; Brinkkemper et al., 1998; Henderson-Sellers, 2003; Ralyté and Rolland, 2001), as we shall demonstrate, offers valuable insights and tools by which to create a tailored requirements engineering method that is highly suitable for the specific, identified endeavour (e.g., project or programme of related projects). Here, we encapsulate the ideas of method engineering (ME) within an object-oriented framework, the OPF (OPEN

60


Zowghi, Firesmith and Henderson-Sellers

Process Framework) (Firesmith and Henderson-Sellers, 2002). The OPF is a standardized approach, originally devised for full system lifecycle methodology creation (Graham et al., 1997), but here evaluated in terms of its capability of offering adequate support for the creation of a requirements engineering method. This set of guidelines presented here offers ME ideas on how to use/tailor a method framework to produce a more generic RE method. These guidelines could equally be applied to any method framework, any organisation and any project in a repeatable manner.

2

The OPEN Process Framework (OPF)

2.1 Introduction The OPEN Process Framework (OPF) consists of three major parts (Figure 1):

OPF

Metamodel Repository of method components Construction & usage guidelines

Figure 1. The main elements of the OPF.

•

A metamodel defining the fundamental kinds of reusable method components and how they are related to each other.

•

A repository of reusable method components (actual descriptions of each kind of reusable method component) [cf. method chunk (e.g. Rolland and Prakash, 1996) and method fragment (e.g. Harmsen et al., 1994)].

•

Construction and usage guidelines on how to reuse the method components in the repository to produce situation-specific processes. These are described in the next three sub-sections.

2.2 The OPF Metamodel The OPF metamodel provides a standard terminology and semantics for the elements in the repository of free open source reusable method components. Based on the elements in the metamodel (Figure 2), the method components fall into a small number of major groupings:


61


Figure 2. The major meta-elements of the OPF. All method components are generated as instances of one of these meta-elements and documented in the repository.

•

Work Products model anything of value (e.g., documents, diagrams, applications, classes) produced by the collaboration of one or more producers during the performance of one or more work units.

•

Work Units model functionally cohesive operations that are performed by producers during the delivery process. OPF recognizes the following three kinds of work units:

62

•

Activities are the highest-level of work units consisting of cohesive collections of one or more tasks that are performed by one or more collaborating producers when either producing a set of one or more related work products or when providing one or more related services. For example, requirements engineering is an OPF activity.

•

Tasks are mid-level work units that model a functionally cohesive operation that is performed by one or more producers. For example, requirements elicitation, requirements analysis, requirements specification, requirements validation, and requirements management are OPF’s primary requirements engineering tasks.

•

Techniques are low-level work units that model the way that one or more tasks are performed. For example, use case modelling would be a technique for engineering functional requirements and hazard analysis would be a technique for engineering safety requirements.



•

Producers model anything that produces, either directly or indirectly, versions of one or more work products. OPF recognizes the following kinds of producers: organizations, teams, roles, tools and persons. For example, requirements team and requirements engineer are two OPF producers.

•

Languages model the languages used to document work products. For example, UML could be used to document use case models and Object-Z could be used to formally specify requirements.

•

Endeavours model large-scale ventures undertaken by collaborating producers during multiple stages to develop and/or maintain one or more related applications. The OPF metamodel defines the following subclasses of endeavours in the OPF repository: projects, programmes of related projects and enterprises. In the REM, this gives a contextual setting only.

•

Stages model formally identified time periods or points in time that provide organization to the work units of the delivery process. Typical kinds of stage are cycles, phases, builds and milestones. For example, you could define a milestone marking when the requirements for a development iteration will be complete, under configuration control and frozen.

•

Work Performances model work units as performed by producers.

2.3 OPF Repository of Method Components The OPF contains a repository of free, open source reusable method components. These are used by following the tenets of Method Engineering (Kumar and Welke, 1992). In this approach, a “personalized” method is created for a specific organization, a specific division or a specific project by bottom-up construction from a number of these method components (Brinkkemper et al., 1998), here identified by the OPF metamodel and using the construction and usage guidelines (Section 2.4) in order to aid the actual construction of the REM. In Section 2.2, only the types of the method components are listed. For use on an actual project, each of these types and subtypes is used to generate (by instantiation) a wide range of actual work products, techniques, activities, roles etc. Those relevant to the construction of an REM are summarized below. The only relevant OPF Activity is, naturally, that of Requirements Engineering, although there are subclasses such as RE for developing a system, RE for developing a software application and RE for developing the reusable requirements for a specific application domain. RE typically involves teams and roles performing requirements tasks in an iterative, incremental, parallel and time-boxed manner. From the OPF repository, method components can be identified for each of these(for further details see Firesmith, 2002b). Useful RE Tasks include

•

Stakeholder profiling, during which the representatives of all major stakeholders of customer organization’s current business enterprise of the are studied, modelled and analyzed.

•

Customer analysis, during which the current business enterprise of the customer organization is studied, modelled and analyzed.


63


•

Competitor analysis, during which competing businesses of the current business enterprise of the customer organization are identified, profiled, studied, and analyzed.

•

Market analysis, during which the current or planned marketplaces in which the business enterprise of the customer organization are identified, studied, modelled, and analyzed.

•

User analysis, during which the current and future intended user organizations of the application(s) of the customer organization’s business enterprise are identified, studied, modelled, and analyzed.

•

Business visioning, during which the customer organization’s vision of their [re]engineered business enterprise is produced and documented.

•

Application visioning, during which the customer organization’s vision of a new or updated application is produced and documented.

•

Requirements elicitation, during which raw new potential requirements for the business enterprise are identified and captured.

•

Requirements analysis, during which elicited and reused requirements for the business enterprise are studied, modelled, refined, prioritized, scheduled, and traced.

•

Requirements specification, during which requirements, requirement diagrams, and requirements models for the business enterprise are documented in requirements specifications and related documents.

•

Requirements reuse, during which reusable requirements and requirementsrelated analyses are identified, evaluated for relevancy, and where appropriate reused (possibly with modification).

•

Requirements management, during which the storage, access, approval, publication, and tracing of requirements work products are managed.

•

Technology analysis, during which the potential technologies for future applications are identified, analyzed, and documented

•

Requirements prototyping, during which one or more prototypes are produced in order to identify and iterate requirements

To facilitate these Tasks, there are many possible documented Techniques; for instance Abstraction, Brainstorming, Documentation standards, Documentation templates, Gap analysis, Inspection checklists, Interviews, Joint application development (JAD), Prototyping, Questionnaires, Reference requirements, Requirements patterns, and Storyboarding. Typical Work Products for the REM include:

•

64

Software Requirements Specification (SRS) – documents a cohesive set of requirements, possibly including their associated models, diagrams, and ancillary information



•

Use case diagram – depicts functionality expressed in terms of use cases

•

Class diagram – depicts definitions of objects (classes)/concepts and their inter-relationships

•

State transition diagram – depicts for a single entity or class the various states it can be in and how changes of state can be triggered

Whereas programmers are primarily concerned with various kinds of implementation languages, requirements engineers and their technical writers use the following kinds of languages to implement requirements work products:

•

Natural languages - such as English, although often ambiguous, are most often used to specify textual requirements.

•

Modelling languages - such as the Unified Modeling Language (UML) and the Object Modelling Language (OML), can be used to produce requirements diagrams and associated graphical models.

•

Specification languages - such as Z and Object-Z, are sometimes used to specify requirements more formally and so that they can be verified using tools such as theorem provers or model checkers.

There are many relevant producers defined in the OPF repository of method fragments. These include: Business architect, Business strategist, Customer representative, Digital brand strategist, Domain expert Process engineer, Project manager, Requirements engineer, Security analyst, Software architect, System architect, Technical leader, Technical writer, Technology strategist, Test engineer, User analyst, and User representative. Some teams for these producers are Business strategy team, Technology strategy team, Requirements team, Strategy inspection team, Requirements inspection team, Architecture team, Management team, and Quality team. 2.4 Construction and Usage Guidelines There are several kinds of guidelines needed to engineer a project-specific method. These include, inter alia, method construction guidelines, tailoring guidelines and, less relevant here, extension guidelines – which assist the method engineer in modifying the metamodel itself. (Tailoring guidelines, which support minor modifications to the method once constructed also have less immediate impact on the topic of this paper.). Other important elements (not discussed further here) include sequencing rules, which can be expressed using pre- and post-conditions on (particularly) Tasks (Goldberg and Rubin, 1995) and/or by ensuring the process and product perspectives are adequately connected (Brinkkemper et al., 1998). A construction guideline helps method engineers both to instantiate (when necessary) the development process framework (metamodel) to create method components and also to select the best method components (from the Repository) in order to create the method itself (van Slooten and Hodes, 1996). Specifically, guidance is provided on the selection of appropriate work products, producers and work units as well as advising on how to allocate tasks and associated techniques to producers and how to group the tasks into workflows, activities etc. Finally, developmental stages (including phases and lifecycles) are chosen.


65


A commonly used, pragmatic approach to method construction is the following. Pick the work products you are willing to spend money on to create. Select the appropriate tasks and techniques to produce them. Choose the appropriate producers to perform them, using tools where appropriate. Pick milestones and inch pebbles to schedule them and add to appropriate phases. Check for consistency. Document the method. Verify the method with stakeholders for acceptability and feasibility. Train teams in the method. Use the method. Iterate as appropriate. However, this needs experience. As an aid to helping the development team pick the best set of method components, the OPF suggests the use of a matrix to describe this multi-faceted connexion between any pair of kinds of method component e.g. Team and Task; Team and Role). Each matrix specifies the possibility values for each pair (e.g. each method component derived from the Team and Task metaclasses) either on a five-point scale (Graham et al., 1997) or, as here, as a binary value (Y/N).

3

Method Engineering Process

From a practical point of view, industrializing the above process of component selection involves an identification of the people involved. It is important that both management and development team representatives (the whole team if possible) be involved in creating the REM. Clearly, those involved need to have adequate skills that they can utilize in the selection of method components and their integration together. As well as project managers and requirements engineers, it may be beneficial to have an (internal or external) method engineer on the method engineering team. Ralyté and Rolland (2001) introduce a “Method Engineering Process Model (MEPM)” to construct the overall process with a complementary assembly process model (APM) for guiding the selection of appropriate method components; while Brinkkemper et al. (2001) propose the use of a “method engineering language” that will assist in formalizing descriptions and usage of the various method components. Henderson-Sellers and Serour (2000) propose a Trans-IT process which identifies method components specifically relevant to the introduction and inculcation of a software development process into an organization. Some of the more important elements of the method engineering process are discussed in the following subsections. 3.1 Determine Method Needs The first step in producing an organization-specific requirements engineering method is for the members of the organizational method team to determine the goals and needs for their organizational method, of which requirements engineering is a critical part. These include robustness, repeatability, feasibility with respect to the organisational culture, measurable outcome, easy to learn, easy to follow, flexible. It is critical to understand the existing culture and the alternatives that may be perceived by both management and staff (Serour and Henderson-Sellers, 2004). This study produces a documented statement of the specific needs of the organization and/or project team. 3.2 Learn OPEN Basics The second step in producing an REM is for the members of the organizational method team to familiarize themselves with the OPEN Process Framework (OPF) in general and with the generic default OPF requirements engineering process framework (i.e., the subset of the OPF related to requirements engineering) in particular.

66



This step is optional and only applicable when the team is not familiar with the OPF. They can begin by skimming the most recent OPEN books, skimming the overview webpages of the official OPEN website (http://www.open.org.au), and looking at the relevant webpages of the selected OPF tool. In this case, the OPEN Process Framework website (http://www.donald-firesmith.com), which provides over 1,000 open source reusable OPF compliant method components. While doing this, the members of the method team should learn the concepts, terminology, and relationships between these concepts that are captured by the OPEN metamodel (e.g., what are the basic kinds of method components and how they relate to each other). They should also learn about the relevant reusable OPF method components (e.g., requirements engineering tasks, techniques, work products, roles). They should also familiarize themselves with the relevant OPEN method engineering tasks that they will be performing when producing their organizational-specific method-engineering framework for requirements engineering. 3.3 Select Method Components The OPF contains numerous method components, not all are relevant to requirements engineering. Even the default requirements engineering subset of the OPF probably contains other related reusable method components that may not all be required for a typical organization, especially if that organization is limiting the type of endeavours it has in mind. The following steps should be followed for selecting the method components: Step 1. Make a copy of the OPF generic default requirements engineering process framework as the initial draft version of the organizational RE process framework. Step 2. Use the output of the preceding Determine Process Needs task to decide which (if any) of the default method components in the organizational RE method component repository are either irrelevant or inappropriate to the needs of organization. Step 3. Go through the list of currently available reusable method components, type-by-type, and component-by-component, and delete any method components that do not belong. The construction and usage guidelines (Section 2.4) may be helpful here. Step 4. Just to be completely safe, also check the complete OPF to ensure that no useful cost effective method components were inadvertently left out when the OPF generic default RE process framework was created. This could be done using, for example, contingency factors (after ter Hofstede and Verhoef, 1997). Note that this is currently a manual task, the success of which will depend on the experience, skills, thoroughness and the care of the method engineers that perform it. However, many aspects of this process could be supported by automated tools. 3.4 Extend the Process Framework Repository The OPF repository is relatively large and complete, because it is based on the premise that it is easier to delete what you do not need from the repository than to add what you do need, especially if you are under typical project time and resource constraints. Nevertheless, it remains possible that the draft organizational RE method created thus far using only reusable method components from the OPF is incomplete. Now is the time to add any special method components that your organization might


67


need in its organizational RE method. If these method components are not proprietary, you may also consider sharing them with the OPEN Consortium so that OPF can be updated with them and there will be fewer problems maintaining the organizational RE process framework if the OPF can be kept consistent with it. 3.5 Tailor the Method Components Although the organizational REM now contains all of the appropriate method components, this does not mean that these method components are ready to be used immediately. They may need to be tailored in several ways. For example, the method component itself may be too large and complex for the needs of the organization. Excessive elements of these components may need to be removed. For example, the table of contents of documentation work products may contain sections that are inappropriate and should be removed. Similarly, the requirements team may contain too many roles, have too many objectives, or perform too many tasks. 3.6 Document the Method Since the constructed method is to become the organization-specific or projectspecific requirements method to be followed during RE, it is important that it is adequately documented and made available to all stakeholders (e.g., the members of the team as well as to all levels of management). One way of ensuring that the documented method is maintained is to store it in some kind of database that can be used not only to generate the constructed method from its method components but also to undertake some checking for consistency. For example, it is important that any work product produced as part of the REM is either consumed in another part of the REM, delivered to other parts of the software development (e.g. design, test) or is delivered to the client. 3.7 Train the Staff For the REM to be used successfully, all members of all teams must have buy-in and, potentially, “ownership” (Serour and Henderson-Sellers, 2004). Training staff about the new method can often be one of the most risky components of this whole approach (see Goldberg and Rubin, 1995) since the introduction of a new and innovative approach to an existing culture can often lead to resistance from the individuals concerned (Bridges, 1995). Staff need to be convinced that the introduction of the REM will be beneficial to them personally as well as to the organization for which they work. In addition, they must see that senior management are supplying sufficient resources and permitting them sufficient time to undertake the new learning experience. Only when the development team members feel comfortable with their understanding of the new method is it appropriate to mandate the method (Serour et al., 2002). Once such commitment has been gained from the development team, its use is likely to thrive. Without it, the project will be likely to fail (Serour and HendersonSellers, 2002). 3.8 Evaluation and Improvement of the Process Process evaluation is a notoriously challenging research issue. Even success and failure are hard to define, being perceived differently by different parties (Serour and Henderson-Sellers, 2002).

68



For many organizations, it is not method adoption that it critical to their overall success but their success in creating a culture in which software process improvement (SPI) is the norm. To identify successes in SPI, it is common to utilize one of the existing capability assessment frameworks such as SPICE (ISO15504) or the SEI’s CMM or CMMI. In summary, then, the REM needs to be carefully maintained, sustained and improved as time progresses and the management and team members become increasingly adept in its use.

4

A Partial Example

Here we can give an example of how the above could produce an endeavour-specific RE method. Since we are creating a REM, then there is only a single method component that is relevant in the category of OPF’s Activities viz. Requirements Engineering. Within that activity, many tasks need to be enacted by many teams, roles and people. Some possible linkages between teams and tasks (here we use the naming style of http://www.donald-firesmith.com rather than the style in the OPEN books in which OPF Tasks have imperative verb phrase names), are given in Table 3 and between teams and roles in Table 4. For each team in the matrix, we list vertically all the possible Task (Table 3) or Roles (Table 4) and then ask whether the task/role is relevant to each team in turn (Y/N). This gives a first cut at the most appropriate method fragments to use and also identifies any unnecessary tasks/roles since these are indicated by a blank line in the final matrix. In these tables, we do not use the full five-value range discussed above, but merely a binary Y/N (blank means N). It is found from experience that this is adequate for the first adoption of an ME approach. With more experience, a more sophisticated use of the deontic matrices will become possibly, using all five deontic values (mandatory, recommended, optional, discouraged, forbidden). Table 3: Deontic matrix to link RE Teams and Tasks (using only two deontic levels: Yes/No) Associated Tasks

Team Business strategy

Business visioning

Y

Competitor analysis

Y

Customer analysis

Y

Market analysis

Y

Requirements analysis

Y

Technology strategy

Requirements

Architecture

Customer representatives

Y

Y Y


Y

Y

69


Requirements elicitation

Y

Requirements management

Y

Y Y

Y

Requirements prototyping

Y

Requirements specification

Y

Requirements reuse

Y

Stakeholder profiling

Y

Technology analysis

Y Y

Y Y

Y

User analysis

Y

Y

Y

Table 4: Deontic matrix to link Teams and their associated Roles Associated Roles

Team A

Team B

Team C

Business architect

Y

Y

Business strategist

Y

Y ind.

Y

Customer representative

Y

Y

Y

Y

Team D

Database architect

Team E

Y

Domain expert

Y

Y

Y ind.

Y Y

Metrics analyst

Y Y

Y

Project manager

70

Team H

Y ind. (if relevant)

Hardware architect

Quality

Team G

Y

Digital brand strategist

Method engineer

Team F

Y Y

Y

Y



engineer Requirements engineer

Y

Security analyst

Y Y

Y

Y

Y

Security architect

Y

Software architect

Y

System architect

Y

Y

Technology strategist

Y

Y Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Technical leader Technical writer

Y ind.

Y

Test engineer User analyst

Y

User representative

Y

Y Y

Key to Teams: Team A = Business strategy team; Team B = Technology strategy team; Team C = Requirements team; Team D = Strategy inspection team; Team E = Requirements inspection team; Team F = Architecture team; Team G = Management team; Team H = Quality team. ind. means Independent

Initially, the matrix is filled in from past experience: that of the process engineer, project manager, the team members and the external method engineer. As experience builds up, it becomes possible to create a database of past knowledge from which it is easier and more reliable to draw a first estimate of the likely linkages that will work for that organizational context. In time, it is anticipated that tools will be constructed to assist in this stage.

5

Discussion and Future Work

Davis and Zowghi (2005) state that the purpose of requirements is to raise the likelihood that the right system will be built, i.e., that the system when built satisfies its intended customers and addresses their needs to an acceptable degree. It may be argued that the purpose is more short term, e.g., to ensure communication among all stakeholders, provide designers and testers with an oracle, guide project managers in allocation of resources, serve as a basis for requirements evolution. However, they argue that each of these short term objectives are important only because of their strong correlation to the real purpose of requirements, i.e., to raise the likelihood that the right system will be built. They further state that a “good” requirements practice is one that either reduces the cost of the development project or increases the quality of the resulting product when used in specific situations. Few requirements practices have been validated as “good” in practice, while those that have, rarely if ever, describe the specific situations where they are effective. However, there are several


71


published requirements practices for which the authors do claim goodness e.g. Sommerville and Sawyer (1997), Weigers (2003) and Robertson and Robertson (1999). Following construction of the REM and its utilization on a project, it is important to follow up and enquire about its effectiveness in practice. Some early results on exploring the effectiveness of the OPF are reported in a series of papers (Serour and Henderson-Sellers, 2002, 2004; Serour et al., 2002) from two industry case studies. While these papers focus on success or failure indicators, primarily in terms of people, culture and organization, there are other questions that could be asked in any future evaluation survey. These include: How big was the job? (person days) How easy/hard was it to use OPEN? How quick was it to construct the tailored process – was it overly labour intensive? Which parts could benefit from automation? Was the method component repository complete? Were method components adequate? Were the method components adequately documented? Can you evaluate the quality of the method component repository? Can you evaluate the quality of the ensuing REM? Did the approach permit or support process improvement? Has the ME approach turned out to be cost effective? Is an ME approach practical in an industry setting? We plan to undertake such surveys with companies adopting the OPF- and ME-based approach to requirements engineering. The results of these surveys will be the subject of a later paper.

6

Conclusion

As it is practically impossible to identify or to create a single method that is appropriate for all situations, the need for an REM necessitates the search for a mechanism that will support the flexible creation of a number of tailored REMs from a single base – here a repository of method components, based on that of the OPEN Process Framework and the techniques of method engineering, is used to illustrate how a project-specific or an organisational specific REM can be generated, applied and maintained. Since the RE process is complex and multifaceted and although the ability to create REMs for specific situations is an effective starting point, there is still more to be considered. Indeed, to address the diverse challenges of RE is not a matter of introducing a new tool and environment or merely selecting or devising a RE method. Instead, attention should be paid to the complex interplay between a number of organisational, cultural, technological and economical factors impacting the RE process. The RE method needs to be carefully maintained, sustained and improved as time progresses and the management and team members become increasingly adept in its use. The success of any REM can only be measured by how best the resulting product (i.e. SRS and ultimately the system when built) satisfies the real needs of the intended users.

72



References BOEHM BW and PAPACCIO PN (1988) Understanding and controlling software costs., IEEE Transactions of Software Engineering 14(10), 1462-1477 BRIDGES W (1995) Managing Transitions, Making the most of change. Nicholas Brealey Publishing, UK. BRINKKEMPER S (1996) Method engineering: engineering of information systems development methods and tools. Information and Software Technology 38(4), 275-280. BRINKKEMPER S, SAEKI M and HARMSEN F (1998) Assembly techniques for method engineering. In Proceedings CAiSE’98, LNCS 1413, Advanced Information Systems Engineering (PERNICI B and THANOS C, Eds), Springer-Verlag, Berlin, 381-400 BRINKKEMPER S, SAEKI M and HARMSEN F (2001) A method engineering language for the description of systems development methods (extended abstract). In CAiSE 2001 (DITTRICH KR, GEPPERT A and NORRIE MC, Eds), LNCS 2068, Springer-Verlag, Berlin, 473-476 COCKBURN A (2000) Selecting a project’s methodology. IEEE Software 17(4), 64-71 CURTIS B, KELLNER MI and OVER J (1992) Process modelling. Communications of the ACM, 35(9), 75-90 DAVIS AM (1993) Software Requirements: Analysis and Specification. Prentice Hall, second Edition DAVIS AM and ZOWGHI D ( 2005) Good requirements practices are neither necessary nor sufficient. Viewpoints, Requirements Engineering Journal 10. available online 8th October 2004 FIRESMITH DG (2002a) Requirements engineering. Journal of Object Technology 1(4), 93103 FIRESMITH DG (2002b) Requirements engineering. Journal of Object Technology 1(5), 8394 FIRESMITH DG and HENDERSON-SELLERS B (2002) The OPEN Process Framework. An Introduction. Addison-Wesley GOLDBERG A and RUBIN K (1995) Succeeding with Objects. Addison-Wesley GRAHAM I, HENDERSON-SELLERS B and YOUNESSI H (1997) The OPEN Process Specification. Addison-Wesley, 314pp HARMSEN AF, BRINKKEMPER S and OEI H (1994) Situational method engineering for information systems projects. In Methods and Associated Tools for the Information Systems Life Cycle. Procs. IFIP WG8.1 Working Conference CRIS/94 (OLLE TW and VERRIJNSTUART AA, Eds), North Holland, Amsterdam, 169-194 HENDERSON-SELLERS B (2003) Method engineering for OO system development. Communications of the ACM 46(10), 73-78 HENDERSON-SELLERS B and SEROUR M (2000) Creating a process for transitioning to object technology. In Proceedings Seventh Asia--Pacific Software Engineering Conference. APSEC 2000, IEEE Computer Society Press, Los Alamitos, 436-440 HRUBY P (2000) Designing customizable methodologies. JOOP, December 2000, 22-31 JIROTKA M and GOGUEN J (1994) Requirements Engineering social and technical issues. Academic Press KOTONYA G and SOMMERVILLE I (1997) Requirements Engineering processes and techniques. Wiley


73


KUMARK and WELKE RJ (1992) Methodology engineering: a proposal for situation-specific methodology construction. In Challenges and Strategies for Research in Systems Development (COTTERMAN WW and SENN JA, Eds), Wiley, Chichester, 257-269 MACAULAY L (1996) Requirements Engineering. Springer RALYTÉ J and ROLLAND C (2001) An assembly process model for method engineering. In Advanced Information Systems Engineering (DITTRICH KR, GEPPERT A and NORRIE MC, Eds.), LNCS2068, Springer, Berlin, 267-283. ROBERTSON J and ROBERTSON S (1999) Mastering the Requirements Process. Addison Wesley ROLLAND C and PRAKASH N (1996) A proposal for context-specific method engineering. In Proceedings of the IFIP WG8 International Conference on Method Engineering. Atlanta, GA, 191-208 SEROUR MK and HENDERSON-SELLERS B (2002) The role of organizational culture on the adoption and diffusion of software engineering process: an empirical study. In The Adoption and Diffusion of IT in an Environment of Critical Change (BUNKER D, WILSON D and ELLIOT S, Eds), IFIP/Pearson, Frenchs Forest, 76-88 SEROUR MK and HENDERSON-SELLERS B (2004) Introducing agility: a case study of situational method engineering using the OPEN Process Framework. In Proceedings of the 28th Annual International Computer Software and Applications Conference. COMPSAC 2004, IEEE Computer Society Press, Los Alamitos, 50-57 SEROUR M, HENDERSON-SELLERS B, HUGHES J, WINDER D and CHOW L (2002) Organizational transition to object technology: theory and practice. In Object-Oriented Information Systems (BELLAHSÈNE Z, PATEL D and ROLLAND C, Eds), LNCS 2425, Springer-Verlag, Berlin, 229-241 SOMMERVILLE I and SAWYER P (1997) Requirements Engineering, a good practice guide. Wiley TER HOFSTEDE AHM and VERHOEF TF (1997) On the feasibility of situational method engineering. Information Systems 22(6/7), 401-422 VAN SLOOTEN K and HODES B (1996) Characterizing IS development projects. In Proceedings of the IFIP TC8 Working Conference on Method Engineering: Principles of method construction and tool support (BRINKKEMPER S, LYYTINEN K and WELKE R, Eds) Chapman&Hall, 29-44 WIEGERS K (2003) Software Requirements. Microsoft Press

74


Conceptual Analysis of Current ME Artifacts in Terms of Coverage: A Contextual Approach Mauri Leppänen Department of Computer Science and Information Systems P.O. Box 35 (Agora), FI-40014 University of Jyväskylä, Finland [email protected]

Abstract Intellectual and methodical support is needed to engineer, in a situational manner, methods for requirements engineering (RE), and more generally for information systems development (ISD). In this paper we define a contextual framework, based on semiotics, linguistics, and the activity theory, and apply it to analyze the coverage of support that current method engineering (ME) artifacts provide for ME. The analysis shows that ME artifacts are rather limited in their support of ME workflows and deploy perspectives that only partly cover multifaceted aspects of ME contexts and ISD contexts. Based on the analysis, we suggest a more systematic use of perspectives in crafting better ME artifacts. Keywords: requirements engineering, information systems development, method engineering, contextual approach, perspective

1

Introduction

Requirements engineering (RE) means the process of proceeding from informal, fuzzy individual statements of requirements to a formal specification that is understood and agreed by all stakeholders (Bubenko, 1993; Pohl, 1996). Quality of requirements is vital to the success of information system development (ISD). For this reason, a multitude of RE techniques and approaches for the elicitation, modeling, specification and validating of requirements have been crafted. RE situations differ substantially from one another, e.g. in terms of largeness and complexity of the target system. Hence, there is the need to decide situationally which techniques and methods are appropriate and how they should be applied in the situation at hand. This need for customizing and configuring existing techniques and methods holds not only for RE but for the whole process of ISD as well. In addition, the emergence of new application areas and technologies necessitates the engineering of novel approaches, models, and techniques for RE and ISD. Method engineering (ME) means the process of developing, customizing and/or configuring a new or improved ISD method, or parts thereof, in a certain organizational and technical context. An ME is often quite a complicated endeavor. To achieve deliverables of good quality and make the process of engineering efficient, proper methodical support is needed. In the recent years several ME strategies and ME approaches (e.g. Kumar and Welke, 1992; Oei, 1995; Plihon et al., 1998; Ralyte et al., 2003; Saeki, 1998;), meta models (e.g. Graham et al., 1997; Harmsen, 1997; Heym and Österle, 1992; Kelly et al., 1996; OMG, 2005; Venable, 1993), ME techniques (e.g. Kinnunen and Leppänen, 1996; Leppänen, 2000; Punter and Lemmen, 1996; Saeki, 2003), and ME procedures (e.g. Harmsen, 1997; Nuseibeh et al., 1996; Song, 1997; Vlasblom et al., 1995) have been developed. We call these


75

Conceptual Analysis of Current ME Artifacts in Terms of Coverage

achievements shortly ME artifacts. Some of these artifacts are descriptive, such as meta data models and meta process models. The other artifacts are prescriptive, providing guidelines and rules for how to proceed in an ME effort. Our purpose here is to analyze the extent of intellectual and methodical support that prescriptive ME artifacts provide for ME. This means that we examine which ME actions are supported by ME artifacts and which concepts and constructs they apply to conceive, structure and represent phenomena in ME. For the analysis we will define and deploy a contextual framework. In the ME literature there are some studies that evaluate and compare meta data models (e.g. Harmsen and Saeki, 1996; Saeki and Wen-Yin, 1994; Tolvanen, 1998; Venable, 1993), meta process models (e.g. Söderström et al., 2002) and other smallscale ME artifacts. To our knowledge, there are not, however, any studies that would make a comprehensive assessment of prescriptive ME artifacts from the conceptual viewpoint. This kind of evaluation is necessary to find insufficiencies and gaps in ME support and to direct future research to improve existing ME artifacts and to engineer new ones. This study is organized as follows. First, we define the basis and contents of the contextual framework. Second, we select ME artifacts for the analysis, give short descriptions of them and analyze them according to the contextual framework. At the end, we present the summary and conclusions.

2

Contextual Framework

To be extensive in its support, an ME artifact has to offer a comprehensive view of ME and ISD contexts. We apply the contextual approach, based on semiotics (Peirce, 1955), linguistics (Fillmore, 1968; Levinson, 1983), and the activity theory (Engeström, 1987), to build the foundation, called the contextual framework, that enables us to evaluate that view. According to the contextual approach, the universe of discourse (UoD) is seen as one or more inter-related contexts in which Somebody (actor) does Something (action), for Some reasons (purpose), for Someone (object), with the help of Something (facility), Somewhere (location) and Sometimes (time). The contextual framework, built upon the contextual approach, is composed of two main parts: ME context and ISD context (see Figure 1). An ME context means a situation in which method engineering is carried out, in order to provide another situation(s), called ISD context(s), with an ISD method. The contexts are decomposed according to seven inter-related contextual domains: purpose, actor, action, object, facility, location, and time. The domains are defined as follows: •

Purpose domain consists of those concepts and constructs which refer, directly or indirectly, to goals, motives, or intentions of someone or some thing. They may also express reasons for why someone exists, why something has been done, why someone is used, etc. in a context.

•

Actor domain encompasses those concepts and constructs, which refer to individuals, groups, positions, or organizations.

•

Action domain is composed of those concepts and constructs which refer to functions, activities, tasks, or operations carried out in a context.

76


Leppänen

•

Object domain comprises those concepts and constructs which refer to something which an action is targeted to. The object can be material or informational.

•

Facility domain consists of those concepts and constructs which refer to means, whether a tool or a resource, by which something can be done or is done.

•

Location domain is composed of those concepts and constructs which refer to parts of space occupied by someone or something. The location can be physical, like a room or a building, or logical, like a site in a communication network.

•

Time domain includes those concepts and constructs which refer to temporal aspects in a context.

ME context ME workflows: ISDM RE ISDM analysis ISDM design ISDM implementation ISDM evaluation

P T

Ar An

L

F O

ISD context

P T

Ar An

L

F

ME perspectives: ME systelogical ME infological ME conceptual ME datalogical ME physical

ISD perspectives: ISD systelogical ISD infological ISD conceptual ISD datalogical ISD physical

Domains: P = Purpose Ar = Actor An = Action O = Object F = Facility L = Location T = Time

O

Figure 1: Contextual Framework.

Applying the domains to an ME context, for instance, means, that ME purposes refer to ME goals, ME intentions, ME problems, etc. ME objects mean all those informational things to which ME actions are targeted. ME objects, such as any other informational objects, can be perceived as linguistic deliverables, or alternatively as conceptual constructs. ME contexts and ISD contexts are often quite large and multifaceted. To cope with this complexity, it is common to apply some well-defined perspectives. The ISD literature provides several taxonomies of perspectives and viewpoints (e.g. Essink, 1988; Freeman and Layzell, 1994; Iivari, 1989; ISO, 1996; Kruchten, 1995; Olive, 1983; Olle et al., 1988; Sol, 1992; Sowa and Zachman, 1992; Welke, 1977). Here, we define, mainly based on Iivari (1989) and Welke (1977), a system of five perspectives to be applied for perceiving ME contexts and ISD contexts. The perspectives are: systelogical, infological, conceptual, datalogical, and physical perspectives. According to the systelogical perspective, the target context is considered in relation to its utilizing context. Applying the infological perspective, the target context is seen as a functional structure of information processing actions and informational objects, independent from any representational and implementational features. The conceptual perspective guides to consider the target context through the semantic contents of information it processes. From the datalogical perspective the target context is


77


viewed, through representation-specific concepts, as a context, in which actors work with facilities to process data. The physical perspective ties datalogical concepts and constructs to a particular organizational and technical environment. In Table 1 we apply the perspectives to characterize the ME perspectives with relevant questions. The ISD perspectives can be described in the same way. Table 1: ME Perspectives. ME perspectives ME systelogical

ME infological ME conceptual ME datalogical

ME physical

Relevant questions Of what kind are the target ISD contexts for which ISD method is to be produced in the ME? Of what kind are the IS’s for which the ISD projects are to be launched? Of what kind are the business systems which the IS’s should provide with information services? Of what kind are the services the ME should provide? What are the goals and constraints for ME approaches, ME organizations, ME actions, etc. in the ME context? What ME objects are produced in the ME on a general level? What ME actions are needed to yield those objects and how they are logically related? What is the conceptual contents of the ME objects processed in the ME? What kinds of structural and dynamic constraints are valid? How are the ME objects presented in data? How are the ME actions composed into ME roles? How are ME actions supported with ME tools? What are the rules for ME actions? How are the ME objects implemented? How are the ME actions actually to be carried out? How is the ME effort staffed in practice? How are the ME tools configured and implemented? How is the ME effort managed and scheduled?

Based on the analogy between ME contexs and ISD contexts (cf. Kumar and Welke, 1992; Olle et al., 1988; Tolvanen, 1998), we distinguish between five ME workflows. An ME workflow is a coherent composition of ME actions, (a) which are organized to accomplish some ME process, (b) which share the same target of action, and (c) which produce results valuable for ME stakeholders. Note that ME workflows do not mean ME phases. The five ME workflows are (cf. Jacobson et al. (1999)): ISD method requirements engineering, ISD method analysis, ISD method design, ISD method implementation, and ISD method evaluation. In the following, we use the abbreviation ‘ISDM’ to stand for ‘ISD method’ in the names of the ME workflows. •

ISDM requirements engineering means an ME workflow, which aims to identify and elicit ME stakeholders’ requirements concerning the nature, contents and structure of the ISD method. It also seeks to establish and maintain an agreement on the essential aspects of the ISD method, and to express them as part of the ME goals.

•

ISDM analysis denotes an ME workflow, which aims to produce high-level descriptions of the ISD method, meaning that the ISD method is considered from

78


Leppänen

the ISD infological perspective and the ISD conceptual perspective. Consequently, in this ME workflow concepts and constructs of the ISD purpose domain, the ISD action domain and the ISD object domain are used to make descriptions and prescriptions of what is to be done, for which, and why in the target ISD context. •

ISDM design refers to an ME workflow, which aims to produce more elaborated descriptions of the ISD method. Here, the ISD method is considered from the ISD datalogical perspective, uncovering “How” an ISD effort is to be accomplished. This means that the following kinds of questions are answered: What kinds of ISD roles and ISD positions are established? How the ISD actions are decomposed at a detailed level? Which part of the ISD work is to be supported by computer-based tools?

•

ISDM implementation means an ME workflow, which aims to produce concrete descriptions/prescriptions of the ISD context from the ISD physical perspective. That means that the descriptions/prescriptions made earlier are realized and instantiated into an ISD project plan that dictates who does what, why, how, for what, when and where.

•

ISDM evaluation means an ME workflow, which aims to produce assessments of one or more ISD methods according to the defined criteria. An ISD method can be evaluated at any point of its life cycle. It can be just a roughly outlined artifact, like that resulting from the ISDM analysis workflow, or it can be a complete ISD method already used in an ISD project. The criteria used vary from logical to technical and from general to detailed, depending on the nature of the ISD method and the ISD perspective applied.

3

Analysis

We can distinguish between three groups of ME artifacts in the ME literature. The first group comprises a large variety of meta models and metamodeling languages developed for modeling ISD methods, or parts thereof. This group contains meta data models (e.g. ER (Chen, 1976), eERM (Rosemann and Green, 2002), NIAM (Nijssen and Halpin, 1989), ASDM (Heym and Österle, 1992), CoCoA (Venable, 1993), GOPRR (Kelly et al, 1996), Telos (Jarke et al., 1995), OPEN (Graham et al., 1997), and MEL/MDM (Harmsen, 1997), as well as meta process models (e.g. Bandinelli et al., 1993; Christie, 1993; Deiters and Gruhn, 1994; Dutton, 1993; Kaiser et al., 1993; OMG, 2005; Shepard et al., 1992; Standards Australia, 2004). The second group of ME artifacts includes ME strategies (e.g. Kumar and Welke, 1992), ME approaches (e.g. Oei, 1995; Grundy and Venable, 1996; Saeki; 1998) and ME techniques (e.g. Kinnunen and Leppänen, 1996; Leppänen, 2000; Punter and Lemmen, 1996; Saeki, 2003; van Slooten and Brinkkemper, 1993). Common to these ME artifacts is that they either remain on a very general level (cf. ME strategies and ME approaches) or they cover only a small part of the ME process (cf. ME techniques). The third group contains artifacts that aim to offer more comprehensive support for ME. This group contains the dissertation works of Harmsen (1997) and Tolvanen (1998). Both of them suggest specific approaches to ME (a situational approach in Harmsen (1997) and an incremental approach in Tolvanen (1998)) and offer general-


79


level procedures to implement the approaches. In addition, this group includes the ME artifacts of Gupta and Prakash (2001), Song (1997), Vlasblom et al. (1995), Nuseibeh et al. (1996), and Ralyte et al. (2003). Gupta and Prakash (2001) define a representation system for a method requirements specification and describe an automated process for instantiating a technical meta model. Song (1997) defines a framework for the integration of design methods and gives principles of applying it. Vlasblom et al. (1995) propose the three-level description of a method and present a “protocol” for the construction of a development model. Nuseibeh et al. (1996) outline a multi-perspective ME approach based on the notion of Viewpoint and describe, on a general level, a process of method design and construction. Ralyte et al. (2003) present a generic process model supporting the integration of different approaches to situational method engineering. Though some of the artifacts in this group (e.g. Nuseibeh et al., 1996; Ralyte et al., 2003) are not described in detail, they are included here because of special features of their support for ME. We select the ME artifacts in the third group for the targets of our analysis. In the following, we outline the ME artifacts and analyze their coverage and emphases in terms of ME workflows, perspectives and contextual domains. The results of the analysis are summarized in Tables 2 and 3. Harmsen (1997) presents (a) an ontology for products of information systems development, called the Methodology Data Model (MDM), (b) a method engineering language, called MEL, and (c) a process of situational method engineering with heuristics and formalized method assembly rules. The process of situational method engineering is decomposed into three main steps. The first step is the characterization of the situation, meaning that ISD project goals are determined and a preliminary scenario is generated and adapted with situational factors (or contingency factors), and possibly with performance indicators. The second step is the selection of method fragments, which is induced by the produced characterizations as the project scenario. Method fragments are characterized by a number of properties, and those fragments which match with the project scenario are selected. The third step is the assembly of method fragments in which the selected fragments are integrated to form a situational method. To avoid defects and inconsistencies in and between the fragments, a number of method assembly quality assurance rules are defined and applied. The steps in the situational ME process address all the ME workflows, except ISDM implementation (e.g. there are neither rules for customization nor instantiation). The ME context is described from the ME systelogical, ME infological and ME conceptual perspectives, and, to a smaller extent, from the ME datalogical perspective. Thus, ME purposes, ME actions (steps), ME objects (incl. method fragments) and ME facilities (CAME, Decamerone) are involved. Some references to ME actors are also given. The conceptual contents of the ME objects are described from the ISD infological and ISD conceptual perspectives, and partly from the ISD datalogical perspective, concerning ISD actors (actors), ISD actions (process types), ISD objects (products) and ISD facilities (CASE tools). The conceptual contents of the ISD objects are also structured. Some descriptions of the ME tool, Decamerone, are so technical that they belong to the physical ME perspective. Tolvanen (1998) presents principles of incremental method engineering and studies method development through experience-based method refinement. The principles are aimed at supporting organizations to develop their own methods, known as local methods. The ME process is divided into two kinds of steps: a priori

80


Leppänen

Table 2: Analysis of the ME Artifacts in Terms of ME Workflows. Reference

ISDM RE

Harmsen (1997)

Characterization of situation

Tolvanen (1998)

Analysis of ISD environment

Gupta and Prakash (2001)

Method requirements engineering (Method nature part)

Song (1997)

--

Vlasblom et al. (1995)

Analysis of a project situation (specific situation profile) --

Nuseibeh et al. (1996) Ralyte et al. (2003)

Set method engineering goal

ISDM Analysis Selection of method fragments Assembly of method fragments Method selection Method construction Method refinement

ISDM design Selection of method fragments Assembly of method fragments --

ISDM implementation --

ISDM evaluation Assembly rules enforcement

Method construction Tool adaptation Method refinement

Method requirements engineering (Simple method part & Mapping method part) Property integration Principle integration Artifact integration Process integration Modification of the bestmatched development model Method design and construction Construct a method

Method design

Method construction and implementation

Evaluation of existing methods Collection of experiences Analysis of method use --

Process integration Representation integration

--

--

Modification of the bestmatched development model Method design and construction Construct a method

Modification of the bestmatched development model Method design and construction Construct a method

--

---

steps and a posteriori steps. A priori ME steps are method selection, method construction and tool adaptation. A posteriori ME steps are collection of experiences, analysis of method use, and method refinement. In the first step the ISD environment is analyzed according to situation-independent and situation-dependent ISD method criteria. In the second step the selected methods are constructed. This means integration and adaptation of one or more methods, or parts thereof. In the third step


81


Table 3: Analysis of the ME Artifacts in Terms of Perspectives and Contextual Domains. Reference Harmsen (1997) Tolvanen (1998) Gupta et al. (2001) Song (1997) Vlasblom et al. (1995) Nuseibeh et al. (1996) Ralyte et al. (2003)

ME Perspectives S & I & C&d I&C

P

Ar

An

O

F

X

x

X

X

X

ISD Perspectives I&C&d

-

-

X

X

x

i&C

-

-

x

X

i&C

-

-

x

s&i

x

-

i&c

-

s&i

X

Legend: Perspectives: S = Systelogical I = Infological C = Conceptual D = Datalogical P = Physical

P

Ar

An

x

x

C

-

-

I&C

x

-

I&c

x

x

-

-

x

x

-

-

x

x

-

I

X

O/ D X

O/ C X

F X

-

-

-

X

-

X

-

X

X

X

-

-

-

X

X

x

-

-

-

-

-

-

-

-

-

X

X

-

-

-

-

-

-

-

-

Contextual domains: Emphasis: P = Purpose An = Action X = concerned to a large extent Ar = Actor F = Facility x = concerned to some extent O = Object - = not concerned O/D = Objects as representational deliverables O/C = Objects as conceptual constructs

the methods constructed are adapted into a CASE tool. This means customizing or building a tool for the method or selecting a set of tools which cover all the method knowledge (ibid p. 70). In the a posteriori part of ME, experiences from the use of the constructed ISD method are first collected in terms of models produced during the ISD, meta models, reports on stakeholder interviews, etc. The experiences are analyzed according to the defined analysis mechanisms. Evaluation of method use can lead to modifications in the method and tool support. These modifications are done in the final step. The iterative nature of the ME process implies that the refined method can be taken as such or as a re-refined method in the next ISD project (ibid pp. 190-192). A part of method selection, the analysis of ISD environment, belongs to the ISDM RE workflow. The rest of method selection as well as method construction and method refinement correspond to the ISDM analysis workflow because the process concerns neither ISD actors nor ISD facilities. Part of method construction and tool adaptation belongs to the ISDM implementation because in that step the method is particularly tied to technical infrastructure of the project. A part of the first step as well as the fourth and fifth steps address issues of the ISDM evaluation workflow. For these steps Tolvanen (1998) provides descriptions of ME actions. ME deliverables are, to a large degree, addressed from the ME conceptual perspective only. Because the incremental ME process has been established on the consideration of the meta

82


Leppänen

data model (i.e. the GOPRR model (Kelly et al., 1996)), the only domain concerned in the ISD context is the ISD object domain, considered from the ISD conceptual perspective. Gupta and Prakash (2001) define a representation system for a method requirements specification (MRS) and describe an automated process for instantiating a technical meta model with an MRS. This instantiation is used to produce the actual method, which is then given to a metaCASE tool to produce a CASE tool. Interesting in the ME approach is that a method is first specified on a ”relatively abstract” level with statements of method requirements, and then it is elaborated and instantiated. The approach applies the static and dynamic views on methods (Prakash, 1997; Prakash, 1999) reflecting the ISD as a decision making process. Method engineering is composed of three main phases: (1) method requirements engineering (MRE), (2) method design (MD), and (3) method construction and implementation (MCI). In the MRE phase the method requirements definition is first produced. Second, the MRE yields a Method Requirements Specification (MRS), which “is a technical document describing what a method that meets the MRS has to offer” (ibid p. 136). Being independent from implementational issues, an MRS details the nature of the method but not the method itself. An abstract language, called MRSL, has been developed to express an MRS. The MD phase translates an MRS into an instantiation of the technical meta model. The method construction and implementation phase generates the method and builds the CASE tool. A CAME tool, referred to as MERU, has been built to provide assistance in the tasks of three ME phases (ibid pp. 136-137). Gupta and Prakash (2001) apply a three-layer architecture to specify a method. At the highest level, the generic view of a method offers a basis for building the abstract model and MRSL. It is used in the MRE phase. The second layer, the metamodel layer, defines the decisional metamodel that is used in the MD phase to make an instantiation. At the third layer, the method is finally produced from the instantiation performed in the second phase. This layer is used in the MCI phase. The suggestion of Gupta and Prakash (2001) is the only one among the analyzed ME artifacts that clearly distinguishes between different levels of abstraction on which a method can be conceived (cf. the generic view, the metamodel view, and the construction view). It also differentiates between three “phases” of the engineering of a method, based on these abstraction levels. The phases stand for our four ME workflows in such a way that the tasks of the MRE phase belong partly to the ISDM RE (cf. the method nature) and partly to the ISDM analysis (cf. the simple method part and the mapping method part). The MD phase and the MCI phase correspond to the ISDM design workflow and the ISDM implementation workflow, respectively. Issues of the ISDM evaluation workflow are not addressed in Gupta and Prakash (2001). The ME context is mainly considered from the ME conceptual perspective, because the emphasis in the article is on the MRS language and the decisional metamodel. The ME actions are outlined only on a very general level (cf. the ME infological perspective). The article also contains a short description of MERU. The ISD context is perceived from the ISD infological and ISD conceptual perspectives. Song (1997) defines a framework for the integration of design methods and gives general principles of applying it. The framework views integration mainly as an effort to enhance the existing method with properties or components of some other method(s). In the framework four kinds of integration are distinguished: model


83


integration, principle integration, process integration, and representation integration. Further, two approaches to integration are recognized: function-driven integration and quality-driven integration. Song does not provide any method of integration, neither any uniform procedure. Instead, he gives an outline of steps for function-driven integration and quality-driven integration on two levels of detail. The steps are divided into two parts, corresponding to high-level integration and low-level integration. The former concerns artifact models, properties, principles, representations, and processes. The latter involves model components (e.g. classes), criteria, guidelines, measures and notations. The function-driven integration is applied when new functionalities are searched for the existing method from other methods, or parts thereof. In the high-level integration, the process starts with consideration of property integration with the aim of revealing properties that are not effectively supported by the existing method. Next, new and promising ISD principles are searched for and integrated into the existing method. Some of these steps correspond to the ISDM RE workflow but because Song (1997) does not provide any guidance to requirements engineering of the method we locate these steps in the ISDM analysis workflow in Table 1. In the artifact model integration the existing method is enhanced with new artifact models (i.e. IS meta models), and in the process integration the processes of specifying the new artifact models are associated into the existing method. These steps are related to the ISDM analysis workflow. Finally, in representation integration the notations of design artifacts are made uniform. This is concerned in the ISDM design workflow in our framework. The low-level integration considers issues that are related to the ISD datalogical perspective in the ME design workflow. The quality-driven integration does not aim to enhance the functionalities of the ISD method but to improve its quality in terms of more general criteria (e.g. more maintainable software, more efficient ISD process, etc.). At the high-level, the quality-driven integration consists of at most process and representation integration, and at the low-level it concerns guidelines, measures, actions, and notations. The steps can be located into the ME workflows as above. The integration process is described in terms of ME deliverables, not by detailing steps. In the ISD context ISD actions (processes) and ISD deliverables (artifacts) are distinguished. Vlasblom et al. (1995) propose a three-level description of the method. The levels are the generic level, the model level, and the specific level. The generic level is composed of building blocks for various elements of the method (i.e. products, activities, development strategies, techniques, tools etc). The model level contains development models for specific application domains. The lowest level corresponds to project-specific development methods, called project scenarios. Based on the three-level architecture, Vlasblom et al. (1995) suggest steps for deploying development models in specific situations. The process starts with the project initiator analyzing the project situation and consulting the library of available development models. After choosing the model the profile of which best matches the specific situation profile, it is modified until a scenario for project direction and operation is achieved (ibid p. 602). In addition, Vlasblom et al. (1995) provides steps to the construction of a development model from existing approaches / projects. The steps are: familiarization with the established practice (i.e. completed projects), formalization of the development model, establishing the model situation profile, and

84


Leppänen

feedback to the library of building blocks. The steps cover, to some extent, the first four of our ME workflows. They are, however, described on a highly general level, viewing from the ME systelogical and ME infological perspectives. Nuseibeh et al. (1996) outline an approach and a process of method design and construction, based on multi-perspective development. The key concept of the approach is Viewpoint that is “a loosely coupled, locally managed, distributable object that encapsulates representation knowledge, development process knowledge and specification knowledge about an ISD” (ibid. p. 268). An ISD method is a collection of method fragments, each of which describes how to develop a single ViewPoint specification. A Viewpoint is internally divided into five ‘slots’: style (notation), work plan (development process), specification (one described in the notation, produced by the development process), domain (label identifying the area of concern of the ViewpPoint), and work record (specification development status, history and rationale). A ViewPoint template contains the first two ‘slots’. A method is a configuration of ViewPoint templates. This implies that an ISD process is not a sequential series of procedures but dynamically created as the development proceeds. The process of method design and construction is divided into six steps: (1) identify development techniques: derive from the requirements of a method the techniques that the target method will deploy, (2) identify ViewPoint templates that need to be constructed to describe these techniques, (3) describe templates, (4) reuse templates, (5) identify and describe inter-ViewPoint relationships, and (6) construct local (ViewPoint) development process models. In Nuseibeh et al. (1996), the descriptions of the ME context and the target ISD context are given on a very general level. The ME steps concern the ISDM analysis, ISDM design, and ISDM implementation workflows, the emphasis being on the ISDM analysis. The ISD context is perceived through ViewPoint patterns, meaning that ISD actions (“work plan”) and ISD deliverables (“specification”) are mainly considered from the ISD infological perspective. Ralyte et al. (2003) present the generic process model supporting the integration of different approaches to situational method engineering. The generic model contains three ME techniques: assembling method chunks, extending an existing method, and generating a method by abstraction/instantiation of a model/meta-model. The paper also shows how other ME techniques could be integrated in the generic model. The generic process model is based on a strategic process meta-model, called Map (Rolland et al., 1999), describing the ME process in terms of intentions and strategies. An intention is a goal that can be achieved by the performance of the process (expressed like “Set Method Engineering Goal”, (Ralyte et al. (2003, p. 97)). A strategy represents the manner in which the intention can be achieved. A triplet of source intention, target intension, and strategy is provided with intention achievement guidelines. According to the generic process model, the process of situational ME is made of two main intentions: setting the ME goals and constructing a method to satisfy these goals. Ralyte et al. (2003) present separate process models for three method construction techniques: assembly-based method engineering, extensionbased method engineering, and paradigm-based method engineering. The process models are expressed in the form of a graph in which nodes stand for intentions and edges correspond to strategies. The models apply the ME systelogical perspective and, partly, the ME infological perspective. It does not explicitly recognize the ME objects.


85


4

Summary and Conclusions

The goal of this study has been to assess the extent to which existing ME artifacts provide intellectual and methodical support for ME. For the analysis we defined the contextual framework, based on the theory-based contextual approach. The framework is composed of two main parts, ME context and ISD context, which are structured through seven contextual domains, five perspectives, and five ME workflows. The analysis of the ME artifacts, in terms of the ME workflows, showed that all of them are somewhat limited as to their support. There are lacks, in particular, in how the ISDM design and ISDM evaluation workflows are addressed. Also the other workflows are only partly addressed, and in the most cases ME actions are described on quite a general level. The most comprehensive artifacts, in this respect, are the ones of Harmsen (1997) and Tolvanen (1998). Gupta and Prakash (2001) are the only ones who decompose the ME process into ME workflows, based on ISD perspectives. But they consider the ME context mainly from the ME conceptual perspective, and the ME actions are only outlined. The ISDM evaluation workflow is totally ignored. In Song (1997) ME work is decomposed into steps based on the target of integration. These steps adopt a narrow scope to the ME workflows. In Vlasblom et al. (1995) and Nuseibeh et al. (1996) the ME work is only partially, and on a general level, covered. The analysis, based on the perspectives and contextual domains, showed that the ME infological and ME conceptual perspectives are most commonly applied. Besides ME actions and ME objects, some ME artifacts also concern ME purposes (Harmsen, 1997; Ralyte et al., 2003; Vlasblom et al. 1995) and ME facilities (Harmsen 1997; Tolvanen, 1998). Harmsen (1997) provides the most extensive treatment of the ME domains. Related to the ISD context, the ISD infological perspective and the ISD conceptual perspective are considered in Harmsen (1997), Gupta and Prakash (2001), and Song (1997). Tolvanen (1998) only addresses the ISD conceptual perspective, and Nuseibeh et al. (1996) apply the ISD infological perspective. In order to offer a comprehensive support for ME, it is necessary that an ME artifact is anchored on some generic foundation, which is justified with relevant theories. Our suggestion for this kind of foundation is the contextual framework, and, in particular, its perspectives and contextual domains. The use of the framework implies for the ME systelogical perspective, for instance, that an ME artifact should offer models and guidelines to characterize the ME context at hand, to define the target ISD context, and to determine goals and constraints for the selection of ME strategies and ME approaches. For the ME conceptual perspectives, an ME artifact should provide ontologies for ISD and IS in the form of models and meta models, and instructions for how these ontologies are customized in a situational manner. Alternatively, an ME artifact should advice how to select and adapt models and meta models of other ME artifacts. Furthermore, an ME artifact should provide a variety of models for making descriptions of an ISD method from several ISD perspectives, first for outlining ISD approaches and application areas, and then for elaborating, stageby-stage, a contextual view of how an ISD is to be accomplished, by which steps, by whom, and by the help of which. The aforementioned characterizations, derived from the contextual framework, are intended just to give some examples of properties of the required ME artifacts. These should be elaborated and extended to address all the perspectives. The

86


Leppänen

perspective-based view should be clearly manifested through special models about ISD methods and a way of structuring the ME process. The ME literature provides some good candidates of these kinds of models. The strategic process meta-model (Ralyte et al. 2003), for instance, is suitable as a general-level ISD systelogical /infological model. More “contextually” elaborated models are, however, needed for viewing from the other ISD perspectives. For structuring the ME process we suggest the use of ME workflows (cf. Gupta and Prakash, 2001), as specified in the contextual framework. We argue that, in addition to the advantages mentioned above, the perspectivebased view can help us structure, in a natural manner, ME actions. Related to the taxonomy of generic, domain-specific, organization-specific, and project-specific methods - which is actually based on perspectives about ISD contexts - we can define more precisely the scopes of and relationships between actions of customization, configuration, and realization of ISD methods. Perspectives also give us the basis for establishing goals and criteria for the evaluation of ISD methods. This is the direction toward which we are engineering our ME artifact, called MEMES (Method Engineering MEthodical Skeleton) (Leppänen, 2005).

References BANDINELLI S, FUGGETT A and GHEZZI C (1993) Software process model evolution in the SPADE environment. IEEE Transactions on Software Engineering 19(12), 1128-1144. BUBENKO J (1993) Extending the scope of information modeling, SISU, Stockholm. CHEN P (1976) The entity-relationship model – toward a unified view of data. ACM Transactions on Database Systems 1( 3), 9-36. CHRISTIE A (1993) A graphical process definition language and its application to a maintenance project. Information and Software Technology 25(6/7), 364-374. DEITERS W and GRUHN V (1994) The funsoft net approach to software process management. International Journal of Software Engineering and Knowledge Engineering 4(2), 229-256. DUTTON J (1993) Commonsense approach to process modelling. IEEE Software 10(4), 5664. ENGESTRÖM Y (1987) Learning by expanding: an activity theoretical approach to developmental research. Orienta-Konsultit, Helsinki. ESSINK L (1988) A conceptual framework for information systems development methodologies. In Information technology for organizational system (BULLINGER HJ et al., Eds.), p. 354-362, North-Holland, Amsterdam. FILLMORE C (1968) The case for case. In universals in linguistic theory (BACH E and HARMS RT, Eds.), Holt, Rinehart and Winston, New York. FREEMAN M and LAYZELL P (1994) A meta-model of information systems to support reverse engineering. Information and Software Technology 36(5), 283-294. GRAHAM I, HENDERSON-SELLERS B and YOUNESSI H (1997) The OPEN process specification. Addison-Wesley, London, UK. GRUNDY J and VENABLE J (1996) Towards an integrated environment for method engineering. In Proceedings of the IFIP TC8, WG 8.1/8.2 working conf. on method


87


engineering – Principles of method construction and tool support (LYYTINEN K, BRINKKEMPER S and WELKE R, Eds.), p. 45-62, Chapman & Hall, London. GUPTA D and PRAKASH N (2001) Engineering methods from method requirements specifications. Requirements Engineering 6(3), 135-160. HARMSEN F (1997) Situational method engineering. PhD Thesis, University of Twente, Moret Ernst & Young Management Consultants, The Netherlands. HARMSEN F and SAEKI M (1996) Comparison of four method engineering languages. In Proceedings of the IFIP TC8, WG 8.1/8.2 working conf. on method engineering – Principles of method construction and tool support (LYYTINEN K, BRINKKEMPER S and WELKE R, Eds.), p. 209-231, Chapman & Hall, London. HEYM M and Österle H (1992) A reference model for information systems development. In Proceedings of the IFIP WG 8.2 working conf. on the impacts on computer supported technologies on information systems development (KENDALL K, LYYTINEN K and DEGROSS J, Eds.), p. 215-240, North-Holland, Amsterdam. IIVARI J (1989) Levels of abstraction as a conceptual framework for an information system. In Information system concepts: an in-depth analysis (FALKENBERG E and LINDGREN P, Eds.), p. 323-352, North-Holland, Amsterdam. ISO (1996) Information technology – Open distributed processing Overview, 10746-1.

- Reference model:

JACOBSON I, BOOCH G and RUMBAUGH J (1999) The unified software development process. Addison-Wesley, Reading. JARKE M, GALLENSDÖRFER R, JEUSFELD M, STAUDT M and EHERER S (1995) ConceptBase: a deductive object base for meta data management. Journal of Intelligent Information Systems 4(2), 167-192. KAISER G, POPOVICH S and BEN-SHAUL I (1993) A bi-level language for software process modeling. In Proceedings. of the 15th int. conf. on software engineering, p. 132-143, IEEE Computer Society Press, Washington. KELLY S, LYYTINEN K and ROSSI M (1996) MetaEdit+: a fully configurable multi-user and multi-tool CASE and CAME environment. In Proceedings of the 8th conf. on advanced information systems engineering (CAiSE’96) (VASSILIOU Y and MYLOPOULOS J, Eds.), p. 1-21, Springer, Berlin. KINNUNEN K and LEPPÄNEN M (1996) O/A matrix and a technique for methodology engineering. Journal of Systems and Software 33(2), 141-152. KRUCHTEN P (1995) The 4+1 view model of architecture. IEEE Software 12(6), 42-50. KUMAR K and WELKE RJ (1992) Methodology engineering: a proposal for situation specific methodology construction. In Challenges and strategies for research in systems development (KOTTERMANN WW and SENN JA, Eds.), p. 257-269, John Wiley & Sons, Washington, DC. LEPPÄNEN M (2000) Toward a method engineering (ME) method with an emphasis on the consistency of ISD methods. In Proceedings of the Fifth CAiSE/IFIP8.1 international workshop on evaluation of modeling methods in systems analysis and design (EMMSAD’00) (SIAU K, Ed.), Stockholm, Sweden. LEPPÄNEN M (2005) An ontological framework and a methodical skeleton for method engineering: A contextual approach. PhD Thesis, Jyväskylä Studies in Computing No: 52, Department of Computer Science and Information Systems, University of Jyväskylä, Finland.

88


Leppänen

LEVINSON S (1983) Pragmatics. Cambridge University Press, Cambridge. NIJSSEN G and HALPIN T (1989) Conceptual schema and relational database design: a fact oriented approach. Prentice-Hall, Englewood Cliffs. NUSEIBEH B, FINKELSTEIN A and KRAMER J (1996) Method engineering for multiperspective software development. Information and Software Technology 38(4), 267-274. OEI J (1995) A meta model transformation approach towards harmonization in information system modeling. In Proceedings of IFIP WG8.1 working conf. on information system concepts – towards a consolidation of views (FALKENBERG E, HESSE W and OLIVE A, Eds.), p. 106-127, Chapman & Hall, London. OLIVE A (1983) Analysis of conceptual and logical models in information systems development methodologies. In Information systems design methodologies: a feature analysis (OLLE T, SOL H and TULLY C, Eds.), p. 63-85, North-Holland, Amsterdam. OLLE T, HAGELSTEIN J, MACDONALD I, ROLLAND C, SOL H, van ASSCHE F and VERRIJN-STUART A (1988) Information systems methodologies – a framework for understanding. 2nd edition, Addison-Wesley, Reading. OLLE T, SOL H and TULLY C (Eds.) (1983) Proceedings. of the IFIP WG8.1 working conf. on feature analysis of information systems design methodologies. North-Holland, Amsterdam. OMG (2005) Software process engineering metamodel specification, Version 1.1, January 2005. Available at URL: . PEIRCE C (1955) Philosophical writings of Peirce (BUCHLE J, Ed.). Dover, New York. PLIHON V, RALYTE J, BENJAMEN A, MAIDEN N, SUTCLIFFE A, DUBOIS E and HEYMANS P (1998) A re-use-oriented approach for the construction of scenario based methods. In Proceedings of the 5th international conf. on software process (ICSP’98), p. 1417, Chicago, Illinois. POHL K (1996) Process-centered requirements engineering. John Wiley & Sons, New York. PRAKASH N (1997) Towards a formal definition of methods. Requirements Engineering 2(1), 23-50. PRAKASH N (1999) On method statics and dynamics. Information Systems 24(8), 613-637. PUNTER T and LEMMEN K (1996) The MEMA-model: towards a new approach for methods engineering. Journal of Information and Software Technology 38(4), 295-305. RALYTE J, DENECKER R and ROLLAND C (2003) Towards a generic model for situational method engineering. In Proceedings of the 15th int. conf. on advanced information systems engineering (CAiSE’03) (EDER J and MISSIKOFF M, Eds.), p. 95-110, LNCS 2681, Springer-Verlag, Berlin. ROLLAND C, PRAKASH N and BENJAMEN N (1999) A multi-model view of process modeling. Requirements Engineering 4(4), 169-187. ROSEMANN M and GREEN P (2002) Developing a meta model for the Bunge-Wand-Weber ontological constructs. Information Systems 27(2), 75-91. SAEKI M (1998) A meta-model for method integration. Information and Software Technology 39(14), 925-932. SAEKI M (2003) Embedding metrics into information systems development methods: an application of method engineering technique. In Proceedings of the 15th int. conf. on


89


advanced information systems engineering (CAiSE 2003) (EDER J and MISSIKOFF M, Eds.), p. 374-389, LNCS 2681, Springer-Verlag, Berlin. SAEKI M and WEN-YIN K (1994) Specifying software specification & design methods. In Proceedings of the 6th int. conf. on advanced information systems engineering (CAiSE’94) (WIJERS G, BRINKKEMPER S and WASSERMAN S, Eds.), p. 353-366, Springer-Verlag, Berlin. SHEPARD T, WORTLEY C and SIBBALD S (1992) A visual software process language. Communications of the ACM 35(4), 37-44. SLOOTEN VAN K and BRINKKEMPER S (1993) A method engineering approach to information systems development. In Proceedings of the IFIP WG8.1 working conf. on information systems development process (PRAKASH N, ROLLAND C and PERNICI B, Eds.), p. 167-188, North-Holland, Amsterdam. SLOOTEN VAN K and HODES B (1996) Characterizing IS development projects. In Proceedings of the IFIP TC8, WG 8.1/8.2 working conf. on method engineering – Principles of method construction and tool support (LYYTINEN K, BRINKKEMPER S and WELKE R, Eds.), p. 29-44, Chapman & Hall, London. SOL H (1992) Information systems development: a problem solving approach. In Challenges and strategies for research in systems development (COTTERMAN WW and SENN JA, Eds.), p. 151-161, John Wiley & Sons, Washington. SONG X (1997) Systematic integration of design methods. IEEE Software 14(2), 107-117. SOWA J and Zachman J (1992) Extending and formalizing the framework for information system architecture. IBM Systems Journal 31(3), 590-616. STANDARDS AUSTRALIA (2004) Australian Standard – Standard metamodel for software development methodologies, AS 4651-2004, Australian Standards International, Sydney. SÖDERSTRÖM E, ANDERSSON B, JOHANNESSON P, PERJONS E and WANGLER B (2002) Towards a framework for comparing process modeling languages. In Proceedings. of the 14th intern conf on advanced information systems engineering (CAiSE’2002) (BANKS PIDDUCK A, MYLOPOULOS J, WOO C and OZSU T, Eds.), p. 600-611, Springer-Verlag, Berlin. TOLVANEN JP (1998) Incremental method engineering with modeling tools – Theoretical principles and empirical evidence. PhD Thesis, Jyväskylä Studies in Computer Science, Economics and Statistics, No. 47, University of Jyväskylä, Finland. VENABLE J (1993) CoCoA: A conceptual data modeling approach for complex problem domains. PhD Thesis, State University of New York, Binghampton, USA. VLASBLOM G, RIJSENBRIJ D and GLASTRA M (1995) Flexibilization of the methodology of system development. Information and Software Technology 37(11), 595-607. WELKE R (1977) Current information system analysis and design approaches: framework, overview, comments and conclusions for large – complex information system education. In Education and Large Information Systems (BUCKINGHAM R, Ed.), p. 149-166, NorthHolland, Amsterdam.

90


Application of Requirements Engineering Techniques to the Analysis of Civil Aviation Security Standards Régine Laleaua, Sylvie Vignesb, Yves Ledruc, Michel Lemoined, Didier Bertc, Véronique Donzeau-Gougee, Catherine Duboise and Fabien Peureuxf a

LACL, Université Paris12, Paris, France GET/ENST, Département Informatique et Réseaux, Paris, France c LSR/IMAG, Grenoble, France d ONERA/CdT/SAE, Toulouse, France e CEDRIC/CNAM, Paris, France f LIFC, Besançon, France b

Abstract The security of civil aviation, like many human activities, is regulated by a series of international standards and recommended practices. The quality of these documents is a prerequisite to effectively reach an acceptable security level. The EDEMOI1 project aims to integrate and apply several requirements engineering and formal methods techniques to analyze these standards. The project applies a two-step approach. In a first step, properties are extracted from the natural language standard and integrated in a domain model; a conceptual model of the underlying system is also elaborated. In a second step, the properties and the models are transformed into a formal model which will be analyzed by formal methods tools. The paper considers the standard produced by the ICAO (International Civil Aviation Organization) and focuses on the first step. We have chosen to apply existing requirements engineering techniques and the paper details the approach, presents several extensions/adaptations to the RE techniques, necessary to take into account the specific features of our application domain. Finally, we report on sample results on how formalization of some imprecise parts of the standard can improve its understanding. Keywords: civil aviation standard modelling, security goals, UML notation, formal notation

1

Introduction

The security of civil aviation is governed by a series of international standards and recommended practices that detail the responsibilities of the various stake-holders (states, operators, agents, ...). These documents give the specifications of various procedures and artifacts which implement security in airports, aircrafts and air traffic control. A key element to enforce security is the conformance of these procedures and artifacts to the specifications. However, it is also essential to ensure the consistency and completeness of the specifications. Standards and recommended practices are natural language documents (written in English or French) and their size may range from a few dozen to several hundred pages. Natural language has the advantage to be easily understood by a large number of stake-holders, but practice has also shown that it can be interpreted in several inconsistent ways by various readers. Moreover, it is very 1

The EDEMOI project is supported by the French National Action Concertée Incitative "Sécurité Informatique".


91

RE Techniques for the Analysis of Civil Aviation Security Standards

difficult to process automatically natural language documents in the search for inconsistencies. When a document has several hundred pages, it is very difficult to ensure that the content of some paragraph is not contradicted by some other paragraphs distant by several dozens of pages from the first one. The EDEMOI project (Edemoi, 2004) aims to provide an industrial methodology and tools to build models from these natural language documents, and use specialized tools to study their consistency. These models will also be used to build test cases to assess the conformance of a given implementation to the security standards. The project applies a two-step approach. In a first step, standards described in natural language are analyzed in order to extract security properties and to elaborate a conceptual model of the underlying system. The second step consists in analyzing and verifying the model by different kinds of formal methods. The paper considers a standard produced by the ICAO (International Civil Aviation Organization) and focuses on the first step. It describes and explains how we have applied existing requirements engineering (RE) methods, and specially goaloriented methods, to elaborate the model of the standard and presents a number of extensions/adaptations we have brought to them in order to take into account the characteristics of the domain. The use of these methods has allowed us to highlight imprecisions and/or deficiencies in the international standard and we show how the formalization of some imprecise parts of the document can improve its understanding. The paper is organized as follows. Section 2 presents the context of airport security and the different standards. Section 3 summarizes the objectives of the EDEMOI project. Section 4 presents the approach to analysis standards and the adaptation of RE techniques. Section 5 reports on sample results of problems we have encountered and how we can take profit of formal notations. The paper concludes with some remarks about the results and future directions.

2

Context: Airport Security

The airport is actually the place where passengers and their baggages are controlled before boarding an aircraft. Preventing dangerous objects from being brought on board an aircraft is a significant step to prevent acts of unlawful interference during a flight. Airport security controls are governed by local regulations that inherit from national and international standards. 1. At the international level, the International Civil Aviation Organization (ICAO) has produced an international standard and recommended practices related to security, called Annex 17 (A17, 2002). It is a very general document that must be followed by all countries members of the ICAO. 2.

At the European level (45 countries), the European Civil Aviation Conference (ECAC) is in charge of refining these rules into a more detailed standard and to organize the inspection of airports to check their conformance to the ECAC standards.

3.

At the national level, each country has to implement the international standards, taking into account national laws. In practice, it introduces a second level of refinement which makes the rules more precise and more constrained, and guides the design and processes of the airports.

92


Laleau, Vignes et al.

4.

At the airport level, the national and international regulations are put into practice, taking into account the specificities of the given airport. This is translated into "airport security programs".

All these documents are written in natural language, and it becomes difficult to assess the consistency of the whole. Moreover, since natural language leads to ambiguities, it may happen that two inspectors visiting the same airport at the same time reach contradictory conclusions on its conformance to the international regulations. In the EDEMOI project, we have naturally begun by studying the highest level of regulations, the international standard Annex 17 (A17, 2002). Another reason is that this standard is a public document when most other regulations have a restricted access status. The primary objective of Annex 17 is to define the obligations of each State, member of the ICAO. The document is rigorously structured. It is decomposed into five chapters: definitions of terms used in the document (airside, screening, security controls, ... ), general principles, organization of the member States, preventive security measures and management of response to acts of unlawful interference. Each chapter is organized as a sequence of numbered paragraphs, each of them defining an obligation. After a deep study and a consultation with the ECAC and the ICAO, we decided firstly to consider only chapters 1 and 4 which describe the actual procedures intended to prevent dangerous objects from being brought on board an aircraft, and secondly to focus on the cabin passengers, the cabin and hold baggage on their way from the check-in desk to the aircraft. We don't cover cargos, mail, movements of airplanes or other technical activities that take place in an airport.

3

The EDEMOI Approach

The EDEMOI project aims at defining an approach for the construction and analysis of a precise reference document that models and structures current standards and associated recommendations. This precise model can be exploited by the civil aviation authorities in several ways: 1. To improve the quality of the standards. 2.

To provide complementary documents to the standard for training and documentation purposes.

3.

To ease maintenance and evolution of standards by evaluating their impact on the essential security properties it enforces.

4.

To define a rigorous inspection process for the evaluation of airport conformity to the standard. This will reduce misinterpretations by the inspectors in charge of this evaluation.

5.

As a starting point for the definition of a facilitation process. The aim of this process is to accelerate passenger boarding and aircraft traffic, by reducing the number of controls while maintaining the same security level. This will decrease costs, and specially airplane tickets cost, and thus improve customer satisfaction.


93


Figure 1: The Stake-holders of the modelling process

In the computer science research community, formal specification and development methods (Abrial, 1996; Spivey, 1992) have been used for system and software modelling to construct precise models and conduct detailed consistency analyzes (Lamsweerde, 2000; Ledru, 1997; Lopez et al., 2002). They provide tools to check the consistency of models, or the consistency between a model and its refinement. They can also be used as a starting point for a test generation process (Bouquet et al., 2004). We believe that such methods can ground the construction of a precise model for airport security. Moreover, their application to this project is not straightforward technology transfer, and addresses the two following research challenges. 1. Modelling airport security standards corresponds to a real size and real world problem. It will be confronted to the limits of the modelling technique, in particular regarding its expressiveness. Therefore, it is important to clearly identify the limits of the modelling techniques, and hence the limits of the formal model. Another important concern is the validation of this real size/real world problem by experts of the civil aviation authorities. 2.

The model structure must distinguish between the expected security properties and the way these are implemented. Properties must be organized hierarchically and prioritized. One of the peculiarities of all the different standards and airport security programs is that they address airport security at several abstraction levels. For example, they feature general considerations (like the State obligations) but also very detailed descriptions (such as the size of passengers control equipment).

Unfortunately, formal methods and their associated mathematical language cannot be used alone. Firstly, formal methods give little guidance on constructing actual specifications. Secondly, formal models can only be read and understood by specialists. It does not really make sense to expect that readers and writers of aeronautics standards will be able to work directly with such models. Therefore, we propose a two-step approach which takes advantage of an intermediate graphical model to support the dialog between model engineers and certification authorities. Fig.1 shows how standards are produced by certification authorities and

94



read by model engineers. Model engineers can then produce a graphical model of the standard, which should be read by certification authorities in order to validate the model. The graphical model can then further be translated into a formal model which will be analyzed by model engineers. Errors found in the formal document can then be propagated at the level of the graphical model to allow the discussion between model engineers and certification authorities and, if needed the correction of the standard. The first step of the approach aims at analyzing the standard and producing graphical models by using a requirements engineering process. Once formal models will be available, we will start the second step that consists in their analysis as well as the generation of test cases which can be used by inspectors to evaluate the conformance of a given airport to the international standards. The paper focuses on the first step which is detailed in the next section.

4

Regulation Analysis

As already said, Annex 17 defines the obligations of each State member of the ICAO, related to the security of international civil aviation. It does not provide to States detailed procedures to be implemented in their respective national security programs. They are the matter of other documents. Consequently, Annex 17 determines a set of preventive measures that must be applied by States in order to meet security requirements that correspond to Non-Functional Requirements (NFR). Compared with the traditional core RE activities (Nuseibeh and Easterbrook, 2000), that are eliciting, modelling and analyzing, communicating, agreeing, evolving requirements, we directly begin by the modelling and analyzing requirements step. Indeed, the eliciting requirements step is rather reduced since we have only one document that precisely describes the requirements in the form of security properties to reach. From a methodological point of view, it seemed to us that a goal-oriented requirements process such as KAOS (Dardenne et al., 1993) or i* (Yu, 1997) was the more appropriate: identification of goals (security properties) and construction of the domain model and agent model associated to the goals. However, we need to adapt these methods to our environment. Indeed, the aim of our requirements process is very specific: it is not the elaboration of project specification that leads to the development and production of software. Our system (the airport) already exists and meets the functional requirements which it has been designed for (boarding passengers in aircrafts). What we want to do is to exhibit the security requirements described in the standards, to specify the system with formal languages, and to check that the specification satisfies these requirements by using formal proofs. Consequently the paper reports on the ability of goal-oriented RE methods, together with the necessary adaptations we have brought, to consider this unusual application domain. This is detailed in the first two subsections. The last subsection presents the model of the existing system, that is an abstract airport as it is described in Annex17. We have used UML diagrams as the representational schema for our models (requirements and system), augmented with a number of stereotypes which allow specific features of our project to be taken into account. Although these diagrams do not convey all the details of Annex 17, they help in structuring the models and provide a support for the discussion with certification authorities and further validation of the models. There are two reasons for using UML notations. The main one is that we want to take advantage of existing tools that translate UML diagrams into formal


95


notations, such as B (Laleau and Mammar, 2000) or Z (Dupuy et al., 2000), or that generate test cases from UML, B or Z notations (Bouquet et al., 2004). The second reason is that we have to adopt a common notation to represent both the requirements and the system models, with regard to the certification authorities. A first specification of a concrete airport, written in UML, has already been achieved (Carton, 2004) and we will need to reuse this specification in a next step of the project when we consider refinement links between the different standards. 4.1

Security Properties (goals) Identification The basic idea of the approach is to identify the main security properties and to analyze how these properties can be refined into sub-properties. The primary security property comes from article 2.1.1 in the second chapter of Annex 17, called "General Principles", and can be stated as follows: P1: Passengers, crew, ground personnel and the general public must be safeguarded against acts of unlawful interference To achieve this goal, Annex 17 prescribes a set of standards and recommended practices that each State member of the ICAO has to adopt and implement. In the framework of our project we have decided to consider the preventive security measures, described in Chapter 4, the objective of which is: 4.1 Each Contracting State shall establish measures to prevent weapons, explosives or any dangerous device which may be used to commit an act of unlawful interference, the carriage or bearing of which is not authorized, from being introduced, by any means whatsoever, on board an aircraft engaged in international civil aviation. This is translated by the following security property: P2: There are no unauthorized dangerous objects on board an aircraft. If there is an obvious causal relation between P2 and P1, it needs, however, to assume the two following hypotheses: H1: Acts of unlawful interference can only be committed with weapons, explosives or any other dangerous device. H2: Each State makes sure that security checks are performed in the originating state of an aircraft. The first hypothesis limits the kind of acts of unlawful interference by considering that only objects can be dangerous. It excludes acts coming from persons. For instance a specialist in martial art may potentially become dangerous but it is obvious that it would not be easy to detect such persons and, anyway, it is not the aim of civil aviation authorities. The second hypothesis concerns aircraft with transit stops. At a transit stop, an aircraft is considered to be secure, otherwise, it would require to control the aircraft again. However, if a state has doubts about verifications carried out by

96



the originating state of an aircraft, it can define specific measures. Note that whereas H2 is clearly stated in the document, H1 is only implicit and has been stated after discussions with the ICAO. P2

Hy pothesis 1 : Acts of unlawf ul interf erence can only be committed with weapons, explosiv es or any other dangerous dev ices.

A17-4.1

P2.1 A17-4.3 PassengersAndCabinBaggage P4 A17-4.3.1

A17-4.4 HoldBaggage

P5 A17-4.3.2

P5Transf er

P2.2

P6 A17-4.3.3

P23 A17-4.6.6

P5Transit

Figure 2: Extract of the security properties graph

Annex 17 distinguishes between six different situations that can lead dangerous objects to be introduced on board an aircraft (passengers and their cabin baggage, hold luggage, ground persons who can access the aircraft, ...) and specifies a list of numbered measures for each situation. This structuring has helped us to elaborate a tree that decomposes property P2 into more specific sub-properties, so that a leaf level sub-property corresponds to an elementary numbered measure. We have identified 22 leaf level sub-properties. At a given level in the tree, a property is related to a set of sub-properties by a refinement relation. That means that satisfying all the subproperties is a sufficient condition for satisfying the property. This tree can be considered as a special kind of NFR graphs (Mylopoulos et al., 1992; Chung, 1993) which are "and/or" graphs that decompose non functional requirements from vague abstractions to more concrete descriptions. Our tree is only a "and" graph that considers only security requirements. From a graphical point of view, we have used a UML class diagram to describe the tree, to have a uniform representation, whatever the model. Each security property is modelled by a class, labelled by the stereotype and the causal relations are expressed by navigable associations, labelled by the stereotype . To ensure traceability between the diagram and the document, an attribute is assigned to each security property class: it refers to the paragraph or section of Annex 17 where the property is stated. For example, Fig.2 considers the sub-diagram modelling the situation concerning passengers and their cabin baggage and corresponding to property P2.1. It is refined by four elementary properties. We detail the first two ones, properties P4 and P5, because they will be used in the following sections of the paper. Security property P4 refers to paragraph 4.3.1 of Annex 17 whereas P5 refers to paragraph 4.3.2.


97


P4: Originating passengers and their cabin baggage must be screened prior to boarding an aircraft. P5: Transfer and transit passengers and their cabin baggage are subjected to adequate security controls prior to boarding an aircraft. This property has been decomposed into two sub-properties P5Transfer and P5Transit which allow us to be more precise in the elaboration of the domain model (see next section). In conclusion, we can say that the specific architecture of the standard has facilitated the properties identification step so that the obtained tree practically reflects the structuring of Annex 17, which will certainly make easier the validation of our models with the certification authorities. In Section 5, we present the main problems we have encountered during this step. 4.2 Domain Model of the Security Properties Once the security properties have been identified, we elaborate a domain model for each of them. It specifies the objects, their relationships and their attributes which are relevant to formulate a security property. An object can be an entity or an agent. An agent is an active component, such as a human or an organization, that plays a role towards the satisfaction of some security properties. For example, Fig.3 describes the objects derived from properties P4 and P5. They are represented by the UML light-filled classes. The ordinaryPassenger class represents all the usual passengers2 embarked in an aircraftCabin of an aircraft. A passenger can own (association own) cabinLuggage. A cabinLuggage can be carried by a passenger but also by another cabin person (a crew member or a pilot). Three kinds of passengers (orginatingPassenger, transitPassenger, transferPassenger) are distinguished in order to be more faithful to the properties. The model shows that originating passengers have a boolean attribute screened, while transit and transfer passengers have a controlled attribute. P4 and P5 require that these attributes are set to true for passengers embarked in an aircraft. This could be easily expressed using OCL (Warmer and Kleppe, 1999). As far as possible, security concerns are integrated in the domain model in the following way. Even if a security property involves a number of domain objects, there is always a single object which plays a central role and which is the target of the security property. It is called subject matter or topic in (Cysneiros and Leite, 2004). For instance, the target of P4 and P5 is an aircraft. This object is depicted in the UML class diagrams as a stereotyped class and linked to the class which it is an instance of. By propagating the instantiation mechanism on the domain model from this object, we obtain a snapshot that determines all the objects affected by a given security property. The aircraft defines an aircraftCabin, a set of ordinaryPassengers with their cabinLuggage. In Annex 17, the security target is generally an aircraft, but it can be for 2

There exist special categories of passengers such as passengers obliged to travel because of judicial of administrative reasons, law enforcement officers, ...

98



be for example the storage area of an airport, where mishandled baggage is kept. In this context, a security property should be linked to the more relevant objects of the snapshot defined by its target. Depending on whether the security property concerns objects of a same class or objects of different classes linked by an association, we define an association or an association class, stereotyped by . In Fig.3, the P4 security property class is linked to the association own defined between the classes originatingPassenger and cabinLuggage. CabinLuggage screened : Boolean controlled : Boolean 0..n

0..n

0..n

P4 A17-4.3.1

/own 0..1

P5Transit

originatingPassenger

/own

screened : Boolean 0..1 P2.1 A17-4.3

transitPassenger controlled : Boolean

/own

P5Transfer

0..1 aircraftCabin

ordinaryPassenger

transferPassenger controlled : Boolean

/embarked 0..1 0..n 1..n

aircraft

any:aircraft

Figure 3: UML diagram for passenger checks

Generally in RE methods (Letier and Lamsweerde, 2002), an agent model captures responsibility links between agents and objects. Up to now, we did not feel a need to model agents apart from the domain model, because the very nature of Annex 17 is to define the obligations of each State member of the ICAO. Thus there is a single legislative agent, a State, who is legally responsible for the application of all the security properties. However, some articles refer to another kind of agent, aircraft operators, and their obligations, but it still remains under the responsibility of the State from which aircraft operators provide services. For example, in paragraph 4.4.3, one can read: 4.4.3 Each Contracting State shall establish measures to ensure that operators when providing service from that State do not transport the baggage of passengers who are not on board the aircraft unless that baggage is subjected to appropriate security controls which may include screening. The corresponding security property is:


99


P10: There is no baggage in the baggage hold whose owner is not on board the aircraft unless that baggage is controlled and possibly screened. Figure 4 describes the domain model of property P10. The class aloneHoldLuggage contains hold luggage that do not belong to anybody, which implies a constraint on the association HL_ownership. The security target of the property is an aircraft that determines an aircraft operator. Again, we have introduced two new kinds of stereotyped class to model the agents: and , as it is shown in Fig.4. For the security property P10, an aircraftOperator plays the role of (stereotype ) who is responsible for the application of the security property (stereotype ), under the control (stereotype ) of a contractingState who remains the . It is sure that this agent model will be significantly extended when we will take into account the other standard documents, and that, in particular, we will introduce "operational" agents who carry out the procedures established to implement the security properties.

any:contractingState any2:aircraftOperator

any:aircraft

chartering

aircraftOperator

aircraft 1

1..n

1..n P10 A17-4.4.3

aircraftLuggageHold

0..1 container

0..n aloneHoldLuggage controlledPossiblyScreened : Boolean

HoldLuggage embarked : Boolean 0..n /own 0..1 cabinPassenger

Figure 4: UML diagram for different kinds of agent

100



4.3 Conceptual Model of the Regulation Context In parallel with the elaboration of the security requirements model, we need to model all the elements (physical characteristics, configuration, material, personal) and the procedures, the application of which is necessary for the safety or regularity of international air navigation. They constitute what we can call the existing physical system. More precisely, we consider different levels of the existing system. At the Annex 17 level, the system is obviously abstract: it corresponds to an abstract airport with the characteristics and the functionalities described in Annex 17. On the other hand, at the airport implementation level, the system is completely concrete: it takes into account the specificities of each airport, such as the actual buildings configuration, the number of ground agents or the number of screening points and their layout. The abstract model of the system will be used to check that Annex 17 is consistent, i.e. that the described procedures are conformed to the security properties. The static aspect of the system is specified using a UML class diagram. It is obtained by merging all the class diagrams of the security properties and by incorporating additional information that comes from other chapters of Annex 17. Figure 5 is an extract that represents all the objects which can be in an aircraft and to which they can belong to. An object that is inside an aircraft can be either in an HoldLuggage or a cabinLuggage or carried by a cabinPerson. In addition we have defined integrity constraints because of the existence of association cycles. Procedures are defined as operations in the relevant classes. At this abstract level, there are only two categories of operations: loading a luggage in the hold of an aircraft and loading someone in the cabin. For instance, operation loadInCabin of the class cabinPerson is described in natural language as: loadInCabin(AC : aircraftCabin, CP : cabinPerson) precondition : if there are dangerous objects inside the cabin luggage of CP or carried by CP then they are authorized postcondition : CP is loaded in AC (embarked = true) This operation is further refined to take into account the different kinds of cabin persons and the different procedures which they are subjected to in order to embark in an aircraft cabin. To improve traceability with the domain models of the security properties, we have associated to each operation the security property that it must establish. For instance, the operation loadInCabin of the class cabinPerson must establish property P2. In conclusion of section 4, existing requirements engineering approaches have up to now proved to be rather well adapted to our project. We have defined new elements or specialized existing ones to take into account the characteristics of airport security requirements, such as the notions of security target, responsible authority and responsible organization. These concepts have been introduced in UML diagrams thanks to the definition of stereotypes.


101


aircraft

0..n

0..1

dangerousObjects authorized : Boolean

objects

objectInsideAircraft 1..n 1..n

1..n 1..n

/contain

/contain

aircraftLuggageHold 0..1 container 0..n

carry

0..1 CabinLuggage 0..1

0..n

HoldLuggage

/own

embarked : Boolean loadInHold(AL : aircraftLuggageHold, HL : HoldLuggage) /own

0..n

1 0..1

0..1

cabinPerson embarked : Boolean loadInCabin(AC : aircraftCabin, CP : cabinPerson)

embark ed 1..n aircraftCabin

0..n

0..1 pilotInCommand

cabinPassenger

crew

armedPassenger

obligedPassenger

ordinaryPassenger loadInCabin(AC : aircraftCabin, OP : ordinaryPassenger)

originatingPassenger screened : Boolean loadInCabin(AC : aircraftCabin, OP : originatingPassenger)

Figure 5: UML diagram for an abstract airport (extract)

A first version of the requirements and system models is achieved and has been validated by the members of the project who belong to the ONERA3 laboratory. On the other hand, the ICAO has validated the process that we have defined and that is described in Fig.1. Indeed, experts are actually able to read and understand easily the different UML diagrams, without being obliged to understand the formal models. The next step is to validate the models by the ICAO and the ECAC.

5

Sample Results

Constructing the requirements and system models leads to a deep study of the standard and often reveals potential inconsistencies. In this section, we highlight some problems we have encountered and how, even without formalizing completely the standard, a first partial formalization can help to solve them. We focus on the notion of authorization which has a significant importance in regulation texts.

3

ONERA : French Aeronautics and Space Research Center

102



5.1 Ambiguity of natural language Paragraph 4.1 (see its wording page 6) is the main paragraph of chapter 4 because it states what are the objectives of the preventive security measures. However it appears to be ambiguous. The point is about interpretation of the rider "the carriage or bearing of which is not authorized". That could mean either "the carriage or bearing of weapons, explosives or any other dangerous devices is neither authorized", or "weapons, explosives or other dangerous devices may not be introduced on board an aircraft unless their carriage or bearing is authorized". It is not clear at all which is the good interpretation, even if the latter seems more right than the former. We have carried out a survey among a group of native speakers of English that confirms the ambiguity of paragraph 4.1. Most of them declared that it is the context of the sentence that allowed them to make a distinction between the two interpretations and to choose the second one. The French translation is more explicit, because it introduces a conjunction "et" saying that the authorization is a supplementary condition for the carriage or bearing of weapons, explosives or other dangerous devices. Formalization of both interpretations of paragraph 4.1 helps to understand the different meanings. We assume that there is a set of all the objects, and three subsets: weapons, explosives and dangerousDevices. For the second interpretation, we also need an attribute authorization which indicates if an object is given an authorization or not. The first interpretation is defined by the following subsets: unauthorized_carriage1 = weapons ∪ explosives ∪ dangerousDevices while the second one is defined by: unauthorized_carriage2 = {object | object ∈ weapons ∪ explosives ∪ dangerousDevices ∧ authorization(object) = no} Because the notation is formal, a question immediately arises about the domain of function authorization. The domain could be the set of all the objects or more specifically the set of weapons, explosives and dangerous devices. It seems to us more realistic to choose the second case, so: dom(authorization) = weapons ∪ explosives ∪ dangerousDevices Questioned about this ambiguity, the ICAO answered that it agrees with the problem but that the second interpretation is of course the correct one. This is determined by the context of the regulation. In fact, it appears that the regulation is not a close world and that the general context must be taken into account. 5.2 Multiple meanings of authorization Chapter 4 is only composed of twenty-height paragraphs, and the word "authorized" (or unauthorized) is used inside nine of them. Moreover, it qualifies various names, such as "carriage or bearing is not authorized", "unauthorized persons", "unauthorized articles", "hold baggage authorized for carriage", "unauthorized interference", "authorized person", "special authorization". A problem is then to determine if every occurrence refers to the same meaning, or if some differences can happen. As an example, we propose to focus the exercise on the notion of objects which are authorized


103


or not authorized for carriage on board aircraft. The same exercise could be done for the persons. To enlarge the context, let us take other paragraphs of this chapter that use the notion of "authorization". For example, in paragraph 4.3.2, one can read: 4.3.2 Each Contracting State shall ensure that transfer and transit passengers and their cabin baggage are subjected to adequate security controls to prevent unauthorized articles from being taken on board aircraft engaged in international civil aviation operations. What exactly does unauthorized articles mean? First, notice that "unauthorized" qualifies "articles", while in item 4.1, it qualifies "carriage or bearing of weapons, explosives or any dangerous devices". So, the questions are: is the word "articles" roughly equivalent to "weapons, explosives or any dangerous devices"? is the word "articles" equivalent to any "objects"? A step further, paragraph 4.4.7 is written with another form: 4.4.7 Each Contracting State shall establish measures to ensure that aircraft operators when providing a passenger service from the State transport only hold baggage which is authorized for carriage in accordance with the requirements specified in the national civil aviation security programme. This paragraph speaks about "authorized hold baggage". One can infer that "hold baggage", or their content, is of the same nature as "articles". Here again, the point is the use of "authorized". We cannot expect that the meaning is the one used in the second interpretation of the first paragraph because in that case, an aircraft can only transport authorized weapons, explosives or other dangerous devices. So, clearly, the word "authorized" means something larger, probably a set containing the ordinary objects and the authorized (and dangerous) objects above. Again, we present the interest of formalizing. For paragraph 4.3.2, the question is again about the domain of the authorization function. It is reasonable to consider that unauthorized articles are the same as the objects, the carriage or bearing of which is not authorized. Following the second interpretation of 4.1, we take the set below for the unauthorized articles: unauthorized_articles = unauthorized_carriage2 For paragraph 4.4.7, we have to determine the meaning of word "authorized" with respect to the one of "unauthorized", already formalized. As informally guessed, it is not the set of weapons, explosives or any dangerous devices where the function "authorization" returns "yes". The notion of "authorized hold baggage" should be here the complement of unauthorized_articles with respect to the set of all the objects, that is to say: authorized_hold_baggage = {object | (object ∈ objects ∧ object∉ weapons∪ explosives ∪ dangerousDevices) ∨ (object ∈ weapons ∪ explosives ∪ dangerousDevices ∧ authorization(object) = yes)}

104



Two conclusions can be drawn from the partial formalization described in this section. First, a formal specification leads to ask very precise questions about the exact meaning of words that even the ICAO and ECAC specialists have not thought of. Second, some words appear to be ambiguous in the text but we need to take into account the general context of the regulation to remove this ambiguity. Thus, validation with the certification authorities is necessary.

6

Conclusion

The 9/11 attacks (9/11 report, 2004) have revealed the need for enhanced civil aviation security. One of the ways to improve security is to build on high quality standards. The most important results of the paper are twofold. First we have shown that existing RE methods, mainly dedicated to build software, can be applied to model standard. We have adopted a goal-oriented method, composed of three steps. The goals described in the standards are exclusively security properties. The first step consists in building the hierarchy of properties based on a refinement relation. Then a domain model is elaborated for each property. Finally, agents responsible for the application of security properties are determined. The second result relies on the definition of a set of extensions to the classical goal-oriented RE method to take into account our specific situation, more precisely the characteristics of airport security requirements. We have used UML notations as the representational view of our RE models, and the new concepts are naturally introduced by the definition of stereotypes. We have also shown on a typical example how formal notations can help ambiguities and incompleteness of the standard to be solved. We are currently studying the complete formalization of Annex 17 by using different formal methods and we also plan to consider the other standards in order to detect conflicts between standards. SAFEE (Safee, 2004) is another project, funded by EU's Sixth Framework Programme for RTD (FP6), which aims to apply similar methods to security but during the flight. However, we do not have more details since up to now, no public papers are available. Finally, we believe that our approach can be applied to several application domains in the aeronautics industry, or more generally in any transportation industry where security or safety are built on international standards.

References 9/11 report (2004). The 9/11 Commission Report - Final Report of the National Commission on Terrorist Attacks Upon the United States. http://www.gpoaccess.gov/911/. A17 (2002). Annex 17 to the Convention on International Civil Aviation - Security Safeguarding International Cicil Aviation against acts of unlawful interference. J.R. Abrial (1996). The B-Book. Cambridge University Press. F. Bouquet, B. Legeard and F. Peureux (2004). A constraint solver to animate a B specification. Int. Journal on Software Tools for Technology Transfer, Springer Verlag, Vol. 6. O. Carton (2004). Modélisation de la sûreté dans le transport aérien. Master thesis CNAM, ONERA, Toulouse, France. L. Chung (1993). Dealing with Security Requirements During the Development of Information Systems. Proceedings CAiSE '93, 5th Int. Conf. Advanced Information Systems Engineering, Lecture Notes In Computer Science, Vol. 685, Paris, France.


105


Cysneiros,L.M. and Leite, J.C.S.P. (2004). Non-Functional Requirements: From Elicitation to Conceptual Model. IEEE Transactions on Software Engineering, vol.30, no5, pp. 328—350. Dardenne, A., Lamsweerde, A. v., and Fickas S. (1993). Goal-Directed Requirements Acquisition. Science of Computer Programming, vol.20, pp. 3--50. S. Dupuy, Y. Ledru, and M. Chabre-Peccoud (2000). An Overview of RoZ : a Tool for Integrating UML and Z Specifications. Proceedings CAiSE'2000, 12th Int. Conf. on Advanced Information Systems Engineering, Lecture Notes In Computer Science, Vol. 1789, Paris, France. Edemoi (2004). EDEMOI project web site, http://www-lsr.imag.fr/EDEMOI/. R. Laleau and A. Mammar (2000). An Automatic Generation of B Specifications from Precise UML Notations for Data Intensive Applications. Proceedings ASE'2000 : International IEEE Conference on Automated Software Engineering, Grenoble, France. Axel van Lamsweerde (2000). Formal specification: a roadmap. In A.Finkelstein, editor, ICSE - Future of SE Track, pages 147--159, ACM Press. Y. Ledru (1997). Specification and animation of a bank transfer using KIDS/VDM. Automated Software Engineering, vol.4 (1) pp. 33--51. E. Letier and A. van Lamsweerde (2002). Deriving Operational Software Specifications from System Goals. Proceedings FSE'10 - 10th ACM S1GSOFT Symp. on the Foundations of Software Engineering, Charleston, USA. N. Lopez, M. Simonot and V. Viguié Donzeau-Gouge (2002). A methodological process for the design of a large system: two industrial case-studies. Proceedings FMICS'02 - Formal Methods for Industrial Critical Systems. J. Mylopoulos, L. Chung, E. Yu, and B. Nixon (1992). Representing and Using NonFunctional Requirements: A Process-Oriented Approach. IEEE Transactions on Software Engineering, vol.18, no.6, pp. 483--497. Bashar Nuseibeh and Steve Easterbrook (2000). Requirements Engineering: a roadmap. In A.Finkelstein, editor, ICSE - Future of SE Track, pages 35--46. ACM Press. SAFEE (2004). SAFEE targets on-aircraft security. http://europa.eu.int/comm/research/aeronautics/info/news/article_681_en.html. J. Spivey (1992). The Z notation - a reference manual (second edition). Prentice Hall. E. Yu (1997). Modeling and Reasoning Support for Early-Phase Requirements Engineering. Proceedings of the 3rd IEEE International Symposium on Requirements Engineering (RE'97). Jan. 6-8, Washington D.C., USA. pp.226-235. J. Warmer and A. Kleppe (1999). The Object Constraint Language. Addison-Wesley.

106


A New Requirements Template for Scientific Computing Spencer Smith and Lei Lai Computing and Software Department, McMaster University

Abstract This paper presents a new template for writing requirements specifications for scientific computing software, using the following characteristics to guide the design: i) only one user viewpoint needs to be considered for specifying the physical model; ii) assumptions can be used to distinguish between models and a strong coupling exist between the assumptions and the functional requirements; iii) a high potential exists for reuse of the functional requirements; iv) the hierarchical nature of goals, theoretical models and instanced models facilitates change management; and, v) documenting and validating continuous mathematics needs to be supported. One significant change from the existing templates is for the functional requirements, which are split into two main sections: “Problem Description” and “Solution Characteristics Specification.” The template introduces a new traceability matrix to facilitate future modifications and it explicitly addresses nonfunctional requirements for the accuracy of the input data, the sensitivity of the model, the tolerance of the solution and the solution validation strategies. Keywords: Domain-Specific Requirements Engineering, Combination of Templates, Scientific Computing

1

Introduction

Requirements analysis and documentation techniques can be used to improve the quality of scientific computing software, where scientific computing is defined as the use of computer tools to analyze or simulate mathematical models of real world systems of engineering or scientific importance so that we can better understand and predict the system’s behaviour. Unfortunately requirements documentation in scientific computing is often nonexistent or incomplete because of a lack of an accepted systematic approach. To encourage a systematic approach one generally accepted technique from requirements engineering is to adopt and follow a requirements template. However, a survey of existing templates shows that the particular needs of scientific computing systems are not met by the current options. This paper addresses this shortcoming by presenting a new template that has been tailored to meet the special characteristics inherent in scientific computing software. The first section below provides background information on scientific computing, the advantages of requirements documentation in this context, and a review of existing requirements templates. The next section explains that the existing templates do not address the specific characteristics of scientific software that distinguish it from other classes of applications. Section 4 presents the template itself by first showing the proposed table of contents and then explaining the intent of each of the sections. The new template combines features of existing templates as well as adding some new features. Sections 5 and 6 discuss future work and concluding remarks, respectively.


107

Requirements Template for Scientific Computing

2

Background

The following five-step procedure is typically used to solve analysis problems in scientific computing: i) define the problem; ii) create a mathematical model by applying proper assumptions; iii) identify a computational method; iv) refine and implement a solution; and, v) validate the solution. If a requirements stage is made part of the development process for scientific software, then the first two steps above will correspond to the stage of requirements gathering, analysis and documentation. In the first step the problem should be clearly, completely and unambiguously defined. The second step involves using simplifying assumptions to develop a model of the real world. In scientific computing the model often consists of governing ordinary or partial differential equations together with boundary conditions and/or initial conditions and a set of closure equations. Although the size and complexity of scientific computing problems are constantly growing, the approach to problem definition, model development and documentation is often done in an ad hoc manner. Moreover, the nonfunctional requirements that would provide information on such important decisions as required accuracy, precision, efficiency, etc., are typically neglected. Unfortunately requirements for scientific computing problems are rarely systematically gathered, analyzed and documented, even though the existence of a complete and consistent requirements document can lead to better decisions for improving such software qualities as reliability, usability, verifiability, maintainability, reusability and portability. One example of how requirements improve quality is that the reliability of software can only be accurately judged when the validation step (v in the above list) has an unambiguous statement of the behaviours and qualities that the software is required to satisfy. Besides enabling software validation, a requirements document provides many other advantages during the lifecycle of a software project (IEEE, 1998; Sommerville and Sawyer, 1997). For instance, a software requirements specification (SRS) reflects the mutual understanding of the problem to be solved between the requirements analyst and the client and it provides a starting point for the software design phase. Other advantages that requirements documentation brings that are of particular value to scientific computing software include the following, as discussed in Smith et al. (2005): i) reducing ambiguity; ii) clearly identifying and documenting the range of model applicability; iii) clearly identifying and documenting the assumptions that simplify the real world for modelling purposes; iv) increasing confidence that all special cases have been considered; and, v) encouraging the analyst to scrutinize their problem in advance of designing the computational software. Given the advantages that requirements documentation can provide, it is surprising that a literature review on the application of software engineering methodologies to scientific computing problems shows little on this topic. The research usually focuses on the design and implementation of the software and does not address how to improve the quality from the requirements level. One exception to neglecting the requirements phase is a requirements analysis of data parallel applications (Gerlach, 2002). Another exception documents the requirements of models of physical phenomena (Kreyman and Parnas, 2002) using tabular expressions. However, this approach to documenting physical phenomena does not entirely match the needs of scientific computing because Kreyman and Parnas (2002) use ideas that were first developed for real-time embedded systems, which have different characteristics than

108


Smith and Lai

scientific computation systems. Moreover, Kreyman and Parnas (2002) allow the numerical methods, which are essentially implementation decisions, to be encompassed into the requirements documentation, which contradicts with the principle that requirements should address “What” is required, but not “How” to achieve it. The scientific computing literature apparently does not provide many details on a methodology for requirements documentation, so the next step is to determine what ideas can be borrowed from the field of requirements engineering. One idea from requirements engineering that satisfies the current goal of encouraging a systematic procedure for requirements documentation is the common practise using of a requirements template, where the template provides a frame of reference, identifies needed information, and suggests an order of presentation for the requirements. An advantage of using requirements templates, as discussed in Sommerville and Sawyer (1997), is increasing the productivity and adequacy of an SRS, because a wellorganized format for the document acts as a checklist for writers of the SRS, which reduces the chances of omitting information. The template also has an important advantage for scientific computing in that it facilitates the communications among various SRS users, which in the scientific context will be researchers, software developers, physical modellers, computational scientist, etc. A template seems ideal for documenting scientific computing problems, but it is difficult to directly adopt an existing template. Although there are several requirements templates that are designed for general purposes and contain good advice on how to write requirements and how to avoid problems (Heninger, 1980; NASA, 1989; Robertson and Robertson, 1999; IEEE, 2000), these templates are not usually used without modifications that depend on the application. Most templates to date focus on business applications and real-time systems. Although the existing templates provide an excellent starting point, they do not address all of the issues of importance for scientific computation problems, as discussed in the next section.

3

Why a New Template?

Differences between the characteristics of scientific computing software and other types of systems suggest that a new template needs to be developed that is specific to scientific software. These characteristics are enumerated below. Although some of these characteristics can also occur in other classes of software, they are considered to be important enough in scientific computing to guide the design of the new requirements template. 3.1 One User Viewpoint for the Physical Model The specification of the mathematical model in scientific computing software allows for an important simplification over some other classes of software because it does not have the variety of viewpoints for the functional requirements that are evident in many other software systems. Unlike banking software, or a library database, which have many different stakeholders and other software/hardware systems, there is only one user viewpoint for the physical model in scientific software. (Although the functional requirements for the physical model have one viewpoint, the nonfunctional requirements will certainly change depending on the user viewpoint.) Only one viewpoint is necessary for the physical model because there is only one correct statement of the problem physics. The one user viewpoint allows application of the prin-


109


ciple of separation of concerns so as to focus on making the documentation of the mathematical model self-contained. As mentioned in Section 3.3 below, the computation may be embedded in a larger system context, but in the context of the five steps outlined at the beginning of Section 2, the physical model need only be considered from one viewpoint. Although there is considerable complexity inside scientific software, from the external viewpoint the model is relatively simple. Although differing in the details, the solution of a scientific computing problem can be effectively abstracted following the simple sequential scenario: input information, perform calculations, output the results. With only one viewpoint to consider, the functional requirements do not have to specify many partial viewpoints, or the complex relationships associated with concurrency. 3.2 Assumptions Distinguish Models To build any model of the real-world it is necessary to introduce simplifying assumptions, such as assuming small distances, angles, or forces may be neglected in favour of larger distances, angles or forces. In scientific computation it is often the differing assumptions that distinguish one piece of work from another. For instance, Smith and Stolle (2003) summarize research on polymer film casting by distinguishing papers based on their simplifying assumptions, such as whether the problem is modelled as 1D, 2D or 3D, or whether the problem is isothermal or nonisothermal, or whether the polymer is assumed viscous or viscoelastic. Often the quality of the model depends on how reasonable the simplifying assumptions are. Assumptions also play a crucial role in scientific computing because a strong coupling exists between the assumptions and the physical model. Given the importance of assumptions, the SRS template should clearly show how they will be documented and justified. Other researchers cannot judge a model, reproduce its results, or improve on it, without knowing the assumptions that were made and the reasoning behind those assumptions. 3.3 High Potential for Reuse A template for scientific software should support the reuse of functional requirements, where the functional requirements correspond to the problem description and the mathematical model. The functional requirements for scientific software have a high potential for reuse because the laws on which they are based are almost universally accepted and slow to change. An example of a requirement that is unlikely to change is that a body at rest shall satisfy force equilibrium. The stable functional requirements should be separated from the nonfunctional requirements, which will change depending on the context in which the software is to be used. For instance, educational software and a safety critical real-time system may both have identical functional requirements based on the same mathematical model, but the educational software will emphasize nonfunctional requirements for ease of use and portability, while the scientific software that is employed as part of a safety critical control system will likely emphasize accuracy and speed of calculation over all other considerations. The documentation on the mathematical model of the scientific computation should be self-contained so that it can be embedded in a larger system, no matter the context of the other system. If a library of SRS’s for scientific software can be built, then people designing a large project will be able to choose the appropriate models from the library and incorporate them into their project.

110


Smith and Lai

3.4 Hierarchical Nature Facilitates Change In software engineering, one of the most important design principles is to design for change. The preceding section described how the document should be designed to allow for changes in the nonfunctional requirements; the functional requirements themselves should also be designed for likely changes. In the case of the functional requirements the most likely changes are adding or subtracting goals, modifying the theoretical model, or modifying the instanced model. In this decomposition goals are defined as the objectives that the software should achieve; theoretical models are the mathematical equations used to solve the problem described in the problem domain; and, instanced models, which refine the theoretical models, express the problem in sufficient detail so that it can be solved. The sequence from goals to theoretical and instanced models corresponds to a decreasing level of abstraction. As an example, the abstract goal might be to solve for unknown forces and the associated theoretical model that is selected may be to use the principle of equilibrium. The theoretical model will be refined further to an instanced model when decisions are made about a specific coordinate system, sign convention, etc. Ideally the requirements template should support reuse of the abstract goals with different theoretical models. For instance, the theoretical model of having the forces of an unmoving body sum to zero could be changed to instead use the principle of virtual work. Similarly a specific theoretical model that was refined into an instanced model using a Cartesian coordinate system could be refined into a different instanced model using a polar coordinate system. In both cases the “higher-level” requirements could be reused. It should also be possible to reuse “lower-level” requirements in a different context, such as using the same theoretical model to satisfy different goal statements. For instance, the same theoretical model of equilibrium could be employed to solve problems where the goal is to find internal forces in a beam or internal stresses inside a glacier. 3.5 Continuous Mathematics Poses a Challenge Scientific software differs from most other software by nature of the fact that the quantities of interest are continuous, as opposed to discrete. The variables that are to be solved for are usually continuous in nature, such as velocity, displacement, temperature, pressure, concentrations, etc. Unfortunately, the formal techniques developed for specifying requirements generally focus on discrete mathematics, which mean the techniques will have to be modified for scientific software requirements specification. Moreover, the SRS template should assist with the challenge of validating the numerical results because most scientific computing problems cannot be solved exactly. When it comes to validation the question of how much error can be tolerated must be addressed. Moreover, since the true solution is often unknown, the specification must address the requirements that must be satisfied to consider a result correct.

4

The New Template

The proposed template is organized in a hierarchical format with nine main sections, as presented in the table of contents shown in Figure 1. The majority of the initial sections are inspired by the IEEE Standard 830 (IEEE, 1998), while the subsection “Nonfunctional Requirements” in the section “Specific System Description” and the section “Other System Issues” mainly come from the Volere Requirements Specifica-


111


tion Template (Robertson And Robertson, 1999). The section “General System Description” comes from both of the previously mentioned sources. The subsections “Problem Descriptions” and “Solution Characteristics Specification” in the section “Specific System Description” are unique propositions of the current work. The template also introduces a systematic approach to manage changes in a scientific computing SRS through a newly defined traceability matrix, which is documented in SRS Section 6. A description of the important sections of the new SRS template are provided in the subsections that follow. Further details on the template presented in this section can be found in Lai (2004). 1. Reference Material: a) Table of Contents b) Table of Symbols c) Abbreviations and Acronyms d) Index of Requirements 2. Introduction: a) Purpose of the Document b) Scope of the Software Product c) Organization of the Document 3. General System Description: a) System Context b) User Characteristics c) System Constraints 4. Specific System Description: (a) Problem Description: i) Background Overview, ii) Terminology Definition, iii) Physical System Description, iv) Goal Statements (b) Solution Characteristics Specification: i) Assumptions, ii) Theoretical Models, iii) Data Definitions, iv) Instanced Models, v) Data Constraints, vi) System Behaviour (c) Nonfunctional Requirements: i) Accuracy of Input Data, ii) Sensitivity of the Model, iii) Tolerance of Solution, iv) Solution Validation Strategies, v) Look and Feel Requirements, vi) Usability Requirements, vii) Performance Requirements, viii) Maintainability Requirements, ix) Portability Requirements, x) Security Requirements 5. Other System Issues: a) Open Issues b) Off-the-Shelf Solutions c) New Problems, d) Waiting Room 6. Traceability Matrix 7. List of Possible Changes in the Requirements 8. Values of Auxiliary Constants 9. References Figure 1: Proposed Requirements Template

112


Smith and Lai

4.1 Reference Material (SRS Section 1) The requirements document should be organized as a reference as well as being a specification of the system. The information in the SRS is recorded in this section in a form that allows easy reference throughout the project. The information includes a table of symbols to provide a quick reference for the symbols specifically defined in the SRS. A table of symbols is invaluable in scientific computing due to the variety of symbols used and the fact that in a different scientific context the same symbol may have a different meaning. As an example, the same symbol σ is used to represent conductivity, stress, the Stefan-Boltzmann constant for radiative heat transfer, the standard deviation, etc. 4.2 General System Description (SRS Section 3) The purpose of this section of the template is to provide general information about the system so the specific requirements in the next section will be easier to understand. Following the design principle that the mathematical model should be easy to reuse, as discussed in Section 3.3, the general system description section is designed to be changeable independent of changes to the functional requirements documented in the specific system description. The general system description accounts for the specification details that change from one system context to another. The general system description should include an overview of the system context that defines the boundaries between the product to be built and the people, organizations, other products and pieces of technology that have a direct interface with the product, such as system interfaces (which describe adjacent system), user interfaces, and software interfaces. The system context subsection also places the product into perspective with other related products. If the product is independent and totally selfcontained, this should be stated here. If the SRS defines a product that is a component of a larger system, as frequently occurs, then this subsection should relate the requirements of that larger system to the functionality of the software and should identify interfaces between that system and the software. Stakeholder characteristics are also summarized within the general system description so as to facilitate consideration on how the system should be designed to conform to the features of the stakeholders. In the case of scientific software the mathematical model is documented from a single viewpoint, as discussed in Section 3.1, but in the larger system context there may be more than one stakeholder and multiple viewpoints. It is important to document the stakeholder and user characteristics, as the information in this subsection will affect the way the product is designed; for example, it could be referenced to determine the usability requirements of the product. This section should not be used to state specific requirements but rather to provide the reasons why certain specific requirements are later specified in SRS Section 4. System constraints are also identified in the general system description section. They differ from other type of requirements in the sense that they limit the developers’ options in the system design and they identify how the eventual system must fit into the world. This is the only place in the SRS where design decisions can be specified. 4.3 Problem Description (SRS Section 4.a) The problem description is part of the “Specific System Description” (SRS Section 4) of the report, where the specific system description includes all of the SRS software


113


requirements in sufficient detail to enable design and testing of a system that will satisfy the requirements. The order of the contents of the first two sections of the specific system description are motivated by common scientific and engineering practises, which typically systematically proceed from the general to the more specific. Thus, the problem to be solved is first described, and then the characteristics that a solution to the problem must satisfy are specified. In the problem description section information on the problem domain of the physical system is given, where the information includes the concepts that populate the area in which the users carry out their activities, and in which they have a problem and expect a solution. 4.3.1

Terminology Definition

This section is motivated by a need to clarify the engineering concepts in the SRS and to serve as a reference aid. The contents consist of a list of engineering concepts and their exact meaning in the SRS, including some related conventions that will be used in the SRS. For example, definitions are given for the sign conventions that are used. This section should provide enough information to allow understanding of the later Sections “Theoretical Model” (SRS Section 4.a.ii) and “Data Definitions” (SRS Section 4.a.iii). The “Terminology Definition” section is necessary in scientific computing for an unambiguous SRS because terminology often has subtly different meanings, even in very similar contexts. As an example, in engineering mechanics the stress in a bar under uniaxial extension can either be expressed as the force divided by the original cross-sectional area (engineering stress), or the force divided by the current cross-sectional area (true stress). When large deformations occur, the distinction between these two stress measures becomes very important; therefore, if the convention for how stress is measured is not clearly stated, the results of the scientific analysis will likely be incorrect. 4.3.2

Physical System Description

The purpose of this section is to clearly and unambiguously state the physical system that is to be modelled. Effective problem solving requires a logical and organized approach. The statements on the physical system to be studied should cover enough information to solve the problem. The physical description involves element identification, where elements are defined as independent and separable items of the physical system. Some example elements include acceleration due to gravity, the mass of an object, and the size and shape of an object. Each element should be identified and labelled, with their interesting properties specified clearly. The physical description can also include interactions of the elements, such as the following: i) the interactions between the elements and their physical environment; ii) the interactions between elements; and, iii) the initial or boundary conditions. This portion of the SRS must clearly state what is unknown and what is known. The inclusion of a diagram or sketch will help the writers organize their thoughts and it will help them communicate the solution process to the reader. An example physical system for analysis of structural mechanics problems would be a beam. The properties of a beam would include its shape and the number of materials used to build it. Interactions between the beam and the physical environment would include external forces applied to the beam. The beam would also have associated boundary conditions that define how it is supported.

114


Smith and Lai

4.3.3

Goal Statements

The motivation of this section of the SRS is to capture the goals in the requirements process. As mentioned earlier, a goal is a functional objective the system under consideration should achieve. Goals provide criteria for sufficient completeness of a requirements specification and for requirements pertinence. For an SRS that solves beam problems an example goal would be to solve for the deflection of the beam, given the beam’s properties and the applied forces. Goals will be refined in Section “Instanced Models” (SRS Section 4.b.vi). Large and complex goals should be decomposed into smaller sub-goals. 4.4 Solution Characteristics Specification (SRS Section 4.b) This section specifies the information in the solution domain of the system to be developed. This section is intended to express what is required in such a way that analysts and stakeholders get a clear picture, and the latter will accept it. The purpose of this section is to reduce the problem into one expressed in mathematical terms. Mathematical expertise is used to extract the essentials from the underlying physical description of the problem, and to collect and substantiate all physical data pertinent to the problem. This section is different from the requirements specification of business applications because scientific software development focuses on efficient mathematical models rather than on the complex interaction of objects. 4.4.1

Assumptions

Section 3.2 emphasized the importance of assumptions to scientific computing. Therefore, an entire section of the SRS template is devoted to listing and labelling the assumptions. The document should not take for granted that the reader knows which assumptions have been made. In the case of unusual assumptions, it is recommended that the documentation either include, or point to, an explanation and justification for the assumption. For instance, for software to solve for the deflection in a beam an assumption may be made that the weight of the beam can be neglected, with the justification that the applied forces in practise are generally larger than a beam’s selfweight. 4.4.2

Theoretical Model

The assumptions in the SRS provide a means to bridge from the goal statements to the theoretical models, where theoretical models are sets of abstract mathematical equations or axioms for solving the problem described in Section “Physical System Description” (SRS Section 4.a.iii). Examples of theoretical models are physical laws, constitutive equations, relevant conversion factors, etc. This section is separate from goals and from the instanced model so that each portion of the document can be changed independently, as discussed in Section 3.4. Each theoretical model should be described from the following aspects: i) an introduction to the theory, which can take the form of a summary of the appropriate equations, together with a reference, or in the case of more complex problems, a more detailed derivation may need to be shown; ii) the reasons for choosing the model; iii) the rules and conventions of the model; and, iv) the limitations of the theory, which help identify the important physical data needed to solve the problem. An example of the limitation of a theory would be a theory for projectile motion that ignores the drag on the object caused by air friction.


115


4.4.3

Data Definitions

This section collects and substantiates all physical data needed to build the instanced model. For instance, if the models in Section “Instanced Model” (SRS Section 4.b.iv) needs a coordinate system, then this section should define it. The dimension system, as well as the dimension of each quantity can also be declared. In general, it is better to list the dimensions without reference to specific units, in support of the principle that it should be easy to reuse the mathematical model (Section 3.3). For instance, it is better to specify that the “MLtT” (Mass Length time Temperature) system is being used rather than to lock the specification into the units kg, m, s, etc. A more general description allows easy conversion of units, for instance between SI (Système International d’Unités) and imperial. The diagram or sketch of the physical system in Section “Physical System Description” (SRS Section 4.a.iii) can be labelled with the defined data for quick reference. One technique that can be beneficially employed at this stage is to use a table summarizing data definitions along with textual descriptions. This approach has the advantage of ensuring a uniform structure for the same type of data objects. For example, the definitions of all applied forces could follow the same structure consisting of “symbol,” “point of application,” “magnitude,” “direction,” and “assumed positive direction.” 4.4.4

Instanced Model

The motivation for this section is to reduce the problem defined in “Physical System Description” (SRS Section 4.a.iii) to one expressed in mathematical terms. This section uses the concrete symbols defined in Section “Data Definitions” (SRS Section 4.b.iii) to replace the abstract symbols in the models identified in Section “Theoretical Model” (SRS Section 4.b.ii). At this stage it is important to avoid assuming or applying a numerical algorithms in the SRS. The SRS should specify the requirements without considering the implementation. 4.4.5

Data Constraints

The motivation for this section is to clarify the environment and the system limitations imposed on admissible data. These constraints are specified to maintain the validity of the models defined in Section “Instanced Model” (SRS Section 4.b.iv). Example data constraints include the following: i) possible units of the data; ii) value constraints imposed by the physics of the problem and from the system (for instance, all lengths must be greater than zero); and, iii) other properties such as whether the data is input or output, or whether its value is known or unknown. As for Section “Data Definitions” (SRS Section 4.b.iii), a table is suggested for the purpose of listing the data constraints in a uniform format. Listing the constraints on the data is necessary to address the challenge of solution validation, which is one of the template’s design principles that were discussed in Section 3.5. As an example, the force Fax applied to a beam can be constrained so that it is not unrealistically different in magnitude compared to the other forces acting on the beam, which are given in the set SF: (min f ≤| Fax |≤ max f ) ∧[(| Fax |≠ 0) ⇒ ∀(FF | FF ∈ S F • FF ≠ 0 ∧

max{| Fax |,| FF |} r ≤ 10 f )] min{| Fax |,| FF |}

where minf and maxf are the system constraints for the minimum and maximum magnitude forces, and rf is a positive integer that is the maximum exponent of base 10 for

116


Smith and Lai

the ratio between the magnitudes of the largest and smallest forces. A constraint such as this is valuable in the subsequent design stage because it identifies whether the software will be required to handle the potentially difficulty situation of performing calculations with values of widely different magnitudes. 4.4.6

System Behaviour

The purpose of this section is to give a detailed model of the system’s dynamic functionalities based on the information in Sections “Data Constraints” (SRS Section 4.b.v) and “Instanced Model” (SRS Section 4.b.iv). The undesired situations, such as user errors, should also be documented here. Responses to undesired situations should be stated in the SRS instead of being left for the programmer to later invent. This section is a technical refinement for the Section “Goal Statements” (SRS Section 4.a.iv), since the technical concerns, such as assumptions and models, are clarified by previous sections. The system behaviour specification reflects a dynamic process of first receiving the input data, then applying the model, and finally obtaining the results. The system behaviour should be specified in a way that all the system goals are satisfied and the data constraints are considered. The content in this portion of the document should be formal enough for design and testing, with a suggested technique being the use of tabular expressions to specify partial specifications of the system functionalities so that the specifications are verifiable on domain coverage, disjoint domain, and definedness (Lai, 2004). 4.5 Nonfunctional Requirements (SRS Section 4.c) This section specifies system requirements that consider the quality and behaviour of the system as a whole. This section is separate from the functional requirements to facilitate the potential independent change of these two portions of the SRS, as discussed in Section 3.3. Several of the sections are borrowed from the Volere template (Robertson and Robertson, 1999), such as sections for look and feel, usability, performance, maintainability, portability and security requirements and a section for other system issues (SRS Section 5). The sections detailed below are unique to the new template. 4.5.1

Accuracy of Input Data

This section indicates the error associated with the input data. The contents of this section can be specified by illustrating each input data with their possible sources of measurement error and error range. The value of specifying the accuracy of the input is that these values can be used to judge the acceptability of the errors in the output. 4.5.2

Sensitivity of the Model

An inaccurate solution is not necessarily due to an ill-conceived algorithm, but may be inherent in the problem being solved. Even with exact computation, the solution to the problem may be highly sensitive to perturbations in the input data, such as when an unstable ordinary differential equations is solved. The cause of any potential propagated data error, which reflects the sensitivity of the problem, should be studied since it is a factor that can lead to inaccurate numerical results. Sensitivity of the problem is sometimes specified by calculating the condition number. In general, the condition number varies with the input, and in practise one usually does not know the exact condition number, or it is very expensive to compute. Thus, analysts often must


117


content themselves with a rough estimate or upper bound for the maximum condition number over some domain of inputs. When the condition number is unavailable other techniques, such as linear perturbation analysis, may be used. 4.5.3

Tolerance of the Solution

The motivation of this section is to establish a criterion for the correct solution, using the principle that it is better to specify what the correct answer should be, as provided in “System Behaviour” (SRS Section 4.b.vi), and then specifying what the allowed tolerances are, rather than to try and specify both simultaneously. Another motivation for this section is to develop an understanding of what level of solution accuracy is required. Solution accuracy refers to the closeness of a computed solution to the true solution of the problem under consideration. The accuracy of numerical solutions against the model depends on input data error, numerical error, computer round-off error, programming error, sensitivity of the problems, and stability of numerical algorithms. As a general rule, the accuracy of the final computation of the output need not be greater than the accuracy of the input data. One possibility is that the tolerance can be specified by tolerance functions. For example, the tolerance for the calculation of force equilibrium in 1D might be: |ΣFi|/√ΣFi2 ≤ ε where Fi is the ith force component and ε is the allowed error. 4.5.4

Solution Validation Strategies

As observed in Section 3.5, it is difficult to validate scientific computing software. The purpose of this section of the SRS is to capture the experts insight on how to validate the system results. Four potential evaluation strategies are: i) solve the problem by different techniques, such as electronic spreadsheet, graphical solution, etc.; ii) substitute the calculated results back into the original governing equations to calculate the residual error; iii) partially validate the problem by validating simpler subsets of it for which the solution is known; and, iv) check that the governing equations are satisfied, boundary conditions are satisfied, energy is conserved, mass is conserved, etc. 4.6 Traceability Matrix (SRS Section 6) The traceability matrix was introduced into the SRS template because of the design principle that the goals, theoretical models and instanced models should be simple to manage, as discussed in Section 3.4. The traceability matrix was designed based on the portions of the document that are most likely to change, such as the assumptions, which as discussed in Section 3.2 are tightly coupled with the functional requirements. By showing the relationship between different items in the SRS, the traceability matrix shows how a change in one functional requirements impacts the other functional requirements. The traceability matrix will often be sparse, so that significant portions of the SRS can be reused for different, but related, scientific computing problems. The entities that were identified as most likely to be reused include the following: “Physical System Descriptions,” “Goal Statements,” “Data Definitions,” “Assumptions,” “Theoretical Models” and “Instanced Models.” These sections of the SRS were selected for tracing because they represent the essential information about the model. A sample traceability matrix is provided in Table 1. In this table the prefixes G, T, A, M, and PS followed by a number correspond to the goals, theoretical model, assumptions, instanced model, and physical system, respectively. The symbol x

118


Smith and Lai

stands for one of the data definitions. An example of two traceability matrices can be found in Lai (2004) for the case of modelling a rigid beam and a deformable beam. A comparison of the two traceability matrices shows what portions of the mathematical model for the rigid beam can be obtained simply by removing sections from the model of the deformable beam. If an assumption is added that the beam behaves as a rigid body, then goals related to solving for shear, bending moment and deflection can be removed. The removal of these goals means that the associated theoretical models and instanced models are also removed. For the traceability matrix to work effectively it is important that independent assumptions are used when deriving the mathematical model of the physical system. Table 1: Sample Traceability Matrix

Phy. Sys./ Goal G1 G2 G3 PS1 …

5

Data/ Model T1 T2 T3 M1 x …

Assumptions A1

A2

√ √ √ √ …

…

… A4 … … … … … … …

Model … … … … … … …

A8

A9

√ √

√ √ √

…

…

A10

√ √ …

… A14 … … … … … … …

M1 √

√ √ …

… … … … … … …

Future Work

The proposed template has been used to document the engineering mechanics problem of solving for the internal forces, moments, shears and deflections of a statically determinant beam (Lai, 2004; Smith et al., 2005). Although this case study demonstrates the usefulness of the template, there is a need for additional case studies that select scientific computing problems from fields other than engineering mechanics and that select problems for which no closed-form solutions exist. Besides looking at special purpose scientific software that is built to solve one scientific computing problem, it would be beneficial to consider the specification of the requirements for general purpose software that is intended to solve a family of related scientific problems. For instance, case studies should be investigated for a system to solve linear algebra problems, or a system to generate finite element meshes. Ideally an empirical study should be conducted to determine the relative efficacy of the new template versus ad hoc procedures. Additional future work will include an investigation as to whether the process of gathering, analyzing and documenting requirements for scientific software differs from the process for other types of applications.

6

Concluding Remarks

The design principles identified in Section 3 were used to guide the structure and content of the proposed template. For instance, the first principle, which states that the functional requirements can be considered from only one user viewpoint, was


119


used to design the template’s simple structure. As there is only one viewpoint, the documentation can follow a simple framework that allows a refinement from general goals to specific statements. Also, the single viewpoint principle allows the template to separate the one viewpoint functional requirements from the, potentially many viewpoint, nonfunctional requirements. The second design principle is that the modelling assumptions play a crucial role in the documentation, which is reflected in the fact that the template has a section devoted to assumptions and a traceability matrix that can be used to track changes in assumptions. Due to the third principle, which requires that the mathematical model be easy to reuse, the template separates the general system description and nonfunctional requirements from the specification of the mathematical model, so that changes can be made to the context of the software without changing the model’s specification. The third principle is also responsible for the template section on auxiliary constants and the suggestion that generic units (m, L, t and T) be used in place of specific units (m, kg, s, etc.). The template separates goals, theoretical models and instanced models because of the fourth principle, which says that their hierarchical nature means that changes to these entities should be easy to manage. The separation allows the individual sections to be considered in isolation, and it allows the influence of changes to the functional requirements to be tracked, via the traceability matrix. The final principle states that documenting and validation of continuous mathematics should be supported by the template. This goal was realized by explicitly introducing sections where data constraints and solution validation strategies must be documented.

Acknowledgements The financial support of the Natural Sciences and Engineering Research Council (NSERC) is gratefully acknowledged. The authors would also like to thank Dr. Ridha Khedri and Dr. Jacques Carette for their valuable advice.

References GERLACH J (2002) Domain Engineering and Generic Programming for Parallel Scientific Computing. PhD Thesis, Von der Fakultät IV - Elektrotechnik und Informatik der Technischen Universität, Berlin. HENINGER KL (1980) Specifying software requirement for complex system: New techniques and their application. IEEE Transactions on Software Engineering, 6(1), 2–13. IEEE 1998 Recommended practice for software requirements specifications, IEEE Std. 830. IEEE. KREYMAN K and PARNAS DL (2002) On documenting the requirements for computer programs based on models of physical phenomena. SQRL Report 1, Software Quality Research Laboratory, McMaster University. LAI L (2004) Requirements documentation for engineering mechanics software: Guidelines, template and a case study. MASc Thesis, McMaster University, Hamilton, Ontario, Canada.

120


Smith and Lai

NASA (1989) Software requirements DID, SMAP-DID-P200-SW, Release 4.3. Technical Report, National Aeronautics and Space Agency. ROBERTSON S and ROBERTSON J (1999) Volere Requirements Specification Template. In Mastering the Requirements Process, p 353–391, ACM Press/AddisonWesley Publishing Co, New York, NY, USA. SMITH WS, LAI L and KHEDRI R (2005) Requirements analysis for engineering computation: A systematic approach for improving software reliability. Reliable Computing, Special Issue on Reliable Engineering Computation, Accepted. SMITH WS and STOLLE DFE (2003) Numerical simulation of film casting using an updated Lagrangian finite element algorithm. Polymer Engineering and Science, 43(5), 1105–1122. SOMMERVILLE I and SAWYER P (1997) Requirement Engineering: A Good Practice Guide. John Wiley & Sons Ltd. THAYER RH and DORFMAN (Editors) (2000) IEEE Recommended Practice for Software Requirements Specifications, 2nd edition. IEEE Computer Society, Washington, DC, USA.


121

A Process Guidance based on a Heuristic for Controlling Method Use in a Process-Centered Software Engineering Environment Inès Bayoudh Saâdi, Yassine Jamoussi and Henda Ben Ghezala Université de la Manouba Laboratoire RIADI-GDL Tunis – Tunisie

Abstract Strategic processes are not well considered in PSEEs (Process-centered Software Engineering Environment). In fact there is no flexibility in guiding their achievement and in determining the adequate path associated to the occurred situation that matches the intention, the engineer and the project requirements. In this paper we propose a heuristic called guidance map allowing the map navigation and the determination of the adequate path by using different strategies (cooperation, negotiation, optimization and so forth). It will then be used by the PSEE and especially by its process engine to guide the engineer. We present also an example of the use of negotiation strategy based on a win-win model to take the adequate decision relative to the situation. Keywords: PSEE, heuristic, map guidance, strategy, adequate path, situation intention, negotiation strategy, win-win model.

1

Introduction

A growing interest in the research area has been led to Method Engineering (ME) because of the recognition of the fact that not only every project is different from the others and current methods generic as they are, are being tuned to the circumstances at hand, but also there is a lack of guidelines to construct a project-specific method of high quality. ME allows method construction by assembling reusable method fragment stored in some method base according to a particular situation of a project. This approach brings flexibility by favouring the adaptation of methods to requirements and they preserve the knowledge on the method [1], [2], [3]. A method fragment is built up from two complementary models which are a product model and a process model [1], [4]. The product model refers to the structure of the results that an Information System Engineer (ISE) wants to achieve while the process model refers to the guidelines that the ISE can follow during the process of using the product model. As the quality of an IS is highly dependent on the process followed to build it [5] [6], the ISE should be guided step by step during the IS development process. Nowadays, there is an important requirement for methods and tools where process guidance is offered by providing advice about which activities are appropriated to which situations, and how to perform them [7]. In fact, there is a great variety of tools that supports, guides, and allows automated definitions and applications of process models. We refer in the following three categories of tools: The first category concerns the Process-centered Software Engineering Environments (PSEEs) [8]. These tools allow user to explicitly model the process to be used to produce and maintain software products and enact the process via a process

122


Inès Bayoudh Saâdi, Yassine Jamoussi and Henda Ben Ghezala

engine. But they enforce process performance according to some prescriptive software process definition [9]. The second category is the one called Computer Aided Requirements Engineering (CARE) [10]. CARE tools provide heuristics and experience based guidance required in the early phases of system development. The third category is relating to ME activities and called Computer Aided Method Engineering (CAME) [11]. This last category of tools, offer to user the possibility of defining the appropriate IS development method taking into account the specific IS project characteristics. The focus of this paper is principally on the first category. In fact, those environments have appeared in order to assist the software developer in achieving his work [12], [13], [14]. PSEEs didn’t follow the evolution noted in process models. So, they have focused on process and neglected the organization aspect. Thus, they aren’t flexible enough to support the human being factor. Moreover, PSEEs use perspective processes while the human activity is creative and may diverge from the process prescription. In this paper we will focus on both the process and the organization aspects in PSEEs and this in a situational context. So, flexibility can be discerned at three levels which are method, process and environment. On the level of methods the flexibility can be viewed as method construction by method fragment assembly. On the level of processes, the flexibility can be considered as the presence of many alternatives and combination of alternatives (paths) to achieve the same intention. To identify those alternatives and their functionality, we propose to use a goal-driven modelling formalism called Map1 [15] to capture the variability through requirements analysis. As for flexibility in the software engineering environment, this latter can be seen as their capacity to support change, evolution, guidance according to the occurred situation. The remainder of this paper is structured as follows. Section 2, presents the notion of path, Section 3 introduces the Map formalism and shows how to use it to represent flexibility. The Map enactment and path retrieval are illustrated in section 4. Section 5 describes an example of guidance map strategies use. Finally, we summarise our work and conclude with future work.

2

Path construction

Method fragment selection and assembly allow the construction of many method paths to reach the same intention. According to our point of view a method path is a sequence of one or many fragments extracted from method base and assembled allowing to reach a goal by altering the product state and while respecting quality features. Path construction is made on the fly according to choices and decisions made in the course of route by the software engineer. In fact, this latter is faced with multitude of alternatives, he needs a global view of what each alternative does and its dependencies with other alternative and what is the adequate alternative that matches the adequate, his requirements without being lost. He needs a means that matches his

1

Cooperation research held by CRI Lab–France and RIADI-GDL Lab Tunisia in CMCU project framework


123

Process Guidance in a Process-Centered Software Engineering Environment

requirements and the product functionality. Those requirements are dynamic and variable in time and space.

3

The MAP formalism and Paths

A map is a process model expressed in a goal driven perspective [15]. It is well adapted to model strategic processes. It provides a system representation based on a non-deterministic ordering of intentions and strategies. It is represented as a labelled directed graph with intentions as nodes and strategies as edges between intentions. The directed nature of the graph shows which intentions can follow which one [15]. An Intention can be achieved by the performance of a process. Each map has two special intentions, Start and Stop to start and end the process respectively. A Strategy is an approach, a manner to satisfy an intention. A strategy Sij between the couple of intentions Ii and Ij represents the way Ij can be achieved once Ii has been satisfied. A Section is a triplet and represents a way to achieve the target intention Ij from the source intention Ii following the strategy Sij. Each section of the map captures the situation needed to achieve an intention and a specific manner in which the process associated with the target intention can be performed (see Figure 1). S ij

Ii

Ij

Figure 1: A section

An intention in a map can be achieved by several combinations of strategies. This is represented in the map by a pair of intentions connected by several sections. All combinations of sections allowing the achievement Ij from the initial intention Ii represent paths in a map. Let’s consider the example of the map presented by Figure 2. We will try to find paths. S1 S5 II I1

S2

IJ

S3

Ik

S4

Figure 2: Method paths

All combination of paths allowing to satisfy intention Ik are presented in Table 1. Table 1: List of paths relative to the intention Ik Initial intention

Target intention

Paths P1: ,

Ii

Ik

P2: , P3: , P4:

124



We notice that method paths (see Figure 2) can be related to one method fragment or the result of assembly of many ones.

4

Map guidance for path construction

Strategic processes provide variability in strategies to satisfy the same intention. Our problem is to determine the path that satisfies the intention according to the engineer functional and non-functional requirement and to the project context. We will qualify this path as being the adequate path. As we have said earlier, a map is an oriented graph. So, adequate path retrieval in this map is an NP Hard problem as the problem can’t be solved in a polynomial time. To solve it two options can be considered either to solve the problem exactly but this uses lots of time on some inputs or to use heuristics which may not solve the problem exactly and which might be computationally expensive. For that reason we have proposed a heuristic that assists map navigation and the determination of the adequate path we attribute the name of guidance map to this heuristic. Indeed, the guidance map will guide the determination of the section to be executed at time t and the progression in the map navigation by identifying the next candidate sections (see Figure 3). We shall notice that in [16] we have presented in detail the guidance map and its strategies. In this paper we will make emphasis on the computation and the negotiation strategy. Forward intention Selection Strategy Intention Selection Backward intention Selection Strategy Strategy Exhaustive Strategy

Start

Determine candidate sections

Computation Strategy

Backward intention Selection Strategy

Exhaustive Forward Strategy intention Backward Selection Exhaustive Strategy Strategy Strategy Evaluate Sections selection Computation Forward Strategy Execute Section Negotiation strategy Strategy Preference Order Mathematical Selection Optimization Cooperation Strategy Strategy Strategy System driven Completeness Select Sections Strategy Strategy Preference Order Strategy

AHP Strategy

Stop

Figure 3: A guidance map for map execution

Path is then constructed progressively in each guidance map loop. It is important to note that guidance map uses several strategies that allow the determination of candidate sections, intentions, strategies. Those strategies permit also the selection of the adequate section to be executed and the progress in the map navigation. 4.1 The intention determination strategies The intention determination strategies allow the determination of the intention to be chosen. We can find the exhaustive strategy the forward intention selection, the backward intention selection and the intention selection. So the exhaustive strategy


125


consists in the determination of all candidate sections from all the sections not achieved in order to choose the intention to be accomplished. While the forward intention selection does the progression from the last section achieved. The backward intention selection allows the progression from the last section achieved but to the back. 4.2 The strategy determination strategies This kind of strategies allows the identification of all the strategies that satisfy the intention while doing a backward or a forward selection strategy. In fact, the forward strategy selection is used when we know the next intention to achieve, so the progression is done from the last intention achieved. As for the forward strategy selection, this latter acts the same way as the former but the progression is done in a backward manner. 4.3 The computation strategy This strategy computes the section aj contributions which are: the section contribution compared with methodological criteria named U(aj/CM), the section contribution compared with engineer criteria named U(aj/CI) and the section contribution compared with project criteria named U(aj/CP). 1  K  ; ; U (a j / CM ) = or  U ( a j / CP ) = ∑ wi S ij i =1 0   

K

U ( a j / CI ) = ∑ wi S ij i =1

with K : the number of criteria, Wi : criterion i weight, Sij : alternative j score compared to criterion i

The section contribution compared with methodological criteria U(aj/CM) can have the value of 1 if the methodological criteria are satisfied and the value of 0 if not. As for, the section contribution compared with engineer criteria and the project ones respectively U(aj/CI) and U(aj/CP), they are computed by summing products of all criterion weights by their corresponding alternative scores. We shall notice that these contributions represent a multi-criteria preference functions. Its goes without saying that different methods can be used either for evaluating criterion weight and alternative scores [17], [18], [19] such as direct and subjective evaluation, pairwise comparison, smart method and geometric progression. 4.4 The preference order strategy The preference order strategy allows us choosing a section arbitrary according to the engineer preference. It can be the section that has the greater contribution or not. 4.5 The negotiation strategy The negotiation strategy allows the choice of one section by means of negotiation. We will start by determining for each engineer, the alternative score compared to their criteria (Sji) and the criterion weight while respecting the fact that the criteria sum weight is equal to one, (Σwi =1). Thus we are able to compute U(aj/CI) and U(aj/CP) respectively the section contribution face to the engineer and project profile.

126



In the case of two engineers, if both don’t prefer the same section then we can say that we are in a conflict case and in this case we can use the win-win model [20]. However, if both engineers vote for the same alternative, this latter will be adopted. In this paper we will present in details the use of this strategy. 1   ; U (a j / CM ) = or  0   

L U (a j / CP ) = ∑ i =1 wi s ji ;

U (a j / CI ) = ∑ i =1 wi s ji N

with L : the number of criteria for project profile, N : the number of criteria for engineer profile, Wi : criterion i weight, Sij : alternative j score compared to criterion i

4.6 The cooperation strategy The cooperation strategy allows the choice of one section by means of cooperation. Indeed the section choice will be done by all the engineers at the same time. We will start by computing the criterion i weight (Wi) by summing all weights given for criterion I and diving the result by the number of engineers. By the same way we will compute the alternative j score compared to criterion i (Sji). Hence the score computed by all engineers is the scores sum divided by the number of engineers. k

Wi =

∑w m =1

k

im

k

;

S ji =

∑S m=1

k

im

with k the number of engineers

The section contributions will be determined by the same way as for negotiation strategy. 1   ; U (a j / CM ) = or  0   

L U (a j / CP ) = ∑ i =1 wi s ji ;

U (a j / CI ) = ∑ i =1 wi s ji N

4.7 The mathematical optimization strategy The mathematical strategy allows applying the dynamic programming, the Ford algorithm, the matrix method. The choice of one method is done according to its application hypothesis. 4.8 The AHP strategy This strategy uses a multi-criteria decision making method called Analytic Hierarchy Process method (AHP) [21]. This method contains five steps in order to determine the adequate choice. It starts by decomposing the problem in a hierarchal structure, the we must do the pair wise comparison, the third step consists in determining criteria priorities, the fourth step consists in synthesising alternative priority compared with criterion and the fifth step allows assuring coherence in judgment.


127


4.9 The system driven strategy The decision is determined by the system after taking into account the user order preference. 4.10 The completeness strategy The present strategy makes it possible to check the coherence and achievement rules on what was carried out. 4.11 The progression strategies: Those strategies allow the progression in the execution of a map after having satisfied an intention. In this category we can find the exhaustive strategy and the forward intention selection and the backward strategy. However, due to paper length limit, we will focus only on computation and negotiation strategies.

5

An Example

To illustrate our approach, we consider the example of defining classes with composition or inheritance according to O* method [22],[23]. The map of Figure 4 represents a fragment of a map in order to facilitate the application of the example and due the paper limit length. Each section in the map represents a feature that the system can provide. Inheritance Composition Strategy strategy Define classes

Figure 4: Class definition strategies The application of section has determined two candidate sections which are : < define classes, defines classes, composition strategy> and . In order to select the adequate section the user can use either the order preference strategy or the computation strategy or the AHP strategy. In the following we will show an example of the application of each strategy (see Figure 5). Evaluate sections Computation Strategy Select sections Preference order strategy

AHP Strategy

Figure 5: strategy selection strategies 5.1 The computation strategy use Section contribution compared with Methodological criteria obtained after having viewing criteria and their weight and their importance level, shows that both strate-

128



gies can be applied as U(Inheritance/CM) = 1, U(Composition/CM) = 1. So to choose one between the two sections we will compute their contribution compared with engineer profile. In order to determine criterion weight we can use the SMART method [17]. In this type of evaluation we attribute the value of 1 to least important criteria, the next criteria will have the value of 2, the next will have the value of 3 and so forth. To find the normalized criterion weight, we must divide the criterion weight (i.e. 1) by the sum of all weights (i.e. 1+2+3=6). Thus the first criterion weight will be 1/6. Table 2 presents the list of criteria expressed by the engineer. We shall notice that in the guidance map the section being executed is . Table 2: Criteria List and their weights Ci

Label

Wi

C1

Reduced load of maintenance

3/6

C2

Stronger encapsulation

2/6

C3

non complexe class

1/6

The application of the computation strategy to both alternatives is illustrated by the table below. For instance, if we consider the composition strategy, to compute its contribution we must apply the formula (1). This latter gives this operation (3/6)*1 + (2/6)*0.3 + (1/6)*0.8 = 0.7333. In the same way we can compute the inheritance strategy. Section contributions are done in table 3. (1)

3

U ( a j / CI ) = ∑ Wi Sij i =1

Table 3: Sections contribution face to engineer criteria C1

C2

C3

3/6

2/6

1/6

Composition

1

0.3

Inheritance

0.5

0.2

Wi

0.8 0.2

3

U (a j / CI ) = ∑ Wi S ij i =1

(3/6)*1+ (2/6)*0.3+(1/6)*0.8 = 0.7333 (3/6)*0.5+(2/6)*0.2+(1/6)*0. 2 = 0.35

U(composition) > U(inheritance)

According to the guidance map to select the adequate section we can either use the preference order strategy, the negotiation strategy, the cooperation strategy or the mathematical optimization (see Figure 6). According to the preference order strategy, the composition contribution is greater than the inheritance one; we can use the composition strategy to define classes. In [16], we have shown the use of cooperation strategy, in this paper we will show the use of the negotiation one.


129


Evaluate sections Optimization Strategy

Negotiation Strategy Cooperation Preference order Strategy strategy Select sections

Figure 6: section selection strategies 5.2 Negotiation based on a win-win model use We will suppose that engineer I1 is not sure of strategies to be used to define a new class is it a composition or inheritance? The PSEE will guide him by interpreting the map guidance and especially by applying the negotiation strategy. So we will have recourse to the win-win model if engineers have conflicts [17],[20]. We shall notice that this model begins with eliciting win conditions, identifying issues, and generating options to resolve the issues, after that it will negotiates the options in order to reach agreements. So, we will apply those steps on the example of class definition and this to reach a common decision (see Figure 7).

Step 2 : Identify Issue

Step 1 : Elicit Win Conditions

Step 3 : Explore Conflict Resolution

Step 4 : Analyse Preferences * Explore objective criteria * Assess options based on criteria * Assess relative weights for criteria by engineer * Rank options

Figure 7: the win-win negotiation model 5.2.1

Step 1: Elicit win condition

Both engineers I1 and I2 are negotiating the use of composition or inheritance to define a new class. So they are engaged in a brainstorming session that yields to the following win-conditions (See Table 4). Table 4: Win condition by engineers Engineers Engineer I1

130

Win Condition WC11

Description Easier change of the interface of back-end class



WC12 WC13 WC14 WC21 WC22

Engineer I2

5.2.2

Easier change of the interface of front-end class Delay the creation of the back-end objects until they are needed Method delegation cost performance Easier adding new subclasses Easier changing implementation of any class

Step 2: Identifying issues

In the following step, we will identify conflicts between win conditions. For instance, there is a conflict between stronger encapsulation and adding new subclasses easier. Other conflicts are given in Table 5. Table 5: Win condition conflict

Win Conditions WC11 WC12 WC13 WC14 WC21 WC22

5.2.3

Conflicted Win Conditions Reduced Strong enNon comload of maincapsulation plex classes tenance WC21 WC21 WC21 WC21 WC13 WC13

Step 3: Explore objective criteria

The contribution function needs identification of criteria reflecting differences to engineers, Table 6 gives a list of such criteria. Table 6: Criteria

5.2.4

Criteria

Related Win Condition

Maintenance Reduced Load Strong encapsulation Non complex classes

WC22 WC11 , WC12 , WC13, WC14 WC11 , WC12 , WC13, WC14 , WC22

Step 4: Assess option scores based on criteria

There are different methods to assign scores to alternatives based on criteria in this paper we will use a direct and a subjective method which uses a 0-1 scale and according to importance of the criteria to the alternative the value will increase. For instance, we can say that for engineer I2 the criterion Reduced load of maintenance is more important for inheritance than for composition that is why he has assigned the value 0.8 to the score of composition based on C1 (see Table 7).


131


Table 7: Alternative scores by each engineer Criteria C1: Reduced maintenance

load

of

C2: Strong encapsulation

C3: Non complex classes

5.2.5

Alternatives

I1

I2

Composition

0.5

0.5

Inheritance

0.5

0.8

Composition

0.3

0.2

Inheritance

0.2

0.3

Composition

0.8

0.1

Inheritance

0.2

0.1

Step 5: Assess relative criteria weights by criteria by individual engineer (engineer 2)

Several methods could be used to assign weights to criteria. In this paper we will use the SMART method which has as principle to rank criteria, then to assign value of one (Wi = 1) to the least important criteria. The next criterion will have the value of 2, the next the value of 3 and so forth (See Table 8). Then each assigned value will be divided by the sum to retrieve the real weight (i.e w2 = 2/6 with 6 = 1+2+3). Table 8: Criteria Weights Engineers

5.2.6

C1

C2

C3

I1

3/6

2/6

1/6

I2

2/6

1/6

3/6

Step 6: Rank options

In this step we will proceed to the ranking of alternatives which are composition and inheritance. So values in Table 9 are obtained by multiplying the weights for each criterion by the score of each alternative on that criterion by individual engineer. For instance, engineer I1 composition score would be: 5*(3/6) + 0.3*(2/6) + 0.8*(1/6) = 0,483. Table 9: Rankings by individual engineer Strategies

132

Engineer I1

Engineer I2

Composition

0.5*(3/6) + 0.3*(2/6) + 0.8*(1/6) = 0,483 (1st)

0.5*(2/6) + 0.2*(1/6) + 0.1*(3/6) = 0,216 (2nd)

Inheritance

0.5*(3/6) + 0.2*(2/6) + 0.2*(1/6) = 0.35 (2nd)

0.8*(2/6) + 0.3*(1/6) + 0.1*(3/6) = 0.367 (1st)



As engineers have different ranking for composition and inheritance strategies, we will proceed to a group aggregated assessments. In which we will take the weights generated from the first engineer because he is the responsible for the present problem. As for, scores they are generated from the analysis of win conditions. So, if the win conditions are provided by the first engineer then his alternative score relative to that criterion is assigned. If ever win conditions are provided by both engineers then we will assign the average to each criterion relative to each alternative (see Table 10). Table 10: Group aggregated assessments

Criteria Weights

C1: Reduced load of maintenance 3/6

C2: Strong Encapsulation 2/6

C3: Non Complex classes 1/6

Scores Composition

0.5

0.3

0.45

Inheritance

0.5

0.2

0.15

Value 0.4 25 0.3 42

Rank 1 2

As shown in table 10, the decision suggested by the PSEE engine process by means of negotiation based on a win-win mode is to use composition instead of inheritance.

6

Conclusion

In this paper, we have proposed an approach for providing flexibility in satisfying intentions in PSEEs. So we used goal driven formalism that is the map both to model strategic processes and to navigate within them. The originality of our work consists in the formalization of map navigation by constructing the adequate path according to the engineer requirements while using a heuristic called map guidance in a PSEE. We consider this latter as a heuristic because it might help us to find solutions which are good, but perhaps not the very best they can be. We have presented an example of the use of this approach by presenting the negotiation strategy based on the win-win model and the computation strategy. We have shown an example of its appliance. We shall notice that this approach is supported by an environment that we have developed in our laboratory. Actually, we are working on the use of genetic algorithms and neural networks to find the adequate path and we will compare the generated results.

References 1. 2.

HARMSEN A. F (1997) Situational Method Engineering. Moret Ernst & Young. BRINKKEMPER S, SAEKI M and HARMSEN F(1998) Assembly Techniques for Method Engineering. Proceedings of the 10th Conference on Advanced Information Systems Engineering, CAiSE’98. Pisa Italy.


133


3.

4. 5.

6.

7.

8.

9. 10. 11.

12.

13.

14.

15. 16.

17. 18.

19. 20.

134

HARMSEN F and BRINKKEMPER S (1995) Description and Manipulation of Method Fragments for Situational Method Assembly. Proceedings of the Workshop on Management of Software Projects, Pergamon Press, London. ROLLAND C (1997) A Primer for Method Engineering, Actes de conférence INFORSID’97, Toulouse. JARKE M, POHL K, ROLLAND C and SCHMITT J. R (1994) Experienced-Based Method Evaluation and Improvement: A Process Modeling Approach, Int. IFIP WG8. 1 Conference in CRIS series: Method and associated Tools for the Information Systems Life Cycle", North Holland (Pub.). PAULK M. C, CURTIS B and CHRISSIS M. B (1991) Capability Maturity Model for Software. Technical report, Software Engineering Institute, Pittsburg, CMU/SEI-91TR-24. ROLLAND C (1998) A comprehensive view of process engineering, Proceeding if 10th international conference CAISE’98 ; B., Lecture Notes in computer science 1413, Spring Verlag Percini, C. Thanies (Eds) ; Pisa, Italy. FINKELSTEIN A, KRAMER J, and BASHAR A (1994) Nuseibeh: Software Process Modelling and Technology. Advanced Software Development Series. Research Studies Press/John Wiley & Sons. DERNIAME J-C, KABA B. A and WASTELL D (1999) Software Process: Principles, Methodology,and Technology, LNCS. pp.1500, Springer. SUTCLIFFE A.G and MAIDEN N (1994) A theory of Domain Knowledge for Requirements Engineering, NATURE Report, Delivrable D-D-2, August 1994. BRINKKEMPER S (1996) Method engineering: engineering of information systems development methods and tools, Information and Software Technology, Vol. 38, No.4, pp.275-280. AMBRIOLA V, CONRADI R and FUGGETTA A (1997) Assessing process-centered software engineering environments, ACM Transactions on Software Engineering and Methodology, 6(3):283--328, 1997. BARGHOUTI N, EMMERICH W, SCHÄFER W, SKARRA A. H(1996) Information management in Process-Centered Software Engineering Environments, In A. Fuggetta &A. Wolf (Eds.) Software Process, Trends in Software 4, pages. 53-87, Wiley. KELLNER M, BECKER-KORNSTAEDT U, RIDDLE W, TOMAL J and VERLAGE M (1998) Process Guides: Effective Guidance for Process Participants. Proc. 5th Int'l Conf. on the Software Process: Computer Supported Organizational Work. Lisle, Illinois USA, 14-17 June 1998. Int'l Software Process Assoc. Press, New Jersey, pp. 1125. Rolland C, Prakash N and Benjamen A (1999) A Multi-Model View of Process Modeling, Requirements Engineering Journal, p. 169-187. BAYOUDH I, JAMOUSSI Y and GHEZALA H.B(2005) Flexibility in satisfying intentions in a situational context, accepted in The ISCA 14th International Conference on intelligent and adaptative systems and Software Engineering (IASSE’05), Toronto, CANADA. HOH P and OLSON D (2004) Requirements Negotiation Using Multi-Criteria Preference analysis, Journal of universal computer science, Volume 10, issue 4. EDWARDS W and BARRON F.H (1994) SMARTS and SMARTER: Improved Simple Methods for Multiattribute Utility Measurement, Organizational Behavior and Human Decision Processes 60, pp. 306-325. CHOO E.U, SCHONER B and WEDLEY W.C (1999) Interpretation of criteria weights in multicriteria decision making, computers and industrial engineering 37, pp. 527-541. BOEHM B, Egyed A, Port D, Shah D, Kwan J and Madachy R (1999) A stakeholder Win-Win Approach to Software engineering Education, Annals of software Engineering.



21. 22. 23.

SAATY T.L (1977) A scaling method for priorities in hierarchical structures, Journal of mathematical psychology 15, page 2134-281. DENECKERE R (2001) Approche d’extension de méthodes fondée sur l’utilisation de composants génériques, Thèse à l’université Paris 1 - La Sorbonne. ROLLAND C, FOUCAUT O and BENCI G (1981) Conception des systèmes d’information : la méthode Remora. Edition Eyrolles.


135

A Lightweight Workshop-Centric Situational Approach for the Early Stages of Requirements Elicitation in Software Development Chad Coulin a,b , Didar Zowghi b and Abd-El-Kader Sahraoui a,c a

LAAS CNRS, 7 avenue du Colonel Roche, 31077 Toulouse France University of Technology Sydney, PO Box 123, Broadway NSW 2007 Australia c IUT de Blagnac, 1 place Georges Brassens, 31703 Blagnac France b

Abstract The elicitation of requirements for software systems is one of the most critical and complex activities within the development lifecycle. Although the subject has received some degree of attention in the research literature, there remains a need for situational methods and processes that can be easily utilized by the majority of practitioners in typical projects. In this paper we present a flexible, yet systematic approach to the early stages of requirements elicitation based on collaborative workshops, and the construction of a lightweight situational method within a general process framework. The research provides practitioners with an approach to requirements elicitation that can be readily applied to real-world projects in order to improve both the process and results. It also offers researchers an example of how lightweight situational method engineering can be applied to very practical activities and situations. Keywords: Requirements, Elicitation, Situational, Workshop

1

Introduction

Within the software development lifecycle, requirements elicitation is the activity typically performed after project initiation and preliminary planning, but before system conception and design. Subsequently requirements elicitation can be broadly defined as the operations related to the acquisition and elaboration of goals, constraints, and features for proposed software-based systems by means of investigation, exploration, and analysis. Furthermore it is generally understood and accepted that requirements are ‘elicited’ rather than just captured or collected. This implies discovery, development, and creativity elements to the process. Similarly, Hickey and Davis (2003) have defined requirements elicitation as “learning, uncovering, extracting, surfacing, and/or discovering needs of customers, users, and other potential stakeholders”. Widely regarded as one of the more challenging activities within the scope of Requirements Engineering (RE), elicitation by its very multi-disciplinary nature is subject to many factors and a variety of both technical and social issues. When performed poorly, the results regularly include costly rework, schedule overruns, and in some cases, project and system failure (Hickey and Davis, 2002). Often expensive in terms of time, effort, and cost, it is therefore even more important that the elicitation of requirements is conducted properly and with the appropriate level of rigor. The production of high quality requirements through effective elicitation is absolutely essential for the engineering of successful software products. One of the major problems in requirements elicitation today is the significant gap between expert and novice analysts. This can be attributed to a number of factors, not least of which is the extensive skill set and range of experience necessary to perform

136


Coulin, Zowghi and Sahraoui

this activity successfully. True experts in this complex and critical activity are few and far between. This situation is further aggravated by the current lack of systematic guidelines and flexible methods. Somewhat related and just as important is the current gap between requirements elicitation theory and practice. A lack of awareness by novice analysts of thee state of the art techniques and tools for requirements elicitation, combined with a general unwillingness to adopt them is largely responsible. As a result the objectives of the research described in this paper are specifically focused on filling the void that currently exists by providing support for novice analysts and those projects without a prescribed software development methodology, with a useful and useable situational approach to requirements elicitation. Within this approach, we wish to take advantage of the collaborative aspects of group workshops, as well as the benefits in combining a number of different techniques, whilst attempting to directly address some of the current issues and challenges faced by analysts. Our primary goal, however, is to improve the effectiveness and efficiency of the requirements elicitation process in terms of time, costs, effort, and quality of results, thereby increasing the likelihood of project success with respect to on-time and onbudget delivery, while achieving customer and user satisfaction. The focus of this work is principally on the early stages of requirements elicitation, and not other often associated RE activities such as modelling and prioritization. Instead we concentrate primarily on the fact-finding and information gathering operations. The paper is structured as follows. Section 2 describes some background information on requirements elicitation and related research. Section 3 introduces the topic of situational method engineering and how it can be related to requirements elicitation. Section 4 presents the developed approach to requirements elicitation including the situational method and process framework. Section 5 demonstrates the implementation of the approach by way of a real-world software development project example, and Section 6 provides a discussion of the approach and its potential implications. Finally Section 7 presents some conclusions from the research, and Section 8 suggests future work to be done.

2

Requirements Elicitation

Much of the research performed over the past two decades on and around the topic of requirements elicitation for software systems has been focused primarily on the development, implementation, and evaluation of a variety of techniques, methods, and tools. Many of these were adopted from other disciplines such as the social sciences (Ball and Ormerod, 2000; Beyer and Holtzblatt, 1995) and knowledge engineering (Hudlicka, 1996; Maiden and Rugg, 1994). Regardless of their origin, the principal motivations for these approaches were to reduce the complexity of the process, improve the quality of the results, and address some of the major issues often experienced by practitioners. In reality there are literally hundreds of approaches that can be used for requirements elicitation. A survey by Goguen and Linde (1993) examined at a relatively high level only a small number of the more traditional techniques such as interviewing, observation, and task analysis. In a more recent survey on the theory and practice of requirements elicitation (Zowghi and Coulin, 2005), several additional and more current approaches were examined including those based on goals (Dardeene et al., 1993), scenarios (Potts et al., 1994), viewpoints (Sommerville et al., 1998), and do-


137

A Workshop-Centric Situational Approach for Requirements Elicitation

main knowledge (Sutcliffe and Maiden, 1998), combined with a review of the tasks, sources, and types of information involved. Of the many available techniques, collaborative approaches to requirements elicitation, and especially facilitated workshops, where the different stakeholder groups are represented and work together to collectively conduct the process of requirements elicitation, are a common and often default approach. These have also been found to be very helpful and successful in not only producing quality requirements, but also in achieving stakeholder buy-in and instilling project ownership (Gottesdiener, 2002). One of the obvious advantages of using group workshops is the ability to integrate other elicitation techniques into them, and then to incorporate their combined usage into a defined requirements process (Maiden et al., 2004). As a result of the relative strengths and weakness of the available approaches, most projects will normally require a combination of several techniques in order to produce quality results (Maiden and Rugg, 1996). Although over the years a number of different process models have been proposed as generic roadmaps to address this (Sommerville and Sawyer, 1997; Kotonya and Sommerville, 1998), and significant progress has been made in developing better techniques to support the process of eliciting requirements for software systems, there still remains a lack of appropriately flexible guidelines and sufficiently detailed methods which can be used by the majority of practitioners in typical projects. Clearly requirements elicitation does not occur in a vacuum and is highly dependant on specific project, organizational, and environmental characteristics (Christel and Kang, 1992). Software can be developed in a variety of contexts such as bespoke systems from scratch, or based on the customization of a COTS solution. The development may be contracted out to an external entity, or performed by internal personnel. Software may be produced for the general market, or for an individual customer. Requirements elicitation itself may be part of a feasibility study, a COTS selection process, or the development of an entirely new system. Furthermore there are many kinds of systems that may be developed including distributed, web-based, and embedded just to name a few. The possible permutations of these situational characteristics are numerous. Moreover, there are number of other internal and external factors that may affect the project and how it is conducted including government regulations, changing market conditions, political considerations within the organization, and the technical maturity of the organization and the users of the target system. Requirements elicitation is an absolute prerequisite for all the different types of software development projects. It is precisely because of the many and varied contexts in which software development is performed, and the large number of factors, techniques, and issues that may have an affect and are involved even in the most typical of processes, that a situational method is not only suitable, but essential. Furthermore it is proposed that the integration of such a method with collaborative workshops and a combination of techniques provides an innovative and productive approach to requirements elicitation for the development of software systems.

3

Situational Method Engineering

Method Engineering (ME) represents a structured way in which methods for software development activities such as requirements elicitation can be designed, constructed, and adapted. Situational Method Engineering (SME) is therefore the configuration of

138



these methods specifically for individual projects (Brinkkemper, 1996). Naturally this is an important topic as no two software development projects are exactly the same, and all projects cannot be adequately supported by a single static method. This is especially the case with requirements elicitation, where the heavy dependence on human involvement adds a significant number of social and communication variables. The idea of creating a situational method for requirements elicitation is not new. As early as 1982, Davis identified the need and importance of developing situational requirements elicitation methods (Davis, 1982), although he referred to them as “requirements determination strategies”. However the basic premise of characterizing a specific project based on some criteria, and as a result selecting from a set of methods those that are most appropriate, remains the same. Davis also suggests that the development of such a method should be based on the types of information to be elicited. The scope of ME research for software development in recent times has included models for situational method engineering (Ralyté et al., 2003), assembly techniques and rules for method construction (Ralyté and Rolland, 2001; Brinkkemper et al., 1998), and more generic process modelling and engineering approaches (HendersonSellers, 2002). The combined result of this work over the past ten years in particular provides a suitable foundation for the development of an activity specific situation method as proposed in this paper for requirements elicitation. Of specific interest and relevance to the objectives of our research is the work by Henderson-Sellers and Firesmith relating to the OPEN Process Framework (OPF, 2005), which has been applied to the entire software development lifecycle, as opposed to just the elicitation of requirements as is our case. Requirements elicitation alone, however, represents an excellent candidate for the implementation of a situation specific method. As it is usually the first phase of a development project, it does not have to conform to the assumptions or constraints of other methods employed in previous phases, or rely on the outputs from other activities. The flip side to this, however, is that at the requirements elicitation stage, very little may actually be known about the project and the target system.

4

The Requirements Elicitation Approach

The following situational approach has been developed based on a critical analysis of the state of the art in requirements elicitation, as well as an ongoing survey of practice. The approach represents not only a detailed process for conducting requirements elicitation, but also an integrated situational method. The overriding intention of this approach is to support the analyst structure and perform requirements elicitation workshops based on project specific characteristics. Throughout the approach we have purposely endeavoured to keep the process of engineering the method, and the process of requirements elicitation itself, as lightweight as possible. This is in direct response to our objective of providing support for novice analysts and projects without a specifically prescribed software development process. 4.1 Meta-levels of the Approach The general approach can be explained using the three-tiered structure as seen in Figure 1 (adapted from Henderson-Sellers, 2002) which differentiates between a method meta-model, a specific instantiation of that method meta-model, and an individual


139


project specific instance of a specific instantiation. This can be described in more basic and practical terms by the following example. L2 represents the components and rules for constructing a requirements elicitation process for an organization that produces different types of software. L1 then represents one possible example of a process, constructed using the components and rules set out in L2, for say the development of customized business information systems. L0 would then represent a project specific enactment of that process detailing the requirements, goals, and constraints of the business information system for that particular customer.

Method Meta-model

Level 2 (L2)

Is an instance of

Specific Method

Level 1 (L1)

Is an instance of

Specific Instance

Level 0 (L0)

Figure 1: Approach meta-levels

The top level of this structure (L2), from which processes are constructed, consists of four main ‘meta-types’ or ‘classes’ as shown in Figure 2 and described in Table 1 below. In fact instances of these meta-types (Info Types, Tasks, Sources, and Techniques), which are sometimes referred to as ‘method fragments’ or ‘method chunks’, are just the building blocks used to construct what we have called ‘method components’, and it is actually a set of these method components that are selected and sequenced to form a specific method (L1) which can then be enacted (L0). Table 1: Method meta-model class descriptions Class

Description

Info Type

A specific kind of required data or knowledge, such as ‘project assumptions’ and ‘design constraints’

Task

A specific individual unit of work. Examples include ‘identify key constraints’ and ‘define work processes’

Source

A place or object that provides information. Sources can be individuals, groups, documents, and systems

Technique

A specific way of performing a requirements elicitation task, such as by questionnaire or brainstorming

140



The term ‘method component’ has been introduced and used to describe a single instance of the entire method meta-model based on an individual task. Therefore a method component is a method fragment of the Task class with its corresponding and related Info Type, Source and Technique method fragments. Specific real-world examples of method components are given in Section 5. In summary, a method component is a task that elicits an info type from a source using a technique. These method components are used as the base unit of work to organize and execute requirements elicitation within a workshop environment, by placing them into a structured sequence according to the process framework described later.

Info Type

provides

addresses

is elicited by Task involves

employs

Source

Technique

makes use of

Figure 2: Method component meta-model

4.2 Process Model for the Approach As previously stated, the approach presented in this paper represents both a process for engineering a situational method, as well as a process for performing requirements elicitation. The process model of the entire general approach as shown in Figure 3 (adapted from Brinkkemper, 1996), provides an overview and illustrates that the engineering of the method and the process of elicitation itself begin with characterization of the project at hand, construction of the method for this project, and then execution of this method within the project at hand. These individual ‘steps’ of the approach are subsequently detailed in the following subsections, as are the approach guidelines, which in addition to supporting all the steps of the approach, provide supplementary assistance for conducting requirements elicitation workshops, and in particular, provide possible solutions to many of the issues and challenges faced by practitioners during this difficult yet vital development activity.


141


Step 1. Project Characterization

Approach Guidelines

Step 2. Method Construction

Method Repository

Tailoring

Step 3. Method Execution

Project Repository

Figure 3: Approach process model

4.3 Step 1: Project Characterization The first step of the approach is Project Characterization. It is at this point that the situational characteristics of the project at hand are identified in order to direct the construction of the method to be used. There are a number of different ways to characterize a software development project based on the specific situation. One suggestion has been to use taxonomy of specific problem, solution, and other project situational factors (Hickey and Davis, 2003). Another has been to base the characterization on the goals, risks, opportunities, and challenges of the project (Kurtz, 2001). Although these are useful ways of characterizing projects, this information is rarely available before the requirements elicitation phase, and in fact it is the actual purpose of requirements elicitation to discover and develop this information. Therefore, we use the following three basic attributes to categorize the specific requirements elicitation project: 1.

Definition – The definition of the type of elicitation project being conducted. Examples of project definitions include Custom Development, COTS Selection, and Feasibility Study.

2.

Domain – The general application domain of the envisaged system. Examples of application domains include Business Information, Group Support, and Embedded Control.

3.

Deliverable – The required deliverable document from the elicitation project. Examples of project deliverables include Requirements Specification, Concept of Operations, and Vision & Scope documents.

142



Although admittedly quite basic, characterization of the project by using only these three variables (hereafter referred to as the ‘3Ds’) does however take into account three of the most important and influential situational elements that are known at this very early stage of the software development lifecycle. The combination of values for these 3Ds of a given project is used to guide the construction of the method as described below. 4.4 Step 2: Method Construction The second step of the approach is Method Construction. It is at this point that the method fragments are selected from the Method Repository and assembled into method components. These project components are then structured according to the process framework, and sequenced according to the approach guidelines. These operations are referred to collectively as the method construction, the result of which is an executable method than can then be enacted for the project at hand. The Method Repository can be represented as a series of lookup tables, which detail instances of the different meta-types (called method fragments) and their relationships to other method fragments. There are ten tables in total, being one flat list for each of the meta-types (or classes), and one for each of the different possible interclass relationships. In the Info Type and Task flat lists, flags are used to identify which ones are recommended for each of the possible values for the 3Ds identified in Step 1 of the approach. An analyst can therefore ensure that all the appropriate info types are addressed and all the prudent tasks are included in the requirements elicitation method, by using these tables to assemble a set of method components. Once the method fragments have been selected and assembled to form a set of method components, this set of method components must then be structured and sequenced to complete the construction of the requirements elicitation method. In order to support this operation, the approach guidelines include a process framework with instructions that can be used by the analyst as a template for arranging and ordering the method components. This process framework, as can be seen in Figure 4, divides the complete set of method components into three key workshop phases of Scoping, High-level and Detailed. These phases are then divided into three stages being Preparation, Performance, and Presentation. Method components of the Performance stage of each phase are subjected to a third division into five different areas of interest. It is anticipated that expert analysts would be able to select instances of each class from the method repository, assemble method components, and construct the resultant method with little or no reference to the approach guidelines and process framework. Furthermore, expert analysts often know familiar and proven ways of doing things during requirements elicitation, and therefore would much prefer the freedom to choose how the method fragments and method components are to be used. Novice analysts, on the other hand, would undoubtedly prefer a more prescribed approach to method construction given that by definition they lack the knowledge of experience and range of expertise that would be required to do this independently.


143


Phases 1. Scoping

Stages

Areas

1.1 Preparation 1.2 Performance

1.2.1 Context

1.3 Presentation

1.2.2 Domain 1.2.3 Processes 1.2.4 Functional 1.2.5 Other

2. High-level

...

3. Detailed

...

Figure 4: Process framework

In direct response to this, and in order to satisfy the key goal of this research to support novice analysts and projects without a defined requirements elicitation process, we have developed and incorporated into the approach guidelines what we have called ‘ready-made’ requirements elicitation methods. These represent pre-selected, preassembled, and pre-constructed methods for typical, common, and often occurring combinations of the 3Ds in practice. The ready-made methods currently available within the approach have been developed as a result of the review of the state of the art, and survey of the state of practice, in requirements elicitation previously mentioned. That is to say that the method repository was populated, and method components assembled, from direct references found in the literature to specific instances of the meta-types and their relationships. The ready-made methods were then constructed from these method components with reference to a number of example requirements documents from real world projects with the same situational characteristics according to our 3Ds classification. An overview of one of these ‘ready-made’ methods is demonstrated by the example in Section 5. 4.5 Step 3: Method Execution The third and final step of the approach is Method Execution. Once the method has been constructed in accordance with the process framework using method components made up of method fragments from the method repository, the requirements elicitation part of the project can then be executed with the results of the method components being stored in the project repository. The Project Repository can be represented as a set of detailed templates for the different types of elicited and supporting information. During execution, each method component task of the method is addressed utilizing the associated techniques to elicit the required info types from the available sources in support of or within a workshop environment. Each of the Performance

144



stages prescribed by the process framework are facilitated by the analyst, and may be completed over a number of workshop sessions depending on the complexity of the project, and the accessibility of relevant stakeholders. It is probable that the same info type may be addressed by more than one task at different stages of the method. In these cases the level of detail investigated and the attributes elicited for the info type are usually different. Normally each task has at least one available technique, and likewise each info type has at least one possible source. The exact steps necessary to conduct a specific task using a particular technique within a requirements elicitation workshop are also contained in the approach guidelines. All method components can be repeated, removed, or reconfigured dynamically during the project by the analyst based on preferences or changing situations. This is referred to as ‘tailoring’ of the method. Tailoring can take place either before the method is enacted, as in the case of adding or removing method components after construction, or during the execution of the process itself, such as selecting which of the requirements elicitation techniques to use for a given task. Like those constructed from scratch, ready-made methods can be tailored by modifying the info types, tasks, techniques, and sources in the method repository before or after construction. This is important as it enables organizations and individuals to develop their own ‘template’ situational methods for different sets of project characteristics. It also creates a feedback and validation mechanism into the approach, adding a further level of flexibility and customization. An example of dynamic tailoring would be if the analyst believes insufficient information has been elicited for a particular info type during a session, a new task or technique for that info type can be selected from the repository, and added to the existing method, or utilized there and then.

5

An Example ‘ready-made’ Method

The following subsections provide an overview example of how one of the existing ‘ready-made’ methods would be implemented and enacted in a real-world project within the context of the general requirements elicitation approach presented in this paper. Although currently only a relatively small number of these ‘ready-made’ methods have been developed for different combinations of the 3Ds, this example aims to illustrate how the basic principles of the approach can be applied to most requirements elicitation project contexts. The example project has the following situation characteristics, i.e. values for the 3Ds, as defined in project initiation phase (preliminary planning) and identified by the participating analyst for the Project Characterization step: 1.

Definition: Custom Development

2.

Domain: Information System

3.

Deliverable: Requirements Specification

Other project definitions currently supported by ready-made methods include COTS Selection, Call for Tenders, and Feasibility Study. Likewise, ready-made assistance exists for Group Support, Data Warehouse, and Embedded Control application domains. The production of project deliverables including Software Requirements Specifications, Concept of Operations Documents, Feasibility Reports, Tender


145


Documents, and Vision & Scope Statements are also available as ready-made methods for the mentioned definitions and domains. The ‘ready-made’ method for the 3Ds values identified above in the Project Characterization step has the following summary details: •

Number of Info types: 22

•

Number of Tasks: 80

•

Number of Sources: 18

•

Number of Techniques: 14

Since each method component is based on an individual task, this means that there are a total of 80 core method components in the pre-selected, pre-assembled, and preconstructed ready-made method for the production of a requirements specification for the custom development of an information system, according to the approach. These method components, within the context of the process framework, and with the assistance of the approach guidelines, provide the basis for the project execution step of the approach, and the conduct of the collaborative and combinational requirements elicitation workshops as described by phase and stage in the subsections below. Due to space limitations it is not possible to detail all the individual method components used in this ready-made method, or their descriptions and individual steps, however we have attempted to illustrate the general sense of the resultant workshops by presenting a concise summary and simple examples. 5.1 The Scoping Phase The most important part of the Preparation stage of the Scoping phase (6 method components) involves the task of identifying the relevant stakeholder sources for participation in the Scoping workshop. Typically these sources would include the project sponsors, i.e. the people paying for the project, upper management of the same organization, and key members of the project team such as the project manager. Furthermore, any and all available external documentation sources relevant to the project should be reviewed such as the organizations marketing material and website. An example of a method component for this phase and stage can be seen in Table 2. Table 2: Scoping Preparation Method Component – ‘Gather preliminary info’ Class

Details

Task

Gather preliminary info

Info Type

All info types

Source

Project sponsors, Executive management, Project manager, External documentation

Technique

Informal discussions, Unofficial observations, Document analysis

146



During the Performance stage (11 method components), the participating stakeholder sources perform tasks to describe the problem, the mission, and the vision for the project, in addition to defining the boundaries for both the project and the system, i.e. what is in and out of scope. Furthermore high-level goals for both the project and the system are established, and key assumptions and constraints are identified. It is also at this point that the major risks, opportunities, and challenges are identified, and stakeholders for the High-level and Detailed workshops are determined. A number of techniques are prescribed for these tasks including Brainstorming, Questionnaires, and Goal Decomposition. Presentation for the Scoping phase (6 method components) consists of documenting the results of the workshop sessions, checking these informally for quality, and then distributing the resultant Vision & Scope document (Wiegers, 2003) to the workshop participants for review and feedback either as a group as a walkthrough, or individually as an inspection. 5.2 The High-level Phase In addition to reviewing all the available high-level internal documentation sources relevant to the project such as organization charts and departmental reports, the Preparation stage of the High-level phase (6 method components) also requires the analyst to observe and take notes at a high-level on the existing work processes and system operations relevant to the target system and the established scope. This enables the analyst to achieve a basic understanding of the business processes and therefore guide the subsequent workshop more intelligently that knowledge. The Performance of the High-level workshop (15 method components) involves firstly the tasks of reviewing and refining the information elicited from the Scoping workshop. In addition to the project team, High-level workshops also typically include domain experts (or subject matter experts), middle management, and key user representatives as sources. During this stage, the system environment is examined in detail, and the main work processes, features, and capabilities of the target system are identified and described. This can be performed using a variety of techniques including Brainstorming, Questionnaires, Domain Analysis, Viewpoint Definition, Repertory Grids, Card Sorting, and Laddering. An example of a method component for this phase and stage can be seen in Table 3 below. Table 3: High-level Execution Method Component – ‘Determine system goals’ Class

Details

Task

Determine system goals

Info Type

Goals

Source

Project sponsors, Executive and middle management, Project manager and team, Domain experts, Key user representatives

Technique

Brainstorming, Questionnaire, Goal decomposition

Like the previous phase, the High-level Presentation stage (6 method components) consists of documenting the results of the workshop sessions, informal quality checking, and then distribution and review, except this time in the format of a Concept of


147


Operations (ConOps) document (IEEE, 1998a). Approval (review and update) of the High-Level document, as with the Scoping and Detailed documents, may required several iterations depending on the effectiveness of the workshops, commitment of the stakeholders, and the complexity of the project. 5.3 The Detailed Phase A major task of the Preparation stage for the Detailed phase is not only to review detailed internal documentation sources such as work instructions and system manuals, but the analyst is also required to observe and take detailed notes on the existing work processes and system operations identified in the High-Level phase. As the participants for the Detailed workshops will typically include supervisors, end users, and developers, it is important that the analyst is very familiar with the specific tasks that must be supported by the target system. During the Performance stage (18 method components), it is necessary for participating stakeholders to review the results from the Scoping workshop in order to understand the objectives and constraints of the current project and target system. Then the work processes, features, and capabilities identified in the High-level workshop are examined in detail with the relevant stakeholder and user sources. Each work process is decomposed into individual steps with exceptions and extensions using Use Cases or Scenario Analysis. Likewise each feature and capability is further decomposed into individual functional and non-functional requirements once again using a combination of Questionnaires, Goal Decomposition, and Viewpoint Definition requirements elicitation techniques. The same process is followed once again for the Presentation stage of the Detailed phase (6 method components), however the format is that of a full System Requirements Specification document (IEEE, 1998). Given that this document is substantially more detailed than the previous documents, and involves many project stakeholders, approval can often take considerably more iterations and time. This is particularly the case when the document is to be used as part of a contractual agreement between a customer and supplier. An example of a method component for this phase and stage can be seen in Table 4 below. Table 4: Detailed Presentation Method Component – ‘Validate info quality’ Class

Details

Task

Validate info quality

Info Type

All info types

Source

All relevant stakeholders, All workshop participants

Technique

Inspection, Walkthrough

6

Discussion

It is important to remember when developing a situational approach for an activity like requirements elicitation that a number of delicate balancing acts naturally take place. One of these is between the flexibility and the rigor within the approach. Another is the risk of being too specific, and hence limiting the applicability of the approach to only a small number of situations, against the risk of being too abstract, and

148



therefore reducing the ability of the approach in providing the necessary support. Furthermore, requirements elicitation in particular is not a stand-alone process, but interrelated and interleaved with other development activities such as system design. As a result we have endeavoured to provide the analyst with several ways of customizing the approach. This not only includes the ability to engineer situation methods for requirements elicitation from scratch, but also the capability to tailor these and ready-made methods throughout the process. These are supported by a process framework and detailed guidelines for each step of the approach, which the analyst can adopt completely, partially, or disregard altogether. Where possible we have attempted to conform to, or at least not conflict with, recognized ME practices, such as the research identified in Section 3, to guarantee a level of consistency. Although our focus has been on the early stages of requirements elicitation, we have been careful to ensure that the fundamental ME concepts used can be adapted and applied to other software development activities and range of process models that acknowledge the iterative and incremental nature of requirements elicitation. Within the approach, the actual execution of the requirements elicitation project is mainly task driven, in order to optimize the process through structure and sequence. However, construction of the method is largely info type driven for the sake of completeness of the process. Rather than causing a conflict, these task driven and info type driven situations actually ensure that the overall approach is both effective (all the required info types are included and elicited) and efficient (tasks are performed productively and systematically). Although the tasks, info types, sources, and techniques of the workshops in the three recommended phases are significantly different, the entire activity is closely integrated and concentrated on the common objective of producing a complete, correct, consistent, and clear documented set of requirements for the target system with supporting information.

7

Conclusions

The lightweight approach for requirements elicitation presented in this paper provides a number of potential benefits over existing ones. It is both extensible and flexible in that it provides detailed guidelines for each step of the approach, and the ability to engineer and tailor situational methods based on specific project characteristics. Implementation of the approach does not require significant expertise or substantial experience, nor is it depended upon the utilization of any other systems development process. As a result the approach is particularly suited to novice analysts and those projects lacking a defined software development process, as it provides a high-level of guidance and instruction, and offers the necessary framework to ensure an efficient process, and effective results. The execution of the approach takes advantage of both collaborative elicitation by being workshop centric, and the combination of multiple techniques in support of and integrated within the requirements elicitation workshop environment. As part of the approach we have introduced a number of useful and novel concepts including that of a ‘method component’ representing a task based method building block, and ‘ready-made’ methods that provide the analyst with a pre-constructed situational requirements elicitation process for the specific project at hand. Tailoring of the resultant methods can be performed throughout the process, even during performance of the requirements elicitation workshops themselves.


149


We believe that this research presents both researchers and practitioners of software development projects with an effective, efficient, useful, and useable requirements elicitation approach for this complex and critical activity. Furthermore, we are of the opinion that the approach described produces requirements elicitation methods that are profitable in terms of offering value for effort, therefore encouraging its acceptance and adoption into industry by organizations and analysts.

8

Future Work

The next step of this research, which is currently underway, is the development of a tool that embodies the complete approach, making it even more attractive, useful, and useable to analysts. The tool represents both a Computer Aided Method Engineering (CAME) and a Computer Aided Software Engineering (CASE) software based system, containing database driven method and project repositories. By utilizing webbased technologies, the tool and subsequently the approach can be used to support distributed requirements elicitation, where stakeholder groups are situated in different geographic locations across multiple time zones. Just as important, the approach and tool needs to be evaluated through industrial case studies in a variety of situations. Ideally this will be performed for a number of different application domains, in diverse project conditions, with analysts and stakeholders of varying levels of experience and expertise. It is expected that these evaluations will provide evidence as to the efficiency and effectiveness of the approach, and its applicability to various domains. The results can then be used to refine and expand the approach to better support a wider range of requirements elicitation contexts.

References BALL LJ and ORMEROD TC (2000) Putting ethnography to work: the case for a cognitive ethnography of design. International Journal of Human–Computer Studies 53(1), pp. 147-168. BEYER HR and HOLTZBLATT K (1995) Apprenticing with the customer. Communications of the ACM 38(5), pp. 45-52. BRINKKEMPER S (1996) Method engineering: engineering of information systems development methods and tools. Information and Software Technology 38, pp. 275-280. BRINKKEMPER S, SAEKI M and HARMSEN F (1998) Assembly Techniques for Method Engineering. CAiSE’98, LNCS 1314, pp. 381-400. CHRISTEL MG and KANG KC (1992) Issues in Requirements Elicitation. Carnegie Mellon University Technical Report, CMU/SEI-92-TR-012. DARDEENE A, VAN LAMSWEERDE A and FICKAS S (1993) Goal-Directed Requirements Acquisition. Science of Computer Programming 20(1-2), pp. 3-50. DAVIS GB (1982) Strategies for information requirements determination. IBM Systems Journal 21(1), pp. 4-30. GOGUEN JA and LINDE C (1993) Techniques for Requirements Elicitation. International Symposium on Requirements Engineering, pp. 152-164, January 4-6, San Diego, CA. GOTTESDIENER E (2002) Requirements by Collaboration: Workshops for Defining Needs, Addison-Wesley, USA.

150



HENDERSON-SELLERS B (2002) Process Metamodelling and Process Construction: Examples Using the OPEN Process Framework (OPF). Annals of Software Engineering 14. HICKEY AM and DAVIS AM (2002) The Role of Requirements Elicitation Techniques in Achieving Software Quality. REFSQ’02, September 9-10, Essen, Germany. HICKEY AM and DAVIS AM (2003) Requirements Elicitation and Elicitation Technique Selection: A Model for Two Knowledge-Intensive Software Development Processes. Hawaii International Conference on System Sciences, January 6-9, Big Island, Hawaii. HUDLICKA E (1996) Requirements Elicitation with Indirect Knowledge Elicitation Techniques: Comparison of Three Methods. International Conference on Requirements Engineering, pp. 4-11, April 15-18, Colorado Springs, CO. IEEE (1998) Std 830 Recommended Practice for Software Requirements Specifications. IEEE (1998a) Std 1362 System Definition - Concept of Operations (ConOps) Document. KOTONYA G and SOMMERVILLE I (1998) Requirements Engineering: Processes and Techniques. John Wiley & Sons, Great Britain. KURTZ T (2001) Ask Pete, Software Planning and Estimation through Project Characterization. International Symposium on Requirements Engineering, pp. 286, August 27-31, Toronto, Canada. MAIDEN NAM and RUGG G (1994) Knowledge Acquisition Techniques for Requirements Engineering. Requirements Elicitation for Systems Specification, July 12-14, Keele, UK. MAIDEN NAM and RUGG G (1996) ACRE: selecting methods for requirements acquisition. Software Engineering Journal 11(3), pp. 183-192. MAIDEN N, MANNING S, ROBERTSON S and GREENWOOD J (2004) Integrating Creativity Workshops into Structured Requirements Processes. Designing Interactive Systems, August 1-4, Cambridge, MA. OPF (2005) OPEN Process Framework. http:// www.opfro.org [Accessed 22 July 2005]. POTTS C, TAKAHASHI K and ANTON A (1994) Inquiry-Based Requirements Analysis. IEEE Software 11(2), pp. 21-32. RALYTE J and ROLLAND C (2001) An Assembly Process Model for Method Engineering. CAiSE 2001, LNCS 2068, pp. 267-283. RALYTE J, DENECKERE R and ROLLAND C (2003) Towards a Generic Model for Situational Method Engineering. CAiSE 2003, LNCS 2681, pp. 95-110. SOMMERVILLE I and SAWYER P (1997) Requirements Engineering: A Good Practice Guide. John Wiley & Sons, Great Britain. SOMMERVILLE I, SAWYER P and VILLER S (1998) Viewpoints for Requirements Elicitation: A Practical Approach. International Conference on Requirements Engineering, pp. 7481, April 6-10, Colorado Springs, CO. SUTCLIFFE A and MAIDEN N (1998) The Domain Theory for Requirements Engineering. IEEE Transactions on Software Engineering 24(3), pp. 174-196. WIEGERS KE (2003) Software Requirements. Microsoft Press: USA. ZOWGHI D and COULIN C (2005) Requirements Elicitation: A Survey of Techniques, Approaches, and Tools. In Engineering and Managing Software Requirements (AURUM A and WOHLIN C, Eds), Springer: US.


151

Panta Rho: Personal before Business in Changing Requirements Priorities Johan F. Hoorn and Mark E. Breuker

Vrije Universiteit, Computer Science Abstract We investigated the effect of changes in business and personal goals on prioritizing a list of functional requirements. Science students (N= 154) rank ordered 16 requirements on an elearning system, Didactor,1 presented to them as possibly replacing the currently used Blackboard system.2 Technology change was motivated either as the result of a change in the business model of the university or as the result of personal interviews with a number of science students. In the business condition, the requirements list was presented to the students as primarily supporting the new business goals; in the personal condition, the same requirements list was presented as primarily supporting the students’ goals. Particularly when the students prioritized the requirements in view of changes that impacted their personal goals, the priorities of requirements changed more than when looking from the business perspective – although the requirements were functionally the same. Whether the new system would support the more egotistically oriented goals (e.g., increase job market value) or the more altruistically oriented goals (e.g., being better educated so to help society) did not have a significant effect. This calls for a personal approach when developing new technology and introducing it to the workfloor rather than inspiring the design and use of the new system with a salute to the latest mission statement. Based on Spearman’s rho, we, moreover, provide four ways to calculate priority change, which can be used as dependent variables in (multivariate) analyses of variance. Keywords: Requirements, Priorities, Change, Business, Goals, Measurement

1

Introduction

Panta rhei, all moves, not only in the classic world of the Greek but also in the requirements on a new information system. Stakeholders disagree on what a system should offer. They show inconsistencies between goals that should be achieved with the system (Van Lamsweerde, 2004). Moreover, requirements change as an effect of evolving business models (Highsmith and Cockburn, 2001; Cockburn and Highsmith, 2001) and part of this change is reflected in a different prioritization (Lam et al., 1999). To stabilize the different stakeholder views and goals, requirements prioritization may serve as input for requirements negotiation (Moisiadis, 2002). Prioritizing requirements is functional for selecting the features that must or won’t be implemented (cf. a MuSCoW classification: Must, Should, Could, Won’t). Moreover, prioritization according to a cost-value analysis (Karlsson and Ryan, 1997) can indicate the expected return on investment. In the literature, requirements are prioritized on several criteria, which involve different types of metrics. Requirements are scored on a rating scale for importance to the customer (e.g., 1-least important to 10-crucial) (Lam et al., 1999). They are prioritized on the basis of urgency (development time until release) (ibid) as well as effort 1 2

http://www.didactor.nl/demo/demo.html http://bb.vu.nl/webapps/portal/frameset.jsp

152


Hoorn and Breuker

(the work needed to develop and implement a feature) (ibid). Important methods in requirements prioritization, such as the Analytic Hierarchy Process (AHP) as applied to cost-value trade-offs (Karlsson and Ryan, 1997), analyze pair-wise comparisons of a set of requirements. Priority of a feature is based on estimated cost to implement a feature against estimated value of importance to the stakeholder(s) (ibid). In scoring requirements on ordinal scales, Quality Function Deployment (QFD) (Akao, 1990) tries to align customer requirements with design parameters. Wiegers Prioritization Model (WPM) is rooted in a combination of AHP and QFD.3 Wiegers conceives of the relative priorities of features as a combination of benefit to the customer versus the risk for the designer to receive ‘punishment’ if the feature is left out as well as the relative cost versus the technical risk to implement the feature (Wiegers 1999). The Requirements Prioritization Tool (RPT) (Moisiadis, 2002) makes use of questionnaires and rating scales to assess the stakeholders’ attitudes to both business objectives and requirements. For a critical discussion of AHP, QFD, and WPM as well as an explanation of RPT, see (Moisiadis, 2002). The above mentioned methods of prioritizing requirements all focus on establishing the requirements of one specific system in one specific organization. These approaches are important to engineer the precise features of a system in a real business case. However, when business models change, the requirements analysis has to start all over again (Moisiadis, 2002), which may be a tedious and frustrating job. This calls for an approach that renders more general knowledge of where to look for priority changes. If we know what particular types of stakeholder views or business goals are vulnerable to change, we can bring more focus to requirements reanalysis, i.e. priority change. Based on work by (Hoorn and Van der Veer, 2003a; 2003b), we examined whether and how changing business models impact requirements priorities. Moreover, we explored whether changes in the personal goals (cf. ‘agent’s intentions’ (Gross and Yu, 2001) of the stakeholders also affect changes in requirements priorities. Large non-profit and governmental organizations like our university tend to be remodeled after commercial businesses. We envisioned business model change in a non-profit institute as shifts between goals that are more focused on the continuity and prosperity of the organization itself (egotistic business goals – Be) and goals oriented towards others than the organization (altruistic business goals – Ba), such as dispensing knowledge to the world, educating people, and improving the quality of life. We predicted similar effects of personal goals. Whether an information system is wanted for gaining more personal influence (egotistic personal goal – Pe) or for helping colleagues with their work (altruistic personal goal – Pa) may seriously affect the priorities on the requirements list. In line with (Hoorn and Van der Veer, 2003a; 2003b), we hypothesized (H1) that changes in business goals predicate changes in (the priorities of) features on the requirements list. The same may be valid for changes in personal goals. Under different conditions of goal change, stakeholders may attribute different relevance (important unimportant) to system features. Changes in business and/or personal goals may impact the priorities of features on the requirements list, which can be regarded as an aspect of requirements change. In MuSCoW terms, low ranking features in one goal condition that move to the top of the requirements list under another goal condition 3

http://www.processimpact.com/process_assets/ requirements_prioritization_worksheet.xls


153

Changing Requirements Priorities

are features the system Must or Should have to adapt to the changed situation. Features in one goal condition that move to the bottom of the list under another goal condition are features that the system now perhaps Could have or even Won’t have any more. As suggested by (Hoorn and Van der Veer, 2003a; 2003b), we also hypothesized (H2) that business goals can change from a more egotistic (e.g., fire more staff) to a more altruistic nature (e.g., educate students) and vice versa. Similarly, personal goals can also change from egotistic (e.g., gain influence) to altruistic (e.g., help colleagues) and back again. In the field experiment we conducted, the factor Stakeholders’ View (cf. IEEE 1472, 2000) indicated whether the concerns of the stakeholders were business or personal. The factor of Direction of Goal Change indicated whether the business or personal goals changed from egotistic to altruistic or the other way round. In the remainder of this paper, we will report whether Stakeholders’ View and the Direction of Goal Change in business and personal situations altered requirements priorities.

2

Method

2.1 Participants and Design From a database of 1005 science students at the Free University of Amsterdam, 968 students were randomly selected and divided into 4 groups of 242 in such a way that each group contained an equal number of students from the same year and field of study (Breuker and Hoorn, 2004). Students served as volunteers. For each student, the year of enrollment and field of study was administered. To balance the number of students over studies, only recent years were used. Therefore, students from the year 1999 and earlier were dismissed from participation. Students from different studies were assigned to four conditions of goal change: 1.

Business goals, from egotistic to altruistic (Be→a)

2.

Business goals, from altruistic to egotistic (Ba→e)

3.

Personal goals, from egotistic to altruistic (Pe→a)

4.

Personal goals, from altruistic to egotistic (Pa→e)

Thus, the experiment consisted of a 2 (Stakeholders’ View: Business vs. Personal) by 2 (Direction of Goal Change: Egotistic-to-altruistic vs. Altruistic-toegotistic) between-subjects factorial design. For each group, an online survey was developed to measure requirements priority change under one of the conditions of goal change. The four surveys each contained two pages (for details, see Breuker and Hoorn, 2004). Each page presented a text that contained one type of goal (either Be, Ba, Pe or Pa), called the Motivation, and a 5-point Likert item about the student’s global personal attitude towards the Motivation. The Motivations were made up by the experimenters. In the Be condition, the Motivation focused on the university’s ambition to play a pre-eminent role in developing the knowledge economy. Therefore, the university wanted to deliver top-qualified students to the market. For the university to acquire European subsidies, the university

154


Hoorn and Breuker

aimed at improving student performance by introducing the new e-learning environment. In the Ba condition, the Motivation emphasized the university’s societal responsibility in developing the knowledge economy. Therefore, the university wanted to deliver top-qualified students to the market. To make sure that European subsidies would be beneficial to the students, the university aimed at creating a stimulating environment by introducing the new e-learning system. The Motivation in the Pe condition stated that earlier interviews among the student population showed that students wanted to profit from the advancing knowledge economy. Therefore, the university wanted to deliver top-qualified students to the market. For the students to get a top job, so the interview results showed, students thought that governmental subsidies should be invested in new technology and learning materials that support the students in their studies. In the interviews, the said new e-learning system was designated as the best alternative. In the Pa condition, the Motivation declared that – in view of earlier interviews – the students felt responsible for advancing the knowledge economy. The students thought that the money invested in their education should also show some returns to society. Therefore, new technology and learning materials were needed for the students to support one another. In the interviews, the said new e-learning system was designated as the best alternative. The Motivation and Likert attitude item were followed by a requirements list of 16 features (Breuker and Hoorn, 2004) of a new e-learning system, Didactor (Didactor, 2003), that was to replace the current Blackboard system (Blackboard, 1997-2005). The requirements list was derived from prior analysis of the Didactor system. Examples of the proposed features were: Chat box for students and teachers, Discussion forum, Web mail, Portfolio of personal development, Work team support, etc. The goals described in the Motivation could be either egotistically (Be or Pe) or altruistically (Ba or Pa) oriented. If the business goals in the Motivation on the first page were egotistically oriented then the goals on the second page were altruistically oriented (Be→a). If the business goals in the Motivation on the first page were altruistically oriented then the goals on the second page were egotistically oriented (Ba→e). The same procedure was followed for personal goals (Pe→a vs. Pa→e). For groups 1 and 2, goals were presented as the university’s (fictitious) business goals, which motivated the features on the requirements list. For groups 3 and 4, the goals were personally oriented and introduced to the students as the outcome of a series of (fictitious) interviews among a sample of science students. The requirements remained the same under each condition of goal change. However, the presentation order of requirements from top to bottom was randomized and hence, different for each student and within students, different between the two goal conditions. 2.2 Procedure An e-mail message (Breuker and Hoorn, 2004) was sent out to the students, containing (1) the announcement of the possible introduction of a new Learning Management System, Didactor, as a replacement for the current Blackboard system, (2) the notice that the needs of the students would be evaluated through a survey before the introduction would take place, and (3) a request to fill out the survey via a personalized hyperlink. While taking the survey, the features in the requirements lists were automatically presented to the students in random order. Students were asked to rank order the features


155


for relevance (the actual word used was ‘importance’). They were encouraged to work quickly so to avoid ties between the first and second list. Upon completion of the survey, the students were shown a short debriefing message. In total, 968 e-mail invitations were sent out. This yielded a response from 154 people of which 131 only ranked the first list (i.e. completed the first page of the survey). The number of responses in each group varied only slightly. The survey was developed and deployed using the PollPoint online survey tool (PollPoint, v7.6.1). 2.3 Measurements Participants put priority scores (1= top priority, 16= no priority) to requirements in the list under the different conditions of goal change Be→a, Ba→e, Pe→a, and Pa→e. Moreover, they rated their global attitude to the business goals or personal goals on a single-item 5-point rating scale (1= negative, 5= positive). We approached the problem of calculating changes in the priorities of requirements in four ways. 2.3.1

Measure (ρs1)

Priority change (the change in priority of requirements under different goal conditions) was established using Spearman’s rho (rs or ρs), which is a rank order correlation coefficient that analyzes whether a bivariate set of paired rankings correlates by rank sum. Spearman’s rho was calculated on the ranks of priority scores that the participants attributed to the features on the requirements list in Be→a, Ba→e, Pe→a, and Pa→e. The measure ρs was used as the operationalization of priority change, which assumingly reflects an aspect of requirements change. The closer ρs approached +1, the higher the agreement between the two sets of ranked features (no priority change). The closer ρs approached -1, the higher the disagreement between the two sets of ranked features (priority change). We predicted that under the influence of changes in the business goals or personal goals, the change in priorities of features in the requirements list will be large, which is reflected in a high disagreement (-1 ≤ ρs < 0) between the two sets of ranked features in, for example, Be→a. To calculate this measure, we used the data of 103 students who filled out both priority lists and neglected the data of those who prioritized the first list alone. Eleven students who ranked the features on both lists exactly the same where filtered from the data set (see Measure 2 for rationale). 2.3.2

Measure (ρs2)

We suspected that the manipulation might have a weak impact, allowing for more-orless the same priority scores between lists. In that case, Measure 1 is too insensitive to indicate priority change. For each student, therefore, we filtered out those features that received the same priority score and additionally, used only those features that contributed maximally to ρs approaching -1. This was accomplished by calculating the squared differences between the features of both lists and selecting the 10 features with scores closest to ρs = -1. A minimum of 10 rank order pairs is required for ρs’s critical values to be allowed between -1 and 1 (Lowry, 2005). This operation seems to be begging the question but this is not so. The features that were filtered out are indeed important to the requirements engineer because they seem to be unaffected by personal or business goal change. If these are the same features throughout a stakeholder group, they reflect stable requirements and need to be implemented in the new

156


Hoorn and Breuker

system if they are high on the priority list. However, our research question was how changes in personal and business models (i.e. goals) affected priority change. Thus, we needed to establish change in order to study the effects of personal and business goals. Probably, on each requirements list there is a subset of features that is not sensitive to goal change and one that is. The latter subset can comprise of different features for different people. We even went so far, in order to establish priority change, to filter 11 students with stable requirements (list 1 and 2 were ranked the same) from the sample. 2.3.3

Measure (ρs3)

We also calculated the feature to feature rank-order total-scores. To do so, we used the data of all the 154 students who rank-ordered at least the first list of requirements. Measure 3, then, utilized data from a larger sample of students than Measure 1 and Measure 2. We took the data of the students who filled out the first list, whereas possible data obtained by the second list were discarded. We then computed a rank-order total-score in condition Be (business egotistic goals), Ba (business altruistic goals), Pe (personal egotistic goals), and Pa (personal altruistic goals). For each feature, the sum of rank-order scores was computed across all students in a condition (e.g., Be). For example, if Be had 5 students, and these 5 students attributed the scores 1, 3, 1, 6, 9 to a feature, the sum total for this feature was 20. If these 5 students all had attributed the score 1 to this feature, the sum total was 5. If for all 5 students this feature was put in the 16th place, the sum total was 80. On the basis of the rank-order total score per feature (which were between 91 and 576), we then rank-ordered the 16 features from the lowest to the highest rank-order total score. Subsequently, we replaced the actual rank-order total score by the rank order number of their relative position in this general priority list. The feature with the lowest rank-order total score received a 1 and the feature with the highest rank-order total score received a 16. The feature to feature rank-order total-scores were established by calculating, for each student in a condition, ρs between •

Be (as based on the raw data) and the revised Ba (as based on the rank-order total scores)

•

Ba (as based on the raw data) and the revised Be (as based on the rank-order total scores)

•

Pe (as based on the raw data) and the revised Pa (as based on the rank-order total scores)

•

Pa (as based on the raw data) and the revised Pe (as based on the rank-order total scores).

In Measure 3, we compared the requirements priorities of each student under one condition with the general requirements priorities of the whole group of students in another condition. The rationale was that if the students in one group showed the same rank-ordering behavior as the group in general in another condition, then there was no change in requirements priorities under conditions of different personal or business goals. If, on the other hand, the students in one group disagreed with the general rank-ordering behavior of a group in another condition, then there was change in requirements priorities. This approach somewhat resembles (Regnell et al., 2001),


157


who used Spearman correlations between individual stakeholder’s priorities and group priorities to indicate stakeholder satisfaction. 2.3.4

Measure (ρs4)

We combined the approaches of Measure 2 and 3 to arrive at Measure 4. We followed the same procedure as explained for Measure 3 but we excluded those features that received the same rank-order score on both lists. Here also, we selected the 10 features that guaranteed the maximum approach of ρs to -1.

3

Results

We ran four separate between-subjects ANOVAs of 2 (Stakeholders’ View: Business vs. Personal) * 2 (Direction of Goal Change: Egotistic-to-altruistic vs. Altruistic-toegotistic) on one of the four measures of change in requirements priorities as based on Spearman’s rho (ρs1, ρs2, ρs3, ρs4). Year of enrollment, field of study, whether or not both lists in the survey where rank ordered, and attitude to the relevant personal or business goals served as covariates. The only significant result was found for Stakeholders’ View with Measure 3 (ρs3). The means for ρs3 in the four conditions of the experiment are shown in Table 1. Table 1: Mean ρs3 for Stakeholders’ View and Direction of Goal Change (N= 154). Stakeholders’ View

Direction of Goal Change

Mean ρs3

SD

n

Business

Egotistic to altruistic

.59

.18

36

Altruistic to egotistic

.61

.24

39

Egotistic to altruistic

.56

.39

43

Altruistic to egotistic

.40

.55

36

Personal

Table 1 illustrates that students who ranked the requirements from the viewpoint of personal goals showed more priority change (mean ρs3 = .48) than respondents who prioritized the requirements from a business perspective (mean ρs3 = .60). This difference was underscored by a significant main effect of Stakeholders’ View (Business vs. Personal), F(1, 146) = 4.09, p < .05, ηp2 = .03. It should be noted that the effect is not strong. To gain more degrees of freedom, we ran another 2*2 ANOVA on ρs3 but this time while excluding the covariates. The results improved, but only slightly: Stakeholders’ View (Business vs. Personal), F(1, 150) = 4.36, p < .04, ηp2 = .03. A stronger manipulation in a real business case may improve the effects even more.

4

Conclusions and Discussion

We described an experimental study of students ranking requirements features for a distance learning application, according to the type of business or personal goals they

158


Hoorn and Breuker

were given. Our hypothesis was that personal stakeholder goals have a greater impact on priority changes than business goals. By using four different variants of rank order correlation, priority changes were measured in four different ways. One measure showed to render significant effects, indicating that requirements change might be more subjective to changes in personal than business goals. The instruments were based on requirements on a particular hypothetical system transition in a university setting. We established some interesting results that should be taken into account by designers using goal-oriented requirements engineering. We proposed a new empirical approach to assess how different types of requirements may impact priority changes over time. The idea of combining goals and features and classify them as egotisticaltruistic vs. business-personal seem novel and relevant. The research question of investigating the underlying reasons for priority change also seems relevant because it attempts to investigate viewpoints influence (IEEE 1471, 2000) on requirements priorities. In our experiment, students prioritized 16 features of a possible new e-learning system under four different conditions of goal change (Be→a, Ba→e, Pe→a and Pa→e). H1 expected to see a difference in the rank ordering of the requirements when the business (B) or personal (P) goals that were presented to the students (the stakeholders in our experiment) changed. Indeed, the main effect of Stakeholders’ View showed that priority change in the requirements list was significantly stronger under conditions of personal goal change (mean ρs3 = .48) than under conditions of business goal change (mean ρs3 = .60). We also changed business and personal goals from egotistic to altruistic (and vice versa) but we did not obtain significant effects of Direction of Goal Change on prioritizing the requirements, although this was expected by H2. Taken together, the priority of a requirement was particularly vulnerable to changes in personally oriented goals rather than to the type of goals that were changed (whether from egotistic to altruistic or v.v.). In changing requirements priorities, then, personal goes before business. We recognize that the manipulation we used was not strongly interfering with the students’ concerns. We tried to influence goal change by confronting the students with different personal or business motivations. Perhaps this is why the effects of egotistic vs. altruistic goal change did not affect the prioritizing behavior. That the students probably attached little relevance to the issue is also illustrated by the somewhat low response rate. With Measure 3, the total of 154 responses out of 968 invitations could be used, but this is a mere 16%. Yet, for the analysis of variance, this is not too severe because these 154 cases were divided over merely four cells with n > 35, which is sufficient. At this moment, we are conducting a similar experiment under conditions of higher relevance to stakeholder concerns in a real business case. The effect of Stakeholders’ View (Business vs. Personal) on priority change was established using Measure 3. However, using four different measures seems somewhat arbitrary and there might be a risk of fishing for significance by constructing new measures to fit the goal of reaching significance. True as this may be, the RE literature is not particularly helpful in this respect and new methods need to be explored and compared to decide for the most sensitive measure. We believe that Measure 3 was the best among the four measures we developed. It was the only measure that did not use the data of the second requirement lists. Sometimes students complained in a reply e-mail that they did not see the purpose of ranking the proposed


159


features twice. In other words, data obtained with the second requirements lists might have suffered from fatigue and training effects. Measure 3 was not affected by such a contamination. Another strongpoint of Measure 3 is that it used the data of more students (N= 154) than just those who completed ranking both requirements lists (n= 103). This by no means releases us from the burden of verifying the measure’s validity in a replication study, which we are doing right now. Because few significant results were found, consequently it might seem that the conclusions are a bit weak. It can be countered, however, that on the contrary, the results are quite strong as only one effect showed significance, whereas all others failed. In view of theoretical parsimony and robustness of effects, H2 can be dismissed in favour of H1, which is corroborated by an effect that occurs despite unfavourable circumstances such as low relevance in a rather hypothetical experimental set up. The other effects were not that strong. Nonetheless, we should be careful in drawing general conclusions. Although it seems reasonable that a first step is testing hypotheses on students, the results may be valid for just students and instruments in this one domain but not for professional requirements engineering in arbitrary domains. Therefore, we are conducting another rank ordering experiment on the e-learning environment Didactor in a financial management buy out of one of the Big Four computer companies. Because of the ensuing changes in the business model of this new organization, this seems an excellent place to investigate the effects of goal change on requirements prioritization in the real world. In requirements engineering, it is good practice to relate requirements to goals (e.g., Van Lamsweerde, 2004). In most of the cases, however, special attention is paid to requirements as related to business goals (e.g., Highsmith and Cockburn, 2001; Cockburn and Highsmith, 2001; Moisiadis, 2002; Karlsson and Ryan, 1997). Yet, our theoretical (Hoorn and Van der Veer, 2003a; 2003b) and empirical work (Hoorn and Kok, 2005) suggests that personal goals of the system stakeholders are equally or even more important in explaining requirements change (also Gross and Yu, 2001). The effects of Stakeholders’ View on changes in requirements priories in this study is another point in case. The requirements list in our experiment was the same throughout conditions. Only the motivation was altered, indicating a change in goals that affected the business’s or the students’ personal situations. Particularly when the focus was on changes in the students’ personal situation, the urge to interfere with the priorities of requirements was stronger. Thus, on the one hand, when stakeholders are confronted with the consequences of the same system features for their own personal circumstances, they want to change the priorities. On the other hand, when business goals are changing, stakeholders do not change their priorities. Perhaps they think that it is of no use to interfere with whatever priorities when the business has already decided for. Consequently, when a business introduces new technology top down without consulting the workfloor, it may surprise the management that nobody is complaining. That does not mean, however, that employees agree to the system as is or do not have different priorities. Panta rho.

Acknowledgements This paper is part of the Innovation Oriented research Program (IOP) for HumanMachine Interaction entitled Integrating Design of Business Processes and Task

160


Hoorn and Breuker

Analysis, granted to the first author by the SenterNovem Agency of the Dutch Ministry of Economic Affairs in The Hague, grant Mmi99009. We thank the anonymous reviewers for considerably adding to the discussion.

References AKAO Y (1990) Quality function deployment QFD: Integrating customer requirements into product design. Productivity Press, Cambridge, MA. BLACKBOARD (1997-2005) Blackboard Inc., WA. BREUKER ME and HOORN JF (2004) The e-learning hoax: Didactor versus Blackboard. Tech. Rep., Information Management and Software Engineering, Free University, Netherlands. COCKBURN A and HIGHSMITH J (Nov 2001) Agile software development: The people factor. IEEE Computer, 131-133. DIDACTOR (2003) The Mediator Group, Amsterdam. GROSS D and YU E (2001) Evolving system architecture to meet changing business goals: An agent and goal-oriented approach. ICSE-2001 workshop: From software requirements to architectures (STRAW 2001), pp. 13-21, Toronto, Canada. HIGHSMITH J and COCKBURN A (Sept 2001) Agile software development: The business of innovation. IEEE Computer, 120-122. HOORN JF and KOK E (2005). Requirements validation of a capacity management system at the Dutch police force. Tech. Rep., Information Management and Software Engineering, Free University, Netherlands. HOORN JF and VAN DER VEER GC (2003a) Requirements analysis and task design in a dynamic environment. In Proceedings of HCI International 2003 (HARRIS D, DUFFY V, SMITH M and STEPHANIDIS C, Eds), pp. 472-476, Erlbaum, Mahwah, NJ, USA. HOORN JF and VAN DER VEER GC (2003b) Requirements engineering for groupware to manage business process dynamics and stakeholders’ mindset. In Proceedings of the 9th European conference on cognitive science approaches to process control: Cognition and collaboration - distributed cognition in complex processes (VAN DER VEER GC and HOORN JF, Eds), pp. 153-160, Free University, Amsterdam, NH, NL. IEEE 1471 (2000) IEEE recommended practice for architecture description. KARLSSON J and RYAN K (Sept-Oct 1997) Prioritizing requirements using a cost-value approach. IEEE Software, 67-74. LAM W, SHANKARARAMAN V and SAWARD G (1999) Requirements change: A dissection of management issues. In Proceedings of the 5th international workshop on requirements engineering: Foundations of software quality REFSQ99, Heidelberg, Germany. LOWRY R (2005) Spearman rank order correlation coefficient. Available at http://faculty. vassar.edu/lowry/corr_rank.html. MOISIADIS F (2002) The fundamentals of prioritising requirements. SETE (the Conference of the Systems Engineering Society of Australia (SESA) and International Test and Evaluation Association (ITEA)), Sydney, Australia. POLLPOINT (V7.6.1) PollPoint online survey’s. Available at http://www.pollpoint.nl.


161


REGNELL B, HÖST M, NATT OCH DAG J, BEREMARK P and HJELM T (2001) An industrial case study on distributed prioritisation in market-driven requirements engineering for packaged software. Requirements Engineering 6, 51-62. VAN LAMSWEERDE A (2004) Goal-oriented requirements engineering: A roundtrip from research to practice. In Proceedings of the requirements engineering conference, 12th IEEE international (RE’04) - volume 00, pp. 4-7. WIEGERS KE (1999) Software requirements. Microsoft Press, Redmond, WA.

162


More than Psychologists’ Chitchat: The Importance of Cognitive Modelling for Requirements Engineering in Complex and Dynamic Environments Constanze Pott a, Fokie Cnossen a and Albert Ballast b a b

University of Groningen, Groningen, The Netherlands University Medical Center Groningen, Groningen, The Netherlands

Abstract Anaesthesiology is practiced within a complex and dynamic socio-technical system that can reach an infinite number of states. Therefore, traditional methods of requirements engineering are not suited to model the tasks and support requirements of the anaesthetist. We introduce an approach for developing decision support systems in anaesthesiology based on cognitive modelling. It is demonstrated that the complexity of the problem space can be reduced to enable the design of a working prototype of a decision support system. This system estimates the cognitive workload of the user, and offers tailored decision support depending on the state of patient. Since anaesthesiology is a typical example of a complex and dynamic environment, the implications of using cognitive modelling for requirements engineering can be transferred to similar contexts. Keywords: Cognitive Modelling, Decision Support System, Anaesthesiology, Requirements Engineering

1

Introduction

In this paper, the implications of complex and dynamic problem spaces for designing decision support systems (DSSs) are exposed. Anaesthesiology is introduced as a representative example of a complex sociotechnical system and as a challenge to designers of DSSs. It is our goal to improve the working conditions of anaesthetists and to increase the safety of patients under anaesthesia by developing a DSS that increases the situation awareness (SA) of anaesthetists. To find out where decision support is most useful, we developed a cognitive process model of decision making in anaesthesiology and integrated the framework of SA into the model. The different parts of the model are explained and how these components are translated into concrete design recommendations. Furthermore, the benefits of using a cognitive model for requirements engineering in the complex and dynamic environment anaesthesiology are exposed.

2

Requirements Engineering in Complex and Dynamic Environments

The process of gathering requirements in system engineering often focuses on the functional requirements of the system to be developed. These are the specifications of the product's functionality and are derived from the fundamental purpose of the product. One typical approach to identify those functional requirements is to describe the future product's actions (Robertson & Robertson, 1999). The relevant context of the product has to be specified and modelled. For every event that might occur, a strategy must be determined of how to react to this event. This normative approach of finding


163

Cognitive Modelling for Requirements Engineering

an optimal solution for a problem to be defined by the system designers works efficiently in many contexts. However, the precondition for this normative approach is that the problem space of the context is finite dimensional and can be determined properly. Many complex systems can reach an infinite number of system states which cannot be anticipated completely by the designers. It is therefore almost impossible to develop a complete model of the contexts that will serve as a base for developing functional requirements. Moreover, any finite set of strategies can only approximate optimal reactions to an infinite set of events. Humans, on the other hand, have the ability to generate new strategies for problem solving. Depending on factors like workload or personal state (e.g. feeling energetic, being fatigue), they decide, according to the situation, which strategy to apply. Even for unfamiliar events, most of the times they can generate an adequate reaction strategy. According to our opinion, it should be the objective in designing complex and infinite systems to enable the users to apply practical strategies by providing them with appropriate information. As an instrument to identify appropriate information, we will introduce a cognitive process model. In this paper we will discuss the benefits of this cognitive model for system engineering. The cognitive model was developed in the setting of developing real-time medical support systems, especially in the field of anaesthesiology. Anaesthesiology is a typical example for a complex and dynamic sociotechnical system, in which common methods for requirements engineering fail. To demonstrate the complexity of anaesthesiology, characteristic features of anaesthesiology are explained next.

3

Anaesthesiology: A Complex Sociotechnical System

During surgery, anaesthetists work in a complex sociotechnical system (Perrow, 1984; Woods, 1988). They are confronted with large problem spaces; the number of relevant factors that anaesthetists and system designers need to take into account is enormous. Unlike most factory plants, patients are not designed to be monitored (Gaba, 1992). Many highly coupled (i.e. interconnected and interacting) subsystems make it difficult to predict all effects of actions or events, or to trace all of the implications of a disturbance caused by a patient problem. Especially in the medical domain, these side effects (e.g. of drug administration) lay a great burden on the anaesthetist because of all the factors that need to be considered simultaneously. We will examine two important subsystems, adding to the complexity of anaesthesiology: the patient and the medical equipment. 3.1 The Patient The patient is a very complex subsystem that contains many components, whose underlying functions are imperfectly understood. The patient system may be disturbed by many factors including his or her illness, surgery, and anaesthesia. The patient can get into an infinite number of states, making it impossible for system designers to anticipate all possible situations. Furthermore, anaesthesia is risky as the patient's vital functions (e.g. breathing) are suppressed. It is the responsibility of the anaesthetist to ensure the patient's well-being and compensate for the effects of surgery and of the anaesthesia. The situation is even more risky as surgery is necessary to treat a

164


Pott, Cnossen, and Ballast

medical problem that in itself may be catastrophic. Unlike in an airplane, which can be kept on the ground in case of problems (Gaba, 1992), many risks cannot be avoided in anaesthesiology. 3.2 The Medical Equipment Another subsystem is the medical equipment that is connected to the patient. Medical equipment is necessary, as the patient's vital functions depend on it. The anaesthesia machine pumps a mixture of oxygen, air, and anaesthetic gas into the lungs of the patient, assuring anaesthesia and the oxygen supply of the patient. Furthermore, monitoring devices are needed to observe the state of the patient as many variables like blood pressure cannot be seen without medical equipment. This causes a large amount of rough data displayed on the monitor that the anaesthetist has to analyze. But even with a large amount of measured and derived data, the state of the patient is typically underspecified by the available indicators (Gaba, 1992). There may be uncertainty about the state of the patient, as the state of the patient cannot be determined totally. It is e.g. nowadays difficult and unusual to measure the total blood volume or the depth of anaesthesia, although this information is highly relevant for administering anaesthesia. The expert knowledge of anaesthetists is necessary to estimate the state of the patient, and this makes it difficult to let a system take over the work of anaesthetists. To show the importance of improving the working situation of anaesthetists, the state-of-the-art of patient monitoring systems in the operating theatre (OT) will be described next. 3.3 State-of-the-art in the Operating Theatre Traditionally, approaches to patient monitoring during surgery have been concerned with the acquisition and evaluation of primary physiological data obtained from a variety of sensors. The intended purpose of this type of monitoring systems is to display the relevant information about the patient's state and to alert the anaesthetist about conditions that indicate that either the physiological patient data or the monitoring devices are outside a pre-selected range (Mora et al., 1993). This has led to a large number of poorly integrated measurement modules connected by a chaotic web of tubes and wires in the OT. There are a number of disadvantages associated with this. It is, for example, almost impossible to identify the cause of an alarm, because all alarms have almost indistinguishable beeps without any further information about the cause of the alarm (e.g. caused by a patient problem or device problem). Furthermore, physical and mental overload, boredom (i.e. lack of significant work), or other device independent factors decreasing the capacity of the anaesthetist to perform well were not considered in earlier designs of patient monitoring devices. It is our goal to develop a DSS for anaesthetists that is based on knowledge of expert decision making processes and human performance. The research field of ‘naturalistic decision making’ (Salas & Klein, 2001) makes an effort to understand and improve decision making in field settings. We will describe this shortly in the following paragraph.

4

Naturalistic Decision Making

In Naturalistic Decision Making (NDM), the research focuses on how people handle complex tasks and environments. Gary Klein's model (1993) of ‘recognition-primed


165


decision-making (RPD)’, based on his experiences with decision making processes of fire ground commanders, is situated in the field of NDM. This model deals with heuristic decision making in complex and dynamic situations and can therefore also be applied for anaesthesiology. Theories for decision making in medicine are not easily applicable to decision making in anaesthesiology. Decision making is usually under risk. Each alternative has one of several possible consequences, and the probability of occurrence for each consequence is known. Each alternative is associated with a probability distribution, and decision making is a choice among probability distributions. However, decision making in anaesthesiology is characterized by uncertainty, e.g. that no probability distributions about the occurrence of consequences is known. Therefore, heuristics are applied to reduce uncertainty. In situations with high time pressure, decision making follows e.g. satisficing (Simon, 1957) heuristics. By using satisficing (a combination of the words satisfying and sacrificing) heuristics, the first satisfactory alternative is chosen rather than the best alternative (which is sacrificed). No elaborate analytical processes of concurrent evaluation of options take place. Therefore, the results of traditional decision theory research, like rational choice theory (Janis & Mann, 1977) applied in medicine, cannot be employed here. The RPD model describes how experts can arrive at good decisions without comparing the strength and weaknesses of alternative courses of actions (Klein, 1993). In dynamic situations, the decision maker tries to recognize states for which an appropriate set of responses can be derived. By doing so, the complexity of the situation can be reduced. The decision maker identifies relevant environmental cues, and matches them to plausible goal/tasks combinations, and identifies familiar situations. The initial match is tested by mental simulation of the decision maker, to find out if the assumptions about the situation are in agreement with the expectancies resulting from already familiar situations. S/he looks for other available cues to complete the picture of the situation. If there is a match, usual actions for similar situations are taken to satisfy a chosen goal. In unfamiliar situations, no initial match with a familiar case is possible. In these situations, deliberations are necessary; either to identify a familiar situation in an unfamiliar setting or to create a new solution. These processes are called simulation and story building.

5

Situation Awareness

In decision making based on recognition of familiar situations, an internal representation of the current situation of the decision maker plays a crucial role. Cognitive psychology provides a large body of evidence (Eysenck & Keanne, 1995) that a person's internal representation of a situation is not a direct mapping of the outer world. Selection, short-term memory, inference, and planning (Bainbridge, 1997) influence a person’s internal representation of the world, even if the person has no conscious awareness of these processes (Nisbett & Wilson, 1977). SA is a framework of describing the ‘big picture’ of a situation and will be explained in the following. 5.1 Definition of Situation Awareness The “perception of the elements in the environment within a volume of time and space, the comprehension of their meaning and the projection of their status in the near future” (Endsley, 1988) is called SA. Following the proposition of Endsley

166



(1995), we distinguish between the ‘state’ of SA and the ‘processes’ of situation assessment. Maintaining SA is the precondition for making good decisions. SA consists of three different stages: perception, comprehension, and projection. 5.1.1

Perception of the Elements in the Environment

The perception of the status, attributes, and dynamics of relevant elements in the environment is the first stage in assessing SA. Apart from recognizing relevant elements, irrelevant elements have to be filtered out. The anaesthetist uses real-time patient data to assess the state of the patient. The data can be divided in observed data (e.g. skin colour, sweating) and measured data that is displayed on the display of the monitoring system (e.g. heart rate, blood pressure). Observed data is available only to the anaesthetist and not to the monitoring system. Without transmitting observed data into the monitoring system, it is almost impossible for any monitoring system to estimate the actual state of the patient. Therefore, to assess SA, all observable data and the measured data of the patient should be accessible to the anaesthetist. 5.1.2

Comprehension of the Current Situation

At the second stage, comprehension of the current situation, the data from the first stage is put together to form a holistic picture of the environment, including a comprehension of the significance of this data. The directly available data is often insufficient for a complete understanding of the situation or for choosing effective actions. More information is actively searched to draw conclusions about the situation. This could either be by combining and analysing available data or by actively generating new data, e.g. by using or checking more measurement devices. 5.1.3

Projection of Future States

The highest stage of SA is the projection of future states of the elements, at least in the very near future. These predictions, e.g. about the future state of the patient, enable the complex process of simulation and story building from RPD. 5.2 Determinants of Situation Awareness SA goes beyond simply perceiving information in the environment. It includes comprehension of the meaning of that information in an integrated form taking actual goals into consideration. The constant process of assessing SA enables decisionmakers without consciously thinking about situations, to response rapidly to unexpected events (Wickens, 1999). The determinants of SA during surgery in the OT derive from the working environment of the anaesthetist: patient record and previous actions of the crew; and from the personal characteristics of the anaesthetist: knowledge stored in long-term-memory, personal strategies, and working memory capacities. These factors and their importance for assessing SA will be explained next. 5.2.1

Patient Record

The patient record contains general information about the state of the patient that could be of relevance for anaesthesia. Allergies, other diseases or medical problems are stored there. Furthermore, it contains information such as lab results and premedication, which is important for calculating the amount of medication for the patient. Therefore, all available data should be integrated in the DSS.


167


5.2.2

Previous Actions

Previous actions of the crew influence the state of the patient. Administered medication usually has effects on the patient, a non-response, however, would be noteworthy. Accordingly, the anaesthetist has to consider all actions from the crew and these actions must be traced and displayed by the DSS to be built to support assessing SA. 5.2.3

Knowledge Stored in Long-Term Memory

By knowledge stored in long-term memory we understand all information that the anaesthetist has stored in his or her memory. The more experience anaesthetists have, the more information is stored in their memory. Therefore, a DSS should also include a knowledgebase with which anaesthetist can compare their own knowledge with. 5.2.4

Personal Strategies

Several different strategies can be applied for solving one problem with the same (positive) outcome. Different persons use different strategies, or one person can change the strategy used, e.g. because of an increasing workload. When a DSS only supports ‘one best strategy’, this system might not be accepted by expert users using other strategies. 5.2.5

Working Memory Capacities

Available working memory capacities influence anaesthetists’ SA. Heavy workload e.g. might influence the availability of their working memory capacities. During heavy workload situations, e.g. if the workload is increased by additional tasks or data, the anaesthetists’ capacity to assess SA might be impaired. Furthermore, no working memory capacities might be available if the anaesthetist’s vigilance is very low. Consequently, a DSS should adapt to different working memory capacities of anaesthetists.

6

An Integrative Model of Perioperative Cognitive Tasks

We developed a cognitive process model (see Fig. 1) of decision making in anaesthesiology. This model integrates the main findings of RPD and the concept of SA into one model. The model is written as a flow chart and should be read from top to bottom. It contains processes (squares) and decision points (diamonds) and arrows indicating a causal relationship.

168



Figure 1: A cognitive process model of decision making in per-operative tasks

This model focuses on all tasks between the induction (intubation) and wake-up (extubation) of the patient in the OT. The tasks between induction and wake-up are called perioperative tasks. In comparison with aviation, perioperative task are the flight and neither take-off (compare intubation) nor landing (compare extubation). Cognitive tasks are dominant in perioperative tasks, whereas during induction and wake-up physical tasks of the anaesthetist are central. Situations during induction and wake-up are mostly familiar and the work pace is extremely high, therefore the need for decision support is low. During perioperative tasks, the patient is already without consciousness, ventilated, and without conscious pain. In general, two different states of the patient can be distinguished: stable and unstable. The state of the patient has consequences for the tasks of the anaesthetist. If the state of the patient is stable, i.e., inside a range of normal patient's body functions, the task of the anaesthetist can be described as a maintenance task. 6.1 Maintenance Tasks To maintain the unconscious, painless, and paralyzed state of the patient over time, the level of medication in the patient has to be adequate. As every human body reacts slightly differently to the medication, the amount of drugs that has to be given differs between patients. Therefore, the depth of the anaesthesia and the vital parameters of the patient have to be monitored and medication may need to be adjusted accordingly. During maintenance tasks, most actions of the anaesthetist can be anticipated, e.g. pain medication is metabolized and has to be re-injected. The most prominent problem for the anaesthetist is to stay vigilant in these routine situations. S/he has to ob-


169


serve the patient's observed and measured data carefully in order to detect changes in the state of the patient. Furthermore, stable situations of the patient may change unexpectedly into unstable situations. In unstable situations, observed or measured variables are changing or outside their normal range indicating a disturbed body function that may deteriorate and therefore needs to be observed. Apart from these maintenance tasks in periods characterized by a stable patient, anaesthetists perform planning tasks that are not related to the actual patient or surgery. These planning tasks require communication with other staff members and lower the SA of the anaesthetist concerning his or her patient. 6.2 Repair Tasks Repair tasks are triggered by an unexpected change of the patient's variable values. These changes indicate that the patient might lose his or her homeostatic equilibrium, i.e. the patient's state changes from stable to unstable. This is where the cognitive process model (see Figure 1) starts. 6.2.1

Situation Assessment

The first decision point of the cognitive process model is the detection of the change by the anaesthetist. In periods of decreasing vigilance or distraction, the anaesthetist might miss changes, especially if changes are small. If the change is not noticed, no therapy is given and the patient's variable values may continue to deteriorate. If the change is noticed by the anaesthetist, the next process of ‘situation assessment’ in the model of the variable values takes place. First, the change of variable values has to be validated. Some changes result from measurement faults and are not related to the state of the patient. If the values result from a change in the state of the patient, the anaesthetist compares the variable values with the general state of the patient. If the variable values are acceptable for the individual patient, the task of the anaesthetist returns to maintenance tasks. If values are not acceptable, the anaesthetist starts the process of ‘situation assessment’ by searching for further information to identify the state of patient and by this assesses SA. 6.2.2

Familiarity

Following ‘situation assessment’, the next point of decision of the anaesthetist is whether the state of the patient seems familiar to him or her. By comparing the realtime patient data with his or her own mental database s/he has to decide whether this specific configuration is familiar. Expert knowledge in long-term memory can be represented as a set of production rules which specify what action is to be performed if a specific situation arises (Patel & Groen, 1992). Thus, if a problem is familiar to the anaesthetist, a set of rules can be applied that leads to a solution from the facts observed. Using these methods, the anaesthetist will opt for the typical therapy for this specific diagnosis. After administrating this typical therapy, s/he will observe the changes in the variable values, to decide whether the trend of the values is as expected. If the trend is as expected, the task of the anaesthetist will return to maintenance tasks, possibly with higher alertness. If the trend is not as expected, the assumption of familiarity was probably incorrect, and the anaesthetist will return to ‘situation assessment’. The cognitive workload in familiar situations is quite low, as strategies or at least heuristics are available to solve the patients’ problems. Difficulties arise if familiar situations are not recognized as familiar situations or if unfamiliar

170



situations are by mistake seen as familiar situations. Furthermore, a confirmation bias (Oswald & Grosjean, 2004) may occur in which decision makers are completely convinced of their hypotheses and refuse to evaluate alternatives, even when they are more likely. 6.2.3

Urgency

If the state of the patient is not familiar to the anaesthetist, s/he decides how urgent the problem of the patient is, e.g. how life threatening. In most repair states, multiple problem chains occur simultaneously, either by one initiating single event or by the coexistence of multiple medical problems in the patient (Gaba, 1992). These problem chains make the detection of the underlying problem difficult, because different interacting processes have to be sorted out. Time for finding a proper diagnosing lacks in urgent situations, as the state of the patient is critical. Therefore, in practice, anaesthetists in these situations usually simply treat the symptom, following the heuristic decision rule “treat first what kills first”. After this symptom treatment, as in familiar situations, the trend of the variables is observed and then the anaesthetist returns, following the outcomes of the therapy, either to the maintenance context or to ‘situation assessment’. 6.2.4

Diagnosing

If the situation is unfamiliar but not urgent (i.e. not acutely life-threatening), the anaesthetist is confronted with an unfamiliar state of the patient. At this point, cognitive resources of the anaesthetist are available to diagnose the state of the patient. This may lead to a high cognitive workload of the anaesthetist, as a high amount of information has to be processed simultaneously. An example could be a patient with a previously undiagnosed heart disease and who is actually a patient for a cardiologist. Nevertheless, symptoms such as an increase in heart frequency could also be attributed to a complication in anaesthesia. When a diagnosis has been made, therapy can be given. After this ‘diagnosisbased therapy’, the patient’s variable values are observed. If the value (or trend) is acceptable, the anaesthetist goes back to the maintenance task. Otherwise s/he continues the ‘situation assessment’.

7

The Implications of the Cognitive Process Model for the Design of Decision Support Systems

The aim of DSSs is to support humans in the performance of tasks that involve decision making and choosing appropriate actions (Sage, 1991). Ideally, DSSs should enhance human abilities such as creativity and overcome human limitations such as limited cognitive capacities or low vigilance. The cognitive process model we developed can be applied in developing DSSs in anaesthesiology. It is a very complex task for system developers to design DSSs for complex contexts where highly trained experts are involved in decision making. Furthermore, anaesthetists are legally responsible for the life of their patients, and the decisions they make. This has consequences for the design, so systems can only support decision making processes rather than take them over. Furthermore, since anaesthetists use different strategies for problem solving, the system to be developed should not have a normative approach but should support various strategies.


171


7.1 Decision Support in Familiar Contexts Decision making in familiar contexts in general induces only low cognitive workload of the anaesthetist and anaesthetists as experts might perform well without any decision support. However, also in familiar situations errors in decision making can occur. In low vigilance and/or high workload situations, the anaesthetist might not pay (enough) attention to the state of the patient. If the state of the patient changes from maintenance to repair, the DSS should detect this change and inform the anaesthetist. Additionally, familiar situations might not be identified as familiar, e.g. because of deficient knowledge of the anaesthetist. Also, unfamiliar situations of the patient might be interpreted as being familiar by the anaesthetist resulting in wrong treatment. Furthermore, erroneous beliefs like the "garden path fallacy" (also called cognitive tunnelling) should be avoided, in which decision makers are completely convinced of their hypotheses and refuse to evaluate alternatives (Klein, 1999), even when they are more likely. Using the results of the work of Le Feber and Ballast (2004), we developed a prototype of a DSS that can identify familiar complications in anaesthesiology (Aitkenhead et al., 2001). This prototype of a DSS for familiar situations generates a list of five relevant diagnoses based on the measured patient data and indicates probabilities for or against the displayed diagnoses, so that the anaesthetist can evaluate the suggested diagnoses of the patient without the feeling of being overruled. 7.2 Decision Support in an Urgent Context In urgent situations, the context is not familiar, time for proper diagnosing is not available, but urgent treatment is required. This context requires active attention and more cognitive resources than the familiar context does. Fortunately, urgent situations can be detected easily by a computer system if a database is provided of ranges in which the patient's variable values are unstable. In fact, this is the purpose of most alarm systems. Information from alarm systems could easily be re-used to detect dangerous situations. If multiple problem chains occur simultaneously, priorities have to be set as to which symptom will be treated first. As the situation is not familiar, no single treatment is available to solve all problems at once. Therefore, all symptoms have to be considered and any potential treatment has to be checked for side effects on other symptoms. Unlike humans, computers can easily compute an almost unlimited number of variables simultaneously and can evaluate consequences of treatments on other parts of the patient's systems. The computer system can produce treatment plans for an urgent situation from which the anaesthetist can choose. Future states of the patient can be simulated according to the available patient data and the medication. In urgent situations, which evoke high cognitive workload in the anaesthetist, the benefits of computers can be exploited to support human decision making processes by detecting the condition, prioritizing in multiple conditions, making suggestions for treatment and prediction of effects. 7.3 Decision Making and Diagnosing The process of diagnosing unfamiliar situations can hardly be taken over by a computer system. In this context, the special human abilities of problem solving are required. In diagnosing, the DSS reaches its limits.

172



However, any system that uses our cognitive process model can detect a diagnosing state of the anaesthetist, and its own limits, accordingly. If the patient's variable values change, and the situation is neither familiar (cf. Le Feber's familiar diagnoses) nor urgent (cf. alarm limits), the anaesthetist is probably occupied with diagnosing tasks. Even when these diagnosing tasks cannot be taken over by a DSS, the system still can support the anaesthetist, as the process of diagnosing demands a great amount of information. All necessary information should be presented to the anaesthetist, if possible on a higher level of interpretation. This could e.g. be grouped according to different systems within the patients, for example their respiratory system or their cardiovascular system. Further research is necessary to determine the need for information in the diagnosing context.

8

The Power of Using Cognitive Modelling for Requirements Engineering in Anaesthesiology

8.1 Cognitive workload Using the cognitive model of decision making we can estimate the cognitive workload of the anaesthetist for any given state of the patient. The state of the patient is defined by the measured data from the monitoring devices. If the patient is in a stable state, the workload of the anaesthetist is low. If the patient is in an unstable state, the system built according to the cognitive model can distinguish three different cognitive states of the anaesthetist: if the state of the patient can be determined by the system, the situation is most likely familiar to the anaesthetist and therefore the cognitive workload is moderate. If the state of the patient is urgent, the cognitive workload is higher, especially because the life of the patient is in danger and immediate actions are required. The highest cognitive workload will be experienced in the diagnosing situations that can also be detected by the DSS. One possible application is to prohibit external disturbances in periods of high workload, e.g. a request from another OT for the anaesthetist to reschedule operations. In contrast, in periods of very low cognitive workload, these communication requests could be encouraged. In periods of low workload, vigilance often decreases (Parasuraman & Davies, 1984) and could be enhanced by planning tasks. In the high cognitive workload situation of diagnosing, an option to request help from other experts easily could be offered. 8.2 Presentation of Information Different amounts of information displayed on the monitor are required in different contexts. The amount of information that is processed by the anaesthetist determines his or her workload. As workload increases, the anaesthetist's ability to allocate time to assess patient information on a visual monitor for example, will decrease (Watson et al., 2004) unless the information is highly relevant. The amount of information displayed on the interface should be adjusted according to the capacity of information processing of the user. In maintenance, the focus is on presenting information that supports and enhances the SA of the anaesthetist. Any change of the patient's state, changing the context from maintenance to repair, should be detected automatically; all additional information available should be displayed in order not to restrict the working strategies of the user. Expert knowledge and experience cannot be reduced to the knowledge of the system engineers. However, as the anaesthetist's interpretation


173


of information may add to the workload, information should also be presented at a higher level of interpretation, grouped e.g. according to functional subsystems of the patient like the cardiovascular or the respiratory system. Further research is needed to specify the information that should be displayed by the DSS. 8.3 Novice and Expert Anaesthetists With the model, the differences in cognitive processes between novice and expert anaesthetists' decision making processes can be accommodated. Novice anaesthetists' memory contains not as much information as expert anaesthetists and is organized differently. For this reason, novices’ assessing SA is more difficult. Furthermore, the number of situations that are familiar to them is smaller and they will more frequently end in the ‘diagnosing’ context of the model we introduced. Using our model, the crucial points in decision making could be further analysed and the results could be used to teach novice anaesthetists.

9

Discussion

In this paper, we demonstrated the benefits of applying our cognitive process model in system engineering for a DSS for anaesthesiology. The information presented by our DSS will be tailored according to the need of information of the anaesthetist, based on the state of the patient. No further input of the anaesthetist or of measurement devices will be required. This personalized information will improve the SA of the anaesthetist and, as a consequence, his or her decision making. Furthermore, the system can detect its limits, where decision support cannot be generated automatically. Anaesthesiology is an ideal example of a complex and dynamic environment that can reach an infinite number of states. The results of this paper can be used for other system design, where complex decision making under uncertainty takes place.

References AITKENHEAD A, ROWBOTHAM D and SCHMITH G (2001) Textbook of Anaesthesia. Churchill Livingstone, Edinburgh, London. BAINBRIDGE L (1997) The change in concepts needed to account for human behavior in complex dynamic tasks. IEEE Transactions on systems, man, and cybernetics- Part A: Systems and Humans 27(3), 351–359. ENDSLEY MR (1988) Design and evaluation for situation awareness enhancement. In Proceedings of the Human Factors Society 32nd Annual Meeting, pp. 97–101, Human Factors Society. ENDSLEY MR (1995) Towards a Theory of Situation Awareness in Dynamic Systems. Human Factors 37(1), 32-64. EYSENCK M and KEANNE M (1995) Cognitive psychology: A student’s handbook. Lawrence Erlbaum, Hillsdale, NJ, 3rd edition. GABA D (1992) Dynamic decision-making in anesthesiology: Cognitive models and training approaches. In Advanced Models of Cognition for Medical Training and Practice (EVANS D and PATEL V, Eds), p 123–147, Springer-Verlag, Berlin, Heidelberg, New York. JANIS I and MANN L (1977) Decision Making: A psychological analysis of conflict, choice, and commitment. Free Press, New York, NY.

174



KLEIN G (1993) A recognition-primed decision (RDP) model of rapid decision making. In Decision making in action: Models and methods (KLEIN G, ORASANU J, CALDERWOOD R and ZSAMBOK C, Eds), p 138–147, Ablex, Norwood, NJ. KLEIN G (1999) Sources of Power. MIT Press, Cambridge, MA, 2nd edition. LE FEBER J and BALLAST A (2004) Development of a decision support system for anaesthesiologists. In Proceedings of Artificial Intelligence and its Applications (ICAAI’2003), pp. 332–335, Kolhapur, India. MORA F, PASSARIELLO G, CARRAULT G and PICHON J-P (1993) Intelligent patient monitoring and management systems: A review. IEEE Engineering Medicine and Biology Magazine, December 1993, 23–33. NISBETT R and WILSON D (1977) Telling more than we can know. Verbal reports on mental processes. Psychological Review 84, 117–134. OSWALD M and GROSJEAN S (2004) Confirmation bias. In Cognitive illusions: a handbook on fallacies and biases in thinking, judgement and memory (POHL R, Ed), p 79–97, Psychology Press, Hove, GB. PARASURAMAN R and DAVIES DE (1984) Varieties of attention. Academic Press, New York, NY, 2nd edition. PATEL V and GROEN G (1992) Cognitive frameworks for clinical reasoning: applications for training and practice. In Advanced models of cognition for medical training and practice (EVANS D and PATEL V, Eds), p 193–211, Springer-Verlag, Berlin, Germany. PERROW C (1984) Normal accidents: Living with high-risk technologies. Basic Books, New York, NY. ROBERTSON S and ROBERTSON J (1999) Mastering the requirements process. AddisonWesley, Amsterdam. SAGE A (1991) Decision support systems engineering. Wiley, New York, NY. SALAS E and KLEIN G (2001) Expertise and naturalistic decision making: An overview. In Linking Expertise and Naturalistic Decision Making (SALAS E and KLEIN G, Eds), p 3–8, Lawrence Erlbaum, Mahwah, NJ. SIMON H (1957) Models of Man. Wiley, New York, NY. WATSON M, SANDERSON P and RUSSELL W (2004) Tailoring reveals information requirements: the case of anaesthesia alarms. Interacting with Computers 16, 271–293. WICKENS C (1999) Cognitive factors in aviation. In Handbook of applied cognition (DURSO F, Ed), p 247–282, Wiley, New York, NY. WOODS D (1988) Coping with complexity: The psychology of human behaviour in complex systems. In Tasks, errors, and mental models (GOODSTEIN L, ANDERSEN H and OLSEN S, Eds), p 169–188. Taylor and Francis, New York, NY.


175

Agile Requirements Definition for Software Improvement and Maintenance in Open Source Software Development Stefan Dietze Fraunhofer Institute for Software and Systems Engineering (ISST), Mollstr. 1, 10178 Berlin, Germany Abstract This paper describes the agile requirements definition processes performed in open source software development (OSSD) projects. These should be considered as a reliable and viable approach to requirements definition in the area of software engineering (SE) and co-operative work in general. 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 feedbackbased requirements definition processes. Therefore, important characteristics of OSS and OSSD are explained and typical roles, processes and an overall lifecycle model of typical OSSD projects is introduced. This leads to the description of the agile requirements definition processes as they are part of the software improvement process in OSSD projects. Thus, the typical requirements contribution and review processes are introduced and a typical lifecycle of the produced requirements artifact is explained. Keywords: Agile RE processes, Open Source, Software Engineering, Software Requirements, Requirements Engineering, Software Development, Process Model, Virtual Organization, Virtual Community

1

Introduction

Open Source Software (OSS) has reached a remarkably high popularity in many different application domains throughout the last years. The success of famous OSS products, like the Linux Kernel or the Apache HTTPD Web Server, leads to the suggestion, that the development processes in general and especially the re-quirements definition processes are well suited to the demands of the users and the developers of OSS. Since the heterogeneous communities of established OSS projects typically consist of a large number of globally distributed actors who collaborate almost exclusively through the internet, OSS projects should be perceived as com-plex sociotechnical systems. Whereas typical RE processes often are not designed to deal with an increasing level of complexity, heterogeneity and distribution of their organizational structures (Herlea, 1998), the collaborative OSS development methodologies seem to have overcome these issues. This suggests the hypothesis that the underlying OSS development model which obviously has the ability to produce successful software products should be considered as a reliable and viable approach in the areas of software engineering (SE) and of cooperative work in general. This paper outlines and interprets some results of a comparative case study of OSS development processes within the Apache HTTPD, the Linux Kernel and the Mozilla project. These research activities were aimed at the identification and formalized specification of a descriptive process model for OSS development based on case studies which were performed by participating in the projects, analyzing the projects’ information sources, doing interviews and literature review. The research was focused on the processes, roles, artifacts, and the deployed software infrastructure, which is used to support the whole development approach. The identification and formal pres176


Stefan Dietze

entation of a descriptive process model enable the further improvement of the identified processes and its software infrastructure and furthermore open the opportunity to consider the integration of these practices into traditional software development approaches. The following describes the results of this approach and focuses on the requirements definition processes in typical OSS environments. Section two provides background information about typical characteristics of OSS and OSS development (OSSD) processes, whereas the third section introduces some important aspects of the identified OSSD process model. This leads to the explanation of the agile requirements definition approach in OSS projects in section four. Finally, the core results of the chapter are summarized in section five.

2

Background

2.1 Open Source Software An appropriate explanation of the open source term is provided by the Open Source Initiative (OSI), which has developed the Open Source Definition (OSD). This definition contains a set of criteria that have to be considered in the software license models used for OSS in accordance with the OSD (Open Source Initiative, 2002): •

Free distribution and redistribution

•

Publicly available source code

•

Possibility of source code modification and redistribution

•

No discrimination of certain users/groups or employment domains

All license models that follow the criteria defined in the OSD can be considered to be compatible to the understanding of OSS as defined by the OSI. In addition, the OSI provides a list of all certified software licenses (Open Source Initiative, 2003). These characteristics have significantly determined the evolution of the entire OSS development model and especially the requirements definition processes. 2.2 Open Source Software Development Although many existing OSS projects have successfully developed individual practices and specific processes, it is possible to define some common characteristics that can be identified in most of the OSS Development projects (Cubranic, 2002; Fogel & Bar, 2002; Gacek, Lawrie & Arief, 2002; Scacchi, 2001; Vixie, 1999). •

Collaborative development

•

Globally distributed actors

•

Voluntariness of participation

•

High diversity of capabilities and qualifications of all actors

•

Interaction exclusively through web-based technologies

•

Individual development activities executed in parallel


177

Agile Requirements Definition in Open Source Software Development

•

Dynamic publication of new software releases

•

No central management authority

•

Truly independent, community-based peer review

•

‘Bug driven’ development

According to Raymond (2001), these characteristics lead to the metaphor of a ‘bazaar’ that represents the characteristics of the OSS development practices in contrast to a ‘cathedral’ representing the centralized and strictly controlled traditional software development. The OSS development processes are often characterized as ‘Bug-driven’. This results from the typical practice that every software modification is based on a specific bug report or more generally on a change request which represents the central requirements artifact within the OSSD approach. This characteristic also clarifies the importance of the requirements definition processes within OSSD projects.

3

Identified OSSD process model

This section summarizes some of the key aspects of the process model which was identified during the preliminary research activities. 3.1 Key processes and roles The initial release of the OSS prototype can be perceived as the starting point of the OSSD process as a gradual process of software improvement. The OSS approach can be divided in the following key processes: •

Management Processes

•

Environment Processes

•

Development Processes

Whereas the development processes describe the collaborative and highly distributed activities to improve the source code and to develop all projects artifacts, particularly the RE artifacts, the management and environment processes support the development activities from a central position. These main development processes are executed in parallel and mainly independent from each other. The following figure (Fig.1) represents these core process categories and the roles involved in this model in an UML-based use case view:

178


Stefan Dietze

Fig. 1. Identified key processes and roles

All collaborative development activities are performed by distributed actors who can be aggregated to the following roles: •

User

•

Contributor

•

Developer

•

Reviewer

•

Committer

These roles are not usually defined explicitly but describe a certain set of actors who fulfill a defined set of functions and tasks. A common set of characteristics can also be defined, e.g. user privileges which all actors fulfilling a certain role are associated with. Usually an actor is associated with more than one role. For example, the development of a source code as a developer implies the use of the OSS as a passive user and the submission of patches makes a developer also become a contributor. 3.2 Maintainers and Core Developers The maintenance processes for maintaining the infrastructure and to support and coordinate all development activities are typically performed by a central maintainer or a maintenance committee. In fact, the initiator of the project is in most cases the same person as the primary maintainer. The maintenance actors provide central ser-vices which cannot be provided by distributed and global actors, e.g. a common software infrastructure which provides central access to all shared resources. In many OSS projects a group of core developers could be identified (Dietze, 2003). These actors are typically responsible for the majority of source code modifications and interact very closely with the maintainer(s) of a project. Furthermore, the core developers are often responsible for activities which require enhanced quali-


179


fications, skills, privileges or knowledge of the source code, e.g. the commit of source code (Mockus, Fielding & Herbsleb, 2000; Reis & Pontin de Mattos Fortes, 2002). 3.3 Overall Process Model The overall process model at its highest level of abstraction is represented in the following figure (Fig.2).

Fig. 2. Overall process model of the OSSD approach

The above figure contains the key processes of the OSSD process model and is presented for informal purposes in order to provide a brief overview on the central processes and their relations. After the initial development and release of the prototype, firstly, environmental and management activities have to be accomplished in order to establish a project community and to setup an initial rudimentary software infrastructure, e.g. a website, a central source code repository (CVS) and a bug tracking system. These environmental and management processes are primarily executed by the maintainers of an OSS project and are necessary to enable the collaborative RE processes and all further development processes by a distributed project community. For means of simplification, only the requirements definition and the patch development processes are visualized as explicit development processes since both represent the primary activities of OSS development. A very important aspect of the distributed activities within the development processes is the fact that most processes are performed continuously, in parallel, and mainly independent from each other by autonomous and distributed actors. This separates the OSSD approach from any traditional SE approach and typical development practices within commercial environments.

180


Stefan Dietze

For example, a developer who is going to develop and submit a patch acts absolutely independently from other developers and also from contributors who are contributing code change requests. The only relation between these two processes is the fact that the database of change requests is the starting point for every patch development cycle.

4

Agile Requirements Definition in OSSD

The typical process of requirements engineering in OSSD projects is based on the collaborative and iterative development of requirements artifacts within the process of gradual software improvement. These requirements artifacts (‘Change Requests’) are used to capture the requirements for all further development activities. 4.1 Scope of the OSSD requirements definition processes As is shown in Fig. 2, the requirements definition processes are part of the process of gradual software improvement and always refer to an existing software version. The typical OSSD processes start after the release of a software prototype as OSS and are just aimed to improve and maintain this prototype. Thus, an already existing software prototype seems to be a prerequisite for the requirements definition processes which typically occur in OSSD projects. This indicates that these requirements artifacts are, in general, not appropriate to describe the requirements of entire new software products exhaustively. The requests which are developed in the RE processes by contributors of the distributed community are aimed to describe requirements for improvement of the OSS, i.e. to remove bugs (‘Corrective Maintenance’) or to add new features to the software (‘Perfective Maintenance’). Therefore, the requirements artifacts can be divided into two categories: •

Bug Reports

•

Enhancement Requests

Whereas a bug report describes an observed software bug, an enhancement request defines the extension of the OSS in terms of functionality or system compatibility. 4.2 Process of contributing requirements The process of contributing requirements is performed by all actors of the community of an OSS-Project which then turn into the role of an active ‘Contributor’. Change requests are typically managed by a central bug tracking system which represents a central repository for all change requests and enables their structured description based on metadata. A popular bug tracking system is Bugzilla which was developed by the Mozilla community and is now used, e.g., for the management of change requests in the Linux Kernel1 as well as in the Mozilla2 and the Apache3 project.

1

http://bugzilla.kernel.org/ http://bugzilla.mozilla.org/ 3 http://nagoya.apache.org/bugzilla/ 2


181


RE processes in OSSD projects are performed autonomously and independently from other processes. This is another big difference to traditional RE processes as they can be identified in proprietary (software) industries, besides the aspect that the RE process in OSSD is aimed at the gradual improvement of an already released software product. The following figure presents the activities of the requirements definition process in an UML-based activity view:

Fig. 3. Activity view of requirements definition process

After the identification of a certain software modification need, this software misbehavior has to be verified by the user. This is generally done by ensuring that the latest release of the OSS was installed and by subsequently trying to reproduce the modification requirement in this software version. If the bug can be reproduced or if a need for a general software enhancement can be identified, the actor reviews the existing change request repository in order to verify that the request has not already been submitted. After ensuring the novelty of the requirement, the contributor can optional-

182


Stefan Dietze

ly communicate the request via a dedicated mailing list to the community of the project. This enables the whole community to review and discuss the request and is aimed at ensuring that the misbehavior is not specific to the system or software installation of one single actor and that no developer is already working on the implementation of this requirement. After completing this process, the contributor creates an entry in the bug tracking system and describes the change request based on structured metadata. In most projects this process is described in a guideline document, which is typically called ‘Bug Reporting Guideline’ and defines the process of developing and submitting a change request. This document ensures a common understanding of this process and is used by the community as a prescriptive guide to the process, thus supporting a higher level of quality assurance by creating a consensus about how the whole requirements definition process has to be performed and which information should be provided. 4.3 Metadata of a change request As mentioned above, the change requests are captured in a bug tracking system and described using certain attributes - the metadata of a requirements artifact. This metadata information may be specific for each OSS project, but contains some generalizable attributes which exemplarily are listed below: •

Summary

•

Description

•

Keywords

•

Status

•

Affected Software Version

•

Attachments

•

Comments

•

Owner

•

Severity

•

Priority

The Status attribute is of special importance because it is used to document the current state of the change request thus controlling the progress of the patch development activities. The severity attribute is typically used to separate enhancement requests from bug reports by assigning the value ‘Enhancement’. 4.4 Collaborative requirements review Processes for reviewing existing change requests supplement the requirements definition processes and are mostly executed independently from the process of requirements definition. In some OSS projects these processes are also known as ‘Bug Triage’ (Mockus et al., 2000; Reis & Pontin de Mattos Fortes, 2002). They are aimed to ensure a consis-


183


tent, redundancy-free and always up-to-date repository of change requests. During these review activities new and unconfirmed change requests are validated, and validated change requests which are currently not in development by a specific developer are assigned. If a change request is assigned to a developer or selected for implementation by a developer himself, an individual patch development cycle, aimed at implementing the described requirement, is started. The following figure represents the requirements review process and its activities:

Fig. 4. Activity view of requirements review

184


Stefan Dietze

It is important to emphasize that these review processes are implicit processes performed voluntarily by the distributed actors, as most typical OSSD processes are. Thus, the intensity these processes are performed with is not centrally planned and a defined level of quality assurance regarding the repository of requirements cannot be guaranteed for each point of time. 4.5 Lifecycle of a change request The attribute Status is used to document the current state of an individual request. Every actor performing an activity that is related to a particular change request can make this information available to the whole community by setting the Status attribute of the change request to a certain value which describes what he is going to do. Thus, this attribute provides a very important functionality for the documentation and coordination of the patch development cycle. The following figure describes the typical states of a change request and therefore illustrates the lifecycle of this artifact which is directly related to the lifecycle of the patch that implements this request.

Fig. 5. Typical lifecycle of a change request


185


This information can be supplemented by setting additional attributes (Attachments, Comments) which can contain supplementary information about ongoing development activities. 4.6 Conclusion This paper has presented certain aspects of the OSSD model and explained an alternative approach of requirements definition than can be observed in typical OSSD projects. The OSSD based approach for gradual software improvement based on collaborative requirements engineering can be perceived as a promising and valuable process for software development that has been developed by users and developers of OSS in an evolutionary process throughout the previous evolution of OSSD practices. It seems to be well suited to detect the requirements of globally distributed users of a software, once a software prototype has been released. Thus, the described requirements definition process, which has already proven its ability to produce successful products, possibly has the potential to be adopted to traditional software development projects aimed at producing proprietary, closed source software and maybe also to other industries. Besides the advantages of the OSSD approach for defining requirements, this methodology still exhibits several weak points and issues. Before implementing OSSD RE practices in conventional SW development projects, these weaknesses should be considered and minimated. Therefore, a higher level of quality regarding the entire OSSD process model should be approached, which could open the opportunity to utilize general OSSD methodologies and especially the described requirements definition practices in commercial software development domains as well as in other industries. This could be achieved by the assignment of supplementary roles and tasks to core developers of an OSSD project aimed at the introduction of formal quality assurance processes into the described requirements definition approach and to make it a reliable starting point for further implementation activities. The implementation of an appropriate software infrastructure that supports these distributed processes in all of their facets could enable process automation and a high level of process autonomy and parallelism. Thus, this could provide a big benefit to further OSSD projects and could support or supplement distributed organizational structures in general.

References BOEHM B, GRÜNBACHER P & BRIGGS R O (2001) Developing Groupware for Requirements Negotiation: Lessons Learned. In IEEE Software (Vol. 18). No. 3, May/June 2001. IEEE Computer Society. CUBRANIC D (2002) Open Source Software Development. Retrieved March 26, 2002 from the Wold Wide Web: http://sern.ucalgary.ca/~maurer/ICSE99WS/Submissions/Cubranic/Cubranic.html. DIETZE S (2003) Improvement Opportunities for the Open Source Software Development Approach and how to utilize them. In Proceedings of the NetObjectDays 2003. NODe Transit GmbH. FOGEL K & BAR M (2002) Open Source-Projekte mit CVS. MITP. GACEK C, LAWRIE T & ARIEF B (2002) The many meanings of Open Source. Retrieved May 28, 2002 from the World Wide Web: http://citeseer.nj.nec.com/485228.html.

186


Stefan Dietze

HERLEA D (1998) Computer supported collaborative Requirements negotiation. Retrieved October 10, 2003 from http://ksi.cpsc.ucalgary.ca/KAW/KAW98/herlea/. MOCKUS A FIELDING R & HERBSLEB J (2000) A Case Study of Open Source Software Development: The Apache Server. In Proceedings of the 22nd International Conference on Software Engineering. IEEE Computer Society. OPEN SOURCE INITIATIVE (2002) Open Source Definition. Open Source Initiative. Retrieved December 12, 2003 from the World Wide Web: http://opensource.org/docs/definition.php. OPEN SOURCE INITIATIVE (2003) OSI certified software licenses. Retrieved January 15, 2003 from the World Wide Web: http://opensource.org/licenses/index.php. RAYMOND E S (2001) The Cathedral and the Bazaar. O’Reilly UK.


187

The Challenges of Tool Integration for Requirements Engineering Lisa K. Meisenbacher Siemens Corporate Research, Inc. [email protected]

Abstract Requirements elicitation and management have been well documented using the Unified Modeling Language (UML) Business Object Models approach (Berenbach, May 2004, October 2004, 2003). There are many software tools that either fully or partially support UML standards. Some tools are more popular than others, and all have their own advantages and disadvantages. Integration of commercially available software products is something of a misnomer. This paper describes techniques that facilitate tool integration for requirements management and maintenance. Specific examples detail the capabilities (and/or limitations) of existing commercial products that a requirements engineer may use to model a business process and elicit detailed requirements. In addition, the case study will describe three challenges encountered with tool integration: traceability, hierarchical organization, and tool maintenance. Keywords: requirements engineering tools, CMMI, tool integration, COTS, traceability, tool maintenance

1

Introduction

Requirements elicitation and management involves using software tools. Many of these tools are commercially available, some are not. The requirements engineer must have fully integrated tools available to provide consistent and uniform solutions for requirements engineering problems. The challenge of tool integration becomes difficult in many instances since many use proprietary API’s and do not easily work together with each other. Requirements engineering tools are becoming increasingly applied in globally distributed environments. Companies can be segmented across different subsidiaries, divisions and geographies. Cross-functional teams are being formed in order to facilitate collaboration in requirements elicitation and management. This trend highlights the need for disparate tools to be fully integrated. Moreover, there is no single or uniform approach to requirements engineering tool use. In addition, as organizations become CMM and CMMI compliant with their requirements engineering processes, seamless tool integration becomes critical for establishing and maintaining traceability of requirements. This paper will illustrate an approach that uses COTS products to provide a CMMI compliant and integrated process to facilitate requirements elicitation and management. The case study described below focuses on describing solutions for three challenging areas: bidirectional traceability, hierarchical organization of requirements, and long-term tool maintenance.

188


Meisenbacher

2

COTS Vendor Landscape

There are many commercial off-the-shelf tools available for different stages of the requirements engineering process. Some of the more well-known ones include Caliber (Borland Software Corporation, 2005), DOORS (Telelogic AB, 2005), Rhapsody (I-Logix Inc., 2005) and Requisite Pro (Rational Corporation, 2005). The results of a Google search on requirements engineering tools show there are more than fifty COTS products currently available. For better or for worse, there are many tools to choose from. Although websites such as Volere and Easyweb detail the capabilities of each of the COTS tools, neither describe how or if any of these tools work together or have synergies available that facilitate development, traceability or requirements maintenance across different product suites (Requirements Engineering Tool Vendors and Freeware Suppliers, 2005; Volere, 2005). Some vendor websites highlight specific areas of tool integration with little or no detail regarding the “degree” of integration or just the overall capabilities and limitations. My experience with one particular Siemens operating company indicates that requirements tool integration “gotchas” are not uncovered until the analyst or team of analysts is “knee-deep” into the product functionality and the project is already committed to a particular tool or suite of tools. With that in mind, this paper will detail the findings of one particular on-going project that uncovers both the benefits and limitations of the following commercially available tools: Rational Rose, Doors, Rose Integration and Doors DXL. Additionally, the details of the case study will also provide the reader(s) with valuable insight into how much of the product integration is “out-of-the-box” and how much you must build on your own or buy from a third party vendor.

3

Challenges

3.1 Traceability Bidirectional traceability is critical for CMMI compliance. Tool integration must provide the ability to trace Rose artifacts to and from their respective requirement(s). In this case study, the business object model was created in Rational Rose. The text requirements reside in an enterprise Doors database. Rose Integration provided the mechanism for bidirectional traceability. Rose Integration provides the ability to link each Rose artifact to the respective Doors requirement(s) as part of the core product functionality. Programming with Doors DXL was necessary in order to automate the creation of these links. Programming proficiency with Doors DXL typically requires additional training in order to acquire the in-house expertise necessary for customization. DXL scripting requires minimal training for an experienced C++ developer but more extensive training for novice programmers or those new to C++. 3.2 Organization The Rose Integration software is used to create a surrogate Doors module that contains the bidirectional links. The Rose business object model contains a hierarchical representation of the requirements. Parent-child relationships are used to accurately represent the relationships between the artifacts. The Doors surrogate module does not have any knowledge of the relationships between the Rose artifacts.


189

Tool Integration for Requirements Engineering

The Rose model is imported into the Doors “surrogate” module with a flat hierarchy. Specifically, all hierarchical information from the Rose model is lost when the model is imported into Doors using the “out-of-the-box” functionality of Rose Integration. All UML diagrams that detail the artifact relationships are also lost. Significant effort and programming are needed to rebuild the original hierarchy in order to represent the original Rose model in a meaningful and useful fashion. Section four will describe the solution used to create a hierarchical module. 3.3 Maintenance Maintaining the imposed hierarchy of the Doors surrogate module poses some longterm tool support issues. Although Telelogic recommends customizing solutions with DXL programming, they have confirmed that the proposed solution outlined in this paper voids the product warranty and will not be supported. In essence, the product vendor will only support a solution that is unusable for the purpose of this case study. Long-term requirements maintenance considered over the full lifecycle of a software product(s) requires tool flexibility as well as short-term and long-term support from the product vendor regardless of whether it is an off-the-shelf or a customized solution.

4

Challenges

The Rose model was imported into Doors using the Rose Integration software (v2.8). DXL scripts were written to recreate the original Rose model hierarchy in the surrogate module. The Rose documentation fields were also migrated into the surrogate module during the import step. Additional DXL scripts were written to parse the description fields of the Rose model and create bidirectional links from Rose to the surrogate module and then to the stakeholder requests located in a separate Doors module. A convention was adopted for the direction of the links (outgoing versus incoming) since the Telelogic definition of link direction was ambiguous. Furthermore, the hierarchical surrogate serves as the focal point for navigating between the text requirements in Doors and the Rose business object model. A working prototype is in place that provides a meaningful framework for automatically generating a detailed systems requirement specification (SRS) from the requirements. The business object modeling of the requirements is on-going. As new objects are created, modified and/or deleted in Rose, the surrogate module is regularly updated using the Rose Integration tool. The DXL script that creates the hierarchy needs to be invoked each time the Rose model is updated and these updates are sent to the surrogate module. This extra step is necessary because the Rose Integration tool is agnostic of the imposed hierarchy on the surrogate without the DXL script. Furthermore, the Rose Integration update process has only been used to send updates from Rose to Doors for this case study. Although Rose Integration has the ability to create new model elements in Doors and export them to back to Rose, this feature has not been used as part of the case study solution (Telelogic AB, 2005). The reader should be aware of an alternate third party solution. Galactic Solutions Group has also developed a proprietary solution for imposing a hierarchical structure on a Doors module. The RM-Int product exports the entire Rose model hierarchy (including UML diagrams) into a Doors module. Although this product is fully

190


Meisenbacher

supported by the vendor, it is not yet commercially available (Galactic Solutions Group, 2005). This was also a contributing factor for developing a customized solution specific to the Siemens operating company.

5

Summary

A case study solution was presented that outlines the methodology used to create a customized solution for COTS integration specifically for requirements management. The prototype developed will be used to automatically generate systems requirements specification for a future Siemens software product. There are currently many COTS products that provide a rudimentary foundation for integrating requirements engineering tools. However, many tools require special customization to meet the particular requirements and business needs of a project. Product vendors should carefully consider the importance of tool integration as they continue to implement new releases and next generation products for requirements engineering. From a technical perspective, XML-based solutions will provide new opportunities to integrate disparate tools in a more systematic and scalable approach with long-term practical benefits for requirements engineering. I hope the reader has gained valuable insight into the benefits, the limitations and the challenges of integrating COTS tools for requirements management.

Acknowledgements I would like to thank Bob Schwanke for his detailed review of this paper and his feedback on the content.

References BERENBACH B (May 2004) The Evaluation of Large, Complex, UML Analysis and Design Models, Twenty Sixth International Conference on Software Engineering (ICSE 2004), Edinburgh, Scotland. BERENBACH B (October 2004) Comparison of UML and Text Based Requirements Engineering, Nineteenth Annual ACM Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA), Van Couver, British Columbia. BERENBACH B (2003) Evaluating the Quality of a UML Business Model, Eleventh IEEE International Symposium on Requirements Engineering (RE’03), Monterey Bay, Ca. BORLAND SOFTWARE CORPORATION (2005) Caliber . GALACTIC SOLUTIONS GROUP (2005) . I-LOGIX INC (2005) Rhapsody . RATIONAL CORPORATION (2005) Requisite Pro . REQUIREMENTS ENGINEERING TOOL VENDORS AND FREEWARE SUPPLIERS (2005) . TELELOGIC AB (2005) Doors . VOLERE (2005) Requirements Tools .


191

Eliciting Requirements Variability for Embedded Real-Time System Family Olfa Djebbi Université Paris1-Panthéon-Sorbonne CRI, 90 rue de Tolbiac, 75013 Paris, France [email protected]

Abstract In this paper, we consider the typical project situation of the enterprise STAGO INSTRUMENTS, an international leader developing a product line of blood analysers. In a highly competitive environment, managing the variability in their product lines would be worthwhile. While the variability concerns are mainly addressed in design and implementation phases, our contribution in this paper is to emphasize the expression of variability for embedded real-time system family during the requirements phase. We define a process to elicit requirements by reengineering. We choose the formalism MAP to model their variability and, finally, we propose to derive the new product models into a service-oriented architecture (SOA). Keywords: Requirements, Variability, Product line, System family, Embedded real-time systems, MAP.

1

Typical Project Situation: The STAGO Case

STAGO INSTRUMENTS (stago) is an enterprise that develops and provides a product line of blood analysis automatons and a set of reagent kits for research as well as for routine analysis. These machines are particularly complex systems : Differently of software systems, automatons are composed of mechanics, electronics, software and firmware components. They implement at least two networks. The first network is internal (CAN1 Bus) and it allows communication amongst several components, such as electronic cards, mechanic arms, measure equipment, … on one hand ; and between hardware and firmware on the other hand. The second network is external and it handles machine’s interactions with external users, particularly the management of patient’s files in other hospital or laboratory systems and the remote support of the machines (after-sales service host, PDA, desktop, …). In addition, this kind of a system requires collaboration from many different stakeholders that use many specification languages. For instance, to develop automatons, some co-workers must interact. These are biological technicians, biological researchers, mechanical engineers, electronic engineers, software engineers, norm experts and industrialization specialists. Each one of them makes use of his own lexicon and notations : state charts, SADT diagrams, CAD2 graphics, electronic card maps, UML, APTE graphs, tables, etc. Moreover, due to their censorious nature, such embedded real-time systems, require a rigorous verification of system integration and integrity. This is a prescribed 1 2

CAN : Controller Area Network CAD : Computer Assisted Design

192


Olfa Djebbi

task to be carried out at different stages of the development in order to ensure the accuracy, reliability and operational safety of the system. STAGO started as a small laboratory, and the STA® - the first developed automaton - was constructed by a group of friends. They did not follow any development process, and did not elaborate any specifications document. It was rather a pragmatic development following the ‘codex fix’ kind of paradigm. After the worldwide launch of the STA®, the first fully automated coagulation analyser, the group of developers was enlarged. Communication and collaboration among the different stakeholders became more and more difficult. Due to the lack of a formal process, STAGO continues to produce automatons in an ‘ad-hoc’ manner. Faced to a diverse and ever-increasing demand, STAGO is held nowadays to find ways of closely monitoring the development of its automatons in order to control their evolution and keep its competitiveness in the market. In order to guarantee a better productivity, STAGO needs a method to evolve a more coordinated specification management, providing tools which enable development of automatons by extension/adaptation of former ones.

2

Position

The instruments produced by Stago fit into a product line : All instruments share the same core part which comprises the main functionalities of blood analysis. However, each automaton has its own characteristics and differs from the others. These variable parts can be as simple as colour, weight or user interface of the machine ; or more complex such as programming language, capacity in term of number of plasma tubes handling, analysis time, mechanical and electronic technologies used in the machine and security level. The position of the author is that STAGO should manage its business knowledge from the point of view of a product line. It should elaborate an automatons specification which includes the variations known today. These variations will allow thereafter extensions and adaptations in order to produce other automatons. In the software community, this leads to the notion of software variability which is defined as the ability of a software system to be changed, customised or configured to a specific context (Van Gurp, 2000). The variability is even more obvious in system family engineering where a product must be conceived to meet the purpose of different customer sets and to be adaptable to different usage situations (Bosch et al., 2001). A product of system family engineering is an application family model, comprising a set of reusable assets for a family of applications. It identifies commonality and points of variability of existing and future systems of that family (Lee, 2003). The concept of variability in systems families seems relevant for STAGO because it allows to develop systems and satisfy customers’ needs as fast as possible while using a minimal set of resources. The idea is based on the reuse of a family core and the customization of variable parts (Lewis, 2000). It avoids to develop customer-build and expensive systems, and it rather benefits from the capitalization of the organisational knowledge. There are examples where system family engineering was used in the production of embedded systems (Tracz, 1995 ; Jacobson, 1997). There are also many exiting


193

Requirements Variability in System Family

approaches such as (Bachmann, 2001 ; Bosch et al., 2001 ; Anastapoulos, 2000 ; Svahnberg et al., 2000) which study the variability for software systems. Unfortunately, as mentioned in (Halmans, 2003), researches most often study the variability as a design problem and concentrate on implementation aspects but very little amount of work has been published about the representation of the variability at the requirements level. The most relevant researches done in variability until now list many technical approaches to implement it, such as : •

compilation techniques (conditional compilation, loading of libraries)

•

techniques related to the object-oriented programming languages (polymorphism, function overloading, dynamic lookup, template classes, ...)

•

design patterns (Gamma et al., 1995) that provide reusable solutions for some kind of problems. (Jézéquel, 1998) and (Keepence, 1999) propose a set of patterns for modelling variability in product lines. They are based on the reification of variants and on a certain types of dependences between a set of properties

•

programming approaches, like aspect-oriented programming (AOP) (Kiczales et al., 1997) whose principle is to break up the problem into a set of functional components and transverse aspects. Some studies (Bayer, 2000 ; Griss, 2000] propose to use this approach for the management of variability in product lines. More recently, a new approach - the generative programming (Czarnecki, 2000) is introduced especially for the development of the families of systems. It is based on the concept of “generator” : variability in product lines can be implemented by developing generators as generic artefacts, their instantiation makes it possible to generate the implementation of a product

Other researches specify variability at a more abstract level (on the level of the models) namely by using and extending UML (Clauß, 2001). Kobra is an example of approach (Atkinson, 2000), which proposes the creation of product lines based on the definition of components by UML views comprising points of variation. Only few studies done in variability for system family are likely to converge towards requirements engineering. We comment on mainly the methodologies FAST (Weiss et al., 1999) and FeatuRSEB (Griss, 1998). FAST (Family oriented Abstraction Specification and Translation) describes a process for the development of systems families. As a key point, FAST proposes the development of a DSL (Domain Specific Language) which can be used to describe an application of the family. As for FeatuRSEB (Feature Oriented Reuse Driven Software Engineering Business), it is a use-case centred development method for system families. RSEB (Reuse Driven Software Engineering Business) extends the UML by constructs for modelling variability. With these constructs it is possible to develop a model out of which many applications can be derived. FODA (Feature Oriented Domain Analysis) describes a family of applications by using their features. Arranged in a tree and marked optional or mandatory, the choice of some features allow the selection of a specific application.

194


Olfa Djebbi

In an enhanced version, FeatuRSEB uses the ideas of FODA added to RSEB to supply a family specific view. In this paper, we suggest that our future research emphasize the expression of variability for embedded real-time system family at the requirements level. Many specification languages are used in STAGO INSTRUMENTS, including SADT diagrams, CAD graphics, electronic card maps, UML, APTE graphs, etc. As these specifications are very detailed and therefore difficult to be understood by the different stakeholders, we propose to position on an intentional level. We take blood analysis automatons’ development as a case study for evaluating and approving our results. Additionally, our position is to model variability perspective on products, therefore, there is a need of a modelling process that organises this activity. Thus, we propose to elaborate a process for the expression of the variability for product lines. It would start by a reengineering process to elicit requirements that might be structured into a common sets and variable ones. This step would be followed by a modelling process that uses an adequate formalism and that should enable thereafter eventual reuse by extensions / adaptations to produce models of a future product within the product line. Moreover, we look ahead to bind variants’ business models with implementation. The opportunity to elaborate a comprehensive alignment among them is a really compelling aspect. The target architecture should provide a level of flexibility which favours easy combination of reusable assets so as to allow the design of a multiple client-type products. We intend therefore to derive the new product models into a service-oriented architecture (SOA) (Krafzig et al., 2004). SOA is an architectural style whose goal is to achieve loose coupling among interacting services. A service is a unit of work done by a service provider to achieve desired end results for a service consumer. The core feature of a SOA is the reuse and the composition of existing services built on top of other services to construct the final application. A variant at a requirement level can be thus perfectly projected into a well-defined course-grained function which represents a business service at a design level.

3

Research

There are two main axes in our research : 1.

The engineering for reuse : how to elicit system family requirements into core assets and variable ones and how to model them in such manner so that they include explicit expression of reuse and variability ?

2.

The engineering by reuse : following an evolution process, how to make an optimal usage of these concepts to develop a new project fitting into the product line, while raising quality and reducing costs and time ?

Concerning the first point, we intend to proceed by reengineering. This approach should allow to elicit and document knowledge corresponding to different points of view : functions, control flows, technologies, quality of service and environmental criterions and constraints.


195


As it is unlikely that product variability can be discovered with a monolithic way of working, we suggest that the reengineering process would be derived in different strategies : document analysis, interviews, brainstorming and observation. This approach might offer then a structuring and flexible way to model variable and adaptable assets of knowledge, ready for a later reuse. To model the requirements alternatives, we envisage to use and extend an appropriate existing formal notation supporting the expression of the variability. In requirements engineering, the most recent approach to elicit IS requirements is a goal oriented manner that captures the strategic, high level goals of an enterprise. By expressing goals and the several ways of their achievement, the MAP formalism (Rolland, 1999) seems to be ideal as a means of specifying variability. As shown in figure 1, the map is a directed, labelled, non-deterministic graph with intentions as nodes, and strategies to achieve intentions, as edges. Its nature allows the capture of different forms of variability through multi-edges between a pair of nodes thereby enabling many traversals of the graph from beginning to end. Besides, using the refinement mechanism of the map, it is possible to represent variability at different levels of detail.

Figure 1 : A map sample

The illustration shows the Crews L’Ecritoire system (Tawbi, 2001) which is dedicated to requirements elicitation. The MAP is composed of four goals namely ‘discover goal’, ‘conceptualise goal’, ‘write scenario’ and ‘conceptualise scenario’ which represent the four steps that are followed to define requirements in Crews L’Ecritoire. An edge entering a node identifies a strategy that can be used for achieving the intention of the node. The map therefore, shows which intentions can be achieved by which strategies once a preceding intention has been achieved. For example, before writing a scenario, we may want to check the correctness of the goal through a linguistic analysis that reformulates its narrative description into a well structured form in order to align the scenario to the goal. There are then two strategies

196


Olfa Djebbi

to write a scenario : either in free prose or by filling a template. We can bring out from this example the relevance of the MAP concepts to model variability. We distinguish then two kinds of variability : (i) the variability in the strategies used to fulfil a goal and (ii) the variability in the combination of strategies to satisfy a goal. The key concepts of a MAP which express variability are the Sections and their inter-relationships. A Section is a triplet and represents a way to achieve the target goal Gj from the source goal Gi following the strategy Sij. Each section of the MAP represents a variant. It captures the situation needed to achieve a goal and a specific manner in which the process associated with the target goal can be performed. The combination of sections represents the second kind of variability based on the non-deterministic ordering of intentions and strategies. We depict thus different inter-relationships between sections to express variability : •

the multi-thread relationship : when there are various ways to achieve the same goal starting from the same source

•

the bundle relationship : when the several ways to satisfy the same goal are exclusive

•

the path relationship : when the achievement of a target goal from a source one requires the satisfaction of intermediary goals (precedence/succession relationship)

•

the multi-path relationship : when a goal can be achieved by several combinations of strategies. This is represented in the map by a pair of goals connected by several sections which are inter-related by some relationships mentioned above

•

the refinement relationship : when a section itself can be seen as an assembly of sections. The section can be detailed then as another MAP.

As for the second axe of our research, and given such a model, this step consists in the definition of a process that guides the analyst of a new project in integrating its new requirements and reusing the existing solutions with a possible adaptation. This includes the analysis of the impact of new requirements, the detection of possible conflicts and the insurance of the completeness of the study. Throughout the feedback of this process, we look ahead to maintain the knowledge model already built in the first stage.

References ANASTAPOULOS M and GACEK C (2000) Implementing Product Line Variability. Technical report IESE report N°: 089.00/E, Franhofer IESE publication. ATKINSON C, BAYER J and MUTHIG D (2000) Component-based product line development : the KobrA approach, In Proceedings of the 1st Software Product Lines Conference (SPLC1), pages 289–309.


197


BACHMANN F and BASS L (2001) Managing variability in software architecture, Association for Computing Machinery (ACM) Press, New York, USA. BAYER J (2000) Toward engineering product line using concerns, Generative and Component-Based Software Engineering ( GCSE 2000), Young Workshop 2000. BOSCH J, FLORIJN G, GREEFHORST D, KUUSELA J, HENK OBBINK J and POHL K (2001) Variability issues in Software Product Lines, 4th International Workshop on Product Family Engineering, Bilbao, Spain. CLAUß M (2001) Modelling variabilities with UML, Generative and Component-Based Software Engineering (GCSE 2001), Young Workshop 2001. CZARNECKI K and EISENECKER UW (2000) Generative Programming: Methods, Tools, and Applications. Addison-Wesley. GAMMA E, HELM R, JOHNSON R and VLISSIDES J (1995) Design Patterns: Elements of Reusable Object-Oriented Software. Addison Wesley. GRISS ML (2000) Implementing Product-line Features by Composing Component Aspects, In Proceedings of the First Software Product Line Conference, pp. 271-288, P. Donohoe. GRISS ML, FAVARO J and D’ALESSANDRO M (1998) Integrating Feature Modelling with the RSEB, In Proceedings of the Fifth International Conference on Software Reuse, pages 76– 85, Vancouver, BC, Canada. HALMANS G and POHL K (2003) Communicating the variability of a software product family to customers, Software and System Modelling, Springer-Verlag. JACOBSON I, GRISS M and JONSSON P (1997) Software Reuse: Architecture, Process and Organisation for Business Success. Addison-Wesley, Reading, Massachusetts, USA, ISBN 0201-92476-5. JÉZÉQUEL JM (1998) Reifying Variants in Configuration Management, ACM Transaction on Software Engineering and Methodology, pages 526-538, 1998. KEEPENCE B and MANNION M (1999) Using Patterns to Model Variability in Product Families, IEEE Software, 16(4): pages 102-108. KICZALES G, LAMPING J, MENDHEKAR A, MAEDA C, LOPES C, LOINGTIER JM AND IRWIN J (1997) Aspect-Oriented Programming, In ECOOP’97 – Object Oriented Programming 11th European Conference. KRAFZIG D, BANKE K and SLAMA D (2004) Enterprise SOA: Service-Oriented Architecture Best Practices, Prentice Hall, Paperback, 382 pages, ISBN 0131465759. LEE J and KANG KC (2003) Feature Binding Issues in Variability Analysis for Product Line Engineering, Workshop on "Modeling Variability for Object-Oriented Product Lines" at ECOOP 2003, Darmstadt, Germany, ISBN 3-8330-0779-6, pp. 77-82. LEWIS O (2000) Performance Issues of Variability Design in Embedded System Application Families. PhD Thesis, Faculty of Engineering and Computing-Napier University. ROLLAND C, PRAKASH N and BENJAMEN A (1999) A Multi-Model View of Process Modelling, Requirements Engineering Journal, p. 169-187. STAGO http://www.stago.com, http://www.stago.fr, http://www.stago-us.com SVAHNBERG M and BOSCH J (2000) Issues Concerning Variability in Software Product lines, Software Architecture for Product Families International Workshop IWSAPF- 3, LNCS 1951, Springer, pp. 146-157.

198


Olfa Djebbi

TAWBI M (2001) Crews L’Ecritoire : un guidage outillé du processus d’ingénierie des besoins. PHD Thesis, university of Paris1. TRACZ W (1995) Collected Overview Reports From the DSSA (Domain-Specific Software Architectures) Project, Technical Report: Lockhead Martin Federal Systems, Owego, NY 13827-3998, USA. VAN GURP J (2000) Variability in Software Systems, the key to Software Reuse. Licentiate Thesis, University of Groningen, Sweden. WEISS D, LAI CTR and WEISS DM (1999) Software Product-Line Engineering, A FamilyBased Software Development Process. Addison-Wesley Publishing Company, ISBN 0-20169438-7.


199

A Unified RE Approach for Software Product Evolution: Challenges and research agenda Pnina Soffer a, Leah Goldin b, and Tsvi Kuflik a a b

MIS Department, Haifa University, Carmel Mountain 31905 Haifa, Israel Golden Solutions, P.O.B 6017, Kfar Saba, Israel

Abstract Requirements engineering plays an important role in the evolution of software products, where a product evolves through new releases that are developed considering market prospects rather than a specific customer. The challenges posed in this situation, which differ from customerspecific RE challenges, have hardly been emphasized in the RE literature. The paper presents an evolution scenario, outlining concurrent RE cycles that take place within this scenario. The cycles relate to the sales process of the current release, the development processes of the next release and possibly of an interim customer-specific release, and the planning process of future releases. The paper characterizes the RE processes that comprise these concurrent cycles and their relationships, and identifies the need for managing the entire scenario in an integrative manner. This forms a basis for specific challenges as an agenda for future research. Keywords: RE for product software, Software evolution, Requirements management

1

Introduction

As of today, the main business trend of software companies is the development of offthe-shelf software products. Two major requirements engineering phases exist in the life of off-the-shelf software products. The first one is an initial development of a new product. There may be no real customers at this time, and requirements are defined on the basis of market analysis and expectations (Potts, 1995). The second phase is an ongoing one, when a product already exists and evolves as new releases are developed periodically. This phase acknowledges the success of the product, as there is an increasing number of customers purchasing it, and these customers require more and more features as part of their growing taste. As well, targetting new market prospects as well as the availability of new technologies may lead to additional requirements. The main focus in the RE literature so far has been towards requirements posed by a specific customer, for a specific contract, through interaction with such customer (e.g., Bray, 2002). This does not explicitly correspond with the reality of RE for software product evolution, where requirements are collected and combined from various sources, then analysed and prioritized in order to generate the content of the next product release, in parallel with the preparation of (possibly) few other releases to follow. As well, traditional RE approaches take a formal view and are developed by and for software engineers, while requirements in product manufacturing companies are frequently defined by marketing people, taking business-oriented considerations. Some attempts to address this situation have been made during the last decade. Potts (1995) described the product RE situation of “imaginary requirements for imaginary customers”. Karlsson et. al. (2002), Sawyer (2000), and Xu and Brinkkemper (2005) indicated the various challenges of this situation, attempting to create a focus of the research community on these challenges. Specific issues that gained 200


Soffer, Goldin and Kuflik

some attention are requirements prioritization (Regnell et.al., 2001; Regnell et.al., 2003), commonality and variability management (Deifel, 1999), requirements dependency (Akker et. al., 2005, Karlsson et. al., 2002), and release planning (Akker et. al., 2005; Carlshamre and Regnell, 2000; Carlshamre, 2002; Dag et. al., 2005) including product vs. project tradeoffs (Grynberg and Goldin, 2004). Other issues, which are addressed also in the context of “traditional” RE, such as requirements traceability and configuration management, are of relevance to the product evolution situation. However, these attempts address specific issues one at a time, and do not take a holistic view, which we claim is essential, due to the relationships among all the activities which comprise an RE process. Recently, attempts to empirically study and characterize the product evolution situation have been made, addressing Market-Driven RE in general (Carlshamre and Regnell, 2000; Dahlstedt et. al., 2003; Karlsson et. al., 2002), prioritization (Regnell et. al., 2001), and release planning (Carlshamre and Regnell, 2000). We view these attempts as very important steps towards gaining an understanding of the practice and needs in this situation. However, a full understanding is yet to be achieved. This paper proposes a scenario of product evolution, outlining concurrent RE cycles that take place within this scenario. The scenario is based on a combination of information obtained from the literature and observations from our accumulated industrial experience with a number of companies, both as a customer and as a requirements engineering consultant, working with software vendors. It characterizes the RE processes that comprise these concurrent cycles and their relationships, and identifies the need for managing the entire scenario in an integrative manner.

2

Product Release Lifecycles

A common scenario of a product developing organization is as follows. At present there exists a current release (denoted as release N), which is being sold as an off-theshelf product. The next release (N+1) is being developed and is planned to become commercial at a known time in the future. At the same time, requirements for future releases (N+2, N+3..) are already being collected. Figure 1 presents a typical schema of a software product release lifecycle in a product development company that is a continuous evolution of the product with respect to market needs. During the development of release N, Marketing was engaged in learning the market, identifying business opportunities, and learning about their competitors. All that information should be available at the beginning of the next product release development (N+1), which starts with Marketing producing the Marketing Requirements Document (MRD) that contains the market requirements for release N+1. Once the MRD is handed-over to the Research & Development (R&D) group, the R&D analyses the Software Requirements Specifications (SRS) based on the current product release (N). The SRS is then used as the basis for implementation and testing of the new product release (N+1). Note that the MRD is a result of planning and analysis, rather than a set of “raw” requirements. The further analysis towards the SRS is of a more technical nature. Dag et. al. (2005) refers to this by distinguishing market requirements from business requirements, which are the result of analysis.


201

A Unified RE Approach for Software Product Evolution

Figure 1: software product release lifecycle

As presented above, the company is occupied at the same time with release N (currently sold to customers), release N+1 (under development, with specific delivery date), and future releases (requirements identification, prioritization, and scoping for future versions). This development process is only a representative part of a larger process of product roadmap planning and evolution. The overall product road map is illustrated in Figure 2. The release (N+1) lifecycle is normally called project lifecycle and is bounded by scope, schedules and budget.

Figure 2: Product roadmap

At this situation assume a strategic customer demands specific adaptations to be made to the product to meet his special needs. This means another project develop-

202



ment cycle (release N’) in parallel to the release N+1 lifecycle. Unlike the other development projects, here the requirements address a specific customer, and are based on a gap analysis between the current release (N) and the customer’s needs. This gap analysis originates in the pre-sales process, where the current release (N) is being sold to customers. During this process, the specific customer’s requirements (e.g., Soffer et. al., 2001) are captured in view of the current product release. The aim of RE in the pre-sales process is to elicit customer’s requirements and accommodate them within the current release (N) features. However, if major gaps are found, they may result in a customer-specific version of the product (N’). The requirements for release N’, once approved, are sometimes termed “commitments”, and the N’ release is a “customized” release. Note that although these requirements are included in release N’, they are not a part of the product roadmap, and should be considered and evaluated for deciding whether they will be included in a future release (and which one). 4 . Commitment to release(N’ ) 3 . Answer RFPs and accumulate wish - list for release(N+2 ) MRD 2 . Developing release(N+1) 1. Selling to customers release(N )

01/01/ 2005

01/01/ 2006 01/02/ 2006

31/08/ 2004 22/10/ 2004 Release(N) actual

30/03/ 2005 Release(N+1) develooped 20/02/ 2005 Release(N’) committed

18/09/ 2005 Release(N+2) planned

Product Roadmap Figure 3: Four RE cycles related to product roadmap

3

RE Cycles in Product Evolution

From the product road-map point of view, all the above-mentioned RE cycles (N, N', N+1, N+2) are related to each other. Marketing & Pre-sales forces keep an ongoing effort of replying to requests for proposals (RFPs) to different prospects. Answering an RFP is mandatory for the business in order to stay in the market, even if the bid does not win. During that time, a list of market needs is accumulated into a wish-list which will then be used as input for preparing the MRD for a product release that will provide the required solution, which will hopefully be N+2 or later, but may also require interim customized releases, to support business constraints. Note that at this


203


stage the MRD for release N+1 is already determined and is being used. The development based on requirements that are within the scope of release N+1 is in process, so any "urgent" new requirements will necessarily casuse an interim, unplanned customized release (N'). Based on the above description, we can identify four concurrent RE cycles, as illustrated in Figure 3.

4

Unified RE Approach

RE processes, as traditionally described in the literature, are elicitation, analysis, specification, and validation (Bray, 2002). Since requierments tend to change, and since in practice the requirements elicitation process is asynchronous, management becomes a crucial issue (Dag et. al., 2005). Since requirements need to be realized in timely fashion, release planning has been introduced as a substantial process as well. All in all, the traditional activities of requirements engineering, together with the specific additions need to be integrated into a complete framework to support RE for product evolutionary development. This section discusses the individual components and what is required from an integrated RE approach. A summary of this discussion is presented in Table 1, whose colomns represent the product releases, while the raws represent the domains of RE processes, i.e., requirements elicitation, analysis, specification, validation, release planning, and requirements management . 4.1 Requirements Elicitation Elicitation with respect to future releases is of a different nature compared with elicitation for releases N and N’. Thus, requirements elicitation should be divided into three different cases: 1. Requirements elicitation regarding release N addresses the specific needs of a customer with respect to the existing product version. It starts with a requirements document prepared by the customer, usually in a form of an RFP, for a first match with the existing product capabilities. Although the customer requirements are presumably specified in the RFP, elicitation proceeds through pre-sales and sales sessions. The purpose of elicitation in this case is not to identify requirements for further evolving the product. Rather, it is to gain an understanding of the customer needs in order to identify the existing product features that meet these needs. A second outcome of this process is unsatisfied requirements, which can be documented and considered for future releases. 2.

If substantial gaps are identified when attempting to sell release N, these may lead to requirements for a customized release N’. Requirements elicitation in this case resembles “traditional” elicitation, since it addresses a specific known customer. It elaborates the identified gaps into specific requirements.

3.

Elicitation for future releases is the elicitation usually referred to as involving “invented requirements” (Potts, 1995). This is an on-going process, where requirements are gathered from various sources, such as customer visits, customers’ feedback on current releases, sales personnel inputs, and to a lesser extent, market surveys (Dahlstedt et. al., 2003). Moreover, unsatisfied

204



requirements when selling the current release (N), as well as the specific requirements elicited for release N’ are also considered as requirements sources for future releases. A major challenge here is to avoid requirements duplication and overload (Deifel, 1999; Sawyer, 2000). As seen in Table 1, release N+1 is considered as being currently developed to an already defined scope. Hence, elicitation is never aimed at it, but rather at release N+2 and ahead, to be planned afterwards. 4.2 Requirements Analysis Analysis traditionally deals with elaboration aimed at removing ambiguity, conflict identification and resolution, feasibility analysis, as well as resource and cost estimation. The most important aspects of the analysis in market oriented RE are requirements prioritization (Dahlstedt et. al., 2003; Regnell et. al., 2001), dependency identification (Akker et. al., 2005; Dahlstedt et.al., 2003; Carlshamre and Regnell, 2000), and resource and cost estimation (Akker et. al., 2005; Carlshamre, 2002; Dahlstedt et.al., 2003). Note that dependency among requirements can either be functional dependency or value dependency, where the customer value of a certain requirement can be fully realized in the presence of another requirement (Akker et. al., 2005). Regarding our four RE cycles, as indicated in Table 1, resource and cost estimations are of importance to releases N’, N+1, and future releases. However, RE for future releases emphasizes prioritization and dependecy analysis (Akker et. al., 2005; Carlshamre and Regnell, 2000; Dahlstedt et. al., 2003; Regnell et. al., 2001; Karlsson et. al., 2002; Regnell et. al., 2003), as a basis for release planning. Gap analysis, which is not usually discussed with respect to requirements analysis, is particularly important both for releases N and N’. It may also form a basis for time / cost estimates for future releases requirements. The analysis, specifically regarding release N and N’, can reuse knowledge gained in the past in similar projects. Analysis of requirements for future releases (N+1 ahead) may also involve variability management. Generic requirements are generalizations of specific customer requirements and a result of domain analysis. These specific requirements, in turn, may be expressed as certain variants and options to be included in the product. 4.3 Specification & Documentation Requirements Specifications is the written (documented) interpretation given to requirements in order to use them as a basis for softeware development. These specifications are subjected to requirements quality criteria, such as clarity, completeness, understandability, verifiability, etc., in order to assure a well defined specifications leading to a quality software product. Regarding our RE cycles, it is mandatory to have well-defined specifications per each release. As indicated by Dahlstedt et. al. (2003) and by Deifel (1999), in practice documentation is frequently in the form of informal textual requirements before a complete release specification is produced. The release specifications themselves are commonly written as delta documents per each release, that indicate the incremental part of specifications with regards to the referenced release, N'ÆN, N+1ÆN, N+2ÆN+1. After several releases it may become impossible to understand the full picture of the current product specifications from the different delta documents. A good requirements management process can sort this problem. The specifications should provide a complete definition of a system at whatever development stage we


205


are interested: N that exists, N+1 that is currently being developed, or N+2 that is planned. 4.4 Requirements Validation Validation of requirements seeks to discover errors in the specifications (Bray, 2002). Validation for releases N and N’ is similar to “traditional” requirements validation, since a specific customer is involved and can validate the requirements. As indicated by Dahlstedt et. al. (2003) and by Deifel (1999), validation of requirements for future releases is somewhat more difficult due to the absence of real customers. Beta versions are used for validation (of release N+1), but at a rather advanced phase in the release life-cycle. Here traceability to the origin of a requirement may play an important role. Some of the requirements for future releases are results of gaps identified when selling release N (or past releases). These requirements were originally raised by real customers, who probably validated them in the past, and track can be kept both for the test plan and for results found. As well, it may be possible that these customers, intending to upgrade their current product release, will be interested in validating their requirements to be included in future releases. As indicated in Table 1, this is particularly relevant for the early phases in the life-cycle of release N+1. 4.5 Release Planning Release planning has started to attract attention recently, indicated by various theorybased approaches (Carlshamre, 2002; Regnell et. al., 2003) as well as practice reports (Carlshamre and Regnell, 2000; Dahlstedt et. al., 2003; Regnell et. al., 2001). Nevertheless, all the reported approaches rely on common building blocks, which are requirements prioritization, roadmapping (which is a view of the product evolution through time), dependency analysis, and resource allocation in view of time/cost estimates. Strategic market planning is sometimes applied, but usually rather as external guidelines than as an integral part of this activity (Dahlstedt et. al., 2003). Release planning naturally relates to requirements for future releases only and not for releases N and N’, although awareness of future release plans may affect these requirements, knowing that certain solution are expected to be available in the near future, i.e., managing product roadmap may eliminate N’ efforts. 4.6 Requirements Management In general, requirements managements is about centerally storing, maintaining, and using the products of all the above discussed requirements processes. In the situation described, requirements management is the centeral control, that integrates all the products, provides the needed connectivity and enables the efficient use of knowledge gained in the various processes, keeping traceability and configuration control. Requirements management should employ a central repository designed to meet the specific challenges of the various processes in the concurrent RE cycles taking place (Grynberg and Goldin, 2004). It should store requirements of the following categories: (a) satisfied requirements (in support of the current release sales-oriented RE process), (b) requirements included in customized releases (N’), that can be considered for inclusion in future releases, (c) unsatisfied requirements already included in future release plans, (d) unsatisfied requirements yet to be planned, and (e) re-

206



quirements that were rejected in the past, together with the reasons for rejecting them (in case they are raised again for reconsideration). Different kinds of requirements groupings may be needed. Two important ones are (a) functional grouping, as a basis for possible generalization, and (b) dependency-related grouping. While release N sales use current satisfied requirements as recorded and adds unsatisfied requirements to the repository, release N’ may reuse requirements that appear in other customized releases and, again, store its requirements in the repository. Release N+1, being developed to a defined requirements set, may introduce changes to them, hence configuration management and traceability are of importance for it. Table 1: RE processes in the concurrent RE cycles Release Process

N

N’

Requirements Elicitation

Requirements to be satisfied within current release, gap detection

Elaboration of gap analysis

Requirements Analysis

Gap analysis

Gap analysis, time / cost estimation,

Dependency analysis, time / cost estimation, generalization and variability management

Prioritization, dependency analysisn, time / cost estimation, generalization and variability management

Delta documents

Delta documents

Delta documents

Along with the customer

Beta version; with specific customers

Requirements Specification Validation

Along with the customer

Release planning

Requirements Management

Current satisfied requirements, traceable unsatisfied requirements

Traceable commitements requirements in other customized releases

N+1

N+2 ahead Multiple sources, both specific and non-specific customer

Based on resource allocation, dependencies, prioritization

Based on resource allocation, dependencies, prioritization, roadmapping

Requirements configuration management

Status-managed unsatisfied requirements, traceable to origin mapped to planned releases, configuration management


207


5

Discussion: Challenges of a Unified RE Approach

RE in software product evolution is crucial. In practical situations, even though at the initiation of the product the requirements are frquently well handled, market pressures as well as schedule and resource limitations may lead to deterioration in the RE processes during the evolution of the software product. This may be viewed as a paradox, that during a software product evolution, the more the RE process is required the less it is done. Considering the above discussion, it seems that a key issue in effectively utilizing the information gathered and created through the four concurrent RE cycles is to be able to capture their inter-relations. This is particularly important with respect to the N and N’ cycles, which are usually regarded as separate activities, not related to road mapping and release planning. In many cases these two cycles are performed by different organizational units (sales for N and N’ vs. marketing for the others) or even outsourced. Nevertheless, the information these cycles can provide is valuable and should be available for the entire RE effort performed in the organization. We believe that the inter-relations within this scenario should be addressed by an appropriate requirements management process, incorporating an appropriate infrastructure. Specific RE activities discussed above, such as analysis, verification, and release planning, should be designed when the entire scope of information and traceability is taken into account. At the same time, each of the four RE cycles requires different capabilities, tools, and views of the requirements database. We therefore identify the following challenges, posed mainly on the requirements management process and infrastructure, to support a unified RE approach. Challenge 1: unification. Defining a requirements management process that intersects between the products of the different RE processes in the different cycles. Such process should enable the utilization of the massive amount of information gathered and produced while avoiding overload. It should be supported by a requirements management infrastructure, incorporating a requirements database that allows full traceability and configuration management of both requirements and releases. Challenge 2: distinction. Defining distinct views of the requirements database and support functionality required for the different activities in the four cycles. The challenge is to separate and distil the specific RE activities and deliverables per each product release during its evolution. Per each cycle we need the specific RE scenario that aggregates all and only the RE activities required for that specific release type. It seems that for future releases in the product roadmap (N+2 ahead) the emphasis is on elicitation, analysis, specification, and planning. However, in current release N, RE should produce its benefits for assisting in the sales activities, consuming minimal RE effort, and producing information for future utilization. As for releases in development (N', N+1), the main RE effort will be in requirements management, specifically configuration control, and in traceability-enabled verification.

6

Conclusion

The motivation for this paper was to analyse the RE activities within software product evolution. This led us to the concept of Unified RE Approach that by different RE scenarios we can handle better the requirements during the evolution of a software product releases.

208



From the above it is clear that in practice, requirements are gathered, analyzed, specified and validated in a continuous process. Product releases are dynamically planned, supporting evolving market/customers needs. In a unified RE approach each scenario per every release type can be viewed as a temporal "snapshot" or view of the product requirements repository. This dynamic situation in turn requires complicated mechanisms for requirements traceability in order to keep track on the actual content of the various products releases. In order to support such dynamic RE approach, RE scenarios need to be defined and evaluated, covering all the above-mentioned RE attributes and activities. The unified RE approach should be based on already existing concepts and methods, while utilizing the inter-relations between the different processes and deliverables for achieving a better support to each distinct activity.

References AKKER JM VAN DEN, BRINKKEMPER S, DIEPEN G and VERSENDAAL J (2005) Determination of the Next Release of a Software Product: an Approach using Integer Linear Programming, In Proceedings of the CAiSE’05 Forum, (BELO O, EDER J, PASTOR O, CUNHA FJ, Eds), pp. 119-124, Porto, Portugal. BRAY IK (2002) An Introduction to Requirements Engineering, Addison-Wesley. CARLSHAMRE P and REGNELL B (2000) Requirements Lifecycle Management and Release Planning in Market-Driven Requirements Engineering Processes, In Proceedings of the 11th International Workshop on Database and Expert Systems Applications (DEXA’00) pp. 961-966, Greenwich, London, U.K. CARLSHAMRE P (2002) Release Planning in Market-Driven Software Product Development: Provoking an Understanding, Requirements Engineering 7, 139-151. DAG JN OCH, GERVASI V and BRINKKEMPER S (2005) A Linguistic-Engineering Approach to Large-Scale Requirements Management, IEEE Software 22(1), 32-39. DAHLSTEDT AG, KARLSSON L, PERSSON A, DAG JN OCH and REGNELL B (2003) Market-Driven Requirements Engineering Processes for Software Products – a Report on Current Practices, In International Workshop on COTS and Product Software: Why Requirements Are So Important (RECOTS), held in conjunction with the 11th IEEE International Requirements Engineering Conference, September 2003, Monterey, USA. DEIFEL B (1999) A Process Model for Requirements Engineering of CCOTS, In 10th International Workshop on Database & Expert Systems Applications, pp.316-321 IEEE Computer Society Press. GRYNBERG A and GOLDIN L (2004) Product Management in Telecom Industry – Using Requirements Management Process, In Proceedings of SwSTE'04, Tel Aviv, Israel. KARLSSON L, DAHLSTEDT A, DAG JN OCH, REGNELL B and PERSSON A (2002) Challenges in Market-Driven Requirements Engineering – an Industrial Interview Study, In 8th International Workshop on Requirements Engineering: Foundations for Software Quality, Essen, Germany. POTTS C (1995) Invented Requirements and Imagined Customers: Requirements Engineering for Off-the-Shelf Software, In Proceedings of Second IEEE International Symposium on Requirements Engineering (RE’95), pp. 128-130, IEEE Computer Society.


209


REGNELL B, HOST M and DAG JN OCH (2001) An Industrial Case Study on Distributed Prioritization in Market-Driven Requirements Engineering for Packaged Software, Requirements Engineering, 6, 51-62. REGNELL B, KARLSSON L and HOST M (2003) An Analytical Model for Requirements Selection Quality Evaluation in Product Software Development, In Proceedings of the 11th IEEE International Requirements Engineering Conference, IEEE Computer Society. SAWYER P (2000) Packaged Software: Challenges for RE, In Proceedings of the 6th International Workshop on Requirements Engineering: Foundation for Software Quality, Stockholm, Sweden. SOFFER P, GOLANY B, DORI D and WAND Y (2001) Modelling Off-the-Shelf Information Systems Requirements: An Ontological Approach, Requirements Engineering 6(3), 183199. XU L and BRINKKEMPER S (2005) Concepts and Research Framework of Product Software, In Proceedings of PHISE 2005 Workshop, Porto, Portugal. YEH AC (1992) Requirements engineering support technique (REQUEST): Assessment of a market driven requirements management process, In Proceedings of the Second Symposium on Quality Software Development Tools, pp. 211-223, New Orleans, LA, USA.

210


Situational Requirements Engineering Processes

Situational Requirements Engineering Processes

Suggest Documents

Requirements Definition for the Situational Method Engineering

Situational Requirements Engineering of Web ... - Semantic Scholar

Requirements Definition for the Situational Method Engineering

Situational Requirements Engineering for the ... - CiteSeerX

Requirements Engineering Processes - Ian Sommerville

Implementing requirements engineering processes ... - CiteSeerX

requirements engineering processes, tools/technologies

An Insight into Requirements Engineering Processes

Improving Requirements Engineering Processes in ...

Market-Driven Requirements Engineering Processes for ... - CiteSeerX

a review of requirements engineering processes ...

a review of requirements engineering processes ...

Implementing Requirements Engineering Processes - IEEE Xplore

Requirements Engineering Processes Feasibility studies Elicitation ...

Requirements Engineering Security Requirements

Requirements for Requirements Engineering Techniques ...

Requirements Processes: An Experience Report

situational method engineering: combining assembly ... - Laboratoire I3S

Situational Factors Affecting Requirement Engineering ... - IEEE Xplore

situational method engineering: combining assembly ... - Laboratoire I3S

Reuse Mechanisms in Situational Method Engineering

Requirements Engineering Management Handbook

Requirements Engineering: An Overview

Ontology as a requirements engineering product - Requirements ...