project-management - 要件仕様をレビューする際、どの「大罪」に対処する必要がありますか?

Question

要件仕様 (機能要件、非機能要件、制約などを含む) をレビューするとき、作成者が犯した「致命的な罪」に注意する必要がありますか?

要件仕様で実行されている (または実行されていない) ことがソフトウェア製品の品質に悪影響を与える最も重要なことを (重大度の降順で) 7 つ以内でリストしてください。7以下なら全然OK。

score 12 · Accepted Answer

OK、これは 7 つ以上ですが、適切な要件には次の属性があります。

ユニーク。他に同様の要件はありますか?
識別可能、要件を一意に識別できますか? 開発プロセス全体で追跡できますか?
完了します。足りないものや忘れているものはありませんか？徹底していますか？スタンドアロンにするために必要なすべてが含まれていますか?
正確。それが正しいか？目標を適切に定義していますか？エラーはありますか？
明白。説明は正確で曖昧ではありませんか? 単一の解釈はありますか？読みやすく、理解しやすいですか？
一貫しています。機能の説明は、仕様の他の項目と矛盾しないように書かれていますか?
関連する。ステートメントは機能に必要ですか? 除外すべき追加情報はありますか? 元の顧客のニーズまで追跡できますか?
実現可能。指定された予算とスケジュール内で、利用可能な人員、ツール、およびリソースで実装できますか?
コードフリー。仕様は、基盤となるソフトウェアの設計、アーキテクチャ、およびコードではなく、製品の定義に固執していますか?
テスト可能。テストできますか？テスト担当者が要件が満たされていることを確認するためのテストを作成できるように、十分な情報が提供されていますか?
優先されます。それは他の要件よりも多かれ少なかれ重要ですか?
アクティブボイスを採用。仕様は能動態ですか？受動態は、誰または何がアクションを実行するかを常に指定するとは限りません。
分類されます。要件は類似の要件と論理的にグループ化されていますか? 考えられるカテゴリは次のとおりです。動作、パフォーマンス、インターフェイス、データ構造/要素、実装、コンプライアンス/品質、運用 (信頼性、安全性、セキュリティ)、派生/エンジニアリング。

適切な要件追跡ツールは、識別可能、優先順位付け、分類など、上記の一部を自動化/適用できますが、残りはチームによるレビューのみが確認できます。重要なのは、これらの属性についてチームをトレーニングし、要件の良い例と悪い例の両方を読んで練習させ、下流の活動に影響を与えるようにライフサイクルの早い段階で要件をチェックする効率的なレビュープロセスを確立することです.

score 2 · Accepted Answer

機能、時間、品質 - 任意の 2 つを選択してください。要件が 3 つすべてをチームに押し付けないようにしてください。

プロセスを制御しようとする要件に反対します。

最初から明確な優先順位を求めてください。

各要件の明確な受け入れ基準を主張します。

score 2 · Accepted Answer

要件の欠落 - 把握するのがはるかに困難です。要件を明確なセクション (安全性、パフォーマンス、スタイリングなど) に分けると、これを見つけやすくなります。

score 1 · Accepted Answer

要件は、誰が/何がそのことを行うかを指定しません。

"The invoice is reconciled to the purchase order."

これは、システムが何かをするということですか、それともユーザーが何かをするということですか?

score 1 · Accepted Answer

私がコーディングしたプロジェクトで見た最悪のもの:-

The system shall interface to SAP as required.

まず、「必要に応じて」という要件はばかげています。その 1 行の費用は 40 万ドルに違いありません。顧客はそれを指さし続け、そこにあなたが何とかしようとしていると言っています。

score 1 · Accepted Answer

1

厳しすぎる - 可能であれば、関連する公差を指定してください。

于 2008-10-09T11:07:25.763 に答える

score 1 · Accepted Answer

あいまいな要件は良くありません。

検証不可能で定量化不可能な要件は、2 倍になります。

score 1 · Accepted Answer

当然、これはすべて、取得する要件の種類によって異なります。典型的な GUI または Web アプリケーション、バッチ処理、

各仕様で定義する必要のない規格を先に立てて参照する
できるだけ小さくする - 200 ページのドキュメントを読み、すべてを念頭に置くことはめったにありません。
具体的で、測定可能で、具体的であること
作例（図面、会計文書）
機能を説明する前に目的を説明してください
パフォーマンス基準、レジリエンス基準、導入手順、必要な操作のドキュメントを含む

また、レビュアーへのアドバイスが 1 つあります。

要件のコンテキスト、特定のクライアントのニーズ、技術環境、そしておそらく最も重要なのは、この要件が誰に向けられているか、そして彼らがどのレベルのグローバルな理解を持っているかについて、非常に詳細な知識を持っている必要があります.

個人の知識が非常に浅かったため、多くの人が仕様をレビューするプロジェクトで、私は非常に悪い経験をしました. ほとんどが正式な修正ですが、仕様の重大な欠如は、プロジェクトのごく最近になって初めて発見されます。

score 1 · Accepted Answer

要件は、必要なものに関して具体的で明確でなければなりませんが、要件を満たす方法についてはそれほど明確にする必要があります。

score 1 · Accepted Answer

仮定を立てる - 仮定のように見えるものが実際に検証されていることを再確認してください。

score 1 · Accepted Answer

複数の要件を含む不適切な文。それらをどこかに分けて、より明確にし、完了を簡単に確認できるようにします。

score 1 · Accepted Answer

満たされていることを確認するのが容易でない要件 - レビュー時に、満たされているかどうかをより簡単にマークできるフォームに変更します。

score 1 · Accepted Answer

「イタチの言葉」は避けてください。文脈から引き出され、悪く聞こえる言語はすべて悪いものです。

すべてが完全に明確であることを確認してください: 漠然とした == 悪いこと (tm)

score 0 · Accepted Answer

すべてを知っているウィクペディアには、要件の優れた概要があります- http://en.wikipedia.org/wiki/Requirement#Good_requirements。その中で最も多いのは、検証可能性の欠如です。全体像を理解することは人生において重要ですが、要件で明示的に説明する必要があります。システムは迅速に応答する必要があります。代わりに、システムは 2 秒以内にすべての要求に応答する必要があります。

score 0 · Accepted Answer

私の推奨事項と、新しいプロジェクトの前に私が常に行うことは、 Steve McConnell の Code Complete の42,43 ページのチェックリストを再確認することです。

score 0 · Accepted Answer

機能要件、アーキテクチャ要件、インターフェース要件、非機能要件の分離。
エンティティを説明するための明確で一貫した表記の使用
ユースケースの明確な開始基準と終了基準
フロー図を用意する (マインドマップは UML と同じ目的を果たし、より簡単に描画できます)
範囲を明確な言葉で定義し、何がカバーされ、何がカバーされていないか、未知のものをどこで見つけるかを定義します
トレーサビリティマトリックスを用意する

score 0 · Accepted Answer

要件管理およびCMMIドキュメントの一部を読むことを検討してください。

また、要件チェックリストにアクセスし、Google で「適切な要件の基準」を検索してください。

これらは、ソフトウェア開発に役立つプロセスを作成するために特別に設計されています。

project-management - 要件仕様をレビューする際、どの「大罪」に対処する必要がありますか?

17 に答える 17

Related

Reference