tool support for the derivation of product line use …

Malardalen UniversitySchool of Innovation Design and Engineering

Vasteras, Sweden

Thesis for the Degree of Master of Science (120 credits) in ComputerScience with Specialization in Software Engineering, 30 credits

TOOL SUPPORT FOR THE DERIVATION OF

PRODUCT LINE USE CASES: A CASE STUDY

IN THE RAILWAY TRANSPORTATION

DOMAIN

Viking [email protected]

Examiner: Jan CarlsonMalardalen University, Vasteras, Sweden

Supervisor: Wasif AfzalMalardalen University, Vasteras, Sweden

Supervisor: Damir BilicMalardalen University, Vasteras, Sweden

Company supervisor: Henrik Gustavsson,Alstom, Vasteras, Sweden

September 1, 2021

Viking Forsman Tool support for the derivation of product line use cases

Abstract

Use cases are textual artifacts used to define the expected behavior of a system. However, usecases become more complicated when applied in a product line context since they need to definethe behavior of several systems. Product line use cases require knowledge of commonality andvariability concepts, which all involved stakeholders do not necessarily possess. Product-specificuse cases are more understandable since they do not include variability information. Therefore,it would be beneficial to derive product-specific use cases from the product line use cases once thevariability has been bound. This derivation could alleviate communication and help create a sharedunderstanding of the product’s expected behavior amongst diverse stakeholders.

In this thesis work, we have implemented a tool that can perform this type of derivation. Thetool is divided into two collaborating parts. The first part is an extension to DOORS, which isresponsible for creating and maintaining product line use cases. The second part is a third-partyapplication responsible for binding the variability and deriving product-specific use cases. Thistool was evaluated using a questionnaire with participants from Alstom, a company within therailway transportation domain. The evaluation showed that the tool has potential as a vehicle forcommunication amongst diverse stakeholders.

i


Contents

1. Introduction 1

2. Background 12.1. Product Line Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.2. Product specific use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.3. Product line use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.4. Product line vs Product specific . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.5. DOORS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3. Related Work 93.1. PUMConf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.2. DREAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.3. PLUSEE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.4. PLUSS toolkit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4. Case study design 114.1. Research question . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114.2. Case and subject selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114.3. Data collection procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.4. Analysis procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.5. Validity procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

5. Results 135.1. Selection of a use case template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135.2. Identifying stakeholder collaboration . . . . . . . . . . . . . . . . . . . . . . . . . . 175.3. Implementing the tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185.4. Evaluation using a questionnaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

6. Discussion 276.1. Participant experience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276.2. Understandability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276.3. Collaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286.4. Variability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296.5. Improvement suggestions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

7. Conclusions 307.1. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307.2. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

References 34

Appendix A Questionnaire 35

ii


List of Figures

1 UML use case diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Cockburn’s fully dressed use case template . . . . . . . . . . . . . . . . . . . . . . . 43 Cockburn’s scope and goal hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . 44 PLUS use case diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Gomaa’s product line use case template . . . . . . . . . . . . . . . . . . . . . . . . 66 Evolutionary Software Product Line Engineering Process . . . . . . . . . . . . . . 78 Use case diagram of the passenger alarm system, modeled after the PLUS approach. 159 The workflow of the tool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1810 Use case specification as presented in DOORS. . . . . . . . . . . . . . . . . . . . . 1911 Use case specification as presented in the application interface. . . . . . . . . . . . 2012 Example of a configured product line use case. . . . . . . . . . . . . . . . . . . . . 2113 Example of a derived product specific use case. . . . . . . . . . . . . . . . . . . . . 2214 Questionnaire result for question 3 to 12 . . . . . . . . . . . . . . . . . . . . . . . . 23

List of Tables

1 Questionnaire result for question 13. . . . . . . . . . . . . . . . . . . . . . . . . . . 242 Questionnaire result for question 14. . . . . . . . . . . . . . . . . . . . . . . . . . . 253 Questionnaire result for question 15. . . . . . . . . . . . . . . . . . . . . . . . . . . 26

iii


1. Introduction

The term metro is a broad description of underground or partly underground railway transportationsystems. The development of products within this domain usually requires the collaboration of amultitude of stakeholders with different backgrounds and experiences, which makes communicationan important aspect of the development process. In addition, the product requirements may alsovary greatly depending on the region where it is intended to be distributed [1].

Product line engineering is one approach that can be applied to manage the variability of suchproducts [2]. This approach develops a family of products that use a common baseline from whichindividual members can be tailored to meet customers’ requirements. The features that are notpresent in all product family members are collected into a portfolio of reusable components fromwhich the customer can choose the alternatives that best suit their needs. The commonalities anddifferences between the individual members’ requirements have to be identified to utilize a productfamily effectively.

Use cases are a successful method for modeling requirements for single systems, and theycan be extended to support requirements from product lines. However, this requires prerequisiteknowledge of product line use cases, which all involved stakeholders do not necessarily possess.Therefore, it would be beneficial to derive product-specific use cases from the product line use casesonce the variable features have been selected. Product-specific use cases are less complicated sincethey do not include any variability information. This derivation could alleviate communicationand help create a shared understanding of the product’s expected behavior amongst stakeholders.It would be beneficial to automate this process so that the transformations are consistent and tosave time.

The motivation of this thesis is twofold. We want to explore how to derive product-specific usecases from product line use cases and how this process could improve stakeholder collaboration.Therefore, we performed a case study where we reverse-engineered product line use cases based onindustry specifications from three similar products. This process allowed us to better understandthe typical type of variability in the domain and identify a suitable use case template. We thenimplemented tool support for product line use cases in an established requirement engineering tool,including a method to bind variability in a user-friendly way to derive product-specific use cases.

2. Background

In this section, we will provide background information regarding concepts that will be discussedin the thesis. These concepts are briefly described to assist the reader in understanding the thesiswork and its motivation.

2.1. Product Line Engineering

A common approach when developing a product family is called ”clone-and-own” [3], where thespecifications from one initial product are copied and modified to suit a new product’s needs. Thisad-hoc approach without formal procedures does not require any specialized reuse training andhas a low initial development cost. However, this low cost is short-termed since it does not scalewhen more members are added to the product family. Maintaining and synchronizing a multitudeof cloned products necessitates a large amount of manual work, which can be both time-consumingand error-prone. An alternative to this is to rely on more stable variability management techniquessuch as product line engineering.

Product lines are a way to develop families of systems with a common reusable baseline thatthe individual family members can build upon to satisfy their differing requirements [2]. Thisapproach can provide a large variety of products to customers while still maintaining many ofthe benefits from mass-produced and standardized solutions. Customers choose options from aportfolio of reusable components to tailor the product to meet their specific requirements [2]. Thereusable components reduce the overall cost of products since they do not have to be developedfrom scratch when new family members are instantiated. The up-front development cost for aproduct line may be higher than the development cost of a single system since the initial productmight not require the provided variation options.

1


However, the long-term benefits will eventually outweigh this initial investment when theamount of requests for customized products increases [2]. Standardizing products can improve theirquality since it allows large-scale testing to be performed systematically [2]. But a standardizedproduct also offers less flexibility to satisfy varying customer requirements. Product lines providea compromise between these options since the reusable components can be standardized, but thecustomers can still customize their product within the limitations of the product line. Building aproduct completely from scratch allows it to be tailored to the customers’ requirements, but thisalso requires a significant investment of time to design and develop the product properly. Thedevelopment time can be reduced drastically by tailoring the product from already implementedreusable components [2]. Even if the product line has to be extended with features that are notyet implemented, the common baseline will still reduce the development time. Therefore productlines provide a reduced time-to-market compared with traditional development methods, which isan important attribute to be able to react to market changes.

The creation and maintenance of a product line can be divided into two processes [2], whichare called domain and application engineering. The domain engineering process is responsible forcreating reusable artifacts based on the product line’s commonality and variability. The applicationengineering process is responsible for deriving an application from these reusable artifacts to meetproduct-specific needs. These processes contain several development activities associated withrequirement, design, realization, and testing of the product line and its members. However, inthis paper’s context, we are primarily interested in the activities that involve the elicitation anddocumentation of requirements in the product line. Gomaa identifies three main activities related tothe creation of domain requirements [4]. The first activity is product line scoping, which establishesoverarching aspects of the product line. This includes identifying potential members, their degreeof commonality and variability, and the provided functionality’s outer bounds. The second activityis use case modeling, which captures the functional requirements as interactions between the systemand actors. The third activity is feature modeling, which identifies the commonality and variabilitybetween the product line members. A feature in this context refers to a reusable requirement orcharacteristic of the product line.

2.2. Product specific use cases

Large systems have a long lifetime and can grow to become very complex [5]. The developmentof large systems generally requires collaboration between many stakeholders from different workdisciplines. A unifying factor for all stakeholders is that they have a vested interest in the system’sbehavior. Therefore, it is advantageous if the system in question is developed with well-definedfunctional requirements that the involved stakeholders can easily understand. One approach whendesigning such functional requirements is by composing use cases, which can provide an overviewof the system’s behavior. There are many textual templates for use cases which has differentcharacteristics [6]. One of these templates, which was proposed by Cockburn [5], has gained muchtraction within the industry. Cockburn has stated that it is reasonable in certain situations toomit fields from this template to create a more lightweight and casual version. The fully dressedversion of this template can be seen in Figure 2.

A use case describes a sequence of interactions between one or more actors and the system[5]. These interactions can have different outcomes depending on the conditions surrounding theinteractions. Actors can either be humans or external systems that interact with the system toachieve a goal. Each use case always has a primary actor that initiates the interaction, and the usecase addresses this actor’s goal. The use case ends when the primary actor’s goal is successfullyachieved or when the scenario deviates and the goal has to be abandoned. The use case can havepreconditions that describe conditions which has to be true at the start of the use case. Similarly,the use case also has a postcondition that describes the conditions that are true at the end ofthe use case if the main sequence of interactions were followed (i.e., the primary actor’s goal wasfulfilled).

2


Use cases have a broad usage domain and can describe behavior with different levels of rigorand technical details. A use case can be assigned a scope that defines its responsibility boundaries,which means that any interactions outside the scope are not considered. The template suggested byCockburn has a scope hierarchy scheme with three levels of differing granularity [5]. Business scopeincludes goals and interactions for enterprises. System scope includes goals and interactions forcomputer systems. Component scope includes goals and interactions for subsystems or components.Use cases are usually designed with a ”black-box” perspective, meaning that the system’s internalstructures are unknown, and only the outward response from the system is considered. However,it is sometimes necessary to create use cases with a ”white-box” perspective, meaning that thesystem’s internal structures are known, and the behavior of internal actors is considered. Thisdifference is expressed in the scope hierarchy. The goals themselves are also divided into a similarhierarchy in this scheme, where the level of details in the use case is defined. The higher levels inthis hierarchy outline why the goal should be achieved, while the lower levels focus more on howto achieve the goal. The scope and goal hierarchies suggested by Cockburn can be seen in Figure3.

