BZPEERReading, trust and collaboration for research
Menu

Discover

GraphFollow connections around a paper, topic or saved view.

Workspaces

HomePick up where your research flow left off.InboxHandle requests, replies and notifications from one place.CollectionsCurate reading lists, evidence sets and shareable dossiers.ResearchSee your private provenance graph, trail and imports.CollaborationMove from discovery into focused discussion rooms.PublishDraft, preview and publish full-text research articles.

Network

ExpertsFind specialists worth following or asking for help.CommunitiesJoin research circles organized around shared work.PartnersSee external organizations active around the same topics.

Opportunities

ListingsBrowse roles, calls and collaborations with clearer fit signals.

Account

Log inReturn to your reading and collaboration workspace.Create accountStart saving work, following people and joining teams.
Log inCreate account

Researcher profile

Reinhold Plösch

Reinhold Plösch contributes to research discovery and scholarly infrastructure.

ResearcherAffiliation not importedOpen to collaborate
Software Engineering

Trust snapshot

Quick read

Trust 15 - UnverifiedVerification L1Unclaimed author
3works
0followers
1topics
1close collaborators

Actions

Decide how to stay connected

Follow researcher0

Identity and collaboration

How to connect with this researcher

Claiming links this public author record to a researcher profile and unlocks direct collaboration workflows.

Log in to claim

Direct collaboration

Open a focused conversation when the fit is right

Claim this author entity first to unlock direct invitations.

Research graph

See the researcher in context

Open full explorer

Inspect adjacent work, topics, institutions and collaborators without jumping out to a separate graph page.

Building this graph slice

BZPEER is loading the nearby papers, people, topics and institutions for this page.

Published work

3 published item(s)

preprint2022arXiv

A DSL for Defining Feature-Level Quality Constraints and the Aggregation of Evaluation Results in DevOps

Quality requirements typically differ among software features, e.g., due to different usage contexts of the features, different impacts of related quality deficiencies onto overall user satisfaction, or long-term plans of the developing organization. For instance, maintainability requirements might be particularly high for software features which are frequently used or bear strategic value for the developing organization. Also, software features where even the smallest delays are perceived as negative by the user will be subjected to specially tight performance requirements. We defined an operational DSL to define software quality requirements as individual feature-level constraints based on quantitative measures. The DSL provides language elements to define the operationalization of measures from external systems, time series operations, time filters, and the automatic evaluation of these feature-level constraints in DevOps based on comparison operators and threshold values. In addition, quality ratings summarize evaluation results of features on an ordinal grading scheme. Likewise, quality gates use these quality ratings to reflect the fitness of software features or the overall software product using different states. Finally, we show an example based on a widely-adopted secure mobile messaging app that illustrates the interplay of the different DSL elements.

0 citations0 reviewsNo code linkedOpen access
preprint2022arXiv

Focus Areas, Themes, and Objectives of Non-Functional Requirements in DevOps: A Systematic Mapping Study

Software non-functional requirements address a multitude of objectives, expectations, and even liabilities that must be considered during development and operation. Typically, these non-functional requirements originate from different domains and their concrete scope, notion, and demarcation to functional requirements is often ambiguous. In this study we seek to categorize and analyze relevant work related to software engineering in a DevOps context in order to clarify the different focus areas, themes, and objectives underlying non-functional requirements and also to identify future research directions in this field. We conducted a systematic mapping study, including 142 selected primary studies, extracted the focus areas, and synthesized the themes and objectives of the described NFRs. In order to examine non-engineering-focused studies related to non-functional requirements in DevOps, we conducted a backward snowballing step and additionally included 17 primary studies. Our analysis revealed 7 recurrent focus areas and 41 themes that characterize NFRs in DevOps, along with typical objectives for these themes. Overall, the focus areas and themes of NFRs in DevOps are very diverse and reflect the different perspectives required to align software engineering with technical quality, business, compliance, and organizational considerations. The lack of methodological support for specifying, measuring, and evaluating fulfillment of these NFRs in DevOps-driven projects offers ample opportunities for future research in this field. Particularly, there is a need for empirically validated approaches for operationalizing non-engineering-focused objectives of software.

0 citations0 reviewsNo code linkedOpen access
preprint2022arXiv

Tailoring Stakeholder Interests to Task-Oriented Functional Requirements

Without a specific functional context, non-functional requirements can only be approached as cross-cutting concerns and treated uniformly across all features of an application. This neglects, however, the heterogeneity of non-functional requirements that arises from stakeholder interests and the distinct functional scopes of software systems, which mutually influence how these non-functional requirements have to be satisfied. Earlier studies showed that the different types and objectives of non-functional requirements result in either vague or unbalanced specification of non-functional requirements. We propose a task analytic approach for eliciting and modeling user tasks to approach the stakeholders' pursued interests towards the software product. Stakeholder interests are structurally related to user tasks and each interest can be specified individually as a constraint of a specific user task. These constraints support DevOps teams with important guidance on how the interest of the stakeholder can be satisfied in the software lifecycle sufficiently. We propose a structured approach, intertwining task-oriented functional requirements with non-functional stakeholder interests to specify constraints on the level of user tasks. We also present results of a case study with domain experts, which reveals that our task modeling and interest-tailoring method increases the comprehensibility of non-functional requirements as well as their impact on the functional requirements, i.e., the users' tasks.

0 citations0 reviewsNo code linkedOpen access