ソフト開発監査チェックリスト（８）要件管理技術（全般）
ソフト開発監査のチェックリストのチェック項目を順に紹介していきます
ソフト開発監査は、ソフトの開発委託先の能力を判定するためにグータラ親父が勝手に命名した監査の方法です。ソフト開発監査の概要や監査時の事前の準備や監査当日の作業内容については、他の記事で紹介しています。また、ソフト開発監査で使う監査チェクリストの使用時のポイントについても、別の記事で紹介していますので、そちらをご覧ください。
この前後の記事では、以下の４つの種類のソフト監査チェックリストの個々の項目について、順番に紹介していきます。
- 開発プロセスのチェックリスト
- 開発技術の１つ目の要件管理のチェックリスト
- 開発技術の２つ目のテストのチェックリスト
- 開発技術の３つ目の設計と実装のチェクリスト
この記事では、前の記事で紹介した開発プロセスのチェックリストに続いて要件管理のチェックリストについて各々のチェック項目を紹介します。なお、要件管理のチェックリストを使う時のポイントについては ソフト監査実務・監査当日その８：要件管理のチェックのポイント の記事で紹介していますので、そちらも一緒に読んで頂くと判り易いと思います。
ソフト開発技術の３つの要素の１つ目は要件管理の確認です
品質の良いソフトを作り上げるには、開発プロセスよりもソフト開発技術がより重要で、その中でも要件管理はとても大切です。簡単な話で、技術が無ければソフトという製品物はできあがりません、何を作るのかの要件があやふやだとピント外れの製品になってしまいます。
ソフト開発監査では、１つ前の記事で紹介したソフト開発プロセスと合わせて、ソフト開発技術についても３つの視点で相手先の技量の良し悪しを判断しています。委託先に要求仕様を伝える要件管理と、委託先での設計・実装と、委託先からの成果物を受け取る時のテストによる確認です。
この記事では、１つ目の要件管理のチェックリストについて紹介していきます。ソフト開発監査がグータラ親父が勝手に作った仕組みなので、このチェックリストも何かの規約とか標準があるわけではありません。単にグータラ親父はこんなのを勝手に作って使っていたというだけですが、要件管理に関するソフトウエア開発監査の紹介には使えると思いますので、ここに載せておきますので、こちらも参考に見ながら記事をご覧ください。
（クリックするとpdf が開きます）
要件管理のチェックリストは１行が１つのチェック項目となっていて、横方向には６つの欄があります、６つの欄の使い方は開発プロセスのチェックリストと同じですので、各々の欄の使い方については、前の記事の ソフト監査実務・チェックリストその１：開発プロセス（要件管理）をご覧ください。
要件管理のチェックリストは以下の７つの大項目に分類してあり、それぞれの分類の頭文字を持ったID番号が付けてあります。
- 全体（GE-） ：要件管理の全体的な項目についての確認
- 信頼性（RE-) ：信頼性に関する要件についての確認
- 可用性（AV-） ：可用性（機能がいつでも使える性質）に関する要件の確認
- 保守性（SA-） ：機能追加や不具合の修正などの保守に関する要件の確認
- セキュリティ（SE-）：セキュリティに関する要件の確認
- 検収条件（TR-） ：完成したソフトウエアの検収に関する要件の確認
- 開発管理（TR-） ：開発管理の手法に関する要件の確認
それでは、順番に紹介紹介していきましょう。要件管理のチェックリストも見ながら記事を読んでいただくと判り易くなると思います。
要件管理全体に関するチェック項目
まずは要件管理の全体に関する項目ですが、実はこれらの項目は最初はその他（Others）としていました。何度かソフト開発監査を実施していく中で、その他という大項目だと何か重要性が他の項目よりも低そうに見えてしまうので、途中から全体に関する項目と名前を変えました。ですので、明らかに全体に関する項目もあれば、その他と分類したほうが良い項目もありますが、あまり気にせずにご覧ください。
【項目番号：GE-0】
要求仕様の一部が未だ確定していない状態でソフト開発が始まってしまう事は、残念ながら良くあります。また、要求仕様の検討設計や実装とが同時並行していく開発スタイルもあります ですので未確定の要求仕様が存在する事を前提にして開発プロセスを考える必要があります。難しい事ではなく、未確定の要求仕様を記録してしっかりと管理する開発プロセスができていて作業が着実に実施されていれば良いので、未確定の要求仕様の管理の状況を具体的に確認します。
【項目番号：GE-02】
製品の要求仕様には準拠する必要のある規格や規制が漏れなく書かれている必要があります。規格に合致している事を証明するための認定を取得する必要があれば、これらも明記してある必要があります。普通に設計していれば見落とす事は少ないのですが、製品を販売する国と設計/製造をする国とが異なる時には注意が必要です。
技術的な規格ならば、必要な物を漏れなくピックアップする事は経験のあるエンジニアにとってはそれほど難しい事ではありません。しかし、他の国の規制や法規に関する事項となるとなかなか判らない事も多く、何等かの手段で相手国に事情に詳しい人に聞く等の工夫が必要です。そのような点も含めて、要求仕様書には製品を販売する国の規制等が漏れなく記載されてるようになっているかに注意して、確認をします。
【項目番号：GE-03】
性能も要求仕様書の重要な項目です。一般的に性能は原価に大きく影響します、単純に言えばお金を掛ければ高性能な製品ができるです。しかしいくら性能が良くても競合他社がより安い値段で販売しているなら、自社の製品は買って貰えません。どの性能を高めるためにどれだけの開発費や部品費用を割り振るのかは、売れる製品の企画として大切な部分です。
そして、その製品企画で決まった方針を確実に製造委託先に伝えるためには、性能についての要件ができるだけ具体的に、定量的に要求仕様書に書かれている事が大切です。性能が良い事、というようなあやふやな要求仕様になっていないか、とう事に注意して確認をしていきます。
【項目番号：GE-04】
コネクテッドというキーワードが世間一般でも聞かれるようになってきたように、装置が単独で使われる事は少なくなってきてなんらかのシステムに接続されて、お互いに連携しながらサービスを提供する事が多くなってきました。
装置をシステムに組み込んで動作させる場合には、異常検出や対応の方法とかソフトのバージョンアップの方法等について、方針やプロトコルがシステムで決められている場合があるので、装置側にもそれらに対応する機能が必要になります。その様な場合に、業界標準とは異なる個別の規格がある場合もあるので必要な規格や仕様が明確になっているのか、という事に中止して確認していきます。
【項目番号：GE-05】
全く新しい装置を開発して製造する場合には問題にならないのですが、既に市場で類似の装置が使われていてその後継機種を開発して製造する場合には、互換性についての仕様に注意する必要があります。特に GE-04 で紹介したように、何等かのシステムの一部として機能する場合には、旧機種を取り外して新機種に置き換えても、何もしなくてもすぐに動作するような、完全互換性が求められます。
一方で、単独で動作する装置の場合には、後継機種であれば機能が増えていたり性能が上がっていたりする事が求められます。互換性という言葉だけでなく、具体的にどんな背景でどんな内容の互換性が求められているのかが明確になっているか、という点に注意して確認していきます。
【項目番号：GE-06】
装置が他の機器や装置と接続されて使われる時には相互接続性が明確になっている必要があります。開発や製造を委託する装置が、どんな装置や機器のどんなバージョンのソフトと接続して動作する必要があるのかが要求仕様に明確に書いてあれば、委託先はそれらの装置や機器との相互接続性を保証するためのテストを実施する事ができます。
言い方を変えると、相互接続性についての要求仕様が不明確だと何と接続してテストしたら良いのか分からない状況なので、代表的な装置とかたまたま手元にあった装置を接続して、とりあえず動作する事を確認してOKと判断する場合もあります。でもこれでは、実際に製品が出荷されてから接続に問題が見つかる場合が出てきます。ですので、要求仕様に相互接続性という項目がある場合には、その内容が具体的に書かれているかという点に注意して確認していきます。
管理全般の次は信頼性と可用性です
管理全般の確認の次は要件管理の内の信頼性と可用性について、次の記事で紹介します。