Jan Jürjens’s research while affiliated with RWTH Aachen University and other places

Code-based analyzers often find too many potentially security-related issues to address them all. Therefore, issues likely to lead to vulnerabilities should be fixed first. Such prioritization requires project-specific knowledge, such as quality requirements, security-related decisions, and design, which is not accessible to code analyzers. We present TraceSEC, an automated technique for prioritizing issues according to their security-related importance to the project. Its core concept is to incorporate available design artifacts and trace links between them, thus considering the project context that the code lacks. We reduce the problem of issue prioritization to a maximum flow problem and quantify the importance of each issue by the flow from user-defined quality aspects to the issue, i.e., quantifying its impact on project-specific security preferences. Our evaluation shows that TraceSEC effectively provides automated prioritization and can be tailored to project-specific quality goals. Its prioritization correlates stronger with manual expert prioritization than SonarQube rule severities, which are commonly used in practice. In particular, TraceSEC has a higher similarity for identifying high-priority issues. TraceSEC scales reasonably well for codebases up to 4 million lines of code, and the initial setup overhead is likely to be recouped after the first automated prioritization.

Various semi-formal syntax templates for natural language requirements foster to reduce ambiguity while preserving human readability. Existing studies on their effectiveness focus on individual notations only and do not allow to systematically investigate quality benefits. We strive for a comparative benchmark and evaluation of template systems to assist practitioners in selecting appropriate ones and enable researchers to work on pinpoint improvements and domain-specific adaptions. We conduct comparative experiments with five popular template systems—EARS, Adv-EARS, Boilerplates, MASTeR, and SPIDER. First, we compare a control group of free-text requirements and treatment groups of their variants following the different templates. Second, we compare MASTeR and EARS in user experiments for reading and writing. Third, we analyse all five meta-models’ formality and ontological expressiveness based on the Bunge-Wand-Weber reference ontology. The comparison of the requirement phrasings across seven relevant quality characteristics and a dataset of 1764 requirements indicates that, except SPIDER, all template systems have positive effects on all characteristics. In a user experiment with 43 participants, mostly students, we learned that templates are a method that requires substantial prior training and that profound domain knowledge and experience is necessary to understand and write requirements in general. The evaluation of templates systems’ meta-models suggests different levels of formality, modularity, and expressiveness. MASTeR and Boilerplates provide high numbers of variants to express requirements and achieve the best results with respect to completeness. Templates can generally improve various quality factors compared to free text. Although MASTeR leads the field, there is no conclusive favourite choice, as most effect sizes are relatively similar.

Decision-making systems are prone to discrimination against individuals with regard to protected characteristics such as gender and ethnicity. Detecting and explaining the discriminatory behavior of implemented software is difficult. To avoid the possibility of discrimination from the onset of software development, we propose a model-based methodology called MBFair that allows for verifying UML-based software designs with regard to individual fairness. The verification in MBFair is performed by generating temporal logic clauses, whose verification results enable reporting on the individual fairness of the targeted software. We study the applicability of MBFair using three case studies in real-world settings including a bank services system, a delivery system, and a loan system. We empirically evaluate the necessity of MBFair in a user study and compare it against a baseline scenario in which no modeling and tool support is offered. Our empirical evaluation indicates that analyzing the UML models manually produces unreliable results with a high chance of 46% that analysts overlook true-positive discrimination. We conclude that analysts require support for fairness-related analysis, such as our MBFair methodology.