オプション要件についてのより良い言葉は？[閉まっている]

ソフトウェアエンジニアリングのオプション要件に対するより良い言葉は何ですか？このフレーズは矛盾しています。以前のプロジェクトで「非コア要件」を使用しました。

「範囲外の要件」という用語を使用することもできます。これは、要件がプロセス内でキャプチャされ、追跡可能であることを意味しますが、要件は、予算、スケジュール、時間、または実現可能性。

ただし、「オプションの要件」という語句は一般に、スコープ内にあるが必ずしもシステムで必要とは限らない何かを示すために使用されます。これは、要件の優先度の尺度です。私の経験では、要件は多くの場合、必須、望ましい、またはオプションとして優先順位が付けられています（他のスキームもあります）。プロジェクトが完全かつ完全に機能していると見なされるためには、すべての必須要件を満たす必要があります。十分なリソースがあれば、次に望ましい要件が実装されます。最後に、オプションと見なされるものはすべて含まれます。

混乱は「要件」という用語から来ると思います。英語では、要件は「必要なもの」または「必須、強制、または必要条件」です。ただし、ソフトウェアエンジニアリングでは、要件という用語はソフトウェアシステムの文書化された特性にすぎません。オプションおよび必須の概念は、ソフトウェアシステムの文書化された特性の優先度を説明します。

要件とは対照的に、「必要な」機能と呼びます。

ソフトウェア要件のドキュメントでは、RFC 2119キーワードを要件レベルを示すためにこの用語を使用する限り、つまり、本当にオプションのアイテムを示すために、オプション要件の表現はまったく問題ありません。

仕様テキストに形容詞ではなく動詞が含まれている場合は、「オプション」ではなく「MAY」を使用します。

小さくて読みやすいので、RFCテキストは以下に完全に引用されています。

    ネットワークワーキンググループS.ブラッドナー
    コメントのリクエスト：2119 Harvard University
    BCP：1997年3月14日
    カテゴリ：現在のベストプラクティス


            要件レベルを示すためにRFCで使用するキーワード

    このメモのステータス

       このドキュメントでは、
       インターネットコミュニティ、および
       改善。このメモの配布は無制限です。

    概要

       多くの標準トラック文書では、いくつかの単語が使用されて
       仕様の要件。これらの言葉はしばしば
       大文字。このドキュメントでは、これらの単語を定義すべき
       IETFドキュメントで解釈されます。これらのガイドラインに従う著者
       ドキュメントの冒頭にこのフレーズを組み込む必要があります。

          キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL」
          NOT」、「SHOULD」、「SHOULD NOT」、「推奨」、「MAY」、および
          このドキュメントの「オプション」は、
          RFC 2119。

       これらの単語の力は要件によって変更されることに注意してください
       それらが使用されるドキュメントのレベル。

    1.この単語、または「必須」または「共有」という用語は、
       定義は仕様の絶対的な要件です。

    2.このフレーズ、または「SHALL NOT」というフレーズは、
       定義は仕様の絶対的な禁止です。

    3.この単語、または「推奨」という形容詞は、
       特定の状況において、
       特定の項目ですが、完全な意味を理解し、
       別のコースを選択する前に慎重に重量を量った。

    4.このフレーズ、または「推奨されません」というフレーズは、
       特定の状況で有効な理由が存在する場合があります
       特定の動作は許容されるか、さらには有用ですが、完全な
       影響を理解し、ケースを慎重に検討する必要があります
       このラベルで説明されている動作を実装する前に。

    5.この単語、または形容詞「オプション」は、アイテムが
       本当にオプションです。あるベンダーは、アイテムを含めることを選択できます。
       特定の市場ではそれが必要であるか、ベンダーが
       他のベンダーが同じアイテムを省略しても、製品が強化されます。
       特定のオプションを含まない実装は
       他の実装と相互運用する準備ができている
       オプションを含めますが、おそらく機能が制限されます。の中に
       同じ静脈特定のオプションを含む実装
       別の実装と相互運用する準備をしなければならない
       オプションを含みません（もちろん、機能の場合を除き、
       オプションが提供します。）

    6.これらの命令の使用に関するガイダンス

       このメモで定義されているタイプの命令は、注意して使用する必要があります
       そして控えめに。特に、それらは、
       相互運用のために実際に必要な、または持っている動作を制限するために
       害を引き起こす可能性（再送信の制限など）
       たとえば、特定の方法を課そうとして使用してはいけません
       メソッドが相互運用性のために必要とされない実装者に対して。

    7.セキュリティに関する考慮事項

       これらの用語は、セキュリティを備えた動作を指定するために頻繁に使用されます
       含意。MUSTを実装しないことのセキュリティへの影響または
       SHOULD、または仕様で指定されていることを実行する必要があります
       行われないことは非常に微妙かもしれません。文書作成者は時間がかかるはずです
       従わないことのセキュリティへの影響を詳述する
       ほとんどの実装者にはない推奨事項または要件
       を生み出した経験と議論の恩恵を受けました
       仕様。

    8.謝辞

       これらの用語の定義は、取られた定義の融合です
       多くのRFCから。さらに、提案は
       ロバート・ウルマン、トーマスを含む多くの人々から法人化
       Narten、Neal McBurnett、およびRobert Elz。

