Exploring software practitioners perceptions and experience in requirements reuse : a survey in Malaysia

In Software Product Lines (SPL) development, reuse process is planned ahead of time, while in traditional software development reuse can occur opportunistically: unplanned or in ad hoc manner. Although many research efforts in SPL focus on issues related to architecture, designs and codes reuse, res...

Full description

Bibliographic Details
Main Authors: Bakar, Noor Hasrina, Kasirun, Zarinah M.
Format: Article
Language:English
English
Published: University Teknologi Malaysia (UTM) 2014
Subjects:
Online Access:http://irep.iium.edu.my/37615/
http://irep.iium.edu.my/37615/
http://irep.iium.edu.my/37615/1/26
http://irep.iium.edu.my/37615/2/26-143-1-PB-2.pdf
Description
Summary:In Software Product Lines (SPL) development, reuse process is planned ahead of time, while in traditional software development reuse can occur opportunistically: unplanned or in ad hoc manner. Although many research efforts in SPL focus on issues related to architecture, designs and codes reuse, research on requirements reuse has received slightly less attention from researchers and practitioners. Requirements Reuse (RR) in SPL is the process of systematically reusing previously defined and validated requirements for an earlier software product and applying them to a new and slightly different product within a similar domain. This paper presents a survey pertaining to RR practice that was conducted in Malaysia with two objectives: a) to identify the factors influencing software practitioners in RR, and b) to assess the factors hindering software practitioners from reusing requirements in software development. The survey results have confirmed seven factors that can influence RR practice in Malaysia. The survey results have also revealed three main impediments to RR practice in Malaysia: the unavailability of RR tools or framework to select requirements for reuse, the conditions of existing requirements to be reused (incomplete, poorly structured or not kept updated), and the lack of awareness and RR education among software practitioners pertaining to the systematic RR