RDRAについて学んだことメモ２
今回はこちらを参考にさせていただきます。
・要求の専門家 ←要求工学系。アカデミックに近い文脈。
・開発者向けの本 ←RDRAはここ。要件定義をやったことのない開発者向けの本。
前回の記事を書いていて、RDRAって要求工学と何が違うの？と思っていたので一定明らかになってよかったです。つまり、要求工学の手法の一つだけれど、より実践に近い手法。要求工学の知識がなくても理解できる手法。と理解しました。それならしっくりきます。
RDRAの言葉は要求の専門家が使う言語とずれていてもやもやする。
網羅性≒完全性、とかですね。個人的にはそこぐらいは要求工学とあわせてほしいなと思いますが、上述の通り要求工学の知識がなくても理解できることを目指すのであればどんな用語を使っても問題ないでしょう。
RDRAというと、モデル化に目が行きがちだけれど、そっちは別の所で学べば良くて、それよりも『要件定義の4つの構成要素』が大切
そうなんですね。モデル化も一つの価値だと思っていましたが、まぁ確かのその点に関しては他の手法もあるわけで、RDRAならではではないということですかね。モデル化できる道具立ての中で、どれを選ぶと要求を表現しやすいか、のまさに「フレームワーク」を提示しているところがRDRAの価値だということですね。納得性はあります。使ったことないですが。。
ステークホルダー要求つまり、システムが生み出す価値からシステムまでのトレーサビリティを重視しているのがRDRAです。
これがまさに「リレーション」の部分ですね。整合性が1つの売りとして言われていることからもよくわかります。実際システム開発をしていて、各システム要件がどんなユーザの要求を実現するものなのかがわからないことがあったりするので、大切さは身にしみてわかります。
書籍の中に「プロトコルモデル」というものがあるが、参加者も主催者も「よくわからん」と言っていた。
これは僕も全く理解できていません。。書籍もまだ読んでないですしね。。状態遷移だとするとそれって内部（システム）に該当するのではと思いますし。状態が大事だというのは疑いの余地のないことだと思いますが、果たしてプロトコルモデルがそれを狙っているのか、についてはちゃんと書籍から理解しないとですね。
要件定義のフレームワークであるRDRA、モデル化は当然のこととして相互の関係性を明らかにし、トレーサビリティを維持する。あー使ってみたくなってきましたね。