astah* チュートリアル...株式会社チェンジビジョン使用バージョン:astah*...

株式会社チェンジビジョン使用バージョン:astah* 6.0, 6.1

astah* チュートリアル [第 6 章要求を整理してみよう]

目次

要求を整理してみよう 2

SysML の概要 2

SysML とは 2

誕生の背景 2

SysML の概要 2

SysML での各図 2

astah*での要求周りの機能の利用 3

要求 3

テストケース 3

要求テーブル 3

導出、コピー、満足、検証、洗練、トレース 5

要求テーブルを使用しての要求モデリングしよう[組み込み系サンプル] 8

要求テーブルを使用しての要求モデリングしよう[WEB 系サンプル] 14

astah* チュートリアル第 6 章要求を整理してみよう

2 / 21

要求を整理してみよう

SYSML の概要

SYSML とは Systems Modeling Language の略で OMG（Object Management Group）によって策定されたハードウェアも含め

たシステム全体を記述するためのモデリング言語です。

誕生の背景特に組み込み分野でのハードウェアも含めたモデリングにおいて、従来のモデリング手法では問題点を抱えたまま

でした。特に、分析・設計において有効とされていた UML においても、仕様策定時には想定していなかった領域

での問題や仕様の曖昧さ、表現力の不足といった問題が指摘されるようになりました。また、UML はあくまでソフ

トウェアを分析・設計する表記法で、ハードウェアなどは対象外でした。UML の配置図など一部ハードウェアを表

現可能なものもありますが、ソフトウェアからの観点であり、ハードウェアそのものを表現できず、表現力の拡張

が望まれていました。それを打破するべく OMG により SysML が策定され今日に至り、最新の仕様書は 1.1 です。

(2009 年 10 月 29 日現在)

SYSML の概要 SysML は、図のように UML 2 を拡張した仕様になっていて、UML2 の全ての仕様を包含しているのではなく、

一部は SysML 独自の仕様となっています。

引用：OMG SysML1.1 仕様書 P7

http://www.omg.org/spec/SysML/1.1/changebar/PDF/

SYSML での各図 SysML 図類は、Figure 4.4 に示されます。

ピンクの点線で囲まれた要求図(Requirement Diagram),パラメトリック図(Parametric Diagram)が新規図で、太枠の

アクティビティ図が UML2 の拡張、太枠で文字が緑のブロック定義図(Block Definition Diagram)は UML2 のクラス

図の拡張の新規図、内部ブロック図(Internal Block Diagram) は UML2 の合成構造図の拡張の新規図です。


3 / 21



ASTAH*での要求周りの機能の利用

astah* professional では SysML の要求に関連した部分をソフトウェア開発の現場で汎用的に使用できるよう実現

しました。要求およびテストケースの階層・派生関係の設定、要求テーブルを用いた管理を容易にし、工程間のギ

ャップを減らします。

要求

使用できるエディション： astah* professional

システムの要求を記述するモデルです。名前、ID、テキスト等を設定でき、階層をツリーとして表現します。また、

導出、コピー、満足、検証、洗練、トレースといった派生関係を設定できます。その他の機能として、要求からユ

ースケースやマインドマップのトピックへの変換もサポートしています。

テストケース


システムのテストケースを記述するモデルです。名前、ID、定義等を設定でき、階層をツリーとして表現します。

また、満足、検証、洗練といったテストケースからの派生関係も設定可能です。テストケースからユースケースや

マインドマップのトピックへの変換もサポートしています。

要求テーブル


デモ動画：http://astah.change-vision.com/ja/movie.html#requirement-table

表形式で要求を編集したり、階層を指定して要求の ID、名前、テキストを表示したりできます。Excel への入出力

も可能です。


4 / 21

要求図


デモ動画：http://astah.change-vision.com/ja/movie.html#requirement-diagram

どんな要求があるかと、要求間の関係を定義する図です。


5 / 21

導出、コピー、満足、検証、洗練、トレース


導出<<DERIVEREQT>>



導出は、クライアント要求がサプライヤ要求に導き出される二つの要求間の依存関係です。

例えば、システム要求はビジネス要求に由来するかもしれません。あるいは、より低レベルの要求はシステム要求

に由来するかもしれません。他の依存関係と同様に、矢方向はクライアント要求からそれが導き出されるサプライ

