Componentes de las competencias

In this section, we first define the various concepts concerning the inter-relationships amongst the requirements and regulations from various countries, which are ultimately used in the proposed framework for structuring them.

First, it is important to identify the relations amongst the subsets RegulC1... RegulCN as well as amongst their corresponding requirements subsets of RLC1... RLCN since it helps to trace the Regulatory requirements’ changes more efficiently.

Further, some requirements in RLCj; for j= {1...N} can be stronger versions of other re- quirements from this set. For example, if req1∈ RLCi and req2 ∈ RLCi are not equal but req1 is a refinement of req2, we call req2 is a weaker version of req1. The same principle applies for regulations.

Thus, we need to have a structured specification of legal requirements on both level, i.e., contract requirements and regulation. In this regard, we build phenomenon such as strongest set and requirements variants to be implemented as features of the requirements structuring framework.

We define the following notations for them:

 Regul∗ denotes the strongest set of legal requirements for the product P.  Regulvar denotes the set of variants of the requirements. It has two disjoint sub-

sets:

‒ RegulNvar denotes the set of variants, which cannot be compared in the sense that one of the variants is stronger than the other(s). This could be the case when the two regulations differs in the description value (e.g., material) that should be used for the products.

‒ RegulVvar denotes the set of variants, which can be compared (variants are numeric) to identify the strongest version.

Then we construct the sets RL∗, RLvar, and RLmin. Here, RLmin denotes the set of contract requirements that should be fulfilled within all countries C1... CN. It is defined on the

basis of the set RLcommon (i.e. to be contained in Regul), s.t. we do not analyse the sets RLspecificCj, for 1 ≤ j ≤ N to construct the set RLmin. While identifying RLmin, we will ana- lyse which components of a target product can be built once for one country and then can be reused for the entire product family across all countries of interest such as PC1,...,PCN. This allows us to have more efficient process for the global software and systems devel- opment. It also helps in efficient tracing of requirements changes that might come from the changes in the regulations. For example, changes in RegulC1ʹ imply changes in RLspecificC1 only since only the C1-specific part is affected, where any changes in Regul might influence global changes. While identifying RL∗ we will obtain the global view on the products’ requirements, which is not overloaded with the variants of the similar re- quirements but are just weaker versions of other.

Example 3: Let rg3C1 is defined to be the standard American Railway Engineering and Maintenance-of-way Association (AREMA), Part 10.3.20, where rg3C2 and rg3C3 are arti- ficially created on its basis (cf. Table 5-2).

Table 5-2 Regulations applicable to req3

rg3C1 Jacketing shall be a durable properly vulcanised black Neoprene; with average thickness of not less than 15 mils, and with min. thickness at any point shall not be 90% of average thickness

rg3C2 Jacketing shall be a durable properly vulcanised Chlorinated Polyethylene; with average thickness of not less than 20 mils, and with minimum thickness at any point shall not be 90% of average thickness.

rg3C3 Jacketing shall be a durable properly vulcanised Chlorosulfonated Polyethylene; with average thickness of not less than 15 mils, and with minimum thickness at any point shall not be 85% of average thickness.

In case of Example 1, rg1C1, rg1C2, and rg1C3 were already elementary, because all the characteristics were either ordinal rather than nominal (i.e., frequency band) or expressed in diverse means (i.e., emission strength limit expressed interleaving manner among elec- tric field strength and EIRP) which are not comparable.

However for Example 3, we need to simplify the regulations first. In this case, each regu- latory requirement consists of three elementary parts (we denote them by necessary in- dexes - see Table 5-3). Without necessary simplification, we obtain that rg3Ci∈ RegulCiʹ for each i ∈{1,2,3},. This also implies that the corresponding contract requirement req3 [rg3Ci] would belong to the set RLspecificCi. One might have considered them as variants of each other but this would provide an insufficient basis for further analysis. However, simplification of rg3Ci allows piecing them into a set of variants of each other such as rg3Cij, if j ∈ number of variants. We cannot compare them to assert that some of them are weaker or stronger than other. Thus, these regulatory requirements should be added to the set RegulNvar.

Table 5-3 Elementary Regulatory Requirements from rg3

rg3C11 Jacketing shall be a durable properly vulcanised black Neoprene rg3C12 The average jacketing thickness should be not less than 15 mils

rg3C13 The minimum jacketing thickness at any point shall not be 90% of aver- age thickness

rg3C21 Jacketing shall be a durable properly vulcanised Chlorinated Polyeth- ylene

rg3C22 The average jacketing thickness should be not less than 15 mils

