In recent years, there has been a growing regulatory burden on information systems. Simultaneously, the process of implementing these regulations remains a cumbersome activity. This paper addresses the complexity of developing a practical regulatory knowledge modelling process for semi-automated compliance assessment in the context of information systems. A proposed practical lightweight ontology and its information extraction process are designed to address these challenges, with a focus on practical usability. While serving as a validation providing preliminary feedback for artefact refinement, this pilot study yields promising initial results. The iterative and participatory methodology applied in developing the information extraction process demonstrates efectiveness, particularly in idealised scenarios, laying the foundation for future refinement and enhancement. Future investigations will explore the usability implications of collaborative eforts between legal experts and technicians, aiming to validate modelling capacity across diverse information types, including essential technical aspects.
models often use complex notations, identified as potential obstacles for legal experts by Bartolini [
In this paper, we focus on the validation of the usability of a regulatory information extraction process, grounded in a regulatory information ontology developed with a minimalist approach. This ontology serves as the cornerstone for a tool-supported process aimed at improving information system compliance assessment and has been preliminary tested on the European Medical Device Regulation (MDR) and GDPR.
This pilot study is framed as an experimental case study [
The paper is structured as follows: Section 2 reviews related work, Section 3 introduces the ARRCIS ontology, Section 4 presents our regulatory information extraction process, Section 5 presents our validation process, Section 6 and 7 discuss the results and limitations. Lastly, Section 8 ofers concluding remarks.
While regulations have been a subject of study in requirements engineering [
Previous studies have focused on extracting regulatory information with two main objectives: (i)
Compliance assistance through process improvement, particularly in requirements engineering, and
(ii) Compliance assessment within systems or organisations, either manually or through automation
(see Table 1). These studies developed various models in line with these objectives. Goal-oriented
model [
Several authors have explored the usability of regulatory ontologies in various contexts. Elgammal et
al. [19] emphasised usability as a crucial criterion for assessing the quality of ontologies, especially in
the context of automated compliance evaluation. Zeni et al. [15, 20] developed a tool for annotating
legal texts to enhance usability for non-legal experts. Boella et al. [
In this section, while not the primary focus of this article, we first briefly introduce our ontology proposal, which serves as the basis for an information extraction process, with an emphasis on its minimalism.
Our lightweight ontology outlines regulatory concepts required for conducting semi-automated compliance assessments, where calculations are performed automatically based on user-provided information. These regulatory concepts are presented in Figure 1. In order to enhance practical applicability, we endorse a flexible approach to compliance evaluation that considers multiple sources of assessment data as dependency on other provision, questionnaires, static code analysis etc. For a more concrete illustration, Table 2 and Table 3 provides an illustrative example of modelling a provision within the European Medical Device Regulation, applicable to software and hardware medical devices.
Our aim is to achieve a minimal solution, defined as one utilising the least number of distinct concepts while providing suficient expressiveness to accomplish the specified goals. To ensure suficient expressiveness, we iteratively tested our approach across several regulations to develop our ontology before assessing its usability, as discussed in this article.
A comprehensive review of the articles cited in Table 1 aford us the opportunity to compare the core
concepts extracted from standards by various authors with diverse objectives. We identified 17 distinct
types of information, labelled from A to Q and describe the rationale for their classification is the
following. References and obligation types are explicitly detailed in all studies. Regarding requirements,
Anish et al. (2019) [
We intentionally exclude in our approach concepts labelled C, E, G, H, O, P, and Q, with details
provided below. Certain pieces of information are exclusively extracted by single ontologies. These
include the object targeted by the obligation [15], the goal of involved stakeholders [
Our ontology use fewer or at least the same number of concepts in comparison to other research with objectives of assisted compliance assessment, by ignoring ’(V)’ marked information types and considering minimality as the number of distinct concepts used. For example, in contrast to the work of Torre et al. (2019) [17] that have similar objectives, our research incorporates fewer concepts. The distinction between our works lies in their use of the ’variation point’ concept, employed to address a technical peculiarity in European Regulations. Although we could adopt a more minimal approach, we have chosen to include the concept of ’Relationships between provisions’. While not strictly necessary for evaluation, this concept was integrated because we believed it simplifies the modelling process for legal experts. Incorporating this does not contradict our goal as we view minimality as a tool to enhance overall usability. Our proposal demonstrates a level of minimality comparable to Kerrigan Law [18]. However, unlike Kerrigan Law [18], our approach considers stakeholders like all the other cited papers. Agarwal et al. (2018) [14], contrary to our work, do not seek to automate the evaluation of relevance, evident in their exclusion of the ’logical combination of conditions’ concept.
Regarding the articles by Siena et al. (2009) [
The regulatory information extraction process adheres to several key principles2. The primary focus is on provisions that define requirements impacting computer systems, whether in development, management, or commercialisation. Each paragraph that outlines a system-afecting requirement constitutes an entry in the regulatory model. This means that requirements from diferent paragraphs are consistently documented as separate entries, even when they share common application conditions. For each requirement, the associated application conditions are identified and added to the model. However, if a single paragraph contains multiple requirements with distinct conditions, each <condition, requirement> pair is treated as a unique model entry. A requirement can be included without restating it as long as it has a clear subject (a stakeholder) and a verb expressing the obligation. Conditions can also be directly extracted from the standard, provided they represent a single condition; otherwise, they need to be broken down and reassembled with logical operators. Traceability is maintained by appending a reference to each extracted piece of information (requirement or condition). This reference must be unique to enable the exploitation of the relationships between the provisions. For each requirement, application conditions are represented with logical expressions, combining atomic conditions with logical operators. A dependency tree is created by identifying which requirements depend on others, thus clarifying the hierarchical relationships among provisions. Each requirement and condition has a precise specification of the information needed to assess compliance that we called ’Necessary Assessment Data’ or ’NAD’. To allow the data collection of each of these NAD, tree types of data collection method are then tailored (although a wide range of methods can be used): (i) individual questions to collect each NAD, (ii) SPARQL to query Resource Description Framework (RDF) files and (iii) ’Compliance dependency’ that, if a provision’s compliance relies on other provisions, will allow the assessment system to evaluate the compliance status of related provisions. Finally, a logical combination of NAD in a logical structure is created to allow for a automatic generation of compliance value, enabling more streamlined data collection and compliance assessment.
Our regulatory information extraction process stands out for its minimalism both in terms of rules, which makes it flexible in its utilisation and evolution, and relying on a regulatory ontology built on a limited set of information.
We posits that this extraction process, that afords flexibility in its utilisation and evolution is more likely to be deemed ’fit for purpose’ and, consequently, more usable, aligning with Brooke’s definition of usability [22], which succinctly characterises usability as the ’appropriateness to a context’. Nevertheless, it is acknowledged that the minimalism inherent in an ontology may introduce inherent complexity, potentially constraining usability, as underscored by Elgammal et al. [19].
In light of these theoretical considerations, we posit that our regulatory information extraction process should exhibit adequate usability to extract, from a standard, comprehensive data essential for automating the evaluation process. 2The regulatory information extraction process used is appended to the current paper in Appendix A in the form and language used during the validation
The concept of usability used in this paper aligns with Brooke’s [22], defining usability as the quality of appropriateness to a given context. Conforming to ISO 9241-11:1998, usability is expansively characterised as the "Extent to which a product can be used by specified users to achieve specified goals with efectiveness, eficiency, and satisfaction in a specified context of use."
This paper context being the evaluation of a regulatory information extraction process, three metrics can be used. The first one is the efectiveness, it assesses the process’s proficiency in achieving its goals, scrutinising how adeptly users can model all requisite information while adhering to form and content constraints. The second one is the eficiency, it measures the temporal aspects of the task, recognising time as an important resource for users engaged in the process. The last one is the user satisfaction, usually evaluated through questionnaires or interviews, ofering insights into the subjective experiences and contentment levels of users interacting with the process.
The validation procedure is the following. Legal experts, chosen for their deep understanding of a specific regulation, are invited to carry out the process. This selection minimises potential limitations related to a lack of understanding of the regulation being used. Strict adherence to the process is maintained without external assistance. The three previously described metrics are employed for evaluation: • Efectiveness : This metric assesses the process’s ability to achieve its goals by determining whether all required information were accurately modelled according to the specified constraints of the extraction process and its underlying ontology. This is achieved through a comparison with a reference model established in advance by one of the authors. • Eficiency : This metric is assessed through the measurement of the time required to complete the task, considering time as a crucial resource for users. • Satisfaction: This metric assess user satisfaction through directed interviews conducted after task completion. The user is interviewed by the evaluator to discuss task performance and any challenges encountered during the process.
The process undergoes modification and iteration until a satisfactory state is reached. The primary aim is to validate that our regulatory information extraction process, constructed on a minimal yet suficiently expressive ontology, is efectively usable for legal experts, enabling them to generate information that streamlines the automation of the compliance evaluation process.
The validation conducted focuses on the usability of the regulatory information extraction process within the GDPR context, as employed by four academic researchers at the Faculty of Law, University of Namur, chosen for their specialisation in privacy law. The validation process is outlined as follows.
First feedback: A concise 3-page guide explaining the information extraction process was given to three legal experts. They were instructed to model GDPR provisions 13.1, 14.1, 30.5, and 37.1. These specific provisions were identified by the experts as both complex and crucial for thorough testing of a regulatory information extraction process. Subsequent to the initial phase, a focus group was conducted to gather opinions, gain deeper insights, and refine the methodology. The quality of their modelling results was then assessed based on a standard modelling conducted by the researcher prior to this test. This evaluation aimed to determine if all the information had been modelled, if the form of the information adhered to the guide, and if the meaning of what was modelled respected both the guide and the standard.
Second feedback: After adding examples and simplifying specific technical sentences in the newly revised 6-page guide, the fourth legal expert from the Faculty of Law at the University of Namur applied the guide to test its usability. This time, the expert focused on modelling provisions 13.3, 20.1, and 32.4 of the GDPR to broaden the range of tested provisions and avoid potential criticisms of overfitting in our solution. Similar to the first interview, a semi-structured interview ensued to gather opinions from the expert. As with the initial phase, the quality of the results was then evaluated in the same manner as previously described.
In the initial feedback session, the three legal experts devoted approximately 90 minutes to the examination of four GDPR provisions, resulting in an average time of 22 minutes per provision (as illustrated in Table 5). However, they were unable to complete the assigned task successfully, managing to extract only specific information categories, including Reference, Requirement, Stakeholder, Conditions, and Logical combinations of conditions. Among the information they failed to extract, the ’relationships between provisions’ was only there to ease the modelling process. We therefore consider that the presence of this non-essential concept is not validated and it has not been considered for the next iteration. Instead, users will have to systematically consider all applicable conditions for each requirements within the ’Logical combinations of conditions’ rather than the particular conditions specific to these requirements.
In terms of user satisfaction, experts expressed challenges during interviews, particularly in understanding certain technical concepts such as hierarchical dependencies, as well as terms like ’formula’ and ’textual’ Moreover, they conveyed a sense of frustration due to their inability to extract the entirety of the required information and the unexpected time investment in the process.
In the feedback session conducted after the modifications were made to the guide, the legal expert dedicated 30 minutes to work on three GDPR provisions, resulting in an average time of 10 minutes per provision (as illustrated in Table 5). Unlike the previous experts, on this occasion, the expert successfully extracted all the information, except for the ’Data Collection Method’, citing unfamiliarity with the SPARQL language as the reason. Notably, the expert did not achieve flawless extractions for two provisions, as the data entered under ’Necessary Assessment Data’ did not align with the expected content because they systematically confused information needed to assess relevance with information needed to assess compliance. It is clear that a legal expert masters these two concepts and that the quality of the guide is the reason why they have not modelled correctly. Nevertheless, the expert expressed satisfaction with the outcome of the task and the time invested, which corresponded to the duration deemed necessary for task completion.
Although we conducted tests with only four experts, Nielsen and Landauer [23] demonstrated in their work that this sample size should be suficient to detect the majority of usability issues. In each evaluation session, six concepts were consistently modelled correctly, reinforcing our confidence that this segment of the ontology is indeed usable by other legal experts. Furthermore, the positive evolution observed in terms of efectiveness, eficiency, and satisfaction indicates that our evaluation process has yielded positive outcomes. Our proposal demonstrated improved usability based on initial feedback, resulting in heightened user satisfaction, accelerated modelling, and more comprehensive provision modelling. Following the revision of our 3-page guide, legal expert exhibited increased willingness to engage in complex reasoning, such as formulating requests using pseudo-code logic.
Even after this iterative process, our guide and ontology are certainly not free from imperfections, as the last user employing the latest version of our guide failed to model all information perfectly. Moreover, we observed that legal experts sometimes inclined towards a classification-oriented approach, categorising text elements into information types. This approach occasionally posed challenges to task execution.
This evaluation process has brought to light that, for the sake of eficiency, certain information should not be extracted by legal experts due to its technical nature. In practice, legal experts consistently extracted essential data requiring expertise in the standard, while leaving out those demanding other technical skills. This prompts us to reconsider our information extraction process and conduct it in multiple stages with the involvement of various stakeholders. In this revised approach, legal experts would still play a crucial role, supported by more technically oriented profiles to formalise the more technical aspects.
Our study is based on certain assumptions and comes with some limitations and threats to validity.
In terms of potential threats, our engagement involved a rather specific profile among the experts: researchers well-versed in the studied standard, essentially experts among experts. They possess an indepth understanding of the standard under consideration, and it remains unknown how they would fare with a diferent standard or how the level of expertise might impose limitations on their performance in this task. While the involvement of four users should theoretically enable us to identify the majority of usability issues [23], our study is constrained by the homogeneity of profiles and expertise, preventing the establishment of real-world conditions.
Throughout this investigation, we solicited feedback from our process’s intended users, suggesting that our methodology holds promise for developing a practical regulatory information extraction process. However, uncertainties persist regarding the comparative usability of our proposal in relation to alternative approaches. Additionally, our findings would benefit from validation through application to a more extensive and diverse user sample.
In this pilot study, our primary focus centred on the validation of the regulatory information extraction process, a crucial component within a larger processing pipeline designed for achieving automatic regulatory compliance of information systems. Specifically, our attention was directed towards optimising the usability of the resultant model, guided by a regulatory information ontology. The ontology-based approach recognises the necessity of human intervention due to current limitations in computer-based legal information extraction.
The theoretical foundation of our approach emphasises the balance between minimalism and expressiveness in the regulatory ontology, aligning with the principles advocated by Ajani et al. [24] and Brooke’s definition of usability [ 22]. While minimalism is perceived as enhancing flexibility, a critical factor in usability, potential complexities are acknowledged, as cautioned by Elgammal et al. [19].
While acknowledging that this article serves as an evaluation providing preliminary feedback for refining the artefact, we have observed promising results. The iterative and participatory methodology employed in developing the ontology has demonstrated its efectiveness, particularly in idealised scenarios, laying the groundwork for future refinement and improvement.
In the broader context, our methodology contributes to the design science literature, presenting a pilot study of a future full-scale experimental case study that will systematically integrate theoretical foundations with practical application. This study sets the stage for future investigations into the usability implications of collaborative work between technicians and legal experts, intending to validate the modelling capacity across various information types, including more technical aspects. Additionally, our plans include the evaluation and refinement of the ontology based on additional quality criteria such as expressiveness and comprehensiveness. A prospective large-scale evaluation within an industrial environment is deemed essential to further validate the usability and practical applicability of our approach.
This work is partially supported by the "Doctorat en Entreprise" program of the Walloon region, Belgium (convention 8097). for Healthcare (SEH), IEEE, Montreal, QC, Canada, 2019, pp. 25–28. doi:10.1109/SEH.2019. 00012. [12] K. Winter, S. Rinderle-Ma, Untangling the GDPR Using ConRelMiner, arXiv:1811.03399 [cs] (2018).
ArXiv: 1811.03399. [13] H. J. Pandit, D. O’Sullivan, D. Lewis, Exploring GDPR Compliance Over Provenance Graphs Using
SHACL, in: SEMANTICS Posters & Demos, 2018, p. 4. [14] S. Agarwal, S. Steyskal, F. Antunovic, S. Kirrane, Legislative Compliance Assessment: Framework, Model and GDPR Instantiation, in: Annual Privacy Forum, 2018, p. 16. doi:10.1007/ 978-3-030-02547-2_8. [15] N. Zeni, N. Kiyavitskaya, L. Mich, J. R. Cordy, J. Mylopoulos, GaiusT: supporting the extraction of rights and obligations for regulatory compliance, Requirements Engineering 20 (2015) 1–22. doi:10.1007/s00766-013-0181-8. [16] T. D. Breaux, M. W. Vail, A. I. Anton, Towards Regulatory Compliance: Extracting Rights and Obligations to Align Requirements with Regulations, in: 14th IEEE International Requirements Engineering Conference (RE’06), 2006, pp. 49–58. doi:10.1109/RE.2006.68, iSSN: 2332-6441. [17] D. Torre, G. Soltana, M. Sabetzadeh, L. C. Briand, Y. Aufinger, P. Goes, Using Models to Enable Compliance Checking Against the GDPR: An Experience Report, in: 2019 ACM/IEEE 22nd International Conference on Model Driven Engineering Languages and Systems (MODELS), IEEE, Munich, Germany, 2019, pp. 1–11. doi:10.1109/MODELS.2019.00-20. [18] S. Kerrigan, K. H. Law, Logic-based regulation compliance-assistance, in: Proceedings of the 9th international conference on Artificial intelligence and law - ICAIL ’03, ACM Press, Scotland, United Kingdom, 2003, p. 126. doi:10.1145/1047788.1047820. [19] A. Elgammal, O. Turetken, W.-J. Van Den Heuvel, M. Papazoglou, On the Formal Specification of Regulatory Compliance: A Comparative Analysis, in: P. P. Maglio, M. Weske, J. Yang, M. Fantinato (Eds.), Service-Oriented Computing, volume 6470, Springer Berlin Heidelberg, Berlin, Heidelberg, 2011, pp. 27–38. doi:10.1007/978-3-642-19394-1_4, series Title: Lecture Notes in Computer Science. [20] N. Zeni, L. Mich, Usability issues for systems supporting requirements extraction from legal documents, in: 2014 IEEE 7th International Workshop on Requirements Engineering and Law (RELAW), IEEE, Karlskrona, Sweden, 2014, pp. 35–38. doi:10.1109/RELAW.2014.6893480. [21] J. Becker, P. Delfmann, M. Eggert, S. Schwittay, Generalizability and Applicability of Model-Based Business Process Compliance-Checking Approaches — A State-of-the-Art Analysis and Research Roadmap, Business Research 5 (2012) 221–247. doi:10.1007/BF03342739. [22] J. Brooke, SUS - a quick and dirty usability scale, Usability evaluation in industry Vol. 189 (1996) pp. 4–7. [23] J. Nielsen, T. K. Landauer, A mathematical model of the finding of usability problems, in: Proceedings of the SIGCHI conference on Human factors in computing systems - CHI ’93, ACM Press, 1993, pp. 206–213. doi:10.1145/169059.169166. [24] G. Ajani, G. Boella, L. Di Caro, L. Robaldo, L. Humphreys, S. Praduroux, P. Rossi, A. Violato, The european legal taxonomy syllabus: A multi-lingual, multi-level ontology framework to untangle the web of european legal terminology, Applied Ontology 11 (2017) 325–375. doi:10.3233/ AO-170174.
Le but est de remplir un tableau avec des informations tirées de la norme. Chaque ligne dans le tableau est initié par un couple <Conditions d’applications, Obligations>, nous ne sommes donc intéressés que par ces 2 concepts (les considérants, les définitions etc. ne doivent pas être inscrits dans le tableau). De plus, il ne faut traiter que les obligations ayant un impact sur les systèmes informatiques, que cela soit sur leur développement, leur gestion ou leur commercialisation. Si après la lecture d’un paragraphe, vous répondez “oui” à la question “est-ce que je dois savoir ça si je développe, gère ou vend un système informatique”, alors vous devez prendre en compte le paragraphe, sinon, non.
Chaque ligne dans le tableau contient toutes les informations associées à une ou plusieurs obligations tirées d’un même paragraphe. Ainsi, des obligations tirées de paragraphes diférents sont donc toujours inscrites sur autant de lignes qu’il y a de paragraphes diférents, même si elles partagent des conditions d’applications communes. Tous les paragraphes de la norme ne définissant pas des obligations, tous les paragraphes ne doivent pas entrer dans le tableau. Dans le cas où un paragraphe définit plusieurs obligations, celles-ci ne doivent pas être séparées en plusieurs lignes dans le tableau sauf si leurs conditions d’application sont diférentes (par exemple dans le cas où un paragraphe formule une obligation et une exception à l’obligation de base formulant ainsi une obligation alternative). Si leurs conditions d’application difèrent, il faut écrire autant de ligne qu’il n’y a d’association <condition d’application, obligation>. Il est tout à fait possible d’inscrire les obligations dans le tableau sans les reformuler tant qu’elles contiennent un sujet et un verbe clair matérialisant l’obligation.
Chaque ligne dans le tableau porte comme référence le numéro du paragraphe dont est tiré le ou les obligations. Ce numéro doit être unique car il servira à référencer cette ligne dans le tableau plus tard.
Ainsi, si par exemple le paragraphe 12.2 définit deux obligations avec chacune des conditions d’application diférentes, deux lignes doivent être ajoutées au tableau avec par exemple comme nom “12.2 partie 1” et “12.2 partie 2” afin de les diférencier.
Lors de l’évaluation de l’applicabilité des dispositions, il est rarement eficace de parcourir une norme dans l’ordre d’apparition de ses dispositions. Ainsi, pour terminer l’initiation du tableau, il est nécessaire de faire apparaître la hiérarchie (souvent implicite) dans l’application des dispositions de la norme, afin de créer un arbre de dépendance.
Dans l’arbre ci-dessous (Figure 2), qui représente les dépendances entre les dispositions au niveau de leur applicabilité, l’article 10.3 (au milieu) n’est applicable que si les articles 5.3, 5.1 et 1.1 sont appliqués. L’article 5.3 n’étant lui-même applicable que si l’article 5.1 est appliqué etc.
Pour cela, il est nécessaire de se poser la question pour chaque paragraphe “quelles dispositions de la norme je dois appliquer pour appliquer cette disposition” : ces dispositions sont les dispositions “parentes” de la disposition étudiée et doivent être ajoutées au tableau. Attention ! Si plusieurs dispositions “parentes” sont identifiées, seule la ou les dispositions “en bout de chaîne” doivent être inscrites.
Ainsi, dans l’arbre en exemple (Figure 2), si par exemple il a été identifié que les dispositions parentes pour le paragraphe 10.2 sont les paragraphes 10.1, 5.1 et 1.1 (c’est à dire qu’il faut respecter les conditions d’applications de ces 3 dispositions pour appliquer le paragraphe 10.2) et si par exemple le paragraphe 10.1 a lui-même comme disposition parente le paragraphe 5.1, alors seul le paragraphe 10.1 doit être inscrit dans le tableau à la ligne de la disposition 10.2. Car l’enchaînement 5.1 -> 10.1 sera lui inscrit à la ligne de la disposition 10.1.
Finalement, comme chaque ligne du tableau doit contenir un couple <Condition d’application, Obligation>, il reste à inscrire la ou les conditions d’application associées à l’obligation. Il y a deux possibilités : Soit la disposition traitée formule la ou les conditions d’application. Celles-ci doivent alors simplement être inscrites dans le tableau à la ligne correspondante à cette disposition. Soit la disposition traitée ne formule pas de nouvelles conditions d’application. Dans ce cas, il faut copier les conditions inscrites dans la ou les dispositions parentes (inscrites à l’étape précédente dans le tableau) à la ligne correspondante à cette disposition. Les conditions sont toujours inscrites sous la forme “Si. . . ”. Si plusieurs conditions sont inscrites dans une même cellule, celles-ci commencent chacune par “Si. . . ” et sont séparées par des opérateurs “et” ou “ou”. Des parenthèses peuvent également être utilisées pour combiner des conditions et exprimer des relations plus complexes.
4 données supplémentaires doivent être inscrites au tableau. Celles-ci sont dérivées des 4 informations déjà inscrites à l’étape précédente
Deux étapes sont nécessaires ici.
En premier lieu, il est nécessaire d’identifier parmi toutes les conditions d’application inscrites dans le tableau celles dont le sens est identique et rassembler une occurrence de chaque conditions d’application diférentes dans un tableau annexe. Ensuite, à chaque condition d’application inscrite dans ce tableau annexe doit être assigné une référence unique (par exemple le numéro du paragraphe d’où est tiré la première occurrence d’une condition)
En second lieu, il faut inscrire dans le tableau principal une formule représentant les conditions d’applications écrites initialement sous une forme en langage naturel.
Le but ici est d’expliciter comment observer la conformité de chaque disposition. 2 concepts sont combinables avec les opérateurs logiques “et” et “ou” :
La dépendance : si l’obligation est de la forme “le système doit être conforme à telles dispositions de la norme”, cela signifie que la conformité de la disposition dépend de la disposition d’autres dispositions. Il faut expliciter cela pour que la machine puisse récupérer la valeur de conformité des dispositions ciblées afin d’établir une valeur de conformité. Dans ce cas, inscrire dans le tableau à la “Case A” la ou les dispositions en question
La collecte d’information : des informations sur le système sont nécessaires pour évaluer la conformité. Dans ce cas, inscrire dans le tableau à la “Case B” les informations à croiser ou observer pour évaluer la conformité. Par exemple : “Observer si une documentation nommée ... existe et si elle a été mise à jour il y a moins de x mois”, “Observer si un marquage de conformité est afiché à l’utilisateur”, etc. Il est nécessaire d’être très clair car ces phrases seront ensuite traduites dans un langage compréhensible par la machine.