Advanced
A Model for Reusing Requirements Using Examples from Open Source Software
A Model for Reusing Requirements Using Examples from Open Source Software
Journal of information and communication convergence engineering. 2012. Sep, 10(3): 284-294
Copyright ©2012, The Korean Institute of Information and Commucation Engineering
This is an Open Access article distributed under the terms of the Creative Commons Attribution Non-Commercial License (http://creativecommons.org/li-censes/bync/ 3.0/) which permits unrestricted non-commercial use, distribution, and reproduction in any medium, provided the original work is properly cited.
  • Received : May 31, 2012
  • Accepted : June 25, 2012
  • Published : September 30, 2012
Download
PDF
e-PUB
PubReader
PPT
Export by style
Article
Author
Metrics
Cited by
TagCloud
About the Authors
Jong Bae Kim
kbj123@ssu.ac.kr

Abstract
The quality of requirements is one of the key factors in the success of a project. One of the studies on successful projects is the reuse of requirements. However, the rate of failed projects is about 70%, and these projects often fail because of improper requirements. The current techniques for software reuse may not perform requirement engineering appropriately or develop requirements having good characteristics. In order to improve this situation, we propose a model for reusing requirements. We expect that our model will contribute toward increasing project productivity using requirement reuse in existing projects, and reusing requirements that have good quality.
Keywords
I. INTRODUCTION
Requirement engineering is a sub-discipline of system and software engineering that is concerned with determining the goals, functions, and constraints of systems [1] . The importance of requirement engineering in ensuring the success of projects has already been shown by various studies. That is, the quality of requirements is one of the key factors in the success a project. In this context, many methods for developing and managing good requirements have been studied [2 - 6] , and one of them is the reuse of requirements [7 - 19] .
Reuse technologies have already been applied in many industries and have become common practice. In software engineering, the limitations of the current paradigm of software reuse saw needs about reuse, and they were evaluated and synthesized to generate a new paradigm. Therefore, we pose some questions about current reuse techniques. First, "does the success rate of software projects increase with software reuse?" According to some research [20] , the likelihood of the success of a given project is about 32 percent, and many projects are denoted as "challenged" or "failed". So, "why do so many projects fail?" According to some research [6] , frequently (in about 70% of cases) the major factors in challenged or failed projects are uncorrected requirements such as omitted, incomplete, inconsistent, and changing requirements. That is, current techniques for software reuse might not allow for performing requirement engineering appropriately or developing requirements having good characteristics.
This study assumes that the current software crisis comes rom not performing requirements engineering appropriately. Therefore, to solve this situation, we propose a model for reusing requirements. To achieve our goal, we set two objectives. First, we propose a concept for reusing requirements effectively and efficiently, which is called the “ domain element” concept. Second, we organize a procedure for reusing requirements. Our study does not cover specific techniques and tools for reuse.
We expect that our model could contribute toward increasing project productivity through requirement reuse in existing projects and reusing requirements that have good quality. It provides a foundation for increasing the success rate of projects.
The reminder of this paper is organized as follows. The related works are introduced at the next section. This includes analyzing existing works on reusing requirements and requirement engineering, and then we propose the concept of domain elements for reusing requirements in Section III. In Section IV, we explain the processes/activities for reuse by tailoring domain and requirement engineering. Section V represents case studies about our model. To validate the applicable feasibility of our model, we make a reuse repository by applying our model to 20 projects (project group A). To validate the effectiveness and efficiency of our model, we find requirements to be reused in other 20 projects (project group B) by using the repository. Then, to validate the improvement in reusability, we compare the requirements in project groups A and B. Finally, Section VI sums up our study, represents the limitations of our model based on a case study method, and proposes future work.
II. RELATED WORK
- A. The Work of Buhne and Pohl[21]
Buhne and Pohl [21] propose domain requirement engineering, which is a process of developing and describing requirements for a domain. It is a process related to domain analysis in domain engineering. The term 'domain requirement' is a requirement for a specific domain, and to
PPT Slide
Lager Image
Meta-model for domain requirements from Moon et al. [12].
develop them, he proposes three steps: commonality analysis of requirements, variability analysis of requirements, and modeling common/variable requirements. This supports communication among the product manager, domain designer and application requirement engineer, and provides consistency regarding the variability of the product line. This study introduces an overview of domain analysis through steps, related techniques, modeling methods, and examples, and emphasizes commonality/variability analysis in reuse requirements. However, this might not provide a concept of reuse requirements.
- B. The Work of Moon et al.[12]
Moon et al. [12] proposes an approach for developing domain requirements as the core asset based on commonality and variability analysis in a product line. This study suggests a meta-model of domain requirements as shown in Fig. 1 , and proposes a process for developing domain requirement that consists of 4 steps. Step 1 is "scoping domain requirements". This has a goal of determining the boundaries of domain requirements and basic concepts and terms using specific domains. Step 2 is "identifying domain requirements". This has a goal of identifying domain requirements using a requirement-context matrix. Step 3 is "refining domain requirements". This has a goal of specifying the constraints between the domain requirements and writing the requirement specification. The final step is "constructing a domain-use case model". This has a goal to define requirement-use case matrix using the specified requirements. Moon et al. [12] contributes the proposal of a meta-model for commonality and variability of domain requirements and a process for developing domain requirements as core assets. However, the study of Moon et al. [12] might not provide specific techniques for identifying variation points and variants using a matrix of requirementcontext and requirement-use case.
- C. The Work of Sutcliffe and Maiden[22]
Sutcliffe and Maiden [22] proposed a set of reusable abstraction concepts, modeling methods, and related tools for constructing a requirements reuse library, and this study suggested reusing domain requirements and knowledge by classifying domains and considering the relationship among them. This work proposes a metamodel of knowledge type for domain modeling, and proposes a framework for a reuse library and domain matching tool. However, the study of Sutcliffe and Maiden [22] might not separate between domain knowledge and domain requirements, and might not consider the relationship between domain and application requirements.
III. PROPOSING DOMAIN ELEMENTS FOR REUSING REQUIREMENTS
- A. The Meta-Model of Domain Requirements
In domain engineering, domain analysis is an activity for eliciting reusable domain requirements in a domain [10] . The result of domain analysis, which is a set of domain requirements, is one of the input-artifacts for domain design and application engineering to adapt requirements for specific applications. The process for reusing requirements comprises the activity of making reusable domain requirements and the activity of adapting and translating them to application requirements. To elicit domain requirements, a meta-model of such requirements is proposed by Moon et al. [12] as shown in Fig. 1 .
As in the meta-model, a domain requirement has some points of variation that are realized by variants. As Fig. 2 , the requirements for specific applications will be made by adapting domain requirements to specific applications using variants (PRElement in Fig. 1 ).
PPT Slide
Lager Image
The relationship between domain requirements and application requirements.
- B. Domain and Domain Requirement
The term "domain" of Trace's definition is a set of problems and solutions that cover similar applications [20] . Therefore, we consider the term "domain requirement" to be a connection between a problem and solution in a domain because the requirement is elicited as a middle artifact to develop solutions that can cover the problems. Fig. 3 shows the relationship among domain, problem, requirement, and solution.
PPT Slide
Lager Image
The relationship among domain, domain requirement, and solution.
Term Definition 1 : Domain
Domain : This is a set of problems, requirements, and solutions
  • ⋅ Domain = (P, R, S), where
  • P = a set of problems
  • R = a set of requirements
  • S = a set of solutions
Considering the meta-model of Fig. 1 , specific applications included in a domain might have application requirements adapted from domain requirements and application solutions modified from the domain solution.
The definition of the term "domain" can be visualized using the set of problems to be covered. Because the requirements of the domain/application are related to the domain problems, the relationship between problems and requirements could be modeled using certain techniques.
- C. Reorganizing Domain and Proposing Domain Elements
In this section, we consider one of most important issues, which is "how can domain scope be decided?" That is, we might decide whether a specific problem or requirement is included within the domain scope. To address this issue, we consider reorganizing problems and requirements to reuse them effectively and efficiently.
A domain includes problems and solutions to be covered by similar applications. To reorganize the domain, problem, and solution, we will discuss two views of a domain: vertical and horizontal [17] .
PPT Slide
Lager Image
Vertical vs. horizontal domains [18].
The vertical view is a business area that can classify domains such as military, medical, management, ordering, etc. The horizontal view is a functionality area such as a database, container library, workflow system, GUI, etc. Fig. 4 represents the vertical and horizontal views [18] . Table 1 represents the domain problems, requirements, and solutions considering the two views of the domain.
The vertical domain is the (business) area including applications; the horizontal domain is the (component) area included within applications. Therefore, each cell of Table 1 could be composed of domain problems, requirements, and
PPT Slide
Lager Image
Proposing processes for developing and reusing domain elements.
a solution. Considering the two views, the information included within each cell might have commonality and variability. Based on analyzing their commonality and variability, we could reorganize domain information, and we define the term "domain element" as a reusable abstraction having a set of domain problems, requirements, and solutions. Fig. 5 shows the meta-model of "domain elements" based on Figs. 1 and 2 .
The relationship among problems, requirements, and solutions considering vertical and horizontal views (example)
PPT Slide
Lager Image
The relationship among problems, requirements, and solutions considering vertical and horizontal views (example)
IV. OUR PROPOSED PROCESS FOR DEVELOPING AND REUSING DOMAIN ELEMENTS
In this section, we consider the iterative processes of domain elements that comprise two areas. One area is a process developing domain elements to ensure reusability, and another area is a process adapting and reusing domain elements to elicit domain/application requirements. We obtained the concept of the two areas from domain and application engineering in PLE (Product Line Engineering) and CD (Component Development) and CBSD (Component Based Software Development) in CBD (Component Based Development). According to this concept, the two areas are separated to find something reusable (such as core asset or component) and to reuse them. We propose our processes for the domain element as shown in Fig. 6 .
PPT Slide
Lager Image
Proposing a meta-model of "domain element".
- A. The Meta-Model of Domain Requirements
The goal of this process is to define domain elements that might include reusable requirements. That is, this is a prestage for reusing requirements, and these results are domain elements to support reusing requirements. This process is composed of 4 activities as follows.
- 1) Activity 1 - Identify Domain Problems, Requirements, and Solutions
The goal of this activity is to identify the basic information for developing the domain element. The basic information is a set of domain/application problems, requirements, and solutions as shown in Fig. 5 . This information is elicited based on the problems and solutions of given applications. They are also elicited based on current problems in the real world.
Term Definition 2: Domain Information
Domain Information (DI): A set of domain problems, requirements, and solutions from given applications. This is used to develop domain elements as input artifacts.
  • ⋅ DI ⊂ Domain
  • ⋅ DI = (PDI, RDI, SDI), where
  • PDI are problems solved by some applications;
  • RDI are some requirements related to
  • PDI; SDI are some solutions to meet RDI.
