=Paper= {{Paper |id=Vol-2581/aesp2020paper1 |storemode=property |title=Tailoring and Evaluating Non-Functional Interests Towards Task-Oriented Functional Requirements |pdfUrl=https://ceur-ws.org/Vol-2581/aesp2020paper1.pdf |volume=Vol-2581 |authors=Philipp Haindl,Reinhold Plösch,Christian Körner |dblpUrl=https://dblp.org/rec/conf/se/HaindlPK20 }} ==Tailoring and Evaluating Non-Functional Interests Towards Task-Oriented Functional Requirements== https://ceur-ws.org/Vol-2581/aesp2020paper1.pdf

Tailoring and Evaluating Non-Functional Interests
Towards Task-Oriented Functional Requirements
Philipp Haindl Reinhold Plösch Christian Körner
Department of Business Informatics Department of Business Informatics Corporate Technology
Johannes Kepler University Linz Johannes Kepler University Linz Siemens AG
Linz, Austria Linz, Austria Munich, Germany
philipp.haindl@jku.at reinhold.ploesch@jku.at christian.koerner@siemens.com

Abstract—Without a specific functional context, non-functional for a certain software feature. As the efforts required to satisfy
requirements can only be approached as cross-cutting concerns stakeholder interests differ between features, this vagueness in
and treated uniformly across all features of an enterprise system. requirements specification results in undetected non-functional
This neglects, however, the heterogeneity of non-functional re-
quirements that arises from the domains of stakeholders and the dependencies between components and features in development,
distinct functional scopes these systems, which mutually influence as well as increased efforts during software operation [1].
how these non-functional requirements have to be satisfied. Functional units of works can be better elicited through taking
Earlier studies showed that the different types and objectives of a user perspective and focusing on the most relevant tasks that
non-functional requirements result in either vague or unbalanced will be performed with the software. Contrarily to isolated
specification of non-functional requirements. We propose a task
analytic method for eliciting and modeling user tasks and the features, tasks can be seen as functional units that support the
stakeholders’ pursued interests towards the enterprise system. users’ goals and also show the required interactions between
Stakeholder interests are structurally related to user tasks and software features. During requirements elicitation, this also
each interest is specified individually as a quantitative constraintmakes the individual relevance of competing NFRs for a single
for a specific user task. These constraints can automatically user task more tangible for all stakeholders. In our work, we
be evaluated throughout the system’s lifecycle to assure that
the respective stakeholder interest is fulfilled. Eventually, this understand constraints as refinements of NFRs. By specifying
allows to proactively counteract violations of constraints and these constraints for a user task using quantitative measures,
thus stakeholder interests. We propose a structured method, constraints can be automatically validated for fulfillment.
intertwining task-oriented functional requirements with non- Monitoring the fulfillment of stakeholder interests facilitates
functional stakeholder interests to specify constraints on the levelrequirements negotiation [2] and assessment of tradeoffs
of user tasks. We also present results of an exploratory case
study with domain experts, which reveals that our task modeling in satisfying constraints [3]. Also, this allows buyers of
and interest-tailoring method facilitates shared understanding of customized individual software products and enterprise systems
stakeholder interests, clarity and quality of software constraints, (ES) to evaluate if non-functional requirements are implemented
prioritization of engineering efforts, and the impact of stake- by vendors as contractual agreed.
holder interests on functional requirements. This paper presents the TAICOS (Task-Interest-Constraint
Index Terms—Non-Functional Stakeholder Interests; Require-
ments Negotiation; Task Modeling; Constraint Specification;
Satisfycing) method as a modification of hierarchical task
Requirements Evaluation. analysis [4] for eliciting functional and non-functional require-
ments and monitoring the fulfillment of these requirements
I. I NTRODUCTION for enterprise systems. This facilitates taking appropriate
counteractions throughout the lifecycle to meet the stakeholders’
Balancing functional and non-functional requirements requirements on a very detailed level. The contributions of the
(NFRs) articulated from stakeholders is a challenging endeavor method are twofold: (a) it provides requirements engineers a
in software projects of any scale. Also, due to the primarily structured sequence for eliciting functional requirements from
engineering-oriented scope of NFRs, the practical relevance of user tasks and non-functional requirements from stakeholder
business, strategic, operational, legal, and privacy interests is interests towards enterprise systems; (b) it provides a compact
often neglected during requirements specification. As a result, language for refining these interests into quantified constraints.
these types of requirements are neither monitored nor evaluated These constraints can eventually be operationalized through
in the software lifecycle. respective instruments that acquire typical measures for specific
We define the term stakeholder interest to emphasize a constraints, e.g., the execution time or maintainability char-
broader understanding of NFRs and to also capture relevant acteristics of the task’s software implementation. The prime
non-engineering related qualities of software, that must be objective of these constraints is to satisfice the original interest,
addressed. In industrial settings, these stakeholder interests i.e., to satisfy an interest sufficiently and not better than required.
are typically elicited and defined on a high level as cross- The operationalization and evaluation of these constraints even-
cutting concerns. This however does not take into account the tually gives engineering teams important feedback to practically
relevance, applicability, and characteristic of a specific interest handle these constraints in software design, implementation,

AESP20: 1st Workshop on Requirement Management in Enterprise Systems Projects @ SE20, Innsbruck, Austria 2
and operation. Also, the TAICOS method is complemented by NFRs for enterprise systems. According to Fotrousi et al. [9],
a dedicated operational software quality model [5] to facilitate the main limitation of goal models is that they make it difficult
evaluating the fulfillment of interests in an automated manner for stakeholders to understand the impact of unmet NFRs
in a DevOps context. towards a goal during requirements specification.
The remainder of this paper is organized as follows. In Riegel et al. [10] present a prioritization method which
Section II we present a motiviating example to stress the categorizes non-engineering related NFRs by project-related, fi-
practical importance of our method. An overview of related nancial, customer, operational business performance or business-
work and the demarcation of our method to other approaches strategy related benefits. Their work underline the broader
are given in Section III. Following, Section IV describes notion of NFRs to also capture non-technical qualities of
our method to eliciting, modeling, and tailoring functional software. Karlsson et al. [11] investigate the applicability
requirements and stakeholder interests. Subsequently, Section of goal models for market-driven software development and
V presents how our method can be utilized in a DevOps context stressed the advantages of goal-centered feature elicitation.
for automatically evaluating the fulfillment of stakeholder The authors conclude that these types of models facilitate
interests. Following, Section VI presents selected evaluation stakeholder participation during requirements engineering.
results of a case study with domain experts in which we The third stream of research examines the different satisfac-
examined particular aspects of the method. Following, we tion criteria of NFRs in the context of user tasks. Zubcoff et
describe the possible threats to validity in Section VII before al. [12] propose to specify soft goals in the context of user
we conclude our work and sketch possible directions for future tasks to assist requirements engineers in evaluating trade-offs
work in Section VIII. between NFRs. The authors also underline that NFRs shall be
specified individually for functional requirements to improve
II. M OTIVATING E XAMPLE end-user satisfaction. Ameller et al. [13] present a survey
To motivate our method to tailoring stakeholder interests among practitioners about the practice of NFR specification
to user tasks and specifying concrete constraints therefor, let in model-driven design. The interviewees argued that NFRs
us consider a simple example. Your company runs a local are not only difficult to specify through models, but even
book store and you want to provide your customers an online difficult to discover and explicate in measurable terms. As
application. Basically this application shall allow customers to a result of this imprecise definition, the fulfillment of NFRs
search books and write reviews about them, update credit card usually can only be evaluated and counteracted very late in the
information and change their shipping address. Your company software development process. An interview study of Svensson
and the customers most likely will have diverging expectations et al. [14] also shows that NFRs typically have lower priority
regarding individual characteristics of these tasks. than functional requirements in practice and often are not
But how concretely could these expectations differ among the specified in early stages of development. This lack of integration
user tasks? In order to concentrate your software maintainance between functional and non-functional requirements can result
efforts you could require higher software quality standards in prolonged time-to-market and cost overruns in many software
for functionality that is part of your revenue stream. In this projects [15]–[17].
example this particularly affects tasks where users search for In summary, recent research had elaborated the importance
books or update their credit card information, as both tasks are of balancing functional and NFRs in understanding technical
part of the core purchase process. On the contrary, the quality qualities. Though, no structured method has yet been presented
characteristics of the software components allowing the users that captures stakeholders interests outside the technical domain.
to write book reviews might be less important for you. Taking The approach presented in this paper provides a structured
the customer perspective it most likely will be important that method for eliciting and specifying constraints from NFRs for
your application is responsive even if many users concurrently individual functional requirements. Also, it is complemented
use it. Particulary the response time of your application will be by a compact constraint language and operationalization
relevant when customers search for a book and less important framework that allows to evaluate the fulfillment of the
if they write a book review. respective stakeholder interests in an automated manner during
As can be depicted from this example, while there can the software lifecycle.
be general stakeholder interests that the software shall be
maintainable or responsive, it actually depends on the concrete IV. T HE TAICOS M ETHOD
user task how an interest concretely manifests itself. Our Particularly in the context of enterprise systems, with
method facilitates tailoring qualitative stakeholder interests users executing tasks as activities of business processes,
towards user tasks and specifying quantitative constraints that it is important to elicit functional requirements from the
can be evaluated during the lifecycle of an enterprise system. goals that users pursue by using the software [18]. Hence,
the TAICOS method hierarchically decomposes functional
III. R ELATED W ORK blocks of software from the users’ goals into concrete tasks.
Goal- [6], [7] and task-driven elicitation techniques [1], [8] In contrast to eliciting isolated features, this gives a more
are effective approaches for functional requirements elicitation. comprehensive picture about how these different functional
As such, they do not support stakeholders in specifying suitable blocks are related to each other so that the user can most

AESP20: 1st Workshop on Requirement Management in Enterprise Systems Projects @ SE20, Innsbruck, Austria 3
effectively achieve the pursued goal. To facilitate a shared responsibilities to support these user intentions through the
understanding among requirement engineers of the users’ tasks system. Both perspectives are compared with each other in
and goals, each step of the method is repeated until a common tabular form and refined with pre- and postconditions, as
understanding has been achieved. Figure 1 illustrates the eight well as information objects, which describe the information
steps of the method, starting with capturing user tasks and generated or required for task execution. The task detailing step
collecting stakeholder interests. helps to map the fine-grained intentions of the user to suitable
functional requirements by carving out the minimal and
satisfactory technical solution to execute the task effectively.
A. Capturing User Tasks
1 Elicitation: To elicit tasks, we rely on hierarchical task 2 Modeling: In the next step, the control flow and decision
analysis [4] with some modifications to carve out the functional points between the subtasks are modeled. Figure 2 shows an
scope of the elicited actions. Hierarchical task analysis breaks exemplary task of searching for a book at an online store. This
down a task into goals, subgoals, plans, and operations, focusing example was also used for presenting our method in the expert
on the structure and decomposition of the task into a hierarchy interviews.
of subtasks in sequential order of tasks so that the goal can Each subtask is modeled as a rectangular gray box labeled
be attained. According to this notion, a task is a sequence of with the corresponding user intention and incorporates one or
actions that people perform to attain a goal. The elicitation multiple rounded rectangles (i.e., system responsibilities) that
of tasks in our method follows a sequential procedure that reflect the required software functionality. Information objects
provides structured guidance to detail the functional scope and are denoted by colored rectangles, with the direction of the
connections between tasks. arrows indicating whether the information object is generated
– Step 1: Define task under analysis. Which task should or consumed by the respective subtask. The objective of this
be analyzed and what is its objective? Scope boundaries modeling is to outline the control flow among the subtasks
must be clearly defined prior to analysis, typically driven for all stakeholders and to facilitate sketching the required
by the underlying business model. software features. In this work we refer to features as concrete
– Step 2: Collect data for task analysis. This collection software implementations [19] which realize the actions that
comprises data about task execution, dependencies be- are required to implement a task. Also, the granularity of the
tween tasks, constraints. It originates from interviewing actions executed within a subtask can be chosen arbitrarily
subject matter experts or key users. to foster a common understanding of the scope and goal of
– Step 3: Determine the overall task goal. This will the features among the involved stakeholders. In contrast to
become the root goal of the hierarchy, i.e., the starting process modeling, this type of modeling primarily focuses
point for decomposition. on the flow among the activities and also relates them to the
– Step 4: Determine subtasks. The predecessor task goal technical counterparts needed for their execution. For the sake
will then be used to derive subtasks necessary for achieving of simplicity, we abstain to describe conditional loops or
the superordinate goal. concurrent executions of subtasks in our modeling method.
– Step 5: Identify task details. Derived from the goal of
each subtask, identify the intentions of the user in attaining 3 Prioritization: Next, only those user tasks are selected
the goal and the resulting responsibilities of the system to for the subsequent steps, which are most important (following
support these intentions. We elaborate this step in more the idea of a minimum viable product), bear a competitive
detail below. advantage, or have been selected by an agile team for
– Step 6: Define execution plans. Execution plans organize development in the next program increment. Typically, the
how to reach the goal of the task by modeling execution question of importance can only be answered by considering
order and dependencies between the subtasks. The objec- the underlying business model. Also, the required assessment
tive is to define how the subtasks relate to each other so of the tasks’ value contribution prevents specifying details or
that the goal of the task can be achieved. exhaustive constraints for rarely executed tasks.
While hierarchical task analysis allows infinite refinement
of tasks to the point that tasks are purely operational for a B. Collecting Stakeholder Interests
user, our method only allows refinement of tasks by means of 4 Elicitation: Due to their primary technical focus, the
task details tables. This forces the development team to define notion of NFRs does not satisfactorily cover non-technical
the granularity of tasks upfront. If the refinement is still too objectives of stakeholders having an impact on a software
vague to be operational, a separate model should be created system. This specially comprises all objectives that must be
for refinement. This assures that tasks and constraints can be considered continuously throughout the software lifecycle, from
properly treated and described at the refined level. software development and operation to its decommissioning.
Existing classification schemes [20], [21] for these non-
For the structured elicitation of task details, our method technical objectives, which we understand as stakeholder
offers two perspectives: (1) user intentions, the user’s interests, also reflect their relevance for software quality and
interactions during execution of the task; and (2) system need for precise specification. These stakeholder interests are

AESP20: 1st Workshop on Requirement Management in Enterprise Systems Projects @ SE20, Innsbruck, Austria 4
Capturing User Tasks Collecting Stakeholder Interests Tailoring Stakeholder Interests Specifying Constraints
1 2 3 4 5 6 7 8
Elicitation Modeling Prioritization Elicitation Documentation Reﬁnement Tailoring Speciﬁcation
1 4 7
2 4
2 5 8

3 6 9 35 50

Figure 1: The TAICOS method defines a structured sequence from capturing user tasks to collecting and tailoring stakeholder
interests for specifying task-dependent constraints.

List of book titles List of matches with title,
Search term
for auto-completion author, cover and year
Search terms saved
in user proﬁle

Entering title of book (1) Searching for book (2) found books? Displaying results (3)

Providing suggestions Search for Format list of Display exact
for book titles Search by title matching and
similar books [yes] matches
similar books

Customer [no]
logged in
Selected book

Show hint that no books
match search term Displaying book details (5) Selecting a book from list (4)
Subtask

System Responsibility Display details Select book

Information Object
Displayed book
Pre/Post-Condition saved in user proﬁle

Figure 2: Modeling Subtasks, System Responsibilities, Information Objects and Conditional Flows.

still unsatisfactorily covered by existing, solely technically elicitation step.
oriented standards such as ISO/IEC 29148:2011 [22] or
ISO/IEC 25030:2007 [23], which often results in NFRs being C. Tailoring Stakeholder Interests
only vaguely elicited. 6 Refinement: Similar to the refinement of user tasks, also
The objective of this step is to capture all stakeholders’ stakeholder interests are iteratively refined until they show a
quality-related, operational, business, legal, and other non- delimited and comprehendible scope for the later tailoring.
behavioral interests that influence how the later software Refined stakeholder interests again are documented conjointly
system needs to support the tasks of the users. with the relevant stakeholders. This is done to cross-check that
there is common understanding about the interest even after its
5 Documentation: In this step, the elicited stakeholder refinement. Stakeholder interests which are too large in scope
interests are documented informally to express the stakeholders’ are decomposed down to a suitable level. The overall objective
objectives and expectations towards the software system. It is of this step is to prevent ambiguities about an interest’s scope
important to document each stakeholder interest in a manner among the stakeholders. Uniform comprehension about the
comprehensible for all involved stakeholders to foster shared scope of an interest is the prerequiste for its effective tailoring
understanding and also to later assess its individual relevance. and the specification of suitable constraints therefore.
In this step of the method an interest does not need to be
documented on a quantitative basis. The concrete tailoring 7 Tailoring: In this step, the stakeholder interests and
and deriving of constraints for each user tasks is done in a user tasks are analyzed pairwise to evaluate the relevance
subsequent step. Stakeholder interests can be documented in of an interest and how it can be satisfied in each narrow
the following ways: task context. This detailed analysis also assures that for all
• “The software must be responsive to user inputs.” elicited stakeholder interests the relevant measures can later
• “... handle peaks of concurrent users.” be operationalized in the context of individual user tasks.
• “... be deployable automatically.” Stakeholder interests and user tasks are then related to each
• “... recover quickly after outages.” other in a two-dimensional task-interest matrix. Following, each
• “... be operated in the cloud.” interest is tailored individually to each user task so that it can
Our method explicitly separates interest elicitation from be fulfilled exactly for the respective user task. Resulting from
documentation. The former being conducted by all stakeholders this tailoring is a qualitative ordering of the cells indicating
in a brainstorming like manner striving to unveil as many the relevance of the interest for the respective user task, e.g.,
possibly relevant interests that could impact the software through coloring cells darker gradually with relevance. The
lifecycle; the latter just to document the results from the tailoring and qualitative ordering of the interests’ relevance is

AESP20: 1st Workshop on Requirement Management in Enterprise Systems Projects @ SE20, Innsbruck, Austria 5
shown in the (task-interest matrix, top) in Figure 3. At that D. Specifying Constraints
point of the method no quantitative fulfillment criteria for the 8 Specification: In the last step of our method, the task-
stakeholder interests are defined. The focus of this step is interest matrix created in the last step serves as input for
on getting a common understanding about the relevance of eventually specifying concrete constraints. These constraints
an interest for a particular user task. As a practical example, are specified individually for each user task based on threshold
the interest that “the software must be responsive to user values to satisfice the stakeholder interests. Hence, when
inputs” might be subjected to different qualitative expectations specifying concrete constraints the objective is to fulfill the
depending on the concrete user task. Responsiveness might be stakeholder interests satisfactorily and not optimally, so that a
much more important for a user when searching for a book than majority of stakeholder interests can be fulfilled.
when writing a book review, but less important when changing The previous qualitative evaluation of individual relevance
the shipping address. As a further example from the perspective of an interest for a user task helps to find concrete measures
of the software manufacturer, the interest “the software shall be and criteria for specifying these constraints. To foster a shared
modularized into separate units.” is important when changing understanding among the stakeholders of the threshold values
credit card information or the shipping address of the customer. used in the constraints, it is important to use a well known unit
These two tasks are part of the billing process and thus the of measurement. Ideally, one should start with determining
associated source code need to be better modularized than for metrics and threshold values for the most relevant user task for
other tasks. a specific stakeholder interest. Taking the example illustrated
in Figure 3, the task to search for a book needs to be specially
responsive. Determining the response time as metric and
rd

g
ca

w
vie
pp
rm c k

values below 2 milliseconds as being very responsive, the
Ch tion dit
in da boo

re
a re

es s

ok
Up for

dr ge

other constraints can be derived thereof straightforwardly. This
fo te

bo
s
ad an
ch

e
ar

procedure is repeated until
rit
Se

The software must be • for each cell in the matrix there is a concrete constraint
responsive to user inputs.
defined, or alternatively
The software must use
resources effectively.
• the stakeholders agree that the interest is of little relevance

The software must be for a certain user task and does not need to be specified.
maintainable easily.
Figure 3 shows the transition from the task-interest matrix
The software shall be
modularized into separate units.
(top) into a task-metric matrix (bottom) defining metrics and
The software must be resilient
threshold values for each user task and stakeholder interest.
to external outages. Lastly, using the information of the task-metric matrix we can
task-interest matrix specify concrete constraints for each user task. To faciliate
expressing these constraints our method provides a compact
constraint language. The units of measure used in the task-
responseTime (ms) <2 <3 <3 <4
metric matrix do not necessarily need to be the same as used
memoryUsage (mb) <100 <100 <50 <70 for the constraints, but depend on the operationalization of a
measure. As an example, while the technical debt is expressed
technicalDebt (days) <1 <2 <2 <3 in days in the task-metric matrix, constraints use hours as
unit of measure. The same applied to the mean time between
classFanOut <10 <4 <4 <10
failures (MTBF) which is defined in minutes in the task-metric
MTBF (min) <1 <1 <5 <10 matrix and expressed in seconds in the constraints.
task-metric matrix

Figure 3: Deriving quantitative measures for user tasks after search_book: responseTime < 2, memoryUsage < 100,
techDebt < 24, fanOut < 10, mtbf < 60.
qualitatively evaluating relevance of stakeholder interests. update_card: responseTime < 3, memoryUsage < 100,
techDebt < 48, fanOut < 4, mtbf < 60.
change_address: responseTime < 3, memoryUsage < 50,
Analyzing these interests outside the context of individual techDebt < 48, fanOut < 4, mtbf < 300.
user tasks neglects the fact that some tasks are more important write_review: responseTime < 4, memoryUsage < 70,
than others and thus need more attention. The fulfillment of techDebt < 72, fanOut < 10, mtbf < 600.
interests typically requires intertwining multiple teams, e.g.,
requirements engineering and DevOps teams. This even more Figure 4: Example constraints to evaluate stakeholder interests
emphasizes the need to evaluate its relevance conjointly with all using quantitative measures for each user task.
relevant stakeholders in the narrow context of a user task. Also,
stakeholder interests evaluated with little relevance for multiple In Figure 4 we illustrate how the information of the task-
user tasks should be revised as this indicates ambiguities metrics matrix can be expressed as concrete constraints for
regarding its scope or its actual irrelevance. the elicited user tasks. These constraints allow to evaluate

AESP20: 1st Workshop on Requirement Management in Enterprise Systems Projects @ SE20, Innsbruck, Austria 6
the fulfillment of the respective stakeholder interests through
concrete measures, which themselves are operationalized
through dedicated software instruments. For instance, the
interest that “the software must be responsive to user inputs”
is only fulfilled if the response time of the user task’s software
implementation is below the defined thresholds. For the sake
of brevity we skip the details of this constraint language and
refer to our other publications in this context [5].
V. E VALUATING F ULFILLMENT OF I NTERESTS
(a) Overview of user tasks and evaluated stakeholder interests.
When developing software components for enterprise sys-
tems, the TAICOS constraint language can be used to evaluate
whether the explicated requirements are fulfilled. Specially
for software components that concertedly realize business
processes, unfulfilled software quality requirements can lead
to delays and disruptions of the affected business processes.
For the evaluation of the interests in a development context,
the measures used in the respective constraint specification are
acquired from development, operational or other enterprise
systems. Afterwards, the actual value of a measure can
be compared against the threshold value explicated in the (b) Detailed evaluation results of the maintainability interest for each
constraint. Our constraint language provides basic comparison user task, along with the specified constraints.
operators as well as time series operations and time filters for
Figure 5: Visualization of evaluation results of stakeholder
acquiring the measures.
interests for user tasks, (a) overview, (b) detailed view.
The evaluation results are then displayed on a web applica-
tion (cf. Figure 5) in a tabular form similar to the task-interest
matrix. In the overview (cf. Figure 5a) the colors of the cells Taking the guidelines by Runeson and Höst [24] as a
(red, orange, green) give a condensed view about violated blueprint we designed a questionnaire covering practices,
interests for a specific user task. If at least one stakeholder challenges, and problems that arise during specifying NFRs
interest is violated for a single user tasks, the respective interest with different stakeholders. Also, we conducted a pilot interview
is colored in red. As an example, the cell of the maintainability as suggested by Yin [25] with one highly experienced expert
interest in Figure 5a is highlighted in red, even if it is only and included his feedback to improve the questionnaire itself.
violated for the user task to update the credit card information. Particulary, we refined certain phrases in the questionnaire and
Also, we provide a detailed view of evaluation results used more common terminology to assure a good understanding
for each constraint. Figure 5b shows an exemplary detailed during the interviews among the experts. The questionnaire
view for the maintainability interest and its constraints. If the comprised 20 open questions and 4 closed questions on a 4-
constraint is fulfilled, its concrete value and deviation from point Likert scale and was separated into 3 parts: The first
the constraint threshold is also shown. This shall give an part captured educational and company background, roles in
early hint that a constraint has only been scarcely fulfilled projects and years of experience with requirements engineering.
and that counteractions should be taken. Our main objective In the second part we asked questions to find out how the
was on keeping these visualizations comprehendible specially companies currently model functional requirements and NFRs,
for non-engineering stakeholders. The combination of visual what challenges they are confronted with, and what types of
cues and quantitative information about constraint fulfillment stakeholder interests typically need to be taken into account
shall ease communication between technical and non-technical thereby. Finally, in the third part we presented the experts our
stakeholders. method for tailoring stakeholder interests to concrete constraints
in the context of user tasks. During the interviews we used
VI. E XPLORATORY C ASE S TUDY Figure 2 to present the method to the experts. In this final
We conducted an exploratory face-to-face interview study part we asked them to specially reflect about the anticipated
with 11 domain experts to examine how they rate the TAICOS benefits and drawbacks of the method.
method. Particulary we studied the benefits and weaknesses Before asking the experts to rate our method, we presented
the experts anticipated from eliciting functional requirements them a selection of tasks from a well-known online book store
from the most relevant user tasks of an enterprise system and and a list of generally understandable performance, privacy,
specifying concrete non-functional requirements for it. These and legal interests. Then, we illustrated how these interests can
domain experts had typical roles in the context of enterprise be used in our method to derive constraints on the level of user
systems - from requirements engineering to development, tasks. Finally, we asked the experts 4 questions to evaluate our
operation, and product management. method for tailoring these interests in the context of individual

AESP20: 1st Workshop on Requirement Management in Enterprise Systems Projects @ SE20, Innsbruck, Austria 7
Shared Understanding of 82%
Stakeholder Objectives
Increased Clarity and 55%
Quality of Constraints
Premature Analysis 36%
of Project Risks
Prioritization of 18%
Engineering Efforts
Facilitated Elicitation and 18%
Specification of Constraints
More Precise Documentation 18%
of Stakeholder Interests
Easier Detection 9%
of Critical Paths

0 20 40 60 80 100

Figure 6: Anticipated benefits of tailoring stakeholder interests to user tasks.

user tasks. interviews, the experts mentioned the increased specification
quality of constraints derived from interests, and 36% said it
A. Anticipated Benefits and Weaknesses of the Task-Oriented would help them to assess project risks by better understanding
Modeling Method for Enterprise Systems interests and their interdependencies.
In one part of the interview, the experts were asked to In 18% of interviews, experts expressed the prioritization
elaborate the anticipated benefits and weaknesses of the method. of interests, the time savings accrued by deriving constraints
They argued that especially due to the granularity and focus from interests, and the ease of documentation as expected
on user tasks, they expect the following main benefits of the benefits of the method. Only 9% of experts mentioned that our
method: method could also help them to detect critical paths. Based
• fostering shared understanding of functional requirements on the open answers examining the weaknesses, we codified
among stakeholders especially across domains; the experts’ answers into 3 groups. 45% of experts believed
• easier and more precise structuring of the functional scope that the method would introduce an additional specification
compared to e.g., user stories or epics; effort but also expressed that the expected benefits outweighed
these tradeoffs accompanying any structured method. 27% of
• additional guidance for eliciting functional requirements
experts mentioned the complexity of the method as a drawback,
through the structured decomposition of goals into tasks
and a further 18% anticipated that our method would result in
and subtasks.
explicitly specifying standard industry constraints that usually
Concerning the weaknesses of the method for task-oriented need no special documentation (e.g., a default availability,
modeling of functional requirements, 27% of the experts common security requirements).
anticipated no weaknesses for the practical introduction of
the method. We codified the open answers of the 73% experts VII. T HREATS T O VALIDITY
naming weaknesses, summarizing their statements as follows. In this section we outline the possible threats to the validity
34% responded that, as with every structured method, our of our method. Particulary this affects the design, execution,
method requires knowledge of how to use it effectively in and interpretation of the exploratory interview study.
projects. The experts also assumed that the method would We see a threat to construct validity in the different
require only little training time for its practical introduction, interpretations of the questions by the experts, which is mainly
due to its simplicity. The additional maintenance effort to due to their different roles and experiences. We addressed
adapt diagrams to changing requirements was expressed as a this threat by showing each expert concrete definitions of
weakness by 22% of the experts, and the complexity of the the terminology used in the interview and discussed any
model elements was also mentioned by 22% of the experts. ambiguities. When summarizing the experts’ answers, we also
Flexibility and additionally introduced complexity were each considered the background and role of each expert to determine
mentioned by 11% of the experts. from what view and with what intention the statement was
given. Also, as the objective of the exploratory case study
B. Anticipated Benefits and Weaknesses of the Interest- was on gathering preliminary feedback for methodological
Tailoring Method for Enterprise Systems improvement of the method, a further empirical validation is
Finally, we asked the experts 2 open questions to elaborate necessary after the experts have applied our method.
the anticipated benefits of our interest tailoring method on The foremost threat to internal validity can be seen in
the level of user tasks. We condensed their answers to these some experts’ trend to answer in confirmation of our theories.
questions into 8 categories, which are illustrated in Figure 6. This could have led to confirmation bias, but we regard this
Increased comprehensibility of the system was expressed as as negligible because in response to this trend to answer
a benefit by 82% of the experts, namely by increasing the towards confirming our theories, we asked follow-up questions
clarity of objectives pursued through an interest. In 55% of the to capture the experts’ actual experiences.

AESP20: 1st Workshop on Requirement Management in Enterprise Systems Projects @ SE20, Innsbruck, Austria 8
We addressed the threat to external validity by selecting [6] A. v. Lamsweerde, “Goal-oriented requirements engineering: a guided
experts who operate in different industry sectors, and we also tour,” in Proceedings Fifth IEEE International Symposium on Require-
ments Engineering, 2001, pp. 249–262.
selected only one expert per company. However, we see a threat [7] C. Rolland and C. Salinesi, “Modeling Goals and Reasoning with Them,”
to the generalizability of the results to other industries due in Engineering and Managing Software Requirements, A. Aurum and
to the different size and maturity of requirements engineering C. Wohlin, Eds. Springer Berlin Heidelberg, 2005, pp. 189–217.
[8] S. Lauesen and M. A. Kuhail, “Task descriptions versus use cases,”
practices in the companies. Requirements Engineering, vol. 17, no. 1, pp. 3–18, Mar. 2012.
Particularly, an empirical validation of the overall approach [9] F. Fotrousi, S. A. Fricker, and M. Fiedler, “Quality requirements elicitation
needs to be conducted to gather empirical evidence about its based on inquiry of quality-impact relationships,” in 2014 IEEE 22nd
International Requirements Engineering Conference (RE), Aug. 2014,
applicability and suitability in industrial settings. pp. 303–312.
[10] N. Riegel and J. Doerr, “A Systematic Literature Review of Requirements
VIII. C ONCLUSION AND F UTURE W ORK Prioritization Criteria,” in Requirements Engineering: Foundation for
Utilizing the proposed hierarchical task analysis method to Software Quality. Springer, Cham, Mar. 2015, pp. 300–317.
[11] L. Karlsson, s. G. Dahlstedt, B. Regnell, J. Natt och Dag, and A. Persson,
structurally decompose tasks into subtasks seems to offer a “Requirements engineering challenges in market-driven software devel-
promising approach for clarifying the core functionality needed opment – An interview study with practitioners,” Qualitative Software
to support the users’ goals in enterprise systems. Stakeholder Engineering Research, vol. 49, no. 6, pp. 588–604, Jun. 2007.
[12] J. Zubcoff, I. Garrigós, S. Casteleynb, J.-N. Mazón, and Aguilar, “Evalu-
interests can be conjointly refined into quantitative constraints ating different i*-based approaches for selecting functional requirements
within the context of a user task so that their fulfillment can be while balancing and optimizing non-functional requirements: A controlled
automatically evaluated during the software lifecycle. Due to experiment,” Information and Software Technology, vol. 106, pp. 68–84,
Feb. 2019.
the specification of stakeholder interests and derived constraints [13] D. Ameller, X. Franch, C. Gómez, S. Martínez-Fernández, J. Araujo,
on the level of user tasks, our method explicitly addresses chal- S. Biffl, J. Cabot, V. Cortellessa, D. Méndez, A. Moreira, H. Muccini,
lenges arising from the interdependencies between functional A. Vallecillo, M. Wimmer, V. Amaral, W. Bühm, H. Bruneliere,
L. Burgueño, M. Goulão, S. Teufl, and L. Berardinelli, “Dealing with
requirements and NFRs in software systems. Non-Functional Requirements in Model-Driven Development: A Survey,”
We have focused our exploratory case study on the elicitation IEEE Transactions on Software Engineering, pp. 1–1, 2019.
practice and the granularity of NFR specification in the [14] R. Berntsson Svensson, T. Gorschek, and B. Regnell, “Quality Require-
ments in Practice: An Interview Study in Requirements Engineering
companies. The main objective of this research design was to for Embedded Systems,” in Requirements Engineering: Foundation for
effectively address the issues and challenges gathered from the Software Quality, ser. Lecture Notes in Computer Science, M. Glinz and
expert interviews in our method. Together with an industry P. Heymans, Eds. Springer Berlin Heidelberg, 2009, pp. 218–232.
[15] L. Chung and J. C. P. Leite, “On Non-Functional Requirements in
partner we are currently planning an empirical validation of Software Engineering.” Springer, 2009, pp. 363–379.
the method to ensure the generalizability and the applicability [16] L. Chung, B. Nixon, E. Yu, and J. Mylopoulos, Non-Functional
of the results in an industrial context. A special emphasis of Requirements in Software Engineering, ser. International Series in
Software Engineering. Springer US, 2000, vol. 5.
this empirical validation will be put on the completeness and [17] M. Daneva, L. Buglione, and A. Herrmann, “Software Architects’
expressiveness of the constraint language. Experiences of Quality Requirements: What We Know and What We
Future work shall specially concentrate on ensuring scalabil- Do Not Know?” in Requirements Engineering: Foundation for Software
Quality, ser. Lecture Notes in Computer Science, J. Doerr and A. L.
ity of the method for large-scale software engineering projects Opdahl, Eds. Springer Berlin Heidelberg, 2013, pp. 1–17.
and particularly for efficiently handling multiple heterogenous [18] E. C. S. Cardoso, J. P. A. Almeida, G. Guizzardi, and R. S. S.
interests being attached to the same task. Also, the existing tool Guizzardi, “Eliciting goals for business process models with non-
functional requirements catalogues,” in Enterprise, Business-Process
support for operationalization of measures shall be extended and Information Systems Modeling, T. Halpin, J. Krogstie, S. Nurcan,
to also integrate data accruing in ERP systems, such as E. Proper, R. Schmidt, P. Soffer, and R. Ukor, Eds. Berlin, Heidelberg:
data relating to internal business-process and procurement Springer Berlin Heidelberg, 2009, pp. 33–45.
[19] P. Bourque and R. E. Fairley, Guide to the Software Engineering Body of
performance, customer relationship management, and product- Knowledge, 3rd ed. Los Alamitos, CA, USA: IEEE Computer Society
related revenue indicators. Press, 2014.
[20] M. Glinz, “Rethinking the notion of non-functional requirements,” in
R EFERENCES Proceedings of the Third World Congress for Software Quality (3WCSQ
[1] D. Zowghi and C. Coulin, “Requirements Elicitation: A Survey of 2005), vol. 2, Munich, Germany, 2005, pp. 55–64.
Techniques, Approaches, and Tools,” in Engineering and Managing [21] M. Broy, “Rethinking Nonfunctional Software Requirements,” Computer,
Software Requirements, A. Aurum and C. Wohlin, Eds. Springer Berlin vol. 48, no. 5, pp. 96–99, May 2015.
Heidelberg, 2005, pp. 19–46. [22] “ISO/IEC/IEEE International Standard - Systems and software engineer-
[2] J. D. Blaine and J. Cleland-Huang, “Software Quality Requirements: ing – Life cycle processes –Requirements engineering,” ISO/IEC/IEEE
How to Balance Competing Priorities,” IEEE Software, vol. 25, no. 2, 29148:2011(E), pp. 1–94, Dec. 2011.
pp. 22–24, Mar. 2008. [23] “ISO/IEC/IEEE 25030:2007 International Standard - Software product
[3] P. Berander and A. Andrews, “Requirements Prioritization,” in Engineer- Quality Requirements and Evaluation (SQuaRE) - Quality requirements,”
ing and Managing Software Requirements, A. Aurum and C. Wohlin, 25030:2007, 2018, (accessed 2019/12/04). [Online]. Available: https:
Eds. Berlin, Heidelberg: Springer, 2005, pp. 69–94. //www.iso.org/standard/35755.html
[4] J. Annett, “Hierarchical Task Analysis,” in The Handbook of Task Analysis [24] P. Runeson and M. Höst, “Guidelines for conducting and reporting case
for Human-Computer Interaction. London, UK: Taylor & Francis, 2003, study research in software engineering,” Empirical Software Engineering,
pp. 67–82. vol. 14, no. 2, pp. 131–164, Apr. 2009.
[5] P. Haindl, R. Plösch, and C. Korner, “An Extension of the QUAMOCO [25] R. K. Yin, Case Study Research and Applications: Design and Methods,
Quality Model to Specify and Evaluate Feature-Dependent Non- 6th ed. Los Angeles: SAGE Publications, Inc, Nov. 2017.
Functional Requirements,” in 2019 45th Euromicro Conference on
Software Engineering and Advanced Applications (SEAA). Kallithea-
Chalkidiki, Greece: IEEE, Aug. 2019, pp. 19–28.

AESP20: 1st Workshop on Requirement Management in Enterprise Systems Projects @ SE20, Innsbruck, Austria 9