軟件需求

是指用戶對系統(tǒng)在功能、行為、性能、設計約束等方面的期望。
是指用戶解決問題或達到目標所需的條件或能力，是系統(tǒng)或系統(tǒng)部件要滿足合同、標準、規(guī)范或其他正式規(guī)定文檔所需具有的條件或能力，以及反映這些條件或能力的文檔說明。

兩大過程

需求開發(fā)->需求獲取、需求分析、需求定義（需求規(guī)劃說明書SRS）、需求驗證。
需求管理->變更控制、版本控制、需求跟蹤、需求狀態(tài)跟蹤。

三個層次

業(yè)務需求(business requirement)

反映了組織機構或客戶對系統(tǒng)、產(chǎn)品高層次的目標要求。

用戶需求(user requirement)

描述了用戶使用產(chǎn)品必須要完成的任務，是用戶對該軟件產(chǎn)品的期望。這兩種構成了用戶原始需求文檔的內(nèi)容。

功能需求 (functional requirement)

定義了開發(fā)人員必須實現(xiàn)的軟件功能，使得用戶能完成他們的任務，從而滿足業(yè)務需求。

非功能需求

作為補充，軟件需求規(guī)格說明還應包括非功能需求。
它描述了系統(tǒng)展現(xiàn)給用戶的行為和執(zhí)行的操作等。
它包括產(chǎn)品必須遵從的標準、規(guī)范和合約；外部界面的具體細節(jié)；性能要求；設計或實現(xiàn)的約束條件及質(zhì)量屬性。
所謂約束是指對開發(fā)人員在軟件產(chǎn)品設計和構造上的限制，常見的有設計約束和過程約束。
質(zhì)量屬性是通過多種角度對產(chǎn)品的特點進行描述，從而反映產(chǎn)品功能。多角度描述產(chǎn)品對用戶和開發(fā)人員都極為重要。

概述

需求工程是指應用已證實有效的原理、方法，通過合適的工具和記號，系統(tǒng)地描述待開發(fā)系統(tǒng)及其行為特征和相關約束。
需求工程覆蓋了體系結構設計之前的各項開發(fā)活動，主要包括分析客戶要求、對未來系統(tǒng)的各項功能性及非功能性需求進行規(guī)格說明。
需求工程的目標簡單明了：確定客戶需求，定義設想中系統(tǒng)的所有外部特征。

活動階段

1. 需求獲取
2. 形成需求規(guī)格(或稱之為需求文檔化)
   按照相關標準，生成需求模型的文檔描述，用戶原始需求書作為用戶和開發(fā)者之間的一個協(xié)約，往往被作為合同的附件；軟件需求描述規(guī)約作為后續(xù)軟件系統(tǒng)開發(fā)的指南。
3. 需求確認與驗證
   以需求規(guī)格說明為輸入，通過用戶確認、復審會議、符號執(zhí)行、模擬仿真或快速原型等途徑與方法，確認和驗證需求規(guī)格的完整性、正確性、一致性、可測試性和可行性，包含有效性檢查、一致性檢查、可行性檢查和確認可驗證性。
4. 需求管理
   包括需求文檔的追蹤管理、變更控制、版本控制等管理性活動。
   軟件需求開發(fā)的最終文檔經(jīng)過評審批準后，則定義了開發(fā)工作的需求基線 (Baseline)。 這個基線在客戶和開發(fā)者之間構筑了計劃產(chǎn)品功能需求和非功能需求的一個約定 (Agreement)。需求約定是需求開發(fā)和需求管理之間的橋梁。
   需求管理是一個對系統(tǒng)需求變更、了解和控制的過程。
   需求管理過程與需求開發(fā)過程相互關聯(lián)，當初始需求導出的同時就啟動了需求管理規(guī)劃，一旦形成了需求文檔的初稿，需求管理活動就開始了。需求管理的主要活動如圖：
   
   強調(diào)：
   （1）控制對需求基線的變動。
   （2）保持項目計劃與需求一致。
   （3）控制單個需求和需求文檔的版本情況。
   （4）管理需求和聯(lián)系鏈，或管理單個需求和其他項目可交付產(chǎn)品之間的依賴關系。
   （5）跟蹤基線中的需求狀態(tài)。

