第6回:要件定義文書を取りまとめ--不採用要求も整理、記録が必要 - (page 4)

山下博之 (IPA/SECシステムグループリーダー)

2017-10-20 07:00

千石君:それでは、今後の進め方について確認です。経営会議での計画変更案了承を前提に、「要件の合意」アクティビティに進みます。並行して「要件の記録」アクティビティも実施します。

製造部門代表:具体的に説明してください。

千石君:はい。次のタスクは、主に業務要件について要件定義の結果をまとめてステークホルダーにフィードバックし、全ステークホルダーの合意を取り付けることです。これまでも個々の項目については関係するステークホルダーに確認してきましたが、今回の目的は、項目間の関係などに見落としや矛盾がないか、全体を通して再確認することです。

製造部門代表:続けてください。

千石君:はい。みなさんは、あらかじめ定めた分担に従って、これまでにこのプロジェクト会議で議論して合意した内容と文書様式を、わが社の「システム開発標準」に照らして今一度確認してください。本日の会議で確定した部分は、早急に定義文書を更新してください。

 この作業で重要なことは、各ステークホルダーからの要求に対し、採用したもののみならず、不採用としたものについても、その理由とともに記録しておくことです。この記録を再確認し、整理してください。

経営部門代表:不採用の要求も記録して整理するのか。それ、必要ないんじゃないですか?

千石君:いいえ。これらの記録は、ステークホルダー要求のベースラインとなり、構築するシステムのライフサイクルを通して維持されます。その間、たとえば変更要求や追加要求が生じた場合に、この記録に基づいて検討することになります。

販売部門代表:そうか。この記録があれば、今回涙を呑んで削減したわれわれの要求についても、その復活時の検討が効率的にできるんですね。

経営部門代表:なるほど。さすがシステム部門ですね。よく考えられている。

千石君:ありがとうございます。実は、これらのことはみんな、わが社の「システム開発標準」に規定されているんです。さらに、これらの記録は、ビジネスニーズとシステム構成要素をひも付ける、いわゆる“トレーサビリティ”の維持にも必要です。…実を言うと、僕もこのプロジェクトを手掛けるまで知りませんでした。

○:作成主体、△:作成支援(情報提供、確認、アドバイスなど)
要件定義文書種別分担部門
各要求元システム
ビジネスプロセス関連図
業務機能構成表
ビジネスプロセスフロー(業務フロー)
画面/帳票レイアウト
業務処理定義書
概念データモデル(ER図)
エンティティ定義書/データ項目定義書
CRUD図
統合テスト計画書
システム移行計画書>
運用・操作要件書
非機能要件書

経営部門代表:よくわかりました。

千石君:次に、設計部門に渡す要件定義文書全体がまとまったら、最終の要件定義レビューを行います。このレビューでは、複数のシステム設計担当と運用担当にも加わってもらい、特にシステム要件まわりを中心に問題がないか確認します。

ZDNET Japan 記事を毎朝メールでまとめ読み(登録無料)

ホワイトペーパー

新着

ランキング

  1. セキュリティ

    「デジタル・フォレンジック」から始まるセキュリティ災禍論--活用したいIT業界の防災マニュアル

  2. 運用管理

    「無線LANがつながらない」という問い合わせにAIで対応、トラブル解決の切り札とは

  3. 運用管理

    Oracle DatabaseのAzure移行時におけるポイント、移行前に確認しておきたい障害対策

  4. 運用管理

    Google Chrome ブラウザ がセキュリティを強化、ゼロトラスト移行で高まるブラウザの重要性

  5. ビジネスアプリケーション

    技術進化でさらに発展するデータサイエンス/アナリティクス、最新の6大トレンドを解説

ZDNET Japan クイックポール

所属する組織のデータ活用状況はどの段階にありますか?

NEWSLETTERS

エンタープライズコンピューティングの最前線を配信

ZDNET Japanは、CIOとITマネージャーを対象に、ビジネス課題の解決とITを活用した新たな価値創造を支援します。
ITビジネス全般については、CNET Japanをご覧ください。

このサイトでは、利用状況の把握や広告配信などのために、Cookieなどを使用してアクセスデータを取得・利用しています。 これ以降ページを遷移した場合、Cookieなどの設定や使用に同意したことになります。
Cookieなどの設定や使用の詳細、オプトアウトについては詳細をご覧ください。
[ 閉じる ]