概要 2021/10/29に開催された下記勉強会のメモです セッション RDRAはどう形作られたか? RDRAの構造 4つのレイヤーと依存関係 WhatとWhyを表現->要件定義ではこの2つを明確に Howは表現しない->Howを考えると手が止まる ビジネスユースケースでボリュームがわかる 打ち合わせの回数、時間など計画が立てられる RDRA導入後の要件定義の変化 ※公開資料見つかりませんでした 課題 プロダクトの業務仕様管理 業務仕様の把握・管理の属人化が進行 変更差分で全体像が把握できない 要件定義プロセス そもそもよくわかっていない RDRA導入 RDRAモデルによるサービス仕様マスタの作成 RDRAの要素を要件定義書フォーマットへ反映 改善事例 ビジネスユースケース(BUC)の定義活用 BUCをプロダクトの業務として定義、プロジェクトごとに共通単位として利用 BUC視点で話すと伝わ
従来の RDRA から RDRA2.0 では大きく 3 つの変更があります。 ダイアグラムのシンプル化 業務フロー、利用シーンを洗い出す方法の明示 ビジネスルールの記述方法の明示 「参考: RDRA2.0 ハンドブック の 1: RDRA2.0 とは より」 あまり使われなかったダイアグラムが整理されて、ビジネスユースケースモデルへの拡張があり、また、アイコンの形を規定しない や アイコン間の関連線に方向はつけない の変更により PlantUML で表現がやりやすくなりました。 サンプル: 図書管理システム RDRA2.0 ハンドブック の 10章:サンプル:図書管理システム から同じ内容でダイヤグラムをいくつか書きます。 (10.1. や 10.2. ... は RDRA2.0 ハンドブックの見出しと合わせています。) 10.1. ビジネスコンテキスト図 ビジネスルールに関わるビジネス要
本記事は、DDD-Community-Jp Advent Calendar 2020の19日目です。 はじめに DDD-Community-JP(以下、DDDCJ)内で開催するモデリング会で、RDRAをしたときの体験に基づいて、RDRAの進め方をお話しします。 ここでは、自分たちが実施した中の「こうやってうまくいった」「こうやって失敗した」の観点を中心にお話しします。 参考に出している実際にかいたモデル図は、正確にRDRAの方式に沿っていない部分も一部あります。 やり方の詳細や正確な表現は、RDRA2.0 ハンドブックをご参照いただくと良いです。 何を書く、何を避けるなど含めて書かれています。 RDRAについて RDRAってなに? Relationship Driven Requirement Analysis 読み方: らどら 神崎 善司さん考案の要件定義手法です。 モデルベースで、要件
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く