Relationships between use cases and actors or other use cases can be expressed in graphicalnotations, the most common of which is the UML use case diagram [7, 8]. This type of diagramprovides a high-level overview of the system by obscuring the details contained in the use cases.See an example of a use case diagram in Figure 1. The use cases are represented as eclipses,actors are represented as stick figures, the system is represented as a rectangle, and relationshipsare represented as arrows. Four different types of relations are supported in this type of diagram:Associations show which actors interact with a use case. Generalization relationships show theinheritance of behavior between use cases or the inheritance of associations between actors. Includerelationships show that the behavior of one use case is contained within another use case. This canbe used to reduce complexity or to extract behavior that is common to multiple use cases. Extendrelationships show that one use case’s behavior might occur in another use case. This relationshipcan be further defined with an extension point, which describes the conditions that need to be truefor the behavior to occur. Each extension point is assigned a name that is displayed in the baseuse case and on the extend relationship notation. The latter of these also displays the conditions.

See Figure 4 for an example of extension points.

Figure 1: Example of a UML use case diagram [4].

3


Figure 2: Fully dressed use case template as described by Cockburn [5]. Note that putting thetemplate content in a table is optional, and it can also be expressed in a completely textual form.

Figure 3: Hierarchy of use case scopes and goals as described by Cockburn [5], the icons are usedto assist the reader in differentiating the levels in the hierarchy.

4


2.3. Product line use cases

Use case specification becomes more difficult when applied in a product line context [6, 4]. A usecase defined for a single system will only contain the necessary elements for that specific system. Inproduct families, it is unlikely that every member will require all actors or use cases. The basic setof use case concepts has to be extended to express this variability between the individual membersof the product family.

The PLUS approach, which was introduced by Gomaa [4], accomplished this by classifying usecases into three categories based on their variability: Kernel use cases represent the commonalityin the product line and are required by all its members. Optional use cases are only required by asubset of the members. Alternative use cases represent a choice where the members must choosebetween varying solutions that usually are mutually exclusive.

Smaller variations can be expressed as variation points within the use case itself, which avoidsintroducing trivially small use cases that could reduce the overall readability [4]. In the PLUS ap-proach variation points should be assigned a name, type of functionality (i.e., optional, alternativemandatory, or alternative optional), the lines where it could be introduced, and a description ofits functionality. The textual template for PLUS can be seen in Figure 5 and an example of a usecase diagram with PLUS entities can be seen in Figure 4.

The process of identifying kernel, optional and alternative use cases is often referred to as com-monality and variability analysis. Gomaa [4] have identified two main strategies when performingthis analysis and designing product lines. The first strategy is forward evolutionary engineering,which is best suited when developing a product line for a new product family where existing sys-tems cannot guide the development. This strategy first defines the kernel use cases for the membersof the product line. Optional and alternative use cases are then iteratively introduced into theproduct line, and during each iteration, the previous classifications can be adjusted. The secondstrategy is reverse evolutionary engineering, which is best suited when developing a product line foran existing product family. This strategy reverse-engineers the individual members’ specificationsinto product line use cases. These use cases are classified into the kernel, optional, or alternativecategory depending on the variability between the individual members’ specifications.

Both of these strategies are incremental and evolutionary, which removes the classical distinc-tion between development and maintenance [4]. A high-level overview of this engineering process,which is divided into two domains, can be seen in Figure 6. The first domain is software productline engineering, where models and reusable components are created according to the identifiedcommonality and variability amongst the individual members. These development artifacts arestored in a common repository that is accessible from both domains. The second domain is soft-ware application engineering, where individual product family members are instantiated using theartifacts from the repository. The individual members’ unsatisfied requirements, errors, and adap-tations are used as feedback to evolve the product line in the next iteration. A case study performedby Kruger et al. [9] suggests that the different work phases in reverse engineering product lines areoften intertwined and iterative instead of progressing like a waterfall with easily separable activi-ties. This approach can also be seen in the PLUS approach, which suggests iteratively expandingupon a ”throwaway prototype” of the product line until its requirements are well-understood [4].

5


Figure 4: Example of a PLUS use case diagram [4].

Figure 5: PLUS use case template as described by Gomaa [4]. Note that putting the templatecontent in a table is optional, and it can also be expressed in a completely textual form.

6


Figure 6: The Evolutionary Software Product Line Engineering Process (ESPLEP) as describedby Gomaa [4].

2.4. Product line vs Product specific

Use cases have many areas of utilization, and there exist different schools of thought concerningthe relationship between use cases and functional requirements [5]. Use cases can in themselves beclassified as requirements, while others consider them a method to reveal requirements. But it isgenerally agreed upon that use cases are adept at capturing the expected response of a system byformulating its behavior in a structured manner which helps avoid introducing ambiguity in thesystem. The way use cases are structured can, however, be challenging to understand and learn[10]. This is especially true for product line use cases which must manage both commonality andvariability concepts, which all the involved stakeholders do not necessarily possess.

Therefore it could be beneficial to derive the product line use cases into simpler use cases,which only include product-specific information once the variability options have been selected.The extra information in the product line use cases is used to present the available variabilityoptions to stakeholders, assisting them in choosing options that best suit their needs. The benefitof this type of use case template is that it can capture the behavior of multiple systems in onedevelopment artifact instead of several, which increases the maintainability and reduces the riskof introducing inconsistencies. However, this necessitates that the author of the use cases andthe stakeholders that guide the customer through the binding process are familiar with variabilityconcepts. The benefit of the less complicated product-specific use case template is that it does notrequire specialized knowledge and can, therefore, be used for collaboration amongst a more diverseset of stakeholders.

The concept of changing use case templates based on its intended readers is advocated byCockburn [5], who recommends two types of templates called fully dressed and casual. Fullydressed use cases contain more information, making them more challenging to read, but they areless likely to introduce ambiguity. Casual use cases are faster to read and are generally easier tounderstand, but they can introduce ambiguity. A fully dressed use case is suitable for certain typesof stakeholders who need to know the details of the system, while a casual use case might be enoughto describe the system behavior to a stakeholder who is more interested in the overarching behaviorof the system. This is similar to how product line use cases are interesting to engineers that workwith requirements that span multiple products. In contrast, the application engineers and thecustomer are more interested in the product-specific use case that can be derived by binding thevariability.

7


2.5. DOORS

Alstom uses the commercial tool DOORS to engineer and manage requirements. This tool iscreated and maintained by the multinational cooperation IBM. Some of the key characteristics ofthis tool are the following [11]:

• Hierarchical database: DOORS uses a hierarchical database that is structured in projectsand folders. These can contain formal modules where the requirements are documented in aspreadsheet format, where the rows are called objects, and the columns are called attributes.The objects are also organized in a hierarchical structure with sections and sub-sections. Eachobject contains a textual description where the requirement can be defined, which can befurther clarified using attributes. Attributes have a type and a definition. There are severalbase attribute types, such as integer, string, enumeration, and date. These base attributescan be combined to create custom attribute types.

• Traceability: DOORS supports traceability between objects via link modules that connectobjects through links, which can map information and estimate the impact of changed infor-mation. Links are also traversable, making it easier to find the relevant information withouthaving to perform a manual search. An obvious application for this functionality is to linkrelated requirements to one another. Links do not necessarily have to point to content storedin the same module. It can point to content in other modules or even external content suchas URL addresses.

• Filters and views: DOORS support filters that can be used to customize the type ofinformation that is displayed. This can be a useful way to only display information that isrelevant to a specific stakeholder. For example, a business manager might not be interestedin formal modules and attributes that are related to detailed implementation requirements.Frequently used filters can be saved as views, which contain the configuration of the filters.Users can switch between views and access their information without having to reconfigureand run the filter.

• Textual and visual requirements: DOORS primarily defines requirements in textual for-mat and does not inherently support the creation of graphical models. However, images canbe imported and displayed in formal modules. A potential risk with this approach is that itlacks a practical way to check the consistency between imported models and textual require-ments. A way to mitigate this problem is by deriving the model from textual requirements.An example of this is the feature modeler developed by Thurimella et al. [12], who were ableto derive a graphical variability tree based on textual requirements in DOORS. However, theautomatic placement of entities and relations in complex models such as use case diagramsis not trivial to implement.

• Extendable: DOORS can be integrated with other IBM products or tools that rely onOSLC data sharing specifications. The base functionalities of DOORS can also be extendedusing the DXL scripting language, which is specifically developed for this purpose. In thisthesis work, we are interested in adding variability support to DOORS through DXL plugins.Variability support is necessary for developing product lines, but it is not inherently supportedin the base tool. DXL is similar in syntax to languages such as c or c++, but it is interpretedinstead of compiled. DXL enables users to implement user interfaces and interact withthe hierarchical database programmatically. The are several ways DXL programs can beemployed. Smaller programs can be typed into and executed directly from an editor windowin DOORS. More extensive programs are better suited to be saved into files that can beexecuted from the editor window or as an option in the default menu in DOORS.

• Export and import: DOORS can populate modules by importing data from other appli-cation artifacts, such as word documents. Similarly, DOORS also allow the content of formalmodels to be exported into different formats. The amount of information that is exported orimported is also customizable. DXL enables users to define their own output by parsing themodule content and writing it to external files.

8


3. Related Work

In this section we will review a selection of the existing knowledge on requirement engineering toolsthat support product lines. For a comprehensive list of such tools, see the systematic literaturereview performed by Pereira et al. [13]. We primarily focus on papers that utilize use cases or relyon the requirement engineering tool used at Alstom. The publication dates of the related workwe discuss range from 2005 to 2018. We have identified other works that investigate product lineengineering approaches that utilize use cases, such as the FeDRE approach that was proposed byOliveira et al. [14, 15]. However, we did not include their work in this section since they did notimplement any tool support for their approach.

3.1. PUMConf

Hajri et al. [16, 17] have created a tool called PUMConf, which supports the creation and main-tenance of domain models and product line use cases. These models can then be used to gener-ate product-specific domain models and use cases. The tool is integrated with the requirementmanagement tool DOORS and performs the generation based on the user’s configurations and atransformations ruleset implemented in Java. The tool automatically performs several consistencychecks to examine whether the created use cases and domain models are valid. The tool checksif product line use cases adhere to the RUCM template [18], which is a use case template thataims to reduce ambiguity by introducing a more restrictive ruleset. It also checks whether theproduct line use case diagram and domain model correspond to those specifications. The tool’sfeasibility was evaluated using a case study in an industry context. In this case study the authorsmodeled product line use cases for a ”Smart Trunk Opener,” an embedded real-time system, whichthen were used to generate product-specific use cases for four clients. Analysts from the companythat produced the system verified that the PUMConf tool’s output was accurate to the consideredsystem. The output was further evaluated by conducting semi-structured interviews with sevenparticipants who were experienced in software engineering. The participants also answered twoquestionnaires, which enquired about the tool’s modeling method, expressiveness, adoption effort,and how it compared to current practice. This evaluation showed that the tool was practical andthat the adoption effort was reasonable, but they also stated that further training was necessaryto become familiar with the tool.

