On Efficient Collaboration between Lawyers and Software Engineers when Transforming Legal Regulations to Law-related Requirements

Transcription

1 Proceedings of the 2n d International Conference on Information Technology, ICIT June 2010, Gdansk, Poland. On Efficient Collaboration between Lawyers and Software Engineers when Transforming Legal Regulations to Law-related Requirements Anna Bobkowska I), Magdalena Kowalska 2) 1) Department of Software Engineering Faculty of ETI, Gdansk University of Technology Gdansk, Poland annab@eti.pg.gda.pl 2) SoftLex Law and Software Quality Consulting Warsaw, Poland magdalena.kowalska@softlex.com.pl Abstract - In order to develop information systems which comply with law, cooperation between lawyers and software engineers is necessary. The problem is how to transform legal regulations to law-related systems requirements efficiently. In this paper, we present both lawyer's perspective and software engineer's perspective on this problem and then we attempt to capture a common information space. The lawyer's perspective delivers a method for identifying and analyzing relevant laws and legal regulations. The software engineer's perspective discovers the specifics of dealing with law-related requirements with the use of requirements engineering as a frame of reference. The common information space includes a process of transforming legal regulations to legal requirements and a description of knowledge which must be shared in order to facilitate efficient collaboration. Keywords-software compliant with law, common information space, law-related requirements, legal analysis. I. INTRODUCTION Ensuring that information systems comply with law becomes an increasingly important aspect of software development. Information systems are developed in the areas regulated by law and more and more often legal regulations are related to Information and Communication Technologies (lct). One of the reasons why ensuring compliance with law is not easy is the diversity of possible impacts of legal regulations to IT systems. Application of domain specific legal regulations, e.g. in domain of banking, is different from applying general legal regulations, e.g. related to privacy policy. Methods of dealing with ICT related laws, e.g. concerning e-voting or e-signature, are different from methods of dealing with laws introduced in times when no computer systems existed. Law regulates different domains of human life. AdditionalJy, in some domains law aijows or requires use of information technologies and in some cases even determines some features of systems. Sometimes the text of legal regulation is clear and precise, in other cases the legal regulations are ambiguous or even contradictory. In some cases, a new system which must comply with law is developed, and in other cases, the introduction of new laws causes the modifications of existing systems. In general, this issue concerns lawyers, representatives of ICT area, business decision makers and legislators. Effective and efficient collaboration between lawyers and software engineers is a real chaijenge. Representatives of these professions use different approaches and different terminology. They have different understanding of being effective. They must collaborate on transforming legal regulations to law-related Software engineers themselves will not perform a proper analysis of the system of law and characteristics of legal regulations, and lawyers themselves will not create a correct specification of system This problem has been discussed at a few conferences, especially at Requirements Engineering and Law (RELA W) workshops. The differences between legal concepts and requirements engineering concepts have been noticed at RELA W 2008 workshop [1] and the challenges of 'standardizing terminology between law, engineering and business' and 'increased collaboration between lawyers and engineers' were indicated as important interdisciplinary challenges during the break-out sessions of this workshop. One of the ways of solving this problem is representation of legal regulations with a kind of formalism and then development of software which supports processing this form of regulations. The formalisms can be text-based [2] or diagram-based [3]. The next step in this approach is the integration of the representations of legal regulations with the descriptions of software in order to meet the challenges of documenting legal constraints for software and supporting their traceability as well as change management. The results are interesting but they are in the research phase nowadays. In 105

