I define compliance as the adherence of a work product to standards, conventions, regulations, laws, or similar prescriptions. In other words, I check whether a product or process follows rules set by internal or external parties. For example, I may follow legal rules, industry standards, corporate policies, or directions from an enterprise architect. Moreover, I consider it an important class of quality requirements. Therefore, I treat compliance like any other requirement, but often with higher priority.
First, I identify the sources of compliance. For instance, regulatory authorities, my parent company, or external stakeholders may impose constraints. In addition, organizational policies and legacy traditions may create constraints. Consequently, I list each source and link it to specific requirements. Next, I classify each constraint. I separate product constraints from process constraints. Product constraints limit how the product must behave. Process constraints limit how the team must work. Thus, I understand the direct and indirect effects on the product.
Furthermore, I check whether a constraint is negotiable. In agile terms, some constraints can change through negotiation. However, compliance rules that come from law or regulation are often non-negotiable. Nevertheless, some traditions or internal rules may be negotiable. Therefore, I question the validity of constraints. I discuss alternatives with responsible stakeholders. For example, I may ask regulatory experts or the enterprise architect to explain the reason behind a rule. If the other parties insist, then I accept the constraint and record it.
I document compliance requirements clearly. First, I capture the requirement source. Second, I state the rule in plain language. Third, I add acceptance criteria and test cases. In addition, I link each compliance item to system requirements and design decisions. Consequently, I improve traceability. Moreover, I use this traceability for estimation, testing, and audits. Thus, I reduce the risk of missing a regulatory need.
I involve the right people early. For instance, I invite legal, compliance officers, and subject matter experts to reviews. Also, I bring stakeholders into planning and negotiation. Meanwhile, I keep developers informed about constraints that affect design. As a result, I avoid late rework and delays.
I assess the impact of compliance on cost and schedule. Therefore, I estimate effort for specification, verification, and certification. In addition, I prioritize compliance items based on criticality and risk. For example, I treat legally required items as high priority. Consequently, I allocate more RE effort to those items.
Finally, I test compliance continuously. First, I write acceptance tests that reflect the regulation or standard. Second, I run these tests during development. Third, I keep evidence for audits. In summary, compliance requires early identification, clear documentation, stakeholder engagement, and continuous verification. Hence, I treat compliance as a central part of Requirements Engineering.