there's probably a stakeholder who can define what that means

Indeed. As you know whenever something becomes a buzzword, it also becomes oversimplified. On the other hand, I question whether one is really doing BDD if one have broadened it to the general (non BDD specific) wisdom: listen to your stakeholders and agree upon measurable deliverables.

The conversational tools of BDD are not necessarily the best communication method for all stakeholders. End users often respond well to stories because they experience their jobs as a flow. BDD can be an extremely effective tool for communication with this group of stakeholders.

On the other hand, senior management tends to respond better to discussions that focus on cost-benefit analysis: the cost of implementing X versus the impact of X on market position, future sales, branding, and other strategic or operational goals. Stories (aside from case studies of market success or failure) tend to take the back stage.

IT managers and the engineering staff who advise them are primarily interested in fact-based discussions of the impact of implementation X vs. Y on total cost of ownership (TOC), long term support needs and security related liabilities. Connecting the dots between the technical features of implementation X and the TOC of implementation X takes a lot more than getting stakeholders to articulate goals and scenarios. I find it far more important to do an assessment of organizational strengths and coping mechanisms. TOC does not exist in a vacuum - it is inseparable from organizational culture.

I suppose you could call market impact, TOC or security risk level a "behavior", but if you do so, you've broadened the meaning of BDD so greatly that (a) behavior merely becomes a synonym for goals (b) BDD looses its distinctiveness as a methodology.

Best, beth