ソフトウェア要件分析と例

ソフトウェア要件は、システムに実装するための機能的または非機能的なニーズです。機能的とは、ユーザーに特定のサービスを提供することを意味します。

たとえば、銀行アプリケーションの場合、機能要件は、顧客が「残高の表示」を選択したときに、最新の口座残高を確認できる必要があることです。

ソフトウェア要件は、機能以外の要件である場合もありますし、パフォーマンス要件である場合もあります。たとえば、非機能要件は、システムのすべてのページが 5 秒以内にユーザーに表示される必要があることです。

だから基本的に ソフトウェア要件は

機能的または
機能しない

必要それをシステムに実装する必要があります。 ソフトウェア要件は通常、ステートメントとして表現されます。

要件の種類

ビジネス要件: これらは、プロジェクトのビジネスケースから抽出された高レベルの要件です。たとえば、モバイルバンキングサービスシステムは、東南アジアに銀行サービスを提供します。インド向けに決定されたビジネス要件は口座概要と資金振替ですが、中国向けには口座概要と請求書の支払いがビジネス要件として決定されます。

国家	銀行機能またはサービスを提供する会社
インド	口座概要と資金移動
中国	アカウントの概要と Bill お支払について

Archi構造要件と設計要件: これらの要件は、ビジネス要件よりも詳細です。ビジネス要件を実装するために必要な全体的な設計を決定します。私たちの教育機関の場合、アーキテクチャと設計のユースケースは、ログイン、コースの詳細などです。要件は以下のようになります。

銀行のユースケース	要件
Bill お支払について	この使用例では、顧客がネットバンキングにログインし、 Bill 支払い施設。顧客は、登録された請求者の未払い請求書のダッシュボードを見ることができます。請求者の詳細を追加、変更、削除できます。顧客は、さまざまな請求アクションに対して SMS や電子メールのアラートを設定できます。過去に支払った請求書の履歴を見ることができます。このユースケースを開始する主体は、銀行の顧客またはサポート担当者です。

システムと統合の要件: 最も低いレベルでは、システムと統合の要件があります。これは、すべての要件の詳細な説明です。これは、日常のビジネス言語を実際に記述するユーザーストーリーの形式になることがあります。要件は詳細に記述されているため、開発者はコーディングを開始できます。ここでは、 Bill 追加の要件が記載される支払いモジュール Biller

Bill お支払について	要件
Add BillERS	ユーティリティプロバイダー名関係顧客番号自動支払い – はい/いいえ全額支払う Bill - はい・いいえ自動支払い制限 - 次の場合は支払わないでください Bill 規定量を超えている

プロジェクトによっては、作業に必要な要件やドキュメントを受け取らない場合があります。ただし、要件や情報について考慮できる要件のソースは他にもあり、これらの要件に基づいてソフトウェアやテストの設計を行うことができます。したがって、信頼できる要件に関する他のソースは次のとおりです。

要件のその他のソース

すでにそのプロジェクトに取り組んでいる同僚や従業員からの知識の伝達
ビジネスアナリスト、プロダクトマネージャー、プロジェクトリーダー、開発者にプロジェクトについて話す
すでにシステムに実装されている以前のシステムバージョンを分析する
プロジェクトの古い要件ドキュメントを分析する
過去のバグレポートを調べてください。バグレポートの一部は、現在のバージョンに実装される可能性のある機能拡張リクエストに変換されています。
インストールガイドが利用可能な場合は、インストールに必要なものを確認してください。
チームが実装しようとしているドメインまたは業界の知識を分析する

要件のソースが何であれ、必ず何らかの形式で文書化し、他の経験と知識のあるチームメンバーからレビューしてもらいます。

要件を分析する方法

学生がさまざまなコースに登録できる教育ソフトウェアシステムの例を考えてみましょう。

要件を分析する方法を勉強しましょう。要件はその要件の標準品質を維持する必要があります。さまざまなタイプの要件品質には以下が含まれます。

Atomic
一意に識別される
完全
一貫性と明確さ
トレーサブル
優先
テスト可能