3.2. DREAM

Moon et al. [19] has created a tool called DREAM that can provide functionality for creatingand managing requirements. The authors create product line use cases that contain ”primitiverequirements,” which they define as transactions that impact an external actor. These primi-tive requirements are building blocks that can be combined to form more complex requirements.The primitive requirements can be assigned relations amongst themselves, and they can also con-tain variability points. The primitive requirements are then mapped to a use case diagram thatrepresents the product line. The relationships between use cases and primitive requirements aredocumented in a ”PR-use case matrix” where the commonality and variability of the product lineare presented. The authors’ approach describes two different categories for product line use cases,namely ”common” and ”optional”. The former describes the product members’ commonality, whilethe latter describes the product members’ variability. The tool does not support modeling of usecase diagrams and instead relies on importing and exporting models from any third-party modelingtool that supports XML files. Once the product line use cases have been created and importedinto DREAM, they can be used to configure product-specific use cases. The authors’ approach foridentifying and specifying requirements was evaluated in an industry case study where a productline for e-Travel Systems was developed. The developers of this product line assessed that theDREAM approach reduced the overall development effort.

9


3.3. PLUSEE

Gomaa et al. [20] have developed a prototype tool for product line engineering that is calledPLUSEE. It is developed on top of the Rational Rose tool, which provides a graphical interface forcreating models. It adheres to the PLUS approach for representing commonality and variabilityin the product line. The product line’s characteristics are defined using a multiple-view model,which is a combination of several UML models. One of these is a use case diagram, which capturesthe product line’s requirements. The additional models allow the user to define other aspectsof the product line, such as its architecture. The tool performs automatic consistency checksto ensure that the different models do not contain contradictions. If the multiple-view model isconsistent, it can be used to derive product-specific requirements and architectures. The tool wasevaluated in two industry case studies where product lines for an electronic commerce system and afactory automation system were developed. The evaluation was based on six validation proceduresspanning from the product line’s creation to the derivation of individual products.

3.4. PLUSS toolkit

Eriksson et al. [21, 22, 23] have developed an approach called PLUSS to manage natural-languagerequirements specifications in software product lines. Their approach is based on the creation ofa use case model that describes the functional behavior of the product line. However, the authorsrely on a FODA model to represent the product line’s variability and commonality instead ofextending the use case diagram. The authors also introduced a new type of relationship thatrepresents ”at-least-one-out-of-many” relations that are not part of the standard FODA notation.The nodes and leaves in this model represent features that can be mapped to use case diagramsand specifications to describe their functional behavior. The use cases adhere to the RUP-SE ”flowof events notation,” which is written in tabular form to describe the scenario steps. Each step hasan identifier, a description of the actors’ actions, a description of the system’s response, and a”blackbox budgeted requirement” that binds non-functional requirements to the interaction. Thevariability is expressed in the step identifier, where different notations indicate if the step is optionalor mandatory. The notation can also express whether a choice is mutually exclusive if multiplebehavioral differences are contained in a step. The authors use the concept of parameters in usecases to express the system’s variability further. Local parameters are contained in individual usecases, while global parameters are contained in the FODA model and are accessible for multipleuse cases. The method for creating the use cases and transforming them is implemented in thetools DOORS and Rational Rose using extension scripts. This collection of extensions are referredto as the PLUSS toolkit by the authors. DOORS does not inherently support graphical modeling,so the use case specifications are created with textual templates. Rational Rose provides a way tobuild and instantiate graphical feature models and use case diagrams. The PLUSS approach andits supportive toolkit were evaluated in a case study where two product lines within the automotivedomain were developed for the Swedish Defense industry. The authors collected data from multiplesources during this case study. They examined documentation from the project’s early phases toidentify whether their approach was used correctly. Participant observations were transcribedduring the model analysis process, where the authors acted as instructors on the PLUSS approach.At the end of the case study, the authors collected information about the participants’ experiencewith the approach using a questionnaire and interviews. The evaluation revealed that PLUSSperformed better than the ”clone-and-own” reuse of requirements, which the defense contractorsresponsible for developing the two product lines had used in previous projects.

10


4. Case study design

We used a research method called case study during this thesis work. Case studies enable theinvestigation of research questions within an industry context, where variables that influence theoutcome cannot be controlled. Runeson and Host [24] have created a set of guidelines on how toplan and conduct case studies. They advocate five essential processes that need to be performedduring a case study: Case study design, preparation for data collection, collecting evidence, analysisof collected data, and reporting. We have tried to capture these processes in the workflow we usedduring the thesis work. Furthermore, the structure of the thesis report is also based on theirrecommended arrangement of sections for documenting case studies.

Figure 7: Overview of the study’s context, case and unit of analysis.

4.1. Research question

The research questions for this thesis is

RQ1: How to specify commonality and variability information in use cases of product familiesand how to enable derivation of product specific use cases.

RQ2: Does the implemented tool aid stakeholder collaboration?

This thesis work explored how product-specific use cases can be derived from a specific productline use case using a tool. Another important aspect was exploring whether this approach couldimprove stakeholder collaboration during the use case specification process.

4.2. Case and subject selection

The context of this case study is Alstom, which is an international company that develops prod-ucts within the railway transportation domain. The objective of a case study defines what theresearchers expect to achieve with the research. Our case study’s objective is to investigate how toimplement tool support for writing product line use cases and deriving product-specific use cases.The rationale for this objective is that use cases have proven to be an effective medium to capturefunctional requirements for single systems [5], and several proposals have been made to extendtheir functionality to be able to express the variability of product lines requirements [6]. However,many requirement engineering tools are primarily focused on the management of single systems.Consequently, there is a need for tools that can manage the variability of product lines.

The term case in this research method refers to things such as a phenomenon, individual,project, organization, or process that will be investigated in its real-life setting [25]. The case cancontain units of analysis that further define the foremost object of interest in the study. The casein this study is the specifications and requirement management tool used by Alstom. The unit ofanalysis in our case is how the tool’s base functionality can be expanded to support product lineuse cases. We are also interested in this approach’s collaboration aspect since the developmentprocess of product lines usually involves communication amongst diverse stakeholders.

11


4.3. Data collection procedures

A literature search often precedes a case study, where peer-reviewed articles are used to assist theresearchers in understanding the investigated topic [24]. Therefore, our initial focus was gatheringpeer-reviewed information regarding related works, use case specifications, product lines, func-tional requirements, and existing requirement engineering tools that support variability. We alsoinvestigated how the functionality of the company’s current requirement engineering tool, whichis called DOORS [11], could be extended with support for writing specifications for product lineuse cases. We conducted this investigation by working with the tool, reading its documentation,and comparing its functionalities with the investigated concepts. Finally, once we had reachedan initial understanding of the investigated research area, we outlined the objective, collectionmethods, analysis methods, and countermeasures against validity threats.

To make the tool support as realistic as possible, we created product line use cases using reverseevolutionary engineering [4] on specifications from a family of products provided by Alstom. Thisanalysis of archival data provided information on how to capture behavior requirements typicalwithin this domain, which was then used during the implementation phase. We also inquiredstakeholders at the company about potential collaboration features during the development of thetool.

The tool was evaluated using a questionnaire that contained a combination of closed and open-ended questions. Our rationale for choosing this method is that it does not require much effortfrom the participant, potentially increasing the number of stakeholders willing to partake in thestudy. The number of available participants was limited, which meant that it would be difficult toonly rely on quantitative data when evaluating the tool [25]. Therefore, we also decided to collectqualitative data, which does not necessarily require many participants while still providing rich anddescriptive answers to research questions. In total, we were able to identify sixteen stakeholdersin the company whose tasks were associated with requirement engineering, which meant that theybelonged to a demographic whose work could potentially be improved by the tool. Of these,ten responded that they were willing to participate in the study. The participants watched ademo video before answering the questionnaire, which contained information regarding the tool’sfunctionalities and concepts.

4.4. Analysis procedures

The majority of the questions were closed-ended and were answered with a five-point Likert scale,which is easy to interpret. These questions are formulated as statements, which the participantcan answer by checking one of the five scale points (strongly disagree, disagree, neither agree nordisagree, agree, or strongly agree). The most common way of analyzing responses to these types ofquestions is to visualize them [26]. We have chosen to visualize the data using a diverging stackedbar chart that displays the percentages for the responses. The responses are divided alongside acentral line. The responses that disagree with the question are placed on the left side of the centralline. The responses that agree with the question are placed on the right side of the central line.Finally, the responses that neither agree nor disagree are placed directly on the central line. Thistype of graph makes it easier to distinguish the differences among the Likert scale questions.

The three last questions in the questionnaire were open-ended questions, which the participantsanswered textually. These questions allow the participants to express their opinions more freely,but they are also more challenging to analyze. We decided to analyze these questions by manuallycategorizing them into groups based on the similarities in their statements. This method is time-consuming but can produce accurate results. Some tools allow this process to be performed semi-automatically, reducing the time needed to categorize the responses. However, this was unnecessaryin our case since we only had ten participants. There is always a risk of introducing author biaswhen interpreting qualitative data. Therefore, we included the individual responses for all the open-ended questions in the report. This allows the reader to form their own opinion based directlyon the participant responses. The only thing altered with the responses is the anonymization andminor grammatical corrections.

12


4.5. Validity procedures

The chosen collection methods involved human participants, which entailed that certain ethicalconsiderations had to be considered [24]. Participants were informed of the purpose of the casestudy, that their participation was voluntary and that they could withdraw their participationfrom the study at any point. We also inform the participants that data that could be used toidentify individuals will be anonymized. Besides the ethical considerations, this also increasesthe likelihood that participant shares their honest opinion without being concerned with ulteriormotives. When distributing the questionnaire, we took precautions not to disclose the identities ofthe stakeholders that had been invited to participate. This precaution can reduce the likelihoodof the participants’ opinions being influenced by other participants or group dynamics.

We emphasized making the questionnaire easy to understand to ensure that the participantscould answer the questions accurately. The questions were reviewed in two separate sessions by thethesis supervisors before the questionnaire was distributed to the participants. We also encouragedthe participants to contact us if they had any questions about the questionnaire, video, or tool inthe closing section of the demo video.

Weekly meetings were held with the supervisor throughout the majority of the study. Duringthese meetings, we discussed the progress of the case study and potential validity threats. Inaddition, the selection of the use case template and the implementation of the tool support wasperformed with real specifications from the domain in mind, minimizing the threats to the study’sexternal validity.

5. Results

In this section of the report, we describe the steps taken during the case study. This includes theprocess of selecting a use case template, the implementation decisions for the tool support, andthe evaluation process using a questionnaire.

