システムエンジニアのためのモデリング心得 トップ10: その7 要求モデルで、高くつく欠陥を早期に回避できる

Bruce Douglassが、より完全でより的確でより精密でより正確な要求をどのように作成するかについて説明します。

Bruce Douglass (Bruce.Douglass@us.ibm.com), Rationalチーフ・エバンジェリスト, システムズ・エンジニアリング, IBM

author photo組込みソフトウェア方法論者。トライアスリート。システムズエンジニア。UMLおよびSysML仕様開発コントリビューター。作家。黒帯。神経科学者。クラッシックギター奏者。高校中退。Bruce Powel DouglassはUSD(サウスダコタ大学)医学部より神経サイバネティックスの博士号を取得し、35年以上にわたる様々なハードリアルタイム環境のセーフティ・クリティカルなリアルタイム・アプリケーションの開発の経験を持っています。彼は5,700ページにおよぶ多くの技術書籍の著者で、Real-Time UML, Real-Time UML Workshop for Embedded Systems, Real-Time Design Patterns, Doing Hard Time, Real-Time Agility, Design Patterns for Embedded Systems in Cといった本を書いています。彼は、IBM Rationalのチーフ・エバンジェリストであり、システムズ領域のソート・リーダーでもあります。BruceはIBMの全世界の顧客に対してコンサルテーションや助言を提供しています。Bruceをツイッターでフォローするには@BruceDouglassです。



2013年 12月 06日

要求仕様をうまく作り上げるのは、見かけ以上に大変な作業です。実際、非常に大変で、35年以上やっていますが、私は未だに欠陥のない要求というのを見たことがありません。要求仕様は、「することになる(shall)」を使った文章からなる文書であるのが普通です。これには幾つもの根本的な問題があります 。

まず、文章というのは、表現力がすばらしく豊かであるのですが、また曖昧であり、いろいろな解釈が可能なものです。自然言語を用いて精密にというのはとても難しいことです。そう考えると、詩には自然言語がうまく合っており、技術仕様にはあまりうまく合っていないと言えます。

注 :実際、私はUML状態マシンを使って詩を書いたことがありますが、まあこれは今一つだなとわかりました。

更に、その仕様が完全で漏れがないことを確証するのも困難です。システムが稼動する全てのケース・状況・環境を網羅できていますか?性能やその他のクオリティ・オブ・サービスに関する要求についてはどうでしょうか?故障や例外事象の条件については?

非常にたくさんの要求の一貫性を証明することはもっと大変です。数百ページにわたる仕様での一貫性というのはとても困難な問題です。

では、このような仕様を、設計や開発を行うエンジニアリング・チームに手渡す前にどのように検証するのでしょうか。たいていの場合は、やらない(その結果プロジェクトの最終局面にて発覚する問題への対応での長時間かかるシステム検証や妥当性確認作業に陥る)か、もしくは、気の遠くなるような時間のかかるピア・レビューをするかでしょう。

問題は、文章としての要求は本質的に検証可能ではないという点です。では解決策はというと、モデルとして要求を作成することです。

簡単なユースケースとして、交通信号制御システムの「夜間閑散モード」を考えてみましょう。優先道路側の信号機は黄色点滅し、二次的道路側の信号機は赤色点滅します。図1は、このような簡単な要求群がどのように状態マシンとして表現され、取り巻く環境中のアクターである優先道路側の歩行者(primary road pedestrians – PP)、二次的道路側の歩行者(secondary road pedestrians – SP)、優先道路を直進する車(primary through traffic vehicles – PV)、優先道路から方向を変える車(primary turn traffic vehicles – PtV)、 二次的道路を直進する車(secondary through traffic vehicles - SV)、二次的道路から方向を変える車(secondary turn traffic vehicles – StV)にメッセージを送る様子を表しています。

図 1. 「夜間閑散モード」のための簡単なユースケース状態マシン
「夜間閑散モード」のための簡単なユースケース状態マシン

このモデルの主要な利点は、実行可能であるということです。モデルは、異なる状況・文脈・設定値・イベントの発生順序といったことを探っていくのに使えるのです。もちろん、図1の状態マシンは、ほとんど自明な例ではあります。しかし、もう少しだけ複雑な要求集合として、この同じ交通信号制御システムの「固定サイクルモード」を考えてみましょう。

  • ユースケース : 固定サイクルモード
    • 交差点には優先道路と二次的道路がある。
    • それぞれの道路には直進レーンとターン・レーンがある。
    • 直進レーンは、その道路の対面する両方向に対して同時にアクティブになり進行指示をする。
    • ターン・レーンは、その道路の対面する両方向に対して同時にアクティブになり進行指示をする。
    • 直進レーンは、外部からの何らかのきっかけ(stimulus)がなくとも、赤-緑-黄-赤のサイクルを通して進行指示をする。ある道路が通行を許可している間は、他の信号機は赤(そして歩行不可)の状態を維持する。
    • ターン・レーン は、ターン・レーンに車が到達することでアクティブになり進行指示を開始する。それ以外の状況では赤の状態に留まる。
      • 直進レーンが通常にアクティブになるはずの次のタイミングにおいて、まずターン・レーンが先に動作し、直進レーンはターンのサイクルが完了するまで赤の状態に留まる。
      • 対面する両方のターン・レーンは、赤-緑-黄-赤と進む。その後、直進レーンが緑になることを許される。
      • 一旦ターン・レーンが「処理される」と、再度アクティブになるには次の車の到達を待つ必要がある。
    • 歩行者信号機 は、歩行者が到着してボタンを押さない限りは「歩行不可」の状態に留まる。
      • 直進レーンが緑になる次のタイミングにおいて、歩行者ラインのサイクルが動く。
        • DON'T WALK (歩行不可)
        • WALK (歩行可)
        • FLASHING DON'T WALK (歩行不可)の点滅
        • DON'T WALK (歩行不可)
      • 直進レーンは、歩行者信号機が歩行不可になった後にのみ黄へと進むこととする。

これは、ものすごく複雑なユースケースというわけではありませんが、直進レーンとターン・レーンと歩行者の異なる組合せを扱う多くの異なるシナリオが構成可能です。図2に示すこのユースケースの状態マシンは、それほど自明なものでもなく、簡単に把握できるものではありません。そして、興味深い状況やシナリオが全て説明されるべきものです。このモデルを実行することで、イベントや条件や設定値の異なる組合せを調べ上げて、システムが常時正しく動作することを確証することができます。

図 2. 「固定サイクルモード」のユースケース状態マシン
「固定サイクルモード」のユースケース状態マシン

このようなユースケースによる機能分析の自然な帰結として、欠けている要求が明らかになります。それらは文章としての仕様に追加され、モデル中の仕様要素と紐付けされます。その結果、より完全で、より的確で、より精密で、より正確な、つまり、より良い要求になるのです。

訳者について

三ツ井欽一は、東京ソフトウェア開発研究所に所属するラショナル・システムズ開発担当マネージャーです。この記事の著者のBruce Douglassを含む、ラショナル・グローバル・チームのメンバーと共に、ラショナル・ソリューションの普及とお客様へ提供する価値の向上に日々取り組んでいます。

参考文献

学ぶために

製品や技術を入手するために

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Rational
ArticleID=954834
ArticleTitle=システムエンジニアのためのモデリング心得 トップ10: その7 要求モデルで、高くつく欠陥を早期に回避できる
publish-date=12062013