A lot about the product architecture and design depends on the inputs of business requirements. The team responsible for business study and documentation must understand the severity of risk built in development stages due to wrong or incomplete interpretation of business requirements to be built in the product.
Business requirements documents include both functional and non functional requirements emerging out during the discussions with customer management and key functional managers. All these requirements become integral part of the requirement document that moves to various teams during the different stages of project development.
What if some of the crucial requirements are not captured during the study phase? Or if some of the requirements are not documented in illustrating manner which in return present wrong interpretation to developers and the product development starts moving in wrong direction.
All such ambiguous/ wrong/ incomplete developments lead to a risk of customer/ user dissatisfaction at a later stage depending on how soon or late the product built is exposed to the customer front. Such risks must have a concrete mitigation plan beforehand in order to not to lose confidence, time and reputation.