RENOIR NORDIC WORKSHOP ON PARTICIPATIVE REQUIREMENTS ENGINEERING

 

 

 

5-6. August 1999

Jyväskylä

Organisers: RENOIR and University of Jyväskylä

 

Organizers

 

Janis Bubenko (Royal Institute of Technology, Stockholm), Kalle Lyytinen (University of Jyväskylä) and Barbara Farbey (University College London)

 

 

 

Participants

 

Janis Bubenko - Janis@dsv.su.se,

Kalle Lyytinen - kalle@jytko.jyu.fi,

Barbara Farbey - B.Farbey@cs.ucl.ac.uk,

Danny Brash - Danny@dsv.su.se,

Anne Persson - Anne.persson@ida.his.se,

Claes-Göran Lindström - claes-goran.lindstrom@itplan.se,

Annika Bergenheim - Annika.bergenheim@sales.vattenfall.se,

Janis Stirna - Js@dsv.su.se,

Ingi Jonasson - Ingi@ida.his.se,

Christer Nellborn - Christer.nellborn@astrakan.se,

Stefano de Panfilis - Depa@mail.eng.it,

Dario Avallone - Dario@mail.eng.it,

Jorgen Boegh - Jb@delta.dk,

Jyrki Heikennen - Jyrki.heikkinen@nokia.com,

Uoelvi Nikula - Uolevi.nikula@lut.fi,

Timo Kakola - Timo.kakola@cc.jyu.fi,

Janne Kaipala- Jka@jytko.jyu.fi,

Jouni Huotari Jhuotari@cc.jyu.fi,

John King - king@wang-wei.ics.uci.edu,

Anja Mursu - anjamu@jytko.jyu.fi,

Juhanni Iivari - iivari@rieska.oulu.fi,

Sari Hakkarainen - sari@zaphod.sisu.se,

Mika Jussila- mika.k.jussila@nokia.com

Marjo Kauppinen Hutmhk@cs.hut.fi,

Zheying Zhang zhezhan@cc.jyu.fi

 

 

 

The purpose of the meeting was to consider Requirements Engineering in the context of the Nordic tradition of participation in the workplace: hence Participative Requirements Engineering. The intention was to seek out the views and problems of industrial members, as well as the concerns of the academic community.

 

The conference was sponsored by RENOIR and open to all RENOIR nodes and invited industrialists. It was organised by Kalle Lyytinen, and Janis Bubenko. Administrative support came from the University of Jyvaskyla, in particular from Maarit Kinnunen.

 

 

16 papers were presented.

 

1. Danny Brash, Putting Participative Requirements Modelling in Context, Stockholm University/Royal Institute of Technology

 

2. Anne Persson: The utility of Participative Enterprise Modelling in Requirements Engineering - some influencing actors, University of Skövde

 

3. John King and Kalle Lyytinen: High Level Requirements Engineering- How to Derive Organisationally Sound and Valid Requirements, University of California, Irvine and

University of Jyväskylä

 

4. Claes-Göran Lindström Lessons Learned from Applying Business Modelling, Exploring Opportunities and Avoiding Pitfalls, Stockholm University,

 

5. Janis Stirna Requirements Driven Enterprise Modelling Tool Acquisition,

Royal Institute of Technology and Stockholm University

 

6 Panel: Four views for Assessment of RE practices

Barbara Farbey, RENOIR, University College London

Janis Bubenko, Royal Institute of Technology

Marjo Kauppinen, Helsinki University of Technology

John King, UCI

 

7. Jyrki Heikkinen Challenges to Requirements Engineering at Nokia, Nokia Research Center

 

8. Annika Bergenheim Creating a Learning Organisation - Experiences from using EKD as a participative approach in building new models for human resource management, Vattenfall AB

 

9. Dario Avallone, The Euro introduction requirements, Engineering Ingegneria Informatica S.p.A.

 

10. Timo Käkölä: Success factors of GroupWare supported requirements management

processes, University of Jyväskylä

 

11. Sari Hakkarainen: On Adaptive RE Environments for Information Service Development, SIS

 

12. Stefano De Panfilis: Requirements Engineering with Squid, ´Engineering Ingegneria Informatica S.p.A.

 

13. J. Boegh, A method for software quality planning, control, and evaluation, Copenhagen University

 

14. Ingi Jonasson, Organisational patterns as a contribution to Requirements Engineering, University of Skövde

 

15. Christer Nellborn Process-based System Service Requirements, The Royal Institute of Technology

 

