プロジェクトに望まれる結果が定義されているならば，振る舞い駆動開発(BDD/Behaviour-Driven Development)は，開発対象に対する開発側の理解と，要件によって生じる技術的課題に対するビジネス側の理解とのギャップを克服する上で，有効な手段だ。その理由は２つのグループのコミュニケーションの改善にあると，Inviqaに所属するAlistair Stead，Konstantin Kudryashov両氏は，ビジネスと技術のプロフェッショナルを対象とした記事“Beginner’s guide to BDD”の中で説明している。
両氏はBDDを，２つの主要なプラクティスに分解する。振る舞いの説明をユビキタスな言語で記述したサンプルの導入，そして，それらのサンプルを自動テストのベースに利用することだ。これら２つのプラクティスが相まって，ユーザの立場で見た機能と，プロジェクト全体を通じて定義されたシステムの振る舞いを検証することが可能になる。
BDDで重視すべき部分として，両氏は，次の点を指摘する。
- 可能であればプロジェクトの開始時に，ビジネスの側面から，具体的かつ計測可能な目標を立てること。
- インパクトマッピング – 目標に到達するため，ビジネスにとって最も重要な機能を見付ける方法である。インパクトマッピングは，機能が必要な理由と，目標達成のために変更すべき振る舞いを視覚化する。
- 複雑性解析 – 最適な開発とコラボレーションのアプローチを見つけ出す方法。Cynefinはその一例だ。
- サンプルの計画 – ビジネスルールの説明とコンテキストの提供にサンプルを用いることによる誤解を防ぐ。これらのサンプルは後で変換して，開発中にもテストとして使用する必要がある。
- ユビキタス言語 – ドメイン駆動設計(DDD/Domain-Driven Design)からの用語で，そのドメインでの用語に対して共通理解に達するために，開発側と管理側が共有する言語である。
- サンプルを通じた開発 – 形式的言語とCucumberのような自動化ツールを利用することで，サンプルを実行可能な仕様に変換して，実装機能を検証することが可能になる。
- BDDループは，システムの大規模な変更をサポートするためのものだ。実行可能な仕様の利用に加えて，システムの個々の要素が取るべき振る舞いについて，ユニットテストをオブジェクトの仕様として用いることにより，大規模な変更や小規模な変更への対処が可能になる。
BDDは2006年頃，Dan North氏によって開発された。インタビューで氏が強調していたのは，BDDはテストの手段ではなく，アプリケーションが存在する前にアプリケーションの振る舞いを説明するための手段として，サンプルと期待結果を記述するものである，という点だ。これによって，プロジェクトの参画者同士の会話が成立する。North氏は，参画者同士が近い位置を保つことが重要であり，組織構造的あるいは地理的な分離は，BDDの成功に対する大きな障害になり得る，と指摘している。