軟體工程性能需求分析

㈠ 關於軟體工程的需求分析人員，大家來談談這個工作的性質

..
...
我個人認為，需求分析是大型軟體程序開發工程的第一步，也是最舉足輕重的一步！
這一步做不好，後面全部是無用功。
不誇張的講，這一步是最富創造性、最需要經驗、最具決定性的工作。盡管表面看，這一步似乎技術含量並不高。

隨著軟體業的發展、進步，需求分析師必然會成為更受重視、更需要工作經驗、待遇更高的工作職位。
..
.

㈡ 軟體工程 進行需求分析有多種描述工具

需求分析有功能需求，性能需求，界面需求等。還需要根據不同的軟體工程需求背景，需求對象進行不同的需求分析。至於需求描述工具不知道你說的是什麼。

㈢ 軟體工程的需求分析階段主要要完成哪些工作

1. 確定需求調研對象。

2. 制定需求調研計劃，以一般會議記錄的方式即可。

3. 分析用戶需求。顯化用戶需求與軟體規格的差異（有些用戶需求點能完全通過軟體功能去滿足，有些用戶需求點只能通過軟體功能部分地滿足，有些用戶需求點不通過軟體功能去實現）對用戶需求的優先順序進行排序。

4. 制定用戶需求規格說明書，系統需求規格說明書。 或者軟體需求規格說明書。

5. 做好需求問題管理表（整個需求過程中，需跟進、協調的重要問題）。
   

㈣ 軟體工程中需求分析的任務是什麼（具體點）

軟體需求包括 3 個不同的層次――業務需求、用戶需求和功能需求。

除此之外，每個系統還有各種非功能需求。

業務需求（Business requirement）表示組織或客戶高層次的目標。業務需求通常來自項目投資人、購買產品的客戶、實際用戶的管理者、市場營銷部門或產品策劃部門。業務需求描述了組織為什麼要開發一個系統，即組織希望達到的目標。

使用前景和范圍（ vision and scope ）文檔來記錄業務需求，這份文檔有時也被稱作項目輪廓圖或市場需求（ project charter 或 market requirement ）文檔。

用戶需求（user requirement）描述的是用戶的目標，或用戶要求系統必須能完成的任務。用例、場景描述和事件――響應表都是表達用戶需求的有效途徑。也就是說用戶需求描述了用戶能使用系統來做些什麼。

功能需求（functional requirement）規定開發人員必須在產品中實現的軟體功能，用戶利用這些功能來完成任務，滿足業務需求。

功能需求有時也被稱作行為需求（ behavioral requirement ），因為習慣上總是用「應該」對其進行描述：「系統應該發送電子郵件來通知用戶已接受其預定」。功能需求描述是開發人員需要實現什麼。

系統需求（system requirement）用於描述包含多個子系統的產品（即系統）的頂級需求。系統可以只包含軟體系統，也可以既包含軟體又包含硬體子系統。人也可以是系統的一部分，因此某些系統功能可能要由人來承擔。

業務規則包括企業方針、政府條例、工業標准、會計准則和計算方法等。業務規劃本身並非軟體需求，因為它們不屬於任何特定軟體系統的范圍。

然而，業務規則常常會限制誰能夠執行某些特定用例，或者規定系統為符合相關規則必須實現某些特定功能。有時，功能中特定的質量屬性（通過功能實現）也源於業務規則。所以，對某些功能需求進行追溯時，會發現其來源正是一條特定的業務規則。

功能需求記錄在軟體需求說明書（ SRS ）中。 SRS 完整地描述了軟體系統的預期特性。 SRS 我們一般把它當作文檔，其實， SRS 還可以是包含需求信息的資料庫或電子表格；

或者是存儲在商業需求管理工具中的信息；而對於小型項目，甚至可能是一疊索引卡片。開發、測試、質量保證、項目管理和其他相關的項目功能都要用到 SRS 。

除了功能需求外， SRS 中還包含非功能需求，包括性能指標和對質量屬性的描述。