5.1. Selection of a use case template

To understand the type of variability and commonality that needs to be captured within thisdomain, we decided to create product line use cases based on specifications from a system developedat Alstom. This process also allowed us to identify a suitable use case template for the tool, and italso provided us with an example to show during the evaluation of the tool. To this end, we hadaccess to specifications for a passenger alarm system from three product family members providedby the case study company. In addition, we also had access to UML activity diagrams from oneproduct family member, which clarified the order of events in more detail.

The specification was originally documented in DOORS using natural language sentences andparagraphs. Each requirement paragraph was divided into shorter sentences, each of which con-tained a single requirement to simplify the identification of the common and variable characteristics.These were then exported to an excel file where the columns represent the individual product linemembers, and the rows contain their similar requirements.

The requirements were then categorized into four different groups based on their commonalityand variability. The groups consisted of identical requirements, requirements that contained smallvariations, requirements that contained major variations, and requirements that only were presentin a subset of the product line members. The groups were labeled with different background colors,and the varying specification text was colored red. We then tried to identify external actors thatinteracted with the system and their goal for initiating those interactions.

The specification did not contain any structured variability information, so we had to refine theuse cases incrementally as our understanding of the passenger alarm system’s common and variablebehavior increased. The requirements from the specification were written in the traditional formatwith unambiguous statements with keywords such as ”shall”, ”will” and ”must.” However, usecase specifications are usually written in a narrative format where the system’s interactions withactors capture its expected behavior. Therefore, when creating the product line use cases, we hadto rewrite the requirements into a narrative format while maintaining the underlying meaning.

13


Once we identified the system’s commonality and variability, we considered what type of usecase template would be most suitable for the tool. We examined several templates describedin academic literature. A systematic mapping study and controlled experiment by Santos et al.[6] identified 12 different product line use case templates from previous academic papers andcompared them in terms of their comprehensibility. The authors categorized the templates intodifferent categories depending on their method for expressing variability and commonality. Onetemplate from each category was then chosen to be used in the experiment. During the experiment,participants defined the variability of a product using the templates. The authors assessed thecomprehensibility based on how long it took for the participants to write the use cases and howaccurate they were to the original specifications. The result showed that the template proposedby Eriksson et al. [21], which express variability in the step identifiers, required the least amountof time and was the most accurate. The template proposed by Gomaa et al., which expressesvariability in a separate section of the template, also performed well in the experiment. However,the result of their mapping study might not be generalizable to an industry setting since mostparticipants were graduate or undergraduate students and the use cases that were created in theexperiment were simple in terms of size and complexity due to time constraints.

Ultimately we decided to follow Gomaa’s use case template since it defines variability in aclear way, and its usage was well-documented [27]. However, we decided to make some deviationsfrom the template to suit the need of our tool support. The reason for changing some featuresof this template was to simplify the process of binding variability, allowing more stakeholders toparticipate in the decision-making process when deriving product-specific use cases.

We wanted to make the binding of variability as easy as possible to avoid confusing stakeholderswithout much experience in product line engineering. Therefore we decided to merge the ”optionalalternative” and ”mandatory alternative” variation point categories into a single type called ”alter-native”, which asserts that zero to one of the options should be chosen. Furthermore, we decidedto use tags to refer to the variation point directly inside the interactions. Gomaa’s original ap-proach [27] uses a section inside the variation point to refer to interactions. Our intention with thischange was to avoid having the stakeholders manually write or copy-paste the updated informa-tion when binding the variability. The tags inside the interactions can easily be replaced with thecontent of the variability point programmatically. In contrast, the original approach relied on thestakeholders manually updating the interactions by hand, which risks introducing inconsistenciesin the specification. The usage of tags in the interactions is inspired by several of the templatesevaluated in the mapping study and experiment performed by Santos et al. [6], who used tagsto define variability. The result of this study showed that the understandability of this approachwas high. The last change we made was excluding the question section of the use case template.Our reason for this decision is that DOORS already provides a built-in discussion section that canbe associated with any objects, which can be used when stakeholders discuss the specification ofactors or use cases.

Some of the requirements were non-functional, which broadly means that they describe non-behavioral aspects of the system. Use cases primarily capture functional requirements, where thesystem’s behavior is expressed as a series of interactions between the actors and the system [5].The actors provide stimuli to the system (input), and the system responds accordingly (output).However, non-functional requirements do not have this stimulus-response relationship. Thereforeit can be challenging to express non-functional requirements in the narrative interactions betweenthe actor and system. The Rational Unified Process (RUP) attempts to overcome this problemby attaching non-functional requirements to the use cases whenever possible and otherwise doc-umenting them as separate artifacts called supplementary or special requirements. The productline use case template proposed by Eriksson et al. [21] binds non-functional requirements relatedto quality attributes such as performance, usability, and security directly to individual use casesteps. Similarly, a paper by Nguyen [28] proposes an additional section in Gomaa’s use casetemplate to capture non-functional requirements related to quality attributes. This additionalsection is documented in the use case similar to the variability points. We decided not to includea separate section for non-functional requirements since we were concerned that it would obscurethe template with too much information. We reasoned that the variation points could containnon-functional requirements when suitable, and otherwise, these kinds of requirements could bedocumented separately. The result of the reverse engineering process is shown in figure 8.

14


Figure 8: Use case diagram of the passenger alarm system, modeled after the PLUS approach.

We identified the following actors in the specifications of the passenger alarm system:

• Passenger: This mandatory actor represents persons that are traveling in the railway cars ofthe train. In case of an emergency, which could pose an immediate risk to health or property,passengers should report it to the staff so that they can take appropriate action. The railwaycars are equipped with passenger alarm devices (PAD), which activate a passenger emergencyalarm (PEA) when operated. Once the responsible staff has acknowledged the PEA thepassenger can report the hazardous situation through an intercom on the PAD.

• Train operator: This mandatory actor is the staff member that operates the train fromthe driver’s cab. In the case of a PEA, the train operator’s responsibility is to assess theemergency through the camera footage and communication with the passenger and thentake the appropriate actions. The train operator works from a console that is located inthe driver’s cab. This actor’s goals and responsibilities did not deviate much amongst theindividual product family members, at least within the context of the passenger alarm system.

• Operation Control Centre (OCC): This optional actor is a centralized location where theoperations of multiple trains can be monitored, analyzed, and directed. The responsibilityof this actor varies between the individual product family members. Some of the productfamily members support unattended train operations (UTO), where certain functionalitiesdo not require direct staff involvement or can be operated from a remote location. Therefore,the OCC interactions can either be similar to the train operator or more of an advisory role.

• BCC: This optional actor is similar in its role to the train operator and OCC. Unfortunately,the passenger alarm system specification, which we based the use cases and actors on, did notprovide further explanation on its abbreviation or how it differs in responsibilities comparedto the train operator and OCC.

15


• Train control and monitoring system (TCMS) This mandatory actor is an externalsystem responsible for controlling and monitoring equipment and processes on the train.TCMS logs information regarding the activation and clearing of the PEA.

• Closed-circuit television (CCTV) This mandatory actor is an external system of camerasthat broadcast video surveillance to a limited number of monitors. Each cab is equipped withseveral CCTV cameras used to transmit recordings of PEA activations’ location to the trainoperator so that the appropriate actions can be taken.

• Emergency brake: This optional actor is an external system designed to stop the train asquickly as possible if the train operator or other responsible staff fails to acknowledge thePEA within a specified deadline.

We identified the following use cases in the specifications of the passenger alarm system.

• Activate PEA: This kernel use case describes how the passenger activates the PEA byoperating a PAD, which should be performed when the passenger perceives a potentiallyhazardous situation. The train operator is informed of the PEA activation by a sonic alarmand automatically receives camera footage and location information from the PAD location.A visual indication is also displayed on the exterior of the affected car. An optional varia-tion point determines whether OCC and BCC are additional recipients of the sonic alarm,surveillance footage, and location indication. Another optional variation point determinesif the PAD should include multilingual support, where the choices are English, Hindi, andMarathi.

• Acknowledge PEA: This kernel use case describes how the train operator acknowledges theactivated PEA, which terminates the sonic alarm and lights an indicator at the PAD location.It also describes how the train operator can switch amongst different communication channels.An optional variation point determines whether OCC and BCC are able to acknowledge thePEA.

• Communication with passenger: This kernel use case describes how the train operatordeactivates the sonic alarm and initiates bi-directional communication with the passengerthat activated the PEA. An optional variation point determines whether OCC and BCC caninitiate communication with the passenger.

• Reset PEA: This kernel use case describes how the train operator can clear the PEA, andthe associated indicators are deactivated. An optional variation point determines whetherOCC and BCC is able to reset the PEA.

• Display PEA origin: This kernel use case describes how the CCTV automatically sendsrecordings from the PEA origin to the train operator if a passenger operates a PAD. It alsospecifies that the date, time, camera ID, and location event stamping should be included inthe recordings. An optional variation point determines if additional information should beincluded in the recordings, where the options are train ID, rake ID, Geographical location,and PAD location. Another optional variation point determines whether OCC and BCC arealso receiving the CCTV recordings.

• Log all PEA events: This alternative use case describes how the TCMS logs PEA activa-tions and clearances with timestamps. The TCMS is also provided with the current statusof each PAD. An optional variation point determines whether acknowledgments from OCCand BCC are logged as well.

• Log all PEA events after deadline: This alternative use case describes how the TCMSlogs PEA activations and clearances with timestamps if the train operator fails to acknowl-edge the PEA within a specified time. The TCMS is also provided with the current statusof each PAD. An optional variation point determines whether acknowledgments from OCCand BCC are logged as well.

• Emergency brake after deadline: This optional use case describes how the emergencybrake is activated if the train operator fails to acknowledge a PEA within a specified time.

16


• Change recording speed: This optional use case describes how the CCTV camera record-ing speed increases after the activation of a PEA.

• Creation of historic data: This optional use case describes how the CCTV creates abackup of recordings that spans a specified time before and after the PEA event.

5.2. Identifying stakeholder collaboration

Before starting the tool implementation, we had to identify what type of collaboration the stake-holders at the company desired. We initially considered using a formal method for collectingthis information, such as a questionnaire. However, we found it difficult to formulate questionsthat would restrict the answers to the thesis’s scope, especially since collaboration has a broaddefinition. So instead, we decided to identify potential features through discussion with softwareengineers at Alstom. This informal method allowed us to collect suggestions that guided the initialdirection of the implementation:

• Overview: During the discussion with developers from the company it was brought upthat it would be good if the tool provides an overview of the content to aid stakeholdersin overseeing what has been produced. While this can be interpreted in various ways, weunderstood it as providing a summary of the use case information in a format where thedetails are hidden. The related works discussed in the previous section achieved this usinguse case diagrams, feature models, or textual matrices.