ヤ要求まで指します。

astah*では、要求から要求に引くことができます。

要求のプロパティビューの”依存元”タブ、”依存先” タブ、もしくは、要求テーブルの要求のポップアップメニュー

”依存元の設定”、”依存先の設定”から追加できます。

A DeriveReqt relationship is a dependency between two requirements in which a client requirement can be derived

from the supplier requirement. For example, a system requirement may be derived from a business need, or

lower-level requirements may be derived from a system requirement. As with other dependencies, the arrow

direction points from the derived (client) requirement to the (supplier) requirement from which it is derived.



コピー<<COPY>>



コピーは、クライアント要求とサプライヤ要求間の依存関係で、クライアント要求のテキストがサプライヤ要求の

読み取りコピーであることを示しています。異なる状況で再利用する目的で、クライアント/サプライヤ関係を維持

します。クライアント要求は、コピーの矢印の先のサプライヤ要求の読み取り専用コピーです。





6 / 21

A Copy relationship is a dependency between a supplier requirement and a client requirement that specifies that the

text of the client requirement is a read-only copy of the text of the supplier requirement. A Copy dependency created

between two requirements maintains a master/slave relationship between the two elements for the purpose of

requirements re-use in different contexts. When a Copy dependency exists between two requirements, the

requirement text of the client requirement is a read-only copy of the requirement text of the requirement at the

supplier end of the dependency.



満足<<SATISFY>>



満足は、要求とその要求を満足させるモデル間の依存関係です。

他の依存関係と同様に、矢方向はクライアントモデルからそれを満たすサプライヤ要求まで指します。

astah*では、モデル※から要求に引くことができます。

モデル※とは以下を示します。

パッケージ、モデル、サブシステム、クラス、関連クラス、インターフェース、エンティティ、

コントロール、バウンダリ、アクター、ユースケース、コンポーネント、成果物、ノード、要求、

テストケース

要求のプロパティビューの”依存元”タブ、”依存先” タブ、テストケースのプロパティビューの”依存先” タブ、もし

くは、要求テーブルの要求のポップアップメニュー”依存元の設定”、”依存先の設定”から追加できます。

A Satisfy relationship is a dependency between a requirement and a model element that fulfills the requirement. As

with other dependencies, the arrow direction points from the satisfying (client) model element to the (supplier)

requirement that is satisfied.




7 / 21

検証<<VERIFY>>



検証は、要求とシステムが要求を満たすかどうかを検証するテストケースの依存関係です。他の依存関係と同様に、

矢方向は、クライアントテストケースからそれが導き出されるサプライヤ要求まで指します。

astah*では、テストケースから要求に引くことができます。



A Verify relationship is a dependency between a requirement and a test case or other model element that can

determine whether a system fulfills the requirement. As with other dependencies, the arrow direction points from the

(client) element to the (supplier) requirement.



洗練<<REFINE>>



洗練とは、モデルから要求に詳細化する依存関係です。他の依存関係と同様に、矢方向は、クライアントモデルか

らサプライヤ要求の方向を示します。

astah*では、モデル※から要求に引くことができます。

モデル※とは以下を示します。

パッケージ、モデル、サブシステム、クラス、関連クラス、インターフェース、エンティティ、

コントロール、バウンダリ、アクター、ユースケース、コンポーネント、成果物、ノード、要求、

テストケース




8 / 21

トレース<<TRACE>>



トレースとは、要求間の抽象的なつながりを表す依存関係です。




要求図と要求テーブルを使用して要求をモデリングしよう [組み込み系サンプル ]


以下は、OMG から提供されている SysML1.1 仕様書の要求図のサンプルです。

[組み込み系サンプル]で自動車の舗道摩擦まわりの要求を表したものです。



これと同等のモデルを書いてみます。要求のモデルや、要求図と要求テーブルのそれぞれで表現できますが、ここ

ではまず要求図を作成してみましょう。まず、図メニューから“要求図”を選択し、要求図を作成します。


9 / 21

エディタのボタンから“要求”作成ボタンをクリックし、図上に要求を作成します。要求名、要求の ID を入力しま

す。Text の項目には、その要求の説明を入力します。（astah*では、ID と Text の順序が例と異なります）

同様に他の要求も作成します。次に、要求間の関係を作成してみましょう。

