要件

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

製品開発およびプロセス最適化では要件は、特定の設計、製品、またはプロセスが満たすことを目的とする、文書化された単一の物理的または機能的ニーズです。これは、システムエンジニアリングソフトウェアエンジニアリングエンタープライズエンジニアリングなど、エンジニアリング設計で正式な意味で一般的に使用されます。これは、システムが顧客、組織、内部ユーザー、またはその他の利害関係者にとって価値と有用性を持つために必要な(または場合によっては望ましい)機能、属性、機能、特性、または品質について話すことができる広い概念です。要件には、さまざまなレベルの特異性が伴う場合があります。たとえば、要件仕様または要件「仕様」(多くの場合、「the」仕様/仕様と不正確に呼ばれますが、実際にはさまざまな種類の仕様があります)は、明示的で非常に客観的/明確な(そして多くの場合定量的な)要件(または場合によっては、一連の要件)が材料、設計、製品、またはサービスによって満たされる必要があります。[1]

一連の要件は、製品開発の設計段階への入力として使用されます。テストは特定の要件にまでさかのぼる必要があるため、要件も検証プロセスへの重要な入力です。要件は、特定のプロジェクトに必要な要素と機能を示しています。ソフトウェア開発の反復法またはアジャイル法を使用する場合 、システム要件は設計と実装と並行して段階的に開発されます。ウォーターフォールモデルでは、設計と実装の前に要件が作成されます。

用語の由来

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

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

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

この定義は、IEEE 610.12-1990:IEEE Standard Glossary of Software EngineeringTerminologyに基づいています。[4]

製品とプロセスの要件

要件は、次の2つのフィールドに関連していると言えます。

  • 製品要件は、システムまたは製品のプロパティを規定します。
  • プロセス要件は、開発組織によって実行されるアクティビティを規定します。たとえば、プロセス要件では、従う必要のある方法論や、組織が従わなければならない制約を指定できます。

製品とプロセスの要件は密接に関連しています。製品要件は、プロセス要件をサポートするために必要な自動化を指定すると言うことができ、プロセス要件は、製品要件をサポートするために必要なアクティビティを指定すると言うことができます。たとえば、最大販売価格要件(製品要件)を達成するために、最大開発コスト要件(プロセス要件)を課すことができます。製品が保守可能であるという要件(製品要件)は、特定の開発スタイル(オブジェクト指向プログラミングなど)、スタイルガイド、またはレビュー/検査プロセス(プロセス要件)に従うための要件を課すことによって対処されることがよくあります。

要件の種類

要件は通常、開発の進行のさまざまな段階で生成されるタイプに分類され、使用されているモデル全体に​​応じて分類法が異なります。たとえば、次のスキームは、International Institute of BusinessAnalysisのBusinessAnalysis Body of Knowledge [5]で考案されました( FURPSおよび要件のタイプも参照)。

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

良い要件の特徴

優れた要件の特徴は、さまざまなライターによってさまざまに述べられており、各ライターは一般に、一般的な議論または対処されている特定のテクノロジードメインに最も適した特性を強調しています。ただし、以下の特徴が一般的に認められています。[8] [9]

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

要件の品質に寄与する考慮すべき属性は他にもたくさんあります。要件がデータ整合性のルールに従う場合(たとえば)、正確性/正確性および有効性/承認も価値のある属性です。 トレーサビリティは、要件セットがニーズを満たしていることを確認します(必要なもの以上およびそれ以上)。

上記に、外部で観察可能なものを追加します。つまり、要件は、ユーザーが外部で観察可能または経験する製品の特性を指定します。このような支持者は、内部アーキテクチャ、設計、実装、またはテストの決定を指定する要件はおそらく制約であり、要件ドキュメントの「制約」セクションで明確に説明する必要があると主張しています。対照的な見方は、この視点は2つの点で失敗するということです。まず、パースペクティブは、ユーザーエクスペリエンスが、ユーザーが認識できない要件によってサポートされている可能性があることを認識していません。たとえば、ジオコーディングされたものを提示するための要件ユーザーへの情報は、外部のサードパーティビジネスパートナーとのインターフェイスの要件によってサポートされる場合があります。インターフェイスを介して取得した情報の表示は確かにそうではありませんが、インターフェイスはユーザーには認識できません。第二に、制約は設計の選択肢を制限しますが、要件は設計の特性を指定します。例を続けると、Webサービスインターフェイスを選択する要件は、シングルサインオンアーキテクチャと互換性のあるメソッドの代替設計を制限する制約とは異なります。

検証

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

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

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

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

要件は、あいまいさ、不完全性、および不整合の問題を起こしやすいです。厳密な検査などの手法は、これらの問題に対処するのに役立つことが示されています。要件フェーズで解決できるあいまいさ、不完全性、および不整合は、通常、これらの同じ問題が製品開発の後の段階で見つかった場合よりも、修正にかかるコストが桁違いに少なくなります。要件分析は、これらの問題に対処するよう努めています。

