「要求仕様」の版間の差分
2022年12月23日 (金) 21:35時点における最新版
要求仕様(ようきゅうしよう、requirement、requirements specification)とは、工学分野において特定の製品やサービスがどうあるべきかを記述する文書を指す。主にシステム工学とソフトウェア工学で使われる用語である。単に、要件、または英語の requirement からリクワイアメント(リクワイヤメント)ともいう。
従来からの工学的手法では、要求仕様を入力として製品開発における設計工程が行われる。
要求仕様作成工程の前に一般に実現可能性調査(feasibility study)や概念的分析の工程が置かれることがある。要求仕様作成工程はさらに、要求収集(関係者からのヒアリングなど)、要求分析(一貫性と完全性の検証)、要求定義(開発者に要求を理解させるための文書を作成)、要求仕様記述(要求と設計の橋渡しとなる文書を作成)の各工程に分けることができる。
システム工学とソフトウェア工学における要求仕様
[編集 ]システム工学では、要求仕様はシステムが何をしなければならないかを記述したものと言える。この種の要求仕様は、完成したシステムが実行可能でなければならないことを指定する。他の要求仕様の形式として、システム自身に関する記述をする場合もあり、機能をどの程度うまく実行するかを示す。後者の要求仕様は「非機能的要求仕様」あるいは「性能要求仕様」、「サービス品質要求仕様」などと呼ばれる。例えば、可用性、検証可能性、保守性、ユーザビリティなどに関する記述がそれに含まれる。
要求事項の集合によって、必要なシステムの特徴や機能が定義される。よい要求仕様は一般に「どのように」システムを実装すべきかを記述せず、そのような設計上の判断は設計者に任せる。
ソフトウェア工学でも、要求仕様に記述すべきことはほぼ同じだが、ソフトウェアだけに焦点が当てられている点が異なる。
要求仕様作成の要因
[編集 ]分類
[編集 ]要求仕様は、一般に以下の3つに分類される:
- 機能的要求仕様 - システムの機能やシステムがなすべきことを記述する。
- 非機能的要求仕様 - システムの備えるべき属性(例えば、性能、可用性、アクセス可能性など)を記述する。
- 制約条件 - 開発に対する何らかの条件。例えば、システムが動作すべきオペレーティングシステムを指定したり、システムの実装に使用すべきプログラミング言語を指定したりする。
要求仕様を理想的なレベルに仕上げるのは非常に難しい。専門知識を有するユーザーが、ユーザーと開発者の橋渡しの役を果たすことも多い。そのようなユーザーは機能的要求を容易にシステムの機能設計に変換できる形で表現でき、かつその表現はエンドユーザーにも理解できるものとなる。
よい要求仕様
[編集 ]理論上、よい要求仕様は次の特徴を満たす:
- 必要性 - 含めなければならない事項や他のシステムコンポーネントで補えないような重要なシステム要素が網羅されている。
- 明確性 - 何通りにも解釈できる書き方をしない。
- 簡潔性 - 読みやすく簡潔に書かれており、何が必要かという要点は抑えている。
- 一貫性 - 各要求事項間で矛盾がなく、他の関連する要求仕様とも矛盾しない。さらに、用語の使い方も一貫している。
- 完全性 - 1つの文書に全てが書かれており、読者が意味を調べるために他の文書を読まなければならなくなるようなことがない。
- 到達性 - 前提条件となる費用と期間に対して、要求されている機能の程度に実現性がある。
- 検証性 - 要求内容が正しく実装されたかどうかを検証する方法が記されている(インスペクション、分析、デモンストレーション、テスト)。
検証可能性
[編集 ]ほとんどの要求事項はテスト可能であるべきである。もしテストできない要求事項があれば、代替となる検証方法が使われるべきである(例えば、分析、インスペクション、設計レビューなど)。テスト可能な要求事項は評価(ソフトウェアテストなど)の重要な要素となる。
要求事項によっては、その構造上テスト不可能な場合がある。例えば、ある事象が「決して起きてはならない」とか「常にそうでなければならない」といった要求事項は、テストができない。こういった事項をテストしようとすると、テストを無限に実施しなければならなくなる。このような要求事項はより現実的な時間を指定するよう書き換えられることが多い。
テスト不可能で非機能的な要求事項が、顧客の要請で残される場合がある。しかし、そのような要求事項は適切な実際的方法で限定された開発手法の要求事項として置き換えられるのが一般的である。
検証可能性は一種の明確さに基づくものであり、必須ではあるものの、他の重要な問題がおろそかになる危険性もある。要求仕様が全体として間違っていても、依然として検証可能である場合もある。検証可能であることは、その要求仕様が正しいことの保証にはならない。また、必要な事項が抜け落ちていた場合、検証可能性はそれについて何も保証できない。分析やインスペクションやレビューによってそのような問題の一部を見つけることができるとしても、要求仕様の妥当性の問題は大きく、要求工学の研究テーマの1つとなっている。
要求分析
[編集 ]要求仕様はあいまいで不正確で一貫しないものになりやすい。この問題への対処として厳密なインスペクションなどの技法が示されてきた。あいまいさや不完全性や不整合性を要求仕様からなくすことで、開発工程の後の方で同様の問題が発覚したときよりも遥かに費用がかからなくなる。要求分析はそのような問題に対応する努力である。
要求仕様の詳細さの程度には、以下のような工学的トレードオフがある:
- より詳細な要求仕様は、作成により時間がかかる
- より詳細な要求仕様は、選択可能な実装上のオプションを制限する傾向がある
- より詳細な要求仕様は、作成により費用がかかる
要求仕様の記述
[編集 ]要求仕様は、システムが使われる領域に適したビジネスルールに従い、システムの作成/修正を指示するような形で書かれる。システムは、その事業のビジネス領域に正しく対応すべきである。要求仕様の一般形式は「誰が何をするのか」といったものである。例えば、「契約者は X年Y月Z日までに製品を提供する」といった形である。
要求仕様の変更
[編集 ]時と共に、要求仕様は変更されることがある。
その場合、要求仕様が定義され承認された後、要求仕様は変更制御の管理下におかれる。多くのプロジェクトでは、要求仕様はシステム完成前に変更される。このような特性があるため、要求仕様には要求管理が必要とされる。
ソフトウェアの要求仕様の厳密性に関する論争
[編集 ]エクストリーム・プログラミングのような最近のソフトウェア工学の方法論では、要求仕様を厳密に記述する必要性に疑問を呈している。その代わりとして要求仕様を「ユーザーストーリー」として非形式的に記述し、そのユーザーストーリーから受け入れテストのテストケースを作成する。ユーザーストーリーとは、システムのすべきことをある観点から簡単に描いたものである。
関連項目
[編集 ]外部リンク
[編集 ]- The Rational Edge 要求仕様の決定に時間を割かない結末 @IT
- 要求仕様検証ツールSTIMULUS(要求仕様の動的検証)