202205のエントリ
山本 修一郎
| この連載コラム「山修の開発文書品質入門」では，開発文書に携わる皆さんに役立ちそうな開発文書の品質につながる知識を分かりやすく解説します． バック・ナンバ |
本ブログ第4回では，国際標準に基づく要求文のテンプレートの例を紹介した．
今回は，MazoとJaramillo[1]が，新たに提案しているシステム要求仕様の構文を紹介する．彼らは構成要素を8種類に分類している（表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.
山本 修一郎
| この連載コラム「山修の開発文書品質入門」では，開発文書に携わる皆さんに役立ちそうな開発文書の品質につながる知識を分かりやすく解説します． バック・ナンバ |
機能要求の書き方について，本ブログ第4回で要求テンプレートを紹介した．情報システムの信頼性を向上する上で，非機能要求を明確に定義することが重要である[1]．本稿では，非機能要求の書き方について紹介したい．
ロバートソン ら[2]は，非機能要求(NFR, Non Functional Requirements)を8種類に分類している（表1）．以下では，この分類に従って非機能要求の記述例を説明する．
| 非機能要求 | 説明 | |
| 1 | 外見要求 | システムの外見についての要求 |
| 2 | 使用要求 | システム機能が使用性について満たすべき達成条件 |
| 3 | 性能要求 | システム機能の応答速度，容量，正確性，効率性，安全性 |
| 4 | 運用要求 | システムの運用・操作環境が満たすべき条件 |
| 5 | 保守要求 | システムの変更可能性 |
| 6 | セキュリティ要求 | システムが機密性，一貫性，可用性について満たすべき条件 |
| 7 | 組織文化要求 | システムの開発・運用・利用に携わる組織行動についての要求 |
| 8 | 法制度要求 | システムに適用される法制度および標準への準拠性 |
1. 外見要求
2. 使用要求
3. 性能要求
4.運用要求
5. 保守要求
6. セキュリティ要求
7. 組織文化要求
8. 法制度要求
[1]経済産業省「情報システムの信頼性向上に関するガイドライン(案）」平成18年4月4日，https://warp.da.ndl.go.jp/info:ndljp/p ... rent.ndl.go.jp/print/3751
[2]スザンヌ・ロバートソン，ジェームズ・ロバートソン，苅部英司訳，要件プロセス完全修得法，三元社，2002
