Sewradj, Runa (4148428), Group A, Utrecht University, Leuvenlaan 4, Minneart building, 3548 LA
Utrecht, Netherlands, r.s.sewradj@students.uu.nl
Notice of Originality
I declare that this paper is my own work and that information derived from published or unpublished work of others has been acknowledged in the text and has been explicitly referred to in the list of references. All citations are in the text between quotation marks (“ ”). I am fully aware that violation of these rules can have severe consequences for my study at Utrecht
University.
Signed:
Date: 11-04-2014
Name: Runa Sewradj
Place: Utrecht
The delineation of this paper concerns the paper “Extracting and Modeling Product Line Functional
Requirements” by Niu and Easterbrook (2008).
Niu and Easterbrook (2008) describe the extraction and modeling of a software product line’s
(SPLs) functional requirements assets. For extracting and modeling the requirements assets a semiautomated method was applied. According to studies in the field of requirements engineering (RE) and small and medium-sized enterprises (SMEs) a majority of requirements assets are in Natural Language
(NL) documents (David Sheperd, Lori Pollock, 2006). Therefore the NL written documents from legacy systems were utilized to identify and analyze the functional requirements profiles (FRPs).
Through that process FRPs could be extracted and validated. FRPs are defined as the study of system qualities and capture domain’s action themes. The profiles were used because of its functional aspects, which is advisable to use for modeling an SPLs actions and external behaviour. In order to find interdependencies of the requirements the FRPs were merged.
Requirements assets of software product lines (SPLs) can be extracted and modeled when it is stated in a mature domain (Bühne et al., 2003). Requirements extracting and modeling in a mature domain ensures that SPLs can be used on a long-term. Extracting requirements was performed with the use of an auto-marker SPL. An auto-marker refers to automatically generating requirements using
Software requirements specifications (SRSs). Extracting requirements of a SPL has a number of basic tenets, namely: Maximal reuse , gradual change and reactive development (Niu & Easterbrook, 2008).
Each of these tenets indicates what should be taken into account when adopting the extractive model.
The results of the extraction model were presented using a orthogonal variability model
(OVM) (K. Pohl, G. Böckle, 2005). An OVM uses a single view to determine a SPLs variability.
Two aims were described by the authors to specify their contribution to the research field of
SPLs. Firstly, to provide insights into functionalities of SPL systems and product line variabilities, and complements domain analysis. Secondly, the reduction of the cost of manual operation and an increase of the operations efficiency (Niu & Easterbrook, 2008).
1

The domain in which the method was executed is the SPL engineering domain. The enterprises in this domain who will have the most benefits from the model are SMEs according to
(Bühne et al., 2003).
The final deliverables of this method are semantic cases and the automated generated FRPs.
Semantic cases are created with the OVM.
One of the authors of this paper is Nan Niu. Niu followed his Ph.D. at the University of
Toronto. Currently, Niu is an assistant professor at the University of Mississippi at the department of
Computer Science and Engineering. His interests focuses on “information seeking strategies that developers use in software development.” (Niu, 2013). His latest paper is: “On the sole of semantics in automated requirements tracing” (Niu, 2013).
The other author is Steve Easterbrook. Easterbrook is a professor at the University of Toronto at the department of Computer Science and Engineering. Currently, Easterbrook is focusing on:
“the contributions of computing and software to the challenge of dealing with climate change.”
(Easterbrook, 2013). Previously, his focus was on “ systems analysis for complex software-intensive systems.” (Easterbrook, 2013).
In order to apply the aforementioned process, about extracting and modeling product line functional requirements, an example will be explained. Take for example the software of an online bookstore which deals with operation management. Operations management manages the production of a company’s products. At first the FRPs need to be retrieved. The online bookstore has developed software requirements specifications (SRS’s) in order to efficient and effective manage the progress of the production. SRS’s are the NL written documents about the software requirements that need to be analyzed (Niu & Easterbrook, 2008), see Figure 1 and 2. The documents can be composed with the help of interviews or analysis of other existing documents.
After FRPs are retrieved the model clearly shows the system’s functionalities for the users
(Niu & Easterbrook, 2008), see Figure 4. The domain dictionary will be retrieved if it already exists
(Lai, 1999) or need to be complemented, for an example see Figure 3. Domain dictionaries are terms which are standard used in the operations management domain of the online bookstore. The created
FRPs characterizing the action themes of a SPL’s (Figure 4).
Figure 1: Functional requirements
2

