201404のエントリ

  山本 修一郎

 

開発文書品質の研究というと耳新しく聞こえますが,開発文書の構文や構造,要求仕様テンプレートなど,研究の役に立ちそうな素材はこれまでに研究されてきた分野の中に転がっています.この連載コラム「山修の開発文書品質入門」では,開発文書に携わる皆さんに役立ちそうなそれらの知識を分かりやすく解説します.

バック・ナンバ

 

開発文書の作成のために,文書のテンプレートを用意している組織や開発チームもあるかと思います.ルールや形式を決めて,それに当てはまるように記述することは,読み手の解釈の範囲を限定しますから,複数の解釈を避けることにつながります.

本稿では,2つの国際標準機関が取り決めている要求文のテンプレートの例を紹介します.

 

■IREBが規定する要求文書化の項目

国際要求工学委員会(International Requirements Engineering Board, IREB)[1]が要求工学専門家を認定するための基礎レベルのシラバスを提供しています.このシラバスでは,要求文書に関連する教育単位(EU)として,次の項目を定義しています.

  • 要求文書化(EU4)
  • 自然言語による要求文書化(EU5)
  • モデルに基づく要求文書化(EU6)

 

とくに,「自然言語による要求文書化(EU5)」の基礎レベルのシラバスで述べられている要求テンプレートを解説します.

 

■要求の義務の強さを示すための要求テンプレート

要求の定式化における言語効果を削減するために,容易に学習でき適用できる方法が要求テンプレートです.高品質な要求を作成する上で,要求テンプレートが要求執筆者を効果的に支援します.IREBは,要求テンプレートによって要求を5段階に定式化しています.

  • 法的な義務を決定する
  • 要求の中核を決定する
  • システムの活動を特徴づける
  • オブジェクトを挿入する
  • 論理条件と時制条件を決定する

 

そして,要求文では,「shall」「should」「will」を用いて、義務を定義できます.義務が変化した場合,要求も変化します.

 

義務の強さは,shall  >  should  >  will   の順です.

shall :     (絶対義務)   絶対に満たすべき要求であることを表す

should:  (義務)       絶対ではないが,高い確率で満たすべき要求であることを表す

will:    (可能義務)   できれば,満たすべき要求であることを表す

 

日本語で,shallshouldの区別は難しいと言えます.しかし,日本語でも,要求の義務の強さによって,「shall」「should」「will」に対応して,次のように書き分けることを意識してみてはいかがでしょうか.

(絶対義務)    システムは, 処理を 絶対に行う必要がある

(義務)            システムは, 処理を 行う必要がある

(可能義務)    システムは, 処理を 可能であれば行う

 

 

また,日本語では,英語のように使用する用語の違いで意味書き分けることが,難しい場合もあります.副詞の有無や文末だけの記述の違いで,要求の違いを明確に示すには限界もあるかもしれません.そういったときに,属性を付与することも1つの方法と言えます.たとえば,上記の [絶対義務], [義務], [可能義務] などを属性として,各要求に付与することを決めれば,要求文に補助情報を付けて,より明確化することになります.属性の例としては,他に,[必須要求](なくてはならないの意), [可能要求](あったほうがよいの意), [期待要求](なくてもよいの意)なども挙げられます.

こういった属性の記述は,自由度の高い自然言語の表現にある制約を付けて,意味を限定しようとするものであり,要求表現テンプレートの記述項目と言えます.

 

このように要求のテンプレートを決めることは,その使用を強制するわけではありません.テンプレートに合せて記述する訓練の機会を得ることによって,要求テンプレートを補助的なツールとして活用できるのではないでしょうか.

 

■文の構成要素を規定する要求構文

ISO/IEC/IEEE 29148:2011内「5.2.4 Requirements construct」では,表1に示すように3種類の要求構文の型を例示しています.この要求構文も要求テンプレートの例です.なお,日本語構文に合わせるために,助詞を補うとともに,語順を入れ替えています.

 

(構文の型1) [条件] [主体] [対象][制約] [活動]する必要がある.

例:信号x を受信したとき,   [条件]

  システムが,                   [主体]

  信号 xの受信ビットを       [対象]

  2秒以内で                   [制約]

  設定する                        [活動]

  必要がある

 

(構文の型2) [条件] [活動 または 制約] [値]である必要がある.

例:海の状態が 1のとき                                        [条件]

  レーダーシステムが目標を検知すべき範囲は,  [活動または制約]

  100 nautical マイルである                                  []

    .必要がある.

 

(構文の型3) [主体][値条件][活動] する必要がある.

例:請求書システム が                  [主体]

  昇順で,                         [値条件]

  支払いが保留中の顧客請求書を表示する  [活動]

  必要がある.

 

■要求テンプレートを使った要求文の例

たとえば,IREBによる義務の強さと,ISO/IEC/IEEE 29148:2011による要求構文を適用して,要求文を書いてみます.

 

(絶対義務) 

例:[主体] 交差点の信号機システムは,

  [値条件]  一方の信号機を赤に切り替えてから,

  [活動]        他方を青に切り替えることが,

                         絶対に必要である

 

(義務) 

例:[主体] 交差点の信号機システムは,

  [値条件] 一定時間,

  [活動]         両方の信号機を赤にすることが,

                        必要である

 

(可能義務) 

例:[条件]   両方の信号機が赤である時の一定時間は,

    [値]     3秒間とする

 (注)上記は、信号機システムの要求の一部のみを例示しています.要求として完全な記述ではありません.

 

このように,要求テンプレートを利用して,自然言語の記述の中で定型化できる箇所を整理し記述することは,読み手に対して要求を明確に伝える助けとなります.それ以上に,要求執筆者にとって,要求を整理し定義する際の1つの手立てとなります.


参考文献
[1] The home of Requirements Engineering, http://www.ireb.org/
[2] IREB Certified Professinal for Requirements Engineering - Foundation Level-Version 2.1 Dec.20th 2012
[3] 山本修一郎,IREBの紹介,http://www.bcm.co.jp/site/youkyu/youkyu111.html
[4] ISO/IEC/IEEE 29148:2011,Systems and software engineering-Life cycle processes-Requirements engineering.

 

  • コメント (0)
  • トラックバック (0)
  • 閲覧 (4843)

サイト内検索

カテゴリ一覧

ログイン

ユーザ名:

パスワード:

次回からIDの入力を省略



パスワード紛失