Not another attempt to "fix" requirements!

Regular readers of the blog, and there are getting to be close to 100 of you I think, will have seen my rants on requirements management as a solution for business agility before.

Over on ComputerWorld today I saw another article on companies trying to deliver what their users want by improving requirements management - In Depth: IT Looks to Halt Clashes Between Users, Developers. Now I don't have anything particularly against managing requirements better and I certainly applaud any attempt by anyone to get users and developers on the same page. That said two things need to be made clear:

1. Business rules are not like other requirements (see these book reviews for more)
2. Changing business rules are what cause most problems in systems maintenance/evolution (see the whole section on business agility)

Getting better at managing technical requirements like performance and UI design will help. Getting the business and IT to collaborate in the definition of the business rules that drive the system might actually solve the problem.

Comments

[Rolando Hernandez]

James:

Sure, companies need to manage both rules and requirements. But people simply need to understand that requirements are for the system, and rules are for the business. You need both, but they are different things for different people and different purposes.

Requirements are basically the things that the system needs to do. Rules are the way the business works - - the things that the business needs to do under various conditions.

Certainly managing system requirements better is a great idea, but that is not the solution to agility.

Getting rid of "hard-wired" rules by using business rules, however, will result in increased agility.

How? Because you no longer to wait weeks or months for IT to change the system. Imagine the business changes overnight, and the next day your new ruleset is up and running.

That agility is possible using business rules. It is impossible, however, using hard-wired rules no matter how well the requirements are managed.

Rolando