Roboticists are grappling with how to address privacy in robot design at a time when regulatory frameworks around the world increasingly require systems to be engineered to preserve and protect privacy. This paper surveys the top robotics journals and conferences over the past four decades to identify contributions with respect to privacy in robot design. Our survey revealed that less than half of one percent of the ~89,120 papers in our study even mention the word privacy. Herein, we propose privacy preserving approaches for roboticists to employ in robot design, including, assessing a robot's purpose and environment; ensuring privacy by design by selecting sensors that do not collect information that is not essential to the core objectives of that robot; embracing both privacy and performance as fundamental design challenges to be addressed early in the robot lifecycle; and performing privacy impact assessments.

In agile software development projects, software engineers prioritize implementation over documentation to eliminate needless documentation. Is the cost of missing documentation greater than the cost of producing unnecessary or unused documentation? Even without these documents, software engineers maintain other software artifacts, such as tickets in an issue tracking system (ITS) or source code committed to a version control system (VCS). Do these artifacts contain the necessary knowledge? In this paper, we examine undocumented knowledge in an agile software development project at NTT. For our study, we collected 159 commit logs in a VCS and 102 tickets in the ITS from the three-month period of the project. We propose a ticket-commit network chart (TCC) that visually represents time-series commit activities along with filed issue tickets. We also implement a tool to generate the TCC using both commit log and ticket data. Our study revealed that in 16% of all commits, software engineers committed source code to the VCS without a corresponding issue ticket in the ITS. Had these commits been based on individual issue tickets, these "unissued" tickets would have accounted for 20% of all tickets. Software users and requirements engineers also evaluated the contents of these commits and found that 42% of the "unissued" tickets were required for software operation and 23% of those were required for requirements modification.

Although the Cuban government has tightly controlled information access for more than half a century, a small number of Cubans have access at work. In this paper, we examine Internet and social media use by early adopters in Cuba in early 2015, as we enter a time of potential change. Specifically, we explore Cubans' access limitations and the activities they do online, as well as what Internet access means to them. We conducted interviews with 12 Cuban Internet users and observed their social media use. Our findings suggest that access limitations and slow network speeds greatly restrict Cubans' Internet use. To counter these limitations, Cubans are collaborative, often conducting online research and posting photos for friends with less access. Based on these findings, we propose future work to help meet Cuban citizens' information needs.

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 arelegally 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.

Properly protecting information is in all our best interests, but it is a complex undertaking. The fact that regulation is often written by non-technologists, introduces additional challenges and obstacles. Moreover, those who design systems that collect, store, and maintain sensitive information have an obligation to design systems holistically within this broader context of regulatory and legal compliance. There are questions that should be asked when developing new requirements for information systems. For example, how do we build systems to handle data that must be kept secure and private when relevant regulations tie your hands? When building a system that maintains health or financial records for a large number of people, what do we need to do to protect the information against theft and abuse, keep the information private, AND at the same time, satisfy all governing privacy/security laws and restrictions? Moreover, how do we know that we've satisfied those laws? How do we monitor for compliance while ensuring that we're monitoring the right things? And, how do you accomplish all this in a way that can be expressed clearly to end-users and legislators (or auditors) so they can be confident you are doing the right things? We've been working on technologies to make these tasks simpler, and in some senses, automatic. In this talk, I will describe some of the research that we have been conducting to address these problems.

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.

Businesses and organizations in jurisdictions around the world are required by law to provide their customers and users with information about their business practices in the form of policy documents. Requirements engineers analyze these documents as sources of requirements, but this analysis is a time-consuming and mostly manual process. Moreover, policy documents contain legalese and present readability challenges to requirements engineers seeking to analyze them. In this paper, we perform a large-scale analysis of 2,061 policy documents, including policy documents from the Google Top 1000 most visited websites and the Fortune 500 companies, for three purposes: (1) to assess the readability of these policy documents for requirements engineers; (2) to determine if automated text mining can indicate whether a policy document contains requirements expressed as either privacy protections or vulnerabilities; and (3) to establish the generalizability of prior work in the identification of privacy protections and vulnerabilities from privacy policies to other policy documents. Our results suggest that this requirements analysis technique, developed on a small set of policy documents in two domains, may generalize to other domains.

