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.
The fields are part of the conversation that should be had. They may be written down if that is useful but that is a judgment call. Keeping the documentation up to date may be challenging whereas the working software could be seen as documentation to some extent.
User Story - A Promise to have a conversation would be a blog entry about this.
Your trivial example has a couple of points that I don't know how well you'd notice this. What does it mean to "register new books?" What is "Find their availability online?" Those are where the conversation begins and once the story is done there may be new stories as perhaps those registrations have to be kept on file or reports have to be generated periodically.
Best Answer
This is one of the use cases for BDD frameworks, like Cucumber, that allow you to capture the business requirements in code and test against those requirements frequently. Other approaches I've seen used include long and complicated specification documents, large sheets of paper tacked to the wall, slide decks, and Joe, the guy at the end of the table who knows everything.