【連載】要求工学における「利用状況」の扱いをめぐる考察：要求(要件)定義に主語は必要か？（第４回②）

先より参照しているJIS X 0166[1]の8.4.2において、システム要件（要求事項）仕様（SyRS）のアウトライン例が示されていますが、その先頭の方で以下のような項目を含めるように示されています。

1.1 システムの目的

1.2 システムの適用範囲

1.3 システムの概要

1.3.1 システムの状況

1.3.2 システムの機能

1.3.3 利用者特性

こういった項目をまず明確にした上で、十分に意識して個々の要求を表現していく必要があります。範囲は適用範囲と共に、これから作る人工物全体の構成の範囲を明確にしていきます。基本的にそれが個々の要求表現の主語になるからです（機能的な範囲は、それら個々の要求表現と、その集合として明確化されることになります）。ここで役立つのがコンテキスト図です。

コンテキスト図は対象システムが動作する環境および周囲の外部要素を明示するためのダイアグラムです。扱う範囲を明確にするには、それが扱う要素を示すと共に、周りの（関係はするが）扱わない要素を示し、境界を描き出す必要があります。ただし、外部要素は挙げ出したらきりがないので、以下のような観点に絞って、網羅的に記すと良いでしょう。

• 対象システムに影響を与える外部要素
• 対象システムと何らかの相互作用する外部要素
• 以降の分析/設計作業において、分析/設計者が着目し、検討を行うべき外部要素つまり、「コンテキスト図とは何か」と言えば、次のようにも説明できます。
• 分析/設計者が検討を行う範囲を宣言するためのダイアグラム
• 分析/設計作業の前提条件を表現するダイアグラム

以下にSysMLを用いた顧客(関係)管理システムのコンテキスト図を例示します。図の中央の青い枠で示した範囲がこれから作る人工物の範囲であり、各機能要求表現の暗黙の主語になるものである、と明確に宣言することになります。

なお、このコンテキスト図はSysMLの仕様では特に定義されていません。そのため内部ブロック図の表記方法を流用して作成されることが多いようです。

ここまでは、特に設計・開発する入口としての要求表現について話しました。設計が進むにつれて、手段となる構成やアーキテクチャが検討・決定されていき、要求およびそこから導出された要求(derived requirement)が、分解された構成に割り当てられていくことになります。

そこに至ってから、割り当てられた先の構成を主語として書き込んでいくという方法もあれば、分解された構成別に別途文書やモデルを作成していくという方法もあります。

ここで、入口での元の要求はそのまま取っておくことをお勧めしています。設計が進んで定義し直すにあたって、“refine”の関係として結びつけておけば、トレースも維持できます。これをお勧めする理由は、派生開発が繰り返されることになる現場で役に立つからです。技術が進歩し、時とともに環境が変われば、改めて元の要求に立ち戻ると、前よりもっと競争力のある別の手段が見つかることが結構あります。簡単に元の要求に立ち戻れないとなると、派生開発を繰り返してもさまつな改良にとどまってしまいがちになります。トレースを維持することは説明責任のためという目的だけでなく、こういったビジネス的な効果も期待できます。もちろん、タイミングよく活用しなければそのトレース情報はただの死蔵になってしまいます。

少し大きなシステムになると、分解された構成別に文書やモデルを作成していく方法を取ることになります。その一部を外注することもあるでしょう。このため、構成別に分割された文書(分冊)を作成する時のルールを明確にしなければなりません。まず、その文書(分冊)が扱う範囲を明確にして、十分にその範囲を意識した表現をすることが大切です。

分冊が扱う範囲、つまりその中での暗黙の主語は分冊ごとに異なるはずなので、当然、要求の表現もそれに合わせて変わるはずです。ところが、全体の要求仕様書(親文書)から多くの部分を、ただコピー・アンド・ペーストしているだけで済ませているのをよく見ます。範囲に関する項目やコンテキスト図も元の親文書からコピー・アンド・ペーストしただけで、その文書がどの範囲を扱うのかを全く示していないことさえよくあります。おそらく、効率よく文書を作ることが目的になってしまい、何のために作るのか、どう活用されるのか、あまり考える余裕がないのだと思います。範囲を曖昧にすることで、どんな問題が起こるかについて、少し考えてみましょう。

