ソフトウェア開発プロジェクトの最も重要な部分の XNUMX つは、詳細で正確な要件を作成することです。 何を構築する必要があるかを明確に理解していなければ、高品質の最終製品を作成することはできません。 残念ながら、適切な要件を記述することは、言うは易く行うは難しです。 不十分な要件を作成する主な理由は、適切な要件を作成するためのトレーニングや経験がないためです。 あなたやあなたのスタッフが適切な要件を書くのに問題がある場合は、適切な要件を書く方法についてのガイダンスが役に立つかもしれません。 時間をかけてより良い要件を作成する方法を学ぶことで、ソフトウェア開発プロジェクトの全体的な品質を向上させることができ、将来の多くの頭痛の種から解放されます。

システム エンジニアリング プロジェクトが失敗する理由

規制の厳しい業界のプロジェクトが失敗するのはなぜですか? 多くの研究者が、システムやソフトウェア プロジェクトが失敗する理由を調査してきました。 Standish Group は 2009 年に調査を実施し、プロジェクトが失敗するほとんどの理由が要件に関連していることを強調しています。

これが、適切な要件を記述することがプロジェクトの成功に不可欠である主な理由の XNUMX つです。 さらに、優れた要件を作成することは、チーム全体に他の多くの利点をもたらします。

要求仕様とは？

要件仕様は、要件を定義、文書化、および分析するプロセスです。 開発を開始する前に、すべての利害関係者がソフトウェアの機能に同意することを保証するため、これはソフトウェア開発の重要な部分です。 こうすることで、後で誤解ややり直しの可能性を減らすことができます。

ドキュメントとも呼ばれる要件仕様は、システムとユーザーのすべての要件をドキュメントの形式で書き留める、または書き出すプロセスです。 これらの要件は、明確、完全、包括的、かつ一貫している必要があります。

要件エンジニアリング プロセス

要件を処理するときに直面するいくつかのアクティビティがあります。 要件エンジニアリングサイクルには、XNUMXつの主要なアクティビティがあります。

1. 要件の引き出し – これは、利害関係者とユーザーのニーズとシーズンの制約を収集、確認、および理解するプロセスです。 ユーザーが必要とするドメイン情報、既存システム情報、法規、規格など。これらの情報を基に、要件を抽出します。 この後、要件分析と交渉に移ります。 
2. 要件分析と交渉 – 分析とは、収集して引き出した情報に基づいて、ユーザーのニーズと制約を絞り込むプロセスです。 その後、ドキュメンテーション活動に移ります。 
3. 要件のドキュメント/仕様 – 要求仕様を取得したら、ドキュメント部分に移ります。 ユーザーのニーズと制約を明確かつ正確に文書化します。 
4. 要件の検証 – 最後に、検証アクティビティで、シーズンの要件が完全で簡潔かつ明確であることを挿入します。 
5. 要件管理 – 要件管理は、開発段階ですべての製品または要件を収集、分析、改良、および優先順位付けする方法です。 この段階では、要件と情報源の間の確実なトレーサビリティも確立されます。 

これらのXNUMXつのアクティビティを完了すると、正式な仕様である合意された要件ドキュメントのセットを取得するまで、それらを何度も繰り返します。

適切な要件を記述することが重要なのはなぜですか?

優れた要求仕様を持つことには多くの利点があります。 それらのいくつかを以下に示します。

• すべての利害関係者が、開発されるシステムについて共通の理解を持つようにするのに役立ちます。 これにより、開発の後の段階での誤解を避けることができます。
• 開発プロセス中のすべての利害関係者の参照ポイントとして機能します。
• 要件のギャップを早い段階で特定するのに役立ちます。
• 要件の変更による手直しが回避されるため、開発の全体的なコストと時間が削減されます。

優れた要件を作成することで、何を達成できますか?

優れた要件が達成に役立つことがたくさんあります。 それらのいくつかを以下に示します。

