要件定義idea本記事について最近この本を読んで、実際のプロジェクトで使ってみているところです。試行錯誤の真っ最中です。良さそうな感触はありつつ、結構大変だな〜と思うところもあったので、体感したみた感想を交えて実際の作成方法も紹介していきます。オブジェクト指向分析からSpringによる実装まで』https://www.amazon.co.jp/dp/B01B5MX2TC/また、ユースケース駆動開発(ICONIXプロセス)自体は別の方が紹介してくれているので、本記事では詳細は割愛した上で、詳細設計や実装の話は完全に省き、要求定義〜基本設計までの流れについて書いていきます。https://zenn.dev/tomoeine/articles/2babb554aa0478前提ドキュメントの管理はGithubで行なってますVScodeを使ってMarkdownやdrawioで書いてますざっくりICONIXプロセスICONIXプロセスとは、UMLを描きながら、ユースケースを中心に設計していく手法のことです。以下の手順で行います。テスト」と続いていきますまずは「ドメインモデル図」を作成VScodeの拡張機能で、drawioで作成しました。詳細化されていないし不完全な状態ですが、書籍によればこれでOKで、このあと詳細なユースケースを記述していくときに必要に応じてアップデートすれば良いみたいです。描くまでもないかな〜と思ってましたが、描いてみたら頭の中が改めて整理できたので描いてよかったです。!PlantUMLやMermaidではだめか?慣れてるならそちらの方が良いと思います。UMLをアップデートしながら設計していくプロセスなので、追加や修正が割と発生しますのでdrawioだと大変かもしれないです。私は慣れてなかったですし、処理が複雑だったり図が大きくなりすぎると見辛くなってレイアウトの微調整が大変でした。直感的にかつ柔軟にレイアウトを微調整しやすいdrawioに落ち着きました。次に「ユースケース図」の作成ドメインモデル図と同様にdrawioで作成しました。「そのユースケースは、このユースケースの後にできるようになる」といった、ユースケース間の関係を図示できるようになり、UIデザインとの整合性や流れがわかるようになりました。フォルダ構成を決めてなかった...このあとは「ユースケース記述」と「ロバストネス図」を作成していくのですが、どのようなフォルダ構成で管理するか設計していませんでした。記事も探しましたが見つからなかったので、自分なりに考えた結果、以下の通りになりました。...何か仕様を確認したいときにrequirementに来たら、ユースケース記述のドキュメントが並んでいるREADMEにドメインモデル図とユースケース図を埋め込んでおくことで要件の全体感がパッと分かるというのを意識した結果です。「ユースケース記述」と「ロバストネス図」どちらもユースケースごとに作成し、それぞれを行き来しながら更新していくことで要件定義と詳細設計の間を埋めていくことができます。以下のフォーマットに沿ってMarkdownで記述していきました。これに沿って記述するテキストと、このあと触れるロバストネス図は1枚のドキュメントで見られると良いとのことなので、Markdownファイルの中に画像を埋め込む形にしました。加えて、「ロバストネス図」だとぱっと見よく分からない人もいそうなので「処理フロー図」と勝手に呼ぶことにしました。代替コースこのとき「ユーザーが〜すると、システムは〜を取得して表示する」といった感じで、ユーザーとシステムの対話になるような記述にするのが大事みたいです。対話形式で書いてみて良かった点として、システムの振る舞いなのかユーザーの行動なのかが明確になったこと、適当にぼやかして書くと伝わりにくくなり自然と細かく書くようになったこと、設計まで考慮して考える時間が増えたことがあげられます。先ほども触れた通り「処理フロー図」と呼ぶことにしています。ユーザーがそのユースケースを完了させるまでの流れを画面、処理、エンティティで書き、関連しているユースケースと紐付けて相互にリンクさせています。関連するユースケースを紐づけることで、それぞれのユースケース間の関わり方や呼び出し関係なども整理できました。第1弾を描いて、エンジニアと詰めて、絵を更新して、テキストも直して、デザイナーとも議論して、、、というのを繰り返してブラッシュアップしたので精度は割と高いのかなと思ってます。基本的にビジュアルで仕様を整理するので、自分の理解も深まるしメンバーへの説明もしやすい詳細設計の途中まで踏み込むので抜け漏れも少ない(はず)UIデザインと処理との整合性チェックがしやすかったユースケース記述ではユースケースの開始から終了まで順番にテキスト化+ビジュアル化していくので、それ自体がマニュアルにもなるくらいまで記載されることになる(そしてテストケースにもそのまま流用できるはず)悪かった点UMLのレイアウトの微調整が大変(体感的にはほとんどが絵を描く時間)ユースケースごとに切り出すことでその機能の全体感が掴みにくくなる例えば「社員データを新規登録する」「社員データを削除する」と分かれていても、新規登録の部分だけで設計はせず、削除も含めた全体で設計を行うことになったユースケースのモデリング自体が悪かった可能性もあるが正直よく分からないまとめ悪かったこ点にも書きましたが、UMLを描くのが結構大変です。どの規模でもある程度いけそうな手法だと思いますが、ユースケース数が多かったりそもそも複雑だったりするとかなり時間取られます。個人的には好感触だったので、引き続き運用も含めてブラッシュアップしていこうかなと思います。より固定NCDCでは、一緒に働いてくれるエンジニアを通年で募集しています。詳しくは下記をご覧ください。)のエンジニアチームです。Proよくある質問LinksX(Twitter)GitHubメディアキットLegal利用規約プライバシーポリシ。