要件

工学において、要件とは、作業成果が許容されるものとなるために満たされなければならない条件のことです。これは、材料、設計、製品、またはサービスが満たすべき条件を、明示的、客観的、明瞭に、そして多くの場合定量的に記述したものです。[ 1 ]

仕様またはスペックとは、通常、製品開発の設計段階で開発者によって使用され、検証プロセスでテスト担当者によって 使用される要件のセットです。

アジャイルソフトウェア開発のような反復的かつ漸進的な開発では、要件定義は設計・実装と並行して行われます。ウォーターフォールモデルでは、要件定義は設計や実装の開始前に完了します。

要件は、エンジニアリング設計、システム エンジニアリング、ソフトウェア エンジニアリング、エンタープライズ エンジニアリング、製品開発、プロセス最適化 など、多くのエンジニアリング分野で使用されます。

要件は、顧客、組織、ユーザー、またはその他の利害関係者にとって価値と有用性を持つために必要な、またはシステムが望まれる機能、属性、機能、特性、品質を説明できる、比較的広い概念です。

用語の起源

要件という用語は、少なくとも1960年代からソフトウェアエンジニアリングのコミュニティで使用されています。[ 2 ]

IIBAのビジネス分析知識体系ガイド®バージョン2（BABOK）によると、 [ 3 ]要件は次のとおりです。

  1. 問題を解決したり目的を達成したりするために利害関係者に必要な条件または能力。
  2. 契約、標準、仕様、またはその他の正式に課された文書を満たすために、ソリューションまたはソリューション コンポーネントが満たす必要がある、または備えている必要がある条件または機能。
  3. （１）または（２）のような状態または能力を文書化した表現。

この定義はIEEE 610.12-1990: IEEE標準ソフトウェア工学用語集に基づいています。[ 4 ]

製品要件とプロセス要件

要件は次の 2 つの分野に関連していると言えます。

  • 製品要件は、システムまたは製品の特性を規定します。
  • プロセス要件は、開発組織が実行すべき活動を規定します。例えば、プロセス要件では、従うべき方法論や組織が遵守すべき制約を規定することができます。

製品要件とプロセス要件は密接に関連しています。製品要件はプロセス要件をサポートするために必要な自動化を規定すると言える一方、プロセス要件は製品要件をサポートするために必要な活動規定を規定すると言えるでしょう。例えば、最大開発コスト要件（プロセス要件）は、最大販売価格要件（製品要件）を達成するために課される場合があります。また、製品の保守性要件（製品要件）は、特定の開発スタイル（例：オブジェクト指向プログラミング）、スタイルガイド、またはレビュー／検査プロセス（プロセス要件）に従う要件を課すことによって対処されることがよくあります。

要件の種類

要件は通常、開発の進行段階の異なる段階で生成されるタイプに分類され、その分類法は使用される全体モデルによって異なります。例えば、以下の体系は国際ビジネス分析研究所（IBI）のビジネス分析知識体系[ 5 ]で考案されています（ FURPSおよび要件のタイプも参照）。

アーキテクチャ要件
アーキテクチャ要件は、システム構造とシステム動作の必要な統合、つまりシステムのシステム アーキテクチャを特定することによって、何を行う必要があるかを説明します。
ソフトウェア工学では、これらはアーキテクチャ的に重要な要件と呼ばれ、ソフトウェアシステムのアーキテクチャに測定可能な影響を与える要件として定義されています 。[ 6 ]
ビジネス要件
組織の目標、目的、またはニーズを高レベルで記述したもの。通常、組織が実現したい機会や解決したい問題を記述します。多くの場合、ビジネスケースで述べられます。
ユーザー（利害関係者）の要件
特定のステークホルダーまたはステークホルダーグループのニーズを中間レベルで記述したもの。通常、対象となるソリューションをどのように利用したいかを記述します。多くの場合、高レベルのビジネス要件とより詳細なソリューション要件の中間点として機能します。
機能（ソリューション）要件
通常、ソリューションが実行する機能や能力、動作、および情報に関する詳細な記述です。例としては、テキストの書式設定、数値の計算、信号の変調などが挙げられます。これらは「機能」と呼ばれることもあります。
サービス品質（非機能）要件
通常、ソリューションが効果を発揮し続けるための条件、ソリューションが備えるべき特性、またはソリューションが動作する際に守らなければならない制約について詳細に記述されます。[ 7 ]例としては、信頼性、テスト可能性、保守性、可用性などが挙げられます。これらは特性、制約、または能力とも呼ばれます。
実装（移行）要件
通常、企業の現状から望ましい将来の状態への移行を可能にするためにのみ必要な能力または行動の詳細な記述ですが、その後はもはや必要ありません。例としては、採用、役割の変更、教育、あるシステムから別のシステムへのデータの移行などが挙げられます。
規制要件
法律(連邦、州、地方自治体、または地域)、契約(利用規約)、またはポリシー(会社、部門、またはプロジェクト レベル)によって定義された要件。

