skip to main content

This content will become publicly available on September 1, 2024

Title: Accountable Design for Individual, Societal, and Regulated Values in the UAV Domain
Software systems are increasingly expected to address a broad range of stakeholder values representing both personal and societal values as well as values ensconced as laws and regulations. Whereas laws and regulations must be fully addressed, other human values need to be carefully analyzed and prioritized within the context of candidate architectural designs. The majority of prior work has investigated requirements engineering techniques for either regulatory compliance or for human-values, we take an integrated approach which simultaneously considers laws and regulations as well as societal and personal human values throughout the system analysis, specification, and design process. We illustrate our approach through detailed examples drawn from a multi-drone system regulated by the USA Federal Aviation Authority (FAA) and operating in a domain rich with human and societal values. We then discuss requirements engineering challenges and solutions unique to identifying analyzing, and prioritizing human, societal, and regulatory requirements, and ultimately for designing accountable software systems.  more » « less
Award ID(s):
Author(s) / Creator(s):
; ;
Publisher / Repository:
Date Published:
Journal Name:
31st {IEEE} International Requirements Engineering Conference, {RE} 2023, Hannover, Germany, September 4-8, 2023
Page Range / eLocation ID:
287 to 292
Subject(s) / Keyword(s):
human values traceability regulations design decisions accountable design
Medium: X
Hannover, Germany
Sponsoring Org:
National Science Foundation
More Like this
  1. Regulations outline high-level guidance or expectations for a profession or industry. Analyzing laws or regulations is one way a software developer would derive and document regulatory compliance requirements within their software design. However, ambiguities within regulations can make it challenging to define technical software design specifications for regulatory requirements. Further, due to the subjective nature of ambiguous phrasing within a law or regulation, the interpretation of the legal text can differ based on the interpreter’s perspective. Our study examines whether software developers can analyze regulatory ambiguities as a group using our modeling process and our online Ambiguity Heuristics Analysis Builder (AHAB) tool. Eleven participants formed three groups and modeled ambiguities within a regulation using our process and tool. Modeling regulatory ambiguity, while difficult for our participants, allowed them to communicate potential issues, ask meaningful questions, and deepen their knowledge of the regulation. Ambiguity modeling allows developers to articulate interpretation and compliance issues with the laws to other parties (i.e., lawyers) and document this requirement analysis step for future use. Documenting these intermediate steps is rarely highlighted in requirement analysis. However, it is useful to negotiate with regulators, avoid negligence, and show due diligence toward regulatory compliance. It can also lead to clarifying guidance software developers need to make better, more compliant choices during software design. 
    more » « less
  2. Abstract

    Water allocation occurs within systems that include market‐driven and nonmarket approaches; these are often nested within complex collections of laws, contracts, and customs, and embody cultural definitions of the nature of water as a commodity or a right and the nature of fair exchanges. Understanding the dynamics of such an allocation system, including the ways that it may change through time and the ways that it can be modified to better achieve societal goals, can be challenging. One promising approach is agent‐based modeling (ABM), and specifically models in which the agents dynamically adapt to the system that they create. The potential for such modeling in the domain of water systems is only beginning to be explored. We present a highly abstract but illustrative example of an adaptive system and its analysis to show the potential for the ABM approach.

    This article is categorized under:

    Engineering Water > Planning Water

    Human Water > Rights to Water

    Engineering Water > Methods

    Human Water > Water Governance

    more » « less
  3. Ensuring software security is a critical task for a deliverable software system in today’s world, and its proper implementation guarantees the quality and security of the information ingested, stored, and processed by the system. It is imperative to introduce computer science and computer engineering students (CS/CE) with the secure software design practices early in their curriculum. This approach will help them understand fundamentals of secure programming, vulnerabilities in software systems, and secure software development before joining the industry workforce. In this paper, we propose an educational framework that integrates software security concepts in a software engineering design course. We envision that the framework will engage CS/CE students applying security principles and practices in different phases of the software development life cycle (SDLC) process. Our work focuses on review of common security requirements, policies, and mechanisms related to specific use cases as well as how those requirements are defined during the software design. 
    more » « less
  4. Compliance reviews within a software organization are internal attempts to verify regulatory and security requirements during product development before its release. However, these reviews are not enough to adequately assess and address regulatory and security requirements throughout a software’s development lifecycle. We believe requirements engineers can benefit from an improved understanding of how software practitioners treat and perceive compliance requirements. This paper describes an interview study seeking to understand how regulatory and security standard requirements are addressed, how burdensome they may be for businesses, and how our participants perceived them in the software development lifecycle. We interviewed 15 software practitioners from 13 organizations with different roles in the software development process and working in various industry domains, including big tech, healthcare, data analysis, finance, and small businesses. Our findings suggest that, for our participants, the software release process is the ultimate focus for regulatory and security compliance reviews. Also, most participants suggested that having a defined process for addressing compliance requirements was freeing rather than burdensome. Finally, participants generally saw compliance requirements as an investment for both employees and customers. These findings may be unintuitive, and we discuss seven lessons this work may hold for requirements engineering. 
    more » « less
  5. When dealing with safety–critical systems, various regulations, standards, and guidelines stipulate stringent requirements for certification and traceability of artifacts, but typically lack details with regards to the corresponding software engineering process. Given the industrial practice of only using semi-formal notations for describing engineering processes – with the lack of proper tool mapping – engineers and developers need to invest a significant amount of time and effort to ensure that all steps mandated by quality assurance are followed. The sheer size and complexity of systems and regulations make manual, timely feedback from Quality Assurance (QA) engineers infeasible. In order to address these issues, in this paper, we propose a novel framework for tracking, and “passively” executing processes in the background, automatically checking QA constraints depending on process progress, and informing the developer of unfulfilled QA constraints. We evaluate our approach by applying it to three case studies: a safety–critical open-source community system, a safety–critical system in the air-traffic control domain, and a non-safety–critical, web-based system. Results from our analysis confirm that trace links are often corrected or completed after the work step has been considered finished, and the engineer has already moved on to another step. Thus, support for timely and automated constraint checking has significant potential to reduce rework as the engineer receives continuous feedback already during their work step. 
    more » « less