requirement
「requirement」とは、必需品・前提条件・要求のことを意味する英語表現である。
「requirement」とは・「requirement」の意味
「requirement」は、必要とするもの、必需品などの意味を持つ名詞である。ビジネスやシステムに関することなど、フォーマルな場面や、やや堅い文章でよく使われる言葉だ。通常、「requirements」と複数形で用いられることが多い。「requirement for～」のように前置詞の「for」を伴うと、「～の必要条件」という意味の表現になる。関連語としては、「require」という動詞が挙げられる。これは、必要とするという意味を持つ言葉だ。また、要求物、要件、要求するものという意味も持ち合わせている。工学分野において、「Requirements」という表現が用いられる際は、要求仕様のことを指している。これは、特定の製品やサービスがどうあるべきか、機能や特性などについてまとめたものだ。「Requirements」の他に、「requirements specification」と言われる場合もある。
「requirement」の発音・読み方
「requirement」の音節は「re・quíre・ment」である。発音記号は「rikwáiərmənt」で、「リクワイアメント」と読む。なお、アクセントは「ワイ」の部分にくる。「requirement」の語源・由来
「requirement」は、「re」と「quire」、「ment」という三つの言葉から成り立っている。「ment」は、「～すること、～するもの」などの意味を持ち、単語を名詞化する接尾辞である。そして、「require」の語源は、「再び、繰り返し」という意味を持つラテン語「re-」と、「求める」を意味する「quaero」とされている。ラテン語の「requiro（必要とする）」を経て、古期フランス語の「requerre（必要とする）」へ形を変えていったのだ。「requirement」の対義語
対義語としては、「option（選択肢）」や「elective（選択科目）」などが挙げられる。「requirement」の類語
要求という意味を持つ場合、「demand（要求）」が挙げられる。必需品や、必須といった意味合いの場合は、「necessity（必要、必要性）」や「essential（必要不可欠、必須）」、そして「requisite（必要、必需品）」や「necessary（必要、必需品）」などが当てはまる。また、「prerequisite」も必要条件という意味を持つ言葉で、類語として挙げられる。「requirement」を含む英熟語・英語表現
「Requirement」の略称とは
「Requirement」の略称は、「req」である。必須、要件などの意味を持つ。なお、「req」は、依頼という意味の「request」が省略された言葉でもあるため、注意が必要だ。依頼という意味の場合は、メールの件名などに使われることが多い。
「requirement already satisfied」とは
直訳すると、「要件はすでに満たされてる」になる。すでに正しくインストールされているという意味で、プログラミングの際などに出てくる表現。
「minimum requirements」とは
必要最小量、必要最小限という意味の表現。「minimum」は、最小の、最小限のといった意味合いを持つ言葉である。
「requirement」に関連する用語の解説
「required」とは
必要な、必須の、必修の、必要とされるという意味合いの形容詞だ。「required courses」で、必須課程、必須科目といった意味になる。類語としては、「compulsory」が挙げられる。法や命令などによって、強制的な、必修の、義務的なといったニュアンスを持つ言葉だ。なお、対義語には「elective（選択の、選択的な）」が当てはまる。また、「required」は、動詞「require」の過去形、過去分詞形でもある。
「meet requirements」とは
「meet requirements」は、「条件を満たす」というニュアンスの表現である。
「requirement」の使い方・例文
「requirement」を使った例文は、下記の通りである。・This product meets the requirements to pass the examination.（この製品は、審査に合格するための要件を満たしている。）
・As long as you meet the entrance requirements for this school, you shouldn't feel too uneasy.（この学校の入学要件を満たしていれば、あまり不安に感じることはないだろう。）
・I would like you to explain the requirements in detail at the next meeting.（次の会議で、要求仕様を詳しく説明してほしい。）
・To move into that luxury apartment, you have to meet strict requirements.（あの高級マンションに入居するには、厳しい要件を満たす必要がある。）
・In order to clear the presented requirements, we have to solve many problems from now on.（提示されている要求条件をクリアするためには、これからたくさんの問題を解決していかなければならない。）
Requirement
要求仕様
(requirement から転送)
出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2022/11/24 08:42 UTC 版)
|
|
要求仕様（ようきゅうしよう、requirement、requirements specification）とは、工学分野において特定の製品やサービスがどうあるべきかを記述する文書を指す。主にシステム工学とソフトウェア工学で使われる用語である。単に、要件、または英語の requirement からリクワイアメント（リクワイヤメント）ともいう。
従来からの工学的手法では、要求仕様を入力として製品開発における設計工程が行われる。
要求仕様作成工程の前に一般に実現可能性調査（feasibility study）や概念的分析の工程が置かれることがある。要求仕様作成工程はさらに、要求収集（関係者からのヒアリングなど）、要求分析（一貫性と完全性の検証）、要求定義（開発者に要求を理解させるための文書を作成）、要求仕様記述（要求と設計の橋渡しとなる文書を作成）の各工程に分けることができる。
システム工学とソフトウェア工学における要求仕様
システム工学では、要求仕様はシステムが何をしなければならないかを記述したものと言える。この種の要求仕様は、完成したシステムが実行可能でなければならないことを指定する。他の要求仕様の形式として、システム自身に関する記述をする場合もあり、機能をどの程度うまく実行するかを示す。後者の要求仕様は「非機能的要求仕様」あるいは「性能要求仕様」、「サービス品質要求仕様」などと呼ばれる。例えば、可用性、検証可能性、保守性、ユーザビリティなどに関する記述がそれに含まれる。
要求事項の集合によって、必要なシステムの特徴や機能が定義される。よい要求仕様は一般に「どのように」システムを実装すべきかを記述せず、そのような設計上の判断は設計者に任せる。
ソフトウェア工学でも、要求仕様に記述すべきことはほぼ同じだが、ソフトウェアだけに焦点が当てられている点が異なる。
要求仕様作成の要因
分類
要求仕様は、一般に以下の3つに分類される:
- 機能的要求仕様 - システムの機能やシステムがなすべきことを記述する。
- 非機能的要求仕様 - システムの備えるべき属性（例えば、性能、可用性、アクセス可能性など）を記述する。
- 制約条件 - 開発に対する何らかの条件。例えば、システムが動作すべきオペレーティングシステムを指定したり、システムの実装に使用すべきプログラミング言語を指定したりする。
要求仕様を理想的なレベルに仕上げるのは非常に難しい。専門知識を有するユーザーが、ユーザーと開発者の橋渡しの役を果たすことも多い。そのようなユーザーは機能的要求を容易にシステムの機能設計に変換できる形で表現でき、かつその表現はエンドユーザーにも理解できるものとなる。
よい要求仕様
理論上、よい要求仕様は次の特徴を満たす:
- 必要性 - 含めなければならない事項や他のシステムコンポーネントで補えないような重要なシステム要素が網羅されている。
- 明確性 - 何通りにも解釈できる書き方をしない。
- 簡潔性 - 読みやすく簡潔に書かれており、何が必要かという要点は抑えている。
- 一貫性 - 各要求事項間で矛盾がなく、他の関連する要求仕様とも矛盾しない。さらに、用語の使い方も一貫している。
- 完全性 - 1つの文書に全てが書かれており、読者が意味を調べるために他の文書を読まなければならなくなるようなことがない。
- 到達性 - 前提条件となる費用と期間に対して、要求されている機能の程度に実現性がある。
- 検証性 - 要求内容が正しく実装されたかどうかを検証する方法が記されている（インスペクション、分析、デモンストレーション、テスト）。
検証可能性
ほとんどの要求事項はテスト可能であるべきである。もしテストできない要求事項があれば、代替となる検証方法が使われるべきである（例えば、分析、インスペクション、設計レビューなど）。テスト可能な要求事項は評価（ソフトウェアテストなど）の重要な要素となる。
要求事項によっては、その構造上テスト不可能な場合がある。例えば、ある事象が「決して起きてはならない」とか「常にそうでなければならない」といった要求事項は、テストができない。こういった事項をテストしようとすると、テストを無限に実施しなければならなくなる。このような要求事項はより現実的な時間を指定するよう書き換えられることが多い。
テスト不可能で非機能的な要求事項が、顧客の要請で残される場合がある。しかし、そのような要求事項は適切な実際的方法で限定された開発手法の要求事項として置き換えられるのが一般的である。
検証可能性は一種の明確さに基づくものであり、必須ではあるものの、他の重要な問題がおろそかになる危険性もある。要求仕様が全体として間違っていても、依然として検証可能である場合もある。検証可能であることは、その要求仕様が正しいことの保証にはならない。また、必要な事項が抜け落ちていた場合、検証可能性はそれについて何も保証できない。分析やインスペクションやレビューによってそのような問題の一部を見つけることができるとしても、要求仕様の妥当性の問題は大きく、要求工学の研究テーマの1つとなっている。
要求分析
要求仕様はあいまいで不正確で一貫しないものになりやすい。この問題への対処として厳密なインスペクションなどの技法が示されてきた。あいまいさや不完全性や不整合性を要求仕様からなくすことで、開発工程の後の方で同様の問題が発覚したときよりも遥かに費用がかからなくなる。要求分析はそのような問題に対応する努力である。
要求仕様の詳細さの程度には、以下のような工学的トレードオフがある:
- より詳細な要求仕様は、作成により時間がかかる
- より詳細な要求仕様は、選択可能な実装上のオプションを制限する傾向がある
- より詳細な要求仕様は、作成により費用がかかる
要求仕様の記述
要求仕様は、システムが使われる領域に適したビジネスルールに従い、システムの作成/修正を指示するような形で書かれる。システムは、その事業のビジネス領域に正しく対応すべきである。要求仕様の一般形式は「誰が何をするのか」といったものである。例えば、「契約者は X年Y月Z日までに製品を提供する」といった形である。
要求仕様の変更
時と共に、要求仕様は変更されることがある。
その場合、要求仕様が定義され承認された後、要求仕様は変更制御の管理下におかれる。多くのプロジェクトでは、要求仕様はシステム完成前に変更される。このような特性があるため、要求仕様には要求管理が必要とされる。
ソフトウェアの要求仕様の厳密性に関する論争
エクストリーム・プログラミングのような最近のソフトウェア工学の方法論では、要求仕様を厳密に記述する必要性に疑問を呈している。その代わりとして要求仕様を「ユーザーストーリー」として非形式的に記述し、そのユーザーストーリーから受け入れテストのテストケースを作成する。ユーザーストーリーとは、システムのすべきことをある観点から簡単に描いたものである。
関連項目
外部リンク
- The Rational Edge 要求仕様の決定に時間を割かない結末 @IT
- 要求仕様検証ツールSTIMULUS(要求仕様の動的検証）
- requirementのページへのリンク