機能要件または非機能要件？

機能要件または非機能要件について疑問に思っています。これらの用語にはさまざまな定義がありますが、要件の一部を適切なカテゴリに割り当てることはできません。

たとえば、次のように、何らかのアクションに関連していない、または追加の条件がある要件について疑問に思っています。

1. 選択したデバイスのリストで、デバイスを繰り返すことができます。
2. データベースには少なくとも100個のアイテムが含まれている必要があります
3. 価値のある通貨は米ドルである必要があります。
4. デバイスには、ワット単位の名前と電力消費値が必要です。

それらの要件は機能的または非機能的ですか？

機能要件を定義するもの（具体的に、または他のシステムとユーザーとの）外部の相互作用のコンテキストで-システムまたはアプリケーションが行います。

新しい注文を出すとき、システムは総費用を表示し、ユーザーからの確認を要求します。それは機能要件です。システムの機能を説明しています。

詳細については、Wikipedia：Functional Requirementを参照してください。

非機能要件とは、システムの入出力動作を説明しない要件です。実装の詳細ではなく、まだ要件について話していることに注意してください。そのため、「非機能的」というフレーズを使用しているからといって、そのセクションに置くのが公正なゲームであることを意味しません。

表示される最も一般的な非機能要件のタイプは、システム操作（可用性、継続性、DR）、パフォーマンス（スループット、遅延、ストレージ容量）、およびセキュリティ（認証、承認、監査、プライバシー）に関連しています。

これらはすべて横断的な関心事であり、すべての「機能」に影響を及ぼしますが、実際には機能そのものではありません。それらは機能メタデータに似ており、システムが本来の目的を果たしているかどうかだけでなく、それがどれだけうまく機能しているかを説明するのにも役立ちます。ただし、その類推はあまりにも遠すぎないでください-それは単なる類推です。

非機能的な要件は主観的でも手荒いものでもありません。ここで何人かの人々が示唆しているように見えます。実際、それらには実際にハードメトリックが付加されている必要があります（100ミリ秒以下の応答時間）。NF要件は、実装の詳細や「ORMフレームワークのアップグレード」のようなタスクでもありません。誰もそのアイデアを得る手掛かりではありません。

詳細については、Wikipedia：Non-Functional Requirementをご覧ください。

質問の例を具体的に説明するには：

1. 選択したデバイスのリストで、デバイスを繰り返すことができます。

   • 明らかに機能要件。システムの出力がどのように見えるかを説明します。

2. データベースには少なくとも100個のアイテムが含まれている必要があります

   • ビジネスルールのように聞こえるので、機能要件でもあります。ただし、不完全なようです。このルールの理由は何ですか？データベースに含まれるアイテムが100未満の場合、どうなりますか？

3. 価値のある通貨は米ドルである必要があります。

   • 機能要件ですが、実際には適切に記述された要件ではありません。より有用な表現は次のとおりです。システムは1つの通貨（USD）をサポートします。 複数の通貨をサポートする必要がある場合、これは明らかに修正され、通貨換算などに関する情報を要件に含める必要があります。

4. デバイスには、ワット単位の名前と電力消費値が必要です。

   • どんな種類の要件でもありません。これは技術仕様に似ています。電力定格はワットであると想定されるため、機能要件が記載されます。複数のUOMがある場合、通貨の場合と同様に、機能要件には単位変換、それらの構成/場所などに関するセクションが必要です（該当する場合）。

Aaronaughtによる優れた回答は既にありますが、機能以外の要件についてはまったく間違っていた他の回答が削除されたため、いくつかの説明を追加して、非機能要件です。

機能以外の要件とは、「製品に必要な品質または特性」 ¹です。ジェイムス・テイラーは、非機能要件は「[...]はそれにもかかわらず要件であり、顧客にとって重要であり、機能要件よりもさらに重要である」と語っています。次に、2つの例を示します。製品のロゴと、機器の精度と信頼性です。これらの両方の例は、次のことを非常によく示しています。

• 非機能要件は、「最近はインターネットが重要であり、ウェブサイトを持ちたい」というようなマーケティング上の問題ではありません。
• 非機能要件は、生産性と製品を使用する能力自体に大きな影響を与える可能性があるため、顧客に関係します。
• 非機能要件は完全に客観的です。

最後のポイントは不可欠です。要件が主観的なものである場合、要件のリストには関係ありません。主観的なものから検証テストを構築することは不可能でしょう。要件のリストの唯一の目的は、顧客の明確な期待を列挙することです。「この正方形を赤くしたい」が必要です。「この正方形に素敵な色が欲しい」というのは説明が必要な願いです。

