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.