• Printable: Not every stakeholder will necessarily have access to DOORS, and some stake-holders prefers to work with physical documents instead of within the tool itself duringthe review process. Therefore it would be good if the tool could export the content into aprintable format, such as a word or pdf file.

• Use case and reuse guidance: Not all stakeholders are familiar with use case concepts.Therefore, it would be good if the tool support includes information and guidance to avoidcommon pitfalls. A mapping study by Barros et al. investigated the impact of use cases inreal-world software projects [29], including commonly reported advantages and disadvantagesof this approach to capture functional requirements. The most frequently reported issueswere related to the inconsistent granularity of the use cases and the incompleteness andincorrectness in the natural language scenario descriptions. A similar work by Tiwari andGupta investigated the learnability and comprehension aspects of different use case templatesby performing two controlled experiments [10]. The result of the experiments indicated thatuse cases with a higher degree of formalism and restricted use of natural language resultedin better comprehension and learnability. Therefore we deem it reasonable to implementan interface to guide stakeholders to adhere to the rules of the use case template and beconsistent when defining the scenario description and binding variability.

• Graphical representation: Graphical models such as could help improve the overall read-ability, at least to some extent. However, models which use a high number of elements intheir graphical notation become less readable according to the ”principle of graphic economic”proposed by Moddy [30]. The author argues that this principle affects novices to a higherdegree than experts since the former must consciously maintain the meaning of the notationsin working memory. Domain models usually require numerous elements in their graphicalnotation to express common and variable features. Therefore use case diagrams might notbe an optimal way to communicate requirements amongst diverse stakeholders. A controlledexperiment performed by Reinhartz-Berger and Sturm [31] investigated UML-based domainmodels for product lines, including use case diagrams, and found that the comprehensibilitywas reduced when multiple variability specifications aids were introduced. The authors spec-ulate that the decreased comprehensibility was caused by confusion regarding the expandedgraphical notation. Therefore, a complicated visual domain model might not be a usefulcommunication artifact for diverse stakeholders.

• Stakeholder feedback: Stakeholders might identify issues related to their area of exper-tise during the review process of use cases. These issues could be expressed as comments

17


that are contained or easily traceable to the use case, which could aid the stakeholders’discussions during the review process. Some use case templates include elements to aid dis-cussion amongst stakeholders. For example, Gomaa’s use case template contains a sectionlabeled ”outstanding questions”, which contains questions that should guide stakeholders’discussions. The product line use case proposed by Braganca [32] took this concept one stepfurther by introducing each variability point with a question that guides the instantiationof product family members. An example of how stakeholder discussions can be used in thedevelopment process of product lines can be seen in the Metadoc feature modeler developedby Thurminella and Janzen [12]. This tool is an extension to DOORS that documents stake-holder discussion in a feature model to enable collaborative decision-making and capture therationale for features.

5.3. Implementing the tool

Since stakeholder collaboration is an important aspect of requirement engineering, we discussedthis topic with stakeholders that were involved in the product family we studied, which helped usget a better initial understanding of some of the company’s collaboration needs. The best option inour case was not to implement a tool from scratch since it would be time-consuming, and we wouldbe unable to achieve the same level of reliability as well-established requirement engineering tools.However, such tools do not always support the functionalities necessary to manage the variabilityof product line requirements.

A recent study by Thurimella et al. [33] proposes a set of guidelines for how variability supportcan be added to requirement engineering tools using plug-ins. A plug-in is a software componentthat can extend the functionality of the base tool. The authors argue that this approach minimizesthe required effort without negatively affecting the outcome. Alstom uses IBM DOORS (amongstother tools) to perform requirement engineering. Using this tool as a base to which we can appendthe desired functionality would have several advantages. It requires less time for the developersat the company to get used to the tool during the evaluation phase since they would already haveexperience with the tool’s functionality and interface. DOORS also features a dedicated scriptinglanguage called DXL, which can extend the base tool’s functionality. DXL is well documented, andit has been used in several related works that could be used as a source of inspiration during theimplementation phase. However, not all stakeholders will have access to DOORS or experience inproduct line engineering. Therefore we decided to divide the tool into two collaborating parts inaccordance with the domain engineering and application engineering division of responsibilities[4].The workflow between the domain and application parts of the tool can be seen in figure 9.

Figure 9: The workflow of the tool.

The first part of the tool is an extension to DOORS responsible for creating and maintainingthe product line use cases and actors, see figure 10. Initially, we were unsure how to representthe use cases inside DOORS, and we experimented with three approaches. First, we tried to havemultiple objects (i.e., the rows) represent the different sections of the use case template. However,

18


this approach was impractical since it took too much time to create so many objects, and it wasnot easy to keep track of where one use case ended and another began. So instead, we attemptedto represent the use case sections in the attributes (i.e., the columns). This approach allowed theuse case to be contained within a single object, making it easy to track its sections. However, anotable drawback of this approach was that it became difficult to view the entirety of the use casespecification. The sections occupied more of the available screen space when they were containedin the attributes since they were stacked horizontally instead of vertically. This caused some ofthe sections to disappear beyond the computer screen’s edges.

Ultimately we decided to keep the use case contained within a single object that has twoattributes. The first attribute is called Type, and it assigns the object as either a use case oran actor. The second attribute is Text, which contains the different use case sections in textualformat. To separate between the individual sections in the Text attribute, we use tag-value pairs.This approach allowed us to stack the use case sections horizontally while still containing themwithin a single object. The only drawback was that it became more complex to parse the contentof the use case when exporting it from the DOORS extension. The actors and use cases can beexported into JSON format, which the other collaborating part of the tool can read. We choosethis format because it is easy to serialize and deserialize, and it is also human-readable, makingdebugging possible.

Each section in the template has a corresponding tag. The objects that represent use cases alsocontain an additional tag called group that is used to divide the use cases into groups. We use squarebrackets to define the available options in variation points, where brackets enclose each option.Square brackets are used similarly to define references to variation points in the interactions.The actors are also defined using tags, but they do not contain any variable information. Theextension must also distinguish between subitems in some of the tag-value pairs to parse thecontent successfully. Therefore certain characters are reserved for separating individual items inthese sections. New lines are used to separate the interactions and variation points, while commasseparate the actors and dependencies.

Figure 10: Use case specification as presented in DOORS.

19


The third-party application interface, see figure 11, is implemented in the open-source engineGODOT using the coding language C#. This application is responsible for presenting the variablefeatures and then deriving product-specific use cases once the user has selected their preferredchoices.

A configuration menu is placed on the lower-left side of the application’s interface. This menuprovides the user with several functionalities. The user can import use cases and actors that havebeen exported from the DOORS extension, which are stored in the JSON format. The user can savetheir current selection of use cases and variation points from this menu. This updates the relatedJSON file, and the selected options will be the same when the user loads the file the next time. Theuser can export the content to a document containing product-specific use cases or product lineuse cases, depending on the user’s choice. As mentioned before, the difference between the typesof use cases is that the product line version contains variability information and shows all availableoptions. In contrast, the product-specific version only displays the selected options and doesconsequently not contain the reuse category or variation points fields. Lastly, the user can exporta UML use case diagram that provides an overarching view of the system’s expected behavior.This will open a new window where the diagram is generated. The relations between actors anduse cases are already assigned in the diagram based on the imported specification. However, theplacement of the use cases and actors is only preliminary when the diagram is generated, andthe user should drag them to a more readable position. The application prevents the user fromaccidentally overlapping the position of two or more entities in the diagram or placing entitiesoutside the borders of the diagram.

Figure 11: Use case specification as presented in the application interface.

20


The imported actors and use cases are presented in two lists on the right side of the interface,see figure 11. The user can determine which optional and alternative use cases they wish to includeby pressing the icon that precedes their names. If the text is grey and the icon depicts an X, theuse case is not selected. If the text is white and the icon depicts a checkmark, the use case isselected. The use cases are sorted into their categories and groups, and the application enforcesthe rules of the reuse categories.

The user can determine which options in the variation points they wish to include by pressingon the icons inside the description section of the variation point. Each choice is preceded by anicon that either depicts an X or a checkmark. If the text is grey and its icon depicts an X, theoption is not selected. If the text is white and its icon depicts a checkmark, the option is selected.White text will be inserted into any interactions that refer to that variation point, while the greytext is omitted in the updated interaction. If no option is selected within a variation point, itscontent will not be inserted into any interactions. For an example of the differences between theproduct line use case and a derived product-specific use case, see figure 12 and 13.

We added visual cues to help the stakeholders identify the connections between the referencesand variation points. For example, if the user hovers the mouse over the variation points in theapplication, the font color of the corresponding references will shift between their standard colorand blue. The same effect is applied to the variation points if the mouse hovers over references.We also make use of tooltips to guide the user during the configuration process.

Figure 12: Example of a configured product line use case.

21


Figure 13: Example of a derived product specific use case.

5.4. Evaluation using a questionnaire

Initially, we considered evaluating the tool by inviting all participants to a hands-on session withthe tool and then performing a group interview regarding their initial impression. However, severalfactors made this approach less viable, which ultimately led us to choose another data collectionmethod. For example, it was impossible to gather a large group of people in one location duringthe case study due to restrictions enforced due to the Covid-19 pandemic. It would have beenpossible to have an online meeting, but it would have been difficult to arrange a hands-on sessionbecause the tool has some prerequisite conditions that need to be fulfilled before the tool works asintended. For example, the DOORS extension requires permission to execute DXL scripts in thecompany’s preproduction environment, which all participants did not have. Furthermore, findinga suitable meeting time for all participants would have been difficult since it would have takenplace close to the annual Swedish vacation period.

Therefore, we decided to collect feedback on the tool using a questionnaire accompanied bya demo video that explained the tool’s functionality and concepts. One reason for choosing thisdata collection method is that it does not require as much of the participants’ time, and it canbe answered at a date and time they find suitable. We reckoned that this would increase thenumber of people willing to participate in the study. The questionnaire we created consists offifteen questions which can be divided into three sections, see appendix A.

The initial section has six questions regarding the participant’s background and experience. Thetwo first questions are used to identify participants by inquiring about their name and positionwithin the company. Since this is personally identifiable information, it will not be included in thethesis report. Instead, we will refer to individual participants using numbers. The other questionsin this section were answered using a Likert scale, see figure 14.

The second section has six questions that inquire about the participant’s initial impressionof the tool, focusing on the understandability and ease of use. Similar questionnaires used suchattributes to evaluate the usefulness of a tool. An example of this can be seen in the evaluation ofa tool developed by Silva et al. [34] who reasoned that users are more likely to adopt a tool theyperceive as easy to understand and use. We are also interested in this aspect because it should be

22


as easy as possible for diverse stakeholders to bind variability in the use cases in the tool. Thesequestions were answered using a Likert scale, see figure 14.