2 our opinion, even when these systems gain industrial maturity, they will not eliminate the need of collaboration between system engineers and lawyers in the area of law-related In our approach, we focus on facilitating collaboration between lawyers and software engineers. The goal of this paper is to analyze this problem from both lawyer's perspective and software engineer's perspective and to propose a solution with synergetic effect. The contribution is a common information space which contains a description of common knowledge necessary for efficient collaboration and a process which integrates analysis of legal regulations and resulting requirements with the activities performed during traditional requirements engineering. The paper is structured as follows. Section 2 presents the lawyer's perspective. Section 3 deals with issues related to engineering legal requirements from the software engineer's perspective. Section 4 presents the common information space. II. LAWYER'S PERSPECTIVE This section presents important issues which arise when analysing this problem from lawyer's perspective. It includes selected aspects of identifying and analysis of legal regulations related to the IT system, the priority of legal requirements over other business goals, as well as the impact of law on software development decisions. Compliance of software with the binding law at all moments of its exploitation and maintenance is a special priority. In case of conflict between legal requirements and other goals, e.g. efficiency or scope of functionality, compliance with law has the priority and other goals must be subordinated. Law-related requirements may not be omitted and their implementation can not be delayed because of decreased budget. Compliance with law means sometimes the changes that have to be made to systems. They might result from the changes in related law and legal regulations. The analysis of changeability of legal regulations allows for estimating the impact of changes regarding legal regulations on system In order to perform analysis of impact of law for system under development, one must first identify all laws and legal regulations concerning the system. Before starting the identification of related legal regulations, one has to analyse the domain in which system will operate and understand business goals of the system. With this information, one can identify properly the legal areas that the system refers to and determine which legal regulations need to be taken into consideration. The next step is analysis of the character of legal regulations in this area, e.g. whether they are stable or they are subject to frequent changes, whether they are very detailed or the subject is regulated without many constraints. The manner of acquisition of legal requirements depends on the legal system and on the degree of regulation of various domains in different countries [4]. In the EU member states apart from the national regulations, one has to deal also with the EU regulations. And in the end, the legal obligations arising from international treaties and conventions should also be included. Analysis of the identified legal regulations is the next activity. It should result in a complete list of regulations which have impact on system. The points of this analysis are: 1) identification of basic legal regulations having impact on a respective IT system 2) analysis of completeness of legal regulations in the given domain 3) analysis of the time-scope validity 4) identification of possible transitory regulations regulating the rules of solving possible conflicts between old and new regulations 5) identification of potential changes of law and possible further new regulations. The complete analysis includes also the formal aspect of legal regulations: the hierarchy of acts and regulations and the characteristics of obligation (obligatory without exception or relatively obligatory). This analysis will allow systematizing requirements imposed by law and granting priorities to respective system In the next step, transformation of identified legal regulations to law-related requirements is performed. Several legal norms may influence one requirement but also on the basis of one legal norm several system requirements may be formulated. Some legal norms concerning the economic domain that the system refers to, may have no impact on the development and functioning of the system. Lawyers should extract relevant legal regulations and software engineers should formulate detailed requirements for an IT system and place them in System Requirements Specification. In this activity, the lawyers' role is mostly a consultancy. At the end, the lawyers should verify whether all legal requirements are integrated into System Requirements Specification. III. SOFTWARE ENGINEER'S PERSPECTIVE In this section, in order to discover specifics of dealing with law-related requirements we analyze them in context of the sub-areas of requirements engineering [5]. Requirements elicitation is the process of identifying stakeholders of a system and collecting requirements as well as constraints of the system. Legal requirements elicitation is different because their source is not in users' needs or customers' expectations. Legal requirements come from the analysis of the impact of law on the system under development. The process of analysis of relevant laws and legal regulations must be performed for every system separately. Thus, the vision of system which determines domain, goals and scope of the system should be delivered as 106

