はじめに
情報システム部の方で、ITに詳しいだろうからという理由で、ビジネス用のシステム開発のマネージメントをするように依頼されることはないでしょうか？
実際は情報システム部の仕事と、ビジネス用システムの開発は大きく異なるものかと思います。
また、非IT企業では、システム開発を依頼する機会も少なく、一発勝負になることも多いです。
そんなお悩みを解決できるよう、いち非IT企業の情報システム部メンバーとして、実体験に基づくシステム開発の依頼の流れをまとめさせていただきました。
システム開発でお悩みの方は、是非見てみてください！
またITベンダーの皆さんにも企業側はこんなこと考えてるんだなーと思ってみていただければ嬉しいです。
要件定義とは？
要件定義は要求者と開発者の合意事項を記すものである。ここで明記されていないものは、実装されないものである。
成果物例
成果物の例としては以下である。プロジェクトにより必要なものは変動するため柔軟に対応する必要がある。
業務・機能要件系
- 業務フロー図
- ユースケース図
- システム構成図
- 機能要件一覧
非機能要件系
- 非機能要件一覧
業務・機能要件
業務要件に認識齟齬があると、機能追加や修正リスクが高くなる。要件定義工程にて業務要件を整理することが望ましい。設計を進めていく中で業務要件の修正加筆が必要な場合は、ベンダー・ユーザ企業が合意の下で、修正を行うのが正しい。
業務要件は主に以下５つの情報をまとめることが望ましい
１．システム化の背景・目的
２．システム化の対象範囲
３．システム化業務一覧
４．新業務フロー
５．システム化業務説明
要は作るシステムが関連する業務をまとめる作業
非機能要件
軽視されがちであるが、事業・システムに重大な影響を与える可能性がある。非機能要件はビジネスに直結せず、イメージし辛いため、抜け漏れが良く発生するものである。抜け漏れを低減するため、IPA非機能要求グレードを活用する。未決項目も基本設計フェーズでは決定できるように情報を残しておく。
非機能要件は主に以下６つの情報をまとめることが望ましい
１．可用性
２．性能・拡張性
３．運用・保守性
４．移行性
５．セキュリティ
６．システム環境・エコロジー
※要は非機能要求グレードを見ながら埋めていく作業
さいごに
また、要件定義の内容は要求定義の内容を包含している。そのため、要件定義完了前に、要求事項を見直し、抜け漏れがないことを確認すべきである。
改めて、要件定義は要求者と開発者の合意事項を記すものである。ここで明記されていないものは、実装されないものであると意識して取りまとめを行う必要がある。
コメント