• 優れた要件は、開発中のシステムがユーザーのニーズを満たすことを保証するのに役立ちます。
• これらは、システムをテストして期待どおりに動作することを確認するための基礎として機能します。
• 要件の変更によるやり直しを回避することで、開発の全体的なコストと時間を削減するのに役立ちます。
• 優れた要件は、開発プロセスをより効率的かつ効果的にするのに役立ちます。

要件を記述する際の課題

要件を作成するときに人々が直面するさまざまな課題があります。

事務処理が不十分 – 一部の組織では、プロセスの文書化が存在しないか、標準に達していません。 この場合、要件の収集は XNUMX 段階のプロセスになります。最初に既存のプロセスをリバース エンジニアリングし、次に改善と最適化が必要な領域を特定します。 要件が具体的で正確であることを確認するには、主要な利害関係者と対象分野の専門家を特定し、直接関与することが重要です。 ビジネス プロセス マップの描画とワークフローの視覚化は、そのための XNUMX つの優れた方法です。 これは、全体像を提供しながら、誤った仮定を排除するのに役立ちます。 プロセス マップの描画とプロセスの表示は、この目的に役立つ XNUMX つの方法です。

相反する要件 – 利害関係者がビジネス目標に対して異なる優先順位を持っている場合、これは互いに競合する要件につながります。 このような場合、ビジネス アナリストの責任は、すべての要件を詳細に文書化し、どの要求が相反するかを特定し、利害関係者が優先順位を決定する機会を与えることです。

利害関係者の意見を聞くことなく決定を下すことはできません。また、ビジネス アナリストとして、何を優先すべきかについていくつかのアイデアを持っているかもしれません。 利害関係者の視点を聞くことは依然として重要です。 世論調査を設定することは、大多数の利害関係者にとって何が最も重要かを明確にする方法の XNUMX つかもしれません。

ユーザー入力の利用不可 – いくつかの理由により、エンド ユーザーが利用できなくなる可能性があり、それぞれに独自の解決策が必要です。 たとえば、エンド ユーザーが日常業務に没頭しすぎて、要件収集活動に参加したくない場合があります。

このような場合、ビジネス アナリストができる最善の方法は、エンゲージメントの数と長さを制限することです。 会議の前に、できるだけ多くの調査を行うと、議論がより組織的で有益なものになります。 これは、要件の収集を要件の検証セッションに変えるようなものです。 フォーカス グループを定義し、各グループに最適なエンド ユーザーを特定する

経験ではなくインターフェースに焦点を当てる – 多くの利害関係者とエンド ユーザーは、新しいソリューションがどのように表示されるべきかについて明確なビジョンを持っていますが、それが何を達成すべきかを知りません。 どのシステムのユーザー インターフェイスも重要ですが、機能を定義したり干渉したりしてはなりません。

ビジネス アナリストは、ドキュメント内で設計要件と機能要件を区別することを常に忘れないでください。 設計ドラフトではなく、ダイアグラム、ユーザー ストーリー、ローファイ プロトタイプなどのより一般的なツールを使用することで、要件収集の機能面に集中することができます。

利害関係者のインプット – 利害関係者またはエンドユーザーが、システムが何をすべきかではなく、システムがどのように機能すべきかを設計者に伝えようとすると、最適ではない設計につながる可能性があります。 これを回避するには、「なぜ?」と尋ねて、潜在的な「誤った要件」を検証します。 解決が必要な本当の問題に到達するまで。

コミュニケーションの問題 – ビジネス アナリストと他の関係者の間の誤解につながる可能性のある問題には、言葉の壁、間違った前提、不十分な語彙の説明、専門用語の乱用などがあります。

この問題を回避するための理想的なアプローチは、頻繁に対話し、双方向の会話を展開することです。 発見したニーズを文書化し、ピア レビューとさまざまな主題の専門家への批評のために提出し、専門用語の用語集を作成し、前提を再確認します。

要件を書くための基準？

ここでは、EARS が効果的な方法論となります。 それは Eアッシー Aへのアプローチ R備品 Sシンタックス、Alastair Marvin 著。 この方法では、明確で簡潔でわかりやすい言葉を書きます。 これにより、要件エンジニアリングのワークフロー全体が改善され、物事が非常に理解しやすくなるため、作業が簡素化されます。 

