要件管理とトレーサビリティの最も完全なガイド
要件を記述する際の推奨事項と禁止事項
目次
あなたがほとんどの人と同じなら、おそらく要件を書くことを好まないでしょう。 これは世界で最もエキサイティングなことではありませんが、製品開発の重要な部分です。 より優れた要件ドキュメントは、開発者と製品の利害関係者の間の明確なコミュニケーションにより、組織に大きな利益をもたらします。 これは、透明性の向上、やり直しの減少、生産性の向上など、組織全体に反映されます。
組織ごとに異なる要件と方法論がありますが、要件を記述するための基本は同じままです。 この記事では、要件を書くスキルを向上させ、明確で鮮明な要件仕様を作成するのに役立つヒントをいくつか紹介します。
要求仕様とは？
要件仕様は、ドキュメントとも呼ばれ、すべてのシステム要件とユーザー要件をドキュメントの形式で書き留めるプロセスです。 これらの要件は、明確で、完全で、包括的で、一貫している必要があります。
キャプチャアクティビティ中に、さまざまなソースからすべての要件を収集します。 分析および交渉活動中に、私たちはそれらの要件を分析および理解します。 次に、これらの要件を説明する正式な文書を作成する必要があります。 それが要件仕様です。 正確には、すべてのユーザーとシステムのニーズと制約を明確かつ正確に文書化するプロセスです。
要件管理における「ベスト プラクティス」とはどういう意味ですか?
誰もが「ベスト プラクティス」のトレーニングが必要だと話していることは、私にとって非常に興味深いことです。 この用語は、私たちが提供するコンサルティングの種類を説明するためにもよく使用されます。 それは本当にどういう意味ですか？ 私たちは皆、ベスト プラクティスが個人のトレーニングの基礎になり得るという神話に陥っていると思います。 ベスト プラクティスは訓練されたものではなく、経験済みのものです。
ベスト プラクティスのアプローチを自然と比較すると、生き残るのは最も強い種であるだけでなく、最も多産な種であることがわかります。 これが、組織内のプロセスを変更することが非常に難しい理由の XNUMX つです。 ちょっと考えてみてください。 最も強力で最も多作な人は、おそらく、組織内のほぼすべてのグループに所属する大多数の個人を表しています。 これは、システム エンジニアリングの分野で何度も見てきました。 最強で最も多作なエンジニアは、多くの場合、長年にわたって自分の仕事をしており、この仕事を行う特定の方法を持っています。 彼らに新しいテクニックやツールを試すように頼むことは、多くの場合無駄です。なぜなら、これが彼らが行っているすでに素晴らしい仕事をどのように改善するのか分からないからです。 私たちが彼らにベストプラクティスのアプローチを押し付け続ければ、彼らの実践は生き残るでしょう。
要件を記述する際の課題
要件を作成するときに人々が直面するさまざまな課題があります。
事務処理が不十分 – 一部の組織では、プロセスの文書化が存在しないか、標準に達していません。 この場合、要件の収集は XNUMX 段階のプロセスになります。最初に既存のプロセスをリバース エンジニアリングし、次に改善と最適化が必要な領域を特定します。 要件が具体的で正確であることを確認するには、主要な利害関係者と対象分野の専門家を特定し、直接関与することが重要です。 ビジネス プロセス マップの描画とワークフローの視覚化は、そのための XNUMX つの優れた方法です。 これは、全体像を提供しながら、誤った仮定を排除するのに役立ちます。 プロセス マップの描画とプロセスの表示は、この目的に役立つ XNUMX つの方法です。
相反する要件 – 利害関係者がビジネス目標に対して異なる優先順位を持っている場合、これは互いに競合する要件につながります。 このような場合、ビジネス アナリストの責任は、すべての要件を詳細に文書化し、どの要求が相反するかを特定し、利害関係者が優先順位を決定する機会を与えることです。
利害関係者の意見を聞くことなく決定を下すことはできません。また、ビジネス アナリストとして、何を優先すべきかについていくつかのアイデアを持っているかもしれません。 利害関係者の視点を聞くことは依然として重要です。 世論調査を設定することは、大多数の利害関係者にとって何が最も重要かを明確にする方法の XNUMX つかもしれません。
ユーザー入力の利用不可 – いくつかの理由により、エンド ユーザーが利用できなくなる可能性があり、それぞれに独自の解決策が必要です。 たとえば、エンド ユーザーが日常業務に没頭しすぎて、要件収集活動に参加したくない場合があります。
このような場合、ビジネス アナリストができる最善の方法は、エンゲージメントの数と長さを制限することです。 会議の前に、できるだけ多くの調査を行うと、議論がより組織的で有益なものになります。 これは、要件の収集を要件の検証セッションに変えるようなものです。 フォーカス グループを定義し、各グループに最適なエンド ユーザーを特定する
経験ではなくインターフェースに焦点を当てる – 多くの利害関係者とエンド ユーザーは、新しいソリューションがどのように表示されるべきかについて明確なビジョンを持っていますが、それが何を達成すべきかを知りません。 どのシステムのユーザー インターフェイスも重要ですが、機能を定義したり干渉したりしてはなりません。
ビジネス アナリストは、ドキュメント内で設計要件と機能要件を区別することを常に忘れないでください。 設計ドラフトではなく、ダイアグラム、ユーザー ストーリー、ローファイ プロトタイプなどのより一般的なツールを使用することで、要件収集の機能面に集中することができます。
利害関係者のインプット – 利害関係者またはエンドユーザーが、システムが何をすべきかではなく、システムがどのように機能すべきかを設計者に伝えようとすると、最適ではない設計につながる可能性があります。 これを回避するには、「なぜ?」と尋ねて、潜在的な「誤った要件」を検証します。 解決が必要な本当の問題に到達するまで。
コミュニケーションの問題 – ビジネス アナリストと他の関係者の間の誤解につながる可能性のある問題には、言葉の壁、間違った前提、不十分な語彙の説明、専門用語の乱用などがあります。
この問題を回避するための理想的なアプローチは、頻繁に対話し、双方向の会話を展開することです。 発見したニーズを文書化し、ピア レビューとさまざまな主題の専門家への批評のために提出し、専門用語の用語集を作成し、前提を再確認します。
要件を記述する際の 10 のすべきこととすべきでないこと:
＃1を行います。 一つずつ – 各要件は個別のテスト ケースとして扱う必要があります。 and、or などの接続詞は、要件を見逃す可能性があるため、使用しないでください。 このような用語は、ソフトウェア開発者やテスターが要件を見落とす可能性があるため、これは特に重要です。 複雑なニーズを小さな部分に分割して、それぞれを個別にテストできるようにすることは、これを防ぐ XNUMX つの方法です。
＃1しないでください。 「どのように」ではなく「何を」話す – システムがどのように機能するかではなく、システムが何を実行するかに焦点を当てる必要があります。 さらに、フィールド名、プログラミング言語オブジェクト、ソフトウェア オブジェクトなどの設計トピックを深く掘り下げないようにしてください。 要件仕様ドキュメントでこれらのトピックについて議論していることに気付いた場合は、一歩下がってください。これは、具体的になりすぎている可能性があります。
＃2を行います。 トレーサビリティ – プロジェクト管理におけるトレーサビリティとは、要件がプロジェクト内の他のコンポーネントにリンクされていることを確認することです。 これにより、プロジェクト マネージャー、開発者、および利害関係者は、システムの他の部分だけでなく、すべての方向で要件のライフサイクル全体を最初から最後まで追跡できます。 トレーサビリティを適切に管理すれば、どの要件にも対応しないコード (「浮遊」コード) を回避し、すべてのテスト ケースが少なくとも XNUMX つの要件をカバーするようにすることができます。 一意の識別子でラベルを付け、すべてのチーム メンバーがアクセスできる中央リポジトリにソースに関する情報を提供することで、要件を追跡可能にすることができます。
＃2しないでください。 例外なく – 要件にエスケープ句を含めることはできません。 たとえば、「ユーザーが明らかに間違ったユーザー名を入力した場合を除き、システムはログイン試行回数を決定します」。
＃3を行います。 実現可能な – プロジェクトの予算とタイムラインが実現可能であり、利用可能なリソースがあることを確認します。 この条件が要件をサポートできる場合は、計画を進めることができます。
＃3しないでください。 「手放す」条項にノーと言う – but、except、and only if needed などの言い回しは避けてください。
＃4を行います。 一貫性 – 一貫した詳細レベルを維持します。 たとえば、ユーザーの要件については、エンド ユーザーをすべての文の主語にする必要があります。 同様に、システム要件については、システムをすべての文の主語にする必要があります。
＃4しないでください。 略語なし – すべての要件は、頭字語や専門用語を使用せずに完全な文にする必要があります。
＃5を行います。 アクティブボイス – 常に能動態で書き、俳優の XNUMX 人がすべての文の主語になるようにします。
＃5しないでください。 曖昧にしないで – などのあいまいな用語を使用しないでください 約など、および要件ドキュメントにある同様の用語。 関係者全員が正しく理解できるように要件を説明してください。 あいまいな記述は誤解を招く可能性があり、さまざまな利害関係者の間で対立を引き起こす可能性があります。
＃6を行います。 主語と述語 – すべての要件には、主語 (ユーザー/システム) と述語 (意図した結果、アクション、または条件) が必要です。
＃6しないでください。 投機は損害を引き起こす可能性があります – 推測しないでください。 問題外の機能のリストを作成しないでください。 システムにすべての予期しない障害を処理してほしいと言うのは、まったくの空想です。システムが 100% 希望通りになることは決してないからです。 重複や矛盾する記述は避けてください。
＃7を行います。 検証可能 – 要件を整理する際に留意すべきもう XNUMX つのことは、要件は常にテスト可能である必要があるということです。 これは、システムが問題の要件を満たしていることを確認できる必要があることを意味します。 これは、次のポイントであるトレーサビリティにもつながります。 要件があいまいな用語でいっぱいの場合、システムが実際にこれらの基準を満たしているかどうかを分析して検証するのが難しくなります。 したがって、要件の収集があいまいなプロセスにならないように、できるだけ明確で正確な言語を目指してください。
＃7しないでください。 オプションを避ける – アイデアやオプションを提供しないでください。 これらは、may、might、could、または should というフレーズを含むステートメントで見つけることができます。
＃8を行います。 正解 – すべての文が完全であり、適切な主語、動詞、および述語を使用して文法的に正しいことを確認してください。
＃8しないでください。 未来形で話さないでください – まだ定義されていない要件を参照しないでください。 あなたの目標は、文書をできるだけ読みやすくすることです。
＃9を行います。 フォーカス – とりとめのない、長すぎるフレーズ、および古い論文への言及を排除して、焦点を確立します。
＃9しないでください。 何をどこで使用する必要がありますか? – 要件が述べられている場合は「しなければならない」を使用する必要があり、「意志」は事実の記述を表すために使用する必要があります。 & 「すべき」は、達成すべき目標を表します。
＃10を行います。 整理された事務処理は驚くべきことを行います – ドキュメントの読みやすさを改善し、複数のソースを相互参照して時間を無駄にしないように、要件を XNUMX か所にまとめます。
＃10しないでください。 不明な用語を使用しないでください – テストケースを定義しようとするときに困難を引き起こす可能性があるため、「ユーザーフレンドリー、多用途、堅牢」などの未知の用語を使用しないでください。 これらの言葉は、多くの場合、人によって意味が異なります。
視界要件ALMプラットフォーム
Visure は、世界中のあらゆる規模の組織の要件管理に特化した、最も信頼できるアプリケーション ライフサイクル管理プラットフォームの XNUMX つです。 Visure の主要なパートナーには、ビジネスに不可欠な企業や安全に不可欠な企業が含まれます。 同社は、リスク管理、問題と欠陥の追跡、トレーサビリティ管理、変更管理、および品質分析、要件のバージョン管理、強力なレポート作成などのさまざまな分野を含むアプリケーション ライフサイクル管理プロセス全体を統合します。
機能要件と非機能要件の両方に役立つ要件管理ツールをお探しの場合は、Visure Requirements をご覧ください。 このプラットフォームを使用すると、プロジェクトのすべての要件を XNUMX か所で簡単に作成、管理、追跡できます。
まとめ
要件仕様はソフトウェア開発における重要なプロセスですが、適切な要件を記述するのは難しい場合があります。 私たちが提供した 20 のヒントは、より良い要件を作成するのに役立ち、関係者全員にとってプロセスがよりスムーズになります。 要件の記述を次のレベルに引き上げたい場合は、Visure Requirements ALM Platform などのツールの使用を検討してください。 リクエスト 無料の30日試用版 今日、当社のプラットフォームが要件の収集と管理プロセスを合理化するのにどのように役立つかをご覧ください。
この投稿を共有することを忘れないでください！
