• 以下の基本的な問題を指摘する。
    • 機能: 想定されているソフトウェアの機能。
    • 外部インターフェース: ソフトウェアが人員、システムのハードウェア、他のハードウェア、他のソフトウェアと相互作用する方法。
    • 性能: 多様なソフトウェア機能の処理速度、利用可能性、応答時間、回復時間など。
    • 属性: 移植性、正確性、保守性、セキュリティーなどの考慮事項。
    • 実装に課せられた設計上の制約: 要求される標準で導入されているもの、実装言語、データベース信頼性の方針、リソースの限界、運用環境などがあるか。
  • ソフトウェア要求仕様 (以下 SRS) の範囲外で指定された要求があるか。この場合は、SRS の仕様は次のようになる。
    • ソフトウェアの要求すべてを正確に定義している。
    • 設計または実装の詳細は記述していない。
    • ソフトウェアに追加の制約を課していない。
  • 特定の設計を指定せずに、SRS が有効な設計の範囲を正しく限定しているか。
  • SRS が次の特徴を提示するか。
    • 正確性: SRS で述べた要求のすべては、ソフトウェアが満たす必要があるものか。
    • 明白性
      • 各要求の解釈が一とおりのみであって、誤解を招く表現はないか。
      • 顧客が使用している言語を使用したか。
      • 使用されているダイアグラムが、自然な言葉による説明を補っているか。
    • 完全性
      • SRS に機能、性能を設計する上での制約、属性、外部インターフェースのいずれかに関連する、重要な要求すべてが含まれているか。  
      • 可能なすべてのシナリオでの、入力値の予期される範囲を明らかにして取り扱っているか。  
      • 有効・無効な入力値両方に応答が含まれているか。
      • すべての用語および測定単位のラベル、参考文献、定義が、完全に全図表に含まれているか。  
      • すべての TBD が解決または取り扱われているか。
    • 一貫性
      • SRS が、開発構想書、ユース・ケース・モデル、補足仕様書のすべてと一致しているか。
      • より高レベルの仕様書と一致しているか。
      • 内部的に一貫性があり、記述されている各要求のサブセットに矛盾がないか。
    • 要求をランク付けする能力
      • 要求の重要性または安定性を示す識別情報を持つタグが、各要求に付けてあるか。
      • 優先度を適切に決定するためのその他の重要な属性を明らかにしたか。
    • 検証可能性
      • SRS で述べた各要求が検証可能なものか。
      • ソフトウェア製品が仕様を満たしているかを人間または機械がチェックできる、何らかの有限な費用対効果のよいプロセスが存在しているか。
    • 変更可能性
      • SRS の構造と形式が、要求の変更が発生した際に、その構造と形式を保持したまま、容易に、完全に、そして一貫して変更できるものであるか。
      • 重複を識別し、最小化し、相互参照したか。
    • 追跡可能性
      • 各要求に明確な識別情報があるか。
      • 各要求の発生元が明確か。
      • 過去への追跡可能性が、以前の成果物を明らかに参照することによって、保持されているか。
      • SRS の結果である成果物に、十分な将来への追跡可能性を保持する対策が講じられているか。

参考資料: [IE830]



Rational Unified Process   2003.06.15