System requirements-OSS components: matching and mismatch resolution practices – an empirical study

Abstract

Developing systems by integrating Open Source Software (OSS) is increasingly gaining importance in the software industry. Although the literature claims that this approach highly impacts Requirements Engineering (RE) practices, there is a lack of empirical evidence to demonstrate this statement. To explore and understand problems and challenges of current system requirement–OSS component matching and mismatches resolution practices in software development projects that integrate one or more OSS components into their software products. Semi-structured in-depth interviews with 25 respondents that have performed RE activities in software development projects that integrate OSS components in 25 different software development companies in Spain, Norway, Sweden, and Denmark. The study uncovers 15 observations regarding system requirements-OSS components matching and mismatch resolution practices used in industrial projects that integrate OSS components. The assessed projects focused mainly on pre-release stages of software applications that integrate OSS components in an opportunistic way. The results also provide details of a set of previously unexplored scenarios when solving system requirement–OSS component mismatches; and clarify some challenges and related problems. For instance, although licensing issues and the potential changes in OSS components by their corresponding communities and/or changes in system requirements have been greatly discussed in the RE literature as problems for OSS component integration, they did not appear to be relevant in our assessed projects. Instead, practitioners highlighted the problem of getting suitable OSS component documentation/information.

Appendices

Appendix 1

Semi-structured Interview-Guide.

Part 1.A: Background Questions on Company and Person (Completed by the respondent before the meeting)

• 1.1. Current date (dd.mm.yyyy):

• 1.2. Your company/local business unit:

• 1.3. Company URL (only used internally):

• 1.4. Number of company employees, part-time and full-time:

Personal information:

• 1.5. First name and last name:

• 1.6. Email address (only used internally):

• 1.7. Phone number (only used internally):

• 1.8. Age (only used internally):

• 1.9. Degree of highest completed education, and in what area:

• 1.10. Current job position

• 1.11. Describe your experience with software development and with OSS (tasks, products, duration etc.)

Part 1.B: Background Questions on Project and System (Completed by the respondent before the meeting).

The study object for this survey is a software development project, with at least one release of the corresponding product, and with reuse of one or more OSS components. If you have experience with several such projects, please select the one that you are most familiar with and motivated to discuss.

• 1.12. What was the mean annual staff-size of the project (both full- and part-time employees)?

• 1.13. What part of the staff had previous experience with OSS-based development?

• 1.14. Did you have previous experience with OSS-based development before joining the project?

• 1.15. What was the total effort of the project?

• 1.16. What was (roughly) the starting time of the project?

• 1.17. Which part of the system do the OSS Components occupy?

• 1.18. What was the time of the first complete delivery of the project?

• 1.19. What were the major application domain(s) of the system?

• 1.20. Please provide a brief description of the chosen project and its main functionalities and architectural environment.

• 1.21. What was the overall, software development process/environment of the project?

• 1.22. Where did the requirements come from? [Interviewer should provide the following alternatives: there is an external client who paid for the project and “supervise” the requirements / there is no a specific client that paid for the project but it is the own company who “supervise” the requirements]

• 1.23. How were the functional requirements described with regard to level of detail? [Interviewer should provide the following alternatives: very sketchy/ coarsely-grained/ medium/ detailed/ very fine-grained/]

• 1.24. Which notation was used to describe the requirements?

Part 2. Details of requirement-component matchin process

• 2.1. In which lifecycle phases were these OSS Components searched, evaluated and decided?

• 2.2. How was the search process and the evaluation for these OSS Components done?

[Interviewer should provide the following alternatives to promote discussion]

• a) No real search/evaluation needed, since I have successfully used this component before.

• b) Consulted with my job colleagues/engineers, or with similar people elsewhere.

• c) Consulted with the customer about company policies or preferences.

• d) Read/heard about it in”peer-review” literature: scientific conferences, journals, books etc.

• e) Read/heard about it in”grey” literature: reports, ads, bulletin boards etc.

• f) Heard about it in connection with trade fairs, seminars, workshops, courses etc.

• g) Searched for it in general portals (http://Sourceforge.net) or in domain-specific ones.

• h) Searched for it using general or specialized search engines: google, google code etc.

• i) Used a formal method named ________to search for and assess candidate components.

• j) Used a systematic/documented method named:___________________.

• k) Some other way (please explain):

• 2.3. What was decided first – application platform and architecture vs. major components

Part 3: Details of processes to solve potential requirement-component mismatches

• 3.1. What did you do when the functional requirement-component mismatches ocurred? [Interviewer should inquiry about the following: OSS component is affected/ System requirement is affected / Any other approach and let the respondent provide details and examples of the most usual approach followed in each of these cases]

• 3.2. Which and how the major non-functional requirements were achieved by using OSS components?

Part 4: Problems Experienced

• 4.1. Did changes in OSS Components by the community or changes in your Requirements create any problems?

• 4.2. Did you experience problems with licensing issues?

• 4.3. Did you experience other problems to understand and integrate major OSS components?

Part 5: General summary and reflections

• 5.1. Which factors influenced your prioritization of Requirements vs. OSS Components?

• 5.2. What is the influence of integrating OSS components in your software development practices?

• 5.3. Other comments?

Appendix 2

English Report Transcript Guidelines.

Here are the format requirements for the transcript of the audio interviews. Please read these very carefully. Although they are detailed, they represent the information required to make your transcript fully useable for other researchers. This information is vital for the long-term effectiveness of our survey. Begin work on the transcript early. It is an essential and time-consuming task that must be completed as soon as possible after each interview.

• 1) The transcripts will be typed directly on each interview form in the language that it was conducted in the interview. In the analysis phase, we will determine how to conduct the analysis with the different languages.

• 2) Include the following information on the first page of the word document containing the interview:

Process:	Record details of the process followed in the interview (e.g. we completed first the Part 1 and 2 and we then interviewed him by phone).
Interview Time:	X minutes
Interview Date:	dd/mm/year
Interviewee:	XXXX
Interviewers:	XXX and XXXX
Media:	Phone/Face to face/Skype
Language:	English
Comments:	Please provide as much detail as possible

• 3) Use the blue color to highlight the transcripts. Please see the example transcription file in the companion material.

• 4) Try to put the transcription related to each question in the appropriate place, if possible, so that it will be easier to perform the analysis. If there are conversations that do not follow the question order, just leave the block of transcription, in the part where you are doing the interview. We will try to link to the question later on the analysis.

• 5) The speakers should be identified. On the first page, respondents and interviewers should be identified in parentheses following their name. Indicate what abbreviations will be used to identify the various speakers on the transcript. For example, you can use initials for speakers present, e.g., “MD” for Marion Doe.

• 6) Indicate any non-verbal responses in parentheses such as (narrator weeping), (laughter), (narrator very agitated) and so forth. However, do not reproduce irrelevant sounds such as “Ahhh, let me see…” Do not, correct the interviewee’s grammar or syntax. Faithfully transcribe slang expressions, exclamations (“Gosh!”) and fragmentary sentences. Do not use quotation marks unless the speaker is quoting someone else or reading from a document.

• 7) The explanatory remarks you add for clarity should be in [square brackets], e.g., [inaudible in 00:19:15]. Then, we will know that there were some inaudible parts at that specific time in the audio.

• 8) Be sure to proofread your transcript from the tapes once it is completed to ensure accuracy.

• 9) If at all possible, give the respondent an opportunity to review the transcript and make corrections.