優れた要件の特徴

優れた要件の特徴は、様々な作成者によって様々に述べられており、各作成者は一般的に、それぞれの議論全体、あるいは対象となる特定の技術分野に最も適​​した特徴を強調しています。しかしながら、以下の特徴は一般的に認められています。[ 8 ] [ 9 ]

特性 説明
ユニタリー（凝集性） この要件は、ただ 1 つのことだけを対象としています。
完了 要件は、情報が欠落することなく 1 か所に完全に記載されています。
一貫性のあるこの要件は他の要件と矛盾せず、すべての信頼できる外部ドキュメントと完全に一致しています。
非共役（原子） 要件はアトミックであり、接続詞を含みません。例えば、「郵便番号フィールドはアメリカとカナダの郵便番号を検証する必要がある」という要件は、(1)「郵便番号フィールドはアメリカの郵便番号を検証する必要がある」と(2)「郵便番号フィールドはカナダの郵便番号を検証する必要がある」という2つの別々の要件として記述する必要があります。
追跡可能要件は、利害関係者によって述べられ、正式に文書化されたビジネス ニーズ全体または一部を満たします。
現在 この要件は、時間の経過によって時代遅れになっていません。
明確な要件は、専門用語、頭字語（要件文書の別の箇所で定義されていない場合）、その他の難解な表現に頼ることなく、簡潔に述べられています。主観的な意見ではなく、客観的な事実を表現しています。また、解釈は唯一無二です。曖昧な主語、形容詞、前置詞、動詞、主観的な表現は避けてください。否定的な表現や複雑な表現は避けてください。
重要度を指定する 多くの要件は、ステークホルダーが定義した特性を表しており、その特性が欠如すると重大な欠陥、あるいは致命的な欠陥につながる可能性があります。また、時間と予算が許せば実装できる機能を表す要件もあります。要件には重要度レベルを指定する必要があります。
検証可能要件の実装は、検査、デモンストレーション、テスト（計測）または分析（検証済みのモデリングとシミュレーションを含む）などの基本的な方法を通じて決定できます。

要件の品質に寄与する、考慮すべき属性は他にも数多くあります。例えば、 要件がデータ整合性のルールに従う場合、正確性／正しさ、妥当性／承認性も重要な属性です。トレーサビリティは、要件セットがニーズを満たしている（要求されている以上のものでも、それ以下のものでもない）ことを保証します。

上記に加えて、「外部から観測可能」という要件、つまり、要件は製品の特性を規定するもので、その特性は外部から観測可能、あるいはユーザーが体験できるものである、という要件を付け加える人もいます。こうした主張をする人々は、内部アーキテクチャ、設計、実装、あるいはテストに関する決定事項を規定する要件はおそらく制約であり、要件文書の「制約」セクションで明確に記述されるべきだと主張します。これとは対照的な見解は、この観点には2つの欠陥があるというものです。第一に、この観点は、ユーザーエクスペリエンスが、ユーザーが知覚できない要件によって支えられる可能性があることを認識していません。例えば、ジオコーディングされた情報をユーザーに提示するという要件は、外部のサードパーティ・ビジネスパートナーとのインターフェースに関する要件によって支えられている可能性があります。インターフェース自体はユーザーには知覚できませんが、インターフェースを通じて得られる情報の提示はユーザーには知覚できません。第二に、制約は設計の選択肢を制限するのに対し、要件は設計特性を規定します。この例を続けると、Webサービスインターフェースを選択するという要件と、シングルサインオンアーキテクチャと互換性のある方法に設計の選択肢を制限するという制約は異なります。

