目次
はじめに
ロボットなどを使って、
自動化システムを開発する人向けの
要件定義の方法や、言葉の定義、作成物のリストなどをまとめておきます。
要望、要求、要件の違い
いろんな定義がありますが、自分が下記の定義が個人的に好きです。
| 英語 | 意味 | |
|---|---|---|
| 要望 | (User) Needs | ユーザが最終的に実現したいこと |
| 要求 | User requirement | 要望を実現するために、ユーザが具体的に実現したいこと |
| 要件 | System requirement | 要求を実現するために、システムが実現すべきこと |
要件の部分をもう少し噛み砕いて説明すると、
冒頭の書籍は要件をこのように定義しています。
要件とは： 依頼した人ができあがったものに対して「これならOKです」と言うために、「何がどうなればよいのか」ということを明確に定めたもの。
上記の定義に従って、これならOKです、と言うためには、
要望、要求、要件が明確になっている必要があります。
要件定義をするために準備すべきもの
基本的には、下記の資料を準備すると、自動的に要件定義を進めることができます。
1. プロジェクトやシステムの名称
まず、プロジェクトやシステムの名前をつけることが重要です。
ミーティング、ドキュメント、ソースコードなど全てにおいて、この名前が必要になります。
2. 5W1Hに基づくシステム概要
5W1Hに基づいて、システムの概要を定義すると全体像がわかりやすくなります。
Why: ユーザの要望はなにか？(要求と要件に関しては、後ほどまとめます)
What: 要求を満たすために、どのようなものをつくるか？
Who/Where: どこの誰がこれを使うのか？それによりどのような利益を得るのか？
When: 現時点でのユーザの納期はいつか？
How: どのような体制で開発を実施するのか？
3. ユースケース図
開発するシステムを真ん中において、そのシステムを使う人がどのように使うのかを列挙します。
システムのユーザには、システムの管理者や、外部接続のシステムなども忘れないようにしましょう。
4. モジュール図
開発するシステムの簡単なモジュール(サブ機能)分割図を記述します。
5. 基幹技術リスト
下記のような、今回のシステム開発で利用する下記の基幹技術のリストを作ります。
フロントエンド側のプログラミング言語はなにか?
フロントエンド側の実装フレームワークはなにか？
フロントエンドとバックエンド間の通信プロトコルはなにか？
フロントエンドとバックエンド間の通信のデータフォーマットはなにか？
バックエンド側のプログラミング言語はなにか？
バックエンド側の実装フレームワークはなにか？
どのデータベースを使うのか？
6. 要求リストを作る
ユーザが求めている要求のリストをこのタイミングで作ります。
一度ですべての要求をすべて上げるのは難しいと思うので、
下記のユーザストーリーなどを作る際に新しい要求を思いついたら、
またこのリストに追加してきます。
またシステムのための要件は、最後に作るので、
この時点ではあくまでもユーザ視点での要求をまとめることに注力します。
加えて、この時点では何を改善すべきかを明確にすることに注力し、
どのように改善するかまで踏み込まないようにしましょう。
7. ユーザーシナリオをつくる
前述の要求リストを元に、
その機能を使うユーザや、その機能の初期設定するユーザの
時系列の動きを決めるユーザーシナリオを作ります。
ユーザーシナリオを作るときに重要なのは、
ユーザーの行動のルールですが、この行動のルールは
「義務」、「禁止」、「契機」で表としてまとめると管理しやすいです。
またユーザシナリオを形作るフローとルールは分けて管理すると良い事が多いです。
なぜならフローでは同じルールを参照することが多く、
また、フローは変わることが稀ですが、ルールは時間につれて変更されることが多いからです。
この場合、ルールの表にIDをつけて、フロー側でIDを元に参照するようにすると、
ルール側が変更されても、フロー側を変更しなくてよくなります。
8. UI遷移図を作る
前述の各ユーザシナリオ毎に、
UIが絡むものに対しては、大まかなUI遷移図を作ります。
9. レポート(帳簿)機能についての要求をまとめる
どのようなシステムでも、
その稼働履歴やシステムの統計データのレポート出力機能が必要になります。
メインの機能では無いので忘れがちですが、
ユーザや、ユーザの上司、システムのサポートの人など、
様々なシステムのユーザの洗い出しと、
それぞれの人の要求を分析して、レポート機能を設計する必要があります。
10. エンティティモデルを作る
ユーザシナリオがだいたい出来てくると、
必要なデータ(エンティティ)も明確になってくるので、
それを元にエンティティモデルを作ります。
この時点でちゃんと定義できる場合は、
ER図まで作成しても問題ありませんが、
最初のステップでは、データの分類を四角で作って、
関連するデータを矢印でつなげるぐらいでもOKです。
11. ワークセットリストを作る
先程のユーザシナリオと、エンティティモデルから、
ユーザがエンティティを操作する、ワークセットのリストを作ります。
そして、このワークセットとエンティティを縦と横に並べて、表を作り、
それぞれのワークセットをCRUD: (Create, Reference, Update, Delete)で分類し、
すべてのエンティティがワークセットによって抜けなく操作できることを確認します。
12. 非機能要件の検討をする
上記の検討で、機能要件は網羅できますが、
下記の非機能要件検討する必要があります。
可用性 (システム稼働性)
性能、拡張性
保守性
移行性 (旧システムからの移行の場合)
セキュリティ
環境性(エコロジー性)
また、非機能要件を検討する上で一番重要なのは、
コストと非機能性のバランスを考えることです。
コストをかければ非機能性は向上させることができますが、
本当に必要なレベルを定義し、コストとバランスを取ることが必要になります。
非機能要件に関しては、下記のIPAの資料も非常に参考になります。
13. 要件リストの作成
最後に以上の検討結果を元に、最終的なシステム要件のリストや表を作成します。
要件定義を進め方
下記のように進めるとスムーズに進むことが多いと思います。
- 要件定義に参加する人や役割を表にし、明確化する。
- 定期的にステークホルダーをミーティングを実施し(ルーチン化)、合意を積み上げる。
- 最後に積み上げた合意をドキュメントにまとめ、承認をもらう。
参考資料
図解即戦力 要件定義のセオリーと実践方法がこれ1冊でしっかりわかる教科書
MyEnigma Supporters
もしこの記事が参考になり、
ブログをサポートしたいと思われた方は、
こちらからよろしくお願いします。