これを例で理解してみましょう。ここに示されているテーブルには XNUMX つの列があります。

最初の列は「要求品質」を示します。
XNUMX 番目の列は、「何らかの問題を伴う不適切な要件」を示します。
XNUMX 番目の列は XNUMX 番目の列と同じですが、「適切な要件に変換されています」。

要求品質	悪い要件の例	良い要件の例
Atomic	学生は学部および大学院コースに登録できるようになります	学生は学部コースに入学できるようになります学生は大学院コースに登録できるようになります
一意に識別される	1- 学生は学部コースに登録できるようになります1- 学生は大学院コースに登録できるようになります	コース登録学生は学部コースに入学できるようになります学生は大学院コースに登録できるようになります
完全	教授ユーザーは、ユーザー名、パスワード、その他の関連情報を入力してシステムにログインします。	教授ユーザーは、ユーザー名、パスワード、学部コードを入力してシステムにログインします。
一貫性と明確さ	学生は学部コースまたは大学院コースのいずれかを受講しますが、両方を受講することはできません。一部のコースは学部生と大学院生の両方に公開されます	学生は学部か大学院のいずれかを取得しますが、両方を取得することはできません
トレーサブル	BRD 要求 ID にマッピングされた学生情報を維持しますか?	学生情報の維持 - BRD 要求 ID 4.1 にマッピング
優先	登録済みの学生 - 優先度 1 ユーザー情報の維持 - 優先度 1 コースの登録 - 優先度 1 レポートカードの表示 - 優先度 1	学生の登録 - 優先度 1 ユーザー情報の維持 - 優先度 2 コースの登録 - 優先度 1 レポートカードの表示 - 優先度 3
テスト可能	システムの各ページは許容可能な時間枠で読み込まれます。	システムの学生登録ページとコース登録ページは 5 秒以内にロードされます

それでは、これらの要件をそれぞれ詳しく理解してみましょう。 AtomIC。

Atomic

したがって、すべての要件はアトミックでなければなりません。つまり、非常に低いレベルの詳細で、コンポーネントに分離できないようにする必要があります。ここでは、要件の2つの例を見てみましょう。 Atomic および一意に識別された要件レベル。

それでは、教育ドメインのシステム構築の例を続けましょう。ここで、悪い要件は「学生は学部課程と大学院課程に登録できる」です。これは、学部課程と大学院課程という 2 つの異なるエンティティについて言及しているため、原子性がなく、悪い要件です。したがって、明らかにこれは良い要件ではなく悪い要件であるため、対応する良い要件は、これを 2 つの要件に分割することです。つまり、1 つは学部課程への登録について言及し、もう 1 つは大学院課程への登録について言及します。

一意に識別される

同様に、次の要件品質は一意に識別されるかどうかを確認することです。ここでは 1 つの別個の要件がありますが、両方とも同じ ID#1 を持っています。そのため、ID# を参照して要件を参照している場合でも、どちらも同じ ID#1 を持っているため、ドキュメントまたはシステムの他の部分を参照している正確な要件が明確ではありません。したがって、一意の ID で分離すると、適切な要件がセクション 1.1- コース登録として再度返されます。これには 1.2 つの要件があります。XNUMX ID は学部コースへの登録であり、XNUMX ID は大学院コースへの登録です。

完全

また、すべての要件が満たされている必要があります。たとえば、ここでは悪い要件として、「教授ユーザーはユーザー名、パスワード、その他の関連情報を提供してシステムにログインする」と書かれています。ここでは、その他の関連情報が明確ではないため、要件を完全なものにするために、その他の関連情報を適切な要件に詳しく説明する必要があります。

一貫性と明確さ

次に、すべての要件は一貫性があり、明確である必要があります。たとえば、ここでは「学生は学部コースまたは大学院コースのいずれかを受講するが、両方を受講することはできません」という要件があります。これは XNUMX つの要件であり、「一部のコースでは、次のような要件があります。」学部生と大学院生の両方にオープンであること。」

