機能要件と非機能要件を区別する必要があるのはなぜですか？

この2つの違いを理解していますが、同僚から、要件を機能的または非機能的（または移行的）としてラベル付けすることの利点について疑問に思います。なぜそうするのですか？彼は、あるプロジェクトの要件のリストを2日間調べたが、最終結果は「すべてをやる」という命令で別のビジネスエンティティにドキュメントを提出することだったため、彼が言ったことを費やしました。

私が恐れているのは、要件が1つのドキュメントにまとめられていることです。実用的な用語でメリットを説明しようとしましたが、売れませんでした。機能している要件と機能していない要件を文書化する利点を販売するにはどうすればよいですか。

要件を明確に分離することで、適切なシステムを設計しやすくなります。

非機能要件（概念/用語の品質属性が望ましい-機能対非機能を超える新しい洞察を提供する必要があります）では、機能よりもソフトウェアのプロパティに関心があります。つまりどのように、システムはいくつかの機能を実行していないだけで何のシステムはありません。品質要件はシステムのアーキテクチャに重要な影響を与えますが、機能要件はそうではないため、異なる理由で処理する必要があります。

品質属性を機能要件とは別に保つことにより、さまざまな種類の要件をさまざまな方法で分析、指定、および優先順位付けすることができます。たとえば、通常、品質属性は品質属性シナリオを使用して指定されますが、機能要件はストーリー、ユースケース、shallステートメント、またはその他の形式の形式を取ります。私が取り組んだシステムのほとんどは、12個未満の品質属性と、さらに多くの機能要件を備えていました。

実際に、別の種類の要件- 技術的制約を紹介します。繰り返しますが、これらの3つのバケットに要件を明示的に分けることにより、システム構築中に適切なトレードオフを行う方法の手がかりが得られます。多くの場合、機能要件はかなり交渉可能であり、品質の属性はアーキテクチャと選択する構造に大きく影響し、技術的な制約は交渉不可能です。

これが私のチームである場合、アーキテクチャで重要なものを見逃さないようにするために、タイプごとに要件に明確に注釈を付ける必要があることを伝えます。機能だけでなく、アーキテクチャのドライバーについても考えてください。

ソフトウェア集中システムの設計の Anthony Lattanze ：プラクティショナーズガイドでは、アーキテクチャドライバーの実際の概要と、なぜ異なる扱いが必要なのかを説明します。

すべての要件の優先度/重みが等しい場合（特に「必須」）、おそらく機能要件と非機能要件を分割するだけでなく、心配する必要があります。

それでも、2つのカテゴリの要件を分離する理由はいくつかあります。

実装の責任 多くの非機能要件、特にパフォーマンスに焦点を当てた要件は、開発者に適度にしか適用できないことがわかりました。設計は拡張性と速度をサポートできますが（特定のコードセクションを調整できます）、一般にパフォーマンス要件を満たすことができるかどうかは、アーキテクチャに依存し、多くの場合、ハードウェア構成に依存します。

テストの責任 ユーザー、QAチームは、セキュリティ、フォールトトレランス、安全性、および信頼性の要件が満たされているかどうかを十分に検証していますか？

繰り返さないでください ドキュメントは、コードと同じDRY原則に従う必要があります。一般的なUIスタイルの要件はグループ化する必要があります。要件の責任者が本当に望んでいる場合、機能要件で非機能要件を（個別にまたはグループとして）参照できます。

バージョン管理 多くの「標準」がある企業環境にいる場合-特定のUIまたはセキュリティ（いくつか例を挙げれば）要件ドキュメントを作成して、バージョン管理することができます。そうすれば、アプリケーション固有の要件（主に機能要件）を記述できます：「アプリケーションは、XYZ-Company-SecReq-​​DocumnentNamingStandard.docxで定義されたセキュリティ要件のV2.3に準拠する必要があります」。

機能要件と非機能要件を区別する必要があるのはなぜですか？

差別化の1つの理由は、2つのタイプ間の抽象化のレベルです。非機能要件はシステムレベルにあり、システム全体の動作方法を示します。機能要件とは、特定の機能と、クライアントに提供する必要がある機能を指します。

非機能要件もシステムを制約しますが、機能要件はシステムが何をする必要があるかを示します。非機能要件は、機能要件をどのように設計および実装するかについての制限を提供します。それらを分離することにより、制約と制限から機能を明確に識別することが可能になります。

私が恐れているのは、要件が1つのドキュメントにまとめられていることです。実用的な用語でメリットを説明しようとしましたが、売れませんでした。機能している要件と機能していない要件を文書化する利点を販売するにはどうすればよいですか。

私の経験では、機能要件と非機能要件は実際には同じドキュメントにグループ化されるか、同じシステムで追跡されます。ただし、ドキュメントには独自の個別のセクションと、各セクションを満たすための成功基準が与えられます。

一般的に、要件を分類して、チームがそれらに対応できるようにします。アーキテクチャ上のニーズを特に対象とする要件がある場合、それを「アーキテクチャ」要件と呼ぶと、アーキテクチャで作業するときにチームが役立つはずです。

すべての要件の大きな単一のドキュメントは必ずしも悪いことではありません...それをレビューするのに2日間を費やすことも悪くありません。通常、問題は、1人のユーザーが要件を確認すると、それらを理解しますが、他のユーザーが同じことを行うのは簡単ではないということです。プロジェクトに参加する他の人々を支援するメタデータで要件のラベル付けを開始することは大きな助けになります。

抽象化の問題として説明しようとするかもしれません。レガシーコードベースで作業する必要がある場合は、既存のすべてのコード行を読んで作業を開始するだけではありません。あなたはあなたを助けるためにコードの構造に従います。要件に何らかの構造があると、同じように役立ちます。

分離には複数の利点があります。

1. テストの時間を節約します（つまり、機能要件のみをテストします）
2. 要件に対する将来の変更の時間を節約します（つまり、非機能要件はレビュー/承認/実装/テストにかかる時間が短縮されます）
3. 規制された（FDAなど）世界では、非機能要件には、機能要件に必要な事務処理量の1/10が必要です。
4. チームに、シニア（機能）チームメンバーとジュニア（非機能）チームメンバーの間で作業を分割する機能を提供します。

続けられた...

表面的には2日間は長い時間のように思えますが、長期的には数週間または数か月の将来の作業を節約できます。