Legal Requirements, Compliance and Practice: An Industry Case Study in Accessibility

Abstract

U.S. laws and regulations are designed to support broad societal goals, such as accessibility, privacy and safety. To demonstrate that a product complies with these goals, businesses need to identify and refine legal requirements into product requirements and integrate the product requirements into their ongoing product design and testing processes. We report on an industry case study in which product requirements were specified to comply with Section 508 of the U.S. Workforce Investment Act (WIA) of 1998. This study sought to identify: limitations in existing requirementsacquisition methods; compliance gaps between previously specified product requirements and Section 508 of the WIA; and additional sources of knowledge that are necessary to refine legal requirements into product requirements to comply with the law. Our study reveals the need for a community of practice and generalizable techniques that can reduce ambiguity, complexity and redundancy in legal and product requirements and manage innovation in product requirements. We present these findings with several examples from Section 508 regulations and actual product requirements that are implemented in Cisco products.

Exercising Due Diligence in Legal Requirements Acquisition: A Tool-supported, Frame-Based Approach

“…For the broader challenge of aligning software requirements with relevant laws, the FBRAM is only a partial solution as evidenced by eight requirement refinement patterns, which provide reasonable explanations for the kinds of gaps that exist between legal and software requirements [8]. In addition to these patterns, we envision incorporating the FBRAM legal requirements into other requirements acquisition activities to contextualize legal requirements in the context of ongoing business practices.…”

“…To maintain traceability, the FBRAM includes a document model that maps acquired legal require-ments to official indices and titles for parts, sections and paragraphs [7]. For example, the document model maps the cross-reference §164.520(a)(2)(ii) to the two requirements "to maintain a notice" (lines 1-16) and "to provide a notice" (lines [1][2][3][4][5][6][7][8][9][10][11][12][13][14][17][18][19], whereas reference §164.520(a)(2)(ii)(A) to the sub-paragraph only refers to the first of these two requirements. The case studies reveal that the document model is critical to assist engineers with integrating constraints on requirements that are cross-referenced from other paragraphs.…”

Legally “reasonable” security requirements: A 10-year FTC retrospective

“…During this acquisition process, we identified heuristics that can be used to reproduce this study and to validate the acquired artifacts; the heuristics are reported in Section 4 with the case study findings. These artifacts represent nominal measures of the range of phenomena described by the units and can be compared to each other to identify similarities and differences using metrics that we developed in prior work [BAB08]. To compensate for errors in subjective interpretation that results from classifying phrases and sentences, multiple analysts must apply the units of analysis to the case study materials during the acquisition process.…”

Early Studies in Acquiring Evidentiary, Reusable Business Process Models for Legal Compliance

“…Another challenge includes complex legal exceptions, which Breaux et al address with a requirements prioritization method based upon priority hierarchies [2]. Finally, Breaux et al have proposed requirements refinement patterns as a method to guide engineers in the refinement of legal requirements into product requirements [3].…”

“…The method has been previously applied to the HIPAA Privacy Rule [6,2] and to the Section 508 Access Standards (36 C.F.R. §1194) [3].…”