機能的または非機能的要件？
機能要件または非機能要件について疑問に思っています。これらの用語のさまざまな定義がたくさん見つかったので、要件の一部を適切なカテゴリに割り当てることができません。
いくつかのアクションに関連付けられていない、またはいくつかの追加の条件がある要件について疑問に思っています。次に例を示します。
- 選択したデバイスのリストで、デバイスを繰り返すことができます。
- データベースには少なくとも100項目が含まれている必要があります
- ある価値の通貨は米ドルである必要があります。
- デバイスには、名前とワット数の電力消費値が必要です。
これらの要件は機能しているか、機能していないか？
機能要件は、システムまたはアプリケーションが実行するwhatを定義します-特に外部との対話（ユーザーとの、または別のシステムとの）のコンテキストで。
新しい注文を出すとき、システムは合計費用を表示し、ユーザーからの確認を必要とします。これは機能要件です。システムのfunctionを記述します。
詳細は Wikipedia：Functional Requirement を参照してください。
非機能要件とは、システムの入力/出力動作をしないで記述する要件です。 「implementation details」ではなく、「requirements」について話していることに注意してください。「非機能」というフレーズを使用しているからといって、anythingは、そのセクションに入れるのに適したゲームです。
表示される最も一般的なタイプの非機能要件は、システム操作（可用性、継続性、DR）、パフォーマンス（スループット、待ち時間、ストレージ容量）、およびセキュリティ（認証、承認、監査、プライバシー）に関連しています。
これらはすべて、すべての「機能」に影響を与える分野横断的な懸念事項ですが、実際には機能そのものではありません。これらは機能メタデータに似ており、システムがwhetherで想定されていることを実行するだけでなく、howellでも実行できることを説明するのに役立ちます。ただし、その類推を過度に行わないでください。これは単なる類推です。
非機能的な要件はない主観的または手作業によるものであり、ここで一部の人々が示唆しているように思われます。実際、shouldには、実際にはハードメトリックが付加されています（つまり、応答時間が100ミリ秒以下）。 NF要件もない実装の詳細や「ORMフレームワークのアップグレード」などのタスク-誰もがそのアイデアを得る手掛かりはありません。
詳細は Wikipedia：Non-Functional Requirement にあります。
質問の例に具体的に対処するには：
選択したデバイスのリストで、デバイスを繰り返すことができます。
- 明らかに機能要件です。システムの出力がどのように見えるかを説明します。
データベースには少なくとも100のアイテムが含まれている必要があります
- ビジネスルールのように聞こえるので、機能要件も必要です。ただし、不完全なようです。このルールの理由は何ですか？データベースに含まれるアイテムが100未満の場合、どうなりますか？
ある価値の通貨は米ドルである必要があります。
- 機能要件ですが、実際には正しく記載されていません。システムは1つの通貨（USD）をサポートする必要があります。複数の通貨をサポートする必要がある場合、これは修正され、要件に情報を含める必要があります。通貨換算などについて。
デバイスには、名前と消費電力値（ワット）が必要です。
- 実際にはどのような要件でもありません。これは技術仕様に似ています。機能要件はとして示されます。電力定格はワットであると想定されます。複数のUOMがある場合、通貨と同様に、機能要件には単位変換に関するセクションが必要です。 /それらがどのように構成されているかなど（該当する場合）。
Aaronaughtによる優れた回答は既にありますが、機能以外の要件がまったく間違っている他の回答が削除されたため、いくつかの説明を追加して、非機能要件です。
非機能要件は"製品に必要な品質または特性" isです。 James Taylorは、非機能要件"[...]は[それにもかかわらず]要件であり、顧客にとって重要であり、場合によっては機能要件よりもさらに重要であると述べています"。次に、2つの例を挙げます。製品のロゴ、および機器の正確さと信頼性です。これらの両方の例は、次のことを非常によく示しています。
- 非機能的な要件は、「今日のインターネットは重要であり、私たちはウェブサイトを持ちたい」のようなマーケティングジバージャバーではありません。
- 非機能要件は、生産性と製品を使用する能力自体に大きな影響を与える可能性があるため、顧客に関係しています。
- 非機能要件は完全に客観的です。
最後のポイントは不可欠です。要件が主観的である場合、要件のリストでは何もする必要はありません。 主観的なものから検証テストを構築することは不可能です。要件のリストの唯一の目的は、顧客の明確な期待を列挙することです。 「この四角を赤くしたい」は必須です。 「この四角にいい色をつけたい」は説明が必要な願いです。
要件のリストは契約のようなものであることに注意してください（ほとんどの場合、契約の一部です）。これは顧客と開発会社によって署名され、訴訟の場合は、あなたが正しく作業を行ったかどうかを判断するために合法的に使用されます。ソフトウェア製品を注文し、「製品は素晴らしいものでなければならない」と明記し、製品が完成したら支払いを拒否します。私にとって、実際に行ったことはgreatではないためです。製品？
それでは、いくつかの例を見てみましょう。
1.ソフトウェア製品はエンドユーザーに応答します。
これは必須ではありません。機能的ではありません。非機能的ではありません。 それは単なる要件ではありません。まったく。値はゼロです。検証テスト中に、ソフトウェアシステムがこの要件を満たしているかどうかを確認することはできません。あなたも、QA部門も、顧客も。
2. 2.付録Gパート2で指定されたパフォーマンスとCPUの負荷が10％未満、メモリの負荷が50％未満のマシンでテストした場合、ユーザー統計のリロードは100 ms未満の時間の90％を実行します。アクティブなR/Wディスク操作はありません。
それは要件です。付録Gパート2が十分に正確である場合、同様のハードウェアを備えたマシンを使用してQA部門で検証テストを実行できます。成功または失敗のバイナリ結果が常に得られます。
機能要件ですか？いいえ。システムが実行する必要があるwhatは指定されていません。以前はおそらく機能要件があり、ソフトウェアアプリケーションがユーザー統計を再ロードできる必要があることを指定していました。
非機能要件ですか？そうです。パーセンテージしきい値を指定して、製品に必要な特性、つまり最大/平均応答時間を指定します。
.アプリケーションはC＃で記述されています。
これは要件ですか？コンテキストがないとわかりません。この要件を挿入することで、後で使用する言語について同僚と話し合うことを避けたいという主な開発者の希望かもしれません。また、ハードウェア/ソフトウェア、レガシー要素または互換性要素に基づく要件である場合もあります。わかりません。
4.製品のC＃コードベースは、Microsoft最小推奨ルールおよびMicrosoftグローバリゼーションルールに従います。
これは奇妙なことです。個人的には、これを要件と呼ぶのではなく、標準とベストプラクティスを指定する別のドキュメントに入れます。
5.アプリケーションのメインウィンドウには、ピンク（#fcc）の塗りつぶされた円が付いた青色（＃00f）の10ピクセルの境界線があり、これらの円は境界線の内側の端に配置され、直径が3ピクセルで、20ピクセル離れています。お互いから。
これは要件であり、機能しないものです。これは、検証テスト中にテストする可能性のあるものを指定し、-whatではなく製品のプロパティを指定して、製品が実行することを意図しています。
6.車両追跡システムは、±0.016 mphの精度で速度を測定します。
また、機能以外の要件。これは、システムの精度の測定可能なしきい値を提供します。システムが何をしなければならないかはわかりませんが、システムがどの程度正確に機能しているかを示します。ちょっと待って？これは、車両追跡システムmeasures速度であることを示していますね。だから、それも機能要件ですか？ええ、いいえ、測定が行われたという事実ではなく、測定の精度に重点を置いているためです。
7.車両追跡システムが車両の速度を測定します。
これは機能要件です。システムの動作はわかりませんが、システムの動作はわかります。機能要件を通じて、車両追跡システムが速度、バッテリー電源、私が何をしているのか、そしてライトが点灯しているかどうかがわからないという圧力を測定していることがわかりました。
8。Webサイトのページの読み込みには850ミリ秒かかります。
これは必須ではありません。は1になろうとしますが、完全に無効です。これをどのように活用しますか？どのページ？すべて？クアッドコアクライアントマシンのローカル1GbpsネットワークとSSDが2％で使用されている8コアサーバーを通じて、またはWebサイトが99％で使用されている小さなサーバーによってホストされている間に古くて壊れやすいラップトップのモデムを通じてテスト？ 「ロードする」とはどういう意味ですか？それはページをダウンロードすることを意味しますか？ダウンロードして表示しますか？大きなデータを含むPOSTリクエストを送信してから、レスポンスをロードして表示しますか？
結論として、非機能要件は常に要件です。つまり、それは完全に客観的であり、自動または手動の検証テストで確認できるものを記述しますが、whatシステムの動作またはシステム自体の動作について説明します。
¹情報技術プロジェクトの管理：ソフトウェア、ハードウェア、および統合イニシアチブへのプロジェクト管理戦略の適用、James Taylor、ISBN：0814408117。
機能要件は、システムとの相互作用の結果（システムが特定の状況で行うこと）を示し、非機能要件は通常、パフォーマンス、容量、応答の詳細を示します時間など、機能、システム内のプロセス、または相互作用の結果を表していないもの。
そうは言っても、あなたが説明している非機能要件は、実際には技術仕様を備えた機能要件です（これは実際には悪い要件になります）。ケースの非機能要件の例は、次のようなものです。
-サイコロのアニメーションの実行中は、UIをロックしないでください。
ユーザー要件は通常、特定のUI要件であり、コンテキストに応じて機能的または非機能的ですが、システム要件（たとえば、同時ユーザー容量）は通常ほとんどの時間は機能しません。
非機能要件が「不潔」と呼ばれることもあるという既存の良い答えに追加するために、システムがその単純な機能に加えて持つ必要がある品質。 「問題」には、可用性、使いやすさ、セキュリティ、柔軟性、さらには主観的な美学が含まれます。
これらのいくつかはveryを指定して評価することが困難です。それにもかかわらず、それらは重要です。契約でそれらにサインアップしている場合は、意味のない手で波打ったバージョンを避けたいでしょう。 「システムは安全でなければなりません」。このような要件を明確にしようとすることの問題は、人々が重要なものではなく、簡単に測定できるものに引き付けられる傾向があることです（そして、要件は関連する専門分野に根拠のない人々によって書かれることもあります） ）。最終結果は、一般に、安全でなく、使用可能でも、柔軟でもないシステムになることです（可用性は、まだ多くの頭痛を引き起こしますが、指定および測定することはそれほど難しくありません）。
契約や正式なものを扱う人々と、より一般的な分析、アーキテクチャ、研究などを扱う人々の間には、ここに文化的な違いがあります。漠然とした手ざわりの要件はまだ要件までです後者は、顧客が重要なことを表現しているため、顧客が契約者と完全に共感しても、それが（有用な契約要件ではないことを詳細に調査して徹底的に掘り下げるまでは）であるためです。
最後の1つのポイント-「まだ」という客観的な測定方法を（まだ）思い付かなくても、顧客がそれを必要としていないという意味ではありません。曖昧な！=は不要です。ただし、そのようなものを測定するためのより良い方法を開発したり、非機能要件を段階的に引き出したり改良したり、すべてに対して事前の客観的測定なしで機能できる方法（アジャイルなど）で契約したりする必要があるかもしれません。
これらのコメントはすべて非常に優れていますが、あまりに料理が行き過ぎており、使用する明確なテンプレートを提供していません。次のように指定するのは明らかではないでしょうか。
私の意見では、機能要件はユーザーがアプリケーションを使用するときに経験するものです。これは、開発者がこれを最初から実装し、拡張や変更を行うときに満たす必要がある要件です。たとえば、ユーザーはログインする必要があります。コマンドプロンプトを使用してアプリケーションを実行する新しい方法も追加した場合、ユーザーはまだログインする必要があります。
ボンネットの下で機能しない要件が発生します。ユーザーはそれを認識していませんが、実装されていても存在する必要があります。例：アプリケーションはC＃で開発する必要があります。それが他の言語で開発されている場合、ユーザーは気付かないでしょう。しかし、これは既存のコードに基づいているため、要件になる場合があります。別の例として、特定のサーバーにインストールする必要がある場合があります。サーバーの移動はユーザーには気づかれません。