SysMLの要求図の書き方

SysMLの要求図の書き方についてメモ。
間違っていたら後で直す。

【参考】
astah 6.1 で「要求モデル」が目指している姿：An Agile Way：ITmedia オルタナティブ・ブログ

「何故システムモデリングが必要か」 | 株式会社オージス総研

第2回 SysMLとは何か | Think IT

第2回目 SysMLとは？SysMLの現状 : つれづれブログ

SysML : つれづれブログ

第3回目 SysMLセミナー感想 : つれづれブログ

The Rational Edge：汎用グラフィカルモデリング言語「SysML」 パート2：グラフィカルなモデル言語で製品構造を記述 (1/2) - ITmedia エンタープライズ

「システムエンジニアリングで SysML を使いこなす」第2章　実践編－電光掲示板を設計する(1)

astah* professional 6.1の要求図: プログラマの思索

TestLinkとEnterprise Architectを連携する: プログラマの思索

【1】SysMLは特に、組込みシステムの要件定義や方式設計で使えるモデリング図法。
UMLとかなり重複しているが、ブロック図のように、エンタープライズ系では使わない図法もある。
電気回路を作る所ならば、ハードウェア技師とコミュニケーションするのに役立つかもしれない。

僕は、SysMLの中でも要求図に一番興味がある。
業務システムの要件定義でも、Whyに相当する要求と要求仕様(SRS)を関連付けて、詳細化していく作業は重要だ。
設計していると、すぐにWhyの部分を忘れてしまいがち。
だから、要求図を使って、本来の要求を詳細化していく過程で、仕様と要求を常にリンクするようにしながら、要求と仕様のズレをなくしたい。

平鍋さんがastah 6.1 で「要求モデル」が目指している姿：An Agile Way：ITmedia オルタナティブ・ブログで書いているように、「モデルは要求を満たす(satisfy)」「テストは要求を検証する(verify)」のように表現したいのだ。

要求図が要件定義に使えるかどうか、以下検討してみる。

【2】astahならば要求図がすぐに書ける。
要求図のイメージは、ゴール指向分析。

要求工学 第14回：ゴール分析(エンタープライズICT総合誌 月刊ビジネスコミュニケーション)

SysML要求図をGSNと比較する

要求工学 第15回：iスター・フレームワーク(要求工学：Requirements Engineering)

つまり、定性的で曖昧な要求をゴールとしてとらえ、普通はツリー構造でゴールを分解しながら仕様へ詳細化していく手法。
SysMLの要求図も、要求(Requirement)をツリー構造で細分化していく。

【3】astahの要求図の書き方は下記が分かりやすい。

要求を整理してみよう （PDF、1568KB） - Astah

Astah* SysMLの各図の動画　要求図と要求テーブルの作成

astahの要求図における要求は、idとTextの2つの属性を持つ。
idは一意な番号。
Textは要求の内容。

要求同士の関係は以下の種類がある。

・Contain：包含
　→親の要求を複数の子の要求へ分解すると、親の要求は子の要求の論理積になる
　　つまり、親の要求を満たすには、全ての子の要求を満たさなければならない。

・deriveReqt：派生
　→一方の要求が他方の要求から派生した要求の依存関係。
　　この関係で要求を詳細化する時が多い。

・satisfy：充足
　→要求とその要求を満足させるモデルとの依存関係。
　　例えば、ブロックやインターフェイスなどの振る舞い構造を持つ実装モデルと捉えられる。
　　ゴール指向分析におけるソリューションに相当する。

verify：検証
　→要求とその要求をシステムが満たしていることを検証するテストケースとの依存関係。
　　例えば、受入テストケースとして捉えられる。

refine：詳細化
　→要求とその要求を詳細化して得られるモデルとの依存関係。
　　例えば、モデルはユースケースのような明確な機能要求として捉えられる。

copy：複製
　→クライアント要求とサプライヤ要求間の依存関係で、クライアント要求のテキストがサプライヤ要求の読み取りコピーであること。
　　例えば、該当の要求が法令から派生している時に使われる。

trace：追跡
　→要求間の追跡の関係。使われない。

rationale
　→要求間の関係が、要求と根拠になっている。

problem
　→要求間の関係から生じる欠陥、制限などの望ましくない問題。

いずれの関係も矢印の向きは、子→親に向く。
UMLのクラス図と同じ。

【4】astahの要求テーブルは、要求図を表形式にしたもの。
要求のidとTextの一覧。

