Paul N. Otto

Addressing Legal Requirements in Requirements Engineering

Legal texts, such as regulations and legislation, are playing an increasingly important role in requirements engineering and system development. Monitoring systems for requirements and policy compliance has been recognized in the requirements engineering community as a key area for research. Similarly, regulatory compliance is critical in systems that are governed by regulations and law, especially given that non-compliance can result in both financial and criminal penalties. Working with legal texts can be very challenging, however, because they contain numerous ambiguities, cross-references, domain-specific definitions, and acronyms, and are frequently amended via new regulations and case law. Requirements engineers and compliance auditors must be able to identify relevant regulations, extract requirements and other key concepts, and monitor compliance throughout the software lifecycle. This paper surveys research efforts over the past 50 years in handling legal texts for systems development. These efforts include the use of symbolic logic, logic programming, first-order temporal logic, deontic logic, defeasible logic, goal modeling, and semi-structured representations. This survey can aid requirements engineers and auditors to better specify, monitor, and test software systems for compliance.

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.

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.

Ensuring compliance between policies, requirements and software design: a case study

Specifying correct and complete access control policies is essential to secure data and ensure privacy in information systems. Traditionally, policy specification has not been an explicit part of the software development process. This isolation of policy specification from software development often results in policies that are not in compliance with system requirements and/or organizational security and privacy policies, leaving the system vulnerable to data breaches. This paper presents the results and lessons learned from a case study that employs the Requirements-based Access Control Analysis and Policy Specification (ReCAPS) method to specify access control policies for a Web-based event registration system. The ReCAPS method aids software and security engineers in specifying access control policies derived from requirements specifications and other available sources. Our case study revealed that the ReCAPS method helps identify inconsistencies across various software artifacts, such as requirements specification, database design, and organizational security and privacy policies. Had these problems not been identified and resolved, they would have crippled later phases of software development, resulted in missing or incomplete system functionality, and compromised the systems security and privacy. This case study reinforces, validates, and extends our previous recommendations that access control policy specification should be an integral part of the software development process for information systems to achieve information assurance and improve the quality of the information system

The role of data use agreements in specifying legally compliant software requirements

Security and privacy requirements are often not explicitly stated and are often not easy to elicit. In this paper, we discuss data use agreements (DUAs) as a source of security and privacy requirements that can be leveraged by requirements engineers. Within the healthcare domain, regulations created pursuant to the U.S. Health Insurance Portability and Accountability Act (HIPAA) specify that a DUA must exist for certain uses and disclosures of protected health information as a limited data set. For compliance reasons, it is important for requirements engineers to ask for and evaluate DUAs, as they are legally binding on the parties. We discuss HIPAA-governed DUAs and the information contained within them. Using four DUAs, we apply commitment, privilege, and right (CPR) analysis to identify legally compliant requirements. Through this work, we have identified contractual compliance requirements while also identifying compliance problems in relation to DUAs.

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.

Identifying vulnerabilities and critical requirements using criminal court proceedings

Information systems governed by laws and regulations are subject to civil and criminal violations. In the United States, these violations are documented in court records, such as complaints, indictments, plea agreements, and verdicts, which thus constitute a source of real-world software vulnerabilities. This paper reports on an exploratory case study to identify legal vulnerabilities and provides guidance to practitioners in the analysis of court documents. As legal violations occur after system deployment, court records reveal vulnerabilities that were likely overlooked during software development. We evaluate established requirements engineering techniques, including sequence and misuse case diagrams and goal models, as applied to criminal court records to identify mitigating requirements that improve privacy protections. These techniques, when properly applied, can help organizations focus their risk-management efforts on emerging legal vulnerabilities. We illustrate our analysis using criminal indictments involving the U.S. Health Insurance Portability and Accountability Act (HIPAA).

Managing Legal Texts in Requirements Engineering

Laws and regulations are playing an increasingly important role in requirements engineering and systems development. Monitoring systems for requirements and policy compliance has been recognized in the requirements engineering community as a key area for research. Similarly, legal compliance is critical in systems development, especially given that non-compliance can result in both financial and criminal penalties. Working with legal texts can be very challenging, however, because they contain numerous ambiguities, cross-references, domain-specific definitions, and acronyms, and are frequently amended via new statutes, regulations, and case law. Requirements engineers and compliance auditors must be able to identify relevant legal texts, extract requirements and other key concepts, and monitor compliance. This chapter surveys research efforts over the past 50 years in handling legal texts for systems development. This survey can aid requirements engineers and auditors to better specify, test, and monitor systems for compliance.

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.