2

ソフトウェア システムの実装を終えたばかりで、要件を満たしているかどうかを文書化する必要があります。どのような情報を含め、どのようにレイアウトすればよいですか?

私の最初の機能要件と非機能要件は、2 列の表にあり、次のようなものでした。

  • FN-01 システムは、ユーザーが互いにプライベート メッセージを送信できるようにする必要があります。
  • NFN-03 セットアップ/構成フォームには、ほとんどのフィールドで適切なデフォルト値が含まれている必要があります。
4

6 に答える 6

1

新しいものを作成するのではなく、すでに実施されている要件番号付けスキームを使用します。要件ごとに次の項目を文書化します。

  1. 要件ステータス：これはさまざまな言い方をすることができますが、要件がリストどおりに完了したか、リストされたものの変更されたバリアントで完了したか、または単にまったく完了できなかったかどうかを伝えるのは面倒です。
  2. 要件コメント：前述の要件ステータスについて説明します。これが、要件を完全に満たすことができなかった項目を説明する「理由」です。
  3. 完了日：これは主に将来の製品計画のためですが、履歴参照としてのサーバーでもあります。

覚えておくべき他のいくつかのポイント：

  1. 特に顧客が要件のソースである場合、要件は顧客によってレビューされる場合があります。したがって、このドキュメントはできるだけ正確で有益である必要があります。（これは、必要がない限り、要件の番号付けスキームを変更しないもう1つの理由でもあります。）
  2. テスト部門（あなたが持っていると仮定して）は、テスト計画にこれらのドキュメントを使用する必要があり、どの要件が満たされているか、どの要件が満たされていないか、そして最も重要なのはどの要件がどのように変更されたかを知る必要があります。

最後に、誰かのために犬とポニーのショーを行う場合を除いて、要件のドキュメントの一部としてスクリーンショットは必要ありません。また、完了の「証明」を提供する必要はありません。テスト部門があなたに代わってそれを行います。

于 2009-06-03T03:49:41.413 に答える
1

要件をテストケースに変換するためのいくつかの手法があります。ただし、これらは要件がどのように文書化されているかによって異なります。シナリオベースの要件分析をすでに行っている場合は、非常に簡単です。シナリオのすべてのパスのシーケンス図を作成し、テストを作成/実行->完了します。そのように作成されたドキュメントに加えて、講師にも感銘を与えるはずです。

シナリオがない場合は、ユースケースからいくつかを作成する必要があります。

ここでの欠点は、それが非常に作業集約的であり、その使用を正当化する場合にのみ使用されるべきであるということです（例えば、論文;））

于 2009-11-09T17:38:20.553 に答える
0

要件の行に要件番号を1つずつリストし、それを証明するテキストやスクリーンショットをリストします。

左側の要件番号を太字にし、要件テキストをタブで囲んで斜体にします。プルーフテキスト/スクリーンショットを要件テキストに合わせ、要件番号だけの左側の列をクリアにします。例えば：

REQ-1      italicized requirement text

           text discussing how the software has
           fulfilled the requirements, possibly
           with a picture:

           -----------------------
           |                     |
           |                     |
           |                     |
           |                     |
           |                     |
           -----------------------

REQ-2      italicized requirement text

           etc...

論理的なプログラム領域に基づいて章またはセクションにグループ化し、プログラム領域全体が要件をどのように満たすかについての宣伝文でセクションまたは章を開始する必要があります（一般的に

于 2009-06-01T02:43:11.083 に答える
0

私たちは通常、各項目が満足のいくものであるかどうかをチェックできるテスト計画を用意しています。計画は、元の要件 (機能的または非機能的) に基づいています。たとえば、次のようになります。

要件:間違ったパスワードでログインを 3 回試行すると、ユーザー アカウントがロックされる必要があります。

テスト:間違ったパスワードで 3 回以上ログインを試みます。ユーザー アカウントは現在ロックされていますか?

これを要件ごとに行い、リリース候補ごとに計画を再実行します。一部のテストは自動化されていますが、手動テストを実行する贅沢なテスト チームもあります。

これらのテスト計画とユーザー受け入れテストの実行結果に基づいて、RC が正しく、リリースに適していることを承認します。

テスト計画のいくつかの項目が合格しない場合でも、リリースを承認する場合があることに注意してください。それはすべて項目の性質に依存します!

于 2009-06-03T18:20:24.443 に答える
0

シンプルに保ち、次の列を追加します。

  • 配信要件を満たす - はい、いいえ、オープンを含むドロップダウン リストを使用
  • コメント - 「メッセージ サイズを定義する必要がある」、「メッセージのレイアウトを完全には満たしていないが、クライアントに受け入れられた」など、配信に関するコメント。
  • 完了日 - 変更が配信された日
  • 満足日 - 変更が受け入れられた日

要件 ID を使用することで、レイアウトやスクリーン ショットなどのより詳細な情報を含むドキュメントを指していると思います。

于 2009-06-02T15:31:30.753 に答える
0

要件を検証する正式な方法は、テスト (通常は受け入れテスト) を使用することです。

アイデアは、すべての要件に対して、要件を検証する 1 つ以上のテストが必要であるということです。正式な開発状況では、顧客は要件を承認すると同時に受け入れテストを承認します。

次に、製品が完成したら、受け入れテストの結果を提示し、最終製品を受け入れる前に顧客がレビューします。

テストできない要件がある場合、それらはおそらく不適切に記述されています。

たとえば、「ファイルの読み込みは高速でなければならない」、「サイズ X のファイルは Z のハードウェアで Y ミリ秒以内に読み込まれる」などと言ってはいけません。

于 2009-06-03T23:02:54.983 に答える