要求と要求仕様（要件）

ここでは要求仕様と要件は同じ意味で使っています。

要求と要求仕様は若干異なっています。
要求はステークホルダがだす要求を表しているもので要求仕様は要求を解決するために定義されたシステムの動作（ソリューションとしては概要的）を表しているものです。

要求仕様は踏み込みすぎると設計をしていることになってしまいますが、その境はあいまいです。

要求のMECE

MECE（(Mutually Exclusive collectively Exhaustive))とは漏れなくダブりなく洗い出し整理された状態を表しています。もともとロジカルシンキングの考え方ですが整理手法として優れているので要求を整理するのに利用します。

MECEの出所からアイディアを借りて考えると、要求をロジックツリーのように整理します。Whyの問いかけをすることで階層構造となるわけです。
ステークホルダはいろいろな立場の人がいるとはいえ、根本にある共通目標は同じはずです。もし同じでないとすればまず同じになるように調整する必要があるはずです。
よくある表面的合意（あるいは総論賛成・各論反対）というのはプロジェクトを迷走させる原因になるので注意が必要でしょう。
共通目標から各ステークホルダの目標、共通目標のサブ目標といった形でブレイクダウンしながら要求を整理していきます。
そうするとそのツリーに偏りができたり階層の兄弟要素間で粒度が異なったりします。そのような時に「漏れ」があるということがわかったりします。このような整理をすることで漏れなくダブりなく整理することができるようになります。

この手法は、要求の整理の手法であって抽出の手法ではありません。抽出には抽出の技術ががあるので別途どこかで説明したいとは思います。

誤解しやすいのは、「要求の性質*1上MECEができないから無意味だ」という誤解です。完全なものを作ることができないという点は正しいのですが、できないからといってできるところまでやらない理由にはなりません。
ここでMECEを取り上げているのはできる限りその近くまで行くためにどうするかという話をしたいからであって、「MECEができる。」「だから変更を認めない」「仕様は凍結しなければならない」といったことではないのです。
補足しておくと、要求の追加・変更は変更管理プロセスによって制御されていればよく、要求の追加・変更を認めないわけではないのです。

*1:人間から抽出するので漏れる