# 示例軟件需求分析 > 原文： [https://www.guru99.com/learn-software-requirements-analysis-with-case-study.html](https://www.guru99.com/learn-software-requirements-analysis-with-case-study.html) 軟件需求是系統中要實現的功能性或非功能性需求。 功能性意味著向用戶提供特定服務。 例如，對于銀行應用程序，功能要求將是客戶選擇“查看余額”時，他們必須能夠查看其最新帳戶余額。 軟件需求也可以是非功能性的，也可以是性能需求。 例如，非功能性要求是系統的每個頁面都應在 5 秒內對用戶可見。 因此，基本上**的軟件要求是** * 功能或 * 無功能 **需要已在系統中實現的**。 **軟件需求通常表示為陳述。** **在本教程中，我們將學習** * [需求類型](#1) * [其他要求來源](#2) * [如何分析需求](#3) * [原子](#4) * [唯一標識的](#5) * [完成](#6) * [一致且明確](#7) * [可追溯的](#8) * [已優先處理](#9) * [可測試的](#10) * [結論](#11) ### 要求類型 1. **Business requirements**: They are high-level requirements that are taken from the business case from the projects. 例如，移動銀行服務系統向東南亞提供銀行服務。 針對印度確定的業務需求是帳戶摘要和資金轉賬，而針對中國賬戶摘要和賬單支付則確定為業務需求 | 國家 | 提供銀行功能或服務的公司 | | 印度 | 帳戶摘要和資金轉帳 | | 中國 | 帳戶摘要和帳單支付 | 2. **Architectural and Design requirements**: These requirements are more detailed than business requirements. It determines the overall design required to implement the business requirement. 對于我們的教育機構，建筑和設計用例將是登錄名，課程詳細信息等。要求如下所示。 | 銀行用例 | 需求 | | 繳費 | 該用例描述了客戶如何登錄到網上銀行并使用賬單支付工具。 客戶將看到已注冊開票人的未結帳單的儀表板。 他可以添加，修改和刪除開票人明細。 客戶可以為不同的計費操作配置 SMS，電子郵件警報。 他可以查看過去已付??帳單的歷史記錄。 啟動此用例的參與者是銀行客戶或支持人員。 | 3. **System and Integration requirements**: At the lowest level, we have system and integration requirements. It is detailed description of each and every requirement. It can be in form of user stories which is really describing everyday business language. The requirements are in abundant details so that developers can begin coding. 在“帳單支付”模塊的示例中，將提到添加帳單的要求 | 繳費 | 要求 | | 添加帳單 | * 公用程序提供商名稱 * 關系/客戶編號 * 自動付款–是/否 * 支付整個賬單–是/否 * 自動付款限額–如果賬單超過指定金額，請勿付款 | 有時對于某些項目，您可能沒有收到任何要求或文檔。 但是，您仍然可以考慮需求的其他來源或需求信息，以便可以將軟件或測試設計基于這些需求。 因此，您可以依賴的其他需求來源是 ### 其他要求來源 * 來自已經在該項目上工作的同事或員工的知識轉移 * 與業務分析師，產品經理，項目負責人和開發人員討論項目 * 分析已在系統中實現的先前系統版本 * 分析項目的較早需求文件 * 查看過去的錯誤報告，一些錯誤報告被轉換為增強功能，可以實施為當前版本 * 查看安裝指南（如果有）以查看需要進行的安裝 * 分析團隊嘗試實施的領域或行業知識 無論您有什么要求來源，請確保以某種形式記錄下來，并請其他經驗豐富且知識淵博的團隊成員進行審核。 ### 如何分析需求 考慮一個教育軟件系統的示例，學生可以在其中注冊不同的課程。 讓我們研究如何分析需求。 需求必須保持其需求的標準質量，不同類型的需求質量包括 * 原子 * 唯一識別 * 完成 * 始終如一 * 可追溯的 * 優先 * 可測  讓我們以一個示例來了解這一點，此處顯示的表格中有三列， 1. 第一列表示“要求質量” 2. 第二列指出-“有問題的不良要求” 3. 第三列與第二列相同，但–“已轉換為良好要求”。 | 需求質量 | 不良要求的例子 | 良好要求的例子 | | 原子 | * 學生將可以報讀本科和研究生課程 | * 學生將能夠報讀本科課程 * 學生將能夠報讀研究生課程 | | 唯一識別 | 1-學生將能夠注冊本科課程 1-學生將能夠注冊研究生課程 | 1. 課程注冊 2. 學生將能夠注冊本科課程 3. 學生將能夠注冊研究生課程 | | 完成 | 教授用戶將通過提供用戶名，密碼和其他相關信息來登錄系統 | 教授用戶將通過提供其用戶名，密碼和部門代碼來登錄系統 | | 始終如一 | 學生將修讀本科課程或研究生課程，但不能同時修讀這兩種課程。 一些課程將對本科生和研究生開放 | 一個學生將擁有本科生或研究生，但不能同時擁有兩者 | | 可追溯的 | 維持學生信息映射到 BRD req.ID？ | 維護與 BRD req ID 4.1 對應的學生信息 | | 優先 | 注冊學生優先級 1 維護用戶信息優先級 1 注冊課程優先級 1 查看成績單優先級 1 | 注冊學生優先級 1 維護用戶信息優先級 2 注冊課程優先級 1 查看成績單優先級 3 | | 可測 | 系統的每一頁將在可接受的時間范圍內加載 | 注冊學生并注冊系統的頁面將在 5 秒鐘內加載 | 現在，讓我們從原子開始詳細了解每個需求。 #### 原子  因此，您的每一項要求都應該是原子性的，這意味著它應該處于非常低的詳細程度，因此不可能分離成組件。 在這里，我們將在原子和唯一標識的需求級別上看到這兩個需求示例。 因此，讓我們繼續以教育領域的系統構建為例。 在這里，不好的要求是“學生將能夠報名參加本科和研究生課程”。 這是一個不好的要求，因為它不是原子的，因為它涉及兩個不同的實體本科生和研究生課程。 因此，顯然這不是一個好的要求，而是不好的要求，因此對應的好的要求就是將其分為兩個要求。 因此，一個人談論的是本科課程的入學率，而另一個人談論的是研究生課程的入學率。 #### 唯一標識  同樣，下一個需求質量是檢查唯一標識的需求，這里我們有兩個單獨的需求，但是它們都有相同的 ID＃1。 因此，如果我們參考 ID＃來引用我們的需求，但是由于兩者都具有相同的 ID＃1，我們所參考的是文檔或系統的其他部分并不清楚是哪個確切的需求。 因此，用唯一的 ID 分開，這樣好的要求將在第 1 節課程注冊中重新返回，并且有兩個要求：1.1 ID 是本科課程的入學率，而 1.2 ID 是研究生課程的入學率。 #### 完成  同樣，每個要求都應完整。 例如，此處的錯誤要求是“教授用戶將通過提供其用戶名，密碼和其他相關信息來登錄系統”。 這里其他相關信息不清楚，因此應以良好的要求將其他相關信息詳細說明以使要求完整。 #### 一致且明確  接下來，每個要求都應保持一致且明確，因此在此例如我們有一個要求：“一個學生將修讀本科課程或研究生課程，但不能同時修讀這兩個課程”，這是一個要求，還有其他要求則是“某些課程將 向本科生和研究生開放”。 該要求中的問題在于，從第一個要求開始，似乎將課程分為研究生課程和研究生課程兩類，并且學生可以選擇兩者之一，但不能同時選擇兩者。 但是，當您閱讀其他要求時，就會與第一個要求發生沖突，并告訴您某些課程將對研究生和本科生開放。 因此，很明顯將這個不好的要求轉換為很好的要求，即“一個學生將擁有本科課程或研究生課程，但不能同時擁有這兩個課程”。 這意味著每門課程都將被標記為本科課程或研究生課程 #### 可追溯  每個需求都應該是可追溯的，因為已經有不同級別的需求，我們已經看到在頂部我們有業務需求，然后是架構和設計需求，然后是系統集成需求。 現在，當我們將業務需求轉換為架構和設計需求，或者將架構和設計需求轉換為系統集成需求時，必須具有可追溯性。 這意味著我們應該能夠滿足每一項業務需求，并將其映射到相應的一個或多個軟件體系結構和設計需求。 因此，這是一個錯誤要求的示例，上面寫著“維護學生信息-映射到 BRD 請求 ID？”。 此處未提供需求 ID。 因此，將其轉換為一個好的需求時會說同樣的事情，但是它被映射為需求 ID 4.1。 因此，應該為每個需求提供映射。 以同樣的方式，我們具有高低級映射需求，系統和集成需求之間也存在對實現該需求的代碼的映射，并且系統和集成需求之間也存在對測試該特定需求的測試用例的映射 。 因此，這種可追溯性遍及整個項目 #### 優先 | Prioritized | 注冊學生優先級 1 維護用戶信息優先級 1 報名課程-優先級 1 查看報告卡-優先級 1 | 注冊學生優先級 1 維護用戶信息優先級 2 注冊課程優先級 1 查看報告卡優先級 3 | 然后，必須對每個需求進行優先級排序，以便團隊制定指導原則，以便能夠先實施哪些需求，然后再完成。 在這里您可以看到不良優先級已經注冊了學生，維護了用戶信息，并且每個需求都賦予了優先級-1。 并非所有事物都具有相同的優先級，因此可以優先考慮需求。 因此，此處的良好要求示例是注冊學生和注冊課程的優先級最高，同時保持用戶信息的優先級低于 2，然后我們以優先級 3 查看報告卡 #### 可測試 | 可測 | 系統的每一頁將在可接受的時間范圍內加載 | 注冊學生并注冊系統的頁面將在 5 秒鐘內加載 | 每個需求都應該是可測試的，這里的糟糕需求是“系統的每個頁面都將在可接受的時間范圍內加載”。 現在，此要求存在兩個問題，首先是每個頁面意味著可以有很多頁面，這將浪費測試工作。 另一個問題是它說頁面將在可接受的時間范圍內加載，現在什么是可接受的時間范圍？ 可以接受誰。 因此，我們必須將不可測試的參數轉換為可測試的參數，該參數明確說明了我們正在談論的頁面是“注冊學生并注冊課程頁面”，并且給出了可接受的時間范圍，即 5 秒。 #### 總結 因此，這就是我們必須在適當級別上查看每個需求的方式。 例如，如果我們要構建有關系統和集成需求的軟件。 我們必須查看軟件需求規范或用戶案例中給出的系統和集成需求，并將其應用于每個需求質量。 然后檢查每個需求是否都是原子的，唯一標識的和完整的，等等。