機能的/非機能的要件VS設計アイデア
問題ドメイン
- 機能要件は、システムが行う /を定義します。
- 非機能要件は、システムが全体として行うことの品質属性を定義します（パフォーマンス、セキュリティ、信頼性、ボリューム、使いやすさなど）。
- 制約は設計スペースを制限し、設計者を特定のタイプのソリューションに制限します。
ソリューションドメイン
- 設計のアイデア、方法システムが定義する方法を定義します。
たとえば、利害関係者のニーズは売上を伸ばしたい場合があるため、より多くの顧客が購入できるようにWebショップの使いやすさを改善する必要があります。 （問題ドメイン）
デザインでは、「現在の前払いオプションに加えて、クレジットカードによる支払いも提供したい」ということで、これをソリューションドメインに取り入れています。
私の問題は、要件から設計への移行フェーズが非常に曖昧に見えるため、ソフトウェア要件仕様を作成するときに、設計のアイデアを私の要件、それは私の要件を間違ったものにするでしょう。
もう1つの問題は、システムの機能として機能要件を頻繁に記述し、それを実行する必要のある時間枠も指定することです。しかし、これは正しいですか？それでも、それは機能的な要件ですか、それとも機能しない要件ですか？それを2つの異なる要件に分ける方が良いですか？
ここに私が書いたいくつかの要件があります：
主催者のFR1登録
FR1はCrowdFundumでのオーガナイザーの登録について説明しています
- FR1.1システムは shall 登録フォームをWebサイトに表示します。
- FR1.2システム shall には、名前、ユーザー名、文書番号パスポート/ IDカード、住所、郵便番号、市、メールアドレスが必要です、電話番号、銀行口座、登録フォームのキャプチャコードユーザーが登録するとき.
- FR1.4システムは、登録フォームのシステムチェックに失敗した後、1秒以内に「登録を完了できませんでした」というエラーメッセージを加入者に表示します。
- FR1.5システムは、登録フォームのシステムチェックが成功した後、30秒以内に確認リンクを含む確認メールを加入者に送信します。
- FR1.6システムは、確認リンクにアクセスしてから5秒以内に、新しく登録されたオーガナイザーをユーザーベースに追加します。
FR2オーガナイザーがプロジェクトを提出
FR2は、CrowdFundum の主催者によるプロジェクトの提出について説明しています
- FR2 システムは、Webサイトの主催者アカウントにプロジェクト送信フォームを表示します。<-FR2.3システムは、プロジェクトの名前、1〜3枚の写真、プロジェクトのキーワード、パンチライン、最小および最大の人数、資金のしきい値、1つ以上の報酬レベル、何が組織されるかについてのスケジュール、予算の完全性をチェックします。計画、プロジェクトに関する300〜800ワードの追加情報、主催者がプロジェクト送信フォームを送信してから1秒以内の連絡先の詳細。 -FR2.8システムは、システムがプロジェクトWebページを作成してから30秒以内に、新しいプロジェクトカテゴリのホームページにプロジェクトリンクを追加します。
-FR2.9システムは、ホームページのプロジェクトリンクに含めるものとします。システムが作成してから30秒以内に、プロジェクトの名前、写真1枚、パンチラインが含まれます。プロジェクトのウェブページ。
質問：
FR 1.1 ：ここに設計アイデアを組み込んだか、「システムに登録フォームが必要」がより優れた機能要件になりますか？
F1.2、2.3 ：これは単数ではありませんか？条件は、それぞれ独自の個別の要件に対してより適切に記述されますか
FR 1.4 ：これは設計のアイデアですか？これは正しい機能要件ですか、それとも非機能（パフォーマンス）を組み込んでいますか？次のように書いた方がよいでしょう。
FR1チェックが失敗した場合、システムはエラーメッセージを表示します。
NFR：システムは、失敗した登録フォームのチェックに1秒以内に応答します。 FR 2.8と2.9でも同じ質問です。
FR2.3：システムは「完全性」をチェックする必要がありますが、ここでの完全性はあいまいに使用されていますか？言い換えればいいですか？
FR1.2：私は、システムが「Captchaコード」を必要とするものであることを追加しました。これは機能的な要件ですか、それとも非セキュリティシステムの「セキュリティの側面」に属しますか。機能要件。
お返事お待ちしております。ありがとう！
私は [〜＃〜] swebok [〜＃〜] （ Software Engineering Book Of Knowledge ）に頼って私の答えを導きます。
ソフトウェア要件 *の章では、質問に必要な用語のより正式な定義を提供しています。
機能要件は、ソフトウェアが実行する機能を記述します。たとえば、一部のテキストをフォーマットしたり、信号を変調したりします。それらは機能と呼ばれることもあります。
非機能要件は、ソリューションを制約するように機能する要件です。非機能要件は、制約または品質要件と呼ばれることもあります。
文書を生成するように要求された方法にいくつかの重複があるように見えるので、それらを指摘します。あなたは述べました：A SRS should only have functional, non functional and constraintsおよびSWEBOK/IEEE定義に基づいて、非機能要件と制約がまったく同じであることがわかります。
また、過剰に抗議する人もいますが、要件作業に関連する3つの主要なドキュメントがあります。
システム定義ドキュメントこのドキュメント（ユーザー要件ドキュメントまたは操作の概念とも呼ばれます）には、システム要件が記録されています。ドメインの観点から高レベルのシステム要件を定義します。
システム要件の仕様このビューでは、システム要件が指定され、ソフトウェア要件はシステム要件から導出され、ソフトウェアコンポーネントの要件が指定されます。 。
ソフトウェア要件仕様は、顧客と請負業者またはサプライヤーの間の合意の基礎を確立します（市場主導のプロジェクトでは、これらの役割はマーケティング部門と開発部門が果たす可能性があります） ）ソフトウェア製品が何をすべきか、およびそれが何を期待されていないかについて。
したがって、これらすべての問題は、説明すると明確に示されているように見えますが、実装すると最終的に濁ってしまいます。私の回答に集中できるように、システム要求仕様は巨大なトピックであり、質問にはあまり必要ないため、無視します。
直面している主な課題は、SDDとSoftRS（ソフトウェア）のドキュメントを混在させることです。 2つのドキュメントは3つのキャンプ間の通信の架け橋であるため、2つのドキュメントが重複するのは当然であり、避けられません。 SDDはクライアントとアナリスト間のブリッジであり、SRSはアナリストと開発者間のブリッジです。
では、SDDとSRSの間にどのように線を引くのでしょうか。 システムのエンジニアリング トリニティに戻りましょう：
whatwhyhow
V-model を見るとき、これらの3つを使用してレイヤーを処理するため、これらは実際にこの順序で進む必要があります。システムレイヤーのwhat＆whyから始めます。それらをキャプチャすると、howのアイデアの生成を開始します。これは、Vモデルの下の次のレイヤーに入ります。 「最終的に」特定のレイヤーで終了し、同じ方法で下のレイヤーの改訂を開始します。下位層の違いは、上位層のhowがthis層のwhatになることです。
テキストの壁、何とか何とか、あなたの質問に取り組みましょう。
FR 1.1：私はここに設計アイデアを組み込んだことがありますか？「システムには登録フォームが必要です」がより優れた機能要件になりますか？
私は答えのために「meh」から始めるつもりです。ユーザーの操作を必要とするフォームでの「表示する」と「表示する」は無意味です。これらの2つの形式の間のセマンティクスについての議論が実際のプロジェクトで発生した場合、私は巨大な赤旗であると考え、プロジェクトを救済しようとします。真剣に。
この場合、「表示する」は「持つ」を意味し、「表示する」は「表示する」ことを意味します。完全に理解できるようにするには、明確にするために少なくとも「とディスプレイを備えている」必要があります。これら3つのバリアントはどれも問題ありません。
F1.2、2.3：これは単数ではありませんか？条件は、それ自体の個別の要件ごとに適切に記述されますか
それらは確かに関連しており、それらをどのように表現したいかについては注意が必要です。どちらの方法でも同等の結果が得られることを確認したので、この場合はチームの基準に依存します。重要な部分は、このような複合要件の処理方法に一貫性を持たせることです。
FR 1.4：これはデザインのアイデアですか？これは正しい機能要件ですか、それとも非機能（パフォーマンス）を組み込んでいますか？次のように書いた方が良いでしょう。FR1チェックが失敗した場合、システムはエラーメッセージを表示します。 NFR：システムは、1秒以内に失敗した登録フォームのチェックに応答します。 FR 2.8と2.9でも同じ質問です。
おそらく私はこれらを壊すでしょう、はい。理由は次のとおりです。1つ目は機能の提供（エラーメッセージの表示）、2つ目はその機能の提供に関する制約（特定の時間）を提供します。制約は頻繁に変更されますが、機能は変更されません。制約を独自の要件に移動することで、機能性について事前に合意し、実装に入るときに制約（メッセージの配信速度）に対処できます。
FR2.3：システムは「完全性」をチェックする必要があります。ここでの完全性はあいまいに使用されていますか？言い換えればいいですか？
あなたが提供するアイテムのリストで完全性を説明するのに近い。ただし、リストした各項目で、完全性を決定するものまたはそうでないものを指定することで、より明確にすることができます。
FR1.2：私は、システムが「Captchaコード」を必要とすることを追加しました。これは機能的な要件ですか、それとも非機能的な要件の「セキュリティの側面」に属しますか。
話しているデザインのレベルに依存します。高レベルでは、制約であるため、機能以外の要件です。低レベルでは、提供する機能を指定しているため、機能要件です。
*SWEBOKは現在、次のリリースのレビュー状態です。メインリンクを除いて、一部の追加リンクは古くなっている可能性があります。