If you mean representing individual business rule checks with exceptions, then I don't think it's a very good idea. Many times you have to report more than one failed condition, and not stop on the first one.
On the other hand, I do believe that checking for all rules and then throwing an exception with the summary is a good practice.
For business rules I think @Joppe pointed out to the UML we all were thinking.
Use Case Diagrams does an excelente overview of how Actors/Roles interact with the system and what system does. For complexe Use Case, additional info explained textually will help a lot (preconditions,postconditions,dependencies on previous UC executions,etc)
There are diagrams that also does great overviews of the business at different levels:
- State Machine Diagram if there's any sort of states to be documented.
- Activity Diagram. For complexe Use Case you may need to go deep into details. The level of the details is up to you and depends on who is going to read the documentation. This one may not seem business-like documentation, but with the right level of details it could become so.
Just an advice, assign a code to each Use Case (i.e: UC-1, UC-n). These will be useful later, during UI documentation.
For UI documentation the common practice (these days) is to do wireframes. Quite better than screen-shots because it looks cleaner and simpler. For instance, take a look at WireframeSketcher
Wireframes may not be enough documentation, so, for each screen do a brief introduction and describe every button. Additionaly, do references to the UC involved into the screen (see now why UC codes are useful). This will make your documentation coherent.
The point of tools like Wireframesketcher is that they do interactive mockups. Perfect to give something interactive to the customer while you are still designing or developing.
Don't forget to document the navigation plan. Nav. Plan doesn't have UML diagram, but State Machine Diagram can be used instead. It's not for what it was made, but still.
Finally keep in mind who you are addressing to.
Technician: you can go deep into details and to use technicalities.
Not Technician: avoid technicalities (neither related to languaje nor code). Try to be clear and simple and use the same terms/words that customer uses. Think like you had no idea of programming.
Best Answer
You can create your own simple Business Rule Engine with language like Groovy and concept of Domain specific Language (DSL). Business rule written in dynamic language like Groovy (for your J2EE) allow you to change rule/business logic of the application without redeploying. Groovy also have specific features, like metaprogramming, closures, AST transformations, builders that make this task doable. It will be very painful, if not impossible to create decent DSL in java.
Creating domain specific Language (DSL) allow your business users if not code the rule themselves but at least easily read them and understand. And all you need for authoring business rules is simple text editor or Eclipse.
Groovy very well integrated into J2EE application, so you can write only rule portion in the language.
Another question do you really need power and flexibility of business rules and DSL for your application? In my case business want to change rules themselves quite often.
There are resources available if you want to dig deeper: book GroovyInAction Second edition from Manning, book - Groovy for DSL - the later one has a chapter on creating groovy Rule engine - good starting point. There is also several publications online - just goodle for groovy and dsl keywords. http://docs.codehaus.org/display/GROOVY/Writing+Domain-Specific+Languages
Drool is complex piece of software, maybe overkill for task at hand.