Requirements engineers often have to develop software for regulated domains. These regulations often contain cross-references to other laws. Cross-references can introduce exceptions or definitions, constrain existing requirements, or even conflict with other compliance requirements. To develop compliant software, requirements engineers must understand the impact these cross-references have on their software. In this paper, we present an empirical study in which we measure the ability of software practitioners to classify cross-references using our previously developed cross-reference taxonomy. We discover that software practitioners are not well equipped to understand the impact of cross-references on their software.

Over time, laws change to meet evolving social needs. Requirements engineers that develop software for regulated domains, such as healthcare or finance, must adapt their software as laws change to maintain legal compliance. In the United States, regulatory agencies will almost always release a proposed regulation, or rule, and accept comments from the public. The agency then considers these comments when drafting a final rule that will be binding on the regulated domain. Herein, we examine how these proposed rules evolve into final rules, and propose an Adaptability Framework. This framework can aid software engineers in predicting what areas of a proposed rule are most likely to evolve, allowing engineers to begin building towards the more stable sections of the rule. We develop the framework through a formative study using the Health Insurance Portability and Accountability (HIPAA) Security Rule and apply it in a summative study on the Health Information Technology: Initial Set of Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology.

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.

Companies must ensure their software complies with relevant laws and regulations to avoid the risk of costly penalties, lost reputation, and brand damage resulting from noncompliance. Laws and regulations contain internal cross-references to portions of the same legal text, as well as cross-references to external legal texts. These cross-references introduce ambiguities, exceptions, as well as other challenges to regulatory compliance. Requirements engineers need guidance as to how to address cross-references in order to comply with the requirements of the law. Herein, we analyze each external cross-reference within the U.S. Health Insurance Portability and Accountability Act (HIPAA) Privacy Rule to determine whether a cross-reference either: introduces a conflicting requirement, a conflicting definition, and/or refines an existing requirement. Herein, we propose a legal cross-reference taxonomy to aid requirements engineers in classifying cross-references as they specify . Analyzing cross-references enables us to address conflicting requirements that may otherwise thwart legal compliance. We identify five sets of conflicting compliance requirements and recommend strategies for resolving these conflicts.

Online policy documents-such as privacy policies, notices of privacy practices, and terms of use-describe organizations' information practices for collecting, storing, and using consumers' personal information. Organizations need to ensure that the commitments they express in their policy documents reflect their actual business practices. This compliance is significant in the United States where the Federal Trade Commission regulates fair business practices. Therefore, the requirements engineers developing systems for organizations need to understand the policy documents in order to know the information practices with which the software must comply. The requirements engineers also must ensure that the commitments expressed in these policy documents are incorporated into the software requirements. In this paper, we present a summative case study of a commitment analysis approach. The approach was developed during a formative case study of four healthcare organizations' policy documents. Within this approach, we obtain requirements from policy documents based on our theory of commitments, privileges, and rights. During our summative case study we applied our commitment analysis approach to eight healthcare organizations' policy documents in order to validate the methodology. We discuss the results of the summative study, in which we found that most of the statements express organizational practices or procedures. The top seen classification conveys pledges made by the organization based on organizational practices. The second most seen classification expresses actions that the user is entitled to perform based on organizational practices.

