Pre Jasst'20 Kansai の話
https://jasst20kansai.connpass.com/event/185271/
JaSST Kansai の本番が「テストのための分解、再構築」ということでプレイベントの内容もそれにちなんだものになったそうです。本日のテーマはその分解や再構築の対象になるテスト対象の要求や仕様、これをどのように抽出しているか学びましょう、という講演でした。講演者は豆蔵の大段さん。
ということでいわゆる要求エンジニアリング手法というものの解説がメインとなりました。なぜそうなのかというのは伝えたいこととして冒頭に説明がありました。
ということがポイント、ということでした。
ということで以下本編です。まずは要求の重要性の話。
いくつかのデータを元に説明されていましたが、ソフトウェアのエラーの大半は要求や仕様の不完全さに起因するのだそうです。NISTの2002年の報告ではバグの6割以上が要件分析と設計の段階で発生、US AirForceの1992年報告では修正の必要だったエラーのうち、41%が要件分析、28％論理設計の問題だったんだそうです。いわゆる上流工程大事、ってやつでしょうかね。そしてこの手の話ではお決まりとも言えますが手戻りコストの話と下流ほどそのコストが膨れ上がるという話が続きます。これは研修とかではしょっちゅう聞きますね。手戻りコストは全開発コストの3-5割、そして要求の誤りは手戻りコストの70-85%、仕様関連のバグは全体の50%なんて話があるんだそうです。まぁ現場現場によると思うので参考程度、だとは思いますが。
そして要求に問題があるとどうなるかという例が列挙されていきます
-
開発はしたものの、クレーム発生
-
顧客「なぜこうなっていないのですか？」 開発「その仕様は聞いていません」
-
やりたいことは出てくるが明確な要求は出てこない
-
作業内容や範囲がころころ変わる
-
設計や実装の工程で仕様変更が頻発
・・・・既視感、もとい恐ろしいですね。
-
テスト段階での仕様の問い合わせが多い
-
テスト段階で現物に併せた仕様変更や調整、制限が行われる
-
テスト段階で大幅改修が発生する
・・・これこそ既視感、じゃなかった先を続けましょう。
こういう状況のとき、要求にはどのような問題があるのでしょうか。大段さんの説明が続きます。
-
仕様の抜け漏れ
-
文書化されない仕様
-
曖昧な仕様
-
定義されていない用語の使用
-
矛盾のある仕様
「仕様」を「テスト仕様」に置き換えるとこれはそのままテストの問題でもあり、テストエンジニアは常にこれらの問題に対応しているはず、なので、要求に関する理解を深めることがテストにも役立つ、というわけです。
そんなわけで今回説明いただいたのはシステム開発における「要求エンジニアリング」というもので、要求を獲得し要件化して妥当性を確認する、という作業になります。
早速「要求」と「要件」が出てきました。大段さんお勤めの豆蔵さんでは以下のようになっているそうです
-
要求（顧客要件とも）
-
関係者から出たシステムに対する要望で、そのうち関係者間で取り上げることが合意されたもの
-
-
要件（成果物要件とも）
-
システムが備えるべき特性を技術的に定義したもの
-
ちなみに仕様は
-
仕様
-
要件を必要な詳細度で正確かつ完全に定義したもの
-
だそうです。
違いがわかったところで要求の獲得方法です。大まかな流れとしては
-
生成源を特定
-
抽出（初期抽出→網羅的抽出）
-
折衝
となります。
まず生成源ですが、要求の発生するところはどこか？という話です。例としては以下のようなものが挙げられていました。
-
ゴール
-
いわゆるプロジェクトの上位目標、ビジョンとかですね
-
-
利害関係者
-
ドメイン知識
-
不具合リスト（過去の積み残し）
-
リスク（安全・セキュリティ）
-
このあたりはまぁそうですよねというのが続きます
-
-
運用環境
-
システムの運用稼働に関する制約
-
-
組織環境
-
組織の文化、構造、内部政策
-
利害関係者は実際に人物が存在しているわけですが、それ以外はヒアリングすればよいというわけにはいかないので担当をアサインして要求を獲得しにいくことになるようです。
利害関係者は以下のような方々になるということです。
-
顧客
-
ユーザー
-
システムにより職を失う人も喪失者集団という利害関係者なんだそうです
-
-
マーケティング、アナリスト
-
市場動向やニーズ、ならびにその代弁者
-
-
官庁
-
法規制など
-
-
開発者
-
テスター
-
支援者（テクニカルライタなど）
-
運用/保守担当者
-
生産ライン
-
組み込みではよくあるという話です。
-
こういった生成源にたいして、インタビューしたりアンケートしたり、時には進行役付きのグループMTGとかプロトタイピングして要求を引き出していくそうなのですが、その際のポイントとしては
-
高位の目的、ビジョンやコンセプト、ゴールの理解
-
背景や意図を理解することで認識ズレを防ぐことができる
-
目的や意図から見逃していた要求を拾い上げることができる
-
目的や意図は要求の根拠に相当するものなので、要求そのものとは区別して扱う
-
-
-
用語集をつくる
-
同義語をまとめると効果的（Userに対してユーザーや「一般」も同じに意味になる、とか）
-
こうして初期抽出をしていくのですが、その際には大項目、ID、要望内容、理由などを記録していきます。要望と理由はまとめずに分離して書き、複数の理由がないかチェックするのがポイントだそうです。また、とにかくたくさん出てくるので重要度をつけて採否を決めることも大事で、ここでも理由を記録しておくのが大事です。（あとになってなんで採用しなかったんだっけ？となるのを防ぐため）
ここまでが初期抽出で、ついでそれらに漏れがないのかという網羅的抽出になります。手法としては
-
シナリオを使って網羅的に出す
-
既存システム画面による網羅的抽出
で、対象が違うだけで大まかな流れは同じみたいなので前者で説明していきます。
ユーザーがシステムを利用する局面を具体的に取り上げてその利用のステップに沿って要求を抽出することで漏れをなくそうという流れです。シナリオを定義してユースケースをUMLなどで記述し、それを別途体系に照らして不足がないかを洗い出し、最後に要求間の依存関係を整理する、という手順になっています。
シナリオはアクター、事前条件、システム、事後条件を登場人物とした相互作用として記述されるみたいです。このあたりはもうちょっと具体例があると良かったかなと思います。なんとなくわかった気にはなったのですが、あとで思い返すとよくわからない部分もあるような。
で、これだと初期抽出と変わらないので、網羅するために体系を定義してそれに照らし合わせるということをやります。ここのところがポイントなのかなと思いました。体系はユースケース、ならびにシステム全体に対する非機能要求をもとに構成するようです。
体系というからにはレベル？階層？を揃えないといけないので、以下のような感じにされていました。
-
大項目 ユースケースに対応
-
中項目 イベントに対応
-
小項目 イベント単位の入出力や非機能要求に対応
ふわっとしていた話だったように感じていましたが割と具体的になった気がしました。抽出したユースケースで足りないものがないか並べて付き合わせる感じでしょうか。非機能要求の方は考えが及びにくいのでどうするのかなというところですが、そこで登場するのがこちら。
ISO 25010
・・・・。うーんという気もしますが、そうそううまい話があるわけでもないですよね。といってもあくまで参考に照らし合わせて併用する感じだそうです。まぁ規格至上だとだいたい歪んでしまいますものね。そうは言っても何も参照せずにもらなく抽出するのも難しいわけで、使えるものは使えばいい、ってことなのでしょう。大事なのは範囲を決めてその中をもれなく、ということでした。
あとは要求間の依存関係ですが、こちらは例えば
-
ボタンを押すと商品購入できる
-
商品には対応する購入するボタンが存在する
この場合ボタンが存在しないと購入できないという依存関係が存在するということでした。前者の要求は暗黙に後者を前提にしているので、その存在をあぶり出さないといけない、という感じかな？
そして最後は折衝です。関係者間での合意。重要度や要望元を整理し、種々のバランスのもとに合意を形成します。ここでも採否理由の記録をしておくと役立つとのこと。
合意したら要求を要件化します。要件は完全に定義すれば同じものが得られるようになってないといけないということで、明示的に指定されない項目を含めて明細に指定されないといけないそうです。難しそう・・・。要件を文書化する際の注意事項は以下。
-
体系的に。抜け漏れなく
-
要件リスト全体の体系を明確に
-
明確かつ特定的に
-
仕様と説明は区別
-
要件は検証可能でないといけない
要件を引き出すためには要求との関連付けが大事ということです。要求がないのに要件が出てくるのはおかしいので、要求が漏れている可能性があります。あとは要件を引き出すためには要件自体も体系的に構成することを意識したほうが良い、ということでした。例えば
-
要件の構成項目を事前に決めてそれに沿って抽出する
-
画面レイアウト
-
初期値
-
入力データ
-
事前条件
-
処理
-
出力表示
-
例外
-
エラー
-
性能
-
I/F
という具合に。
ざっくりそんな感じの話だったのですが、最後にテストのとの関わりです。まず結論としては「要求エンジニアリング手法の活用は有用」というのが大段さんの言いたいことで、その理由は
-
体系的に洗い出された要求、要件、仕様はテスト分析しやすい
-
開発との共通理解
-
テスト対象、範囲の明確化
-
テストしたいところを絞り込みやすい
-
というあたりでした。うなずけます。そしてやってることはテストとそれほど違わないとも言っていました。なぜかというと技術要素が同じだから。具体的には
であると。たしかに・・・。
最後にテスト開発への活かし方ですが以下のようなものでした。
-
テスト開発への活かし方
-
要求、要件、仕様のつながりを意識したテスト開発
-
テストエンジニア間の認識ズレを無くす
-
要求、要件、仕様の理解
-
特に背景や理由
-
-
用語の意味
-
-
-
重要なテスト条件の抽出およびレビュー、テストの実施
-
曖昧なテストすべき要求、要件、仕様はないか
-
それらを優先的に、レビュー、テストする
-
-
まだ洗い出されていない要求、要件、仕様はないか
-
開発へのフィードバック
-
-
-
プレイベントなのに書いたのがJasstKansai本番直前になってすみません。
まぁ自分の復習になったので良しとしておこう。
