Business analysts or product owners developing software requirements in a regulated industry have surely encountered the challenges that come with defining and managing regulatory compliance requirements. And unfortunately, those requirements are among the most critical to get right. Faulty compliance requirements not only put your projects at risk, but they can put your organization itself in a dangerous position legally and financially.
Understanding the challenges associated with defining and managing high-quality regulatory compliance requirements is the first step to doing just that. Here are six challenges that top the list:
#1: No simple matter
The business of managing regulatory compliance is not a simple one. In most organizations, it requires coordinated efforts across multiple teams as they respond to rapidly changing, hard-to-interpret laws and guidelines. Those teams must have strong capabilities in governance, risk management and compliance – interdependent capabilities that are complex even in small organizations. They require highly experienced people and well-defined business processes. Business analysts need a clear understanding of this complex environment to develop complete, accurate compliance requirements. This is a significant challenge, particularly for new business analysts or those who are new to a regulated environment.
#2: Each team has its own perspectives
Regulations usually impact multiple teams in an organization – crossing projects, systems and regions or countries. Ideally, organizations want a consistent, comprehensive set of compliance requirements across these areas, but that’s not easy. Teams tend to focus on their own goals, because that’s how they’re measured. Developing a bigger-picture view of compliance requirements is outside their scope. So, then, interpreting regulations and developing solutions happens in silos – within individual project teams, system teams or regional groups. As a result, interpretations and solutions vary. Each team develops its own, duplicating efforts and leading to multiple systems to maintain over time.
#3: Ongoing change
Regulations change — often frequently — meaning governance, risk management and compliance requirements can also change. To complicate matters further, multiple regulations may emerge or change in the same time frame – leading to a complex matrix of impacts to systems, projects and processes. Even in-flight projects must accommodate the changes induced by regulatory change, which can lead to serious delays and increased costs. Product owners and business analysts have to perform solid analysis quickly to keep the pace with regulatory change and adapt requirements appropriately without impact to project timelines and cost.
#4: Assembling stakeholders is tough
The subject matter experts that represent compliance requirements — people from legal, risk management or audit teams — are just darn busy. They have competing priorities, and they’re not usually part of core project or system teams. The result? It’s tough to get enough time with them to elicit requirements. And when regulatory change impacts multiple teams, all of which are developing compliance requirements in their silos and seeking time with compliance stakeholders, issues are magnified. Stakeholders are asked to spend time in multiple elicitation sessions, answering similar questions. They become frustrated and less likely to participate willingly. Their participation, however, is crucial. Failure to get enough interaction with the people who can answer compliance questions accurately can keep a business analyst or product owner from developing a complete, true view of compliance needs.
This challenge is often more difficult for Agile teams, because they thrive on collaboration and shared accountability within a core group of full-time team members. It’s tough for Agile teams to figure out how to involve stakeholders outside that sphere. They’re likely to be unavailable when Agile teams need them, and without their timely participation, product owners are faced with a difficult decision: live with unclear requirements or develop lower-priority features until the right people are available for elicitation.
#5: Robust analysis is neglected
Given the complexity of the regulatory environment and the diverse, distributed nature of large organizations, analyzing regulatory change, assessing its impact and identifying potential solutions is time-intensive. Teams often underestimate the effort needed. This is a major challenge for Agile teams that seek to reduce pre-work—including a lengthy up-front requirements phase—to avoid the “analysis paralysis” teams often experience. Teams that underestimate the time needed for elicitation and analysis of compliance requirements experience increased risk of getting them wrong. They also reduce the likelihood of identifying opportunities to leverage work across systems or projects.
Additionally, many organizations haven’t invested in purpose-built requirements tools – tools that provide functionality for defining new object types, visual modeling, precise multidirectional traceability and requirements reuse. Without those capabilities, it’s difficult for business analysts and product owners to perform the analysis needed to identify missing user stories, prioritize the backlog appropriately and fully understand the impact of regulatory change.
#6: Capturing non-functional requirements is hard in Agile
There’s not a great solution for documenting compliance and other nonfunctional requirements in Agile methodologies. Teams could capture them as user story acceptance criteria, but they’ll inevitably apply to multiple user stories, leading to duplication of information. With information spread across user stories, teams lack the ability to keep it consistent and manage change. It’s also impossible to generate a clear, comprehensive view of compliance requirements. Alternatively, teams could resort to Agile’s “definition of done” artifact. This artifact, however, isn’t written at the level of detail needed to be actionable for testing or deployment. It’s intended to be a reference – a tool used to assess completeness and outlying tasks.
If regulatory compliance requirements challenge you, you’re not alone. It’s become a common issue made more difficult in today’s fast-paced development environment. However, there are now best-in-class tools to help gather all the information needed to define and manage regulatory compliance requirements. Using purpose-built technology to address the issues listed above will help everyone involved to feel confident in what they’ve created and breathe a bit easier.
Ruth Zive is VP of Marketing at 