Regulatory compliance is an important consideration for requirements engineering because recent regulations impose costly penalties for noncompliance. This paper details how developing production rule models can aid in acquiring software requirements from regulatory texts. Production rules enable requirements engineers to gain valuable domain knowledge of a particular legal text by providing the ability to receive precise answers to a specific query. In particular, a production rule model facilitates communication between requirements engineers and legal domain experts, supports and augments requirements elicitation, and resolves ambiguity. Prior work in this area has failed to detail a precise methodology for translating a legal text into production rules, and considered using production rule models for aiding requirements elicitation and validation. This paper introduces our production rule modeling methodology, and demonstrates this methodology using examples from a production rule model for four sections of the U.S. Heath Insurance Portability and Accountability Act (HIPAA).

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 speci-fied to comply with Section 508 of the U.S. Rehabilitation Act Amendments of 1998. This study sought to identify: limitations in existing requirements-acquisition methods; compliance gaps between previ-ously specified product requirements and Section 508; and additional sources of knowledge that are neces-sary to refine legal requirements into product require-ments 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 pre-sent these findings with several examples from Section 508 regulations and actual product requirements that are implemented in Cisco products.

We describe a case study in which we evaluated an open-source Electronic Health Record (EHR) system’s 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.

Software engineers must systematically account for the broad scope of environmental behavior, including nonfunctional requirements, intended to coordinate the actions of stakeholders and software systems. The Inquiry Cycle Model (ICM) provides engineers with a strategy to acquire and refine these requirements by having domain experts answer six questions: who, what, where, when, how, and why. Goal-based requirements engineering has led to the formalization of requirements to answer the ICM questions about when , how , and why goals are achieved, maintained, or avoided. In this article, we present a systematic process called Semantic Parameterization for expressing natural language domain descriptions of goals as specifications in description logic. The formalization of goals in description logic allows engineers to automate inquiries using who , what , and where questions, completing the formalization of the ICM questions. The contributions of this approach include new theory to conceptually compare and disambiguate goal specifications that enables querying goals and organizing goals into specialization hierarchies. The artifacts in the process include a dictionary that aligns the domain lexicon with unique concepts, distinguishing between synonyms and polysemes, and several natural language patterns that aid engineers in mapping common domain descriptions to formal specifications. Semantic Parameterization has been empirically validated in three case studies on policy and regulatory descriptions that govern information systems in the finance and health-care domains.

Information practices that use personal, financial and health-related information are governed by U.S. laws and regulations to prevent unauthorized use and disclosure. To ensure compliance under the law, the security and privacy requirements of relevant software systems must be properly aligned with these regulations. However, these regulations describe stakeholder rules, called rights and obligations, in complex and sometimes ambiguous legal language. These "rules" are often precursors to software requirements that must undergo considerable refinement and analysis before they are implementable. To support the software engineering effort to derive security requirements from regulations, we present a methodology to extract access rights and obligations directly from regulation texts. The methodology provides statement-level coverage for an entire regulatory document to consistently identify and infer six types of data access constraints, handle complex cross-references, resolve ambiguities, and assign required priorities between access rights and obligations to avoid unlawful information disclosures. We present results from applying this methodology to the entire regulation text of the U.S. Health Insurance Portability and Accountability Act (HIPAA) Privacy Rule.

Security, privacy and governance are increasingly the focus of government regulations in the U.S., Europe and elsewhere. This trendhas created a "regulation compliance problem", whereby companiesand developers are required to ensure that their software complies with relevant regulations, either through design or reengineering. We previously proposed a methodology for extracting stakeholder requirements, called rights and obligations, from regulations. In this paper, we examine the challenges of developing tool support for this process. We apply the Cerno framework for textual semantic annotation to propose a tool for semi-automatic semantic annotation of concepts that constitute sources of requirements

Customer-reported field failures provide valuable information for the requirements of the next release. Without a systematic approach, the requirements of the next release may not address the field failures, and the same problems may reoccur. In this paper, we propose a procedure for improving performance requirements based on a retrospective analysis of field failures reports and original requirements. In our procedure, the performance information from field failure reports and original requirements specifications is extracted based on a performance meta-model. The extracted information is used to construct new and revised performance requirements, following the performance refinement and evolution model. We applied this procedure on the requirements specifications and field failure reports for a commercial distributed software system. The results from our case study demonstrate that the resulting requirements integrate the information found in the field failure reports.

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.