rg3C23 The minimum jacketing thickness at any point shall not be 90% of aver- age thickness

rg3C31 Jacketing shall be a durable properly vulcanised Chlorosulfonated Poly- ethylene

rg3C32 The average jacketing thickness should be not less than 15 mils

rg3C33 The minimum jacketing thickness at any point shall not be 85% of aver- age thickness

The regulations rg3Ci2, for i ∈ {1, 2, 3} are equal (see the 2nd, the 5th and the 8th row of column two in Table 5-3), which means that they should be added to the set Regulmin and therefore also to the set Regul∗.

However the regulations rg3Ci1, for i ∈ {1, 2, 3}, they are variants of each other (see the 1st, the 4th and the 7th row of column two in Table 5-3). Since the variants (e.g., black Ne- oprene, Chlorosulfonated Polyethylene, and Chlorinated Polyethylene) are descriptive rather than being numeric, they will be placed to the set RegulNvar. But the variants (e.g., 90% average thickness, 85% average thickness) for rg3Ci3, for i ∈ {1, 2, 3} are numeric (see the 3rd, the 6th and the 9th row of column two in Table 5-3), they will be placed to the set RegulVvar. The strongest version will be both rg3C13 and rg3C23 than rg3C33 (90% > 85%) and should be added to the set RL∗.

5.5 Conclusions

In this chapter, we presented our ongoing work on requirements specification and analy- sis in a global context. Requirements for a system meant for use in multiple jurisdictions (e.g., different countries, organisations, or situations) can differ according to the needs of the particular environments. Organising the overlapping sets of requirements across the diverse environments, including variant and change management, can be challenging. This is compounded when we consider diverse regulations, in different jurisdictions, with which deployed system must comply in specific environments. We have developed a framework to deal with this diversity in a systematic manner, avoiding contradictions and non-compliance. In this framework we start the analysis at the level of regulations. This provides a basis for structured analysis of legal requirements for the system to be built for multiple jurisdictions. The chapter describes, in formal terms, the framework and an illus- trative example of the use of the framework.

Organising regulations and requirements into logical structures is anticipated to be rela- tively straightforward in terms of effort, cost and skills required for small-to-medium sized systems in a given locality. However, when dealing with large, complex systems to be deployed in diverse jurisdictions where regulatory compliance is critical, organisation of regulations along with systems regulatory requirements and change management can be challenging. This chapter shows a step in the direction towards a comprehensive solu- tion to tackle this problem. Our future work includes further investigation of the frame- work and actual variant requirements from distributed locations or contexts and to pro- vide tool support for the analysis with the framework.

5.6 References

Alves, V. N., Alves, N. C., and Valenca, G., Requirements Engineering for Software Product Lines: A Systematic Literature Review.Information and Software Technology, Vol. 52(8), pp. 806 – 820, 2010.

Breaux, T., Anton, A., Boucher, K., and Dorfman, M., Legal Requirements, Compliance and Practice: An Industry Case Study in Accessibility. International Conf. on Requirements Engineering, pp. 43–52, 2008.

Breaux, T., Gordon, D., Papanikolaou, N., and Pearson, S.,Mapping Legal Requirements to IT Controls. 6th international workshop on Requirements Engineering and Law, pp. 11–20, 2013.

Breaux, T., Vail, M., and Anton, A., Towards Regulatory Compliance: Extracting Rights and Obligations to Align Requirements with Regulations. International Conf. on

Requirements Engineering, pp. 49–58, 2006.

Buhne,S., Lauenroth, K., and Pohl, K., Modelling Requirements Variability Across Product Lines. International Conf. on Requirements Engineering, pp. 41–50, 2005.

Glinz, M., On Non-Functional Requirements. International Conf. on Requirements Engineering, IEEE Computer Society, pp. 21–26, 2007.

Kiyavitskaya, N., Krausova, A., and Zannone, N., Why Eliciting and Managing Legal

Requirements Is Hard.1st Workshop on Requirements Engineering and Law, pp. 26–30, 2008.

Maxwell, J., and Anton, A., Checking Existing Requirements for Compliance with Law Using a Production Rule Model.2nd Workshop on Requirements Engineering and Law, pp. 1–6, 2009.

Mazar,H., A Global Survey and Comparison of Different Regulatory Approaches to Non-ionizing Radhaz and Spurious Emissions.IEEE international conference on COMCAS, pp. 1–6, 2009.

Nekvi, M. R. I., and Madhavji, N. H., Impediments to Regulatory Compliance of Requirements in Contractual Systems Engineering Projects: A Case Study. ACM Trans. on Management Inf. Syst., Vol. 5, no. 3, pp. 15:1–15:35, 2015.

