An interesting article on Fixing the requirements mess in CIO magazine caught my eye today. Christopher Lindquist does a good job of discussing some of the challenges, and some of the potential solutions, when it comes to requirements and shows how these are key issues for CIOs. I wrote on this topic once before - Writing Better Requirements - Key to Success or false hope? - and I stand by what I said there. I don't believe that writing better requirements is ever going to work as long as those requirements are descriptions of how the business needs to operate as distinct from how the system needs to operate.
What exactly do I mean by that? Well, clearly one can improve the requirements process to ensure that technical requirements relating to how the system operates, looks, performs, integrates etc can be documented effectively by business folks and then implemented by IT folks. What I do not believe is that it is useful or even possible to try and have business folks articulate how their business is supposed to operate - the business rules of their business if you like - to IT people in some fixed or semi-fixed statement of requirement. They can probably explain what kinds of things need to be happening - meta-requirements if you like - but the specifics change all the time. Why do they change? Because competitors change, regulations and policies change and the market changes. In addition there is a difference of perspective here - one I explore in Different Perspectives.
A business rules approach, and a business rules management system, can help close the gap and empower business users to manage their business while allowing IT to manage the system. How?
There are a number of advantages gained by expressing business logic in business rules and using the processing and management facilities included with a business rules management system to work with them. In brief summary:
- The separation of decision logic from mechanical implementation gives you more flexibility to make changes with minimal or zero impact on basic systems operation.
- Business rules are more understandable to business-level people, leading to better business/technical cooperation, reduced implementation times, and fewer opportunities for interpretation errors.
- Business rules management systems have predefined rule replacement features to handle system updates without interrupting service to application users.
- Rule management templates can be created to let users update, view, or create rules in a controlled manner without knowing anything about syntax or code.
I explore this in more detail in my business rules FAQ. Essentially the use of business rules technology allows the IT folks to define the system and the types of rules to be managed while allowing the business folks to directly manage the business rules within the framework established. This is like having IT define a reporting framework, templates, data marts etc and then allowing the business to define and manage the reports it actually needs day to day.
I will leave you with a quote from the article. If you do want the business and IT to cooperate, what language are they going to cooperate in? Code? I doubt it. Business rules? Maybe.
Agile development advocates argue that old-style requirements processes are too rigid, put walls between users and developers, and, given the ever-changing nature of software and business, are fated to fail. Instead, they say, developers and users should sit down together and start coding almost immediately, stopping frequently to evaluate progress and make necessary changes based on user input without feeling the need to follow a monolithic requirements document.
