(Georgia Institute of Technology, 2015)
Massey, Aaron K.; Rutledge, Richard L.; Antón, Annie; Hemmings, Justin D.; Swire, Peter P.
Ambiguities in legal texts can make the difference between regulatory compliance and non-compliance in software systems. Ambiguities are
prevalent in laws and regulations. Policy analysts who write laws and regulations and software engineers who build software systems that must comply with laws and regulations approach ambiguity differently. In our prior work, we surfaced differences between the approach taken by policy analysts
and technologists in identifying and classifying ambiguities in legal texts.
Understanding the rationale behind the identification and classification of legal ambiguities is essential to disambiguating them for requirements
engineering. Herein, we discuss a case study in which we seek to understand the rationale used to make determinations about ambiguities in legal texts.
Our 48 case study participants identified 373 ambiguities, 99.1% of which
were classified using our ambiguity taxonomy. The results of our qualitative analysis suggest participants are consistently able to identify words and
phrases they believe to be ambiguous, but are unable to express and agree on
a consistent rationale defending their classification. This result supports a
strategy for addressing ambiguity in regulatory requirements—software
engineers are likely to be successful at identifying components of legal texts that then require supplemental expertise to resolve.
(Georgia Institute of Technology, 1994)
Potts, Colin; Takahashi, Kenji; Antón, Annie
The Inquiry Cycle is a formal structure for describing and supporting
discussions about system requirements. It divides requirements analysis into
three intertwined processes: proposing or writing requirements, challenging or
discussing them, and refining or improving them. In this paper, we present
an extended example (a meeting scheduler) of the Inquiry Cycle in operation,
categorize the types of requirements discussion that occur in practice, and
suggest some heuristics for analyzing requirements. We also explain how
concrete scenarios improve analysis.