Nekvi,M.R.I., Ferrari, R., Berenbach, B., and Madhavji, N., Towards a Compliance Meta-model for System Requirements in Contractual Projects.4th Workshop on Requirements Engineering and Law, pp. 74–77, 2011.

Otto,P., and Anton, A., Addressing Legal Requirements in Requirements Engineering. International Conf. on Requirements Engineering, pp. 5– 14, 2007.

Pohl, K., B¨ockle, G., and Linden, F. J. V. D., Software Product Line Engineering: Foundations, Principles and Techniques. Springer, 2005.

Siena, A., Perini, A.,Susi, A., and Mylopoulos, J., A Meta-model for Modelling Law-Compliant Requirements.2ndWorkshop on Requirements Engineering and Law, pp. 45–51, 2009. Spichkova, M., Human Factors of Formal Methods. IADIS Interfaces and Human Computer

Interaction, IADIS Press, pp. 307–310, 2012.

Spichkova,M., H¨olzl, F., and Trachtenherz, D., Verified System Development with the

Autofocus Tool Chain. Workshop on Formal Methods in the Development of Software, EPTCS, pp. 17–24, 2012.

Spichkova,M., Schmidt, H., and Peake, I., From Abstract Modelling to Remote Cyber-physical Integration or Interoperability Testing. Improving systems and software engineering conference, 2013.

Spichkova, M., Schmidt, H.W., Nekvi, M.R.I. and Madhavji, N.H., Structuring Diverse

Regulatory Requirements for Global Product Development.IEEE International Workshop on Requirements Engineering and Law (RELAW), pp. 57-60, 2015.

Yin, Q., Madhavji, N., and Pattani, M., Eros: An Approach for Ensuring Regulatory Compliance of Process Outcomes.7th Workshop on Requirements Engineering and Law, IEEE Computer Society, pp. 21–24, 2013.

Chapter 6

6.

Emerging Theory

6.1 Introduction

Existing literature on regulatory compliance in RE focuses mainly on developing techno- logical solutions (e.g., (i) modelling and analysis of regulatory text (Kerrigan and Law, 2003; Antoniou et al., 1999), (ii) techniques and framework (Islam et al., 2010; Breaux et al., 2006) to elicit regulatory requirements from applicable regulations and standards for compliance, and (iii) techniques (Ramezani et al. 2012; Ingolfo et al., 2011; Saeki and Kaiya, 2008) to validate requirements for regulatory compliance. However, there is not much "empirically grounded theory" on the complexities arising from the characteristics of a large set of artefacts and their inter-relationships that exist in compliance work in RE of contract-based large systems engineering projects. For example, questions such as the following do not have responses grounded in empirical theory today:

Q1: What are the types of inter-relationships among RE artefacts existing in compli- ance work in RE?

Q2: Which characteristics of RE artefacts and their inter-relationships complicate the tasks of ensuring regulatory compliance of requirements?

Q3: What are the impediments to ascertaining regulatory compliance of requirements? Q4: What are the effort-critical activities and artefacts in compliance work in RE? Q5: How do industries measure the complexities associated with effort-critical activi- ties and artefacts involved in compliance work in RE of contractual systems engineering projects?

1

This chapter is not published as an independent research paper but is written as part of thesis composi- tion.

The main goal of this dissertation was to investigate the characteristics of compliance work in RE of large contractual systems engineering projects. Therefore, we performed multiple industrial-scale studies on identifying and characterising: (i) the artefacts used in compliance and their inter-relationships (see Chapter 2), and (ii) the impediments existing in compliance projects (see Chapter 3). Consequently, based upon the study results (e.g., artefacts types and inter-relationships, and impediments) we derive a number of RE met- rics towards creating an effort estimation model for compliance work of RE (see Chapter 4) and develop a preliminary framework for structuring regulatory requirements in global product development settings (see Chapter 5).

Based on the findings of the described studies, we propose an emerging descriptive theo- ry that inter-relates characteristics of numerous artefacts, impediments to ensuring regu- latory compliance of requirements, and emerging metrics towards an effort estimation model for compliance work in RE of large contractual systems engineering projects. The theory and its associated propositions are inferred directly from observational data fol- lowing the hypothetico-inductive model2 (Sjoberg et al., 2008). The emerging theory and propositions are described in Section 6.2. The propositions are evaluated using the crite- ria for measuring the goodness of a theory in Software Engineering (Sjøberg et al., 2008) in Section 6.3. The implications of this theory are provided in Section 6.4. Lastly, in Sec- tion 6.5, we conclude this chapter.