- 2) Activity 2 - Analyzing Relationships and Classifying Domains Considering Vertical and Horizontal Views
The goal of this activity is to prepare rationales for defining domain elements. The criteria for classification are vertical and horizontal views as shown in Fig. 4 . One of the tasks in this activity is to establish a relationship among the elicited problems, requirements, and solutions in a domain. If the domain element of the same views already exists, we might add or refine domain information to the existing domain element.
- 3) Activity 3 - Defining Domain Elements
The goal of this activity is to define domain elements based on the results of the previous activity. After the domain problems, requirements, and solutions are classified, we are able to define domain elements. The commonality and variability of domain problems, requirements, and solutions are then analyzed to reuse them effectively and efficiently in applications. The domain element is composed of a specific problem (and related sub-problems), problem-related requirements, and solutions to meet these requirements, and the relationship among them. To reuse domain elements as basis unit in the reuse process, they should be defined independently from others. It is important that a domain element has independent characteristics because it could be reused for various domains. To reuse them, the commonality and variability of domain elements should be analyzed using several techniques [7 - 9 , 22 - 24] .
Term Definition 3: Domain Element
Domain Element (DE): This is an abstract concept consisting of a domain problem and related requirements and solutions to reuse them efficiently. DEs are related to each other. This is a subset of Domain Information.
  • ⋅ DE ⊂ DI, where the criteria of classification are vertical and horizontal views.
  • ⋅ DE = (PDE, RDE, SDE), where PDE is a problem(s) classified by vertical and horizontal views.
  • RDEs are a set of requirements that have been prepared to reuse and are related to the PDE.
  • SDEs are a set of solutions that have been prepared to reuse and could meet RDEs.
