I am struggling in my brain about what the right answer is here and where the gap in our requirements gathering process is on this team.

• Non-technical BA – their role is to write Business and User requirements in the form of User Stories. When there is a compelling business reason for defining a general system behavior though they will write user stories with a system actor. They define Acceptance Criteria for these stories.

• Business Systems Analysts and SE’s – our role is to take Business and User requirements and derive Functional Requirements from these. We will generally define system actors and define system behavior with traceability back to business requirements and user stories.

The gap I am confused about is that the Business Requirements and User stories generally don’t define the necessary details needed to describe functional components and I am not sure they even should. The Non-Technical BA’s wouldn’t understand the intricacies of how to do this even if we asked them to so it seems they belong in the Functional Requirements, however according to the formal definition of functional requirements they are to define the behavior of systems:

A function is described as a set of inputs, the behavior, and outputs (see also software). Functional requirements may be calculations, technical details, data manipulation and processing and other specific functionality that define what a system is supposed to accomplish.
Functional Requirements (Wikipedia)

Everybody on the team is dealing with this differently right now. Our approved document for capturing FR’s is limited in a way that forces us to define functions of a component and not details of the component itself. Some BSA’s and SE’s are defining functions with empty conditions and acceptance criteria and using the Inputs field to define properties of the component. Others still are not even capturing the information or they have it scattered in notes that they attach to functions.

Others still argue with the Non-Technical BA’s claiming their requirements aren’t specific enough and the Scrum master’s answer is encouraging us to split things into total obfuscated oblivion with the hope that things become more estimable.

Is my understanding of the definition of functional requirements limited here?

CLARIFICATION: I felt I should clarify that when I say Business Requirements I mean VERY high level vision statements from a management level. They are almost irrelevant to the project in all but water cooler talk. The actual used requirements are User Stories.