3 an input. Identification of relevant laws and legal regulations and their analysis should be performed by lawyers. One can treat law as a specific stakeholder. Law is obligatory with no possibility of exclusions or negotiations. It is invisible and abstract, which might cause problems with interpretations and validation. It covers many areas of human life and when it specifies the business rules, its impact to system is to be determined. There are not many formal constraints related to the changes in law, which means that changes in law will cause changes in systems. One of best practices is delegation of a person for tracing laws and legal regulations. Requirements analysis categorizes requirements, explores their relationships, examines them for consistency, omissions and ambiguity, and prioritizes them based on users' needs. Analysis must be performed also with respect to legal regulations and law-related requirements, because of their complexity, sources in different acts, necessary interpretations and possible contradictions between legal regulations, possible contradictions between legal requirements and other The goal of legal regulations and legal requirements analysis is understanding the impact of legal regulations on the system under development as well as integration of law-related requirements with other These activities should be performed by lawyer when analysis is related only to law. Transformation of legal regulations to legal requirements must be made iteratively in cooperation between lawyers and software engineers. Software Requirements Specification (SRS) is a document which describes goals of the system under development, their requirements and constraints. A separate document describing law and legal regulation analysis in details can be prepared by lawyers. However, the requirements which have impact on system should be integrated with other parts of Software Requirements Specification. In the section of legal requirements, all legal acts, their dependencies, attributes, effectiveness periods and changeability dates should be specified. Apart from this, traditional requirements resulting from law should be specified in other sections with indication of their source in legal Validation of requirements examines entire specification for fulfillment of goals, consistency, unambiguity and conformance to standards. It is usually made during reviews. There are two aspects of validation of law-related Validation of the system from legal perspective should be made by lawyers and it should result in confirmation that entire system complies with law. This review should detect situations when law forbids features which have not been specified or solutions which are consistent with requirements but entire system does not comply with law. The second type of validation is traditional validation with examining the impact of law-related requirements on the system by developers and customers. This review should check whether such scope of system is satisfactory for customers and feasible for development team in given project constraints. IV. COMMON INFORMATION SPACE A common information space is a set of information which must be shared by lawyers and software engineers in order to collaborate effectively on transforming legal regulations to system The common information space includes: Basic knowledge about software engineering for lawyers - Lawyers do not need the knowledge about technical details of software development. However, they should understand briefly the phases of software development. As legal regulations are transformed to requirements and the lawyers should validate SRS from legal perspective, they should have a basic knowledge of requirements engineering. Basic knowledge about law for software engineers - Software engineers should understand briefly the nature of law, the basis of legislation and legal reasoning. They need to see law as an entire system of many different regulations that may have impact on IT system. They should be aware of changeability and possible contradictions of legal regulations. Specific knowledge on the border of these disciplines - It consists of the knowledge how laws and legal regulations might impact software development, maintenance and exploitation. This knowledge can be presented in the form of taxonomy of impacts of law on information systems. The next element of the common information space is a process which defines the roles, activities and artefacts when transforming legal regulations to system requirements and integrating them with other Such a process defines and facilitates efficient collaboration. Law can have a diverse impact on IT systems. From legal point of view, law can allow for the use of the system, or law can require a system with a set of specified features in a given application, or text of legal regulation in a given domain does not refer to systems. From software project's point of view, legal regulations of the domain can determine business processes which must be supported by the system, administrative procedures can set constraints on print-outs, forms, data and algorithms in information systems, or legal regulations related to IT system can be related to functional and quality requirements of the system. Law can also set constraints on development and exploitation of the system. A proposition of the process which integrates analysis of legal regulations and resulting requirements with traditional requirements engineering activities is presented in Fig. 1. This process clearly defines the responsibilities of the involved roles and the structure of activities. System's Vision which defines goals and domain must be delivered before performing any activities related to requirements, including law-related Then, identification and analysis of different kinds of requirements can be made separately. With the 107

4 Analyst Lavvyer --- perform Systems Vision identify and analyse functional and quality requirerrents transform legal regulations to requirerrents validate SRS from business and tedmical perspective Figure 1. Figure. 1. The process for integration of analysis of legal regulations and resulting requirements with traditional requirements engineering activities knowledge of analyst's expectations, lawyers can get prepared with relevant legal regulations in order to perform the transformation smoothly. The transformation is made in cooperation between the lawyer and the analyst in discussion which determines the impact of all legal regulations for the system under development. SRS is prepared by an analyst. It should contain a section of legal requirements and complete specification of system requirements related to law. The final activity is the validation of the SRS from the technical, business and legal perspectives and introduction of necessary changes. V. CONCLUSIONS When searching for a solution to the problem of developing information systems which comply with law we have focused on facilitating efficient collaboration between lawyers and software engineers. We have analyzed this problem from both lawyer's and software engineer's perspectives and on the basis of this analysis we have proposed a common information space with a process which allows to integrate analysis of legal regulations and resulting requirements with traditional activities made during requirements engineering. The strengths of this process are the synergetic use of the expertise of both professionals involved in the process, the structure of the process resulting from the detailed analysis of the phenomena and dependencies between activities, and focus on communication and collaboration which should allow to overcome misunderstandings and clarify appearing problems as early as possible. In further work, we plan to elaborate the taxonomy of impacts of Iaw on information systems. REFERENCES [1] AI. Anton, T.O. Breaux, O. Karagiannis, 1. Mylopoulos, "First International Workshop on Requirements Engineering and Law (RELAW)", Proceedings of the workshop on Requirements Engineering and Law, RELA W'08, [2] T.O. Breaux, M.W. Vail, AI. Anton, "Towards Regulatory Compliance: Extracting Rights and Obligations to Align Requirements with Regulations", 14th IEEE International Requirements Engineering Conference (RE'06). [3] A Siena, 1. Mylopoulos, A Perini, A Susi, "From Laws to Requirements", Proceedings of the workshop on Requirements Engineering and Law, RELA W'08, [4] 1. Oniszczuk, "Filozofia i teoria prawa" (Philosophy and theory of law), Beck, Warsaw [5] R.S. Pressman, O. Ince, "Software Engineering. A Practitioner's Approach", 5th edition, McGraw Hill,

5 109