If there are already existing domain elements that contain similar domain views and information, they are added or modified using elicited information.
- 4) Activity 4 - Validating Domain Elements and Storing Them in a Repository
The goal of this activity is to ensure that domain elements are reusable and that reuse is manageable. To validate domain elements, we should ensure that they have good characteristics, such as cohesion and coupling. This has an effect on reusing them, and provides basis information to decide whether domain elements are correct or not. Second, a domain element is ensured to have correct information such as problems, requirements, solutions, and the relationship among them. Because the information for finding domain elements effectively and efficiently is based on the real world, a specific problem within the domain element might correspond to some requirements and solutions. Finally, the commonalty and variability of each domain element should be reviewed to reuse and adapt them for different domains/applications.
After validating the domain elements, they are stored in a repository, which has a method for finding the correct reusable domain element efficiently. This repository and environment will be discussed in a future study.
- B. Domain and Domain Requirement
The goal of this process is to reuse domain/application requirements with a domain element. In this process, the requirements are identified by performing domain analysis of a project, and are adapted to consider the project’s characteristics [19] .
- 1) Activity 1 - Determining a Project Domain and Scope
The goal of this activity is to select a project domain and determine its scope for finding reusable domain elements. The domain could be considered a specific area or abstraction of the real world having some problems to be solved by a project. The requirement could then be considered as the inter-relationship between the problems and solutions [2 , 5] . Because problems are selected by a project, we assume that the project scope is determined by visualizing selected problems.
Term Definition 4: Project Scope
Project Scope (PS): This is an area that could include the problems to be solved by a specific project, related requirements, and solutions.
  • ⋅ PS ⊂ Domain
  • ⋅ PS = (PPS, RPS, SPS), where
  • PPS is a problem(s) interested in a specific project.
  • RPS is a set of requirements related to PPS.
  • SPS is a set of solutions to meet RPS.
