methodology - 機能仕様

Question

私がどこを見ても、機能仕様は、要件/提案された機能が表現され、詳細に記述されたある種のドキュメントです。私は最近、機能仕様の標準テンプレートを作成する立場にありました。私が決めたフォーマットは、暫定的に、かなり自動化されたExcelファイルです。

1. テンプレートは、階層内の最上位の要件を下位レベルの要件にリンクすることを計画しています。

2. 次に、低レベルの要件を、品質の家と同様に、設計の技術的側面にマッピングできます。コアレーションはHOQの場合と同様に識別されますが、さらに、要件と技術的側面の各ペアについて、実現可能性が推定されます。

3. 要件の技術的側面のいずれかが実行不可能としてマークされている場合、その要件には再検討のフラグが立てられます。

4. すべての要件に実行可能のフラグが立てられるか、適切に削除された後、各要件と技術的側面のペアが抽出され、時間と予算の観点からそれぞれの見積もりが求められます。

5. 見積もりは、プロジェクトの計画に役立ちます。

この提案について情報に基づいた意見をいただけますか？これは、要件を技術的な側面にリンクし、次にプロジェクト計画にリンクするための最良の方法のように思えました。

Answer 1

私の経験では、機能仕様は一般的にユース ケース ドキュメント (対応する図の有無にかかわらず) でした。スプレッドシートはかなりクールに聞こえますが、機能要件は一般に、プロジェクトの予算を承認できるように合意を得て、最終的にサインオフすることを目標に、ビジネス関係者と通信するためのものです。あなたのスプレッドシートが何らかの方法で印刷出力の要件をフォーマットできない限り、ディスカッションやフィードバックのために内容を共有する方法について、私は少し混乱しています.

私の2セント...

お役に立てれば、

明細書

Answer 2

ユース ケースとユーザー インターフェースの仕様を一覧表示するには、スプレッドシートの補足が必要になる場合があります。

Answer 3

低レベルの要件とテスト (「単体テスト」ではなく「設計テスト」など) の間のマッピングを追加することをお勧めします。
これにより、そのプロジェクトに必要な幅広い機能テストの範囲を確立できます。

Answer 4

「この提案について十分な情報に基づいた意見をいただけますか?」

このスプレッドシートのユーザーは誰ですか?

ユーザーはこのスプレッドシートで何をしますか? 要件の収集、計画、およびプロジェクトの承認のためのユースケースは何ですか?

あなたがユーザーなら、それはあなたにとって完璧です。

あなたがユーザーでない場合は、ユーザーと会い、次のことを決定する必要があります。

• 要件のユーザーはどのようなアクションを実行しますか? 彼らは承認、拒否、確認、拒否しますか?

• 彼らはどのような決定を下しますか？

• それらの決定を下すために必要な情報は何ですか?

スプレッドシートがユーザーのニーズを満たしていれば、それで問題ありません。

要件は扱いにくいものであり、非常に多くの点で優先順位を付け直し、再検討する必要があります。スプレッドシートの自動化が多すぎると、障害になる可能性があります。

ほとんどの場合、列を無制限に追加し、それらを無数の組織や再編成に分類できる必要があります。