Model-based testing (MBT) is a method that supports the design and execution of test cases by models that specify theintended behaviors of a system under test. While systematic literature reviews on MBT in general exist, the state of the arton modeling and testing performance requirements has seen much less attention. Therefore, we conducted a systematic map-ping study on model-based performance testing. Then, we studied natural language software requirements specificationsin order to understand which and how performance requirements are typically specified. Since none of the identified MBTtechniques supported a major benefit of modeling, namely identifying faults in requirements specifications, we developed thePerformance Requirements verificatiOn and Test EnvironmentS generaTion approach (PRO-TEST). Finally, we evaluatedPRO-TEST on 149 requirements specifications. We found and analyzed 57 primary studies from the systematic mappingstudy and extracted 50 performance requirements models. However, those models don’t achieve the goals of MBT, whichare validating requirements, ensuring their testability, and generating the minimum required test cases. We analyzed 77 Soft-ware Requirements Specification (SRS) documents, extracted 149 performance requirements from those SRS, and illustratethat with PRO-TEST we can model performance requirements, find issues in those requirements and detect missing ones.We detected three not-quantifiable requirements, 43 not-quantified requirements, and 180 underspecified parameters in the149 modeled performance requirements. Furthermore, we generated 96 test environments from those models. By modelingperformance requirements with PRO-TEST, we can identify issues in the requirements related to their ambiguity, measur-ability, and completeness. Additionally, it allows to generate parameters for test environments

Context: In infrastructure projects with design-build contracts, the supplier delivers digital assets (e.g., 2D or 3Dmodels) as a part of the design deliverable. These digital assets should align with the customer requirements. Poorrequirements communication between the customer and the supplier is one of the reasons for project overrun. To thebest of our knowledge, no study have yet investigated challenges in requirements communication in the customer-supplierinterface.

Objective: In this article, we investigated the processes of requirements validation, requirements communication, anddigital assets verification, and explored the challenges associated with these processes.

Methods: We conducted two exploratory case studies. We interviewed ten experts working with digital assets fromthree companies working on two infrastructure projects (road and railway).

Results: We illustrate the activities, stakeholders, and artifacts involved in requirements communication, requirementsvalidation, and digital asset verification. Furthermore, we identified 14 challenges (in four clusters: requirements quality,trace links, common requirements engineering (RE), and project management) and their causes and consequences inthose processes.

Conclusion: Communication between the client and supplier in sub-contracted work in infrastructure projects is oftenindirect. This puts pressure on the quality of the tender documents (mainly requirements documents) that provides themeans for communication and controls the design verification processes. Hence, it is crucial to ensure the quality of therequirements documents by implementing quality assurance techniques

Background: Traceability is an important quality of artifacts that are used in knowledge-intensive tasks. When project budgets and time pressure are a reality, this leads often to a down-prioritization of creating trace links.

Objective:We propose a new idea that uses knowledge organization structures, such as taxonomies, ontologies and thesauri, as an auxiliary artifact to establish trace links. In order to investigate the novelty and feasibility of this idea, we study traceability in the area of requirements engineering.

Method: First, we conduct a literature survey to investigate to what extent and how auxiliary artifacts have been used in the past for requirements traceability. Then, we conduct a validation study in industry, testing the idea of taxonomic trace links with realistic artifacts.

Results: We have reviewed 126 studies that investigate requirements traceability; ninetey-one of them use auxiliary artifacts in the traceability process. In the validation study, while we have encountered six challenges when classifying requirements with a domain-specific taxonomy, we found that designers and engineers are able to classify design objects comprehensively and reliably.

Conclusions: The idea of taxonomic trace links is novel and feasible in practice. However, the identified challenges need to be addressed to allow for an adoption in practice and enable a transfer to software intensive contexts.