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
570
モデルベースの要件定義で 要件定義と実装との距離を近づける / requirements definition and implementation
モデルベースの要件定義で 要件定義と実装との距離を近づける為に試したり考えていることの発表です。
natsu
December 23, 2020
Tweet
Share
Featured
See All Featured
How STYLIGHT went responsive
nonsquared
100
5.8k
Balancing Empowerment & Direction
lara
4
680
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
54
3k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
Building an army of robots
kneath
306
46k
KATA
mclloyd
32
15k
Navigating Team Friction
lara
189
15k
Done Done
chrislema
185
16k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
29
2.6k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
GraphQLとの向き合い方2022年版
quramy
49
14k
Java REST API Framework Comparison - PWX 2021
mraible
33
8.8k
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 の内容を解説したものではございませんのでご注意ください。
ご清聴ありがとうございました