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 to Think Like a Performance Engineer
csswizardry
26
1.9k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
358
30k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
7
840
Making the Leap to Tech Lead
cromwellryan
135
9.5k
Producing Creativity
orderedlist
PRO
347
40k
Why Our Code Smells
bkeepers
PRO
339
57k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Why You Should Never Use an ORM
jnunemaker
PRO
59
9.5k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
111
20k
Code Review Best Practice
trishagee
70
19k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
53
2.9k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
667
120k
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 の内容を解説したものではございませんのでご注意ください。
ご清聴ありがとうございました