202402のエントリ
山本 修一郎
| この連載コラム「山修の開発文書品質入門」では，開発文書に携わる皆さんに役立ちそうな開発文書の品質につながる知識を分かりやすく解説します． バック・ナンバ |
要求仕様者のレビュー結果の妥当性を確認するためには、客観的な評価基準が必要です。本稿では、要求仕様書の語彙に基づく客観的なレビュー手法を紹介します。
まず、レビュー項目では曖昧さの種類を定義します。曖昧さの種類は、①用語自体、②用語属性、③用語例外（用語が正常ではない場合）のいずれかです。用語属性には、範囲、下限、上限があります。
次に、用語の曖昧さに基づいて、レビュー精度を定義します。
定義 レビュー精度水準値 L
0:曖昧用語がない
1:曖昧用語がある
2:用語属性が曖昧である
3:用語例外が曖昧である
たとえば、用語 W の上限などの用語属性が省略されている場合、L(W) =2 となります。
定義 語彙の次元
語彙の次元を、要求仕様の基本要素として「イベント」「入力」「機能」「出力」「応答」で定義します。そして、語彙の次元ごとに、レビュー精度水準値を評価します。
語彙レビューの過程で、レビュー担当者は特定の要件仕様に対する一連のレビュー項目を作成します。
＜実験＞
要求工学の研修コースの中で、要求レビューの実験をオンラインで実施しました。この実験には、16名の組込みソフトウェア開発者が参加しました。開発者の経験年数は、3名が5年未満（以下「初心者」）であり、他の13名は5 年以上（以下「経験者」）でした。
実験に参加した16名の被験者は、インスリンポンプ制御システムに関する次の5つの要求文をレビューしました。
(R1) インスリンポンプ制御ソフトウェアは、患者に埋め込まれたセンサーを使用して、血糖値に比例した血液パラメータを測定します。
(R2) 血液パラメータはポンプコントローラに送られます。
(R3) ポンプコントローラーは、必要なインスリンの糖度と量を計算します。
(R4) ポンプコントローラーは、患者に埋め込まれた針を介してインスリンを投与するために、小さなポンプに信号を送信します。
(R5) インスリンポンプは、ポンプコントローラからの1単位パルスに応答して1単位のインスリンを投与します。
各被験者がこれらの要求文に対してレビューを行い、前述した定義に基づいて要求文Rのレビュー精度水準値Lを、以下のように計算します。
L(R)=（Rの語彙の曖昧さに対する指摘数）／Rの用語数
ここでもし、被験者によるレビューにおいて要求文の語彙の曖昧さに対する指摘がなければ、L(R)＝0になります。また、指摘数が多くなると、L(R)は大きくなります。
レビュー対象とした要求文R1からR5までのL(R)の平均値を、語彙の次元ごとに計算した結果を表1に示します。
|
語彙の次元 被験者 |
イベント | 入力 | 機能 | 出力 | 応答 |
| 初心者 | 0.067 | 0.2 | 0.333 | 0.267 | 0.133 |
| 経験者 | 0.323 | 0.877 | 0.508 | 0.662 | 0.323 |
| 経験者／初心者 | 4.85 | 4.38 | 1.5 | 2.48 | 2.42 |
表1では、曖昧な項目が検出された平均レベルを示しています。経験者の数値が初心者の数値より高いのは、曖昧用語の指摘数が多いことを示します。たとえば、曖昧な「イベント」項に対する初心者のレビュー精度水準値L(R) は0.067であるのに対し、経験者の L(R) は0.323です。したがって、経験者による曖昧な「イベント」項のL(R) は、初心者の4.85倍です。
表1から、経験者と初心者による曖昧用語レビューの大きな違いが「イベント」と「入力」にあることが分かります。一方、「機能」に対する経験者と初心者の差は、これらに比べると大きくないことが分かります。経験者の場合、機能をいつ実行するかという「イベント」と、機能が何を処理するかという「入力」に対し、注意深く要求文を確認する経験知識があると考えられます。このことから、初心者には「イベント」と「入力」について確認する訓練が必要であると言えます。
このように表1は、経験者と初心者の語彙レビュー知識の差を明らかにしていることが分かります。
表1の結果から、初心者と経験者による L(R) をレーダーチャートとして図1に示します。
図1：被験者別のレビュー精度水準値L(R)の比較
まとめ
本稿では、組込みソフトウェア開発者向けに語彙による要求レビュー手法を提案しました。本手法により、曖昧な用語のレビュー精度を数値化できます。本手法を用いて、要求仕様のレビュー実験を行い、定量的な評価を示しました。この実験から、初心者と経験者の要求レビュー能力の差を客観的に示せることが分かりました。
本手法に基づいて、語彙の観点から自然言語要件仕様の曖昧な用語を検出でき、要求レビューを標準化できます。なお、本稿の内容は、論文[1]の要約に基づいています。
参考文献
[1]Shuichiro Yamamoto, Requirements Review Education Curriculum for Embedded Software Practitioners, WSSE '23: Proceedings of the 2023 5th World Symposium on Software EngineeringSeptember 2023Pages 184–187
山本 修一郎
| この連載コラム「山修の開発文書品質入門」では，開発文書に携わる皆さんに役立ちそうな開発文書の品質につながる知識を分かりやすく解説します． バック・ナンバ |
「仕事量を見誤ったか」
生産能力を越えた仕事を受注した結果、品質検査工程で上司から手抜きを強要された社員による外部通報が発生して社会問題化した，ある自動車企業の経営者の言葉だ．この会社のグループ企業では，同じことを繰り返している．
ところで，企業の生産能力を越えた過大な注文を受ければ，所要量の製品やサービスを生産できないか，生産できたとしても製品やサービスの品質が低下するのは明らかである．この経営者は生産能力という最も重要な組織能力の正確な値を認識していなかったことになる．正しい生産能力を知らなければ，注文数が生産能力を越えたかどうか分からない．逆に，生産能力の上限が分かっていれば，過剰な注文数を例外として検知することにより，それ以上の受注を制限できる．
同じことが情報システム障害の原因にもなることがある．たとえば，サービスを受付サーバと処理サーバによる分散システムとして構成することがある．処理サーバの処理能力には上限がある．処理能力を越えたサービス依頼を受付サーバで受理した結果，処理サーバが過負荷となってシステム全体が停止することになる．
DXがめざす姿の一つにデータ駆動経営がある．企業の生産データをリアルタイムに収集することで，生産能力に応じて適切な受注判断ができる．分散型情報システムの例でも，後続サーバの処理能力を越える可能性を先行サーバ側で例外として検知できれば，システム全体の性能や信頼性などの非機能要求の低下を抑止できる．
このように，システムの構成要素間の依存関係に基づく機能例外を考慮することによって，システム全体の非機能要求を達成できる．
