skip to main content
US FlagAn official website of the United States government
dot gov icon
Official websites use .gov
A .gov website belongs to an official government organization in the United States.
https lock icon
Secure .gov websites use HTTPS
A lock ( lock ) or https:// means you've safely connected to the .gov website. Share sensitive information only on official, secure websites.


Search for: All records

Creators/Authors contains: "Seaman, Carolyn"

Note: When clicking on a Digital Object Identifier (DOI) number, you will be taken to an external site maintained by the publisher. Some full text articles may not yet be available without a charge during the embargo (administrative interval).
What is a DOI Number?

Some links on this page may take you to non-federal websites. Their policies may differ from this site.

  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