これを達成するために、要件を作成する際に留意しなければならないいくつかの原則があります。 それらは以下を含みます：

• 各要件は、完全な文の形式である必要があります。 箇条書き、頭字語、略語、流行語は使用しないでください。 短く、直接的で、完全な文を作るようにしてください。 
• 各要件に適切な主語、述語、動詞があることを確認してください。 件名は、私たちが話しているユーザータイプまたはシステムになります。 述語は、私たちが期待する条件またはアクションまたは望ましい結果になります。 ある種の必要性を表すには「shall」、「will」、「must」などの単語を使用する必要があり、要件のオプション性を表すには「may」などの単語を使用する必要があります。 
• 各要件は、システムに求める最終結果を効率的に説明する必要があります。 
• また、要件には、システムに期待する品質を記述する必要があります。 これは、最終結果を測定し、要件が適切に実装されているかどうかを確認するときに役立ちます。

要件ドキュメントの必須コンポーネント:

ソフトウェア要件仕様の主なセクションは次のとおりです。

• ビジネスドライバー – このセクションでは、お客様がシステムを構築しようと考えている理由について説明します。 このセクションには、お客様が現在のシステムで直面している問題と、新しいシステムが提供する機会が含まれています。
• ビジネスモデル – このセクションでは、システムがサポートするビジネス モデルについて説明します。 さらに、組織やビジネスのコンテキスト、主なビジネス機能、システムのプロセス フロー図など、さまざまな詳細が含まれます。
• 機能要件とシステム要件 – 通常、このセクションでは、階層構造で編成された要件について詳しく説明します。 機能要件は最上位にあり、詳細なシステム要件はサブ項目としてリストされています。
• システムのユースケース – このセクションは、システムと対話するすべての主要な外部エンティティと、実行する必要があるさまざまなユース ケースを説明する統一モデリング言語 (UML) のユース ケース図で構成されています。
• 技術要件 – このセクションでは、技術環境を構成するすべての非機能要件と、ソフトウェアが動作する技術的な制限について説明します。  
• システムの品質 – このセクションでは、信頼性、保守性、セキュリティ、スケーラビリティ、可用性、保守性など、システムのさまざまな品質が定義されています。
• 制限と仮定 – このセクションでは、顧客の観点からシステム設計に課されるすべての制限について説明します。 開発中に何を期待するかについてのエンジニアリング チームによるさまざまな仮定についても、ここで説明します。
• 受け入れ基準 – システムが最終顧客に引き渡される前に満たすべきすべての条件の詳細については、このセクションで説明します。

ソフトウェア要件仕様書の特徴:

• クリア – 書面による要件は、明確で読みやすく、理解しやすいものでなければなりません。 アクター間で交換する肯定的な文を使用して、情報を明確に指定します。 すべての要件は、明確な成功基準を記述する必要があります。 簡単な語彙を使用し、略語を避けるようにしてください。 たとえば、「ユーザーは監査ログ レポートを表示できる必要があります」。
• アトミック – 各要件は個別のテスト ケースとして扱う必要があります。 and、or などの接続詞は、要件を見逃す可能性があるため、使用しないでください。 このような用語は、ソフトウェア開発者やテスターが要件を見落とす可能性があるため、これは特に重要です。 複雑なニーズを小さな部分に分割して、それぞれを個別にテストできるようにすることは、これを防ぐ XNUMX つの方法です。
• 明確な – 不明確、不完全、または矛盾する要件は、エラーややり直しにつながる可能性があります。 これが起こらないようにするには、最終決定する前にすべての利害関係者が要件を確認する必要があります。 これにより、ギャップを早期に特定し、対処することができます。
• 検証可能 – 必要に応じて何度でも参照できるように、開発チームの全員がドキュメントにアクセスできる必要があります。 要件は明確でなければならないため、チーム メンバーはそれ以上の情報を必要としません。 これらはすべて、SRS ドキュメントでアクセスできる必要があります。
• Necessary – 各要件は、ユーザーが実際に必要とするもの、または外部インターフェースの存在による標準または統合のニーズを満たすために必要なものを文書化する必要があります。 また、各要件が承認されたソースを持つことが重要です。
• デザインに依存しない – 各要件は、実装方法ではなく、何が必要かを定義する必要があります。 要件は、内部の詳細ではなく、外部から観察されるシステムの特性を定義する必要があります。
• 実現可能な – 各要件は技術的に実行可能である必要があり、プロジェクトに影響を与える予算、期限、およびその他の制限を考慮して実装する必要があります。 要件は、コスト、タイムライン、テクノロジーなど、実際の状況を反映する必要があります。 将来の技術進歩に左右されるべきではありません。
• 完全 – 要件ドキュメントには、開発チームとテスターが製品を完成させ、バグなしでユーザーの要件を満たしていることを確認するのに十分な情報を含める必要があります。
• 正解 – ドキュメントで指定された要件は、混乱を避けるために非常に正確である必要があります。 抜け穴、あいまいさ、主観性、最上級、または比較があってはなりません。 したがって、正しい要件を記述するには、正しい情報を取得し、収集した情報を正しく文書化する必要があります。

