Aaron K. Massey

Evaluating existing security and privacy requirements for legal compliance

Governments enact laws and regulations to safeguard the security and privacy of their citizens. In response, requirements engineers must specify compliant system requirements to satisfy applicable legal security and privacy obligations. Specifying legally compliant requirements is challenging because legal texts are complex and ambiguous by nature. In this paper, we discuss our evaluation of the requirements for iTrust, an open-source Electronic Health Records system, for compliance with legal requirements governing security and privacy in the healthcare domain. We begin with an overview of the method we developed, using existing requirements engineering techniques, and then summarize our experiences in applying our method to the iTrust system. We illustrate some of the challenges that practitioners face when specifying requirements for a system that must comply with law and close with a discussion of needed future research focusing on security and privacy requirements.

Prioritizing Legal Requirements

Requirements prioritization is used in the early phases of software development to determine the order in which requirements should be implemented. Requirements are not all equally important to the final software system because time constraints, expense, and design can each raise the urgency of implementing some requirements before others. Laws and regulations can make requirements prioritization particularly challenging due to the high costs of noncompliance and the substantial amount of domain knowledge needed to make prioritization decisions. In the context of legal requirements, implementation order ideally should be influenced by the laws and regulations governing a given software system. In this paper, we present a prioritization technique for legal requirements. We apply our technique on a set of 63 functional requirements for an open-source electronic health records system that must comply with the U.S. Health Insurance Portability and Accountability Act.

Identifying and classifying ambiguity for regulatory requirements

Software engineers build software systems in increasingly regulated environments, and must therefore ensure that software requirements accurately represent obligations described in laws and regulations. Prior research has shown that graduate-level software engineering students are not able to reliably determine whether software requirements meet or exceed their legal obligations and that professional software engineers are unable to accurately classify cross-references in legal texts. However, no research has determined whether software engineers are able to identify and classify important ambiguities in laws and regulations. Ambiguities in legal texts can make the difference between requirements compliance and non-compliance. Herein, we develop a ambiguity taxonomy based on software engineering, legal, and linguistic understandings of ambiguity. We examine how 17 technologists and policy analysts in a graduate-level course use this taxonomy to identify ambiguity in a legal text. We also examine the types of ambiguities they found and whether they believe those ambiguities should prevent software engineers from implementing software that complies with the legal text. Our research suggests that ambiguity is prevalent in legal texts. In 50 minutes of examination, participants in our case study identified on average 33.47 ambiguities in 104 lines of legal text using our ambiguity taxonomy as a guideline. Our analysis suggests (a) that participants used the taxonomy as intended: as a guide and (b) that the taxonomy provides adequate coverage (97.5%) of the ambiguities found in the legal text.

Assessing the accuracy of legal implementation readiness decisions

Software engineers regularly build systems that are required to comply with laws and regulations. To this end, software engineers must determine which requirements have met or exceeded their legal obligations and which requirements have not. Requirements that have met or exceeded their legal obligations are legally implementation ready, whereas requirements that have not met or exceeded their legal obligations need further refinement. Research is needed to better understand how to support software engineers in making these determinations. In this paper, we describe a case study in which we asked graduate-level software engineering students to assess whether a set of software requirements for an electronic health record system met or exceeded their corresponding legal obligations as expressed in regulations created pursuant to the U.S. Health Insurance Portability and Accountability Act (HIPAA). We compare the assessment made by graduate students with an assessment made by HIPAA compliance subject matter experts. Additionally, we contrast these results with those generated by a legal requirements triage algorithm. Our findings suggest that the average graduate-level software engineering student is ill-prepared to write legally compliant software with any confidence and that domain experts are an absolute necessity. Our findings also indicate the potential utility of legal requirements metrics in aiding software engineers as they make legal compliance decisions.

Tracking requirements evolution by using issue tickets: a case study of a document management and approval system

Requirements evolve throughout the software life-cycle. When requirements change, requirements engineers must determine what software artifacts could be affected. The history of and rationale for requirements evolution provides engineers some information about artifact dependencies for impact analysis. In this paper, we discuss a case study of requirements evolution for a large-scale system governed by Japanese laws and regulations. We track requirements evolution using issue tickets created in response to stakeholder requests. We provide rules to identify requirements evolution events (e.g. refine, decompose, and replace) from combinations of operations (e.g. add, change, and delete) specified in the issue tickets. We propose a Requirements Evolution Chart (REC) to visually represent requirements evolution as a series of events over time, and implement tool support to generate a REC from a series of issue tickets using our rules to identify requirements evolution events. We found that the REC supports impact analysis and compliance efforts.

Aligning Requirements with HIPAA in the iTrust System

We describe a case study in which we evaluated an open-source electronic health record (EHR) systempsilas requirements for compliance with the U.S. Health Insurance Portability and Accountability Act (HIPAA). Our findings suggest that legal compliance must be requirements-driven, while establishing due diligence under the law must be test-driven.

A Requirements-based Comparison of Privacy Taxonomies

Understanding the nature of privacy regulation is a challenge that requirements engineers face when building software systems in financial, healthcare, government, or other sensitive industries. Requirements engineers have begun to model privacy requirements based on taxonomic classifications of privacy. Independently, legal research has modeled privacy harms in a taxonomic fashion. In this paper, we compare a requirements engineering taxonomy of privacy protections and vulnerabilities to a legal taxonomy of privacy harms. We seek to determine the extent to which the concepts and terminology are consistent between the two taxonomies. A consistent, standard vocabulary for privacy concepts for both requirements engineers and lawyers will improve the common understanding of privacy concepts, legal traceability and compliance auditing. We conclude that the taxonomies we analyzed are reasonably compatible. We believe this compatibility indicates that a taxonomic understanding of privacy is a promising area of research for requirements engineers.

Proposing regulatory-driven automated test suites for electronic health record systems

In regulated domains such as finance and health care, failure to comply with regulation can lead to financial, civil and criminal penalties. While systems vary from organization to organization, regulations apply across organizations. We propose the use of Behavior-Driven-Development (BDD) scenarios as the basis of an automated compliance test suite for standards such as regulation and interoperability. Such test suites could become a shared asset for use by all systems subject to these regulations and standards. Each system, then, need only create their own system-specific test driver code to automate their compliance checks. The goal of this research is to enable organizations to compare their systems to regulation in a repeatable and traceable way through the use of BDD. To evaluate our proposal, we developed an abbreviated HIPAA test suite and applied it to three open-source electronic health record systems. The scenarios covered all security behavior defined by the selected regulation. The system-specific test driver code covered all security behavior defined in the scenarios, and identified where the tested system lacked such behavior.

Evaluating Legal Implementation Readiness Decision-Making

Software systems are increasingly regulated. Software engineers therefore must determine which requirements have met or exceeded their legal obligations and which requirements have not. Requirements that have met or exceeded their legal obligations are legally implementation ready, whereas requirements that have not met or exceeded their legal obligations need further refinement. In this paper, we examine how software engineers make these determinations using a multi-case study with three cases. Each case involves assessment of requirements for an electronic health record system that must comply with the US Health Insurance Portability and Accountability Act (HIPAA) and is measured against the evaluations of HIPAA compliance subject matter experts. Our first case examines how individual graduate-level software engineering students assess whether the requirements met or exceeded their HIPAA obligations. Our second case replicates the findings from our first case using a different set of participants. Our third case examines how graduate-level software engineering students assess requirements using the Wideband Delphi approach to deriving consensus in groups. Our findings suggest that the average graduate-level software engineering student is ill-prepared to write legally compliant software with any confidence and that domain experts are an absolute necessity.