Using business rules to create a better software development lifecycle

I recently finished Ron Ross' book 'Business Rule Concepts - Getting to the Point of Knowledge' in which he emphasises that true business process agility is achieved by de-coupling business rules from the processes and events which they govern.

"You get thin processes by externalising business rules ..."

I've already had an opportunity to apply this and have seen how separating rules - as well as channels - from processes, leaves you with much fewer and simpler process patterns. Over eighty procedures were simplified to a dozen "essential" processes. 

The question which most interests me, however, is how does this apply to the business process we often refer to as the Software Development Lifecycle.

What do the business rules which guide this process relate to?

• Completeness (or state) of artifacts?
• Traceability between artifacts? 
• Level of understanding? 
• Degree of risk?

What are the events (flash points) at which these rules are tested?

• Approval? 
• Product handover?
• Creation or adjustment of artifacts (requirements, design concepts, code, tests)?

Are the various rules (often refrerred to as business knowledge) actually what differentiates one method from another? So some rules drive a specific approach (e.g. All design concepts must be specified before coding begins would drive a waterfall approach).

This is a rule which drives behaviour. Other rules provide definitions (e.g. a user story consists of ...) and these may also differentiate one method from another. 

But some rules seem to be more methodology agnostic in nature (e.g. a piece of code must help to implement a specified requirement). 

So if we strip out all the software development rules, particularly the methodology-related sequencing (governance) and artifact definition rules, what are we left with?

A process which says we do analysis, design, build and test in a sequence determined by the business rules? Will this be just the activities which make up the essence of software development? If we add the methodology agnostic rules (the best practice rules) how much does this change our essential SDLC?

Do we then replace any methodology specific rules (behavioural and definitional) with a set of generic rules which are based on the facts of the project in question? That is, degree of risk, expected cost, type of development, business domain etc.

If we documented this SDLC it should be much simpler and more static than previous methodologies. We wouldn't attempt to specify the possible alternate paths through this process (as previous methodologies, PRISM etc., have done) as the permutations would be almost infinite.The possible variations in approach would not fall within any of waterfall, formal iterative or agile styles but could fit anywhere on a continuum from rigid discipline related phases to short time-boxed iterations.

The end result would be a dynamic and truly agile software development process, possibly the last SDLC we'd ever need.​