この要件の問題は、最初の要件から、コースが大学院コースと大学院コースの XNUMX つのカテゴリーに分けられており、学生はその XNUMX つのいずれかを選択できますが、両方を選択することはできないことです。しかし、他の要件を読むと、最初の要件と矛盾しており、一部のコースは大学院生と学部生の両方に開かれていることがわかります。

したがって、この悪い要件を「学生は学部コースまたは大学院コースのいずれかを受講するが、両方を受講することはできない」という良い要件に変換することは明らかです。つまり、すべてのコースは学部コースまたは大学院コースのいずれかとしてマークされます。

トレーサブル

すでにさまざまなレベルの要件が存在するため、すべての要件は追跡可能である必要があります。最上位にはビジネス要件があり、次にアーキテクチャと設計の要件があり、その後にシステム統合の要件があることはすでに説明しました。

ここで、ビジネス要件をアーキテクチャおよび設計要件に変換する場合、またはアーキテクチャおよび設計要件をシステム統合要件に変換する場合は、追跡可能性が必要です。つまり、すべてのビジネス要件を取得して、対応する 1 つ以上のソフトウェアアーキテクチャおよび設計要件にマッピングできる必要があります。ここでは、「学生情報を維持する - BRD 要件 ID にマッピングしますか?」という不適切な要件の例を示します。ここでは要件 ID が指定されていません。

したがって、これを適切な要件に変換すると、同じことが言えますが、要件 ID 4.1 でマップされます。したがって、マッピングはあらゆる要件に対応する必要があります。高レベルと低レベルのマッピング要件があるのと同じように、システムと統合要件とその要件を実装するコードとの間にもマッピングがあり、システムと統合要件とその特定の要件をテストするテストケースとの間にもマッピングがあります。。

したがって、このトレーサビリティはプロジェクト全体にわたっています

優先

優先	登録済みの学生 - 優先度 1 ユーザー情報の保守 - 優先度 1 コースの登録 - 優先度 1 レポートカードの表示 - 優先度 1	学生の登録 - 優先度 1 ユーザー情報の保守 - 優先度 2 コースの登録 - 優先度 1 レポートカードの表示 - 優先度 3

次に、すべての要件に優先順位を付ける必要があるため、チームにはガイドラインがあり、どの要件を最初に実装し、どの要件を後で実行できるかが決まります。ここでは、学生登録、ユーザー情報の維持が不適切な優先順位であり、すべての要件に優先順位 1 が与えられていることがわかります。すべてを同じ優先順位にすることはできないため、要件に優先順位を付けることができます。ここでの適切な要件の例では、学生登録とコース登録に最高の優先順位 1 が与えられ、ユーザー情報の維持が優先順位 2 でそれより下になり、成績表の表示が優先順位 3 になります。

テスト可能

テスト可能	システムの各ページは許容可能な時間枠で読み込まれます。	システムの学生登録ページとコース登録ページは 5 秒以内にロードされます

すべての要件はテスト可能である必要があります。ここで悪い要件は、「システムの各ページが許容可能な時間枠で読み込まれる」ことです。この要件には 5 つの問題があります。まず、各ページは多数のページが存在する可能性があることを意味し、テスト作業が膨大になることです。もう XNUMX つの問題は、ページが許容可能な時間枠で読み込まれると表示されることです。許容可能な時間枠はどれくらいでしょうか? 誰にでも受け入れられます。したがって、テスト不可能な引数をテスト可能な引数に変換する必要があります。具体的には、どのページが「学生の登録とコースの登録ページ」について話しているのかを示し、許容可能な時間枠も XNUMX 秒として指定されます。

まとめ

このように、適切なレベルで各要件を検討する必要があります。たとえば、システム要件と統合要件に関してソフトウェアを構築する場合、ソフトウェア要件仕様またはユーザーストーリーで指定されたシステム要件と統合要件を検討し、各要件の品質に適用する必要があります。次に、各要件がアトミックで、一意に識別され、完全であるかどうかなどを確認します。