モダンな要件定義手法「RDRA」をRPGゲーム風にカスタマイズして説明してみた - Goodpatch Tech Blog
この記事はGoodpatch Advent Calendar 2022 18日目の記事です。 ソフトウェアエンジニアの 池澤です。 ここ最近はテクニカルディレクションとして仕事に関わることが増えました。その中で要件定義を作ったりデザイナーとエンジニアの橋渡しをする機会が多く、メンバーみんなが同じゴールを認識して制作できるようなより良い要件定義方法はないものかと探していました。 今回はそんな中で見つけたモダンな要件定義手法の一つ、RDRA（ラドラ）について、理解しやすくなるコツやカスタマイズしている内容についてお話しします。 なお、RDRAの詳細解説をするととても書ききれませんので、RDRA本体の詳細については公式サイト等をご参照ください。 RDRA（ラドラ）とは？ 概要 RDRAのバージョン これまでの要件定義でよくある問題 期待される要件定義の姿 公式サイト おすすめの学び方 実際のRD
PlantUML で始めるリレーションシップ駆動要件分析 (RDRA) - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに ソフトウェア開発において、エンジニアが開発対象のドメインの業務に精通していない場合、書く内容やかける時間に程度はあれど 業務分析 や 要件定義 が必要になります。しかし、要件定義の方法論についての話題がネット上に上がることも少なく、書籍などもあまり話題になっていない印象があります (私の観測範囲では)。なので、私の場合、要件定義の実務では公の方法論を体系的に学ばずに、実務で見てきたものを自分なりにアレンジして対応してきました。 そんなとき、モデルベースの要件定義の方法論として リレーションシップ駆動分析 (RDRA) というも
RDRA学習ロードマップ
RDRAが広まってきているので情報源を充実させたい リチャード 伊真岡です。最近私はRDRAという要件定義手法についてじっくり勉強しています。 RDRAは株式会社バリューソースの神崎善司さん(@zenzengood) が提唱している要件定義の手法です。日本のドメイン駆動設計コミュニティからも注目を集めているようで、ビジネスのルールをきれいにソフトウェアに反映しようとすると、要件定義に目が向くのは自然な流れです。 要件定義手法 RDRA 2.0のハンドブックのサンプル「図書館システム」の実装例です。 RDRAで可視化されたビジネスルール（バリエーション・条件・状態モデル）をビジネスロジックとして実装しています。 ドメイン駆動設計の実装例としても参考にしてください。 https://t.co/UyFscwKMPi#CCSR手法 — 増田 亨． (@masuda220) May 26, 2020
よりよい開発手法 - ソフトウェア設計を考える
ソフトウェア開発の問題点 従来のウォータフォール方式で、フェーズ分けと分業を重視し、手続き的なモジュール構造でソフトウェアを開発するやり方には次の問題があります。 大量のドキュメントの作成に膨大な時間と費用がかかる（工程が多く、必要な人員がふくらむ） フェーズ分けと分業のため、関係者の間の認識合わせが難しい（伝言ゲーム） ちょっとした変更でも、調査・修正・確認に膨大な時間がかかる（変更がやっかいで危険） 一方、アジャイルと呼ばれる開発のやり方は、以下の問題が起きがちです。 ソフトウェアの規模が大きくなると、どこになにが書いてあるか理解ができなくなる 増築・改築の繰り返しが、全体の構造と品質を劣化させる 全体を俯瞰したり構造を確認するための情報がなく、変更の影響がわかりにくい ちょっとした変更でも、調査・修正・確認に膨大な時間がかかる（変更がやっかいで危険） どちらのやり方でも 変更がやっか
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
