モダンな要件定義手法「RDRA」をRPGゲーム風にカスタマイズして説明してみた - Goodpatch Tech Blog
この記事はGoodpatch Advent Calendar 2022 18日目の記事です。 ソフトウェアエンジニアの 池澤です。 ここ最近はテクニカルディレクションとして仕事に関わることが増えました。その中で要件定義を作ったりデザイナーとエンジニアの橋渡しをする機会が多く、メンバーみんなが同じゴールを認識して制作できるようなより良い要件定義方法はないものかと探していました。 今回はそんな中で見つけたモダンな要件定義手法の一つ、RDRA（ラドラ）について、理解しやすくなるコツやカスタマイズしている内容についてお話しします。 なお、RDRAの詳細解説をするととても書ききれませんので、RDRA本体の詳細については公式サイト等をご参照ください。 RDRA（ラドラ）とは？ 概要 RDRAのバージョン これまでの要件定義でよくある問題 期待される要件定義の姿 公式サイト おすすめの学び方 実際のRD
Chatworkのドメインをモデリングした / Modeling Chatwork domain
Object-Oriented Conference https://fortee.jp/object-oriented-conference-2020/proposal/c44ec6d8-1cca-44b0-812b-3617beabaa83 #ooc_2020
PlantUML で始めるリレーションシップ駆動要件分析 (RDRA) - Qiita
はじめに ソフトウェア開発において、エンジニアが開発対象のドメインの業務に精通していない場合、書く内容やかける時間に程度はあれど 業務分析 や 要件定義 が必要になります。しかし、要件定義の方法論についての話題がネット上に上がることも少なく、書籍などもあまり話題になっていない印象があります (私の観測範囲では)。なので、私の場合、要件定義の実務では公の方法論を体系的に学ばずに、実務で見てきたものを自分なりにアレンジして対応してきました。 そんなとき、モデルベースの要件定義の方法論として リレーションシップ駆動分析 (RDRA) というものがあることを知りました。モデリングはずっと取り組んできていることなので、興味が湧いて少し調べてみると PlantUML でも表現できるというではありませんか！ PlantUML Example for RDRA 2.0 ハンドブック そこで、RDRA2.0
リレーションシップ駆動要件分析(RDRA) - Qiita
リレーションシップ駆動要件分析(RDRA)とは？ 要件定義において、重要な要素が3つあります。 「網羅性」：システムの目的や、それを実現するための要件が漏れや重複無く定義されている 「整合性」：各要件の整合性が取れている 「表現力」：それぞれの要件が分かりやすく表現されている 複数の人間で共同作業する際にも、網羅性によって要件定義に必要な情報の枠組みが決まり、整合性によって作業の手順が決まり、表現力によって共通認識を確立します。 リレーションシップ駆動要件分析(RDRA)とは、要件定義において重要なこれらの３要素を高いレベルで実現するための要件分析フレームワークです。 RDRAでは要件定義を4つの構成要素に分け、UMLを拡張した表現方法で要件分析を行います。 よくあるように要件をリストでただ並べるのではなく、UMLの視覚効果を利用することで表現力を実現します。 要件定義についてはこちら↓
DDD with RDRA, ICONIX
DDDを具体的なプロセスに落とし込むにはどういう観点が必要だろうか。 - 境界づけられたコンテキストがどこまでの範囲かよくわからない - ユビキタス言語やドメインモデルをどのように発見すればいいかわからない。どこから着手すればいいのか？ - ドメインモデルがただのデータの入れ物になってしまう(貧血症) という問いに答えるには、RDRA, ICONIXを検討するとよいというテーマの資料です。
ビジネスモデル2 rdra
3. ビジネスモデルの分析１ コスト構造 収益の流れ パ ー ト ナ ー 顧 客 セ グ メ ン ト 価 値 提 案 リソース 主要活動 チャネル 顧客との関 係 ビジネスコンテキスト ２．ビジネスコンテキスト 登場人物の洗い出し ・顧客セグメント ・パートナー ・商品・サービス ← 価値提案 主要活動 リソース 業務の洗い出し ・登場人物の役割や関係から業務を分類 ・業務と登場人物をつなぐ １．ビジネスモデルキャンバス ・顧客を決める ⇒ 顧客セグメント別にシートを作成 ・価値を洗い出す ・パートナーを洗い出す ・主要活動を洗い出す ・顧客との関係チャネルの洗い出し ・主要活動のためのリソースを洗い出す 会社 顧客 パート ナー 商品 パート ナー サービ ス 営業 購買 物流 業 務 業 務 ビジネスモデルキャンバス ビジネスモデル分析 4. 業務設計 ビジネスコンテキスト 会社 顧客
Rdra4 dddワークショップ
8. 8 ユースケースから機能、データまで システム ７．ユースケースに関わる ユーザーインターフェーズ を洗い出す uc ユースケース ＸｘｘｘをＹｙｙｙする ＸｘｘｘをＷｗｗｗする ＵｕｕｕをＬｌｌｌする システム主体者１ システム主体者２ システム主体者３ システム主体者４ KkkkkをXする OをOnnnnする イベントモデル プロトコルモデル ８．ユースケースを実現 する機能を洗い出す custom 画面モデル <<画面>> 商品登録画面 - 商品名 - 取引先 - 荷姿 - 発注単位 - 商品カテゴリ <<画面>> 販売状況照会 - 月 - 商品カテゴリ <<画面>> 発注登録 - 商品 - 発注日 - 発注数量 - 入荷予定日 <<画面>> 商品説明 - 商品カテゴリ <<画面>> カート処理 - 受注番号 <<画面>> 受注照会 - 顧客名 - 受注日 商品売上詳細 - 商
モデルが導く要件定義、文章が導くプログラミング
高校生の頃、私はシンセサイザーを購入し、ハードロックバンドのキーボーディストになることを夢見て演奏の練習をした。しかし、基礎もなく見よう見まねの独学による練習だったので、思うように上達しなかった。そこで、ふと思った。「自分が弾ける曲を作ればいいじゃん」あの頃からもう30年以上過ぎているが、このような発想は、今も私の基本的な行動原則である。現在は、ソフトウェア開発者として試行錯誤を重ね、そこで得たものを自分のソフトウェア開発戦略として実践している。この根底にあるものは、あのときと同じ「自分ができるようにすればいいじゃん」という行動原則である。このブログでは、私のソフトウェア開発戦略を、少しずつ紹介していきたいと考えている。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