ドキュメントが定義のソースとしてRFCを参照していても害はありません。

このドキュメントは、RFC 2119で指定された定義に基づいて定義を使用します。

それはあなたの質問への答えではないことを感謝していますが、私の世界では、たとえ何らかの理由であなたがそれを果たせないとしても、それはまだ要件です。

私はMoSCoWアプローチ（必須、必須、必須、今回は不要）をユーザーと他の要因（私の規制の世界では、要件は重要または非重要であり、多くの場合、オプションではあるが重要な要件をめぐって議論が広がります

オプションの要件のより良い言葉は、「推奨事項」です

オプションの機能またはオプションのタスクとして識別するのはどうですか。これらは、プロジェクトの特定の時点で、これらの機能を完了するための時間とお金があると判断された場合にのみ行われます。

外部イベントが発生した場合にもトリガーできます。お客様がWindows 8に切り替えた場合、次のタスクを完了する必要があります...

機能の説明には、実行するかどうかを決定するための期限を含める必要があります。

要件は、ソフトウェアエンジニアリングの4つの領域に分類されます。

1. ビジネス要件：システムの全体的なビジネス目標と目的に焦点を当てます
2. ユーザー要件：ユーザーの目的と、システムを使用してビジネス目標を達成するためにユーザーがしなければならないことに焦点を合わせます
3. 機能要件：ビジネス目標を達成するためにシステムが実行する必要がある機能とタスク
4. 非機能要件：機能要件以外にどのような要件がありますか。これには、環境、制約、インターフェイス、メンテナンスの問題などが含まれます。

上記の4つのカテゴリに応じて、要件はOptionalまたはMandatoryになります。上記で概要を説明しました。オプションの要件は、検討中のシステムの範囲に含まれたり、その範囲から外れたりする可能性もあります。オプションの要件は、スコープクリープを避け、正確な用語でスコープを定義するための良い手段です。

オプション要件は、ソフトウェアエンジニアリングの一部であり、スコープの特定に役立ち、スコープクリープを回避するための優れた手段です。SDLCのエンジニアリング慣行と矛盾するとは決して言えません。ただし、要件には優先順位を付け、明確に定義する必要があります。

でVolereテンプレート用語「待合室」が使用されます。

...このテンプレートは、要件仕様の基盤として使用することを目的としています。このテンプレートは、今日のビジネス、科学、およびソフトウェアシステムに適した各要件タイプに対応しています。要件のチェックリスト、構造、トレーサビリティを提供します...テンプレートはツールに依存せず、Yonix、Requisite、DOORS、Calibre RM、IRqA、およびその他の一般的なツールで正常に使用されています...

Volereの手法については、Suzanne RobertsonとJames Robertsonによる「Mastering the Requirements Process」という本で説明されています。

私のビジネス（宇宙船）では、それらは「目標」と呼ばれ、文書化され、それらを満たすために努力が費やされることを示しますが、満たされない場合でもシステムは成功したと見なされます。「望み」（実際の言葉ではありませんが、あなたはそこにいます）は、誰かがそれを望んでいて、目標のステータスを達成しようとしているが、まだ受け入れられていないか文書化されていないことを示します; 「クリーピング要件」は、リソースを消費しようとしているものの、実際の要件を妥協または脅迫する「十分な」成果を達成しようとするプロジェクトでは価値がないものを示す、より軽atory的な要望です。

要件に優先順位が付けられている場合は、それらを低優先順位の要件と見なすことができます。

それらが「目的」と呼ばれていることを誰も言及していないことに私は非常に驚いています。私が働いたすべての会社は彼らにそれを呼びました。それらは、「しな」の代わりに「意志」または「すべき」という言葉の使用によって示されます。数字について話すとき、括弧で囲まれることもあります。たとえば、システムは、100 {250}時間、オペレータの注意を必要とせずに継続的に動作します。つまり、満たす必要がある要件は100時間ですが、目標は250時間です。

補足として、何らかのインセンティブが関与しない限り、実際に客観的な要件を満たすように設計する人はほとんどいません。

「要望」という用語は、オプションの要件に使用されることがあります。ただし、正式な文書には適さない場合があります。

すべての回答がプロジェクト開発の要件の追跡に関係していることに驚いています。開発者であるにもかかわらず、その文脈でこの用語についてあまり心配することはありません。私が最初に質問を読んだとき、私はそれが製品開発ではなく、ユーザー製品仕様に関連していると思いました。たとえば、百科事典では、オプションの要件としてカラープリンターがリストされている場合があります。アプリを最大限に活用する場合は必須ですが、画面を表示する場合はオプションです。しかし、たとえばモノクロプリンターがある場合はどうでしょうか。アプリが、一部の写真があまり良く見えないという明白な制限で動作するかどうかを明確にする方法は？またはまったく印刷しませんか？別の例として、多機能プリンターでインクが要件であるか、オプションの要件要件であるかを確認するために、プリンターのレビューを確認するにはどうすればよいですか？つまり、まだスキャンできますか？用語と検索対象に関するヒントは、製品開発者/販売者としても消費者としても歓迎します。

オプションの要件ではなく、「オプションの機能」と呼びます。要件は必要なもののように聞こえますが、機能は元の製品のアドオンのように聞こえます。