質量屬性（quality attribute）對產品的功能描述作了補充，它從不同方面描述了產品的各種特性。這些特性包括可用性、可移植性、完整性、效率和健壯性，它們對用戶或開發人員都很重要。其他的非功能需求包括系統與外部世界的外部界面，以及對設計與實現的約束。

約束（constraint）限制了開發人員設計和構建系統時的選擇范圍。

行業需求：企業在招聘軟體測試人員時主要看中應聘者的項目經驗、邏輯思維能力、一定的技術能力和綜合素質，而對學歷、年齡、性別、工作經驗等的要求較低，相對於IT行業其他職位而言，軟體測試的入行更加容易。

(4)軟體工程性能需求分析擴展閱讀：

工程與科學：

軟體的開發到底是一門科學還是一門工程，這是一個被爭論了很久的問題。實際上，軟體開發兼有兩者的特點。但是這並不意味著它們可以被互相混淆。很多人認為軟體工程基於計算機科學和信息科學就如傳統意義上的工程學之於物理和化學一樣。

在美國，大約40%的軟體工程師具有計算機科學的學位。在世界其他地方，這個比例也差不多。他們並不一定會每天使用計算機科學方面的知識，但是他們每天都會使用軟體工程方面的知識。

㈤ 在軟體工程中什麼是需求分析

一。 確定對系統的綜合要求
1. 功能需求
這方面的需求指定系統必須提供的服務。通過需求分析應該劃分出系統必須完成的所有功能。
2. 性能需求
性能需求指定系統必須滿足的定時約束或容量約束，通常包括速度(響應時間)、信息量速率、主存容量、磁碟容量、安全性等方面的需求。
3. 可靠性和可用性需求
可靠性需求定量地指定系統的可靠性。
可用性與可靠性密切相關，它量化了用戶可以使用系統的程度。
4. 出錯處理需求
這類需求說明系統對環境錯誤應該怎樣響應。例如，如果它接收到從另一個系統發來的違反協議格式的消息，應該做什麼?注意，上述這類錯誤並不是由該應用系統本身造成的。
5. 介面需求
介面需求描述應用系統與它的環境通信的格式。常見的介面需求有：用戶介面需求；硬體介面需求；軟體介面需求；通信介面需求。
6. 約束
設計約束或實現約束描述在設計或實現應用系統時應遵守的限制條件。在需求分析階段提出這類需求，並不是要取代設計(或實現)過程，只是說明用戶或環境強加給項目的限制條件。常見的約束有：精度；工具和語言約束；設計約束；應該使用的標准；應該使用的硬體平台。
7. 逆向需求
逆向需求說明軟體系統不應該做什麼。理論上有無限多個逆向需求，我們應該僅選取能澄清真實需求且可消除可能發生的誤解的那些逆向需求。
8. 將來可能提出的要求
應該明確地列出那些雖然不屬於當前系統開發范疇，但是據分析將來很可能會提出來的要求。
注意：舉例讓學生理解：這樣做的目的是，在設計過程中對系統將來可能的擴充和修改預做准備，以便一旦確實需要時能比較容易地進行這種擴充和修改。
二 。分析系統的數據要求
任何一個軟體系統本質上都是信息處理系統，系統必須處理的信息和系統應該產生的信息在很大程度上決定了系統的面貌，對軟體設計有深遠影響，因此，必須分析系統的數據要求，這是軟體需求分析的一個重要任務。
分析系統的數據要求通常採用建立數據模型的方法（舉例）。

三。 導出系統的邏輯模型
綜合上述兩項分析的結果可以導出系統的詳細的邏輯模型，通常用數據流圖、實體-聯系圖、狀態轉換圖、數據字典和主要的處理演算法描述這個邏輯模型。
四。 修正系統開發計劃
根據在分析過程中獲得的對系統的更深入更具體的了解，可以比較准確地估計系統的成本和進度，修正以前制定的開發計劃。

