7.5SEMar 10, 2023
Automotive Perception Software Development: An Empirical Investigation into Data, Annotation, and Ecosystem ChallengesHans-Martin Heyn, Khan Mohammad Habibullah, Eric Knauss et al.
Software that contains machine learning algorithms is an integral part of automotive perception, for example, in driving automation systems. The development of such software, specifically the training and validation of the machine learning components, require large annotated datasets. An industry of data and annotation services has emerged to serve the development of such data-intensive automotive software components. Wide-spread difficulties to specify data and annotation needs challenge collaborations between OEMs (Original Equipment Manufacturers) and their suppliers of software components, data, and annotations. This paper investigates the reasons for these difficulties for practitioners in the Swedish automotive industry to arrive at clear specifications for data and annotations. The results from an interview study show that a lack of effective metrics for data quality aspects, ambiguities in the way of working, unclear definitions of annotation quality, and deficits in the business ecosystems are causes for the difficulty in deriving the specifications. We provide a list of recommendations that can mitigate challenges when deriving specifications and we propose future research opportunities to overcome these challenges. Our work contributes towards the on-going research on accountability of machine learning as applied to complex software systems, especially for high-stake applications such as automated driving.
5.1CYMay 29, 2023
RE-centric Recommendations for the Development of Trustworthy(er) Autonomous SystemsKrishna Ronanki, Beatriz Cabrero-Daniel, Jennifer Horkoff et al.
Complying with the EU AI Act (AIA) guidelines while developing and implementing AI systems will soon be mandatory within the EU. However, practitioners lack actionable instructions to operationalise ethics during AI systems development. A literature review of different ethical guidelines revealed inconsistencies in the principles addressed and the terminology used to describe them. Furthermore, requirements engineering (RE), which is identified to foster trustworthiness in the AI development process from the early stages was observed to be absent in a lot of frameworks that support the development of ethical and trustworthy AI. This incongruous phrasing combined with a lack of concrete development practices makes trustworthy AI development harder. To address this concern, we formulated a comparison table for the terminology used and the coverage of the ethical AI principles in major ethical AI guidelines. We then examined the applicability of ethical AI development frameworks for performing effective RE during the development of trustworthy AI systems. A tertiary review and meta-analysis of literature discussing ethical AI frameworks revealed their limitations when developing trustworthy AI. Based on our findings, we propose recommendations to address such limitations during the development of trustworthy AI.
13.3SESep 2, 2021
Non-functional Requirements for Machine Learning: Understanding Current Use and Challenges in IndustryKhan Mohammad Habibullah, Jennifer Horkoff
Machine Learning (ML) is an application of Artificial Intelligence (AI) that uses big data to produce complex predictions and decision-making systems, which would be challenging to obtain otherwise. To ensure the success of ML-enabled systems, it is essential to be aware of certain qualities of ML solutions (performance, transparency, fairness), known from a Requirement Engineering (RE) perspective as non-functional requirements (NFRs). However, when systems involve ML, NFRs for traditional software may not apply in the same ways; some NFRs may become more prominent or less important; NFRs may be defined over the ML model, data, or the entire system; and NFRs for ML may be measured differently. In this work, we aim to understand the state-of-the-art and challenges of dealing with NFRs for ML in industry. We interviewed ten engineering practitioners working with NFRs and ML. We find examples of (1) the identification and measurement of NFRs for ML, (2) identification of more and less important NFRs for ML, and (3) the challenges associated with NFRs and ML in the industry. This knowledge paints a picture of how ML-related NFRs are treated in practice and helps to guide future RE for ML efforts.
3.0SEAug 18, 2020
Modeling and Analysis of Boundary Objects and Methodological Islands in Large-Scale Systems DevelopmentRebekka Wohlrab, Jennifer Horkoff, Rashidah Kasauli et al.
Large-scale companies commonly face the challenge of managing relevant knowledge between different organizational groups, particularly in increasingly agile contexts. In previous studies, we found the importance of analyzing methodological islands (i.e., groups using different development methods than the surrounding organization) and boundary objects between them. In this paper, we propose a metamodel to better capture and analyze coordination and knowledge management in practice. Such a metamodel can allow practitioners to describe current practices, analyze issues, and design better-suited coordination mechanisms. We evaluated the conceptual model together with four large-scale companies developing complex systems. In particular, we derived an initial list of bad smells that can be leveraged to detect issues and devise suitable improvement strategies for inter-team coordination in large-scale development. We present the model, smells, and our evaluation results.
5.0SENov 1, 2019
Strategic API Analysis and Planning: APIS Technical ReportJennifer Horkoff, Juho Lindman, Imed Hammouda et al.
Traditionally, software APIs (application programming interfaces) have been viewed from a technical perspective, as a means to separate implementation from functional calls, and as a way to define a contract of software functionality. The technical benefits of APIs have been reported in numerous studies. Several reports from industry offer useful practical design considerations for APIs, including advice on collecting usage data, monetization strategies, and at what point to open an API to external parties. Although this advice can be useful, the focus is still often on the API, only without considering the role the API plays in the wider organization or how it fits into an organizational strategy. Our industrial experiences show that more information is needed about the challenges and best practices of API design and management in an organizational context. Furthermore, it has become apparent that APIs are able to play a key role as part of a strategic business plan for software-intensive companies. In this report, we present the results of our work with companies to build a framework that synthesizes and summarizes API strategies from several perspectives, including: strategic API lifecycle, lifecycle stage characteristics, lifecycle use cases and transition points, API layered architecture, BAPO, value modeling, ecosystem mapping with goal models, API metrics, goal models with metrics, and API governance guidance. Our research was carried out with an industry-academic collaboration. The framework was developed iteratively through workshops and discussions with company partners. We show how conceptual frameworks can be used to drive API strategy development, drawing on our research with several companies in practice.
T-Reqs: Tool Support for Managing Requirements in Large-Scale Agile System DevelopmentEric Knauss, Grischa Liebel, Jennifer Horkoff et al.
T-Reqs is a text-based requirements management solution based on the git version control system. It combines useful conventions, templates and helper scripts with powerful existing solutions from the git ecosystem and provides a working solution to address some known requirements engineering challenges in large-scale agile system development. Specifically, it allows agile cross-functional teams to be aware of requirements at system level and enables them to efficiently propose updates to those requirements. Based on our experience with T-Reqs, we i) relate known requirements challenges of large-scale agile system development to tool support; ii) list key requirements for tooling in such a context; and iii) propose concrete solutions for challenges.
15.7SEMay 25, 2016
iStar 2.0 Language GuideFabiano Dalpiaz, Xavier Franch, Jennifer Horkoff
The i* modeling language was introduced to fill the gap in the spectrum of conceptual modeling languages, focusing on the intentional (why?), social (who?), and strategic (how? how else?) dimensions. i* has been applied in many areas, e.g., healthcare, security analysis, eCommerce. Although i* has seen much academic application, the diversity of extensions and variations can make it difficult for novices to learn and use it in a consistent way. This document introduces the iStar 2.0 core language, evolving the basic concepts of i* into a consistent and clear set of core concepts, upon which to build future work and to base goal-oriented teaching materials. This document was built from a set of discussions and input from various members of the i* community. It is our intention to revisit, update and expand the document after collecting examples and concrete experiences with iStar 2.0.
3.3SEMay 8, 2016
Desiree: a Refinement Calculus for Requirements ProblemsFeng-Lin Li, Alexander Borgida, Giancarlo Guizzardi et al.
The requirements elicited from stakeholders are typically informal, incomplete, ambiguous, and inconsistent. It is the task of Requirements Engineering to transform them into an eligible (formal, sufficiently complete, unambiguous, consistent, modifiable and traceable) requirements specification of functions and qualities that the system-to-be needs to operationalize. To address this requirements problem, we have proposed Desiree, a requirements calculus for systematically transforming stakeholder requirements into an eligible specification. In this paper, we define the semantics of the concepts used to model requirements, and that of the operators used to refine and operationalize requirements. We present a graphical modeling tool that supports the entire framework, including the nine concepts, eight operators and the transformation methodology. We use a Meeting Scheduler example to illustrate the kinds of reasoning tasks that we can perform based on the given semantics.