Skip to main content
SpringerLink
Log in

Collaborative Requirements Elicitation: A Process-Centred Approach

  • Published:
Group Decision and Negotiation Aims and scope Submit manuscript

Abstract

Requirements Elicitation is one of the first and most critical processes in system engineering. In this paper we will focus on the collaborative aspects of requirement elicitation, in the context of system development. To do so, we adopted the separation of concerns method. Using this method we separate engineering aspects from collaboration aspects in order to study both aspects and finally integrate them. For the collaborative aspect of requirements elicitation we looked at Collaboration Engineering. Collaboration Engineering is an approach to design and deploy processes for recurring collaborative tasks that can be transferred to practitioners to execute for themselves without intervention of professional facilitators. From an engineering perspective we will use the requirements engineering processes described by system engineering standard EIA-632 as a starting point. To integrate these we will use methods and techniques from Collaboration Engineering to specify the collaborative processes involved in this requirements elicitation approach. An object model was build using Unified Modelling Language. This model shows different concepts underlying our approach. Finally two case studies are presented to evaluate this approach.

This is a preview of subscription content, log in via an institution to check access.

Access this article

Log in via an institution

Price excludes VAT (USA)
Tax calculation will be finalised during checkout.

Instant access to the full article PDF.

Institutional subscriptions

Fig. 1
Fig. 2
Fig. 3
Fig. 4
Fig. 5
Fig. 6
Fig. 7
Fig. 8
Fig. 9
Fig. 10
Fig. 11
Fig. 12
Fig. 13

Similar content being viewed by others

