はじめに
システム検討を外注するときに、自社とベンダーで何をしていくかがいまいち分からない。これまで何となく、要件定義→機能開発→お試しで使う という流れをやってきた。この間にベンダーから色々指示を受け、最終的に機能一覧、プロトタイプが出来上がり、何となく使えるものが出来上がったものの、それぞれが何のためにあるのかが整理されない状態に見えた。プロトタイプをみながら各機能が何のためにあるかは説明出来るが、何ができるようになったかが漠然としてしまう。。今一度、要件定義を勉強しようと思った。
参考書
色々見てきたが、具体的に何をやればよいかが書いてあったと思うのはこちら
要件定義以降何をするのかがまとまった本がこちら
要件定義部分についての記載内容も良かった。
何をやるのか
2つの本の良いとこ取りを考えたい。
例題として、「MBSEの成果をストックするシステム」を考える。
要件定義は大きく2つの工程に分けられる。
【業務要件定義】
なぜシステムが必要か。何を期待しているか
【システム要件定義】
どのように課題を解決するか
業務要件定義 「システムの価値」
「誰の」、「何を」、からまずは明らかにする必要がある。
つまり「システムの価値」を明らかにしていくことになる。
使うモデルは
コンテキスト図、要求モデル
コンテキスト図
システムの関係者とその役割を出す
要求モデル
関係者が何を望むかの生の声or予測を出す。
これを要望と呼ぶ。
要望に対し、ナゼナゼを繰り返し、真の困りごとが見つかり、それに対し何をしたいかが要求となる。
なぜの種類として、
・なぜそれがおきるのか？
・なぜそれをしなくてはならないのか？
があり、QCTに影響するまでできればOK。
ここまでが業務要件定義となる。
システム要件定義
ここからは大きく以下の3つを明らかにしていく
・システムの外部環境
・システムの境界
・システムそのもの
「システムの外部環境」
業務フローを書き出す。
書いてるうちに、先程出した要求が出てきそうな箇所が見つかるはず。
「システムの境界」
まず、ユースケースを書き出す。
業務フローの中で対象となる箱を抜き出し、システムをどのように使わせるかを記述していく。これにより、システム設計のときに、ベンダーから何か良い提案をしてくれるはず。
次に、画面帳票モデルを書き出す。
ユースケースごとにユーザーがシステムに対し、何を入力して、何を得るかを書き出していく。ここで、ユーザーインターフェイスが表現されていく。
そして、イベントモデルを書き出す。
外部システムに対し、どのようなイベントが起きると、何をやり取りするかを書き出していく。ここで、システムインターフェイスが表現されていく。このモデルでは外部システムとやりとりが起きるイベントに限定する。
最後に、プロトコルを書き出していく。
システムがイベントを通して状態を変えていく様子を書き出していく。ステートマシン図が用いる。イベントは、イベントモデルにあるものに限らない。
「システムそのもの」
まずはデータモデル。
画面帳票モデルやイベントモデルで扱うデータは揃っているので、これをどのようにつなぎ合わせるかを書いていく。クラス図を用いる。このモデルを作成しているときに画面帳票で抜けがあることに気づいた。が、修正面倒なので放置。。
次にドメインモデル。
システム化対象領域を情報構造として表したもの。情報構造が複雑な場合に作成する。例えば、沢山のツールやソフトをシステムで管理する場合が該当する。今回は外部システムとして「SysMLツール」を入れているが、外部システムとして扱わない場合はこちらのモデルで構造化すると都合がよさそうだ。
最後に機能モデル。
システムがなにを行うかを書いていく。ユースケースやイベントを実施する機能が出てくるはずだ。＊で書いているのは、もしストックデータから学習モデルを作って設計するというユースケースが出れば、この機能が登場するだろう。
まとめ
ここにあるモデルが揃えば、あとはシステム設計に移れるはずだ。また、システム改修する場合もモデルを洗練していけば良いと思う。視覚的で分かりやすいので、時間が経っても利活用できると思う。ちなみにモデルたちは「drawio」というwebアプリで作成した。結構便利だと思う。CSMなどのSysMLのように階層構造を描くことはできなそうだが。。
