RDRA 2.0 をたしなむ - 4つのレイヤーの取り扱い方②
RDRAの導入も進んで、ダニングクルーガー効果の「なんもわからん」の状態になってきました。
成長していればいいなぁ・・・。
今回は、４つのレイヤーのうちのシステム境界とシステムについてやっていきたいと思います。
システム境界
このあたりからはシステムが行うことを具体化していく流れになります。(ただし、実装は書かないことがポイントらしいです）
まずシステム境界レイヤーの定義は、下記のようになっています。
システムとどう関わるかを明らかにするのがこのレイヤーです。システム境界には人との境界とシステムとの境界の２つがあります。
システムの利用する立場を「外部システム」か「人」のどちらかであるとして、その2つのシステムとの関わり方を示すレイヤとなる・・・と考えていきます。
そして取り扱うものは下記の範囲となります。
- システムを使った作業単位を明らかにする(ユースケース)
- ユーザーインターフェースを明らかにする(画面（帳票含む）)
- 外部システムとのインターフェースを明らかにする(イベント)
「ユースケース」ですが、「外部システム」か「人」かの区別はなく、どちらの場合でも同じように情報を処理する場合に出力していきます。
個人的にはこのユースケースが上げるのがRDRAの中で難しいと考えているのですが、「情報を状態Aから状態Bに変換するトランザクション処理」に着目して、そこに「〜〜する」のような命名をつけていってます。
プログラミングの参考書でよく出る銀行系の「Aさんの口座から5,000円をBさんの口座へ振り込むケース」の場合、「銀行口座での振り込み」とのユースケースが提示され、そこにAさんとBさんのような「ユーザー」が紐づく感じですね。
なお、業務分析でRDRAを使っている現状だと「状態Bが多すぎる場合に、ユースケースを日本語でまとめにくくなる」と感じます。（ステータス遷移が多すぎて、一言でまとめにくくなります）
おそらくですが、次の「システム」で説明する「状態」を整理することでまとまっていくのではないかなぁ・・・という印象を受けています。
システムレイヤー
まずシステムレイヤーの定義は、下記のようになっています。
システム化する情報とその情報が取り得る状態でシステムを明示します。
システムレイヤーは要件の要として整合性を維持するために存在します。
そして取り扱うものは下記の範囲となります。
- システムが扱う情報（概念）を明らかにする。(情報)
- 情報が取りうる状態を明らかにする。(状態)
わかるような・・・わからないような・・・と所見でなったので、上にでてきた銀行の例で例えると、下記のようになりますね。
情報->銀行口座
状態->(Aさんの口座) 5,000円の減額、(Bさんの口座) 5,000円の増額
銀行口座という情報の中で減額・増額という状態を扱っていく感じですね。
こうした状態をまとめれたら、ユースケースに紐付けて情報の変化を見ていくことを行うレイヤのようです。
本日はここまでにします。