㈥ 什麼是需求分析，其目標是什麼《軟體工程》

需求分析，也叫軟體需求分析、系統需求分析或需求分析工程等，是開發人員經過深入細致的調研和分析，准確理解用戶和項目的功能、性能、可靠性等具體要求，將用戶非形式的需求表述轉化為完整的需求定義，從而確定系統功能的過程。

需求分析的目標是把用戶對待開發軟體提出的要求或需要進行分析與整理，確認後形成描述完整、清晰與規范的文檔，確定軟體需要實現的功能，完成的工作。此外，軟體的一些非功能性需求、軟體設計的約束條件、運行時與其他軟體的關系等也是軟體需求分析的目標。

(6)軟體工程性能需求分析擴展閱讀：

需求分析階段分為四個方面：問題識別、分析與綜合、制訂規格說明、評審。

1、問題識別：從系統角度來理解軟體，確定對所開發系統的綜合要求，並提出這些需求的實現條件，以及需求應該達到的標准。這些需求包括功能需求、性能需求、環境需求、可靠性需求、安全保密需求、用戶界面需求、資源使用需求、軟體成本消耗與開發進度需求。

2、分析與綜合：逐步細化所有的軟體功能，找出系統各元素間的聯系，介面特性和設計上的限制，分析他們是否滿足需求，剔除不合理部分，增加需要部分。最後綜合成系統的解決方案，給出要開發的系統的詳細邏輯模型(做什麼的模型)。

3、制訂規格說明書： 編制文檔，描述需求。需求分析階段的成果是需求規格說明書，向下一階段提交。

4、評審：對功能的正確性，完整性和清晰性，以及其它需求給予評價。評審通過才可進行下一階段的工作,否則重新進行需求分析。

㈦ 軟體需求分析說明書中對性能的規定這部分怎麼寫啊

對性能的規定

1、精度

說明對該軟體的輸入、輸出數據精度的要求，可能包括傳輸過程中的精度。

2、時間特性要求

說明對於該軟體的時間特性要求，如對：

a、響應時間；

b、更新處理時間；

c、數據的轉換和傳送時間；

d、解題時間；等的要求。

3、靈活性

說明對該軟體的靈活性的要求，即當需求發生某些變化時，該軟體對這些變化的適應能力，如：

a、操作方式上的變化；

b、運行環境的變化；

c、同其他軟體的介面的變化；

d、精度和有效時限的變化；

e、計劃的變化或改進。

對於為了提供這些靈活性而進行的專門設計的部分應該加以標明。

4、輸入輸出要求

解釋各輸入輸出數據類型，並逐項說明其媒體、格式、數值范圍、精度等。對軟體的數據輸出及必須標明的控制輸出量進行解釋並舉例，包括對硬拷貝報告（正常結果輸出、狀態輸出及異常輸出）以及圖形或顯示報告的描述。

5、數據管理能力要求

說明需要管理的文卷和記錄的個數、表和文卷的大小規模，要按可預見的增長對數據及其分量的存儲要求作出估算。

6、故障處理要求

列出可能的軟體、硬體故障以及對各項性能而言所產生的後果和對故障處理的要求。

7、其他專門要求

如用戶單位對安全保密的要求，對使用方便的要求，對可維護性、可補充性、易讀性、可靠性、運行環境可轉換性的特殊要求等。

(7)軟體工程性能需求分析擴展閱讀：

軟體需求分析所要做的工作是深入描述軟體的功能和性能，確定軟體設計的限制和軟體同其它系統元素的介面細節，定義軟體的其它有效性需求。

進行需求分析時，應注意一切信息與需求都是站在用戶的角度上。盡量避免分析員的主觀想像，並盡量將分析進度提交給用戶。在不進行直接指導的前提下，讓用戶進行檢查與評價。從而達到需求分析的准確性。

分析員通過需求分析，逐步細化對軟體的要求，描述軟體要處理的數據域，並給軟體開發提供一種可轉化為數據設計、結構設計和過程設計的數據和功能表示。在軟體完成後，制定的軟體規格說明還要為評價軟體質量提供依據。