In the United States, federal and state regulations prescribe stakeholder rights and obligations that must be satisfied by the requirements for software systems. These regulations are typically wrought with ambiguities, making the process of deriving system requirements ad hoc and error prone. In highly regulated domains such as healthcare, there is a need for more comprehensive standards that can be used to assure that system requirements conform to regulations. To address this need, we expound upon a process called semantic parameterization previously used to derive rights and obligations from privacy goals. In this work, we apply the process to the privacy rule from the U.S. Health Insurance Portability and Accountability Act (HIPAA). We present our methodology for extracting and prioritizing rights and obligations from regulations and show how semantic models can be used to clarify ambiguities through focused elicitation and to balance rights with obligations. The results of our analysis can aid requirements engineers, standards organizations, compliance officers, and stakeholders in assuring systems conform to policy and satisfy requirements

Software requirements, rights, permissions, obligations, and operations of policy enforcing systems are often misaligned. Our goal is to develop tools and techniques that help requirements engineers and policy makers bring policies and system requirements into better alignment. Goals from requirements engineering are useful for distilling natural language policy statements into structured descriptions of these interactions; however, they are limited in that they are not easy to compare with one another despite sharing common semantic features. In this paper, we describe a process called semantic parameterization that we use to derive semantic models from goals mined from privacy policy documents. We present example semantic models that enable comparing policy statements and present a template method for generating natural language policy statements (and ultimately requirements) from unique semantic models. The semantic models are described by a context-free grammar called KTL that has been validated within the context of the most frequently expressed goals in over 100 Internet privacy policy documents. KTL is supported by a policy analysis tool that supports queries and policy statement generation.

In this research, we compare three related requirements engineering efforts: an industrial effort based on use cases; a case study analyzing these use cases by means of goal analysis; and a case study analyzing the same use cases with an integrated scenario analysis approach.

We demonstrate the scenario management and requirements tool (SMaRT). It provides an intuitive Web-based interface that supports analysts as they input, manage, view, analyze, and work with scenarios and their associated episodes, requirements, goals, obstacles, and pre- and post-conditions. The tool also supports project management functions. It encompasses greater functionality through the implementation of: similarity measures to aid in the automatic identification of probable duplication, syntactic indicators of scenario dependencies, notifiers of probable coverage gaps, procedural guidance for analysts, as well as revision and evolution tracking mechanisms. We exhibit the various features of SMaRT to the requirements engineering community through live access to actual SMaRT-generated data as well as by providing hands-on access to the tool.

It has long been accepted that requirements analysis should precede architectural design and implementation, but in software evolution and reverse engineering this concern with black-box analysis of function has necessarily been de-emphasized in favor of code-based analysis and designer-oriented interpretation. In this paper, we redress this balance by describing "functional paleontology," an approach to analyzing the evolution of user-visible features or services independent of architecture and design intent. We classify the benefits and burdens of interpersonal communication services into core and peripheral categories and investigate the telephony services available to domestic subscribers over a 50-year period. We report that services were introduced in discrete bursts, each of which emphasized different benefits and burdens. We discuss the general patterns of functional evolution that this "fossil record" illustrates and conclude by discussing their implications for forward engineering of software products.

Privacy has recently become a prominent issue in the context of electronic commerce websites. Increasingly, Privacy policies posted on such websites are receiving considerable attention from the government and consumers. We have used goal-mining, to extract pre-requirements goals from post-requirements text artifacts, as a technique for analyzing privacy policies. The identified goals are useful for analyzing implicit internal conflicts within privacy policies and conflicts with the corresponding websites and their manner of operation. These goals can be used to reconstruct the implicit requirements met by the privacy policies. This paper interrelates privacy policy and requirements for websites; it introduces a privacy goal taxonomy and reports the analysis of 23 Internet privacy policies for companies in three health care industries: pharmaceutical, health insurance and online drugstores. The evaluated taxonomy provides a valuable framework for requirements engineering practitioners, policy makers and regulatory bodies, and also benefits website users.

