Recently, I have been working with a large financial service provider to help them comply with regulations revolving around the Dodd-Frank regulatory bill passed after the financial crisis of 2008. The Dodd-Frank bill itself is 848 pages while the regulations born out of the law amount to almost 14,000. To give a little perspective, that amounts to about 28 tomes of the Russian novel War & Peace (Davis Polk and Wardwell LLP).

All this led me to wonder if we might be able to think about creating government legislation and regulations in the same way we approach developing software requirements—by using the requirements life cycle and visual models. Naturally there are many differences and layers of complexity between software and regulating a large industry, like financial services. However, the base principles could yet apply and I wish to highlight a few of the applicable elements.

Visual Models

We can approach regulation using visual models to help keep us focused, such as using a Business Objectives Model (BOM) to identify the problem, objective, and product concept related to the 2008 financial crisis. The perceived problem was that banks were engaging in risky lending behavior connected to mortgage derivatives, and due to their systemic importance to the economy they were given billions of dollars in emergency loans by the government. The obvious objective would be to prevent or at least mitigate the impact of something similar happening in the future, thereby saving the government and the people billions of dollars. One way to achieve this objective could be instituting new legislation like the Dodd-Frank Act to mitigate some risky behaviors (the product concept). For more on Business Objective Models, check out this blog post by one of ArgonDigital’s Business Architects.

Another visual model that might be useful to include could be an ecosystem map to explain the interconnectedness of potential legislation—which agencies will be responsible and how will it affect them? Check out an example of an ecosystem map here.

Requirements

Software requirements methodology applies at a more granular level as well, so let’s look at the individual regulations themselves. According to the law firm David Polk, the average length of every proposed rule from the Dodd-Frank Act is about 36 pages which might indicate that it is violating one of the characteristics of a good requirement, such as being “unambiguous” (look here for more). Poorly written requirements can result in poorly developed or ill-functioning software, likewise we could make the same correlation to legislation and regulation.

Additionally, we might start looking at the anatomy of a good set of requirements considering how far along the Dodd-Frank Act we can ask ourselves four questions:

Are these requirements….

• Complete? Are we missing any necessary information, such as certain inputs regarding financial statements for example?
• Consistent? Are there contradictions for how a software system must function, or task be accomplished? This could likewise be correlated to two different agencies requiring the same regulation be abided by in two different ways.
• Modifiable? Is it possible to easily make a change that will be reflected throughout the entire document? This is due to the dynamic nature of software and government where regulatory needs might change and adapt frequently.
• Traceable? Can your requirements be linked back to their origin and forward to lower level requirements? This is relevant when developing legislation that will then be developed into a regulatory code, and likewise a regulation should be able to be easily tied back to where it came from.

I have touched on only a few elements of how requirements methodology and visual models can assist in government regulation; however it can be applicable to virtually all industries whether that is software, government, or general business. As the world becomes an ever more complicated place, a framework to be able to understand and work with these additional layers will become more apparent, and the software requirements industry may hold many of the solutions.