Loading article…
エンジニアリングにおいて、要件とは、作業の成果が受け入れられるために満たさなければならない条件のことです。これは、材料、設計、製品、またはサービスによって満たされるべき条件を明示的、客観的、明瞭に、そして多くの場合定量的に記述したものです。[1]
仕様またはスペックは、通常、製品開発の設計段階で開発者が使用し、検証プロセスでテスト担当者が使用する要件のセットです。
アジャイル ソフトウェア開発などの反復的かつ増分的な開発では、要件は設計および実装と並行して開発されます。ウォーターフォール モデルでは、要件は設計または実装の開始前に完了します。
要件は、エンジニアリング設計、システム エンジニアリング、ソフトウェア エンジニアリング、エンタープライズ エンジニアリング、製品開発、プロセス最適化など、多くのエンジニアリング分野で使用されます。
要件は、顧客、組織、ユーザー、またはその他の利害関係者にとって価値と有用性を持つために必要な、または望ましいシステムの機能、属性、機能、特性、品質を説明できる比較的広い概念です。
用語の由来
要件という用語は、少なくとも1960年代からソフトウェアエンジニアリングコミュニティで使用されています。[2]
IIBAのビジネス分析知識体系ガイド®バージョン2（BABOK）[3]によると、要件は次のとおりです。
- 問題を解決したり目的を達成したりするために利害関係者に必要な条件または能力。
- 契約、標準、仕様、またはその他の正式に課せられた文書を満たすために、ソリューションまたはソリューション コンポーネントが満たす必要がある、または備えている必要がある条件または機能。
- （１）または（２）のような状態または能力を文書化した表現。
この定義はIEEE 610.12-1990: IEEE標準ソフトウェアエンジニアリング用語集に基づいています。[4]
製品とプロセスの要件
要件は次の 2 つの分野に関連していると言えます。
- 製品要件は、システムまたは製品の特性を規定します。
- プロセス要件は、開発組織が実行するアクティビティを規定します。たとえば、プロセス要件では、従う必要のある方法論や、組織が従う必要のある制約を指定できます。
製品要件とプロセス要件は密接に関連しています。製品要件はプロセス要件をサポートするために必要な自動化を指定すると言える一方、プロセス要件は製品要件をサポートするために必要なアクティビティを指定すると言えるでしょう。たとえば、最大開発コスト要件 (プロセス要件) は、最大販売価格要件 (製品要件) を達成するために課される場合があります。また、製品が保守可能であるという要件 (製品要件) は、多くの場合、特定の開発スタイル (オブジェクト指向プログラミングなど)、スタイル ガイド、またはレビュー/検査プロセス (プロセス要件) に従うという要件を課すことによって対処されます。
要件の種類
要件は通常、開発の進行のさまざまな段階で生成されるタイプに分類され、分類法は使用されている全体的なモデルによって異なります。たとえば、次のスキームは、国際ビジネス分析研究所のビジネス分析知識体系[5]で考案されました ( FURPSおよび要件のタイプも参照)。
- アーキテクチャ要件
- アーキテクチャ要件は、システム構造とシステム動作の必要な統合、つまりシステムのシステム アーキテクチャを特定することによって、何を行う必要があるかを説明します。
- ソフトウェア工学では、これらはアーキテクチャ的に重要な要件と呼ばれ、ソフトウェアシステムのアーキテクチャに測定可能な影響を与える要件として定義されます 。[6]
- ユーザー（利害関係者）の要件
- 特定の利害関係者または利害関係者グループのニーズに関する中間レベルの記述。通常、意図したソリューションとどのようにやり取りしたいかを説明します。多くの場合、高レベルのビジネス要件とより詳細なソリューション要件の中間点として機能します。
- 機能（ソリューション）要件
- 通常、ソリューションに必要な機能、動作、および情報の詳細な説明です。例としては、テキストの書式設定、数値の計算、信号の変調などがあります。これらは機能と呼ばれることもあります。
- サービス品質（非機能）要件
- 通常、ソリューションが有効であり続けるための条件、ソリューションが備えていなければならない品質、またはソリューションが動作しなければならない制約を詳細に述べたものです。[7]例としては、信頼性、テスト可能性、保守性、可用性などがあります。これらは特性、制約、または能力とも呼ばれます。
- 実装（移行）要件
- 通常、機能や動作の詳細な説明は、企業の現在の状態から望ましい将来の状態への移行を可能にするためにのみ必要ですが、その後は不要になります。例としては、採用、役割の変更、教育、あるシステムから別のシステムへのデータの移行などがあります。
- 規制要件
- 法律(連邦、州、地方自治体、または地域)、契約(利用規約)、またはポリシー(会社、部門、またはプロジェクト レベル)によって定義された要件。
良い要件の特徴
優れた要件の特徴は、さまざまな著者によって様々に述べられており、各著者は一般的に、一般的な議論や特定の技術分野に最も適した特徴を強調しています。ただし、次の特徴は一般的に認められています。[8] [9]
要件の品質に寄与する、考慮すべき属性は他にもたくさんあります。要件がデータ整合性のルールに従う場合(例)、正確性/正しさと有効性/承認も価値のある属性です。 トレーサビリティは、要件セットがニーズを満たしていることを確認します (必要以上にも、必要以上にもならない)。
上記に「外部から観察可能」を追加する人もいます。つまり、要件は、外部から観察可能またはユーザーが体験できる製品の特性を指定します。このような支持者は、内部アーキテクチャ、設計、実装、またはテストの決定を指定する要件はおそらく制約であり、要件ドキュメントの制約セクションで明確に表現する必要があると主張します。対照的な見解は、この観点は 2 つの点で失敗しているというものです。まず、この観点は、ユーザー エクスペリエンスが、ユーザーが認識できない要件によってサポートされる可能性があることを認識していません。たとえば、ジオコード化された情報をユーザーに提示する要件は、外部のサード パーティ ビジネス パートナーとのインターフェイスの要件によってサポートされる場合があります。インターフェイスはユーザーには認識されませんが、インターフェイスを通じて取得された情報の提示は、ユーザーには認識されません。次に、制約は設計の選択肢を制限しますが、要件は設計の特性を指定します。この例を続けると、Web サービス インターフェイスを選択する要件は、シングル サインオン アーキテクチャと互換性のある方法に設計の選択肢を制限する制約とは異なります。
検証
すべての要件は検証可能である必要があります。最も一般的な方法はテストです。そうでない場合は、代わりに別の検証方法を使用する必要があります (例: 分析、デモンストレーション、検査、設計のレビュー)。
特定の要件は、その構造上、検証できません。これには、システムが特定の特性を示してはならない、または常に示してはならないという要件が含まれます。これらの要件を適切にテストするには、無限のテスト サイクルが必要になります。このような要件は、検証可能に書き直す必要があります。前述のように、すべての要件は検証可能でなければなりません。
ソフトウェア レベルで検証できない非機能要件は、顧客の意図のドキュメントとして保持する必要があります。ただし、それらの要件を満たす実用的な方法であると判断されたプロセス要件まで遡ることができます。たとえば、バックドアがないという非機能要件は、ペア プログラミングを使用するというプロセス要件に置き換えることで満たすことができます。その他の非機能要件は、他のシステム コンポーネントまで遡り、そのレベルで検証されます。たとえば、システムの信頼性は、多くの場合、システム レベルでの分析によって検証されます。複雑な安全要件を持つ航空電子工学ソフトウェアは、DO-178B開発プロセスに従う必要があります。
システムまたはソフトウェアの要件を導き出す活動。要件エンジニアリングには、プロジェクトの実現可能性調査または概念分析フェーズ、要件抽出（利害関係者のニーズの収集、理解、レビュー、および明確化）と要件分析、[10] 分析（一貫性と完全性の確認）、仕様（要件の文書化）、検証（指定された要件が正しいことを確認）が含まれる場合があります。[11] [12]
要件には、あいまいさ、不完全さ、矛盾といった問題がつきものです。厳密な検査などの手法は、こうした問題に対処するのに役立つことがわかっています。要件フェーズで解決できるあいまいさ、不完全さ、矛盾は、通常、製品開発の後の段階で同じ問題が見つかった場合よりも、修正にかかるコストが桁違いに低くなります。要件分析は、こうした問題に対処することを目的としています。
あまりに漠然とした要件と、詳細すぎて
- 生産に長い時間がかかり、完成すると時代遅れになることもある
- 利用可能な実装オプションを制限する
- 生産コストが高い
アジャイルアプローチは、要件を高レベルでベースライン化し、ジャストインタイムまたは最後の責任ある瞬間に基づい て詳細を詳述することで、これらの問題を克服する方法として進化しました。
要件の文書化
要件は通常、さまざまな利害関係者間のコミュニケーション手段として記述されます。つまり、要件は一般ユーザーと開発者の両方にとって理解しやすいものでなければなりません。要件を文書化する一般的な方法の 1 つは、システムが実行する必要があることを記述することです。例: 「請負業者は、製品を xyz 日までには納品する必要があります。」その他の方法には、ユース ケースやユーザー ストーリーなどがあります。
要件の変更
要件は一般に時間とともに変化します。要件は定義され承認されると、変更管理の対象となります。多くのプロジェクトでは、システムが完成する前に要件が変更されます。これは、コンピュータ ソフトウェアの複雑さと、ユーザーが実際に見るまで何が欲しいのかわからないという事実に一部起因しています。要件のこの特性により、要件管理の研究と実践が行われました。
問題
競合する標準
要件とは何か、またそれをどのように管理し、使用するかについては、いくつかの相反する見解があります。業界をリードする 2 つの団体は、IEEE と IIBA です。これらのグループはどちらも、要件の定義が異なりますが、類似しています。
ソフトウェア要件の必要性と効果に関する論争
多くのプロジェクトは、要件に関する合意がほとんどまたは全くない状態で成功しています。[13]さらに、要件を指定すると創造性と設計パフォーマンスが低下する可能性があることを示す証拠もあります。 [14]要件は創造性と設計を妨げます。なぜなら、設計者は提供された情報に過度に気を取られてしまうからです。[15] [16] [17]より一般的には、ソフトウェア要件は、実際の要件が明らかでない状況で設計上の決定を要件として誤って表現することによって生み出された幻想であると示唆する研究もあります。 [18]
一方、ほとんどのアジャイル ソフトウェア開発方法論では、ソフトウェア要件を事前に厳密に記述する必要性に疑問を呈しています。ソフトウェア要件は変化する目標であると考えているからです。代わりに、たとえばエクストリーム プログラミングでは、ユーザー ストーリー(システムが実行すべきことの 1 つの側面を説明する、インデックス カードに収まる短い要約) を使用して要件を非公式に記述し、顧客に直接説明を求めるのは開発者の義務であると考えています。アジャイル方法論では、一連の自動化された受け入れテストで要件を把握しようとします。
要件の拡大
スコープ クリープは、要件が時間の経過とともに変化することで発生する可能性があります。要件管理では、要件の変更が許可されていますが、適切に追跡されなかったり、先行する手順 (ビジネス目標、次にユーザー要件) が追加の監視によって抑制されなかったり、コストや潜在的なプログラム障害として処理されなかったりすると、要件の変更は簡単に発生してしまいます。開発者が作業を行うよりも早く要件の変更が発生し、その結果、 作業が後戻りしやすくなります。
複数の要件分類
要件には、どのフレームワークに基づいて作業しているかに応じて複数の分類法があります。(たとえば、IEEE の規定標準、IIBA の規定標準、または米国国防総省のアプローチ) 場所や日常会話によって言語やプロセスが異なると、混乱が生じ、望ましいプロセスから逸脱する可能性があります。
プロセスの破損
人間が実行するプロセスは、ガバナンスにおける人間の欠陥の影響を受けやすく、利便性や欲求、政治によってプロセスの例外や完全な破壊、プロセスの進行方法の教科書的な方法からの逸脱が生じる可能性があります。例:
- 厳密でないプロセスは尊重されません - プロセスを実行する組織に独立性や権限がほとんどなかったり、記録が信頼できず透明性がなかったりするなど、例外や変更が頻繁に発生する場合、プロセス全体が無視される可能性があります。
- やり直しを望む新しいプレーヤー - たとえば、新しい CEO が、すでに開発中のもの (ソフトウェア ソリューションなど) について、ビジネス目標を含む前 CEO の計画を変更したい場合や、新しく設立されたオフィスが、ユーザー要件の作成時には存在していなかったためプロジェクトの現在の開発に反対し、プロジェクトを後戻りしてベースラインを再設定する取り組みを開始する場合など、新しい人々が自分の力や価値の主張を示すために前任者の作業を変更しようとするのは自然な傾向です。
- 枠にとらわれない色付け - たとえば、より多くの制御を望むユーザーは、要件管理の「ユーザー要件」または優先度レベルの定義を満たすものを入力するだけでなく、設計の詳細や優先ベンダーの特性をユーザー要件として挿入したり、自分のオフィスが最高の優先度として言うすべてのことを挿入したりします。
- 遅刻する - たとえば、開発前の要件抽出にほとんどまたはまったく努力をしない。これは、個人の参加に関係なく同じメリットが得られると考えているか、テスト段階と次のスピンで要求を挿入するだけでは意味がないと考えているか、作業後の批評を待って常に正しいことを優先しているためである可能性があります。
米国国防総省のプロセスにおける要件問題の歴史的な例をいくつか挙げると、
- ペンタゴンウォーズで描かれたM-2ブラッドリーのカジュアル要件運動の問題。
- F-16 は、戦闘機マフィアの軽量戦闘機コンセプトから発展したもので、競争を妨害しようとする F-15 プログラムや、軽量で低コストというコンセプトを損なうローカルな要望を掲げる個々の機関によるものとされています。
- 1998 年頃の「Net-Ready」に対する熱意により、Net-Ready オフィスから主要業績評価パラメータとして任命されましたが、これは、オフィスの要件定義プロセスの範囲外で、そのオフィスが以前に定義したプロセスや KPP の定義と一致しておらず、一部の取り組みが「Net-Ready」を構成する要素を定義できないか不適切である可能性があるという問題がありました。
参照
- ビジネス要件
- ソフトウェア要件
- 要件エンジニアリング
- 要件分析
- 要件抽出
- 要件管理
- 要件の優先順位付け
- 要件のトレーサビリティ
- 仕様（技術基準）
- Shall と will の言い回し
- MoSCoWメソッド- 優先順位付け手法
- ユーザーストーリー
- 使用事例
参考文献
- ^ 規格の形式とスタイル、ASTMブルーブック（PDF）。ASTMインターナショナル。2012年。 2013年1月5日閲覧。
- ^ Boehm, Barry (2006)。「20世紀および21世紀のソフトウェアエンジニアリングの展望」。ICSE '06 第28回国際ソフトウェアエンジニアリング会議議事録。南カリフォルニア大学、ユニバーシティパークキャンパス、ロサンゼルス、カリフォルニア州：Association for Computing Machinery、ACM ニューヨーク、ニューヨーク州、米国。pp. 12–29。ISBN 1-59593-375-1. 2013年1月2日閲覧。
- ^ 「1.3 主要概念 - IIBA | International Institute of Business Analysis」www.iiba.org 。 2016年9月25日閲覧。
- ^ 「IEEE SA - 610.12-1990 - IEEE 標準ソフトウェア エンジニアリング用語集」。2011 年 1 月 10 日時点のオリジナルよりアーカイブ。
- ^ Iiba; Analysis、International Institute of Business (2009)。ビジネス分析知識体系ガイド® (BABOK® ガイド) バージョン2.0。ISBN 978-0-9811292-1-1。
{{cite book}}:|first2=一般的な名前があります (ヘルプ) - ^ Chen, Lianping; Ali Babar, Muhammad; Nuseibeh, Bashar (2013). 「アーキテクチャ上重要な要件の特徴づけ」. IEEE ソフトウェア. 30 (2): 38–45. doi :10.1109/MS.2012.174. hdl : 10344/3061 . S2CID 17399565.
- ^ Ralph, P.、Wand, Y. 設計コンセプトの正式な定義の提案。Lyytinen, K.、Loucopoulos, P.、Mylopoulos, J.、Robinson, W. (編)、『設計要件エンジニアリング: 10 年の展望』、Springer-Verlag、2009 年、103-136 ページ
- ^ Davis, Alan M. (1993). ソフトウェア要件: オブジェクト、機能、および状態、第 2 版。Prentice Hall。ISBN 978-0-13-805763-3。
- ^ IEEE コンピュータ協会 (1998)。IEEEソフトウェア要件仕様の推奨プラクティス。米国電気電子技術者協会。ISBN 978-0-7381-0332-7。
- ^ ステルマン、アンドリュー、グリーン、ジェニファー (2005)。応用ソフトウェアプロジェクト管理。オライリーメディア。p. 98。ISBN 978-0-596-00948-92015年2月9日時点のオリジナルよりアーカイブ。
- ^ Wiegers, Karl E. (2003).ソフトウェア要件、第 2 版。Microsoft Press。ISBN 978-0-7356-1879-4。
- ^ ヤング、ラルフ R. (2001)。効果的な要件管理の実践。アディソン・ウェズリー。ISBN 978-0-201-70912-4。
- ^ チェックランド、ピーター（1999）。システム思考、システム実践。チチェスター：ワイリー。
- ^ Ralph, Paul; Mohanani, Rahul (2015 年 5 月)。「要件エンジニアリングは本質的に逆効果か?」。要件とアーキテクチャのツインピークスに関する第 5 回国際ワークショップの議事録。イタリア、フィレンツェ: IEEE。pp. 20–23。
- ^ Jansson, D.; Smith, S. (1991). 「デザインの固定」.デザイン研究. 12 (1): 3–11. doi :10.1016/0142-694X(91)90003-F.
- ^ パーセル、A.; ジェロ、J. (1996). 「デザインとその他の固定の種類」.デザイン研究. 17 (4): 363–383. doi :10.1016/S0142-694X(96)00023-3.
- ^ Mohanani, Rahul; Ralph, Paul; Shreeve, Ben (2014 年 5 月)。「要件の固定」。国際ソフトウェア エンジニアリング会議の議事録。インド、ハイデラバード: IEEE。pp. 895–906。
- ^ Ralph, Paul (2012). 「ソフトウェア開発における要件の幻想」.要件エンジニアリング. 18 (3): 293–296. arXiv : 1304.0116 . doi :10.1007/s00766-012-0161-4. S2CID 11499083.
外部リンク
無料辞書のウィクショナリーで要件を調べてください。
- システム要件の把握