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.

"Requirements Analysis: From Business Views to Architecture"

"Requirements Analysis: From Business Views to Architecture" is a book by David Hay I just discovered at Amazon.ca, I think this link will work:

Requirements Analysis: From Business Views to Architecture

It is from about 2002, and I have bought it because of its rejection of OO-analysis, and the content seems to be focused on Requirements Artifacts as organized by the Zachman Framework. So, I will report back on its complete merits when I have received and read it.

I must admit, I bought a fairly inexpensive copy through eBay, but when we BA's are compensated in measure with our actual value, perhaps I will start buying retail.... :-)

"The Executive Briefing on the Issues Surrounding Getting Business Requirements Right"

Digital Mosaic is a vendor in the Requirements space, and they have released a white paper to communicate the importance of Requirements to Executive-level Management. I recommend its use if you need to do just that... and it is also just a well-written piece, so you can follow the link below to have a look.


TITLE: "The Executive Briefing on the Issues Surrounding Getting Business Requirements Right"
http://www.bitpipe.com/data/detail?id=1149175510_232&type=RES&src=KA_RES_20060607
PUBLISHER: Digital Mosaic
TYPE: White Paper

The Waterfall is not too long, the River is too wide...

Bob Lewis at his Infoworld blog/column is answering a reader question; "What is Waterfall methodology?"

Bob defines it, and trots out the old standbys about how it takes too long, and you can never go back to a previous phase, etc... and several commenters chimed in to agree, Agile proponents I presume... so I had to leave a comment too:

http://weblog.infoworld.com/lewis/archives/2006/06/what_waterfall.html?source=NLC-ADVICE2006-06-07

...which said:

The problem isn't with (the) Waterfall steps, its that the River is too wide. If you have a large project, good heavens, don't do all the requirements at once. Scope out an overall architecture, and break it up into pieces. Plan for multiple phases and releases, then do the first one, then the next one, etc. etc.. You look at any 'alternative' methodology, they will end up doing the same waterfall steps, but in iterations or some other cleverly-named approach. Sounds the same to me.

Computerworld on Requirements

A Computerworld blogger has written about Requirements, and how tough it is to get the right requirements. After getting over the shock of seeing this discussed within Computerworld, I read the blog entry and, of course, it mentions users and developers, but not Business Analysts, so I had to add a comment.

See the blog and my comments at http://www.computerworld.com/blogs/node/2657