Thursday, September 08, 2005

What can be required of an Information System, Part 4

It’s all about the Rules:

The previous Parts have described that Information Systems have Requirements for processing (mainly data), storing data, and communication; these types of Requirements have been recognized for a long time, although not always viewed as being of relatively equal importance.

What has only more recently been recognized is that requirements for processing can often be defined in fairly straight-forward terms, but controlling that processing can be complex; all the exceptions, special cases, or alternative processing that may be needed. What is required of an Information System is to accept and use the rules of the business which drive, control and amend the system’s processing, better known as Business Rules. If this is a new or unexplored concept to the reader, I recommend visiting ; suffice it to say that defining the Business Rules that a system is required to support separate from process, data or communication requirements, results in an overall set of all Requirements of higher quality. (Of course, these different types of Requirements are not completely independent of each other; a future posting will describe how they are inter-related.)

Well, I think I am finished describing the types of Requirements that can be requested of a typical Information System. Remember, we are not talking about missile-guidance systems, or ‘Grand Theft Auto’ (see my earlier posting ‘What is an Information System?”). I am finished at this time, anyway; more types of Requirements are likely to be recognized down the road. For example, I would probably would not have identified Business Rules separately if I was writing this a decade ago.

So, given this set of Requirements, we need to (1) discover them, and (2) document them, so that Information Systems can be delivered that will actually meet the Requirements. … I will carry on with these topics in my next posting…

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.