Figure 2: Domain concepts
Figure 3: Functional Requirements Profiles
(FRPs)
3

The created FRP’s are now used to analyze the variability structures by applying Fillmore’s semantic cases: agentive, objective, process, etc. (Fillmore & Charles, 1968). Figure 5 shows a example of a variation dimension of a semantic case for FRP.
The case describes the range of a dimension, see Figure 6. For example: a ‘registration system’ can ‘send email’, and the type of sending must be ‘on-time’. OVM shows what the variation point is.
The “V” box depicts the variation. Then the FRPs and “VP” are mapped to each other. Hereafter the variants are organized by the cases of FRP. The solid line depicts what is mandatory and the dotted lines depicts the optional ones.
Figure 4: Case for FRPs (Niu &
Easterbrook, 2008)
Figure 5: Orthogonal Variability Model
(OVM ) (Niu & Easterbrook, 2008)
The aforementioned example will be more clear by elaborating its Process-Deliverable diagram
(PDD). The PDD will depict the processes and deliverables of an extraction of a product line’s functional requirements (see Figure 7). In order to model the PDD in an correct way the modelling technique of Van de Weerd and Brinkkemper (2008) is used.
The methods used to build or describe the PDD also derive from other existing methods and techniques. For example the OVM modeling technique from Pohl et al. (2005) and functional requirements profiles used to form semantic cases by Fillmore (1968).
On the left side the process activities are modeled and on the right side are the deliverables modeled.
4

Figure 6: Process-Deliverable Diagram (PDD)
5

Activity
Extracting
Functional
Requirements
Evaluating
Functional
Requirements
Creating
Semantic Cases
Sub-activity
Retrieve SRS
Write/Develop
SRS
Retrieve domain dictionary
Description
Software requirements specifications are retrieved from a specific domain’s source for requirements analysis.
Drafting or develop a SRS by a project manager if not available.
A DOMAIN DICTIONARY containing a set of terms which are generally used in a specific domain.
Drafting a domain dictionary by a domain manager if not available or develop one
Write/Develop domain dictionary
Extract domainaware LAs
Determine domain-aware
LAs
Define FRPs
Extracting domain-aware lexical affinity (LA) from documentation by using a two-word unit
(Maarek et al., 1991). REQUIREMENTS
DOCUMENT and DOMAIN DICTIONARY are used to extract LAs.
Determining the correlation of the two-word units’ and determining high value LAs from the DOMAIN-AWARE LAS.
The FRPs are defined with the DOMAIN-
AWARE LAS and ORTHOGONAL
VARIABILITY MODEL.
Compare FRPs Comparing FRPs is done with the
FUNCTIONAL REQUIREMENTS
PROFILES in where the first unit of LAs were tagged as a verb.
Evaluate index schemes
The compared FRPs are used to evaluate the index schemes described by Maarek et al.
(1991). Index schemes characterize documents for integrating legacy documentation.
Analyze requirements documents
Complementary analyzes for the evaluation of the index schemes.
Evaluate FRPs FUNCTIONAL REQUIREMENTS
PROFILES (FRPs) contains the activity input from the activities ‘Evaluate index schemes’ and ‘Analyze requirements documents’. The
Define variation dimensions
Define constraints
Define internal variation frame
Create semantic case
FRPs are acquired by analyzing natural language documents.
Set of dimensions used to describe the
DIMENTIONS defined by the project manager.
Set of dimentions used to describe the
CONSTRAINTS defined by the project manager.
Set of dimentions used to describe the
VARIATION FRAME defined by the project manager.
Variation structures are described with the
OVM (ORTHOGONAL VARIABILITY
Roles
Project management
Project management
Project management
Project management
Project management
Project management
Project management
Project management
Project management
Project management
Project management
Project management
Project management
Project management
Project management
6

MODEL).
Table 1: Activity table
Concept
REQUIREMENTS DOCUMENT
DOMAIN DICTIONARY
Description
Documents written in natural language (NL) which describe requirements specifications (Niu
& Easterbrook, 2008).
Common used terms are bound together in a
DOMAIN DICTIONARY (Niu & Easterbrook,
2008). These are used within a domain.
DOMAIN-AWARE LAS Contains information of REQUIREMENTS
DOCUMENT and DOMAIN DICTIONARY
(Niu & Easterbrook, 2008).
FUNCTIONAL REQUIREMENTS PROFILES A template containing the DOMAIN-AWARE
LAS and can be measured using a ρ score (Niu &
Easterbrook, 2008).
DIMENSIONS
CONTRAINTS
VARIATION FRAME
DIMENSIONS are used to describe characteristics of FUNCTIONAL
REQUIREMENTS PROFILES. It is described in each case, which is used in an Orthogonal
Variability Model (Niu & Easterbrook, 2008).
After FPRS are merged CONSTRAINTS are used to form an Orthogonal Variability Model
(Niu & Easterbrook, 2008).
VARIANTION FRMAE is determined by the different dimensions (Niu & Easterbrook, 2008).
OVM Orthogonal Variability Model is a result of a created semantic case. The Orthogonal
Variability Model defines a Software product line
(SPL) (Niu & Easterbrook, 2008).
Table 2: Concept table
Software product lines (SPLs) are now more in use in the software industry and are proven to be successful when reusing software (Hartmanis & Leeuwen, 2002). There are several approaches defined to adopt a SPl. The approaches elaborate “ the systematic reuse of core assets for building related products (Hartmanis & Leeuwen, 2002).”
An important part of the method of Niu and Easterwood is founded in the mentioned OVM.
This model is developed by Pohl et al. (2005). It describes a case theory by using Fillmore (1968).
This method was also used by Metzger and Pohl (2006). Niu and Easterwood used this model and extended is a bit more.
Rosa et al. (2008) described how to position an OVM. They mentioned that Software
Configuration Management (SCM) and Feature Diagrams (FDs) are two options to execute this process. SCM elaborates the how to built a software system from a number of components. FDs designs a delineation of a Software product line (SPL).
7

