Collaborative Resolution of Requirements Mismatches When Adopting Open Source Components
(2012) 18th International Working Conference, REFSQ 2012 7195. p.77-93- Abstract
- Abstract in Undetermined
[Context and motivation] There is considerable flexibility in requirements specifications (both functional and non-functional), as well as in the features of available OSS components. This allows a collaborative matching and negotiation process between stakeholders such as: customers, software contractors and OSS communities, regarding desired requirements versus available and thus reusable OSS components. [Problem] However, inconclusive research exists on such cooperative processes. Not much empirical data exists supporting the conduction of such research based on observation of industrial OSS adoption projects. This paper investigates how functional and non-functional requirement mismatches are handled in... (More) - Abstract in Undetermined
[Context and motivation] There is considerable flexibility in requirements specifications (both functional and non-functional), as well as in the features of available OSS components. This allows a collaborative matching and negotiation process between stakeholders such as: customers, software contractors and OSS communities, regarding desired requirements versus available and thus reusable OSS components. [Problem] However, inconclusive research exists on such cooperative processes. Not much empirical data exists supporting the conduction of such research based on observation of industrial OSS adoption projects. This paper investigates how functional and non-functional requirement mismatches are handled in practice. [Results] We found two common approaches to handle functional mismatches. The main resolution approach is to get the components changed by the development team, OSS community or commercial vendor. The other resolution approach is to influence requirements, often by postponing requirements. Overall, non-functional requirements are satisfactorily achieved by using OSS components. Last but not least, we found that the customer involvement could enhance functional mismatch resolution while OSS community involvement could improve non-functional mismatch resolution. [Contribution] Our data suggests that the selecting components should be done iteratively with close collaboration with stakeholders. Improvement in requirement mismatch resolution to requirements could be achieved by careful consideration of mismatches size, requirements flexibility and components quality. (Less)
Please use this url to cite or link to this publication:
https://lup.lub.lu.se/record/2438857
- author
- Nguyen, Anh Duc ; Cruzes, Daniela S. ; Conradi, Reidar ; Höst, Martin LU ; Franch, Xavier and Ayala, Claudia P.
- organization
- publishing date
- 2012
- type
- Chapter in Book/Report/Conference proceeding
- publication status
- published
- subject
- host publication
- Requirements Engineering: Foundation for Software Quality/Lecture Notes in Computer Science
- volume
- 7195
- pages
- 77 - 93
- conference name
- 18th International Working Conference, REFSQ 2012
- conference location
- Essen, Germany
- conference dates
- 2012-03-19 - 2012-03-22
- external identifiers
-
- scopus:84858304319
- ISSN
- 0302-9743
- 1611-3349
- DOI
- 10.1007/978-3-642-28714-5_7
- project
- Embedded Applications Software Engineering
- language
- English
- LU publication?
- yes
- id
- 9b582e85-81b0-4ede-98f7-252df52056e4 (old id 2438857)
- date added to LUP
- 2016-04-04 08:06:59
- date last changed
- 2024-01-12 03:43:01
@inproceedings{9b582e85-81b0-4ede-98f7-252df52056e4,
abstract = {{Abstract in Undetermined<br/>[Context and motivation] There is considerable flexibility in requirements specifications (both functional and non-functional), as well as in the features of available OSS components. This allows a collaborative matching and negotiation process between stakeholders such as: customers, software contractors and OSS communities, regarding desired requirements versus available and thus reusable OSS components. [Problem] However, inconclusive research exists on such cooperative processes. Not much empirical data exists supporting the conduction of such research based on observation of industrial OSS adoption projects. This paper investigates how functional and non-functional requirement mismatches are handled in practice. [Results] We found two common approaches to handle functional mismatches. The main resolution approach is to get the components changed by the development team, OSS community or commercial vendor. The other resolution approach is to influence requirements, often by postponing requirements. Overall, non-functional requirements are satisfactorily achieved by using OSS components. Last but not least, we found that the customer involvement could enhance functional mismatch resolution while OSS community involvement could improve non-functional mismatch resolution. [Contribution] Our data suggests that the selecting components should be done iteratively with close collaboration with stakeholders. Improvement in requirement mismatch resolution to requirements could be achieved by careful consideration of mismatches size, requirements flexibility and components quality.}},
author = {{Nguyen, Anh Duc and Cruzes, Daniela S. and Conradi, Reidar and Höst, Martin and Franch, Xavier and Ayala, Claudia P.}},
booktitle = {{Requirements Engineering: Foundation for Software Quality/Lecture Notes in Computer Science}},
issn = {{0302-9743}},
language = {{eng}},
pages = {{77--93}},
title = {{Collaborative Resolution of Requirements Mismatches When Adopting Open Source Components}},
url = {{http://dx.doi.org/10.1007/978-3-642-28714-5_7}},
doi = {{10.1007/978-3-642-28714-5_7}},
volume = {{7195}},
year = {{2012}},
}