What are useful Software Engineering approaches for legislated requirements?

By Rick Jelliffe
September 29, 2009 | Comments: 4

More projects seem to be coming across my desk that ultimately involve building information systems whose primary requirements come from legislation or regulations. And sometimes even the detailed requirements.

Legislation is sometimes quite a nice Requirement Specification: it is expressed in functional/quality terms rather than internal operations, and is pretty careful in its use of logic. It has been drafted by professionals, and vetted, and thought through. It avoids design and implementation issues almost entirely, so within the great waterfall you have a lot of agility.

But legislation has two other aspects. The first is that often the primary legislation sets up a process (regulation, periodic legislative instruments) to allow change. Secondarily, the legislation becomes a test against which a deployed system can be audited: is this system in harmony with the requirements of this legislation.

But I am not really aware of a software engineering approach that treats legislative inputs as first class object for the design or functionality of the system. I guess the bottom line is that the system code needs to be parameterized both by constants and strategies, since both may be changed by legislation.

And legislation often has a good definitions system: defining a good glossary or data dictionary is often an important part of any job that involves coordination between parties and knowledge domains, so perhaps starting off by cutting and pasting the legislative definitions into a wiki might be a good way to start too: Behaviour Driven Develoment seems to emphasize the need for a common vocabulary.

But I'd love it if any readers have any pointers to approaches in this area.

A colleague today suggested that there might be this kind of semantic gap (between what the legislation actually says and the interpreted version given in typical requirements documents by regulators) in efforts like XBRL.

I am reminded of that quote (BDD's Dan North?) that the trouble with waterfall development is that the programmer is treated essentially as a typist: they just transcribe what the analyst has decided. Consequently the programmers get fed only with the minimum information for the task. And, not seeing the big picture, they can go off the rails.

Perhaps it would be good practice for any team implementing systems springing out of legislated requirements to first have a crash course on the legislation, and be able to comment their code in terms of the legislation/regulation.

You might also be interested in:


A few other aspects:
- legislation usually has a fixed implementation deadline with no provision for slippage
- legislation is written to meet a political need and this is not always compatible with operational requirements, thus leading to very messy implementations
- legislation is also often suject to incremental change on an annual basis (particularly tax legislation) with prior year's rules still applying to the relevant periods
- what seemed like a constant can often become variable because of changes in policy over time
- terminology in legislation can change for policy reasons but without changing the functionality (I've experienced this with multiple name changes to essentially the same thing over a period of a decade or so)

Being able to comment their code in terms of the legislation/regulation is a very good suggestion - better is to have full traceability to sections of the legislation so that the impact of changes to a section can be traced more readily. This is much easier said than done and can be made obsolete by syntactical rewrites of legislation (such as rewrites into plain-English).

It might be helpful to look at Systems Engineering and modeling languages such as SysML. Systems Engineering provides a framework for information models to be driven by requirements. And for those requirements to be traceable to objects in the information model. My sense is that many requirements result from company or government policies and therefore share many characteristics of legislation.

Josh: SysML definitely is in the right kind of area.

It seems a little manufacturing oriented compared to publishing (i.e. publishing: putting together different pieces into the same arrangements; manufacturing: putting together the same pieces into different arrangements) perhaps. But certainly the parameterization/allocation/requirements ideas seem in the ballpark.

Here is a link to the AGILE project (Advanced Governance of Information services through Legal Engineering).


You might also want to take a look at:

News Topics

Recommended for You

Got a Question?