Business requirements are what are most often thought of when we talk about requirements gathering. They are all about what the system should do in plain terms – not the “how,” but the “what.” Of course you have an idea of what you want to build, but in order to have the clearest picture of your solution, you also have to explain why it is being built. Understanding the business case goes a long way towards enabling good architecture, design and ultimately a great end-product.
When writing business requirements, you must also consider the personas involved: the different types of people who will interact with the product. Every user will have slightly different needs, and the program must be able to support all of them.
There are also a host of non-technical or non-functional requirements that should be considered. These include site performance, security, document management, etc. – things outside of the user experience.