開発は、マーケティングやハードウェアエンジニアなどのステークホルダからの「要求書」や変更指示を受け取るところから始まります。
受け取った要求は仕様のレベルのものや、あいまいなものまで様々です。それらの様々な要求を分類と階層で整理します。
まず最初に行うことは、要求と仕様を振り分けて「第1階層の要求」を抽出することです。

• 要求か仕様かを判断し、切り分ける
• 要求の大きさ（粒度）を適切な大きさに分解する

 ＜要求か仕様かを判断し、切り分ける ＞

• 変更の場合、仕様レベルで変更の依頼が来ることがあります。例えば、ある角度をここまで広げてほしい、とか、このボタンを押してこう表示されていたものも、このように変えてほしいなど。。。
• このような変更指示が来た場合は要注意です。「~してほしい」という言葉から要求と捉えると、これ以上分割できない要求となり、仕様も同じような記述になります。
• ここは、一段上に立ち、「このように変更してほしい要求は何か？」を考えるようにします。
• ステークホルダーにインタビューするのもいいでしょう。
• 新しい要求を立ててその下に依頼事項を仕様として記述しましょう。そうすることで、他の仕様にも気づくようになり、モレを防止できます。

＜要求の大きさ（粒度）を適切な大きさに分解する＞

• 要求の粒度が大きいと階層が深くなり、理解性が悪化するだけでなく、要求間の関係が煩雑になり、仕様モレに気付きにくくなります。
• 要求はなるべく2階層以内になるように第1階層の記述を工夫しましょう。
• 例えば、要求が3階層になりそうな場合、第1階層のレベルで2つに分解し、グループで括るという方法があります。
• このように、第1階層の記述粒度を他の要求と揃えることで、2階層に収めることができます。

要求の範囲と仕様の範囲

＜要求と仕様の分かれ目は？＞

• 要求はステークホルダーが製品に対してしてほしいこと、実現ほしいことを表現し、それを実現する上で必要となる細かな情報は含まれません
  　・仕様は要求を実現するために必要な情報
  　・要求と仕様の分かれ目は「実現してほしいこと」か、「実現するために必要な情報」になります
  
• 要求は本来「～できるか」という問い
• 仕様は「～すればできる」という答え

＜仕様のレベル＞

• 派生開発では、仕様はソースコードレベルまで詳細化されています。従って変更仕様には2つのレベルがあります。
  　・機能仕様のレベル
  　・ソースコードのレベル
• すでに機能仕様書がある場合、機能仕様レベルの変更仕様とソースコードレベルの変更仕様が必要となります。
• 機能仕様がない場合、スペックアウトしたソースコードレベルの仕様になります。