軟件工程 需求

軟件需求是對目標系統(tǒng)特性和功能的描述。需求傳達了用戶對軟件產(chǎn)品的期望。從客戶的角度來看，需求可以是明顯的或隱藏的、已知的或未知的、預期的或意外的。

需求工程

從客戶那里收集軟件需求、分析和記錄它們的過程稱之為需求工程。

需求工程的目標是開發(fā)和維護復雜的和描述性的“系統(tǒng)需求規(guī)范”的文件。

需求工程過程

這是一個四步驟的過程，其中包括：

• 可行性研究
• 需求收集
• 軟件需求說明書
• 軟件需求驗證

讓我們來看看這個過程。

可行性研究

當客戶接近組織以開發(fā)所需的產(chǎn)品時，它會粗略地想出軟件必須執(zhí)行的所有功能以及軟件期望的所有功能。

分析人員參考這些信息，詳細研究所需的系統(tǒng)及其功能是否可以開發(fā)。

可行性研究的重點是組織的目標。研究分析了軟件產(chǎn)品是否可以在實施、項目對組織的鞏縣、成本約束以及根據(jù)組織的價值觀和目標方面實際實現(xiàn)。它探討了項目和產(chǎn)品的技術方面，例如可用性、可維護性、生產(chǎn)力和集成能力。

這一階段的輸出應該是一個可行性研究報告，其中應包含對管理層是否開展該項目的充分評論和建議。

需求收集

如果可行性報告對承接該項目是肯定的，下一階段就從收集用戶的需求開始。收集來自各利益相關方的要求后，系統(tǒng)分析員創(chuàng)建SRS文檔.分析師和工程師與客戶和最終客戶溝通，以了解他們對軟件你應該提供什么以及他們希望軟件包含哪些功能的想法。

軟件需求規(guī)格

SRS（Software Requirement Specification，軟件需求規(guī)格）是系統(tǒng)分析師在從各個利益相關者那里收集需求后創(chuàng)建文檔。

SRS定義了預期軟件將如何與硬件、外部接口、操作速度、系統(tǒng)響應時間、軟件跨各種平臺的可移植性、可維護性崩潰后恢復速度、安全性、質量、限制等交互。.

從客戶那里收到的要求是用自然語言編寫的。系統(tǒng)分析師有責任用技術語言記錄需求，以便軟件開發(fā)團隊能夠理解它們并對其有用。

SRS應該具備以下功能:

• 用戶需求以自然語言表達。
• 技術要求以組織內部使用的結構化語言表達。
• 設計說明應該使用偽代碼編寫。
• 表格格式和 GUI 屏幕打印。
• 如 DFD 等的條件和數(shù)學符號。

軟件需求驗證

開發(fā)需求規(guī)范后，將驗證本文檔中提到的需求。用戶可能會要求非法、不切實際的解決方案，或者專家可能會錯誤地解釋要求。如果不將其扼殺在萌芽狀態(tài)，這將導致成本的巨大增加?？梢愿鶕?jù)以下條件檢查要求：

• 如果它們可以實際實施。
• 如果它們有效并且符合軟件的功能和領域。
• 如果有任何的歧義。
• 如果它們是完整的。
• 如果它們可以被證明。

需求獲取過程

可以使用以下圖表描述需求獲取過程。

• 需求收集?開發(fā)人員與客戶和最終用戶討論并了解他們對軟件的期望。
• 組織要求?開發(fā)人員按照重要性、緊迫性和方便性的順序對需求進行優(yōu)先級排序和安排。
• 談判和討論 如果需求不明確或者各個利益相關者的需求存在沖突，如果是，則與利益相關者進行協(xié)商和討論。
  需求來自不同的利益相關者。為了消除歧義和沖突，為了清晰和正確，對它們進行了討論。不切實際的要求被合理地妥協(xié)。
• 文檔?所有正式和非正式的、功能性和非功能性的需求都被記錄，并可供下一階段的處理使用。

