明確で効果的な要件を作成するには
Principal auditor であり、セキュリティ保証マネージャーのデール・ロリンソン (Dale Rollinson) 氏が、明確で効果的な要件 (requirements) を作成する必要性について概説します。
要件 (requirements)* とは、プロジェクト、ミッションまたは組織のニーズを文書化したものです。組織がソファを製造しているのか、人工衛星を製造しているのかに関係なく、私たちはクオリティの実務者として、明確で優れた要件を作成するという規律を根付かせるよう努めるべきです。要件は、プロジェクトのライフサイクル中に発生する他のすべての活動の基盤となります。
プロジェクトが期日どおり、予算内に、かつ高いクオリティで実現されない原因は、多くの場合、要件を満たしていないことにあります。もし要件が間違っていたり、不十分であったりすれば、再作業が必要になる可能性が高くなり、コストは倍増します。したがって、要件の不備が早期に発見されればされるほど、修正にかかる費用は少なくて済みます。
- 要件、要求と訳してあるのはすべて同じ requirements という言葉ですが、日本では意図して、もしくは意図せず、この2つの訳し方が行われており、本稿でも混在する形をとることとなりました。例: 「要求を収集」、「要求工学」
実行可能なタスク
クオリティの実務者が文書化した要件を修正するのに最適なタイミングは、要求を収集し、理解し、文書化に取り組んでいるときです。修正するのが最も難しいのは、省略されている要件です。ここでもまた、利害関係者のニーズを理解する私たちの専門知識は、このような問題を解決するための話し合いの最前線で役立ちます。
IEEE 1233-1998 IEEE Guide for Developing System Requirements Specifications (システム要件仕様開発のためのIEEEガイド) によると、適切な形式の要件には、能力 (capability)、条件 (conditions)、制約 (constraints) を含めることが望ましいとされています。この文脈における「能力」とは、指定された機能を実行できるかどうかを意味します。「条件」とは、何かが可能になる前に存在しなければならない状態を意味します。「制約」とは、要件に適用される制限または制約であり、通常はリソースまたは情報の可用性に関して適用されます。
要件にリソース、メソッド、テスト、制約を適用できれば、実行可能なタスクとなる準備が整います。要件は、何が必要かを記述すべきですが、それをどのように提供するかは記述すべきではありません。要件が実行可能なタスクになる準備が整う前に、「ソリューションを考える」という罠に陥ることがよくあります。
プロセス開発
必要なリソースを備えた整った要件を持つことは、適切に形成されたプロセスの開発につながります。ここで私たちは、プロセスはリソース、メソッド、測定 (テスト)、制約が適用される付加価値活動を通じて、インプットをアウトプットに変換するということを思い起こします。
要求工学 (requirements engineering) の分野では、さまざまな意見がありますが、要求には5つの段階があると考えられています。
- 聞き出し (elicitation)
- 分析 (analysis)
- 仕様 (specification)
- 妥当性確認 (validation) と検証 (verification) (テスト)
- 管理 (management)
まず、「聞き出し」とは、プロジェクト要件のソースとその収集方法を指します。これは、プロジェクトで解決しなければならない問題を理解するための最初の段階です。
次に、「分析」は、要件間の矛盾を検出し解決するプロセスと関係し、プロジェクトの境界を発見して、プロジェクトが環境とどのように相互作用しなければならないかを発見します。そして、より具体的な要件を導き出すために概観的なレベルの要件を精緻化します。
「仕様」とは、プロジェクトの設計目標に値や制限を割り当てることを意味し、要件の定量化と要件間の相互作用のマネジメントに重点を置きます。要件仕様を作成し、適切にレビュー、承認、配布、管理を行う必要があります。効果的なテストを可能にするためには、要件仕様が理解しやすく、一貫性があり、完全であることが重要です。
要件はテストの基盤です。該当する要件が存在しなかったり、適切に記述されていなかったりすると、効果的なテストを実施することは不可能です。要件が完成に近づいている間に、テスターにテストケースを作成してもらうことを検討してください。テスターが有効なテストケースを作成できないとすると、その要件はテスト可能ではないため、書き直す必要があるということです。
テスト可能な要件は、"system shall... (システムは...しなければならない )"という形式で記述されます。「システムはユーザーの要求に対して3秒以内に応答を返さなければならない」など、測定可能な条件が含まれていなければなりません。
テストでは、担当者が要件を理解し、それに従って開発できることを確認します。したがって、要件の妥当性を確認し、実装を検証し、コストを見積もることができるように、要件を十分に正確に記述することが重要になります。
最後に、要件は効果的にマネジメントされなければなりません。ここで、クオリティの実務者は、文書管理、構成管理、変更管理の経験を実践に生かすことで、付加価値を高めることができます。まとめ
これは要件に関するスナップショットに過ぎません。もっと詳しく知りたいクオリティの実務者の方には、以下の2つの規格を参照されることをお勧めします。
- IEEE Standard 1233-1998 IEEE Guide for Developing System Requirements Specifications
- ISO/IEC 25010:2011 Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - System and software quality models システム及びソフトウェア工学 - システム及びソフトウェア品質要求及び評価（SQuaRE） - システム及びソフトウェア品質モデル (JIS X あり)
