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
モデルベースの要件定義で 要件定義と実装との距離を近づける / requirements definition and implementation
Search
natsu
December 23, 2020
0
510
モデルベースの要件定義で 要件定義と実装との距離を近づける / requirements definition and implementation
モデルベースの要件定義で 要件定義と実装との距離を近づける為に試したり考えていることの発表です。
natsu
December 23, 2020
Tweet
Share
Featured
See All Featured
Designing on Purpose - Digital PM Summit 2013
jponch
111
6.5k
YesSQL, Process and Tooling at Scale
rocio
165
13k
Agile that works and the tools we love
rasmusluckow
325
20k
What's new in Ruby 2.0
geeforr
337
31k
4 Signs Your Business is Dying
shpigford
176
21k
Learning to Love Humans: Emotional Interface Design
aarron
267
39k
The Illustrated Children's Guide to Kubernetes
chrisshort
32
46k
The Brand Is Dead. Long Live the Brand.
mthomps
49
29k
StorybookのUI Testing Handbookを読んだ
zakiyama
13
4.6k
Creatively Recalculating Your Daily Design Routine
revolveconf
211
11k
Become a Pro
speakerdeck
PRO
13
4.6k
The World Runs on Bad Software
bkeepers
PRO
61
6.7k
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 の内容を解説したものではございませんのでご注意ください。
ご清聴ありがとうございました