例えば、以下の図のように構成が3分割され、分冊として要求仕様書が作られる例を考えてみましょう。アプリからサーバーに問い合わせて株価を表示するようなシステムを具体例としては考えていきます。

構成Aの機能要求仕様、あるいは機能仕様の中に以下のものがあるとします。

• 時刻と銘柄と通貨種別を指定して、該当する価格を構成Fに問い合わせる

構成Sの機能要求仕様、あるいは機能仕様の中に以下のものがあるとします。

• 構成Fからの時刻と銘柄の指定を含む価格問い合わせを受け付ける
• 保有している情報から問い合わせに該当する価格をドルで求める
• 求めたドル価格を問い合わせ元の構成Fに返す

そして、構成Fの機能要求仕様、あるいは機能仕様に以下のものがあるとします。

• 構成Aからの問い合わせ(時刻と銘柄と通貨種別指定)を受け付ける
• 受け付けた問い合わせを構成Sに適する形式(時刻と銘柄だけの指定)に変換して構成Sに中継する
• 構成Sから返されたドル価格を保有している為替レート情報に基づいて構成Aから指定された通貨の価格に変換する
• 変換した価格を問い合わせ元の構成Aに返す

ここからが問題のあるケースの説明を行います。

構成Fの機能要求仕様の表現が、次のようになっていたとします。

• 構成Aからの問い合わせ(時刻と銘柄と通貨種別指定)に該当する価格を返す

インターフェースの要求仕様表現としては、これで良いでしょう。しかし、機能の要求仕様表現としてこれは適切でありません。まず、構成Fがどんな働きや振る舞いをすべきなのか、表現しきれていません。何らかの他の情報で補われていない限り、これでは構成F自体が各銘柄の価格を知っていなければならないように読めてしまうからです。

構成Fの開発担当に、例示した不適切な方の要求仕様表現の分冊を渡してしまったなら、その担当は自分の担当部分が価格を把握していて、答えられるように作らなければならないと誤解するかもしれません。

他にも、時を経て保守が必要になり、派生開発時に、その時の担当者が構成Fの分冊に不適切な表現を見つけたなら、構成Fの中にその処理があるものと誤解して探し回り、貴重な工数を無駄にすることになりかねません。

ここまで説明してきたような問題を防ぐためにも、ルールを明確に示し、徹底させることが大切です。開発にまつわる文書（電子文書、DBレコード、チケット、カード、付箋紙なども含む）を記述する際には、常にその文書が取り扱う対象の範囲、特に構成（製品、コンポーネント、モジュールなど）の範囲を明確にし、主語としては書かない場合も含めて、常に意識して表現するようにします。

本稿で参照している国際規格[1]は要件(要求事項)の整形式(well-formed)を次のように示しています。

ISO/IEC/IEEE 29148:2018(JIS X 0166:2021)が示す要件の整形式(well-formed)

5.2.4     要件（要求事項）の構成整形式の，利害関係者要件（要求事項），システム要件（要求事項）及びシステム要素の要件（要求事項）を開発しなければならない。

…（中略）…

この記述は，要件（要求事項）とそれらの属性（条件，前提条件及び制約）とを区別する手段を提供する。要件（要求事項）は，ニーズ，並びにそれに付随する制約及び条件を，変換又は表現した記述である。要件（要求事項）は，自然言語又は他の言語形式で記述する可能性がある。自然言語の形で表現する場合，その記述は，要件（要求事項）の情報内容を適切に表現するために不可欠な他の要素とともに，主語及び動詞を含むものにするのがよい。要件（要求事項）は，要件（要求事項）の主体（例えば，システム，ソフトウェア），何をなさなければならないか（例えば，ある電力レベルで運転する，あるフィールドを提供する），又はシステムに課す制約を記述しなければならない。図 1 に要件（要求事項）の構文例を示す。

ほかにも要件（要求事項）を捉える方法に，条件アクション表及びユースケースがある。

…（以下略）…

この文の中で「図1 に要件(要求事項)の構文例を示す」とありますが、その構文例を書き直したものを以下に示します。

自然言語の形で表現する場合、「主語(subject)および動詞(verb)を含むものにするのがよい。」と明記されています。一方、図に示されている[対象(Object)]は伝統的手法が推奨している「A（目的語となる名詞）をBする（動詞）」という表現のAに相当するわけですが、そこに特別な説明は加えられていません。