要求間の導出関係とネスト関係を、それぞれツールバーのボタンを押して作成します。


10 / 21

ネスト関係については、作成時に親子関係が変わることを構造ツリーで確認できると思います。

ここまでで、例の要求図が完成しました。図だと要求間の関係を一目で把握できますね。


11 / 21

これらの要求と分析・設計モデルとの関係も定義してみましょう。具体的な例ではないですが、もし UsecaseA が

Pavement friction を満足する関係があり、TestCaseA が、Pavement friction を検証する関係である場合は、次のよ

うに図上で表現することもできます。ユースケースやクラスを構造ツリーから図にドラッグアンドドロップして配

置しています。

また、下の図のようにパッケージを指定して、要求テーブルを作成することもできます。


12 / 21

要求図を書く時に作成されたモデルから、次のような要求テーブルが作成されます。要求テーブルは、ネームスペ

ース毎に一つ作成可能で、その配下に存在する要求が自動的にリストに表示されるようになっています。

要求図と要求テーブルでは同一のモデルが利用されますので、一方で変更すればもう一方にも反映されます。また、

それぞれのポップアップメニューから、図やテーブルに相互にジャンプ可能になっています。

さて、同等のモデルを始めから要求テーブルを使って作成する場合を見てみましょう。次のような手順です。

まず、図メニューから”要求テーブル”を選択し、要求テーブルを作成します。

要求テーブルを右クリックしてポップアップメニューから”要求の追加”で

Adhesion utilization, Vehicle conditions, Test and procedure conditions, Pavement friction, ASTM R1337-90

の要求を追加していきます。


13 / 21

要求テーブルからは ID、名前、テキストの編集の他に、要求を選択し、以下の操作も可能です。

・子要求の追加

・兄弟要求の追加

・依存元の設定

・ユースケースへの変換

Vehicle conditions は Adhesion utilization とネスト関係がありますので、ポップアップメニューから”子要求の追加”

から追加します。Test and procedure conditions も同様です。

また、Test and procedure conditions から Pavement friction、Pavement friction から ASTM R1337-90 へ導出

<<deriveRept>>でつながっていますので、ポップアップメニューから”依存先の設定”から追加します。(“依存元の

設定”でも可能です。) ちなみに、導出<<deriveRept>>とは、要件から別の要件が導き出される関係のことです。


14 / 21

以下が作成したモデルです。

要求テーブルと要求図の両方を使って、それぞれの利点を活かすといいですね。

要求図と要求テーブルを使用して要求をモデリングしよう [WEB 系サンプル ]


ここでは、ストーリー仕立てで要求モデリングしていきたいと思います。

プロジェクトマネージャーである A さんは、営業 X さんと取引先に新案件の打ち合わせに行きました。

A さんは、いつものように PC を起動しマインドマップでヒアリングを始めました。

「登場人物」

プロジェクトマネージャー A さん

営業 X さん

開発リーダー B さん

要求開発リーダー R さん


15 / 21

どうやらいつもの WEB アプリケーションのようです。顧客はいつもおざなりになりがちな非機能要件周り、レス

ポンスやセキュリティ、障害対策について注意してほしいとのことでした。機能要件については、ログイン程度簡

単なものにとどまり、打ち合わせも無事終了しました。作成したマインドマップは以下です。

プロジェクトマネージャーA さんは、会社に戻り、さっそく以下のようなユースケースを書いてみました。


16 / 21

その後、プロジェクトマネージャーA さんはヒアリングした要求を機能要件、非機能要件もまとめて、要求の機能

をまとめてみることにしました。頭のなかに浮かんだのは以下のモデルです。

プロジェクトマネージャーA さんは要求テーブルからネスト関係を考慮しながら、要求を入力していきました。


17 / 21

次に要求間の依存関係を設定していきます。

先ほど軽く、ユースケース分析をしていました。ユースケースの"ログインする"の詳細は、要求の"ログインボタン

"にあたります。このように機能要件のユースケースから機能要件の要求に対して詳細化するという意味合いの洗練

<<refine>>を引くことができます。このように既存の UML のダイアグラムと関連し合っているため、この様に可

視化することにより、仕様の共有化に一役買うことにもなるでしょう。操作方法は、要求テーブル上で依存を張り