要求図の利点、使えそうな点についてメモ書きする。

(1)要求図の要求には、非機能要求を表現できること。
例えば、性能要件、耐障害性、ソフトウェアの保守性向上など。
UMLのユースケース図の弱点は、ユースケースが機能要求の詳細化という定義故に、非機能要求が書けないこと。

(2)要求図は、派生開発プロセスXDDPのUSDMに相当する。
第3回目 SysMLセミナー感想 : つれづれブログにも書かれている。
つまり、清水さんのXDDPの要件定義手法を、要求図の作成作業へ適用できる。

やはり要求を階層ツリーで表現するのは、それなりのテクニックの習熟を必要とする。
だから、XDDPのような日本人に向いた手法と組み合わせた方が確実だと思う。

また、USDMは絵としてとても見づらいが、要求図で書けば綺麗に書ける。

(3)要求図にゴール指向分析のアイデアを適用できる。
SysMLの要求図とゴール指向分析の比較は下記に書かれている。

SysML要求図をGSNと比較する

要求とゴールはほぼ同じ意味。
従って、要求のツリー構造とゴールのツリー構造はほぼ同じように書ける。
但し、ゴール指向分析にでてくるアクターや資源などはマッピングできない。

微妙に違う点もある。
ゴールツリーは戦略の分析なので、要求のツリー構造そのものに分解理由を表現できない。
そこで、要求図に「rationale(理由、根拠)」の吹き出しを入れることで代用できる。
rationaleには、要求の根拠や要求の前提条件を書くと良い。

要求図では、要求から設計モデルへの詳細化はrefine、要求の実現方法としての設計モデルはsatisfyで書ける。
つまり、要求から要求仕様への詳細化(実際はユースケース)はrefine、要求の実装(例えばアクティビティ図、状態遷移図、シーケンス図など)はsatisfyで書ける。
この手法は、ゴール指向分析の追跡にも使える。

ゴールツリーの追跡は、要求図のtraceで表現できる。
但し、要求図のtraceは推奨でないので使いにくい。

(4)要求図は、関与者利害関連表における各セルを詳細化した図である。

関与者利害関連表は、利害関係者と要求のマトリクス。
問題に対する利害関係者の要求を当てはめることで、利害関係者の要求が明確になり、要求項目の抽出が促進されて、網羅性が高まる利点がある。

例えば、Astah* SysMLの各図の動画　要求図と要求テーブルの作成を見ると、「スマートフォンの要求[マーケティング担当者の要求]」という要求図を作っている。
つまり、要求の発生元である利害関係者の観点から要求を抽出して整理しようとしている。

Road To IT-Engineer / ITエンジニアの生きる道: ユーザーより1歩先に行くための業務分析ノウハウ～業務スキルでユーザーと勝負しても勝てない！ ユーザーをリードするためのモデル化の手法

Road To IT-Engineer / ITエンジニアの生きる道: アーキテクトを目指すITエンジニアのための「要求分析」

要求図のタイトルは、「req 要求図のタイトル[利害関係者の要求]」の形式であり、どの人の観点による要求をまとめたものか、を意識して書く。
だから、関与者利害関連表とセットで書くと、要求の関連が分かりやすくなる。

(5)要求図から、要求とモデル要素、要求とユースケースのマトリクスを作成できる。
これは、要求とユースケースのマトリクスは、XDDPのトレーサビリティマトリクスに相当する。

トレーサビリティマトリクスを意識することで、モデルはどの要求から発生したのか、モデルには全ての要求の制約条件が反映されているか、をチェックしながら書くことができる。
要件漏れや設計漏れの原因のほとんどは、要求から要求仕様、モデルへの詳細化が不十分であることだと思う。

従って、XDDPのトレーサビリティマトリクスの作成技法を適用すると良いだろう。

以上をまとめると、XDDPやゴール指向分析の手法を要求図へ適用すると、要求図を書きながら、質の良い要求分析が可能になるように思える。

【5】要求図を使うことで、要求の8つの品質特性(妥当性、非曖昧性、完全性、一貫性、順序付け、検証可能性、変更可能性、追跡可能性)を満たすように、作業できるか？

要求の品質特性を要求図で表現できるか、検討してみる。

チケット駆動開発を要求工学の品質特性の観点から考える～チケット駆動開発がAgile開発を必要とする理由: プログラマの思索

