山修の開発文書品質入門(10) ―― 要求テンプレートの構成

山修の開発文書品質入門(10) ―― 要求テンプレートの構成

カテゴリ : 
基礎知識
 2022-5-31 17:49

  山本 修一郎

この連載コラム「山修の開発文書品質入門」では,開発文書に携わる皆さんに役立ちそうな開発文書の品質につながる知識を分かりやすく解説します.

バック・ナンバ

 

本ブログ4では,国際標準に基づく要求文のテンプレートの例を紹介した.

今回は,MazoとJaramillo[1]が,新たに提案しているシステム要求仕様の構文を紹介する.彼らは構成要素を8種類に分類している(表1)

表1 要求仕様テンプレートの構成

構成要素 説明
1 条件(Conditionals) この条件が成立するとき,システムが機能要求を実行する
2 システム(System) 機能の実行主体となるシステムおよびサブシステム
3 義務(Obligation) 要求の優先度shall,should,could
4 活動(Activity) システムの機能(動詞)
5 対象(Objects) システムの機能が作用する対象(名詞)
6 評価基準(Criterion) 機能要求が満たすべき条件
7 活動条件 システムの活動が満たすべき条件
8 対象条件 活動対象が満たすべき条件

 

これらの構成要素からなる要求仕様文に対する要求構文は次のようになる.

<条件>が成立したとき,<システム>が,<対象条件>を満たす<対象>を<評価基準>を満たすように,<義務><活動>する
 

ここで,日本語の動詞にはサ変活用があるので,義務の部分を日本語にするのは難しい.日本語では,<義務>部分に,「必ず,絶対,できれば」などを使うことになる.それよりは,義務部分を表す,必須◎,望ましい〇,省略可△などの識別子を要求文の属性とすることにより,要求の優先順位を区別する方が明確になると思われる. 

以下では,この分類に従って要求仕様テンプレートの記述例を説明する.

条件

例:加熱スイッチが押下されたら

システム

例:電気ポット制御システムが

活動

例:加熱信号を送信する

対象

例:ヒータに

評価条件

例:直ちに

評価条件によって,活動に対する性能や信頼性についての非機能要求を記述できる.

活動条件

例:沸騰していない限り

対象条件

例:水タンクが空でない限り

 

■要求テンプレートによる記述例

上述した要素例をまとめて,要求文を記述すると,次の通りである.

加熱スイッチが押下されたら,電気ポット制御システムが,水タンクが空でない限り,沸騰していない限り,直ちに,ヒータに加熱信号を送信する
 

 ただし,この例では,日本語として読みやすいように,要求構文の表現を改めている.このため,日本語の場合,語尾変化を考えて,要求構文を節の集まりで表現した方がいいと思われる.

【システム要求構文】

<条件節>,<システム>が,<対象条件節><評価基準節><対象>に<活動節>
 
 

 ■まとめ

本稿では,システムの要求仕様文についてMazoとJaramilloの構文テンプレートを日本語化した記述例を紹介した.

要求テンプレートには,システム要求仕様を対象とするテンプレートだけでなく,ユーザ要求を対象とするテンプレート[2][3]がある.ユーザ要求テンプレートではユーザの活動を記述する.ユーザ要求テンプレートではシステム機能を直接記述していないので,システム機能を抽出する必要がある.

システム要求仕様を対象とするテンプレートには,EARS(Easy Approach to Requirements Syntax)がある[4].また,ISO/IEC/IEEE 29148にもソフトウェア要求に対するテンプレートの記述例がある[5].EARSやISO/IEC/IEEE 29148のシステム要求仕様テンプレートの構成要素を含んでいるので,現在のところ,MazoとJaramilloの構文テンプレートの表現能力が最も高い.

 
  

参考文献

[1]Raul Mazo, Carlos Andrés Jaramillo, Paola Vallejo, Jhon Medina. Towards a new template for the specification of requirements in semi-structured natural language. Journal of Software Engineering, Research and Development, Brazilian Computer Society, 2020, 8, pp.3. 10.5753/jserd.2020.473. hal-02502411

[2] Davies, Rachel. Format for expressing user stories. 2001.

[3] Wiegers, Karl, and Joy Beatty. Software Requirements Third Edition. Microsoft Press, 2013.

[4] Mavin, A., P. Wilkinson, A. Harwood, and M. Novak. "Easy Approach to Requirements Syntax (EARS)." International Requirements Engineering Conference RE, 2009: 317-322.

[5] ISO/IEC/IEEE. "29148 Systems and software engineering (Life cycle processes — Requirements engineering)." 2011.

トラックバック

トラックバックpingアドレス https://asdoq.jp/blog/tb.php/15

コメント


投稿者 スレッド
ShioyaAtsuko
投稿日時: 2022-6-6 10:45  更新日時: 2022-6-6 10:45
Just can't stay away
登録日: 2011-4-7
居住地:
投稿数: 144
 Re: 山修の開発文書品質入門(10) ―― 要...
要求文を記述する際に、構成要素を決めておくことで、書き手に依存しがちな表現の曖昧性を避けられますね。
書き手自身も、セルフレビュー時に、記載すべき事項のチェックに使えそう。
レビュー時の観点を決める上でも、参考になりそうです。

メニュー

サイト内検索

カテゴリ一覧

ログイン

ユーザ名:

パスワード:

次回からIDの入力を省略



パスワード紛失