ごきげんよう、Zei(ゼイ)です。
以前、要件定義の概要と要件定義でとても大事な『依頼者と開発者の協議』をまとめていきましたが、
今回は、話し合いがまとまり方向性が決まったらそれをどう形にしていくのかをまとめました。
以前の要件定義の『依頼者と開発者の協議』をまとめた記事↓
【IPAの資料を読みながら要求定義を深堀してみた】
以前の要件定義とは何ぞや記事↓
【【依頼者も開発者も大事な工程】要件定義は何をすればいいの？】
以前の決意した記事↓
【超個人的なWEBアプリを作りたい】
システム開発の工程全体を説明している記事↓
【システム開発の流れと開発手法を知ろう】
要件定義書として次の工程の基本設計で困らないように、かつプロジェクトとして失敗しない仕様として決めておくべき内容をまとめてみました。
「ふぁ～、要件定義って何すればいいんやろか～」という初心者さん、一緒に頑張りましょ。
個人開発をするにあたってせっかくなので要件定義を作成してみたいと勉強しまとめた記事となりますので、実際の現場ではもっとシビアに作成していかないといけないかと思いますが、概ねどんなことをした方がいいのかを参考にしていただければ幸いです。
また、成果物の基本の説明はしておりますが、実際自分が今回必要なかったものに関してはキーワードのみになってしまっている可能性がございます。予めご了承ください。
しかしながら、キーワードだけだったとしても次回自分が必要になった際検索ができるので、自分としてはポジティブであります。
要件定義のフォーマットってあるんですか？
結論、特に決まったフォーマットは存在しないらしい。。。
しかし要件を整理することに変わりはないので、組織やすでに稼働しているプロジェクトならもしかしたら存在するかもしれないので、各自ご確認を。
ないなら・・・一緒に作っていきましょ・・・。
要件としてまとめないといけないこと
要件定義としてまとめないといけないことは主に5つ
- システム概要：目的・背景をまとめる
- 業務要件：業務フローをまとめる
- 機能要件：必要な機能をまとめる
- 非機能要件：システムの裏側をまとめる
- 運用・移行・総合テスト要件：システムができた移行の内容をまとめる
システム概要
- プロジェクト名
- プロジェクトの目的
- 背景・課題
- 想定ユーザー(ステークホルダ)
- 主な機能
- 成果物 など
システムの開発経緯や目的・目標などの記載が必須。
ここでゴールを決めておくことで、依頼者側と開発側、関係者全員の認識に齟齬がないようにしておく。
業務要件
- 業務用語定義(皆で同じ用語を認識する用)
- 業務機能構成表(全体像を把握する用)
- 業務処理定義(業務の具体的内容の記載用)
- 業務の全体象が分かる関連図
- 現状の業務フロー(As-Is)
- システム稼働後の業務フロー(To-Be)
関係や業務の流れを文章で書くと分かりづらいので、見た目で分かるように図などを用いて表すと分かりやすい。
機能要件
画面要件
- UI標準(システム全体のUIを確認する用)
- 画面一覧
- 画面遷移図(各画面の処理の流れを確認する用)
- 画面レイアウト(画面の見た目・入出力項目・操作手順などを確認する用)
帳票要件
- 帳票一覧
- 帳票概要
- 帳票レイアウト
バッチ処理一覧(バッチ処理の頻度などを確認する用)
テーブル・ファイル要件
- テーブル関連図(ER図)(データの構造を見た目で確認する用)
- テーブル・ファイル一覧
- テーブル・ファイル定義(各テーブルの詳細)
外部インターフェース要件
- 外部システム関連図
- 外部インターフェース一覧
- 外部インターフェース定義書
本来なら要件定義時に見積もりをする必要があるので、ある程度は決まっている方がいいらしい。
あと友達の開発者に聞いたところ、「細かい方がいい、これで見積もりを出すし、これがそのまま基本設計に使えることもあるから」とも言っていたので、できるだけ細かく作っていこうと思った。
※帳票要件／外部インターフェース要件は今回作成していないので割愛
※場合によってはシステム方式として、
ハードウェア構成図／ソフトウェア構成図／ネットワーク構成図／アプリケーション機能構成図も必要となることがあるらしい。
非機能要件
- 可用性(稼働時間・障害時の稼働目標など)
- 性能・拡張性(処理速度・今後の拡張性など)
- 運用・保守性(業務中の稼働レベル・問題発生時の対応など)
- 移行性(移行期間・移行方法など)
- セキュリティ(利用制限・データの取り扱い方など)
- システム環境・エコロジー(システム周りの環境関係)
非機能要件は軽視されがちのようですが、事業に大きな影響を与える可能性があるそうなので重要な検討事項である。
詳しくはご自身でご確認ください。
(巷のセキュリティに関するニュースはいつも胸がキリキリしながらチェックしているので、ここら辺はもっとしっかり学んでいきたい。。。)
運用・移行・総合テスト要件
- 運用要件書(運用・障害時の対応など)
- 全体移行計画書(スケージュール・移行方式など)
- 総合テスト計画書(概要・テスト方針など)
障害時の対応や以降方式などは非機能要件でも被りそうなので、もしかしたら非機能要件でまとめている可能性もあるかもしれない。
感想
機能要件がとっても大変でした。
処理の流れだけではなく、データの流れ、画面の構成、画面の遷移とかとかとかとか・・・
「あ、そっか、これも決めておかないとか、あ、頭の中で思っていた画面構成だと文字数の関係で組めないよ、よし、見た目よし！仮の値を置いてみよう！うわーー範囲内に入らないーーーー！！！」と、5回くらい画面の見え方を修正しました汗。
私はプログラムを組みたい側なのでデザインはからっきしなので苦戦しました。
デザインもある程度できる人間になりたいです。
あと、非機能要件も難しかったですね。
ユーザーから値を取得する機能があるので一般的なセキュルティ対策を行うのは前提でしたが、他にも決めないといけないことが多くて頭を抱えました。
実際に個人開発でも自分で要件定義をしっかり作るという工程を踏んで沢山学ぶことがあったのでやってみて良かったです。自分がいかに詰めが甘いかや、そうか、システムってこうやって作られていくのかと、とても学びになりました。
ここまでしっかり考えたので、実際にシステムをリリースしたいですね。頑張ります。
参考
コメント