シナリオの重要性

私が今まで関わったプロジェクト環境における開発プロセスのあり方についてある程度自分の中で形が作られつつある中で最近より強く課題と感じられることに要求仕様の管理があります。
典型的には要求を明確にして要求仕様書（ドキュメント）を書くということなのですがどうも生産的でないと感じています。
従来の要求仕様書ではいくら詳細に書いても完全にすべてを網羅することができずにあいまいな部分が出てきます。
できるだけあいまいにならないようにしようとするとその量が膨大となって更新などの管理コストが増大し、挙句の果てには読むのも大変になって利用されなくなるという大きな無駄を生むことになります。
もちろん要求を明確にして文書化することは重要だと思うのですがどのような内容にしてその管理（更新やメンテナンス）をどのようにするのかが非常に悩ましく思います。
このような課題は一般的な問題ですでに体系化されている分野だと思うので書籍などで勉強したいと思うのですがふと思ったことがあるのでを忘れないうちに書いておこうと思います。
このような問題は要求のカバレッジを仕様書で埋めようとすることによる弊害の様に思います。
そこで明確に定義すべきところと要求のカバレッジを実現するという目的を分離して、明確に定義するべき事柄をスペック（仕様書）として書きその他の要求はシナリオとしてカバレッジを実現するということにしてスペックの定義は必要最小限にしてできるだけシナリオを充実させるのが合理的であると思いました。
またこのスペックとシナリオとの関係をwikiなどを使ってうまくリンクさせることでより効果的ではないかと思っています。
品質保証の要件としての仕様は厳格に定義しなければならないように思えますが場合によってはある具体的なシナリオを設定してそのシナリオを実現することを品質保証の要件にするということで十分かつ非常に合理的、効果的なのではないでしょうか。