Documenting Business Rules

  • We are developing a new in-house application.  I have been asked to help with creating the database and documenting our business rules.  Any pointers on how to document business rules within SQL Server?

    For example: we want to have several lookup tables/values that will be used corporate-wide, that define the business and how we operate.

    I'm not sure how to document, but any suggestions would help.

    Thanks, Megan

  • Hello Megan,

    I think the key word in your post is "document", not "implement". 

    Business rules are usually derived by asking the experts in the business how there work takes place.  A rule might be something like "You are not allowed to start work for the client until there is a signed purchase order".  The source of the rule in this example would be the accounting department, or perhaps one of the chief executives.  This business rule would be documented using something like MS Word.

    The implementation of the rule might be something like a referential integrity check on a table that a new project cannot be created unless there is a valid row in the accounting DB with a valid purchase order number.  The implementation of course would take place in SQL Server.

    A decent book, "Requirements before design", was written by Jerry Weinberg a few years ago and discusses a "classic" approach for identifying and capturing requirements.  A more recent approach can be found in the discussions around UML, use cases, and the various flavors of develop first, tell the customer what they require afterwards.  These approaches are sometimes known in the common press as rapid prototyping, agile development, etc. 

    There are many good automated tools for documenting the business rules.  You can find much more discussion if you do a google search on "BPR tools".  Be careful - there have been a huge number of projects that started out withthe best intentions, got completely lost in trying to document everything, and never delivered a line of code.  Your customer is paying you to deliver a product, that works, and correctly matches the current business.  They are probably not paying you to deliver an encyclopedia, and are probably not asking you to change how the company does business.  Both of these are frequent results of gettign too hung up on documenting the world.

    Ok, I'll get off the soapbox now.  Hope this helps.  Good luck

    Wayne

    (edited to correct typos)

  • Wow Wayne. Thanks so much for that thought-out response.  This info gives me a much better stepping stone to start on.

    -Megan

Viewing 3 posts - 1 through 2 (of 2 total)

You must be logged in to reply to this topic. Login to reply