㈧ 軟體工程中常用的需求分析的方法有哪些

一、過濾需求的方法
做後端系統，要學會的第一個技能就是砍需求。也就是過濾需求。

這不是一個貶義詞，反而是體現後端產品價值判斷的基礎。

過濾需求的方法，就是通過一定的手段判斷需求是否是偽需求，應該被過濾掉。

1. 用戶場景模擬法
後端產品的出發點就是幫助業務用戶，因此在調研需求的時候要模擬業務的場景，分析業務用戶提到的需求是否能解決他的問題。

如果不能幫助用戶，那麼這個需求就可能是偽需求。

以下面的案例說明：

背景：「貨到付款」類型的訂單會因為缺貨而無法發出，如果超過一定的時間，客服就會跟顧客溝通，幫顧客取消訂單。

需求：由於這種訂單的數量還是蠻多的，逐個取消太費時間，因此業務用戶要求在「缺貨訂單」列表頁增加「批量取消訂單」按鈕。

分析：調研到業務操作場景,是先找到該類缺貨訂單，然後和顧客溝通，顧客同意刪除，才進行刪除。也就是逐個溝通確認，再逐個取消訂單的，所以「批量取消訂單」無法被有效使用。

因此，該需求是個偽需求，應該被過濾掉。

2. 功能歸屬分析
專門的系統做專職功能，有助於合理的產品體系建設。

因此需求調研的時候，可以通過系統的定位，判斷需求是否應該在該系統完成。

如果不屬於該系統范疇，那麼直接說服需求方更換方案。以

下面的案例說明：

背景：CRM系統（顧客關系管理系統）有一個顧客標簽生成功能，就是根據顧客的消費行為數據，自動對應關聯上標簽，如優質顧客、高潛力顧客、欺詐顧客等。

需求：業務用戶提出需求，除了做上述的基礎標簽之外，還要做出英語版本的標簽（就是把標簽文案翻譯成英文），這樣歐美員工可以在英語版本的系統下使用。

分析：調研到翻譯之後的標簽不是在CRM系統使用的，而是給到SMS（客服系統）使用的。

所以應該由SMS根據CMS提供的基礎標簽數據，自己做二次的衍生。

之所以這樣，首先是為了避免未來更多語言版本的擴展需求或更多系統提出類似的需求；

其次，CRM系統已經完成了「接力賽」的第一棒，創造了基礎數據，那麼其他系統要特殊化使用，完全可以自行進行特殊化處理，無需耦合回CRM系統。

結論：案例的需求本身是真需求，並且實現上也沒難度，但是該功能的定位超出了本系統范疇，專門系統做專職功能，化衍生需求應該在下游執行。

否則，耦合性過高只會增加系統的復雜程度，難以維護和擴展。

二、拆分和聚合的方法
1. 拆分需求法
業務用戶提出一個需求，很可能只是短短的一段話。

但是不要高興太早，可能這一句話暗含了很多線索，因此要善於拆分：

先找他要解決的核心問題，再圍繞核心點，理清前、後、左、右、上、下的旁系需求點。

每個需求點再當做一個子需求進行調研，最後再聚合在一起。

以下面的案例說明：

背景：訂單業務的類型很多，訂單退貨之後需要創建售後單據，但是因為數量大，所以花費很多人力，且手動創建有出錯的風險。

需求：業務提出的需求是「增加退貨訂單自動創建售後單的功能」，這是個一句話需求。

該一句話需求，其實包含了多種具體的訂單類型和場景，那麼我們就要拆分調研，拆分的維度比如：

自營訂單、第三方訂單、貨到付款訂單、先款後貨訂單、部分退貨訂單、完全退貨訂單、服裝事業部訂單、電子事業部訂單等，其中每一個維度就相當於一個小需求。

這里不一一展開。