要件のリストは契約のようなものであることを忘れないでください（ほとんどの場合、契約の一部です）。それは顧客と開発会社によって署名され、訴訟の場合、あなたの仕事が正しく行われたかどうかを判断するために合法的に使用されます。私はあなたのソフトウェア製品を注文する場合は、「製品が大きくなければならない」ことを指定し、製品が行われている支払いを拒否、私のために、あなたが実際にやったことではありませんので、偉大な製品なのでしょうか？

それでは、いくつかの例を見てみましょう。

  1.ソフトウェア製品はエンドユーザーに応答します。

これは必須ではありません。機能的ではありません。機能していません。それは単に要件ではありません。まったく。値はゼロです。検証テスト中に、ソフトウェアシステムがこの要件を満たしているかどうかを確認することはできません。QA部門でも顧客でもありません。

  2.ユーザー統計の再読み込みは、100ミリ秒未満の時間の90％を実行します。付録Gパート2で指定されたパフォーマンスと、CPUの負荷が10％未満、メモリの負荷が50％未満、アクティブなR / Wディスク操作がないマシンでテストした場合。

これは必須です。付録Gパート2の精度が十分であれば、同様のハードウェアを搭載したマシンを使用してQA部門で検証テストを実行できます。常にバイナリの結果（合格または不合格）を取得します。

機能要件ですか？いいえ。システムが何をする必要があるかを指定しません。ソフトウェアアプリケーションがユーザー統計をリロードできる必要があることを指定する前に、おそらく機能的な要件がありました。

非機能要件ですか？そうです。これは、製品が持つ必要のあるプロパティ、つまりパーセントしきい値を指定した最大/平均応答時間を指定します。

  3.アプリケーションはC＃で記述されています。

これは要件ですか？コンテキストなしでは、本当にわかりません。この要件を挿入することにより、使用する言語について同僚と後で議論することを避けたいと考えている開発主任の願いかもしれません。また、ハードウェア/ソフトウェア、レガシーまたは互換性要素に基づいた要件である場合もあります。わかりません。

  4.製品のC＃コードベースは、Microsoft Minimum Recommended RulesおよびMicrosoft Globalization Rulesに従います。

これは奇妙なことです。個人的には、私はそれを要件と呼ぶのではなく、標準とベストプラクティスを指定する別のドキュメントに入れたいと思います。

  5.アプリケーションのメインウィンドウには、ピンク（#fcc）で塗りつぶされた青い（＃00f）10px境界線があり、これらの円は境界線の内側の端に配置され、直径が3pxで、互いに20px離れています。

これは要件であり、機能しないものです。それは私たちが検証テスト中にテストすることが何かを特定し、そしてそれは、製品のプロパティを指定しないで何の製品が行うことを意図しています。

  6.車両追跡システムは、±0.016 mphの精度で速度を測定します。

また、非機能要件。システムの精度の測定可能なしきい値を提供します。システムが何をしなければならないかはわかりませんが、その仕事をどの程度正確に行っているかを伝えます。ちょっと待って？車両追跡システムが速度を測定することを伝えますよね？それは機能要件でもありますか？いえ、測定が行われたという事実ではなく、測定の精度にアクセントを置いているからです。

  7.車両追跡システムは、車両の速度を測定します。

今では機能要件です。システムがどのように機能するかはわかりませんが、何をしているのかはわかりません。機能要件により、車両追跡システムが速度、バッテリー電力、圧力が何であるか、そしてライトが点灯しているかどうかがわからないという圧力を測定することがわかりました。

  8. Webサイトのページには850ミリ秒かかります。ロードします。

これは必須ではありません。は1つにしようとしますが、完全に無効です。これをどのように資産化しますか？どのページ？すべて？クアッドコアクライアントマシン上のローカル1Gbpsネットワークと2％で使用されるSSDを備えた8コアサーバー、またはWebサイトが99％で使用される小さなサーバーでホストされている間に古くてラップトップのモデムを介してテスト？「ロードする」とはどういう意味ですか？ページをダウンロードするということですか？ダウンロードして表示しますか？大きなデータを含むPOSTリクエストを送信し、レスポンスをロードして表示しますか？

結論するには、非機能要件は、常にそれが完全に客観的で、自動または手動の検証テストで確認することができます何かを説明し、代わりに伝えるのことを意味要件であり、どのようなシステムがやっている、それが説明どのようにシステムは何かをしているか、またはシステム自体がどうであるかです。

^{¹情報技術プロジェクトの管理：ソフトウェア、ハードウェア、統合イニシアチブへのプロジェクト管理戦略の適用、James Taylor、ISBN：0814408117。}

機能要件は、一方で、（システムは、与えられた状況で何をするか）システムとの相互作用の結果を説明し、非機能要件は、通常など、パフォーマンス、容量、応答時間の詳細を参照する...機能を表すものではない事を、Aシステム内のプロセス、または相互作用の結果。

