Tuesday, June 27, 2006

Computerworld on Requirements, revisited

The CW blog I wrote about early in June has had some more comments added, and I had to add a new one as well:

http://www.computerworld.com/blogs/node/2657#comment-6399

One comment was:
Great comments all but everyone failed to mention the obvious. It seems business requirements change constantly. End users know this and developers know this. Both parties struggle with the frustration created by such an environment.

So, I replied with:

Just checked back to see how this conversation, looks pretty good.

However, I must challenge the "Business Requirements change constantly" statement. In stating that, you are saying that all Business Requirements are the same in form or shape, which is absurd. Business Requirements vary in their purpose and perspective, and I classify them into at minimum the following categories:
- Business Processes
- Business Rules
- Function / System Use (Use case)
- Data Requirements
This is a ranked list, from the requirements that change the most to the ones that change the least.

Business Processes change frequently: new steps, re-ordering of steps, new restrictions. If you are building today's business process into your information system, you have built an instant legacy system. The business will start to work-around your system almost immediately. This is what workflow and and business process management systems are for. They may be computerized, but they are not 'Information' Systems.

Business Rules change less frequently, but often enough that they now have their own automation systems, known as Business Rule Engines. Do a web search to learn what you need to know about those.

That leaves your core Information system requirements, the data you store and the main functions that CRUD the data. These do change, but not very often. Creating a new customer with name and address is the same now as it was 20 years ago and will be 20 years from now.

So, understand your Business Requirements and that development of software and databases is not the only method available in meeting those requirements.

No comments:

About Me

Ontario, Canada
I have been an IT Business Analyst for 25 years, so I must have learned something. Also been on a lot of projects, which I have distilled into the book "Cascade": follow the link to the right to see more.