- 2) Activity 2 - Selecting Domain Elements Related to the Scope
The goal of this activity is to select domain elements for identifying requirements in the selected scope. Some domain elements could be identified considering the relationships shown in the guidelines below. Because domain elements are a set of problems, requirements, and solutions that are classified as vertical and horizontal views of a domain and a set of related requirements, some candidate requirements are made by selecting domain element and applying the available variants of a project.
Guidelines for selecting domain elements as candidate elements
  • ⋅ A domain element that includes a PDE to be able to cover some PPS can be selected.
  • ⋅ A domain element that includes an RDE to be able to cover some RPS can be selected.
  • ⋅ A domain element that includes an SDE to be able to cover some SPS can be selected.
  • ⋅ A domain element that is considered to have similar vertical and horizontal views can be selected.
Term Definition 5: Candidate Requirements to be reused
Candidate Requirements (CR): The reusable requirements could be made by requirements of candidate elements and variants. A set of requirements to be made by applying variants is called Candidate Requirements.
  • ⋅ CR = (RPS, VP), where
  • VP is a set of variants applied by a specific project to RPS.
In identifying domain elements, the information for visualizing the domain/project scope is identified considering vertical and horizontal views, and this might provide some rationale for reusing requirements that have already been written.
- 3) Activity 3 - Adapting Domain Elements for Domain/Application
The goal of this activity is to adapt problems, requirements, and solutions in candidate elements considering the domain and project. To achieve the goal, this activity should be performed by completing some tasks to identify candidate variants that can be applied to varying points of domain elements and to select a variant considering the project/domain characteristic. As a result, the requirements for the domain and project are reused by applying the variant to the requirements of the domain element, which are then called reused requirements.
Term Definition 6: Reused Requirement by adapting domain elements
Reused Requirement (RR): The reused requirements are selected from Candidate Requirements.
  • RR ∈CR