References

  • Acosta CA, Agerrera LA (2006) Supporting the collaborative collection of user’s requirements. In: Proceedings of international conference of group decision and negotiation (GDN) 2006, Germany

  • Boehm B, Bose P, Horowitz E (1994) Lee MJ (1994) Software requirements as negotiated win conditions. In: Proceedings of international conference on requirements engineering. IEEE Press, Piscataway, NJ

  • Boehm B, Grünbacher P, Briggs RO (2001) Developing groupware for requirements negotiation: lessons learned. IEEE Software 18

  • Briggs RO, de Vreede GJ (2001) ThinkLets, building blocks for concerted collaboration. Delft University of Technology, Delft

    Google Scholar 

  • Briggs RO, de Vreede GJ (2001) Nunamaker Jr JF (2001) ThinkLets: achieving predictable, repeatable patterns of group with group support systems (GSS), Group Systems

  • Briggs RO, de Vreede GJ (2003) Collaboration engineering with ThinkLets to pursue sustained success with group support systems. J Manag Inf Syst 19(4):31–64

    Google Scholar 

  • Briggs RO, Kolfschoten GL, de Vreede GJ, Dean DL (2006) Defining key concepts for collaboration engineering. In: Proceedings of 12th Americas conference on information systems, Acapulco, Mexico August 4th–6th 2006

  • Briggs RO, Reinig BA (2007) Bounded ideation theory. In: Proceedings of the 40th Hawaii international conference on system sciences 2007

  • Coulin CR (2007) A situational approach and intelligent tool for collaborative requirements elicitation. Technical report, PhD thesis, University of Sydney (Australia) and University of Toulouse (France)

  • Den Hengst M, van de Kar E, Appelman J (2004) Designing mobile information services: user requirements elicitation with GSS design and application of a repeatable process. In: Proceedings of the 37th Hawaii international conference on system sciences

  • Den Hengst M, Dean DL, Kolfschoten G, Chakrapani A (2006) Assessing the quality of collaborative processes. In: Proceedings of the 39th annual Hawaii international conference on system sciences, vol 1, 04–07 Jan, pp 16b–16b

  • EIA-632 (1999) EIA-632: Processes for systems engineering. Electronic Industries Alliance, ANSI/EIA-632-1998 Approved: January 7, 1999

  • Essame D (2002) La méthode B et l’ingénierie système.Réponse à un appel d’offre. Technical report, IUT-Nantes, Université de Nantes

  • Fjermestad J, Hiltz SR (2001) A descriptive evaluation of group support systems case and field studies. J Manag Inf Syst 17:115–159

    Google Scholar 

  • Frost and Sullivan (2006) Meetings around the world: the impact of collaboration on business performance. Verizon Business and Microsoft, Technical report, Frost and Sullivan

  • Goguen J, Linde C (1993) Techniques for requirements elicitation. In: First IEEE international symposium on requirements engineering (RE’93), San Diego, USA, 4–6th Jan 1993, pp 152–164

  • Goguen JA (ed) (1994) Requirements engineering as the reconciliation of social and technical issues. Oxford University, Computing Lab., UK, pp 165–199

  • Gray B (1989) Collaborating: finding common ground for multiparty problems. Josses-Bass Publishers, San Francisco

    Google Scholar 

  • GroupSystems (2006) Groupsystems solutions, http://www.groupsystems.com. Accessed on Sept 2008

  • Hoa N (2007) Goal management for a multisession dialogue. Information Technology Convergence ISITC 2007, 23–24 Nov 2007, pp 301–305

  • IEEE (1990) IEEE Std 610.12-1990 Standard Glossary of Software Engineering Terminology

  • Kendall KE, Kendall JE (2002) System analysis and design, 5th edn. Prentice Hall, USA

    Google Scholar 

  • Knoll S, Horton G (2010) Changing the perspective: improving generate thinkLets for ideation. In: Proceedings of the Hawaii international conference on system science. IEEE Computer Society Press, Kauai (HI)

  • Kolfschoten G, Appelman JH, Briggs RO, de Vreede GJ (2004) Recurring patterns of facilitation interventions in GSS sessions. In: Proceedings of Hawaii international conference on system sciences. IEEE Computer Society Press, Los Altos

  • Kolfschoten G, Briggs RO, de Vreede GJ, Jacobs PHM, Appelman JH (2006) A conceptual foundation of the thinkLet concept for collaboration engineering. J Hum Comput Stud 64:611–621

    Article  Google Scholar 

  • Kolfschoten G, de Vreede G-J (2009) A design approach for collaboration processes: a multi-method design science study in collaboration engineering. J Manag Inf Syst 26(1):225–256

    Google Scholar 

  • Kotonya G, Sommerville I (1998) Requirements engineering: processes and techniques. Wiley, Great Britain

    Google Scholar 

  • Macaulay L (1993) Requirements for requirements engineering techniques. In: IEEE international symposium on requirements engineering, San Diego, CA, USA, January 4–6, 1993

  • Machado RG, Borges MRS, Gomes JO (2008) Supporting the system requirements elicitation through collaborative observations. In: Proceedings of the 14th collaboration researchers’ international workshop on groupware, Omaha, Nebraska, September 14–18, 2008

  • Maiden N, Gizikis A, Robertson S (2004) Providing creativity: imagine what your requirement could be like. IEEE Softw 21(5):68–75

    Article  Google Scholar 

  • Monford V, Goudeau S (2004) Web Services et Interopérabilité des SI. Dunod, Paris

    Google Scholar 

  • Nunamaker JFJ, Briggs RO, Mittleman DD, Vogel D, Balthazard PA (1997) Lessons from a dozen years of group support systems research: a discussion of lab and field findings. J Manag Inf Syst 13:163–207

    Google Scholar 

  • Nuseibeh B, Easterbrook S (2000) Requirements engineering: a roadmap. In: Proceedings of international conference on software engineering (ICSE-2000). ACM Press, Limerick, Ireland, 4–11 Jun 2000

  • Osborn A (1948) http://fr.wikipedia.org/wiki/Alex_Osborn-cite_ref-0 Your Creative Power, 1948, p 265; Applied Imagination, 1957, 1963, p 151

  • Potin Y (2007) Travail Collaboratif: Quand la distance permet le rapprochement. http://www.creg.ac-versailles.fr/article.php3?id_article=206. Accessed in Apr 2009

  • PTC (2007) Conception d’un système de collaboration. Parametric Technology Corporation. http://www.ptc.com. Accessed on Jan 2007

  • Rebetez C (2007) Concepts de base. http://tecfa.unige.ch/staf/staf-i/rebetez/staf-11/periode4/. Accessed on Oct 2007

  • Rocques P, Vallée F (eds) (2004) UML 2 en action, De l’analyse des besoins à la conception J2EE. EYROLLES

  • Sahraoui AEK, Buede DM, Sage AP (2008) Systems engineering reasearch. J Syst Sci Syst Eng 17(3): 319–333

    Article  Google Scholar 

  • Santanen EL, Vreede GJd, Briggs RO (2004) Causal relationships in creative problem solving: comparing facilitation interventions for ideation. J Manag Inf Syst 20:167–197

    Google Scholar 

  • Sommerville I, Sawyer P (eds) (1997) Requirement engineering: a good practice guide. Wiley, Great Britain

    Google Scholar 

  • TrueReq (2004) http://www.truereq.com. Accessed on Sept 2008

  • Vreede GJD, Briggs RO (2005) Collaboration engineering: designing repeatable processes for high-value collaborative tasks. In: Proceedings of Hawaii international conference on system science. IEEE Computer Society Press, Los Alamitos

  • Wiegers KE (2000) Process Impact. http://www.processimpact.com. Accessed on Apr 2008

  • Zara O (2005) Management de l’intelligence collective. M2 Editions