検証

すべての要件は検証可能である必要があります。最も一般的な方法はテストです。そうでない場合は、代わりに別の検証方法（例：分析、デモンストレーション、検査、設計レビュー）を使用する必要があります。

特定の要件は、その構造上、検証不可能です。これには、システムが特定の特性を決して示してはならない、あるいは常に示してはならないという要件が含まれます。これらの要件を適切にテストするには、無限のテストサイクルが必要になります。このような要件は、検証可能に書き直す必要があります。前述の通り、すべての要件は検証可能でなければなりません。

ソフトウェアレベルで検証できない非機能要件も、顧客の意図を示す文書として保持する必要があります。ただし、それらの要件を満たすための実際的な方法であると判断されたプロセス要件にまで遡ることができる場合があります。例えば、バックドアがないという非機能要件は、ペアプログラミングを使用するというプロセス要件に置き換えることで満たされる可能性があります。その他の非機能要件は、他のシステムコンポーネントにまで遡り、そのレベルで検証されます。例えば、システムの信頼性は、多くの場合、システムレベルでの分析によって検証されます。複雑な安全要件を持つ航空電子機器ソフトウェアは、 DO-178B開発プロセス に従う必要があります。

システムまたはソフトウェアの要件を導出するための活動。要件エンジニアリングには、プロジェクトの実現可能性調査または概念分析フェーズ、要件抽出（利害関係者のニーズの収集、理解、レビュー、および明確化）、要件分析、[ 10 ] 、分析（一貫性と完全性の確認）、仕様（要件の文書化）、検証（指定された要件が正しいことを確認する）が含まれる場合があります。[ 11 ] [ 12 ]

要件定義は、曖昧さ、不完全性、そして矛盾といった問題を抱えやすい傾向があります。厳格な検査などの手法は、これらの問題への対処に役立つことが実証されています。要件定義段階で解決できる曖昧さ、不完全性、そして矛盾は、製品開発の後期段階で同じ問題が見つかった場合と比べて、修正コストが桁違いに低くなります。要件分析は、これらの問題に対処することを目的としています。

あまりに漠然とした要件と、詳細すぎて

  • 生産に長い時間がかかり、完成すると時代遅れになることもある
  • 利用可能な実装オプションを制限する
  • 生産コストが高い

アジャイルアプローチは、要件を高レベルでベースライン化し、ジャストインタイムまたは最後の責任ある瞬間に詳細を詳述することで、これらの問題を克服する方法として進化しました。

要件の文書化

要件は通常、さまざまな利害関係者間のコミュニケーション手段として記述されます。つまり、要件は一般ユーザーと開発者の両方にとって理解しやすいものでなければなりません。要件を文書化する一般的な方法の一つは、システムが何を実行しなければならないかを明記することです。例：「請負業者は製品をxyz日までに納品しなければならない」。その他の方法としては、ユースケースやユーザーストーリーなどがあります。

要件の変更

要件は一般的に時間とともに変化します。定義・承認された要件は、変更管理の対象となります。多くのプロジェクトでは、システムが完成する前に要件が変更されます。これは、コンピュータソフトウェアの複雑さと、ユーザーが実際に目にするまで何が欲しいのかわからないという事実に一部起因しています。要件のこの特性は、要件管理の研究と実践につながっています。

問題

競合する標準

要件とは何か、そしてどのように管理・活用すべきかについては、複数の相反する見解があります。業界をリードする2つの団体はIEEEとIIBAです。両団体は、要件の定義は異なりますが、概ね共通しています。

ソフトウェア要件の必要性と効果に関する論争

多くのプロジェクトは、要件に関する合意がほとんどまたは全くない状態で成功しています。[ 13 ]さらに、要件を指定すると創造性と設計パフォーマンスが低下する可能性があることを示す証拠もあります。 [ 14 ]デザイナーは提供された情報に過度に気を取られるため、要件は創造性と設計を妨げます。[ 15 ] [ 16 ] [ 17 ]より一般的には、ソフトウェア要件は、実際の要件が明らかでない状況で設計上の決定を要件として誤って表現することによって作り出された錯覚であると示唆する研究もあります。[ 18 ]