たい要求を選択し、ポップアップメニューから”依存先の設定”から追加します。(“依存元の設定”でも可能です。)

また、プロジェクトマネージャーA さんは顧客からログイン時のレスポンスやセキュリティの要求に注意するよう

に言われていたのを思い出しました。非機能要件を満たせないと顧客から信頼をなくしかねません。

機能要件の要求"ログインボタン"は、非機能要件の要求"レスポンス要求"、"セキュリティ要求"を導き出しています。

同様に機能要件の要求"正常遷移"から機能要件の要求" XX 画面要求"へも同様です。

このように、導出<<deriveRept>>とは、要件から別の要件が導き出される関係のことを表します。

操作方法は、要求テーブル上で依存を張りたい要求を選択し、ポップアップメニューから”依存先の設定”から追加

します。(“依存元の設定”でも可能です。)

次にテストケースについて考えています。

テストケースは、astah*内でもモデルとして生成できます。実際のそのテストケースの内容ですが、自動テストに

するか EXCEL でテスト仕様書を書くのか現段階では決まっていませんが、ここは顧客・メンバと話し合うため、

成果物は何にするかは、懸案事項として置いておくとします。


18 / 21

ただ、自動テストならソースや結果のドキュメント、テスト仕様書なら、ドキュメントへ、シナリオならフローチ

ャートやアクティビティ図へのハイパーリンクを張るのか、またはテストケースの定義に書くのかなど、事前にプ

ロジェクトで話し合ってよりよい合意をとったほうがよさそうです。

プロジェクトマネージャーA さんは、この点をメモしておき、開発リーダーB さんにテストケースの設計を指示し

ました。開発リーダーB さんは、まずネスト関係に注意しながら、テストケースを設計し始めました。

また、テストケースと要求間では、検証<<verify>>といって要求を満たすことをテストケースで検証するための依

存関係をはることができます。開発リーダーB さんは、プロジェクトマネージャーA さんが作ったモデルを自分の

モデルにマージし、検証関係を張っていきました。出来上がったモデルは、以下でした。


19 / 21

その後は、プロジェクトマネージャーA さんは要求開発リーダーの R さんに要求の詳細化を依頼しました。

要求開発リーダーR さんは、自身を中心に、要求開発グループで展開させるために、要求テーブルを EXCEL で出

力してチーム内の共有を開始しました。[ツール]-[要求]-[要求テーブルを Excel ファイルに出力]で出力できます。


20 / 21

出力ダイアログが表示されます。

出力された Excel は以下の通りです。

要求テーブルを Excel 形式で受け取った要求開発チームは、要求の階層化と要求テーブルの書式やルール決めを行

い、要求をつめていきました。詳細化された Excel ファイルをプロジェクトマネージャーA さんが持つプロジェク

トファイルに、Excel 入力の機能を使用し、反映しました。

[ツール]-[要求]-[要求テーブルを Excel ファイルに入力]で行います。


21 / 21

要求テーブルの入力時には、まず ID が同じ要求を同一の要求とし、次に名前が等しい要求を同一の要求として更新

します。

要求が固まってきたところで、プロジェクトマネージャーA さんは、要求開発リーダーR さんとレビューを繰り返

し、要求を具体化していきました。その後、明確化された要求を元に開発リーダーB さん中心に実装とテストケー

スを作成していきました。

[要求の機能のポイント]

SysML では主に組み込み系を想定ターゲットとしていますが、それ以外のソフトウェア分野にも汎用的に利用

できるものです。忘れられがちな非機能要件について初期の段階から強く意識できることなども要求モデリン

グの魅力の一つです。

また、astah で要求モデルを扱う利点は、要求間の関係を図示しやすいことと、要求とモデルの間の関係につ

いても管理しやすくなることです。

astah* チュートリアル...株式会社チェンジビジョン使用バージョン:astah*...

Documents

Transcript of astah* チュートリアル...株式会社チェンジビジョン使用バージョン:astah*...

astah* チュートリアル...株式会社チェンジビジョン 使用バージョン:astah*...

Documents

Transcript of astah* チュートリアル...株式会社チェンジビジョン 使用バージョン:astah*...

astah* チュートリアル...株式会社チェンジビジョン使用バージョン:astah*...

Transcript of astah* チュートリアル...株式会社チェンジビジョン使用バージョン:astah*...