User stories as a three-way conversation
While teams often use the user story format as a wrapper for functional requirements, the idea was never to throw away all that valuable work that we used to do and replace it with a few words on a card as the "requirement".
The problem with the old way of functional requirements was that they took months to prepare, were done by a business analyst or solution architect in near isolation, were additive in that everything was an increase of scope and complexity, and then the whole 800-page document defined the scope.
Agile recognised that development teams, clients and even the analysts who wrote the damn requirements struggled with these massive clunky documents and precision on paper almost never results in the delivery of a high-quality usable product by the deadline and within budget.
Agile works instead on shared understanding, of collaboration between the delivery team and client. I prefer "delivery" team because a true multidisciplinary agile team is responsible for delivering value to the business and their users, not just writing and testing code.
In that environment of collaboration and shared understanding about current priorities, user stories become labels or tags that represent something the team had already thought about and discussed.
Instead of a traditional waterfall process of Analysis → Development → Visual design, user stories encourage three-way conversation between the team members and client who represent the needs of the business, the needs of users, and the capabilities and constraints of the technology.
If business analysis dominates the writing of user stories and prioritising of the product backlog then the solution will have a bias towards the way business currently operates or the change they want to realise. It will likely be strongly influenced by efficiency, regulation and cost.
If business analysis took a back seat and the conversation was instead dominated by the technologists then it would be reflected in the product backlog and acceptance criteria as having a bias towards out-of-the-box functionality where "value" are features that can be delivered with little configuration or testing regardless of whether there's an identified need for it.
Technology-dominated product backlogs and stories will reveal traditional development practices of CRUD operations centred around entities, permissions, and how the team prefers to work based on skill strengths, testability, minimising complexity and integration.
Finally, if user-centred designers and the voice of customers is too loud in the conversation then user stories will be biased towards flexibility and empowering users with less regard for business process, regulation and data quality. Nothing will be acceptable out-of-the-box and must be customised.
User stories require balanced input and representation from all three fields: what are the intentions and objectives of the business, how might users perceive and interact with the solution and how can we best make use of the technology to deliver value and not make it do things it wasn't designed to do.
Sometimes there will be irreconcilable differences where the business requires changes that will adversely affect users; for example, internal applications where staff have been getting away with not following processes and the new solution requires them to dot their i's and cross their t's such as replacing shared drives with a document management system.
Sometimes the business will have to accept a bit of a clunky technical solution because of infrastructure constraints or as a trade-off for getting a whole lot of functionality quickly with the downside being the way it works and is structured is fairly static; for example using Drupal instead of Sitecore.
These trade-offs are all ok as long as team members are respectfully representing their opinions and willing to negotiate, along with involving the client and especially the product owner.
PS: The three-way conversation and collaboration model of business, users and technology is simplistic as there are often many discrete perspectives including security, testing, change management, project management, solution architecture, legal and communications. Although they might be able to be grouped under the three top-level headings, they often have conflicting needs and intentions that need to be reconciled within their groups.