アジャイルソフトウェア開発を使って製品をインクリメンタルに開発し提供する場合，要件項目はプロダクトバックログに収集，整理される。ここで使用される要件定義テクニックはユースケースだ。アジャイルの製品要件管理でユースケースを利用するテクニックには，ユースケース2.0やスライシング，ラミネーティングなどがある。
Shobha Rangasamy Somasundaram氏とAmol Sharma氏はブログに，フォーマルな要件定義手法がアジャイルでも有効かを検討した記事を書いた。その中で両氏は，ウォーターフォールとアジャイルソフトウェア開発における要件の利用方法について比較を行っている。
従来型のソフトウェア開発であるウォーターフォールプロセスでは，要件定義フェーズに次のような手法を使用します – ブレーンストーミング，アンケート，モデリング，プロトタイピング，観察，フォーカスグループ，調査，リバースエンジニアリング，インタビュー，ドキュメント解析，JAD(Joint Application Development) – コラボレーションとドメインモデル開発のワークショップ。ウォーターフォールにおいて要件を用意するのはクライアントやBA，プロダクトオーナなどの仕事です。彼らはそこで意見交換をして，最終的に要件定義書を作成します。そこで確定した要件が，次の開発チームへと引き渡されるのです。
(...) アジャイルの時代になって，プロジェクトの初期段階や，少数の限定的な個人による要件定義は行われなくなりました。しかし，ソフトウェア開発のライフサイクル全体に対する影響力は変わっていません。アジャイルでは要件の文書化方法をひとつに決めていません。それよりも"必要十分である"ことを重視しています。詳細は必要になった時点で初めて，時間を費やして展開されます。ひとつに限定されていた"要件定義段階"は分解，分散されて，普遍的な存在になっています。従来と同じ分析方法を用いて，ライフサイクル全体を通じて実行されるのです。
ブログ記事にはロードマップとユースケース，ユーザストーリを組み合わせて製品要件を管理する方法が詳細に説明されている。
Andy Hayward氏は一連のブログ記事で，さまざまな要件手法について検討を行った。"when to use user stories, use cases and IEEE 830 - Part 2: Use cases"と題した記事では，ユースケースの形式について取り上げている。
ユースケースは非常にフォーマルに記述して，プロセスを極めて正確に定義することも可能ですし，Alistair Cockburn氏が"簡易ユースケース(Use Case Brief)"という言葉で表現したような，単純な段落形式を使って，ユーザストーリより多少詳細という程度に記述することもできます。さらにその２つの中間にも，さまざまなバリエーションがあります。アナリストはこの広い範囲から，プロジェクトの必要性に合わせて選択を行えばよいのです。ところが残念なことに，ほとんどの組織では，標準的なテンプレートを用意してこの柔軟性を制限してしまっています。
氏の説明によると，ユースケースを小さな部分にブレークダウンする作業は，時として困難な場合がある。
ユースケースに関する問題点は，それが通常，多数の要件をひとつの大きな情報として閉じ込めてしまっていることです。これによって開発者は，ユースケースの複雑性を想定した作業計画が困難になりますし，管理者は価値や優先度の有意な判断が難しくなります。それぞれのユースケースを，ステップ全体として実現可能なパスを描き出せるような‘シナリオ’のリストに分割することは可能です。ただしそれを行うには，各シナリオの実行に先だって"システムのあるべき姿"を描き出すというように，さらに多くの作業が必要になります。
"Use Case 2.0 Essential Practice"というWebサイトには，ユースケースのスライシングを使って要件を把握する手法 (ベースはUse-Case 2.0 ebook)が概説されている。
- システムが行うべきことを正確に記述する。
- 要件の各部分をグループにまとめて，大まかなスコープ管理を行う。
- 要件をスライスして製品バックログ項目を作成し，それに従って反復型開発を実施する。
- ユーザの要求に対応するため，優先順位を絶えず見直す。
- 開発者とユーザがともに理解しやすいような，シンプルな視覚モデルと意味のある機能要件を作り上げる。
- スクラムやIJI Iterative Essentialsといった，反復的かつバックログ駆動の管理手法のメリットを活用する。
- ユーザの機能要件をジャストインタイムに十分な詳細度で把握することで，彼らのビジネス目標をサポートする。
ユースケーススライシングは，アジャイルで製品の開発と提供をインクリメンタルに行うための方法だ。
IJI Iterative Essentialsの実践は，アクタとユースケースを見つけ出して，開発すべきユースケース部分(スライス)を選択し，優先度を付与することから始まります。次にユースケーススライスの詳細化を行いますが，それ以上に重要なのがテストの詳述化です。そうした上で，そのテストを満足するようにソフトウェアを実装するのです。テストを実施して，検証済の動作可能なソフトウェアとしての進捗を追跡し，チームを変更およびサポートするために結果をフィードバックします。
Ivan Jacobson氏がブログ記事"Architecture"で説明しているように，まずはスリムなシステムから開発を始めるとよいだろう。
[スリムなシステムとは，] ユースケース(あるいはシナリオ)の重要なパスをすべて備えたシステムです。重要なサブシステムやコンポーネント，クラス，ノードなどは漏らさず実装します。通常この段階では，完成コードの5～15%程度にしかなりませんが，重要項目の動作を保証するにはこれで十分です。何よりも大切なのは，スリムなシステムを拡張してシステムを完成可能なことです。
Richard Schaaf氏は"Improving User Stories with Use Cases"と題したブログ記事で，ユースケースを使用した製品要件の管理にユースケース2.0がいかに有用かを説明している。氏によれば，ユーザストーリに関連して問題があるのならば，その定義プロセスを見直す必要がある。
ここで問題なのは (..) 長期的に有効かつ有用なユーザストーリを記述することは非常に困難だ，という点です。私たちに必要なのはユーザストーリの代替手段ではありません。それを考え出すための，もっとよい方法なのです。
プロダクトバックログが時間の経過によって劣化することは珍しいことではありません。これはチームにとって，本当に重要な問題となります。アジャイル組織が真の成功を収めるには，ユーザストーリ作成のプロセスを重視する姿勢こそが必要なのです。
氏が提案するのは，ユーザストーリの定義にユースケーススライスを使用することだ。
ユースケーススライスとは，ユースケースを貫く流れをひとつに集めたものです。その中には，ユーザに対する価値の明確なテストケースが含まれています。この流れはユースケースストーリと呼ばれています。
氏はユースケースをユースケースストーリに分解して，それをユースケーススライスの定義に使用する方法について説明する。そうしてできたユースケーススライスが，プロダクトバックログに必要なユーザストーリとなり得るのだ。
ユースケースをモデリングに正しく使用したのであれば，これらのユースケースストーリそれぞれが確かな価値を持っています。ユースケーススライスは，これらのユースケースストーリを選択(ひとつないし複数)した上で，満たすべきテストケースをいくつか加えればよいのです。
こうして定義されたユースケーススライスは，ユーザストーリとしての基準をすべて満たしています。結果として私たちは，誰のためか(開始アクタ)，何が必要か(ユースケースストーリとテストケース)，価値は何か(ユースケースの構築方法に由来)，といったことを理解します。ゆえにユースケーススライスはユーザストーリそのものであり，プロダクトバックログの項目としても使用可能なのです。
ユースケーススライスを使用するメリットについて，氏は次のように説明する。
ユースケースを中心に置くことにより，常にシステム全体を視野に入れることができます。
詳細なレベルが早い段階で議論されますから，適切なタイミングで十分なレベルの詳細に到達可能です。
ユースケーススライスの定義を通じて，それぞれのユーザストーリが価値を中心として一貫したストーリであることを確認できます。
Alistair Cockburn氏の記事"Laminating not slicing"には，氏が"ラミネーティング"と呼ぶメタファについての説明がある。
しかしながら，その言葉は逆です。私たちが行うのは，巨大な象のような要件をスライスに解体することではありません。私たちは何もないところから始めて，象を作り上げるのです。象のスライスを山ほど集めたところで，それが象になるはずがありません。 私たちはここで，最小の時間でりっぱな象の外観を作り出すような，ラミネーションの手順について議論したいと思います。
ラミネーティングの第一歩となるのがウォーキングスケルトン(walking skeleton)だ。
ウォーキングスケルトンとは，小規模なエンド・ツー・エンド処理を実行する，システムの最小単位の実装です。完成品と同じアーキテクチャを使用する必要はありませんが，主要なアーキテクチャコンポーネントとはリンクさせていた方がよいでしょう。アーキテクチャは機能と並行して発展させればよいのですから。
ソフトウェア製品ないしシステムの「ウォーキングスケルトン」とは，どのようなものだろう？ 氏はいくつかの例を挙げる。
ウォーキングスケルトンの構成要素は，設計されるシステムによってさまざまです。クライアントサーバシステムならば，画面-データベース-バックエンドという構成の１機能になるでしょうし，マルチティアあるいはマルチプラットフォームのシステムであれば，ティアあるいはプラットフォーム間で動作するコネクションでしょう。コンパイラならば言語のもっとも簡単な要素であろうトークンのひとつをコンパイルする構成，ビジネスプロセスの場合は簡単なビジネストランザクション (Jeff Patton氏が，後述する"Essential Interaction Design"のテクニックで説明したような) のワークスルーです。
ウォーキングスケルトンの次には，氏が "The A-B work split, feature thinning and fractal walking skeletons” で説明しているような外面のラミネートに着手する。
機能Fの一部をカーブの急上昇部分に置いて，"残りの機能でトラブルを起こさなくて済むようにこの部分をしっかりやろう"，と伝えます (これがA部分です)。そして機能Fの残り部分 (B部分) をカーブの末尾まで遅らせます。こうしておくことで，Bをいつでも実行できるようになります。
インクリメンタルな製品開発で使用可能な機能単位の決定と優先度付けを行うには，A-Bスプリットをどのように行えばよいのだろう。氏はいくつかの戦略を提供している。
- A-BスプリットではA機能の実施について，残りの作業をいつでも実施できるレベルまで行う，とされています。
- Jeff Patton氏の "Fearure Thinning"は違います - 非常に素晴らしいものである必要はないが，完全に動作すると評するに相応しいレベルまで実装するのです (普通のブレーキは必要だが，アンチロックブレーキまでは不要，というように)。
- ウォーキングスケルトン戦略は，部品間のコネクションを確立する上で必要な，ほぼ最低限 (サブ最低限?) の機能を実現する，という方法です。氏は最近になってこれを拡張し，各ストーリ用のミニ・ウォーキングスケルトンを定義しました(http://agileproductdesign.com/blog/the_new_backlog.html).。このナイスな用語の説明として，Gery Derbier氏は「リカーシブ・ウォーキングスケルトン」あるいは「フラクタル・ウォーキングスケルトン」という言葉を私に提案してきました。Geryはこれらをプロジェクトで使用していて，非常に気に入っていると言っています。そうでしょう – この考え方はA-Bスプリットと多少なりとも関係していますし，それゆえにリスク軽減という特徴も備えていますから。Jeffのミニ(フラクタル)ウォーキングスケルトンにFeature Thinningの発想が含まれているのかどうか分かりませんが，この２つにはほとんど違いがないのかも知れません。
ユースケースによる製品要件の管理に，読者はどのような方法を使っているのだろうか - ユースケース2.0，スライシング，ラミネーティング，あるいは他の手法？