そうは言っても、説明している非機能要件は、実際には技術仕様を持つ機能要件です（実際にはそれが悪い要件になります）。ケースの非機能要件の例は、次のようなものです。

-サイコロのアニメーションの実行中にUIをロックしないでください。

通常、ユーザー要件は特定のUI要件であり、コンテキストに応じて機能または非機能になりますが、システム要件（同時ユーザー容量など）は通常、ほとんどの場合機能しません。

いくつかの既存の良い答えに加えて、非機能要件は「ilities」と呼ばれることもあります。これは、システムがその単純な機能に加えて所有する必要がある品質です。「虚偽」には、可用性、ユーザビリティ、セキュリティ、柔軟性、さらに主観的な美学が含まれます。

これらのいくつかは、特定と評価が非常に困難です。それにもかかわらず、彼らは重要です。契約で契約している場合は、「システムは安全である必要があります」など、意味のない手で波打つバージョンを避ける必要があります。そのような要件を取り除こうとすることの問題は、人々が重要なものよりも簡単に測定可能なものに引き寄せられる傾向があることです（そして、要件は関連する専門分野に根拠のない人々によって書かれている可能性があります） ）。最終的な結果は、一般的に、安全でなく、使用可能でもなく、柔軟性のないシステムになります（可用性を指定および測定するのはそれほど難しくありませんが、それでも頭痛の種はたくさんあります）。

そこ契約や正式なものに対処する人々 、そしてより一般的な分析に対処する人々の間で、ここで文化的な違いがあり、建築、などを研究A漠然と手波状要件があり、まだ要件遠く後者などが懸念しているとして、それが表現しているため、顧客にとって重要なことは、たとえ契約の人々に完全に同情しても、それが詳細に調査され徹底的に打ち消されるまで、有用な契約上の要件ではないということです。

最後のポイント-「まだ」客観的な「 "さ」の尺度を考え出すことができない場合、それは顧客がそれを必要としないという意味ではありません。あいまい！=不要。ただし、そのようなものを測定するためのより良い方法を開発したり、非機能要件を段階的に引き出したり改良したり、すべてに対して事前の客観的な測定なしで機能できる方法（アジャイルなど）で契約する必要があることを意味する場合があります。

これらのコメントはすべて非常に優れていますが、それらは過度に調理されており、使用する明確なテンプレートを提供していません。次のように指定するのは明らかではないでしょうか？

私の意見では、機能要件は、ユーザーがアプリケーションを使用するときに経験するものです。開発者がこれをゼロから実装し、機能強化または変更を試みる場合に満たす必要がある要件です。たとえば、ユーザーはログインする必要があります。コマンドプロンプトを介してアプリケーションを実行する新しい方法も追加した場合、ユーザーはログインする必要があります。

非機能要件はボンネットの下で発生します。ユーザーはそれを認識していませんが、実装されている必要があります。例：アプリケーションはC＃で開発する必要があります。他の言語で開発されている場合、ユーザーは気付かないでしょう。ただし、既存のコードに基づいているため、これが要件になる場合があります。別の例としては、特定のサーバーにインストールする必要があります。サーバーの移動はユーザーには気付かれません。

機能的または非機能的？私はどちらとも言えません。リストされている例のすべてではないにしても、ほとんどの場合、ビジネスルールのように見えます（システムプロセスが従わなければならないプロセス関連の制約と決定ルールを指定します）。

通常、ビジネスルールはビジネス分析の一部として収集されるため（多くの場合、外部参照ではなく機能要件の仕様に埋め込まれているため）、多くのエンジニアが忘れているか、認識していません。

通常、機能要件は、システムが実行できる、または実行するものです。アクションの結果として表現できます（否定的な結果）。非機能要件とは、顧客/エンドユーザーが気にしないものであり、結果に影響を与えないもの
です。たとえば、Windowsにはピンクの点で青い境界線があります。-プログラムはJavaで作成されます
-コーディング標準、メソッド、およびプロセスに関係するもの。

ただし、非機能要件は顧客が機能要件に変更できることに注意してください。例としては、顧客が雑誌の記事を読み、Erlangで書かれることを望んでいるため、プログラムはErlangで書かれます。-プログラムはDB 2を使用する必要があります。顧客は既存のDB 2システムで実行するため、長年の経験とそのプラットフォームに精通したITチームがいるからです。
-ソースコードは、MISRAのすべての推奨事項に合格する必要があります。

要約すると、顧客がそれを気にする場合、それは機能要件です。

機能要件はシステムとその動作を説明するのに必要なものだと思いますが、非機能要件はシステムにとって必要ではなく、システム設計の交渉中に収集されないのは、速度カバレッジ品質などのシステムの結果です、構築されたシステムからのセキュリティ、保守性など。