需求獲取技術

需求獲取是通過與客戶、最終用戶、系統(tǒng)用戶和其他與軟件系統(tǒng)開發(fā)有利益關系的人溝通，找出預期軟件系統(tǒng)需求的過程。

有多種方法可以發(fā)現(xiàn)需求：

面試

面試時收集需求的有力媒介。組織可能會進行多種類型的面試，例如：

• 結構化（封閉式）的采訪，其中每一個要收集的信息是預先決定，他們嚴格遵循討論的模式和問題。
• 非結構（開放式）的采訪，無需事先決定要收集的信息，更靈活且偏見更少。
• 口試。
• 筆試。
• 一對一面試，在桌子對面的兩個人之間進行。
• 在參與者之間進行的小組訪談。由于涉及的人員眾多，它們有助于發(fā)現(xiàn)任何缺失的需求。

調查

組織可以通過詢問他們對即將到來的系統(tǒng)的期望和要求，在不同的利益相關者只之間進行調查。

問卷調查

一份帶有預先定義的客觀問題和相應選項的文件被交給所有利益相關者回答，這些問題被收集和編譯。

這種技術的一個缺點是，如果問卷中沒有提到某個問題的選項，這個問題會無人注意。

任務分析

工程師和開發(fā)團可以分析需要新系統(tǒng)的操作。如果客戶已經(jīng)有一些軟件來執(zhí)行某些操作，則對其進行研究并收集建議系統(tǒng)的要求。

領域分析

每個軟件都屬于某個領域類別。該領域的專家可以極大地幫助分析一般和特定需求。

頭腦風暴

在不同的利益相關者之間舉行非正式辯論，并記錄他們的所有意見以供進一步的需求分析。

原型設計

原型設計是在不添加詳細功能的情況下構建用戶界面，以供用戶解釋預期軟件產(chǎn)品的功能。它有助于更好地了解需求。如果客戶端沒有安裝供開發(fā)者參考的軟件，并且客戶端不知道自己的需求，則開發(fā)者根據(jù)最初提到的需求創(chuàng)建原型。將原型展示給客戶并記錄反饋?？蛻舴答佔鳛樾枨笫占妮斎?。

觀察

專家團隊訪問客戶的組織或工作場所。他們觀察現(xiàn)有安裝系統(tǒng)的實際工作情況。他們觀察客戶端的工作流程以及如何處理執(zhí)行問題。團隊本身得出了一些有助于形成軟件與其需求的結論。

軟件需求特點

收集軟件需求是整個軟件開發(fā)項目的基礎。因此，它們必須清晰、正確和定義明確。

一個完整的軟件需求規(guī)格必須是:

• 清楚的
• 正確的
• 一致的
• 相關的
• 可理解的
• 可修改的
• 可驗證的
• 優(yōu)先的
• 明確的
• 可追溯的
• 可信的信息來源

軟件要求

我們應該嘗試了解在需求獲取階段可能會出現(xiàn)什么樣的需求，以及從軟件系統(tǒng)中期望什么樣的需求。

從廣義上講，軟件需求應分為兩類：

功能需求

與軟件功能方面相關的需求屬于這一類、

它們定義了軟件系統(tǒng)的內部和來自軟件系統(tǒng)的功能和功能性。

例子：

• 為用戶提供搜索選項以從各種發(fā)票中進行搜索。
• 用戶應該能夠將任何報告郵寄給管理層。
• 用戶可以分為組，組可以被賦予單獨的權限。
• 應當遵守業(yè)務規(guī)則和行政職能.
• 軟件開發(fā)保持向下兼容性完好.

非功能性需求

與軟件功能方面無關的需求屬于這一類。它們是用戶假設的軟件的隱含或預期特征。

非功能性需求，包括：

• 安全性
• 日志記錄
• 存儲
• 配置
• 性能
• 成本
• 互操性
• 靈活性
• 災難恢復
• 可訪問性

