IIBA's Definition of Business Analyst:

A business analyst works as a liaison among stakeholders in order to elicit, analyze,communicate and validate requirements for changes to business processes, policies and information systems. The business analyst understands business problems and opportunities in the context of the requirements and recommends solutions that enable the organization to achieve its goals.

IIBA's Definition of a Requirement:

A requirement is:
(1) A condition or capability needed by a stakeholder2 to solve a problem or achieve an
objective.
(2) A condition or capability that must be met or possessed by a system or system
component to satisfy a contract, standard, specification, or other formally imposed
documents.
(3) A documented representation of a condition or capability as in (1) or (2).
Requirements serve as the foundation of systems or system components. A requirement can be thought of as something that is demanded or obligatory; a property that is essential for the system to perform its functions. Requirements vary in intent and in kinds of properties. They can be functions, constraints, or other elements that must be present to meet the needs of the intended stakeholders. Requirements can be described as a
condition or capability a customer needs to solve a problem or achieve an objective. For clarification purposes, a descriptor should always precede requirements; for example, business requirements, user requirements, functional requirements.

IIBA's Definition of Requirements Types:

The types of requirements that exist vary based on the problem domain and methodology that the Business Analyst works with. For the purposes of the Business Analysis Body of Knowledge, the following types of standard requirements types have been defined:
• Business Requirements are higher-level statements of the goals, objectives, or needs of the enterprise. They describe such things the reasons why a project is initiated, the things that the project will achieve, and the metrics which will be used to measure its success. They are detailed further in the Enterprise Analysis KA.
• User Requirements are statements of the needs of a particular stakeholder or class of stakeholders. They describe the needs that a given stakeholder has and how that stakeholder will interact with a solution. User Requirements serve as a bridge between Business Requirements and the various classes of solution requirements.
They are gathered from stakeholders as described in the Requirements Elicitation KA and documented using the techniques described in the Requirements Analysis and Documentation KA.
• Functional Requirements describe the behavior and information that the solution will manage. They describe capabilities the system will be able to perform in terms of behaviors or operations – a specific system action or response. They are further described in the Requirements Analysis and Documentation KA.
• Quality of Service Requirements capture conditions that do not directly relate to the behavior or functionality of the solution, but rather describe environmental conditions under which the solution must remain effective or qualities that the systems must have. They are also known as non-functional or supplementary requirements. They are further described in the Requirements Analysis and Documentation KA.
• Assumptions and constraints identify aspects of the problem domain that are not functional requirements of a solution, and will limit or impact the design of the solution. They are further described in the Requirements Analysis and Documentation KA.
• Implementation requirements describe capabilities that the solution must have in order to facilitate transition from the current state of the enterprise to the desired future state, but that will not be needed once that transition is complete. They are further described in the Solution Assessment and Validation KA.