It has long been accepted that requirements analysis should precede architectural design and implementation, but in software evolution and reverse engineering this concern with black-box analysis of function has necessarily been de-emphasized in favor of code-based analysis and designer-oriented interpretation. We redress this balance by describing 'functional paleontology': an approach to analyzing the evolution of user-visible features or services independent of architecture and design intent. We classify the benefits and burdens of interpersonal communication services into core and peripheral categories and investigate the telephony services available to domestic subscribers over a fifty-year period. We report that services were introduced in discrete bursts, each of which emphasized different benefits and burdens. We discuss the general patterns of functional evolution that this "fossil record" illustrates and conclude by discussing their implications for forward engineering of software products.

Diverse uses of information technology (IT) in organizations affect privacy. Developers of electronic commerce, database management, security mechanisms, telecommunication and collaborative systems should be aware of these effects and acknowledge the need for early privacy planning during the requirements definition activity. Public concerns about the collection of personal information by consumer-based Web sites have led most organizations running such sites to establish and publish privacy policies. However, these policies often fail to align with prevalent societal values on one hand and the operational functioning of Web-based applications on the other. Assuming that such misalignments stem from imperfect appreciation of consequences and not an intent to deceive, we discuss concepts, tools and techniques to help requirements engineers and IT policy makers bring policies and system requirements into better alignment. Our objective is to encourage RE researchers and practitioners to adopt a more holistic view of application and system specification, in which a system or application is seen as an engine of policy enforcement and values attainment.

Evolutionary prototyping focuses on gathering a correct and consistent set of requirements. The process lends particular strength to building quality software by means of the ongoing clarification of existing requirements and the discovery of previously missing or unknown requirements. Traditionally, the iterative reexamination of a systems requirements has not been the panacea that practitioners sought, due to the predisposition for requirements creep and the difficulty in managing it. The paper proposes the combination of evolutionary prototyping and an aggressive risk mitigation strategy. Together, these techniques support successful requirements discovery and clarification, and they guard against the negative effects of requirements creep. We embody these techniques in a comprehensive software development model, which we call the EPRAM (Evolutionary Prototyping with Risk Analysis and Mitigation) model. The model was intentionally designed to comply with the Level 2 Key Process Area of the Software Engineering Institute's Capability Maturity Model. Validation is currently underway on several software development efforts that employ the model to support the rapid development of electronic commerce applications.

Scenarios have proven effective for eliciting, describing and validating software requirements; however, scenario management continues to be a significant challenge to practitioners. One reason for this difficulty is that the number of possible relations among scenarios grows exponentially with the number of scenarios. If these relations are formalized, they can be more easily identified and supported. To provide this support, we extend the benefits of project-wide glossaries with two complementary approaches. The first approach employs shared scenario elements to identify and maintain common episodes among scenarios. The resulting episodes impose consistency across related scenarios and provide a way to visualize their interdependencies. The second approach quantifies similarity between scenarios. The resulting similarity measures serve as heuristics for finding duplicate scenarios, scenarios needing further elaboration, and scenarios which have not yet been identified yielding valuable information about how well the scenarios provide coverage of the requirements. These two approaches, integrated with a scenario database, project glossaries, configuration management, and coverage analysis, form the basis of a useful and effective strategy for scenario management and evolution.

This paper addresses the use of goals to surface requirements for the redesign of existing or legacy systems. Goals are widely recognized as important precursors to system requirements, but the process of identifying and abstracting them has not been researched thoroughly. We present a summary of a goal-based method (GBRAM) for uncovering hidden issues, goals, and requirements and illustrate its application to a commercial system, an Intranet-based electronic commerce application, evaluating the method in the process. The core techniques comprising GBRAM are the systematic application of heuristics and inquiry questions for the analysis of goals, scenarios and obstacles. We conclude by discussing the lessons learned through applying goal refinement in the field and the implications for future research.