Download references

Author information

Authors and Affiliations

  1. LAAS-CNRS, University of Toulouse, 7, avenue du Colonel Roche, 31400, Toulouse, France

    Jacqueline Konaté

  2. CNRS, LAAS, 7 avenue du Colonel Roche, 31400, Toulouse, France

    Abd El Kader Sahraoui

  3. Université de Toulouse, UTM, LAAS, 31100, Toulouse, France

    Abd El Kader Sahraoui

  4. Faculty of Technology Policy and Management, Technology University of Delft, Jaffalaan 5, 2628 BX, Delft, The Netherlands

    Gwendolyn L. Kolfschoten

Authors
  1. Jacqueline Konaté
    View author publications

    You can also search for this author in PubMed Google Scholar

  2. Abd El Kader Sahraoui
    View author publications

    You can also search for this author in PubMed Google Scholar

  3. Gwendolyn L. Kolfschoten
    View author publications

    You can also search for this author in PubMed Google Scholar

Corresponding author

Correspondence to Jacqueline Konaté.

Appendix

Appendix

Storytelling: generate

Choose this thinkLet

  • to create collective story from experiences of all participants

  • to make link between participant problems and real-world situations

  • when people need to understand the context of the contribution

  • to gather rich and detailed contributions based on experience

Overview

In this thinkLet the group members tell stories of their experiences.

Inputs

Clear understanding of the purpose of storytelling

Outputs

A common and collective story created from experiences of all participants. This thinkLet is based on GSS allowing people to speak and write their stories. Each team member shares a story with his/her experience to elicit one perspective of a common problem. Each member can elaborate and reflect on stories from other participants. Members can also ask questions for clarification. The stories are merged to create a collective story.

How to Use Storytelling

Setup

  1. 1.

    Create story pages in GSS

    1. a.

      each participant sees a page and can add part of the story

    2. b.

      one or two extra pages, depending on the group size

  2. 2.

    Present the problem that is the focus points of the story