需求獲取

通過與用戶的交流，對現(xiàn)有系統(tǒng)的觀察及對任務進行分析，從而開發(fā)、捕獲和修訂用戶的需求。
需求獲取是一個確定和理解不同的項目干系人的需求和約束的過程。

基本步驟

（1）開發(fā)高層的業(yè)務模型。
建立一個業(yè)務模型，描述用戶的業(yè)務過程，確定用戶的初始需求。然后通過迭代，更深入地了解應用領域，之后再對業(yè)模型進行改進。
（2）定義項目范圍和高層需求。
項目范圍描述系統(tǒng)的邊界以及系統(tǒng)與系統(tǒng)交互的參與者之間(包括組織、人、硬件設備、其他軟件等)的關系。高層需求不涉及過多的細節(jié)，主要表示系統(tǒng)需求的概貌。常見的建模手段包括系統(tǒng)上下文圖和系統(tǒng)頂層用例圖等。
（3）識別用戶角色和用戶代表。
涉眾不僅包括傳統(tǒng)的用戶、客戶，還包括測試人員、維護人員、市場人員等。
首先確定所有涉眾，然后挑選出每一類涉眾并與他們一起工作。
用戶角色可以是人，也可以是與系統(tǒng)打交道的其他應用程序或硬件部件。如果是其他應用程序或硬件部件，則需要以熟悉這些系統(tǒng)或硬件的人員作為用戶代表。
（4）獲取具體的需求。
確定了項目范圍和高層需求，并確定了所有涉眾后，就需要獲取每個涉眾的具體、完整和詳細的需求。
（5）確定目標系統(tǒng)的業(yè)務工作流。
具體到當前待開發(fā)的應用系統(tǒng)，確定系統(tǒng)的業(yè)務工作流和主要的業(yè)務規(guī)則。
（6）需求整理與總結。
最后對上面步驟取得的需求資料進行整理和總結，確定對軟件系統(tǒng)的綜合要求，即軟件的需求。并提出這些需求的實現(xiàn)條件，以及需求應達到的標準。

獲取方法

（1）用戶訪談
1對1-3，找有代表性的用戶進行訪談，對提問者的水平是有要求的。其形式包括結構化(有劇本)和非結構化(隨意發(fā)揮)兩種。
（2）問卷調(diào)查
用戶多，無法一一訪談，收集到的需求不夠精準，比較雜亂，比較考驗問卷編寫者的水平。
（3）采樣
從種群中系統(tǒng)地選出有代表性的樣本集的過程，類似于數(shù)學中的數(shù)理統(tǒng)計。樣本數(shù)量=0.25*可信度因子錯誤率)2
（4）情節(jié)串聯(lián)板
一系列圖片，通過這些圖片來把需求給進行敘述出來，這樣雖然生動，但是耗時
（5）聯(lián)合需求計劃（JRP）
通過聯(lián)合各個關鍵用戶代表、系統(tǒng)分析師、開發(fā)團隊代表一起，通過有組織的會議來討論需求。
（6）需求記錄技術
任務卡片、場景說明、用戶故事、Volere白卡。

需求分析

為系統(tǒng)建立一個概念模型，作為對需求的抽象描述，并盡可能多的捕獲現(xiàn)實世界的語義。
一個好的需求應該具有無二義性、完整性、一致性、可測試性、確定性、可跟蹤性正確性、必要性等特性，因此，需要分析人員把雜亂無章的用戶要求和期望轉化為用戶需求,這就是需求分析的工作。

常見的需求分析任務：

• 繪制系統(tǒng)上下文范圍關系圖 (數(shù)據(jù)流圖)
• 創(chuàng)建用戶界面原型
• 分析需求的可行性
• 確定需求的優(yōu)先級
• 為需求建立模型
• 創(chuàng)建數(shù)據(jù)字典
• 使用QFD（QFD:質(zhì)量功能部署，把需求和QFD進行關聯(lián)）

結構化特點：
自頂向下，逐步分解，面向數(shù)據(jù)。

三大模型

功能模型(數(shù)據(jù)流圖DFD)、行為模型(狀態(tài)轉換圖STD)、數(shù)據(jù)模型(E-R圖)以及數(shù)據(jù)字典。

