Ok firstly we need to come clean. We know that our Business Requirements are not just Business Requirements but also include technical requirements of both functional and nonfunctional flavours. We called it that due to peer pressure, and also not to bog you down in documentation and semantics. You're welcome...
A requirement is a statement of what something must do. Requirements usually begin with the phrase, "The system must", but we ask you to omit that text to keep things lean. New processes and systems, for example, often have hundreds or even thousands of requirements. This is why the practice of 'requirements management' was invented.
Requirements elicitation is literally its own field in academia and studied rigorously for improvement opportunities as it is often cited as the single most important factor in software development success. After all, if you don't understand the needs of the right people, you will certainly not deliver them by accident through the project. While we cannot provide you expertise in requirements elicitation, here are some practices to follow:
- Get the right people in the room. Make sure all user groups are represented and that they are refereed so that one or more people are not suppressing some of the other voices
- Plant an expert in the room, preferably someone unbiased and nonpolitical, to help the folks dream the 'art of the possible' for the future state versus just reinventing the same tired processes and systems
Requirements are classified by type for the purpose of sorting, and classified by importance, for the purpose prioritization.
As a tip, the requirements designated as "mandatory" should be very few, since a mandatory requirement means that if the system does not possess this feature, the entire project should be abandoned.