The third section has questions about the tool’s collaboration potential, whether the providedmethods can adequately express a product line’s commonality and variability, and if the partici-pants have improvement suggestions on the tool. These open-ended questions were answered in atextual format. We encouraged the participants to define their definition of collaboration since itcan have different meanings depending on the stakeholder’s role. The individual answers to thesequestions can be seen in table 1, 2 and 3.

We were uncertain how familiar the participants would be with use cases and product lineengineering concepts. Therefore, we decided to briefly introduce these concepts in the demo videobefore describing the tool’s workflow. At the end of the demo video, we also encouraged participantsto contact us via email if they had questions regarding the video, questionnaire, or tool. Two ofthe participants contacted us regarding this, and an online meeting was held where the tool wasdiscussed in further detail.

Figure 14: Questionnaire result for question 3 to 12.

23


Question 13: Do you think the tool could be used to improve collaboration between stakeholdersin the project? Feel free to think about or define collaboration depending on your role andunderstanding.Participants AnswersParticipant 1 UseCases are an effective way to capture the scenarios and scope, which the

stakeholders have. And absolutely are a vehicle to improve stakeholder com-munication. In particular in identifying interfaces, and dependencies whichare spanning over these.

UseCases interact between functional and operational architecture, with moreweight in the context of the latter one. This is a formidable vehicle for Front-end analysis on each system level. Ie. not only top end user level, but onsystems, subsystems...

But a distinction needs to be what is ’analysis’ vs ’asset’ - and a ’delta onthat asset’... UseCases drive mostly the ’delta’, and that within the scope ofthe scenarios which involve the project in general. Assets bind accumulated,aggregated, system, and have by definition broader base and scope than anyproject per se would represent.

This is where UseCases play a role for Risk Management. It is possible to”easily” recognize dependencies beyond ”regular” top-down system analysis.This because, one includes multiple architecture views in the context of Use-Cases (operational, functional, logical, physical...). And their stakeholders.In a natural dialogue and setting.

And that makes usecases a very effective method for analysis - and commu-nication method.

Participant 2 Yes, I think the tool will help in the collaboration between different stake-holders.

Participant 3 No, my experience of standardilisation/modularisation using the Doors toolis that organisation and people first need to decide an formulate the processesand interfaces. Since the 80‘s management always believe that a new tool willsolve their problem

Participant 4 I am not sure the tool itself will improve collaboration but Use case diagramsare usually good to share between stakeholders provided that the stakeholdershave basic understanding of UML Use Cases. This is not the case that often.

Participant 5 Yes, I absolutely think so. Coming from old Bombardier I miss this aspectin our line of work. I think it would clarify both internally and in commu-nication with customers what they will get. It will both make requirementmanagement easier and validation.

Participant 6 Yes, as use cases are easy to understand even for non technical persons.Participant 7 Well, it has potential. Open questions for me are traceability, the learning

curve and the alternative tools that exists. However, this tool seems to bevery easy to use :-)

What I would like to see is an example that is more mechanical (electrical)that function oriented. For example a gearbox...

Participant 8 Strongly agreeParticipant 9 It could be used to reduce the amount of copy and paste we currently do with

requirements in DOORS. I would however need to understand how configu-ration management is foreseen of the use cases to determine how useful thistoll would be in the longterm.

Participant 10 Yes, in general use cases is a good way of specifying behavior in way thatmost stakeholders can understand it. And variability points it also importantto visualize and describe them.

Table 1: Questionnaire result for question 13.

24


Question 14: The tool allows the user to define variability through two methods. The firstmethod is the reuse category, which enables the selection of use cases. The second method isthe variation points, which enables the insertion of options inside the interactions of a use case.Do you think this degree of variability in the tool is sufficient to express the differences betweenindividual products in a product family?Participants AnswersParticipant 1 The concept here could be refined to take into account that an UseCase is

a scenario dependent method, with a narrower scope, whereas a Capabilityrepresents Assets, and the total specturum (i.e. multiple usecases) of ”whatthe existing system can provide”. So, if the assets are represented as UseCases,then there is a risk of fragmentation, and overloading with usecases. However,this may be only a topology issue, and question of how to consolidate notationfor describing Assets, rather than scenarios only.

But, I would really like to emphasize, that the concept of Variability, andhow the Product Family mgt is understood, is very well represented in thestudy, and in the way the tooling approaches it. But, this can be ’evolved’ inthe sense that a UseCase (new such) represents ’a kind of’ delta towards theCapability Assets.

Participant 2 I think that the tool provides enough means for defining the variability.Participant 3 I believe it will be difficult to describe the complexity (details of variability).

We have tried to standardize our product portfolio but in reality every newproject end up with new and modified design , i.e. filling the bucket with newplatform products (I suppose correspond to feedback loop).

Participant 4 I don’t fully understand the variability aspect of the tool. It would have beengood to show more Use case diagrams and explain the variability aspects inmore detail in the video. At this point I am not sure what this tool doesdifferent than for example Visio.

Participant 5 At least from my experience I think so. To over complicate the tool with justmake it difficult to use.

Participant 6 YesParticipant 7 I would like to see an example with several layers where building blocks, i.e

subunits/sub functions that are used on more than one place.

I also would like to see and example with systems of systems with one topsystem using three sub systems that also use sub systems.

Participant 8 YesParticipant 9 In most cases it will be sufficient but not in all cases (e.g. when selecting

a different technical solution which more dramatically changes the productfamily solution).

Participant 10 Almost. Perhaps there could be a better way of declaring that one or morecomplete steps are included only in one variant. A convention how to specifythis can be an option, but when generating the application specific variant itcould be important to hide the not-selected steps.


25


Question 15: Are there any changes or additional features that you would suggest to improvethe tool?Participants AnswersParticipant 1 Dependencies: these could be represented as outgoing link towards those

artefacts one is dependent of. The out-going link becomes an ’incoming-link’ at those artefacts one is dependent of - and thus these cannot be deletedwithout resolving the link first.

Topology and context sensitiveness: The representation of Assets - vs changesto these. Capabilities vs UseCases... ;)

Participant 2 no.Participant 3 Not easy to suggest, first I need to understand the background and purpose

with the toolParticipant 4 It is too difficult for me to propose changes or new features. Before that I

must fully understand the purpose and usage of the tool. I must also need totry it out a bit.

Participant 5 I didn’t see the clear connection between requirements and use cases. Thiswill be a hot topic for sure and before implementing it would be nice to atleast have a process in mind. Like: Are the use cases regarded as or internalrequirements? How do we map use cases to customer requirements? Or dowe simply renegotiate customer requirements upon project start to replacethem with our use cases.

In any case, the tool looks good. I think the major work bulk is in creatingthe use cases.

Participant 6 Yes, seems like there is lot of text in the tool, would prefer direct link withless text and user manuel embedded in the tool

Participant 7 This tool has potential, my concerns are included in previous responses. Thechallenge is pure::variants and Pleiade that has been operative/under test forlong time. But, they have a significant learning curve.

Participant 8 This is a good start and can improved based on the need. Appreciate thegood work

Participant 9 Configuration management needs to be included. And to really get savings itneeds to be linked to the standard solutions on the next lower level.

Participant 10 Use case template may include a section for ”Special requirements”so that the author also are guided to think about non-functionalaspects connected to the use case. These can also have varia-tion points (e.g. different timing requirements). See for instancehttps://sceweb.uhcl.edu/helm/RationalUnifiedProcess/process/modguide/md uc.htm#Special%20Requirements


26


6. Discussion

In this section, we will provide our interpretation of the questionnaire result. However, beforediscussing the participants’ responses in more detail, we will summarize their significance in regardsto the research questions.

The first research question in this thesis work, RQ1, inquired about how to specify commonalityand variability information in use cases of product families and how to enable derivation of product-specific use cases. In order to answer this question, we identified a suitable use case template fromprevious works, modified it to allow the derivation of product-specific use cases, and implementedtool support for this approach. The evaluation showed that the modified template and tool couldbe used as a vehicle for communication. The majority of participants found the template easy tounderstand and were positively inclined towards the methods provided by the approach to definevariability (reuse categories and variation points).

The second research question in this thesis work, RQ2, inquired about whether the imple-mented tool alleviates stakeholder collaboration. Since the tool is intended to be used by diversestakeholders, especially the part that binds the variability, we emphasized making the interface easyto understand. The evaluation showed that most participants considered the tool’s understandabil-ity good and were positively inclined towards the tool’s collaboration potential. Understandabilityis an important aspect of the tool since it makes it more accessible for stakeholders with limitedknowledge of product line concepts. The tool’s output does not contain the use cases and variationpoints that were not bound during the product’s configuration. This way, the stakeholders onlyneed to consider the presented information instead of the entire specification of the product line.

6.1. Participant experience

The questionnaire gave us an overview of the participants’ experience with DOORS and use casespecifications. The result showed that 50% were familiar with use case specification, 30% wereunfamiliar, and the remaining participants were somewhere in-between. The answers were rela-tively evenly spread amongst the participants, with a slight majority that felt familiar with usecase specification. However, the participants were less familiar with use case diagrams. Only40% of the participants felt familiar working with use case diagrams, 50% felt unfamiliar, andthe remaining were somewhere in-between. The participants were evenly divided regarding theirexperience with product line concepts, where 40% were familiar, 40% were unfamiliar, while theremaining participants considered themself somewhere in-between. In contrast, almost all partic-ipants felt familiar working with DOORS, and only 10% felt unfamiliar. To summarize this partof the questionnaire, the majority of participants were experienced working in DOORS. However,they were generally less experienced working with use cases, especially its diagrams and productline versions. It should also be stated that most of the participants were from work disciplinesrelated to requirement engineering or testing.

6.2. Understandability

According to the majority of participants, the tool interface was easy to understand. The resultof question 7 showed that 20% strongly agreed, 50% agreed, and 30% were neutral regarding theunderstandability of the interface. We consider this a very positive result since no participantsresponded with a disagreeing rating on the Likert scale. The interface is intended to guide theuser through the process of deriving product-specific use cases by binding variability, so it mustbe easy to understand to fulfill its purpose.

Similarly, the use case template was easy to understand, according to the majority of partici-pants. The result of question 8 showed that 30% strongly agreed, 50% agreed, 10% were neutral,and the remaining 10% disagreed regarding the understandability of the use case template. Wewere concerned whether the deviation we introduced in Gomaa’s template would make it morechallenging to understand, but it seems the template remained understandable.

Unfortunately, the participants regarded the creation process of the use case as less easy tounderstand, at least in comparison with the previous two questions. The result of question 9showed that 10% strongly agreed, 40% agreed, 30% were neutral, 10% disagreed, and the remaining

27