數(shù)據(jù)流圖

數(shù)據(jù)流圖DFD基本圓形元素：外部實體、假功、數(shù)據(jù)存儲、數(shù)據(jù)源。

數(shù)據(jù)流: 由一組固定成分的數(shù)據(jù)組成，表示數(shù)據(jù)的流向在DFD中，數(shù)據(jù)流的流向必須經(jīng)過加工

加工:描述了輸入數(shù)據(jù)流到輸出數(shù)據(jù)流之間的變換，數(shù)據(jù)流圖中常見的三種錯誤:

1. 有輸入但是沒有輸出，稱之為“黑洞。
2. 有輸出但沒有輸入，稱之為“奇跡”。
3. 中輸入不足以產(chǎn)生輸出，稱之為“灰洞”。

數(shù)據(jù)存儲： 用來存儲數(shù)據(jù)。
外部實體(外部主體)：是指存在于軟件系統(tǒng)之外的人員或組織，它指出系統(tǒng)所需數(shù)據(jù)的發(fā)源地(源)和系統(tǒng)所產(chǎn)生的數(shù)據(jù)的歸宿地(宿)。

數(shù)據(jù)字典DD

數(shù)據(jù)流圖描述了系統(tǒng)的分解，但沒有對圖中各成分進行說明。數(shù)據(jù)字典就是為數(shù)據(jù)流圖中的每個數(shù)據(jù)流
文件、加工，以及組成數(shù)據(jù)流或文件的數(shù)據(jù)項做出說明，即為了描述數(shù)據(jù)流圖的。
數(shù)據(jù)字典有以下4類條目: 數(shù)據(jù)流、數(shù)據(jù)項、數(shù)據(jù)存儲和基本加工。(外部實體不是系統(tǒng)內(nèi)部的內(nèi)容)

需求定義

需求定義（軟件需求規(guī)格說明書，SRS）：是需求開發(fā)活動的產(chǎn)物，編制該文檔的目的是使項目干系人與開發(fā)團隊對系統(tǒng)的初始規(guī)定有一個共同的理解，使之成為整個開發(fā)工作的基礎。SRS是軟件開發(fā)過程中最重要的文檔之一，對任何規(guī)模和性質(zhì)的軟件項目都不應該缺少。

1. 嚴格定義也稱為預先定義(結構化定義) ，需求的嚴格定義建立在以下的基本假設之上: 所有需求都能夠被預先定義。開發(fā)人員與用戶之間能夠準確而清晰地交流。采用圖形(或文字)可以充分體現(xiàn)最終系統(tǒng)，適合需求明確的情況。
2. 原型方法，迭代的循環(huán)型開發(fā)方式，需要注意的問題：并非所有的需求都能在系統(tǒng)開發(fā)前被準確地說明。項目干系人之間通常都存在交流上的困難，原型提供了克該服困難的一個手段。特點:需要實際的、可供用戶參與的系統(tǒng)模型。有合適的系統(tǒng)開發(fā)環(huán)境。反復是完全需要和值得提倡的，需求一旦確定，就應遵從嚴格的方法。

需求驗證

也稱為需求確認，目的是與用戶一起確認需求無誤,，對需求規(guī)格說明書SAS進行評審和測試，包括兩個步驟

1. 需求評審：正式評審和非正式評審
2. 需求測試：設計概念測試用例，設計場景來測試需求，沒有代碼.

需求驗證通過后，要請用戶簽字確認，作為驗收標準之一，此時，這個需求規(guī)格說明書就是需求基線，不可以再隨意更新，如果需要更改必須走需求變更流程。

需求管理

需求基線

定義需求基線：通過了評審的需求說明書就是需求基線，下次如果需要變更需求，就需要按照流程來一步步進行。

變更控制過程

變更控制過程用來跟蹤已建議變更的狀態(tài)，使已建議的變更確保不會丟失或疏忽。一旦確定了需求基線，應該使所有已建議的變更都遵循變更控制過程。

