私は CPRE Foundation Level 試験のために International Requirements Engineering Board 。試験では、ステートメントがあります:
品質要件は、機能要件の後に引き出されます。
この声明への答えは偽として提供されます。これは、機能要件の前に、または機能要件と同時に、品質要件を引き出す必要があることを意味しますか?
IREBが要件エンジニアリングをどのように教えるか、または 要件エンジニアリングについて学ぶために彼らが推奨するコンテンツ についてはよく知りません。 Karl Wiegers and Joy Beatty 、 Anthony Chen and Joy Beatty 、および Stephen Withall の作品からソフトウェア要件エンジニアリングに精通しています。要件を収集して分析する私の自身の経験に。
機能要件が満たされた後に品質要件が引き出されるという記述は知っているので、考えられる意味は2つだけです。すべての要件を同時に引き出すか、機能要件の前に品質要件を引き出す必要があります。
非機能要件または品質属性と見なされるものを見ると、一部の品質属性は特定の機能に特に関連しています。これらの例には、パフォーマンスと安定性が含まれる場合があります-特定の機能が指定された時間内に完了する必要があるか、システムが特定の負荷または特定の作業を実行しているときに測定可能な程度に応答する必要があります。その他の品質属性は、システム全体に影響を与える可能性が高くなります-災害復旧、フォールトトレランス、保守性、セキュリティ。品質属性の3番目のセットは、使用される製品とプロセスに適用されます-構成管理、エスクロー、ライセンス。
機能要件が意味をなさない前に品質要件が引き出されるという声明。最初にまたは同時に機能について話しているのでない限り、特定のパフォーマンス要件について 良い要件 になるような方法で話すのは困難です。
したがって、意図は、機能要件と同時に品質属性を利害関係者から引き出す必要があるという認識です。ただし、要件の一部の特性(完全性や一貫性など)についての議論は、機能的要件と非機能的要件のすべてを含むコンテキストで行う必要があります。
NFRは、機能要件に必要な範囲を示すため、機能の前に引き出す必要があります。
それが時間の経過とともに変化しないという意味ではありません。
逆を行うとどうなるか、実際的な例を考えてみましょう。
機能要件。ユーザーが正確なリストをオンラインでスクロールできるように、データベース内のすべてのレコードを取得します。
NFRがなければ、典型的なトランザクション時間にどの程度の負荷を与える必要があるかを示します。上記の要件は、クエリを使用して簡単に実装でき、簡単に承認できます。
次に、いくつかのNFRを追加します。
それらを組み合わせると、ソリューションの設計は単純なものから、もう少しエンジニアリングや交渉を必要とするものに劇的に変化します。
NFRを最初に持つことで、FRをプッシュバックしたり、NFRをより妥当なものに変更したりできます。
NFRは、単に目標値であるため、開発ゾーンの外でも定義および理解が容易です。