ソフトウェア要件分析と例
チャールズ・ムーア
⚡ スマートサマリー
ソフトウェア要件分析では、利害関係者のニーズを機能的および非機能的な記述に分解し、ビジネス、アーキテクチャ、およびシステムレベルでランク付けし、テスト可能、 trac実行可能で優先順位付けされた仕様。
ソフトウェア要件とは、システムに実装されなければならない機能的または非機能的なニーズのことである。機能的とは、ユーザーに特定のサービスを提供することを意味する。
例えば、銀行アプリケーションの文脈では、顧客が「残高照会」を選択した際に、最新の口座残高を確認できることが機能要件となります。
ソフトウェア要件には、パフォーマンス要件のような非機能要件も含まれます。例えば、非機能要件として、システムのすべてのページがユーザーに対して5秒以内に読み込まれる必要がある、といったことが挙げられます。
だから基本的に ソフトウェア要件は
- 機能的または
- 機能しない
必要 それをシステムに実装する必要があります。 ソフトウェア要件は通常、記述形式で表現される。
要件の種類
ビジネス要件これらは、プロジェクトのビジネスケースから抽出された高レベルの要件です。例えば、モバイルバンキングサービスシステムは東南アジアに銀行サービスを提供します。インド向けに決定されたビジネス要件は口座概要と資金送金であり、中国向けには口座概要と請求書支払いとなっています。
| 国 | 銀行機能またはサービスを提供する会社 |
|---|---|
| India | 口座概要と資金移動 |
| アカウントの概要と Bill お支払い |
Archi構造要件と設計要件これらの要件は、ビジネス要件よりも詳細であり、ソリューションアーキテクチャの指針となります。これらは、ビジネス要件を実装するために必要な全体的な設計を決定します。教育機関の場合、典型的なアーキテクチャおよび設計のユースケースには、ログイン、コースの詳細、登録などがあります。要件は以下のようになります。
| 銀行のユースケース | 要件 |
|---|---|
| Bill お支払い | この使用例では、顧客がネット バンキングにログインし、 Bill 決済機能。顧客は、登録済みの請求先に対する未払い請求書のダッシュボードを確認できます。顧客は、請求先の詳細を追加、変更、削除できます。顧客は、さまざまな請求アクションに対してSMSおよびメールアラートを設定できます。顧客は、過去に支払った請求書の履歴を表示できます。このユースケースを開始する主体は、銀行の顧客またはサポート担当者です。 |
システムと統合の要件: 最も低いレベルでは、システム要件と統合要件があります。これは、すべての要件の詳細な説明を提供します。これは、日常的なビジネス言語で書かれたユーザーストーリーとして捉えることができます。要件には、開発者がコーディングを開始できるように、豊富な詳細が含まれています。 Bill 以下の支払いモジュールの例は、請求元を追加するための要件を示しています。
| Bill お支払い | 要件 |
|---|---|
| 追加 BillERS | 公共料金提供事業者名、顧客番号、自動支払い（はい／いいえ）、全額支払い Bill – はい/いいえ、自動支払い限度額 – 支払いをしない場合は、支払いをしないでください。 Bill 規定量を超えている |
プロジェクトによっては、要件や作業に必要なドキュメントが一切提供されない場合もあります。しかし、そのような場合でも、ソフトウェアやテストの設計の基盤となる要件情報を入手できる他の情報源があります。以下に、利用できるその他の要件情報源を示します。
要件のその他のソース
- すでにそのプロジェクトに取り組んでいる同僚や従業員からの知識の伝達
- ビジネスアナリスト、プロダクトマネージャー、プロジェクトリーダー、開発者とプロジェクトについて話し合う
- 既に導入済みのシステムの以前のバージョンを分析する
- プロジェクトの古い要件文書を分析する
- Rev過去のバグ報告を閲覧します。一部のバグ報告は、現在のバージョンで実装される可能性のある機能強化リクエストに変換されます。
- インストールガイドが利用可能な場合は、必要なインストール内容を確認してください。
- チームが実装しようとしているドメイン知識または業界知識を分析する
要件の出典が何であれ、それらを共通の形式で文書化し、経験豊富なチームメンバーにレビューしてもらいましょう。
要件を分析する方法
学生がさまざまなコースに登録できる教育ソフトウェアシステムを例に考えてみましょう。
要件の分析方法について見ていきましょう。各要件は、以下の項目を含む一連の標準的な品質属性を維持する必要があります。
- Atomic
- 一意に識別される
- 完全
- 一貫性と明確さ
- Trac可能
- 優先
- テスト可能
以下の表は、各属性を3つの列で示しています。
- 最初の列は「要求品質」を示します。
- XNUMX 番目の列は、「何らかの問題を伴う不適切な要件」を示します。
- 3列目には、同じ要件を「適切な要件に変換したもの」が示されています。
| 要求品質 | 悪い要件の例 | 良い要件の例 |
|---|---|---|
| Atomic | 学生は学部および大学院コースに登録できるようになります | 学生は学部課程に登録できます。学生は大学院課程に登録できます。 |
| 一意に識別される | 1. 学生は学部課程に登録できます。 1. 学生は大学院課程に登録できます。 | 履修登録。学生は学部課程に登録できます。学生は大学院課程に登録できます。 |
| 完全 | 教授ユーザーは、ユーザー名、パスワード、その他の関連情報を入力してシステムにログインします。 | 教授ユーザーは、ユーザー名、パスワード、学部コードを入力してシステムにログインします。 |
| 一貫性と明確さ | 学生は学部コースまたは大学院コースのいずれかを受講しますが、両方を受講することはできません。 一部のコースは学部生と大学院生の両方に公開されます | 学生は学部か大学院のいずれかを取得しますが、両方を取得することはできません |
| Trac可能 | BRD 要求 ID にマッピングされた学生情報を維持しますか? | 学生情報の維持 - BRD 要求 ID 4.1 にマッピング |
| 優先 | 登録済み学生 - 優先度 1。ユーザー情報の管理 - 優先度 1。コース登録 - 優先度 1。成績表の閲覧 - 優先度 1 | 学生登録 - 優先度1。ユーザー情報の管理 - 優先度2。コース登録 - 優先度1。成績表の閲覧 - 優先度3 |
| テスト可能 | システムの各ページは許容可能な時間枠で読み込まれます。 | システムの学生登録ページとコース登録ページは 5 秒以内にロードされます |
それでは、これらの属性をそれぞれ詳しく見ていきましょう。 AtomIC。
Atomic
すべての要件はアトミックであるべきです。つまり、要件は最も詳細度の高いレベルで記述され、それ以上細分化できないものでなければなりません。以下の例では、アトミックな要件と非アトミックな要件を比較しています。
教育ドメインシステムの例を続けて見てみましょう。ここで、不適切な要件は「学生は学部課程と大学院課程に登録できる」です。これは、学部課程と大学院課程という2つの異なる要素を混在させているため、アトミックではないという点で不適切な要件です。これに対応する適切な要件は、これを2つの要件に分割しています。1つは学部課程への登録を、もう1つは大学院課程への登録をそれぞれ対象としています。
一意に識別される
次の品質特性は、一意の識別です。悪い例では、2つの異なる要件が同じID#1を共有しています。チームが要件をそのIDで参照すると、どちらの要件を指しているのかが不明確になります。良い要件では、それらをセクション1「コース登録」の下に再編成し、サブ要件として1.1（学部コースへの登録）と1.2（大学院コースへの登録）を設定しています。
完全
すべての要件は完全であるべきです。例えば、この不適切な要件では、「教授ユーザーは、ユーザー名、パスワード、およびその他の関連情報を入力してシステムにログインする」とありますが、「その他の関連情報」は曖昧です。完全な要件では、教授が提供しなければならない具体的な項目（例えば、学科コードなど）を列挙する必要があります。
一貫性と明確さ
すべての要件は、一貫性があり、曖昧さのないものでなければなりません。悪い例では、ある要件では「学生は学部課程または大学院課程のいずれか一方のみを履修するものとする」と規定されている一方で、別の要件では「一部のコースは学部生と大学院生の両方に開放される」と規定されています。
最初の要件は、コースが2つの排他的なカテゴリーに分けられることを示唆しているが、2番目の要件は、一部のコースを両方のグループに開放することで、最初の要件と矛盾している。
この適切な要件は、すべてのコースが学部課程か大学院課程のいずれかに分類され、学生はいずれか一方のカテゴリーのコースにしか登録できないことを明確に規定することで、矛盾を解消している。
Trac可能
すべての要件は trac要件がビジネス、アーキテクチャと設計、システムと統合といった複数のレベルに存在するため、実現可能である。
ビジネス要件をアーキテクチャおよび設計要件に変換する場合、またはアーキテクチャおよび設計要件をシステムおよび統合要件に変換する場合、 trac互換性は維持されなければなりません。すべての業務要件は、1つ以上のアーキテクチャおよび設計要件にマッピングされる必要があります。悪い例である「学生情報を維持する - BRD要件IDにマッピングされますか？」では、要件IDが欠落しています。
適切な要件では同じ記述を記録しますが、BRD 要件 ID 4.1 に明示的にマッピングします。すべての要件には、 tracアクセシビリティマップpingシステム要件と統合要件は、それらを実装するコードと、それらを検証するテストケースにも対応している必要があります。
Tracしたがって、eabilityはプロジェクト全体にわたってエンドツーエンドで機能します。
優先
チームが最初に実装すべきものと後回しにできるものを把握できるよう、すべての要件に優先順位を付ける必要があります。悪い例では、「学生登録」、「ユーザー情報の管理」、「コース登録」、「成績表の表示」がすべて優先度1に設定されています。すべてを優先度1にすることはできないため、要件は現実的にランク付けする必要があります。良い例では、「学生登録」と「コース登録」に最高の優先度1、「ユーザー情報の管理」に優先度2、「成績表の表示」に優先度3が設定されています。
テスト可能
すべての要件はテスト可能であるべきです。「システムの各ページは許容時間内に読み込まれる」という悪い例は、2つの理由からテスト不可能です。第一に、「各ページ」とは数十ページを意味する可能性があり、テスト作業が膨大になります。第二に、「許容時間」が定義されていません。誰にとって許容できるのか、どのような基準に対して許容できるのかが不明確です。良い要件では、具体的なページ名（「学生登録ページ」と「コース登録ページ」）を指定し、測定可能な目標値を5秒に設定することで、これらの問題を解決しています。