主体(subject)の例としては、「システム」、「ソフトウェア」が示されています。この例示は、先述してきた通りでもあり、今から設計・開発する入口としての最大限の自由度を担保した範囲を示す表現が選ばれていますが、主語を明記するというルールは多くの伝統的な手法とは一致していません。

ですので、JIS X 0166:2021(ISO/IEC/IEEE 29148:2018)にのっとることを優先させたい場合には、注意が必要です。

ただ、この規格[1]は表現方法を画一化することを目的としていません。先に引用した部分の中でも「自然言語又は他の言語形式で記述する可能性がある。」と記載されており、自然言語以外の例として、「条件アクション表」、「ユースケース」が挙げられています。

ところで、自然言語で要求仕様書が作成された場合、そこには要件(要求事項)だけでなく、例えば既存部分の説明などが随所に含まれることになりがちです。そうなっていると、読む側としてはどの部分の記述が要件(要求事項)なのかが分かりにくくなり、見落としにもつながります。

そこで、先の規格[1]は、このような問題への解決策を以下のように示しています。

5.2.4     要件（要求事項）の構成(続きの一部)

要件（要求事項）の存在を目立たせる特定のキーワード及び用語を事前に合意しておくことは重要である。次のことを取り決めるのがよくある方法である。

注記2 これらの表現を採用しない場合でも，要求事項の所在を識別し，任意選択・非拘束の条項との区別を識別可能な仕組みを合意することが可能である。

－ 要件（要求事項）は必須の拘束条項であり，“○○しなければならない（shall）”を用いる。

…（以下略）…

これは、ISOやIECの規格についてのルールをそのまま取り入れた方法です。ISOやIECの規格では、その規格への適合性を示すための要求事項が明確になるように、「○○しなければならない」という意味を持つ「shall」という言葉を用いて記述しており、これに倣った方法が示されています。

しかし、先の引用部分の注記2に示されている通り、必ずこの方法である必要はありません。

例えば、USDM(Universal Specification Describing Manner)[2]は、要求と理由と説明を明確に分けるテンプレートの形式を示しており、全く同じ問題に対する別解法を提案しています。

別の仕組みで区別がつくので、主語を書きませんし、「○○しなければならない」と表現する必要はなく、「○○する」で構いません。また、専用の要求管理ツールや要求管理ツールとして代用できる便利なツールもあります。

文書テンプレートや規格が示している整形式の項目や属性の構造化した部分にデータベースを活用するなど、さまざまな工夫が考えられます。規格はそうした工夫を妨げるものではありません。

また、本稿で示したのとは文脈や理由は異なりますが、規格[1]の引用部分の少し先に、「“○○できること（shall be able to）”などの言い回しの使用は避ける。」と、同じルールが示されています。

さらに、「アジャイルでの要件（要求事項）は，“○○しなければならない”を明示的に使用せずに，ユーザーストーリーのような代替的な形式を用いることがある。」と注記も加えられています。

今回は、伝統的な手法の多くが、機能およびその要求(要件)定義に主語は記載せず、「A（目的語となる名詞）をBする（動詞）」という表現を用いることを推奨していることを説明しました。その理由として、ユーザーレベルと人工物(システムや製品)レベルで異なるところがあることを別々に説明しました。

その主たる狙いは共通しています。不要な手段を要求に含めて制約を加えてしまうことを避け、自由な発想をできるだけ引き出したい、そのための知恵だということです。

一方で、必ずしも主語に無頓着で良いということではないこと、むしろ主語を意識していないと発生してしまう問題も紹介し、対策を説明しました。

国際規格との関係も併せて説明しましたので、それぞれの現場でのルール作りや運用を徹底する仕組み作りの参考にしていただければ幸いです。

[1] JIS X 0166:2021(ISO/IEC/IEEE 29148:2018)システム及びソフトウェア技術―ライフサイクルプロセス―要求エンジニアリング(Systems and software engineering -- Life cycle processes -- Requirements engineering)

[2] 清水吉男, 『【改訂第２版】［入門＋実践］要求を仕様化する技術・表現する技術 ～仕様が書けていますか？』, 技術評論社