(1) 問題分析和變更描述。當提出一份變更提議后，需要對該提議做進一步的問題分析，檢查它的有效性，從而產(chǎn)生一個更明確的需求變更提議。
(2) 變更分析和成本計算。當接受該變更提議后，需要對需求變更提議進行影響分析和評估。變更成本計算應該包括對該變更所引起的所有改動的成本，例如修改需求文檔、相應的設計、實現(xiàn)等工作成本。一旦分析完成并且被確認，應該進行是否執(zhí)行這一變更的決策。
(3) 變更實現(xiàn)。當確定執(zhí)行該變更后，需要根據(jù)該變更的影響范圍，按照開發(fā)的過程模型執(zhí)行相應的變更。在計劃驅動過程模型中，往往需要回溯到需求分析階段開始，重新作對應的需求分析、設計和實現(xiàn)等步驟；在敏捷開發(fā)模型中，往往會將需求變更納入到下一次迭代的執(zhí)行過程中。

常見的需求變更策略：
(1) 所有需求變更必須遵循變更控制過程。
(2) 對于未獲得批準的變更，不應該做設計和實現(xiàn)工作。
(3) 變更應該由項目變更控制委員會決定實現(xiàn)哪些變更。
(4) 項目風險承擔者應該能夠了解變更的內(nèi)容。
(5) 絕不能從項目配置庫中刪除或者修改變更請求的原始文檔。
(6) 每一個集成的需求變更必須能跟蹤到一個經(jīng)核準的變更請求，以保持水平可追蹤性。
目前存在很多需求變更跟蹤工具，這些工具用來收集、存儲和管理需求變更。問題跟蹤工具也可以隨時按變更狀態(tài)分類報告變更請求的數(shù)目

變更控制委員會CCB

也稱為配置控制委員會，其任務是對建議的配置項變更做出評價、審批，以及監(jiān)督已經(jīng)批準變更的實施。
變更控制委員會 (Change Control Board，CCB) 是項目所有者權益代表，負責裁定接受哪些變更。 CCB 由項目所涉及的多方成員共同組成，通常包括用戶和實施方的決策人員。 CCB 是決策機構，不是作業(yè)機構，通常CCB 的工作是通過評審手段來決定項目是否能變更，但不提出變更方案。

組成

（1）產(chǎn)品或計劃管理部門。
（2）項目管理部門。
（3）開發(fā)部門。
（4）測試或質(zhì)量保證部門。
（5）市場部或客戶代表。
（6）制作用戶文檔的部門。
（7）技術支持部門。
（8）幫助桌面或用戶支持熱線部門。
（9）配置管理部門。

過程及操作步驟

1. 制定決策
   制定決策過程的描述應確認：

• 變更控制委員會必須到會的人數(shù)或做出有效決定必須出席的人數(shù)。
• 決策的方法(例如投票，一致通過或其他機制)。
• 變更控制委員會主席是否可以否決該集體的決定。

2. 交流情況
   一旦變更控制委員會做出決策，指派的人員應及時更新請求的狀態(tài)。
3. 重新協(xié)商約定
   變更總是有代價的，即使拒絕的變更也因為決策行為(提交、評估、決策)而耗費了資源。當項目接受了重要的需求變更時，為了適應變更情況要與管理部門和客戶重新協(xié)商約定。

需求跟蹤

需求跟蹤提供了由需求到產(chǎn)品實現(xiàn)整個過程范圍的明確查閱的能力。
需求跟蹤的目的是建立與維護“需求-設計-編程-測試”之間的一致性，確保所有的工作成果符合用戶需求。
也稱之為雙向跟蹤。分為兩種方式:

• 正向跟蹤，檢查《產(chǎn)品需求規(guī)格說明書》中的每個需求是否都能在后繼工作成果中找到對應點。；
• 反向跟蹤，檢查設計文檔、代碼、測試用例等工作成果是否都能在《產(chǎn)品需求規(guī)格說明書》中找到出處。

使用方式

正向跟蹤和逆向跟蹤合稱為“雙向跟蹤”。不論采用何種跟蹤方式，都要建立與維護需求跟蹤矩陣(即表格)。需求跟蹤矩陣保存了需求與后繼工作成果的對應關系。文章來源地址http://www.zghlxwxcb.cn/news/detail-818763.html

到了這里，關于系統(tǒng)架構14 - 軟件工程（2）的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！