• Publication
  • 2005
  • Issue No. 7 - July
  • Abstract - An Approach to Developing Domain Requirements as a Core Asset Based on Commonality and Variability Analysis in a Product Line
 This Article 
   
 Share 
   
 Bibliographic References 
   
 Add to: 
 
Digg
Furl
Spurl
Blink
Simpy
Google
Del.icio.us
Y!MyWeb
 
 Search 
   
An Approach to Developing Domain Requirements as a Core Asset Based on Commonality and Variability Analysis in a Product Line
July 2005 (vol. 31 no. 7)
pp. 551-569
ASCII Text
x 
 
Mikyeong Moon, Keunhyuk Yeom, Heung Seok Chae, "An Approach to Developing Domain Requirements as a Core Asset Based on Commonality and Variability Analysis in a Product Line," IEEE Transactions on Software Engineering, vol. 31, no. 7, pp. 551-569, July, 2005.
 
 
BibTex
x
 
@article{ 10.1109/TSE.2005.76,
author = {Mikyeong Moon and Keunhyuk Yeom and Heung Seok Chae},
title = {An Approach to Developing Domain Requirements as a Core Asset Based on Commonality and Variability Analysis in a Product Line},
journal ={IEEE Transactions on Software Engineering},
volume = {31},
number = {7},
issn = {0098-5589},
year = {2005},
pages = {551-569},
doi = {http://doi.ieeecomputersociety.org/10.1109/TSE.2005.76},
publisher = {IEEE Computer Society},
address = {Los Alamitos, CA, USA},
}
 
 
RefWorks Procite/RefMan/Endnote
x 
 
TY - JOUR
JO - IEEE Transactions on Software Engineering
TI - An Approach to Developing Domain Requirements as a Core Asset Based on Commonality and Variability Analysis in a Product Line
IS - 7
SN - 0098-5589
SP551
EP569
EPD - 551-569
A1 - Mikyeong Moon,
A1 - Keunhyuk Yeom,
A1 - Heung Seok Chae,
PY - 2005
KW - Index Terms- Requirement engineering
KW - product-line
KW - core asset
KW - commonality
KW - variability
KW - domain analysis
KW - reuse.
VL - 31
JA - IEEE Transactions on Software Engineering
ER -
 
The methodologies of product line engineering emphasize proactive reuse to construct high-quality products more quickly that are less costly. Requirements engineering for software product families differs significantly from requirements engineering for single software products. The requirements for a product line are written for the group of systems as a whole, with requirements for individual systems specified by a delta or an increment to the generic set. Therefore, it is necessary to identify and explicitly denote the regions of commonality and points of variation at the requirements level. In this paper, we suggest a method of producing requirements that will be a core asset in the product line. We describe a process for developing domain requirements where commonality and variability in a domain are explicitly considered. A CASE environment, named DREAM, for managing commonality and variability analysis of domain requirements is also described. We also describe a case study for an e-Travel System domain where we found that our approach to developing domain requirements based on commonality and variability analysis helped to produce domain requirements as a core asset for product lines.

[1] D. Muthig and C. Atkinson, “Model-Driven Product Line Architecture,” Proc. Second Software Product Line Conf., Aug. 2002.
[2] S.R. Faulk, “Product-Line Requirements Specification (PRS): An Approach And Case Study,” Proc. Fifth IEEE Int'l Symp. Requirements Eng., pp. 48-55 2001.
[3] P. Clements and L. Northrop, Software Product Lines: Practices and Patterns. Addison Wesley, 2001.
[4] M. Moon and K. Yeom, “Domain Design Method to Support Effective Reuse in Component-Based Software Development,” Proc. First ACIS Int'l Conf. Software Eng. Research and Applications, pp. 149-154, 2003.
[5] D. Creps, C. Klingler, L. Levine, and D. Allemang, “Organization Domain Modeling (ODM) Guidebook Version 2.0,” Software Technology for Adaptable, Reliable Systems (STARS), 1996.
[6] M. Berard, Essays in Object-Oriented Software Engineering. Prentice-Hall, 1992.
[7] A. Wierzbicka, Semantic Primitives. Frankfurt: Athenäum Verlag, 1972
[8] G. Kotonya and I. Sommerville, “Requirements Engineering with Viewpoints,” Software Eng. J., vol. 11, no. 1, pp. 5-18, Jan. 1996.
[9] D.M. Weiss and C.T.R. Lai, Software Product-Line Engineering: A Family-Based Software Development Process. Addison-Wesley, 1999.
[10] I. Jacobson, M. Griss, and P. Jonsson, Software Reuse— Architecture, Process, and Organization for Business Success. Addison-Wesley, 1997.
[11] G. Halmans and K. Pohl, “Communicating the Variability of Software-Product Family to Customers,” Proc. Software and System Modeling, vol. 2, pp. 15-36, Feb. 2003.
[12] B.C. Kang and Y.H. Kim, “Domain Requirement Definition,” Technical Report EA20030536_0201_0101 Version 1.0, Electronics and Telecomm. Research Inst. (ETRI) and Daewoo Information Systems Corporation, 2003.
[13] S.I. Han, “PR-Context-Matrix,” Technical Report EA20030536_ 0201_0104 Version 1.0, Electronics and Telecomm. Research Inst. (ETRI) and Daewoo Information Systems Corporation, 2003.
[14] B.C. Kang and J.W. Kim, “Domain Usecase Model,” Technical Report EA20030536_0202_0202 Version 1.0, Electronics and Telecomm. Research Inst. (ETRI) and Daewoo Information Systems Corporation, 2003.
[15] Y.H. Kim, “PR-Usecase Matrix,” Technical Report EA20030536_ 0201_0204 Version 1.0, Electronics and Telecomm. Research Inst. (ETRI) and Daewoo Information Systems Corporation, 2003.
[16] B.C. Kang, “Project Plan,” Technical Report EA20030536_ 0202_0102 Version 1.1, Daewoo Information Systems Corporation, 2003.
[17] S.I. Han and J.W. Kim, “Usecase Model,” Technical Report, EA20030536_0202_0302, Version 1.1, Daewoo Information Systems Corporation, 2003.
[18] IBM RequisitePro, http://www.ibm.com/software/awdtools reqpro /, 2004.
[19] Telelogic DOORS, http:/www.telelogic.com/, 2004.
[20] OMG, XMI Metadata Interchange (XMI) 2.0, http://www.omg. org/docs/formal03-05-02.pdf , 2003.
[21] I. Sommerville and G. Kotonya, Requirements Engineering: Processes and Techniques. John Wiley and Sons, Ltd., 1998.
[22] B. Nuseibeh and S. Easterbrook, “Requirements Engineering: A Roadmap,” The Future of Software Eng., pp. 37-46, 2000.
[23] J. Kuusela and J. Savolainen, “Requirements Engineering for Product Families,” Proc. 22nd Int'l Conf. Software Eng. (ICSE '00), pp. 60-68, June 2000.
[24] J.M. Thompson and M.P. E. Heimdahl, “Structuring Product Family Requirements for N-Dimensional and Hierarchical Product Lines,” Requirements Eng., pp. 42-54, Apr. 2003.
[25] G. Chastek, P. Donohoe, K. Kang, and S. Thiel, “Product Line Analysis: A Practical Introduction,” Technical Report CMU/SEI-2001-TR-001, Software Eng. Inst., Carnegie Mellon Univ., 2001.
[26] K. Kang, S. Cohen, J. Hess, W. Novak, and S. Peterson, “Feature-Oriented Domain Analysis (FODA) Feasibility Study,” Technical Report CMU/SEI-90-TR-21, Software Eng. Inst., Carnegie Mellon Univ., Nov. 1990.
[27] K.C. Kang, S. Kim, J. Lee, and K. Kim, “FORM: A Feature-Oriented Reuse Method with Domain Specific Reference Architectures,” Annals of Software Eng., vol. 5, pp. 143-168, 1998.
[28] M. Griss, J. Favaro, and M. d'Alessandro, “Integrating Feature Modeling with the RSEB,” Proc. Fifth Int'l Conf. Software Reuse, pp. 76-85, 1998.
[29] J. Coplien, D. Hoffman, and D. Weiss, “Commonality and Variability in Software Engineering,” IEEE Software, vol. 15, no. 6, pp. 37-45, 1998.

Index Terms:
Index Terms- Requirement engineering, product-line, core asset, commonality, variability, domain analysis, reuse.
Citation:
Mikyeong Moon, Keunhyuk Yeom, Heung Seok Chae, "An Approach to Developing Domain Requirements as a Core Asset Based on Commonality and Variability Analysis in a Product Line," IEEE Transactions on Software Engineering, vol. 31, no. 7, pp. 551-569, July 2005, doi:10.1109/TSE.2005.76
Usage of this product signifies your acceptance of the Terms of Use.