あいまいすぎる要件と、非常に詳細な要件との間で考慮すべきエンジニアリング上のトレードオフがあります。

  1. 制作には長い時間がかかります-完成すると時代遅れになることもあります
  2. 利用可能な実装オプションを制限する
  3. 生産に費用がかかる

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

要件の文書化

要件は通常、さまざまな利害関係者間のコミュニケーション手段として作成されます。これは、要件が通常のユーザーと開発者の両方にとって理解しやすいものでなければならないことを意味します。要件を文書化する一般的な方法の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」は、要件プロセスを定義するオフィスの外で、そのオフィスの以前に定義されたプロセス、KPPとは何かの定義、またはいくつかの取り組みと一致しない、Net-Readyオフィスからの主要なパフォーマンスパラメータとしての義務につながりました。 「Net-Ready」を構成するものを定義するのは適切でないか、定義できない可能性があります。

も参照してください

参考文献

  1. ^ 規格の形式とスタイル、ASTMブルーブック (PDF)ASTMインターナショナル2012 2013年1月5日取得
  2. ^ ベーム、バリー(2006)。「20世紀と21世紀のソフトウェア工学の展望」ICSE'06ソフトウェア工学に関する第28回国際会議の議事録南カリフォルニア大学、ユニバーシティパークキャンパス、ロサンゼルス、カリフォルニア州:Association for Computing Machinery、ACMニューヨーク、ニューヨーク、米国。pp。12–29。ISBN 1-59593-375-12013年1月2日取得
  3. ^ 「1.3重要な概念-IIBA |国際ビジネス分析研究所」www.iiba.org 2016年9月25日取得
  4. ^ 「IEEESA-610.12-1990-ソフトウェアエンジニアリング用語のIEEE標準用語集」
  5. ^ 飯葉; 分析、国際ビジネス研究所(2009)。ビジネスアナリシス知識体系ガイド(BABOK®ガイド)バージョン2.0ISBN 978-0-9811292-1-1
  6. ^ チェン、リアンピン; アリババール、ムハンマド; Nuseibeh、Bashar(2013)。「アーキテクチャ的に重要な要件の特徴づけ」。IEEEソフトウェア30(2):38–45。土井10.1109 /MS.2012.174hdl10344/3061S2CID17399565_ 
  7. ^ Ralph、P。、およびWand、Y。デザインコンセプトの正式な定義の提案。In、Lyytinen、K.、Loucopoulos、P.、 Mylopoulos、J.、and Robinson、W。、(eds。)、Design Requirements Engineering:A Ten-Year Perspective:Springer-Verlag、2009、pp.103-136
  8. ^ Davis、Alan M.(1993)。ソフトウェア要件:オブジェクト、機能、および状態、第2版プレンティスホール。ISBN 978-0-13-805763-3
  9. ^ IEEE Computer Society(1998)。ソフトウェア要件仕様に関するIEEE推奨プラクティス米国電気電子学会ISBN 978-0-7381-0332-7
  10. ^ ステルマン、アンドリュー; グリーン、ジェニファー(2005)。応用ソフトウェアプロジェクト管理オライリーメディア。p。98. ISBN 978-0-596-00948-92015-02-09にオリジナルからアーカイブされました。
  11. ^ Wiegers、Karl E.(2003)。ソフトウェア要件、第2版MicrosoftPress。ISBN 978-0-7356-1879-4
  12. ^ ヤング、ラルフR.(2001)。効果的な要件の実践アディソン-ウェスリー。ISBN 978-0-201-70912-4
  13. ^ チェックランド、ピーター(1999)。システム思考、システム実践チチェスター:ワイリー。
  14. ^ ラルフ、ポール; モハナニ、ラフル(2015年5月)。「要求工学は本質的に逆効果ですか?」要件とアーキテクチャのツインピークに関する第5回国際ワークショップの議事録イタリア、フィレンツェ:IEEE。pp。20–23。
  15. ^ Jansson、D。; スミス、S。(1991)。「デザインの固定」。デザイン研究12(1):3–11。土井10.1016 / 0142-694X(91)90003-F
  16. ^ パーセル、A。; 下呂、J。(1996)。「デザインおよび他のタイプの固定」。デザイン研究17(4):363–383。土井10.1016 / S0142-694X(96)00023-3
  17. ^ モハナニ、ラフル; ラルフ、ポール; シュリーブ、ベン(2014年5月)。「要件の修正」ソフトウェア工学に関する国際会議の議事録インド、ハイデラバード:IEEE。pp。895–906。
  18. ^ ラルフ、ポール(2012)。「ソフトウェア開発における要件の錯覚」。要件エンジニアリング18(3):293–296。arXiv1304.0116土井10.1007 / s00766-012-0161-4S2CID11499083_ 

外部リンク