10% strongly disagreed regarding the understandability of the use case creation process. A possibleexplanation for this being less understandable could be that the creation process was divided acrossthe DOORS extension and the third-party application, making the overall process more complexto comprehend. A contributing factor to this is that we did not emphasize understandabilitywhen creating the DOORS extension. We reasoned that primarily product line engineers woulduse this part of the tool, who are already familiar with variability and commonality concepts. Incontrast, the application part of the tool is primarily used by application engineers, the customer,and other diverse stakeholders who might not be as familiar with these concepts. Therefore wedecided to emphasize making the application user-friendly with an interface that has tooltips,color-coded information, and visual cues. The DOORS extension lacks this level of guidance. Sothe overall creation process becomes less understandable compared to the processes performed inthe application.

The majority of participants regarded the process of defining variability through the usage ofvariation points and reuse categories easy to understand. The result of question 10 showed that30% strongly agreed, 30% agreed, 20% were neutral, and the remaining 20% disagreed regardingthe understandability of the process to define variability.

Similarly, most participants regarded the process of binding variability through the usage ofvariation points and reuse categories easy to understand. The result of question 11 showed that 30%strongly agreed, 40% agreed, 10% were neutral, 10% disagreed, and the remaining 10% stronglydisagreed regarding the understandability of the process to bind variability.

Many participants regarded the tool’s way of constructing use case diagrams as easy to under-stand. However, a sizeable portion of the participants was undecided regarding the understandabil-ity of this process. The result of question 12 showed that 20% strongly agreed, 30% agreed, and theremaining 50% were neutral regarding the understandability of the use case diagram construction.A potential explanation for why half of the participants were undecided could be that roughly halfof the participants were unfamiliar working with use case diagrams. This unfamiliarity could makeit challenging to evaluate the construction process. Another possible explanation is that the demovideo did not describe the construction process in detail, so some participants might feel that theydid not receive enough information to evaluate the understandability.

To summarize this part of the questionnaire, the overall understandability of the tool was con-sidered high among the participants. All questions that inquired about this aspect of the tool hadmore agreeing than disagreeing answers on the Likert scale. The participants that disagreed withthe understandability did not exceed 20%, while the participants that agreed with the understand-ability never receded below 50%.

6.3. Collaboration

The result of question 13 shows that most participants (1, 2, 5, 6, 7, 8, and 10) were positivelyinclined regarding the tool’s collaboration potential. In addition, some of the participants providedreasons why use cases are a suitable vehicle for collaboration. It was stated that use cases are easyto understand for non-technical stakeholders, making them good for both internal and externalcommunication. Another aspect that was brought up was that they have a wide area of usage,including requirement management, risk management, and testing. Participant 7 stated that thetool has potential and seems easy to use, but also noted that its traceability aspect, learning curve,and comparison to existing tools are still open questions.

There were also other participants (3, 4, and 9) who were more doubtful regarding the collab-oration aspect. Participant 3 argued, based on their experience, that a new tool in DOORS isnot the solution to collaboration amongst stakeholders. Instead, this participant argued that theorganization and stakeholders should establish processes and interfaces before considering whichtool to use. Participant 4 was concerned regarding the reliance on use case diagrams. This partic-ipant agreed that use case diagrams could support communication amongst stakeholders but alsostated that this requires knowledge of UML basics, which is not that common. Finally, participant9 noted that the tool would reduce the amount of copy-paste performed in DOORS. However, thisparticipant also stated that more information regarding configuration management is needed toevaluate the tool’s long-term benefits.

28


6.4. Variability

The result of question 14 shows that most participants (1, 2, 5, 6, 8, 9, 10) were positively inclinedtowards the reuse category and variation points approach to defining variability in product lines.However, some of these participants also pointed out limitations or improvement suggestions tothe used approach. Participant 1 suggested that the current approach should make a clearerdistinction between use case and capability but that the tool otherwise provided a good way todefine variability. Participant 10 stated that it could be helpful if the tool allowed entirely optionalsteps in the description and alternative section of the use case, which should be omitted if notchosen in the product-specific version. The use case template currently used in the tool onlyallows the insertion of variable information inside steps which always will appear in the product-specific version. We agree that this limitation could potentially lead to steps that are too long orsteps with unclear objectives. One way to achieve this would perhaps have been to add a similarapproach as Eriksson et al. [21], who defined entirely optional and alternative steps in their usecase template. The one disadvantage with including many ways of expressing the variability isthat the template could become overly complex, making it difficult to use. The response fromparticipant 5 also expressed this concern.

Some participants (3, 4, 7) were unsure regarding the used approach, or at the very least, didnot state if they agreed or disagreed with it. Participant 3 believed that it would be difficultto describe the details of variability, stating that there have been many attempts to standardizethe product portfolio but that each new project results in a modified design (creating a feedbackloop). Participant 4 felt that not enough information regarding the variability was provided inthe demo video to understand it fully. This participant would have liked more examples of usecase diagrams and that we compared the tool’s functionality with established counterparts such asVisio. Participant 7 would also have liked us to use more examples, suggesting two system patternsthat could have been used. This stakeholder also suggested using a system with more technicaldetails to demonstrate the tool in the previous question.

6.5. Improvement suggestions

The last question in the questionnaire provided a way for the participants to suggest general im-provements regarding the tool. Unfortunately, some participants were unable to offer improvementsuggestions. A possible explanation for this could be that we did not provide enough informationregarding the tool to allow the participants to identify areas of improvement. We decided to keepthe demo video short as not to discourage potential stakeholders from participating in the study. Inthis aspect, we were successful since about two-thirds of the invited stakeholders participated in thetool’s evaluation. However, the drawback was that we did not go into as many details. Participant2 did not provide any reason for not providing suggestions. Participants 3 and 4 stated that theyrequired more information about the tool’s purpose before being able to suggest improvements.Participant 7 referred to his responses in the previous questions (traceability and learning curve).Participant 8 stated that further improvements could be added based on the needs. The remainingparticipants provided a couple of suggestions.

Participant 1 suggested that we could rely on the built-in link functionality in DOORS totrack references between use cases and actors. The advantage of this approach is that it wouldprevent the deletion of use cases or actors referenced in the tool. This way, there would not beany references that refer to nonexistent use cases or actors. We considered using this functionalityduring the tool’s development, but we deemed it too time-consuming to implement this approachwithin our timeframe. So instead, we use a more naive approach and loop through the module(i.e., the document) and save the position and name of each use case and actor. This informationcan then be used to validate the references. However, this is a more computationally expensiveapproach since we need to loop through the module twice when exporting the content. Anotherdrawback with the current approach is that it does not prevent the user from removing referenceduse cases and actors. Instead, it can only inform them that the specification is invalid when theuser tries to export the content in the module. Participant 6 mentioned direct links as a possibleimprovement for navigation in the tool.

29


Participant 5 suggested that we define a clear purpose regarding the use cases and how theyare intended to be applied in the requirement engineering process. However, this can be difficult todefine since there exist many contradicting viewpoints regarding use cases. For example, the usecases can in themself document the requirements, or they can be used to reveal the requirements.Therefore we leave it to the end-user to decide how they wish to use the tool’s output.

Participant 6 suggested reducing the amount of presented text and embed a user manual directlyin the tool. A way to show less text in the application could be to allow the user to collapsethe sections in the use case template, so only the sections the user is interested in are displayed.Unfortunately, this approach would not be achievable in the current implementation of the DOORSextension. This is because the built-in filter in DOORS is intended to hide either objects orattributes. But each actor and use case in our approach has its sections specified within a singleobject and attribute, making it impossible to hide individual sections. The embedded user manualis also an interesting proposal, which probably would improve the ease of use aspect of the tool.The application actually has some tooltips popups, but it was not shown in the demo video sincewe considered it a minor feature.

Participant 9 suggested configuration management as an improvement feature. The tool pro-vides such functionality, but the participant further advised that it would be most beneficial ifintegrated with standard solutions. This request could be challenging to implement, but someinspiration could be taken from the related works. The tool developed by Moon et al. [19] seemsto have a very robust configuration management system, where all the individual variation pointsare stored and managed in matrices. This approach provides a way to view all variation pointssimultaneously, giving a good overview of the currently bound variability.

Participant 10 suggested an additional ”special requirement” section in the use case template toguide users to think about non-functional use cases. The participant gave an example by providinga link to a guideline for the rational unified process, which explains how this section is used. Weconsidered including something similar when we modified the use case template. However, wedecided against including such a section since we were concerned the template would be obscuredwith too much information. But since most participants were positively inclined towards theunderstandability of the template, it might have been possible to include this section withoutmaking it difficult to understand.

7. Conclusions

In this paper, we created tool support for the derivation of product line use cases into product-specific use cases. The tool consists of two collaborating parts. The first part is an extension toDOORS which is responsible for defining the variability in the product line use cases, and thesecond part is a third-party application responsible for binding variability and deriving product-specific use cases. The tool was designed with industry specifications in mind. Therefore, weidentified a suitable use case template for the tool by reverse-engineering product line use casesusing specifications from three similar products in the railway transportation domain. The selectedtemplate was also modified to allow a more streamlined approach for inserting variability points intothe interactions between the actor and system. The tool was evaluated using a questionnaire withten participants from the case study company. The result indicates that the tool’s collaborationaspect has potential, with most participants perceiving the use case template and tool to have ahigh degree of understandability. This is an important aspect since product line engineering usuallyinvolve a diverse set of stakeholders who might not have prerequisite knowledge of variability andcommonality concepts.

7.1. Limitations

Some limitations need to be taken into account when considering the result of this paper. Thethesis work was conducted on a limited timeframe, so not all suggested collaboration aspects couldbe implemented and evaluated. The timeframe also limited us to only investigate part of a productline (a passenger alarm system) when searching for a suitable use case template for the tool. So thetemplates approach for defining variability and commonality might not be ideal for other productlines, depending on their level of technicality and differences between the individual members.

30


The number of responses to the questionnaire could potentially be considered small, with onlyten participants. However, most of the participants were experienced within their respective fields,which could outweigh the relatively small number of participants. In addition, previous works havealso evaluated their tool with a similar number of participants. A prominent example of this canbe seen during the evaluation of the PUMConf tool [16][17], which included two questionnaireswith seven participants.

7.2. Future Work

While we are happy with the tool’s outcome, there is still room for further improvements and otheraspects of the tool to investigate.

A higher degree of automation during the generation of the use case diagram could be aninteresting avenue to explore in further depths, especially the placement of entities in the gen-erated diagrams. Use case diagrams can be complicated, and this can cause the introduction ofdiscrepancies between the model and the specification. This was one of the motiving factors forimplementing the generation of use case models in the tool. However, the placement of the entitiesin the diagrams our tool generates are not definitive, and it is up to the user to place them in amore readable way. The placement of use cases and actors in the diagram can also infer additionalinformation. Fully automatic placement of entities in a use case diagram is not a trivial thing toimplement, and it is still an open research question to our knowledge. Alternatively, we could tryto use a more manageable model type to visualize the commonality and variability. For example,the use case tool developed by Ericksson et al. [21][22][23] used a FODA model to visualize productlines. FODA models have a tree-like structure, making it easier to determine where the entitiesshould be placed programmatically.