- 4) Activity 4 - Validating Domain/Application Problems, Requirements, and Solutions
The goal of this activity is to validate reused requirements from domain elements and to store them in a repository. Some methods and techniques can be used for validating the reusability and feasibility of the requirements. The result of validation might be stored with the used methods and techniques. It will provide some information for reusing the domain elements. These domain elements revised using the information will have good quality.
V. VALIDATION FOR OUR STUDY
Our study performs some case studies to validate the proposed domain elements to reuse requirements. The first case study is performed to validate our concept and developing domain elements. The candidate target is 20
PPT Slide
Lager Image
Some requirements and features of specific software at SourceForge.net.
Identifying domain element considering vertical/horizontal views
PPT Slide
Lager Image
Identifying domain element considering vertical/horizontal views
applications in 4 categories in SourceForge.net, which is a portal of open source software (OSS), and we elicit some requirements of these projects. Using this requirement, domain elements are identified by applying our process for developing domain elements. We show the results of identified domain elements and of our concept.
The second case study is performed to validate the process for reusing domain elements. We select other applications that participate in a domain of a previous case study. We then create requirements using the previous results, which are domain elements of the first case study, and the process for reusing domain elements. We measure the reusability rate of the requirements that are developed using domain elements.
The third case study is performed to show evolutionary improvements in the reusability of requirements. Our processes are proposed to have more reusability than many applications used for domain elements. The third case study is similar to the second case study. However, the domain elements of the third one are improved using 20 other applications along with the second one. Therefore, we will compare the reusability rate between the second and third case study, and show improvements in the reusability of the domain element.
- A. The First Case Study to Validate the Concept of Domain Elements and Their Development Process
To validate our domain element, we performed a feasibility study of our work. Considering our process of developing the domain element, we have selected 20 applications in SourceForge.net, and have elicited some requirements using the feature list in project site. Fig. 7 shows features of a software program named is “ KeePass”.
We have elicited 265 requirements of 20 applications for 4 categories in SourceForge.net. Our second step is analyzing the domain using horizontal and vertical views. We defined 4 vertical views like the 4 categories in SourceForge.net and identified 35 horizontal views by analyzing the relationship (such as semantic similarity) of words included in the requirements and naming them. Table 2 shows some requirements for each view.
The third step of our process is to define the domain element. One of the key activities is analyzing commonality and variability considering two views. Table 3 shows an example, which generates reusable requirements with Business & Enterprise (vertical view) and Customize (horizontal view) using R047 and R050 as follows:
  • R047:The user might make some custom fields.
  • R050:The system should support a personalization of the specific user.
  • R047: might make some custom of .
  • R050: should support to make custom to .