一方、アジャイルソフトウェア開発手法の多くは、ソフトウェア要件を事前に厳密に記述する必要性に疑問を呈しています。なぜなら、要件は流動的であると考えているからです。例えばエクストリームプログラミングでは、ユーザーストーリー（システムが実行すべきことの一側面を説明する、インデックスカードに収まる短い要約）を用いて要件を非公式に記述し、顧客に直接説明を求めるのは開発者の義務だと考えています。アジャイル手法では、一連の自動化された受け入れテストを通して要件を把握しようとします。

要件の拡大

スコープクリープは、要件が時間の経過とともに変化することで発生する可能性があります。要件管理では要件の変更が許容されますが、適切に追跡されていない場合、または先行するステップ（ビジネス目標、そしてユーザー要件）が追加の監視によって抑制されなかったり、コストや潜在的なプログラム障害として扱われなかったりすると、要件変更は容易かつ発生しやすくなります。開発者が作業を完了できるよりも早く要件変更が発生し、結果として 作業が後戻りしてしまう可能性が高くなります。

複数の要件分類

要件には、どのフレームワークに基づいて作業しているかに応じて複数の分類法があります（例えば、IEEE、IIBA、米国国防総省のアプローチなどの標準規格）。場所や日常会話によって言語やプロセスが異なると、混乱が生じ、望ましいプロセスから逸脱する可能性があります。

プロセスの破損

人間が運営するプロセスは、ガバナンスにおける人間の欠陥の影響を受けやすく、都合や欲望、政治的思惑によって例外が生じたり、プロセスが意図的に破壊されたり、教科書的なプロセス進行方法から逸脱したりすることがあります。例えば、以下のようなことが挙げられます。

  • 厳密でないプロセスは尊重されません - プロセスを実行している組織に独立性や権限がほとんどなかったり、記録の信頼性や透明性が低かったりするなど、例外や変更が頻繁に発生する場合、プロセス全体が無視される可能性があります。
  • やり直しを望む新しいプレーヤー - 例: 新しい人々は、自分の力や価値の主張を誇示するために前任者の作業を変更しようとする自然な傾向があります。たとえば、新しい CEO が、すでに開発中のもの (ソフトウェア ソリューションなど) について、ビジネス目標を含む前任者の計画を変更したい場合や、新しく設立されたオフィスが、ユーザー要件の作成時には存在していなかったためプロジェクトの現在の開発に反対し、プロジェクトの後戻りとベースラインの再設定を開始する場合などです。
  • 枠にとらわれない色づけ - たとえば、より多くの制御を望むユーザーは、「ユーザー要件」または優先度レベルの要件管理定義を満たすものを入力するだけでなく、設計の詳細や好ましいベンダー特性をユーザー要件として挿入したり、自分のオフィスが可能な限りの最高優先度として述べているすべてのものを挿入します。
  • 遅刻 - 例：開発前の要件抽出にほとんど、あるいは全く努力をしない。これは、個々の参加に関わらず同じ利益が得られると考えている、あるいはテスト段階と次のスピンで要求を提示するだけでは意味がないと考えている、あるいは作業後の批評を待つことで常に正しい判断をしたいと考えているなど、様々な理由が考えられます。

米国国防総省のプロセスにおける要件問題の歴史的な例をいくつか挙げると、

  • ペンタゴンウォーズで描かれた、M-2 ブラッドリーのカジュアル要件運動の問題。
  • F-16 は戦闘機マフィアの軽量戦闘機コンセプトから発展したが、これは F-15 プログラムが競争を妨害しようとしたこと、または各省庁が軽量で低コストというコンセプトを蝕む地域的な要望を提示したことに起因する。
  • 1998 年頃の「Net-Ready」に対する熱意により、Net-Ready オフィスから主要業績指標としての役割が委譲されましたが、これは、同オフィスの定義要件プロセスの枠外で、同オフィスが以前に定義したプロセスや KPP の定義とは一致せず、一部の取り組みが「Net-Ready」を構成する要素を定義できない、あるいは不適切である可能性があるという懸念がありました。

参照

