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, Copyright © 2020 for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0). 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 Refinement Tailoring Specification 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 profile 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 profile 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 in w vie pp rm c k values below 2 milliseconds as being very responsive, the Ch tion dit in da boo hi 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 W 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