要求定義のチェックポイント427

著者：本園明史
発売元：翔泳社

第3章　基盤整備フェーズ
　問題を明確にする
　システムの目的を明確にする
　業務を理解する
　既存のシステムを検証する
　システム化の範囲を検討する
　ユーザ情報を収集する
　制約条件を明確にする
　トレードオフ条件を明らかにする

第4章　要求獲得フェーズ
　ルーチン作業のヒント
　機能要求を獲得する
　非機能要求を獲得する
　トレードオフ条件を明らかにする

第5章　引渡しフェーズ
　すべての要求を見直す
　テスト可能性を検証する
　要求の曖昧さを排除する
　追加変更要求に対応する

付録　一歩踏み込んだフェーズ別チェックリスト

感想

開発案件で揉めてしまうのって、お客さんの要求をきっちり引き出せていないことが多いからなんだよね。

まぁ、お客さんが望んでいたものを、ドンピシャに開発しても、そもそもその要件じゃ課題が解決できなかったりするんだけれどね。

そういうこともあるんだけれど、それはそれということで、正しい要求定義の書き方がしっかり書かれていますわ。

で、個人的には要求仕様確定Phaseの成果物ってRFP,つまり要求仕様書だけでいいんじゃねえか？って思っていたりしたんだけれど、ソウじゃないんだな。

それは50ページにしっかり書かれている。

□正式な納品物として何を想定しているか。
→要求フェーズにおける正式な納品物の例
　●要求仕様書
　●ユーザマニュアルなど
□開発用のアウトプットとして何を想定しているか。
→開発用のアウトプット例
　●開発用の要求仕様書
　●問題リスト
　●制約リスト
　●リスクリスト
　●ユースケース図
　●要求管理データベースなど

これは改めて勉強になりましたな。

あと、同じ流れで要求仕様書のページ建てというか、内容がしっかり定義されていて、それも52ページに書いてあった。

IEEE/ANSI標準
1.はじめに
　1.1要求仕様の目的
　1.2アウトプットの範囲
　1.3用語の定義、頭文字、および略語
　1.4参考資料
　1.5要求仕様の概要
2.一般記述
　2.1製品の概要
　2.2製品の機能
　2.3ユーザの特性
　2.4制約条件
　2.5仮定および依存事項
3.要求仕様
　3.1外部インターフェース
　3.2機能的要求
　3.3性能要求
　3.4論理データベース要求
　3.5設計の制約
　3.6システムの特性
　3.7品質の特性
付属資料
索引

こうやって構成されてるんだとな。

で、そんなしっかりとした要求仕様書を作成するためのチェック項目が54ページに書いてあるのだな。

それは

□基本事項
　●要求に番号がふられているか。
　●要求の発生日はいつか。
　●要求は新規か、追加・変更か。
　●要求の出処はどこ（誰）か。
　●要求が要求仕様書に記録された日はいつか。
□要求詳細
　●要求は何か。
　●要求の基になった原因・背景は何か。
　●要求の実現システムの目的はどのように貢献するか。
　●要求の実現は誰にどのようなメリットがあるか。
　●要求の実現は誰にどのようなデメリットがあるか。
　●要求の実現によって得られる効果は何か。
　●要求の実現によって得られる効果は計測可能か。
　●開発工数、費用はどの程度に見積もられるか。
　●投資対効果は検討されているか。
　●要求に付帯する非機能的要求（品質・性能等）は明確いなっているか。
　●発生するとすれば、どのような変更要求が発生するか。
　●要求の優先度は明確か。
　●要求の重要度は明確か。
□他の要求との関係
　●要求は他の要求に依存しているか。
　●要求は他の要求の前提条件となるか。この要求の実現を前提条件にしている要求はあるか。
□既存の要求への影響
　●要求間の依存関係に変更はあるか。
　●要求間の前提条件、制約条件の変更はあるか。
　●既存の機能間のインターフェースに変更はあるか。
□開発可否の判断の記録
　●開発可否の判断会議が実施された日はいつか。
　●判断会議の参加メンバーは誰か。
　●判断に使用された情報は何か。
　●判断基準は何か。
　●判断結果は何か。
　●判断基準、判断結果に関して特記すべき事項はあるか。
　●判断に使用された情報が誤っている、あるいは正確性に欠ける可能性はないか。
□要求のステータス
　●要求の処理状況の例
　　・要求管理ドキュメントに記述済み。
　　・開発可否の判断待ち。
　　・開発可否の判断済み。
　　・要求仕様書の記述済み、など。