需求按邏輯分類為：

• 必須具備?: 沒有它們，軟件就不能說是可操作性的。
• 應具備?: 增強軟件的功能。
• 可以有?: 軟件仍然可以在滿足這些要求的情況下正常運行。
• 愿望清單?: 這些需求并不映射到軟件的任何目標。

在開發(fā)軟件，'必須擁有'必須執(zhí)行，“應該有”的爭論與利益相關者和否定的問題，而“可能”和“愿望清單”，可以保持軟件更新.

用戶界面的要求

UI（User Interface，用戶界面）是任何軟件、硬件或混合系統(tǒng)的重要組成部分。一個軟件被廣泛接受，那么它是：

• 易于操作
• 響應快速
• 有效地處理運行錯誤
• 提供簡單而一致的用戶界面

用戶的接受程度主要取決于用戶如何使用軟件。UI 是用戶感知系統(tǒng)的唯一途徑。一個性能良好的軟件系統(tǒng)還必須配備有吸引力、清晰、一致和響應迅速的用戶界面。否則軟件系統(tǒng)的功能不能方便的使用。如果一個系統(tǒng)提供了有效使用它的方法，那么它就被認為是好的。下面簡要提到用戶界面要求：

• 內容呈現(xiàn)
• 輕松導航
• 簡單的界面
• 響應迅速
• 一致的 UI 元素
• 反饋機制
• 默認設置
• 針對性布局
• 戰(zhàn)略運用色彩和質感
• 提供幫助信息
• 以用戶為中心的方法
• 基于組的視圖設置

軟件系統(tǒng)分析師

IT 組織中的系統(tǒng)分析師是一個人，他分析提議系統(tǒng)的需求并確保正確和正確地構思和記錄需求。分析師的角色始于 SDLC 的軟件分析階段。分析師有責任確保開發(fā)的軟件滿足客戶的需求。

系統(tǒng)分析員有以下職責:

• 分析和理解意預期軟件的需求。
• 了解項目將如何在組織目標作出貢獻
• 確定需求來源。
• 需求驗證。
• 指定和實施需求管理計劃。
• 業(yè)務、技術、流程和產(chǎn)品要求的文檔。
• 與客戶協(xié)調，確定需求的優(yōu)先級并消除歧義。
• 與客戶和其他利益相關者最終確定驗收標準。

軟件指標和度量

軟件度量可以理解為量化和符號化軟件各種屬性和方面的過程。

軟件指標為軟件過程和軟件產(chǎn)品的各個方面提供度量。

軟件度量是軟件工程的基本要求。它們不僅有助于控制軟件開發(fā)過程，而且有助于保持最終產(chǎn)品的卓越質量。

據(jù) Tom·DeMarco 的說法，“你無法控制你無法衡量的東西?！庇盟脑捳f，軟件度量的重要性不言而喻。

讓我們來看看一些軟件指標:

• 規(guī)模：LOC（Line Of Code，代碼行），多以交付的數(shù)千行源代碼行計算，記為 KLOC。
  功能點計數(shù)是對軟件提供的功能的度量，功能點數(shù)定義了軟件功能方面的規(guī)模。
• 復雜性：McCabe 的圈復雜度量化了程序中獨立路徑數(shù)量的上限，這被視為程序或其規(guī)模的復雜性。
• 質量：缺陷、它們的類型和原因、后果、嚴重程度及其影響決定了產(chǎn)品的質量。
  開發(fā)過程中發(fā)現(xiàn)的缺陷數(shù)和產(chǎn)品在客戶端安裝或交付后客戶報告的缺陷數(shù)，定義了產(chǎn)品的質量。
• 流程：在SDLC的各個階段，所使用的方法和工具、公司標準和開發(fā)績效都是軟件過程指標標準。
• 資源：?工作量、時間和使用的各種資源代表了資源測量的指標。