Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
モデルベースの要件定義で 要件定義と実装との距離を近づける / requirement...
Search
natsu
December 23, 2020
0
560
モデルベースの要件定義で 要件定義と実装との距離を近づける / requirements definition and implementation
モデルベースの要件定義で 要件定義と実装との距離を近づける為に試したり考えていることの発表です。
natsu
December 23, 2020
Tweet
Share
Featured
See All Featured
How to Think Like a Performance Engineer
csswizardry
25
1.7k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
32
2.4k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
233
17k
Build your cross-platform service in a week with App Engine
jlugia
231
18k
KATA
mclloyd
30
14k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
Writing Fast Ruby
sferik
628
62k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
2.9k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
667
120k
Navigating Team Friction
lara
187
15k
Done Done
chrislema
184
16k
YesSQL, Process and Tooling at Scale
rocio
173
14k
Transcript
モデルベースの要件定義で 要件定義と実装との距離を近づける 2020/12/23 設計 モデリング LT会 @natsukbd
Profile natsu Twitter : @natsukbd サーバーサイドエンジニア ⾔語 : メインはPHP 最近取り組んでいるもので関⼼の強いもの
RDRA, DDD, アジャイル開発など
要件定義で⾒かけるツラいやつ • ドキュメントが古くてツラい • ドキュメントの整合性が取れていなくてツラい • 設計・実装・テストに活かせないくてツラい
なんとか実装に活かせるようにしたい
• 実装は要件の実現なので要件定義の精度を上げてお互いの距離を近づけたい なんとか実装に活かせるようにしたい
RDRA2.0 • モデルベースの要件定義⼿法 • RDRAはコミュニケーションが円滑になる構成や整合性 を担保する仕組みをまとめたモデリング⼿法です • ※ RDRA2.0 ハンドブック
「はじめに」より • 現在のバージョンは 2.0
RDRA • コミュニケーションを取りながらダイアグラムをリアルタイムに更新する • ドキュメントが更新されないといった状況に陥らないようする • アイコン同⼠をつなぎ、つながっている理由は説明できる必要がある • 整合性の担保
RDRAレイヤー • システム価値、システム外部環境、システム境界、システムの4つのレイヤー に分かれる • それぞれのレイヤーで定義されるアイコンが決まっている • アイコン同⼠のつながりが決まっている
RDRAレイヤー
None
RDRAレイヤー RDRAレイヤーの説明は重要なのですが、今回はテーマにたどり着けなくなるので省略します... アイコンのつながりについても、今回触れる箇所のみ話します 「4つのレイヤーで定義されるアイコンとアイコンのつながりが決まっている」ことだけ抑えていただい て進めたいと思います
よくある⽂章のドキュメント • 条件が機能ごとや画⾯ごとに説明された⽂章のドキュメントで書かれている • 同じ条件が使われる場⾯を洗い出すのが難しい • ビジネスルールが変わった場合に対象となるドキュメントすべての更新が必 要となる • 更新されなくなったり、整合性がとれていなかったり...
RDRAで考えてみる
例 : 条件に焦点を当てて話します • 例えばあるネットスーパーで以下のような条件があったとします • ポイントn倍デーがある • ポイントの倍率は曜⽇によって決まる
バリエーションと条件 • RDRAでは条件をバリエーションの組み合わせによる 単純な表組みで表現する • 単純な表組みは実装に活かしやすい
ユースケースと条件のつながり • 画⾯と条件はそれぞれユースケースとつながっている • 関係を辿りどんな条件が関わるか知ることができる • 画⾯の説明に条件の話が含まれてしまうような状態にならない • ユースケースはユースケースを実現するためのクラスの候補にできる
• ユースケースが増えてもどこで同じ条件が使われているか 辿ることができる ユースケースと条件のつながり
ユースケースと条件のつながり • 影響範囲が明確であるため、ポイント付与条件が変わる場合の 対応漏れを防ぐことができる
• コミュニケーションをとってダイアグラムを更新することによって最新の状態が保たれる • 実装して古かったといった事態が起きない • ⼀⼈で作業ではなくコミュニケーションしながら作るのでドキュメントの質が⼀定に保たれる • 関係を辿ることで何故そうなっているのか理解できる (説明できる) •
整合性が取れていないことによる確認や⼿戻りを減らすことができる • 同じことを⾊んな場所で書く必要がない為更新漏れが起きない • 要件定義と実装の距離を近づけることで要件の変化をソフトウェアに素早く反映できる • この距離が遠いと何故かまったく関係ない場所に影響が及ぶコードになっていたり... RDRAのいいところまとめ
より実装に近づける為の情報 • 最後に、より実装に近づけるために参考にできそうな情報を紹介します • CCSR という開発⼿法で RDRA が使⽤されています https://masuda220.hatenablog.com/entry/2020/05/27/103750 •
要件定義と実装を近づける話をしましたが RDRA ⾃体は要件定義⼿法であり、どう実装するか は対象外であるため CCSR のような RDRA を実際に使⽤した開発⼿法を知ることは実装につ なげるための重要な⼿がかりになるとおもいます • ※ こちらは参考になる情報として掲載していますが今回の発表内容は RDRA についての話と、実装に活 かすための考えを私なりに整理して話したものであり、その過程で参考になった情報の⼀つとして掲載し ています。ですのでこの発表は CCSR の内容を解説したものではございませんのでご注意ください。
ご清聴ありがとうございました