NTTデータ
技術開発本部
副本部長
山本修一郎
要求工学から見たSSM
また要求工学からSSMのステージを見ると次のようになると思われる。
ステージ1、2では、問題状況を抽出して表現しているので問題定義に相当する。ステージ3、4では、基本定義と概念モデルによって問題状況を解決するシステムを定義しているので要求定義に相当する。ステージ5では概念モデルにより問題状況を評価しているので要求確認工程に相当する。構造化分析手法をSSMに対応付ける場合は、基本定義をコンテクスト図、概念モデルをデータフロー図で表現できるだろう。UMLの場合は、基本定義をユースケース図、概念モデルをアクティビティ図で表現できるだろう。ステージ6、7では、改革案の提示・実行により新たに発生する問題を監視するので要求管理に相当する。
システム分析の留意点
SSMを用いてシステム分析を進める上での留意点を基本定義と概念モデルごとに表2に示す。表2では留意点を、分析範囲、モデルの表現、モデル間の一貫性、分析プロセスに分けて整理した。
◆分析範囲の確認
基本定義では、活動から構成されるシステムとは何かを定義していることに注意する。また基本定義の変換Tに相当する動詞の目的語(C)が受益者になっていることを確認する。
概念モデルでは、基本定義に対して正しい活動であることと達成可能な活動であることを確認する。
◆表現の確認
基本定義の表現は単純化することが望ましい。そのためには一つの基本定義に複数の視点Wや複数の変換Tを含めないようにする必要がある。また基本定義に含まれる用語に対する概念モデルの活動が記述できない場合、その用語を削除する。
概念モデルの活動に対する名称が動詞で表現されていることを確認する。また制御活動の目的が記述されていることを確認することにより、何が制御されるのかを明確にしておく必要がある。
◆一貫性の確認
基本定義では、問題とする現実世界の状況の本質に対応した記述になっていることを確認する。基本定義で一般的な記述をしたのでは意味のある概念モデルを導くことはできない。逆に基本定義の内容を過度に限定してしまうと、システムの境界の範囲を逸脱した活動が概念モデルの中に含まれる可能性があるので、基本定義がシステムの権限範囲を逸脱しないように注意する。基本定義をCATWOE分析した結果、基本定義に修正が必要であることが判明した場合、基本定義を修正した上で、概念モデルを作成する。そうしないと基本定義と概念モデルの追跡性が失われてしまうからである。図3にSSMで作成する生産物間の関係をまとめる。
図3 SSM分析の生産物の関係
概念モデルの作成では、基本定義の構造に対応した活動が存在することが必要である。基本定義の構造には次の2つの構造があるとされている[1][2]。
- 【構造1】
- ZによりXをYに変換する。
このときZを実施する活動が概念モデルに必要である。またどれだけうまくYに変換できるかを監視する活動も必要になる。
- 【構造2】
- Yを達成するためにZによりXを実行する。
このときZとXを実施する活動が概念モデルに必要である。またどれだけうまくXを実行できたか、どれけうまくYを達成できたかを監視する活動も必要になる。
基本定義の内容に対して、概念モデルの活動が十分であり、抜けがないことを確認する。また概念モデルの活動が基本定義が想定するシステムの範囲から外れていないことを確認する。
◆分析プロセス
基本定義の作成は逐次的なプロセスになるのではなく、CATWOE分析と概念モデルの作成により反復的な改善が必要になる。また異なる視点に基づいて一つのシステムに対する複数の基本定義を並行して検討する場合もある。
概念モデルの作成では、活動を過度に詳細化しやすい傾向があるので、基本定義に対して必要最小限の活動をまず守備的に作成することにより、問題状況と比較することで迅速にモデルを改善していくことが重要である。そうしないと基本定義や概念モデルに対する問題状況からのフィードバックが遅れてしまうだけでなく、改訂作業が増加することになる。
今回はチェックランドのソフトシステム方法論の具体的な7つのステージを紹介した。また基本定義、CATWOE分析、概念モデルついて注意すべきポイントや要求工学との関係をまとめた。
次回は情報システムへのSSMの適用法について紹介する予定である。
参考文献
- [1] ウィルソン著, 根来龍之監訳「システム仕様の分析学」-ソフトシステム方法論-共立出版(1996)
- [2] 第20回 要求工学(20)~ソフトシステム方法論 再考(その1)~,http://www.bcm.co.jp/site/youkyu/youkyu20.html
- [3] 第5回 要求工学(5)~要求抽出~
,http://www.bcm.co.jp/site/2005/2005-03/
05-youkyuu-kougaku-03/05-youkyuu-kougaku-03.htm
- 60:要求とアーキテクチャ
- 61:要求と保守・運用
- 62:オープンソースソフトウェアと要求
- 63:要求工学のオープンな演習の試み
- 64:Web2.0と要求管理
- 65:ソフト製品開発の要求コミュニケーション
- 66:フィードバック型V字モデル
- 67:日本の要求定義の現状と要求工学への期待
- 68:活動理論と要求
- 69:ビジネスゴールと要求
- 緊急:今、なぜ第三者検証が必要か
- 71:BABOK2.0の知識構成
- 72:比較要求モデル論
- 73:第18回要求工学国際会議
- 74:クラウド時代の要求
- 75:運用要求定義
- 76:非機能要求とアーキテクチャ
- 77:バランス・スコアカードの本質
- 78:ゴール指向で考える競争戦略ストーリー
- 79:要求変化
- 80:物語指向要求記述
- 81:要求テンプレート
- 82:移行要求
- 83:要求抽出コミュニケーション
- 84:要求の構造化
- 85:アーキテクチャ設計のための要求定義
- 86:BABOKとREBOK
- 87:要求文の曖昧さの摘出法
- 88:システムとソフトウェアの保証ケースの動向
- 89:保証ケースのためのリスク分析手法
- 90:サービス保証ケース手法
- 91:保証ケースのレビュ手法
- 92:要求工学手法の再利用
- 93:SysML要求図をGSNと比較する
- 94:保証ケース作成上の落とし穴
- 95:ISO 26262に基づく安全性ケースの適用事例
- 96:大規模複雑なITシステムの要求
- 97:要求の創造
- 98:アーキテクチャと要求
- 99:保証ケース議論分解パターン
- 100:保証ケースの議論分解パターン[応用編]
- 101:要求発展型開発プロセスの事例
- 102:参照モデルに対する保証ケース
- 103:参SEMATの概要
- 104:参SEMATの活用
- 105:SEMATと保証ケース
- 106:Assure 2013の概要
- 107:要求の完全性
- 108:要求に基づくテストの十分性
- 109:システムの安全検証知識体系
- 110:機能要求の分類
- 111:IREB
- 112:IREB要求の抽出・確認・管理
- 113:IREB要求の文書化
- 114:安全要求の分析
- 115:Archimate 2.0のゴール指向要求
- 116:ゴール指向要求モデルの保証手法
- 117:要求テンプレートに基づく要求の作成手法
- 118:ビジネスゴールのテンプレート
- 119:持続可能性要求
- 120:操作性要求
- 121:安全性証跡の追跡性
- 122:要求仕様の保証性
- 123:システミグラムとドメインクラス図
- 124:機能的操作特性
- 125:セキュリティ要求管理
- 126:ソフトウェアプロダクトライン要求
- 127:システミグラムと安全分析
- 128:ITモダナイゼーションとITイノベーションにおける要求合意
- 129:ビジネスモデルに基づく要求
- 130:ビジネスゴール構造化記法
- 131:保証ケース導入上の課題
- 132:要求のまとめ方
- 133:要求整理学
- 134:要求分析手法の適切性
- 135:CROS法の適用例
- 136:保証ケース作成支援ツールの概要