Steps

  1. 1.

    Says this:

    1. a.

      Please click on the “start button”. The system will bring you to empty electronic page. Each of you has a different electronic page. You will each start on a different electronic page.

    2. b.

      You may each type a story on the problem presented, up to 50 words long. Then you must click the submit button to send the page back to the group.

    3. c.

      The system will randomly bring you a different page. That page will have somebody else’s story on it.

    4. d.

      When you see a page with somebody else’s story on it, you may respond in following ways:

      1. i.

        You can enrich the story with complementary points

      2. ii.

        You can reflect or react on the story, give comments

      3. iii.

        You may argue against and add your own experience if you have counter example.

    5. e.

      You may type new episode of a story on new page. Then you must send that page back to the group. The system will bring you a new page.

    6. f.

      We will continue swapping pages and submitting comments, suggestions and elaborations about stories until we have a complete picture of the problem.

    7. g.

      Any questions?

Storytelling Insight

In this technique a highly elaborative way of generation is used. People share experiences about a problem or issue. The results will be detailed, but fuzzy stories, which will offer contextual information. Extensive convergence is required to integrate stories and to elicit key aspects or characteristics of the problem. Story telling can also be used in a more visionary sense, to envision future scenario’s and use cases of systems that are to be developed. A challenge is to ensure that the stories are sufficiently anonymous, and that naming and blaming is avoided. Another challenge is to ensure that stories are complete and open reports of experiences, and that vagueness such as ‘and we all know what that meant’ or ‘the rest is history’ is avoided.

Dialogue: generate

Choose this thinkLet if

  • Participants need to envision solutions from different perspectives

  • A shared understanding of the needs and challenges of each perspective is required

Overview

Participants will engage in a dialogue in which they will assume the role of a stakeholder in the issue or topic. In this way they will look at the challenge from a different perspective.

Input

A clearly defined topic or issue to generate reflections or contributions on

A set of stakeholder roles

Output

A dialogue in which issues and reflection are exchanged

How to use dialogue

Setup

  1. 1.

    Assign each participant a stakeholders role, ensure that they understand their role, and that they stay in their role for the duration of the activity

  2. 2.

    Assign each participant to a discussion page with the title of the role he/she represents

Steps

  1. 1.

    Ask each participant to write a brief statement from the perspective of his/her role about the issue

  2. 2.

    Ask participants to stay in their role and respond to one or more statements opening a dialogue. You can ask questions for clarification of the statement, reflect on it, or make a counter proposal.

  3. 3.

    After each contribution, return to your own page and respond, in your role to the remarks, or issues raised, keep your dialogue updated alternating between contributions to others and responding to issues raised on your own page.

Dialogue insights

A dialogue is a natural way to engage in discussion about issues and suggestions or reflections. In this way for instance a requirements negotiation can be done. As each participant is asked to discuss the requirements from a different perspective than his own, they will gain mutual understanding of the challenges and issues of each of the perspectives.

Some definitions

System Engineering (SE) is methodological, cooperative and interdisciplinary approach covering overall suitable activities to design, develop, evolve and verify a system by giving satisfying solution to all stakeholders needs during the system life cycle (IEEE, 1999).

Stakeholder is an enterprise, an organization, or individual having an interest or a stake in the outcome of the engineering of a system (EIA-632 1999).

Client is an enterprise, organization, or individual that: (1) commissions the engineering of a system; (2) is a prospective purchaser of the parts of a system, or portions thereof; or (3) is an acquirer of a system (EIA-632 1999).

End user is an enterprise, organization, or individual that operates directly on the system (EIA-632 1999). He/she can be the client.

Acquirer is an enterprise, organization, or individual that obtains a product (good or service) from a supplier (EIA-632 1999).

Rights and permissions

Reprints and permissions

About this article

Cite this article

Konaté, J., Sahraoui, A.E.K. & Kolfschoten, G.L. Collaborative Requirements Elicitation: A Process-Centred Approach. Group Decis Negot 23, 847–877 (2014). https://doi.org/10.1007/s10726-013-9350-x

Download citation

  • Published:

  • Issue Date:

  • DOI: https://doi.org/10.1007/s10726-013-9350-x

Keywords

Search

Navigation