Business rules are probably ranked in the top-ten of most misunderstood terms in computer science. In order to understand what business rules are you have to understand what business applications are and how the software development process works.
The initial step in developing a new software application is to analyze the specified business area. First, business analysts abstract the real business into workflows, user roles and system interactions. These documentation artifacts are all part of a business (software) requirements specification which helps to solidify the understanding and knowledge of the system to build. Afterward, developers design and implement the solution based on these requirements and finally the QA team validates the application behaviour against the original documentation.
Business rules on the other hand are only a subset of the business requirements. Business rules are created to protect business data (the single most important asset of a company) from unauthorized access and from becoming corrupted. There are two types of business rules:
BR Filters: filters are applied whenever an authorized client requests models (copies of data). Filters implement the business rules that restrict access to data. I.e. Query restrictions on who sees what from the business.
BR Validators: validators are invoked whenever an authorized client inserts, updates or deletes any models. Validators enforce business model constraints. I.e. Modifications rules on when and how data enters the business.
As a rule of thumb, business rules are defined in terms of domain models and most importantly without a specific 'User-Interface' in mind. I.e. applications have to behave correctly without a screen! A good practice is to specify and validate the behavior with unit tests before even implementing or defining any screens. These unit tests simulate the anticipated workflows of the final application.