Another interesting area to investigate is how the use case template could be modified to bettersupport non-functional requirements. The template does not provide a standardized way to bindthis type of requirement to the use case. A possible way to achieve this would be to adopt a”special requirement” section, similar to the one used in the RUP process. This was one of theimprovement suggestions mentioned in the questionnaire responses. In addition, the tool couldbe updated to utilize the built-in linking functionality in DOORS to handle references. Not onlywould this improve the traceability aspect of the tool, but it would also enable it to referencegeneric objects in the module. The current version of the tool keeps track of use cases and actorsby mapping their names to a position in the module, but this method is not applicable to genericobjects without names. The ”special requirement” section could then be linked to non-functionalrequirements that are specified textually in generic objects, which is the standard way to specifyrequirements in DOORS. The one disadvantage with this approach is that it would increase thesize of the DOORS extension (in terms of lines of code), increasing the risk of introducing bugsand making it less maintainable.

31


References

[1] M. Abbas, R. Jongeling, C. Lindskog, E. P. Enoiu, M. Saadatmand, and D. Sundmark, “Prod-uct line adoption in industry: An experience report from the railway domain,” in Proceedingsof the 24th ACM Conference on Systems and Software Product Line: Volume A - Volume A,ser. SPLC ’20. New York, NY, USA: Association for Computing Machinery, 2020.

[2] K. Pohl, G. Bockle, and F. Linden, Software Product Line Engineering: Foundations,Principles, and Techniques. Springer, 01 2005.

[3] Y. Dubinsky, J. Rubin, T. Berger, S. Duszynski, M. Becker, and K. Czarnecki, “An exploratorystudy of cloning in industrial software product lines,” in 2013 17th European Conference onSoftware Maintenance and Reengineering, 2013, pp. 25–34.

[4] H. Gomaa, “Designing software product lines with uml : from use cases to pattern-basedsoftware architectures,” Boston, 2004.

[5] A. Cockburn, Writing Effective Use Cases, 1st ed. USA: Addison-Wesley Longman PublishingCo., Inc., 2000.

[6] I. S. Santos, R. M. Andrade, and P. A. Santos Neto, “Templates for textual use cases ofsoftware product lines: results from a systematic mapping study and a controlled experiment,”Journal of software engineering research and development, vol. 3, no. 1, pp. 1–29, 2015.

[7] I. Jacobson, Object-Oriented Software Engineering: A Use Case Driven Approach. USA:Addison Wesley Longman Publishing Co., Inc., 2004.

[8] J. Rumbaugh, I. Jacobson, and G. Booch, Unified Modeling Language Reference Manual, The(2nd Edition). Pearson Higher Education, 2004.

[9] J. Kruger and T. Berger, “Activities and costs of re-engineering cloned variants into an inte-grated platform,” in Proceedings of the 14th International Working Conference on VariabilityModelling of Software-Intensive Systems, ser. VAMOS ’20. New York, NY, USA: Associationfor Computing Machinery, 2020.

[10] S. Tiwari and A. Gupta, “Investigating comprehension and learnability aspects of use casesfor software specification problems,” Information and Software Technology, vol. 91, pp. 22–43,2017.

[11] IBM. (2021, February) Ibm rational doors and rational doors web access v9.6.1 documentation.[Online]. Available: https://www.ibm.com/support/knowledgecenter/SSYQBZ 9.6.1

[12] A. K. Thurimella and D. Janzen, “Metadoc feature modeler: A plug-in for ibm rational doors,”in 2011 15th International Software Product Line Conference, 2011, pp. 313–322.

[13] J. A. Pereira, K. Constantino, and E. Figueiredo, “A systematic literature review of softwareproduct line management tools,” in Software Reuse for Dynamic Systems in the Cloud andBeyond, I. Schaefer and I. Stamelos, Eds. Cham: Springer International Publishing, 2014,pp. 73–89.

[14] R. P. d. Oliveira, E. Insfran, S. Abrahao, J. Gonzalez-Huerta, D. Blanes, S. Cohen, and E. S.d. Almeida, “A feature-driven requirements engineering approach for software product lines,”in 2013 VII Brazilian Symposium on Software Components, Architectures and Reuse, Sep.2013, pp. 1–10.

[15] R. Pereira De Oliveira and E. Santana De Almeida, “Requirements evolution in software prod-uct lines: An empirical study,” in 2015 IX Brazilian Symposium on Components, Architecturesand Reuse Software, Sep. 2015, pp. 1–10.

[16] I. Hajri, A. Goknil, L. C. Briand, and T. Stephany, “Pumconf: A tool to configure productspecific use case and domain models in a product line,” ser. FSE 2016. New York, NY, USA:Association for Computing Machinery, 2016, p. 1008–1012.

32

https://www.ibm.com/support/knowledgecenter/SSYQBZ_9.6.1


[17] I. Hajri, A. Goknil, L. C. Briand, and T. Stephany, “Configuring use case models in productfamilies,” Software and systems modeling, vol. 17, no. 3, pp. 939–971, 2018.

[18] T. Yue, L. C. Briand, and Y. Labiche, “Facilitating the transition from use case models toanalysis models: Approach and experiments,” ACM Trans. Softw. Eng. Methodol., vol. 22,no. 1, Mar. 2013.

[19] M. Mikyeong, Y. Keunhyuk, and S. C. Heung, “An approach to developing domain require-ments as a core asset based on commonality and variability analysis in a product line,” IEEETransactions on Software Engineering, vol. 31, no. 7, pp. 551–569, 2005.

[20] H. Gomaa and M. E. Shin, “Automated software product line engineering and product deriva-tion,” in 2007 40th Annual Hawaii International Conference on System Sciences (HICSS’07),2007, pp. 285a–285a.

[21] M. Eriksson, J. Borstler, and K. Borg, “Managing requirements specifications for productlines – an approach and industry case study,” The Journal of systems and software, vol. 82,no. 3, pp. 435–447, 2009.

[22] M. Eriksson, J. Borstler, and K. Borg, “The pluss approach – domain modeling with features,use cases and use case realizations,” in Software Product Lines, ser. Lecture Notes in ComputerScience. Berlin, Heidelberg: Springer Berlin Heidelberg, 2005, pp. 33–44.

[23] M. Eriksson, H. Morast, J. Borstler, and K. Borg, “The pluss toolkit? extending telelogicdoors and ibm-rational rose to support product line use case modeling,” in Proceedings ofthe 20th IEEE/ACM International Conference on Automated Software Engineering, ser. ASE’05. New York, NY, USA: Association for Computing Machinery, 2005, p. 300–304.

[24] P. Runeson, M. Host, A. Rainer, and B. Regnell, Case Study Research in Software Engineering:Guidelines and Examples, 1st ed. Hoboken: Wiley, 2012.

[25] P. Runeson, Case study research in software engineering guidelines and examples, 1st ed.Hoboken, N.J: Wiley, 2012.

[26] R. M. Heiberger and N. B. Robbins, “Design of diverging stacked bar charts for likert scalesand other applications,” Journal of statistical software, vol. 57, no. 5, pp. 1–32, 2014.

[27] H. Gomaa and M. E. Shin, “Multiple-view meta-modeling of software product lines,” inEighth IEEE International Conference on Engineering of Complex Computer Systems, 2002.Proceedings., 2002, pp. 238–246.

[28] Q. L. Nguyen, “Non-functional requirements analysis modeling for software product lines,” in2009 ICSE Workshop on Modeling in Software Engineering, 2009, pp. 56–61.

[29] J. L. Barros-Justo, F. B. Benitti, and S. Tiwari, “The impact of use cases in real-world softwaredevelopment projects: A systematic mapping study,” Computer standards and interfaces,vol. 66, 2019.

[30] D. Moody, “The ”physics” of notations: Toward a scientific basis for constructing visualnotations in software engineering,” IEEE transactions on software engineering, vol. 35, pp.756–779, 2009.

[31] I. Reinhartz-Berger and A. Sturm, “Comprehensibility of uml-based software product linespecifications: A controlled experiment,” Empirical software engineering : an internationaljournal, vol. 19, no. 3, pp. 678–713, 2014.

[32] A. Braganca and R. J. Machado, “Deriving software product line’s architectural requirementsfrom use cases: an experimental approach,” Proceedings of the MOMPES 2005, 2005.

[33] A. K. Thurimella, B. Bruegge, and D. Janzen, “Variability plug-ins for requirements tools: Acase-based theory building approach,” IEEE Systems Journal, vol. 11, no. 4, pp. 1935–1946,2017.

33


[34] L. F. da Silva and E. Oliveira, “Evaluating usefulness, ease of use and usability of an uml-based software product line tool,” in Proceedings of the 34th Brazilian Symposium on SoftwareEngineering. Association for Computing Machinery, 2020, p. 798–807.

34


A Questionnaire

Participant informationThe purpose of this questionnaire is to evaluate tool support for specifying requirements in aproduct line context by utilizing use cases. The results will not be used outside the context of thethesis work.

By filling out this form, you agree to participate in the study. Participation in this study isvoluntary. Participants can withdraw their participation at any point. Any information that canbe used to identify individuals will be anonymized in the published thesis report.

Before answering, the participants should view an introductory video of the tool.Link to the video: https://youtu.be/sgVjkKob QM

1. Name:

2. Company role:

3. I am familiar with writing ”use cases” to specify system requirements.

Strongly Agree 2——–2——–2——–2——–2 Strongly Disagree

4. I am familiar with creating ”use case diagrams” to specify system requirements.


5. I am familiar with managing requirements using the tool IBM DOORS.


6. I am familiar with managing variations in use cases across similar products(aka a product family).


Tool evaluationThe tool that is under evaluation consists of two parts. The first part is an extension in IBMDOORS which can be used to define use cases that describe the variability between individualmembers in a product family.

The second part is a standalone program that can interpret the output from the DOORS extensionand display the possible choices to stakeholders. The stakeholders can then select the choices theyprefer to generate product-specific use cases.

7. The tool interface, such as navigation between use cases and selection ofmenu options, was easy to understand.


35


8. The different sections of the use case template that is used in the toolwere easy to understand.


9. The process of creating use cases through the tool was easy to understand.


10. Defining variability in the use cases through the tool was easy to understand.


11. Selecting variability in the use cases through the tool was easy to understand.


12. The construction of use case diagrams through the tool was easy to understand.


13. Do you think the tool could be used to improve collaboration between stake-holders in the project?

Feel free to think about or define collaboration depending on your roleand understanding.

14. The tool allows the user to define variability through two methods. The firstmethod is the reuse category, which enables the selection of use cases. Thesecond method is the variation points, which enables the insertion of optionsinside the interactions of a use case.

Do you think this degree of variability in the tool is sufficient to expressthe differences between individual products in a product family?

15. Are there any changes or additional features that you would suggest to improvethe tool?

36

tool support for the derivation of product line use …

Documents