Bühne, S., Chastek, G., Käkölä, T., Knauber, P., Northrop, L., & Thiel, S. (2003). Exploring the
Context of Product Line Adoption, 14.
David Sheperd, Lori Pollock, K. V.-S. (2006). Using Natural Language Program Analysis to Find and
Understand Action-Oriented Concerns, 12.
Easterbrook, S. (2012). Steve Easterbrook . Retrieved February 10, 2014 from www.cs.toronto.edu/~sme
Fillmore, C. (1968). The case for case. (E. Bach, & R. Harms, Eds.) Universals in Linguistic Theory ,
1-88. link
Hartmanis, J., & Leeuwen, J. Van. (2002). On the Influence of Variabilities on the Application-
Engineering Process of a Product Family (pp. 1–14).
La Rosa, M., van der Aalst, W. M., Dumas, M., & ter Hofstede, A. H. (2009). Questionnaire-based variability modeling for system configuration. Software & Systems Modeling , 8 (2), 251-274. link
Lai, D. M. W. and C. T. R. (1999). Product-Line Engineering: A Family-Based Software Development
Process.
Maarek, Y., Berry, D., & Kaiser, E. (1991). An Information Retreival Approach for Automatically
Constructing Software Libraries. IEEE Transactions on Software Engineering , 17 (8), 800-813. link
Niu, N. (2009, May 9). Nan Niu . Retrieved Febraury 10, 2014 from www.cs.toronto.edu/~nn
Niu, N., & Easterbrook, S. (2008). Extracting and Modeling Product Line Functional
Requirements. RE '08 Proceedings of the 2008 16th IEEE International Requirements Engineering
Conference (pp. 155-164). Washington, DC, USA: IEEE Computer Society. link
Pohl, K., & Metzger, A. (2006). Variability management in software product line engineering.
Proceeding of the 28th International Conference on Software Engineering - ICSE ’06 , 2. doi:10.1145/1134285.1134499
Phol, K., Böckle, G., & van der Linden, F. (2005).
Software Product Line Engineering . Germany:
Springer. link
Weerd, I. van de, & Brinkkemper, S. (2008). Meta-Modeling for Situational Analysis and Design
Methods. In M. Syed, & S. Syed, Handbook of Research on Modern Systems Analysis and Design
Technologies and Applications (pp. 35-54). Hershey, PA, United States of America: Information
Science Reference. link
8