一連の正しい要件のルール

要件が「正しい」と呼ばれるために遵守しなければならない特定の規則があります。

• 完全 – 要件ドキュメントには、開発チームとテスターが製品を完成させ、バグなしでユーザーの要件を満たしていることを確認するのに十分な情報を含める必要があります。
• 一貫性 – 一貫した詳細レベルを維持します。 たとえば、ユーザーの要件については、エンド ユーザーをすべての文の主語にする必要があります。 同様に、システム要件については、システムをすべての文の主語にする必要があります。
• 変更可能性 – 要件は、プロジェクトのライフサイクルを通じて変化する可能性があります。 要件ログは保存する必要があり、変更が他の要件やプロジェクト要素に与える影響を分析できる必要があります。
• 優先順位付け – 要件は重要度の観点から分類する必要があります。 システムに必要なすべての特性が等しく重要であるとは限りません。 そのためには、組織レベルで要件の優先順位を定義するルールを確立し、それを各プロジェクトに適応させることが役立つでしょう。 また、ユーザーが要件に優先順位を付けることができるように、ユーザーと協力してください。

視界要件ALMプラットフォーム

Visure は、世界中のあらゆる規模の組織の要件管理に特化した、最も信頼できるアプリケーション ライフサイクル管理プラットフォームの XNUMX つです。 Visure の主要なパートナーには、ビジネスに不可欠な企業や安全に不可欠な企業が含まれます。 同社は、リスク管理、問題と欠陥の追跡、トレーサビリティ管理、変更管理、および品質分析、要件のバージョン管理、強力なレポート作成などのさまざまな分野を含むアプリケーション ライフサイクル管理プロセス全体を統合します。  

機能要件と非機能要件の両方に役立つ要件管理ツールをお探しの場合は、Visure Requirements をご覧ください。 このプラットフォームを使用すると、プロジェクトのすべての要件を XNUMX か所で簡単に作成、管理、追跡できます。

まとめ

優れたソフトウェアを作成するには、適切に記述された要件仕様を持つことが重要です。 このドキュメントでは、顧客のニーズと、顧客の期待に応えるためにシステムが何をする必要があるかについて概説します。 ただし、適切な要件を記述することは困難な場合があります。 従わなければならない多くの標準とガイドラインがあり、使用する言語とツールに応じて、それらを記述するさまざまな方法があります。 Visure Requirements ALM Platform では、ベスト プラクティスと業界標準を使用して効果的な要件仕様を作成する方法を説明するコースを提供しています。 このコースでは、構造からフォーマットまで、要件ドキュメントのすべての重要なコンポーネントと、要件を記述するためのさまざまな言語の使用方法について説明します。 また、優れた要件の特徴を強調しているため、チームが気に入って作業できるドキュメントを作成できます。 効果的な要件の記述について詳しく知りたい場合は、 要件仕様コース 今日、Vision Requirements ALM プラットフォームで!