さまざまな機能を備えた稼働中のシステムがあり、そのシステムを別の国に合わせて調整しようとしているとします。一部の関数はそのまま残り、一部は調整され、一部はゼロから定義されます。
この状況では、どの形式で要件を記述しますか? 新しい仕様は、既存の関数について言及する必要がありますか? すべての機能を新しく説明する必要がありますか? 新しい国のために小さな変更が必要な大きなユースケースがある場合、それは完全に説明するべきですか、それとも差分だけを説明するべきですか? 開発者がそれが何であるかを理解できるように、そのような小さな変更のコンテキストはどうですか?
この状況では、どの形式で要件を記述しますか?
前回同様、ご満足頂ければ。
新しい仕様は、既存の関数について言及する必要がありますか?
それは本当にすべきです。これは開発者を助け、冗長なロジックが開発されるリスクを軽減します。
すべての機能を新しく説明する必要がありますか?
これほど多くの重複コンテンツを作成することは、ほとんどの場合、経済的理由に反します。付加価値はほとんどまたはまったく得られませんが、多くの貴重な時間とお金がかかります. 要件を再利用すると、改善に役立ちます。
また、既存の要件に加えて指定すると、既存のものから何を使用できるか、どこに構成するか、どこに何か新しいものを追加するかについてかなり良いアイデアが得られます (2 番目の文を参照)。
はい、既に指定した内容に基づいて要件を設定します。
この規則の例外として、(a) 新しい要件を差分として指定することは、ゼロから始めるよりも手間がかかる場合があります。次に、新しいものが本当に既存のものに基づいているかどうかを尋ねるかもしれません。
または、(b) すでに文書化されている要件が振り返ってみると、品質が非常に低いことがわかる場合があります。次に、新しいアプローチを与えるのに役立ちます。
新しい国のために小さな変更が必要な大きなユースケースがある場合、それは完全に説明するべきですか、それとも差分だけを説明するべきですか?
スペースがあれば、既存の図に合わせることができます。または、サブ ダイアグラムを作成し、それらにリンクして詳細を表示することもできます。目標は、ダイアグラムを簡潔で理解しやすいものにすることです。一般化とextend/includeはあなたの友達です。