参考文献

  1. ^規格の形式とスタイル、ASTMブルーブック（PDF）。ASTMインターナショナル。2012年。 2015年11月6日時点のオリジナル（PDF）からアーカイブ。 2013年1月5日閲覧。
  2. ^ Boehm, Barry (2006). 「20世紀および21世紀のソフトウェア工学の展望」 . ICSE '06 Proceedings of the 28th international conference on Software engineering . 南カリフォルニア大学、ユニバーシティパークキャンパス、ロサンゼルス、カリフォルニア州：Association for Computing Machinery, ACM New York, NY, USA. pp.  12– 29. ISBN 1-59593-375-1. 2013年1月2日閲覧。
  3. ^ 「1.3 主要概念 - IIBA | International Institute of Business Analysis」 www.iiba.org . 2016年9月25日閲覧。
  4. ^ 「IEEE SA - 610.12-1990 - IEEE Standard Glossary of Software Engineering Terminology」 。2011年1月10日時点のオリジナルよりアーカイブ。
  5. ^ Iiba; Analysis、International Institute of Business (2009).ビジネス分析知識体系ガイド®（BABOK®ガイド）バージョン2.0 . ISBN 978-0-9811292-1-1。{{cite book}}:|first2=一般的な名前があります（ヘルプ）
  6. ^ Chen, Lianping; Ali Babar, Muhammad; Nuseibeh, Bashar (2013). 「アーキテクチャ的に重要な要件の特徴づけ」. IEEE Software . 30 (2): 38– 45. doi : 10.1109/MS.2012.174 . hdl : 10344/3061 . S2CID 17399565 . 
  7. ^ Ralph, P., Wand, Y. 設計コンセプトの正式な定義に関する提案。Lyytinen, K., Loucopoulos, P., Mylopoulos, J. , Robinson, W. (編)『設計要件エンジニアリング：10年の展望』Springer-Verlag, 2009, pp. 103-136
  8. ^ Davis, Alan M. (1993).ソフトウェア要件：オブジェクト、機能、状態、第2版. Prentice Hall. ISBN 978-0-13-805763-3。
  9. ^ IEEEコンピュータ協会 (1998).ソフトウェア要件仕様に関するIEEE推奨プラクティス. 電気電子学会. ISBN 978-0-7381-0332-7。
  10. ^ステルマン、アンドリュー、グリーン、ジェニファー (2005). 『応用ソフトウェアプロジェクトマネジメント』オライリーメディア. p. 98. ISBN 978-0-596-00948-92015年2月9日時点のオリジナルよりアーカイブ。
  11. ^ Wiegers, Karl E. (2003).ソフトウェア要件 第2版. Microsoft Press. ISBN 978-0-7356-1879-4。
  12. ^ヤング、ラルフ・R. (2001). 『効果的な要件定義の実践』 . アディソン・ウェズレー. ISBN 978-0-201-70912-4。
  13. ^チェックランド、ピーター（1999年）『システム思考とシステム実践』チチェスター：ワイリー。
  14. ^ Ralph, Paul; Mohanani, Rahul (2015年5月). 「要件エンジニアリングは本質的に逆効果か？」 .第5回国際ワークショップ「ツインピークス・オブ・要件とアーキテクチャ」議事録. フィレンツェ、イタリア: IEEE. pp.  20– 23.
  15. ^ Jansson, D.; Smith, S. (1991). 「デザインの固定」.デザイン研究. 12 (1): 3– 11. doi : 10.1016/0142-694X(91)90003-F .
  16. ^パーセル, A.; ジェロ, J. (1996). 「デザインとその他の固定の種類」.デザイン研究. 17 (4): 363– 383. doi : 10.1016/S0142-694X(96)00023-3 .
  17. ^ Mohanani, Rahul; Ralph, Paul; Shreeve, Ben (2014年5月). 「要件の固定化」 .国際ソフトウェア工学会議論文集. ハイデラバード（インド）: IEEE. pp.  895– 906.
  18. ^ Ralph, Paul (2012). 「ソフトウェア開発における要件定義の錯覚」.要件工学. 18 (3): 293– 296. arXiv : 1304.0116 . doi : 10.1007/s00766-012-0161-4 . S2CID 11499083 . 
無料辞書のウィクショナリーで要件を調べてください。
「 https://en.wikipedia.org/w/index.php?title=Requirement&oldid=1316117058」から取得