The “ ; < >” in statement means a variation point to which different variants can be applied depending on the project characteristics. Such reusable requirements will be validated using appropriate techniques and will be refined to be reusable by applying the requirements of other projects. In this case study, 160 reusable requirements, 60 domain elements, 4 vertical views, and 22 horizontal views were defined by our process for developing domain elements.
- B. The Second Case Study to Validate the Effectiveness and Efficiency of Domain Elements and the Process of Reusing Them
To validate reusing domain elements and their effectiveness and efficiency, we performed a second case study to develop application requirements using domain elements developed from the first case study. The specific applications were selected from SourceForge.net. We considered the project goal and elicited some requirements using domain elements. Fig. 8 is one of the examples that we selected from the Business & Enterprise category. We analyze the software considering views, so 13 domain elements and 32 domain-requirements are selected as shown in Table 3 .
The domain elements and requirements to be reused from the first case study in the business & enterprisecategory
PPT Slide
Lager Image
The domain elements and requirements to be reused from the first case study in the business & enterprisecategory
PPT Slide
Lager Image
Application requirements of a selected project to validate the process for reusing domain elements.
Domain elements for 4 categories and 20 projects
PPT Slide
Lager Image
Domain elements for 4 categories and 20 projects
Some variants considering project characteristics are applied to the domain requirements at the domain elements, and application requirements are elicited. That is, as project requirements are related to domain-elements, we consider whether to reuse domain requirements or not. Upon analyzing the result, 10 domain requirements of 32 domain requirements were found to be reusable and 33 application requirements of 45 application requirements can be elicited using domain elements.
To show the extent of reuse of the domain element, we use precision and accuracy metrics [25] , which are the degrees of closeness to evaluate the effectiveness and efficiency of the subset elicited from the population. In our study, the metrics are calculated by analyzing the relationship between the elicited requirements and total requirements of either domains or applications. Table 4 represents the effectiveness and efficiency of the domain elements (elicited from the first case study) considering 20 applications.
It was found that the domain elements of the first case study have 20–40% precision. That is, using domain elements, at least 20% of the domain requirements would be reused. The domain elements have 33?80% accuracy, that is, the application-requirements elicited by using the domain elements are reused in the applications above 33% of the time.
- C. The Third Case Study to Validate Improving Reusability of Domain Elements
The third case study was performed to validate the reusability of the domain elements. Our processes for developing and reusing domain elements include an activity for validating and storing the domain element to the repository to provide feedback and improve them. Therefore, reusability of domain elements might be increased as more requirements are collected. To validate them, we compare the domain elements of the first case study and second case study, and use the number of vertical and horizontal views and precision and accuracy as criteria. Table 5 represents the results of the third case study.
The results of validating the reusability of domain elements
PPT Slide
Lager Image
The results of validating the reusability of domain elements
From the comparison, it was found that domain elements that are generated from a large number of applications have higher values of precision and accuracy than those generated from fewer applications. Therefore, we validated the evolutionary improvement in reusability of our domain elements.
VI. CONCLUSIONS
Our study proposes the concept of domain elements for reusing requirements. The domain elements are developed by collecting information from various applications, analyzing them considering vertical and horizontal views, and defining domain elements using the results of the analysis. They are then reused in future applications by identifying the appropriate domain elements considering vertical and horizontal views of the future domain, applying variants of the (domain) requirement in the domain elements, and generating reused application requirements. In our study, we validate the concept of domain elements and related processes using 40 applications at Sourceforge.net.
There are some limitations of our study. First, our study does not propose techniques for analyzing commonality and variability of requirements in domain elements. Second, this study does not propose the concrete method for searching and applying variants to domain requirements. Finally, our study does not describe the environment for domain elements.
We will perform some future work as follows. First, to validate domain elements practically, we will perform many case studies and refine our results. Second, concrete methods and techniques related to our study should be developed. Finally, we will propose some tools and environments for automating our processes and managing domain elements.
References
Kotonya G , Sommerville I 1996 “ Requirements engineering with viewpoints” Software Engineering Journal 11 (1) 5 - 18
Davis A. M 2005 Just Enough Requirements Management: Where Software Development Meets Marketing Dorset House Pub. New York
Davis M , Zowghi D 2005 “ Good requirements practices are neither necessary nor sufficient” Requirements Engineering 11 (1) 1 - 3
Ross D. T 1977 “ Structured analysis (SA): a language for communicating ideas” IEEE Transactions on Software Engineering 3 (1) 16 - 34
Zimmermann D , Grotzbach L 2007 “ A requirement engineering approach to user centered design” Proceedings of the 12th International Conference on Human-Computer Interaction Beijing,China 360 - 369
Hooks I. F , Farry K. A 2000 Customer-Centered Products: Creating Successful Products through Smart Requirements Management American Management Association New York
DeBaud J. M , Schmid K 1999 “ A systematic approach to derive the scope of software product lines” Proceedings of the 21st International Conference on Software Engineering Los Angeles, CA 34 - 43
Kang K. C , Cohen S. G , Hess J. A , Novak W. E , Peterson A. S 1990 “ Feature-oriented domain analysis (FODA) feasibility study” Software Engineering Institute, Carnegie Mellon University Pittsburgh, PA Technical Report CMU/SEI-90-TR-21
Lee K , Kang K. C , Lee J 2002 “ Concepts and guidelines of feature modeling for product line software engineering” Proceedings of the 7th International Conference on Software Reuse Austin, TX 62 - 77
Kuusela J , Savolainen J 2000 “ Requirements engineering for product families” Proceedings of the 22nd International Conference on Software Engineering Limerick, Ireland 61 - 69
Moon M , Yeom K 2004 “ An approach to develop requirement as a core asset in product line” Software Reuse: Methods, Techniques, and Tools, Lecture Notes in Computer Science 3107 23 - 34
Moon M , Yeom K , Chae H. S 2005 “ 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 31 (7) 551 - 569
Simos M , Creps D , Klingler C , Levine L , Allemang D 1996 “ Organization domain modeling (ODM) guidebook version 2.0” Lockheed Martin Tactical Defence Systems Manassas: VA Technical Report STARS-VC-A025/001/00
Holibaugh R. R 1992 “ Joint integrated avionics working group (JIAWG) object-oriented domain analysis method (JODA)” Software Engineering Institute, Carnegie Mellon University Pittsburgh, PA Special Report CMU/SEI-92-SR-003
Prieto-Diaz R 1990 “ Domain analysis: an introduction” ACM SIGSOFT Software Engineering Notes 15 (2) 47 - 54
Gorschek T , Wohlin C 2005 “ Requirements abstraction model” Requirements Engineering 11 (1) 79 - 101
Gorschek T , Davis A. M 2008 “ Requirements engineering: In search of the dependent variables” Information and Software Technology 50 (1-2) 67 - 75
Frakes W , Prieto-Diaz R , Fox C 1998 “ DARE: Domain analysis and reuse environment” Annals of Software Engineering 5 125 - 141
Lam W , McDermid J. A 1997 “ A summary of domain analysis experience by way of heuristics” ACM SIGSOFT Software Engineering Notes 22 (3) 54 - 64
The Standish Group 2009 CHAOS Summary 2009 The Standish Group International Boston
Buhne S , Pohl K 2005 “ Domain requirements engineering” in Software Product Line Engineering Heidelberg Springer 193 - 216
Sutcliffe A. G , Maiden N. A. M 1994 “ Domain modeling for reuse” Proceedings of the 3rd International Conference on Software Reuse Rio de Janeiro, Brazil 169 - 177
Coplien J , Hoffman D , Weiss D 1998 “ Commonality and variability in software engineering” IEEE Software 15 (6) 37 - 45
Harsu M 2002 “ A survey on domain engineering” Tampere University of Technology Tampere, Finland Technical Report 31
Acken J. M 1997 “ Logic level modeling” in Encyclopedia of Computer Science and Technology Vol 36 Marcel Dekker Inc. New York 281 - 306