* 妥当性(正当性、必要性)
　要求仕様に全ての要求が網羅されている
　ソフトウェアが持つべき要求仕様が要求に含まれており、かつ、それ以外の要求を要求仕様に含まないこと
　↓
　関与者利害関連表から要求図へ落とし込むようにすればよい。
　要求を更に分割する時は、containを使えば、要求を論理積に分割できるのでOK。
　XDDPのトレーサビリティマトリクスを使ってチェックしてもいい。

* 非曖昧性(無曖昧性, 明確性)
　すべての要求が一意的に識別できる
　何通りにも解釈できる書き方をしない
　↓
　要求にはidが一意に振られるのでOK。

* 完全性
　要求仕様に必要な情報がすべて記述されている
　↓
　要求のtextに必要な情報を書くことでOK。
　要求の根拠はrelationale、要求が法令から発生した内容を説明するにはcopyを使えば良い。
　XDDPのUSDMの手法を使うと、要求仕様を明確に書くことができるはず。

* 一貫性(無矛盾性)
　記述されている要求が互いに矛盾しない
　↓
　要求図を作り上げる時に注意するしか無い。
　XDDPのUSDMやトレーサビリティマトリクスの技法と絡めて、要求の整合性に注意する。

* 順序付け
　要求が重要性や安定性について優先順位付けされている
　↓
　要求図から設計モデル(ユースケース図、クラス図など)へ変換していく時に、順位付けすることになる。
　要求に順位というラベルを付けてもいい。

* 検証可能性
　要求仕様に含まれる全ての要求に対し、有限のコストで評価可能な手続きが存在して検証できる
　↓
　verifyを使えば、受入テストケースとして検証可能な仕様としてまとめることができる。
　satisfyを使えば、要求の実現可能性について、実際の実装仕様まで落とし込める。

* 変更可能性
　要求の変更に対して、容易かつ完全で一貫性を保って修正可能である
　個々の要求が独立していることが必要
　↓
　derivedで派生する要求に更に詳細化したり、refineで要求を設計モデルへ詳細化することで、変更可能な要求になるように調整する。
　RUPのようなオブジェクト指向分析が有効だろう。

* 追跡可能性
　それぞれの要求について，その背景，理由，意図などが明確で容易に参照できる
　↓
　要求図のtraceがまさに相当するが、多分使いづらい。
　要求の根拠はrelationale、要求が法令から発生した内容を説明するにはcopyを使うことで、要求の発生源を辿ることができる。
　つまり、要求の前方追跡可能性はOK。
　
　要求の仕様化はrefine、要求の実装仕様はsatisfyを使うことで、要求の実現方法を辿ることができる。
　つまり、要求の後方追跡可能性はOK。

以上をまとめると、要求図の各技法は要求の品質特性を満たすように使える。
但し、XDDPのように、より具体的に要求分析する手法とセットで運用する方が、効果が高いように思う。

【6】要求図の課題

(1)参考にできる書籍がとても少ない。
まともに使えそうな本は「システムズモデリング言語SysML」ぐらいしかない。

「実践SysML―その場で使えるシステムモデリング」も読みやすかった。

ネット上の情報も少ない。
まだ試行錯誤している途中みたい。

(2)要求図を書く場合、モデリングツールが必須。
僕はastah Professionalを使っているけれど、EnterpriseArchitectなど他にもツールがある。
ツールを使いこなすための習熟が必要。

(3)清水さんが提唱する派生開発プロセスXDDPの知識は必須だと思う。
要求図は書き方がいくらでもあるが、本当に使えるものにするには、それなりの習熟が必要。
XDDPは日本発の技法であり、日本の現場で実践例が結構あるので、適用する価値があると思う。

特に、要求の関連図であるUSDMはSysMLの要求図そのものだし、トレーサビリティマトリクスは要求の仕様化や追跡チェックで有効だ。
XDDPに関する書籍「要求を仕様化する技術・表現する技術 -仕様が書けていますか?」「「派生開発」を成功させるプロセス改善の技術と極意」があるので、参考にしやすい。

(4)ソフトウェアプロダクトラインにも適用できるか？
要求図は、プロダクトライン分析におけるフィーチャ図、可変性分析にも役立つらしい。
実際、要求図から設計モデル要素へ詳細化して、どの設計モデル要素を共通部品として作るか、という観点で整理すれば、プロダクトラインのコア資産を抽出できる。
但し、そのノウハウが公開されていない。

(5)要求図の適用分野が組込みシステムの方式設計に偏っている。
業務システムの方式設計にも使えるか？
多分使えると思うが、運用ノウハウがもっといる。