16. Zheying Zhang, A Framework for Reuse of Software Architects, University of Jyväskylä

 

In addition to the papers three workgroups were organised:

 

1. How to develop valid theories for RE

2. What is needed to develop industrially robust methods for RE

3. What is participative RE and what are its main success factors? (see appendix)

 

 

NEXT STEPS

 

The participants agreed to meet again in 2000, in conjunction with CAISE 2000, to be held in Sweden. Anne Persson kindly agreed to organise the meeting if it is accepted by the CaiSE 2000 organizing committee. Barbara Farbey can send Anne Persson a proposal for a workshop and that she will put the proposal before the organising committee.

 

It was hoped that RENOIR 1, although officially terminating in May 2000, would be able to contribute financially since meeting would be in the first week of June. Barbara Farbey would ask the Executive Board to put aside funding for the event. We will also ask for funding from our industrial partners directly.

 

COMMENTS

 

Perhaps the major contribution of the workshop came from the mix of industrial and academic experience, which combined to give critical feedback to those whose research was still at the formative stage, and throw up new, practice-based challenges for research in RE. There was a lot of detailed and very useful discussion of the practical ways to improve modelling and specification of requirements and how to engage in practical dialogues between IT professionals and end users. The workgroups, in addition, had fruitful discussion of RE research and its theory base, adequate research approaches, modelling guidelines and stakeholder views.

 

The "people network" was also greatly strengthened which is critically important for RENOIR and for RE.

 

Group 1: How to develop valid theories for RE

 

Some observations and conclusions from the workshop

 

  1. There is not one single theory of RE. We need several that are applicable for different situations.
  2. Differentiate theories of domains of RE (like aviation, telecommunication protocols) and theories of RE proper. Both are needed but mostly focus in the past has been on developing notations, formal systems that can capture the domains. Much less work on RE proper (as a process and activity).
  3. Theory building starts with classifications that can lead to observe significant differences in behaviors. Very little work is known of how to develop important and significant classifications for theory building in RE.
  4. Theory building is always contextual.
  5. Theory building is always limited.
  6. Theories come in different sorts (predictive, explanatory, constructive, domain constituting). When comparing and assessing theories one must be aware of the espoused purposes of different theories.
  7. There are different criteria which affect the choice of theory and its assessment. These include generality, accuracy and simplicity. The are goals are contradictory in the sense that theories cannot be develop that satisfy well all three criteria.
  8. Theories in RE seldom create "practices" or lead " practices". Very often they rationalize, reconstruct and abstract practices. Sometimes they can lead to changes in viewing and seeing the practice (sometimes theories are just interesting!)

Group 2: What is needed to develop industrially robust methods for RE

Questions

What is robust

Who should promote/deploy the method

Why the methods are not accepted and used

 

What is robust

Proven in combat

Can be integrated with other methods

Sound

Scalable

Industry best practices (as components of the method)?

 

Why the methods are not accepted and used

Academia do not understand practice

Too rationalistic, inflexible, complex

 

Organizational inertia

Lack of evidence of real business benefits

 

Who should promote/deploy the method

Software engineers

Software owners

Project manager

 

Group 3: Participative Requirements Engineering and its Critical Success Factors

 

  1. The group noted that there were some semantic problems: what, for example, was a requirement? As opposed to a "feature"?
  2. A high-level model was agreed as shown below.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

A list of "do wells" (Critical Success Factors) was drawn up:

 

  1. Choose the right stakeholders
  2. Who decides and how?
  3. Consider future stakeholders (ref. John King)
  4. Contact, involve and motivate them
  5. Make clear what's in it for them
  6. Get them back (to a second meeting)
  7. Give them feedback, quickly
  8. Involve user and non-user stakeholders - those who affect and are affected by the process and outcomes of the decision making process and the product
  9. Persuade the decision makers
  10. Developers
  11. Business: talk in terms of money, quality, quality of work, quality of working life
  12. Individuals and groups
  13. Use the power of the group
  14. Need good facilitators
  15. Match the facilitative model with the participants
  16. The relationship [of the people or the group to the project must be decisive
  17. Train facilitators
  18. Judicious use of consultants
  19. Sell facilitation
  20. DON'T BE TOO RIGID
  21. INSPIRE
  22. BUYER EDUCATION
  23. LEARN HOW TO COMMUNICATE WITH PEOPLE WITH MONEY

 

In the discussion the point was made that there may sometimes be a gap between some person's role and their responsibilities.