2. 聚合需求法
拆分法是對單個需求分解成若干小需求進行調研，聚合法相反，是找到許多個相互關聯的小需求的共性，然後統籌成一個大需求去完成。例如：

由於業務用戶分散在不同的部門，各自為政，於是張三、李四可能都對一個業務流程有相同的需求，或者對同一個功能有相同的優化期望，結果倆人分別提了需求過來。那麼產品經理就要找到二者背後的相關性和交叉區。

然後統籌規劃，聚合在一起當作一個需求來調研，最終輸出一個整體的需求調研結果。

三、利用輔助功能調研需求
調研產品現有功能，可以用來確認原有功能的邏輯，或者確定新需求方案是否可行。

比如業務用戶需要更新一個功能，為了避免更新出錯或遺漏，產品經理需要知道修改前和修改後是否會能正常運行。

最基礎的辦法就是自己設計一個測試用例，記錄操作方式、狀態變化、數據流向等。看看下面的例子：

背景：從銷售網站獲取到OMS系統（訂單管理系統）的訂單信息中帶著顧客的郵箱。顧客下完單，可能會在銷售網站修改郵箱，而此時已經獲取到OMS的歷史訂單中的郵箱是不變的。

需求：顧客若在銷售網站修改郵箱，要求已獲取到OMS的該顧客的訂單中的郵箱也要同步修改。

分析：需求是很明白的，也有它的意義，但有風險。

因為我們知道訂單信息貫穿於整個訂單流轉過程中，牽扯到訂單編輯、審核、取消、配貨、發貨等，而這些環節跳轉的觸發條件可能就是某個信息更新（這裡面就可能包括有郵箱更新）。

因此，更新郵箱是否會影響流程中的某些環節，一時間很難准確知道。

於是，我們可以採用預測試的方式，設計測試用例，在測試機運行一些訂單，觀察各個環節郵箱變更的影響，然後收集起來分析對策。

測試法就像是探雷一樣，主要用來解決未知風險點。這個方式的重點是記錄和分析操作前狀態、操作位點、操作後狀態、操作後觸發的連鎖反應、數據流向等。

四、「拔蘿卜帶出泥」的方式調研需求
調研需求時，產品經理要拔蘿卜帶出泥,挖掘用戶沒看到的需求點和價值。

舉例說明：

背景：公司入駐到銷售平台後，銷售平台會對入駐的店鋪的違規行為進行罰款。

需求：業務用戶提出需求，將銷售平台的罰款數據抓取到訂單系統，關聯訂單數據，以便進行人工分析。

分析：

第一步，先拆分需求，確定什麼是罰款數據，總共有哪些罰款種類，需要對接哪些罰款種類，罰款數據與訂單系統關聯方式是什麼，是否都能關聯到，關聯不到怎麼辦，銷售平台是否已經提供了公用的罰款介面，Token（請求許可權）如何獲取，抓取頻率怎麼樣，數據增長幅度多大，獲取之後做哪些展示和搜索，用戶許可權怎麼設置，需要和訂單系統做哪些交互，該需求的價值是什麼……

第二步，挖掘需求：是否需要作分析功能，分析功能的規則是什麼；是否需要做監控和預警，是否需要指派負責人；其他業務人員是否也有類似需求，其他平台是否也有類似需求……

通過「拔蘿卜帶出泥」的方式，連帶出更多需求點。將上述調研結果重新組裝起來，得到一個系統化的完整需求。

羅列出需求要點和對應的驗收目標，這樣使得需求具象化，同時又不會遺漏細節，內部充實，外部閉環，並且進行了價值挖掘，做成控制閾值、預警、責任人分派、趨勢分析、損失分析等高價值的功能，超出業務的預期。

㈨ 軟體工程的需求分析該怎麼寫

非專業人士。答錯勿怪。
1 簡要介紹該項目相關的應用現狀及存在的問題
2 指出最需要解決的問題，以及解決方法。嗯，還有哪些人群最需要解決這些問題
3 闡述解決後能帶來的效益 希望能幫助你！！