When Dr. E.F. Codd introduced the relational model forty years ago it brought about a new way of thinking about data and how it is stored in databases that resonates with us today. In The Decision Model: A Business Logic Framework Linking Business and Technology Barbera von Halle and David Pedersen have produced a seminal work that will have a similar effect on modeling business decisions and how we manage them. Indeed, the authors have borrowed heavily from Dr. Codd in describing the guiding principles and rules one should apply to arrive at a normalized decision model.

"We've just acquired package XYZ. We'd like you to now go figure out what the business requirements are so we can implement it." How many of you have had that kind of conversation? I am going to discuss the role that use cases can fill in acquiring, extending, and rolling out a COTS package. Although use cases typically only represent 20-30% of the total requirements, they do represent a system's behavioural requirements and are of significant importance.

In larger IT shops there is usually a separate quality assurance (QA) group who develops and executes the test cases and comments on the quality of the systems they test. The requirements specifiers and QA people often find themselves at logger-heads over what is a “bug” or missed requirement vs. what is not. (See the “Inventing Requirements” forum thread for an interesting dialogue on the subject.) The QA role is too often seen as getting in the way and slowing things down.