軟體要求

該軟體要求的特徵和目標系統的功能性描述。要求傳送使用者從軟體產品的期望。這些要求可以明顯或隱藏的，已知或未知的，預期的或意外但從客戶的角度.

需求工程

這個過程收集的軟體需求，從用戶端，分析和記錄他們被稱為需求工程.

需求工程的目標是開發和維護複雜的和描述性的“系統需求規範”的檔案.

需求工程過程

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

可行性研究
理解客戶需求
S軟體需求規格說明
軟體需求驗證

讓我們來看看這個過程 -

可行性研究

當客戶接近組織獲取開發所要的產物，它涉及了什麼所有功能的軟體必須執行與其中所有的功能由軟體預期粗略的概念.

參照該資訊，則分析做詳盡的研究有關系統要求的和它的功能是有可能開發.

本可行性研究報告的重點是對本組織的目標。本研究分析是否該軟體產品可實際上物化在實施專案的組織，成本約束的貢獻方面，並按照價值觀和組織目標。它探討的專案和產品技術方面，如可用性，可維護性和生產效率和整合能力.

這一階段的輸出應該是一個可行性研究報告應包含充分的意見和建議，供管理有關專案是否應該進行.

需求收集

如果可行性報告是對正在進行的專案正，下一階段的開始，從使用者收集需求。分析師和工程師設有自己想要的軟體，包括與客戶和終端使用者溝通，了解他們的想法是什麼軟體應該提供和.

軟體需求規格

收集來自各利益相關方的要求後，系統分析員建立SRS文件.

SRS定義如何預定軟體將與硬體，外部介面，操作的速度，系統的響應時間，在不同平台上，可維護性，恢復的速度軟體之後崩潰，安全，品質，限制等的便攜性相互作用.

系統分析員準備根據客戶要求的技術檔案。為了軟體開發團隊該檔案很理解和有用的.

SRS應該拿出以下特點:

使用者需求均以自然語言.
技術要求中表達的結構化語言，它用於在組織內部.
設計說明應寫在虛擬碼.
格式表格和 GUI 螢幕列印.
條件和數學符號進行的DFD等.

軟體需求驗證

經過規定的技術規格，本文件中提及的要求進行驗證。使用者可能會問非法的，不切實際的解決方案或專家可以解釋的規定不正確。這將導致成本大幅增加，如果在萌芽狀態不是扼殺。要求可核對以下條件 -

如果能切實執行
如果他們每個功能和軟體領域，並有效作為
如果有任何含糊之處
I如果它們是完整的
如果他們可以證明

需求獲取過程

需求獲取過程可以用下面的圖來描繪:

收集需求 - 開發人員與客戶和終端使用者的討論和認識，從軟體的期望.
組織要求 - 開發者優先考慮和安排順序的重要性，緊迫性和便利性的要求.
談判和討論 - 如果要求不明確或存在各種利益相關者的要求有衝突，如果是這樣，它是那麼談判和與利益相關方進行討論。要求然後可以優先和合理妥協.

需求來自各個利益相關者。消除不確定性和衝突，他們的清晰度和準確性進行討論。不切實際的要求是合理的妥協.
文件 - 所有正式和非正式的，功能性和非功能性需求都記錄並供下一階段的處理.

需求獲取技術

需求獲取的過程中，找出一個預期軟體系統的要求與客戶，終端使用者，系統使用者和其他人誰在軟體系統開發的股權進行通訊.

有多種方法來發現需求

面試

面試是強中收集的要求。組織可進行多種型別的面試，如:

結構化(關閉)的採訪，其中的每一個資訊收集是事先決定，他們遵循的討論模式.
非結構(開放)的採訪，其中的資訊收集是不是事先決定，更加靈活，更加客觀.
口述訪談.
書面採訪.
這是桌子對面的兩個人之間進行1對1面談.
集團這些參與者群體之間進行面試。它們有助於發現任何缺失要求眾多的人參與.

調查

組織可通過查詢他們從即將到來的系統的期望和要求，進行各種利益相關者之間的調查.

問卷調查

與預先定義的一組客觀題，並選擇相應的檔案移交給所有利益相關者的回答，這是收集和編譯.

這種技術的缺點是，如果沒有在問卷中提到的一些問題的選項，這個問題可能會被看管。.

任務分析

工程師和開發團隊可能分析的量，新的系統是必需的操作。如果客戶機已經有一些軟體來執行某些操作時，它進行了研究，並提出了系統的要求被收集.

域分析

每個軟體屬於某個領域的範疇。專家人在域可以是有很大的幫助，分析一般和具體的要求.

頭腦風暴

一個非正式辯論舉行各種利益相關者之間以及他們所有的投入都記錄作進一步的需求分析.

原型

原型是建立使用者介面，而無需新增細節功能，為使用者詮釋意軟體產品的功能。它有助於提供更好的主意的要求。如果沒有在用戶端結束於開發人員的參考安裝的軟體和用戶端是不知道自己的要求，開發人員建立一個原型的基礎上開始提要求。原型被示出為用戶端和反饋悉。客戶反饋作為輸入的需求收集。.

觀察

專家團隊拜訪客戶的組織或工作場所。他們觀察了現有的已安裝系統的實際工作。他們觀察工作流程，在用戶端和如何執行的問題得到處理。團隊本身得出了一些結論，形成從軟體預期的要求的援助.

軟體需求特點

採集軟體需求是整個軟體開發專案的基礎。因此，他們必須清晰，正確和明確的.

一個完整的軟體需求規格必須是:

清除
正確
一致
相干
可理解
可修改
可驗證
優先
勿庸置疑
溯源
可靠的訊息來源

我們應該試著去了解可能出現的需求獲取階段有什麼樣的要求，什麼樣的要求，從軟體系統的預期.

廣義的軟體需求應該被歸類於兩類:

功能需求

這是關係到軟體功能方面都屬於這一類.

它們定義內，並從軟體系統的功能和功能性.

例子 -

搜尋選項提供給使用者各種發票進行查詢.
使用者應該可以郵寄任何報告給管理層.
使用者可以被分成組和組可以給出不同的權利.
應當遵守業務規則和行政職能.
軟體開發保持向下相容性完好.

非功能性需求

要求，這是不相關的軟體功能性方面，都屬於這一類。他們的軟體隱含的或預期的特徵，這對使用者做出的假設。.

非功能性需求，包括 -

安全性
記錄
儲存
組態
效能
成本
互操作性
靈活性
災難恢復
可存取性

要求在邏輯上劃分為

必須具備 : 軟體不能說的操作沒有他們.
應具備 : 增強軟體的功能.
可以有 : 軟體仍然可以正常使用這些功能的要求.
我的收藏夾 : 這些要求不對映到軟體的任何目標.

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

使用者介面的要求

使用者介面是任何軟體或硬體或混合動力系統的重要組成部分。軟體已被廣泛接受，如果它是 -

易於操作
響應快速
有效地處理執行錯誤
提供簡單而一致的使用者介面

使用者的認可，取決於使用者如何使用該軟體。使用者介面是使用者感知系統的唯一途徑。表現良好的軟體系統也必須具備有吸引力的，明確的，一貫的，反應靈敏的使用者介面。否則軟體系統的功能不能在方便的方式被使用。系統被認為是好的，如果它提供的手段來有效地使用它。使用者介面要求下面簡要提及 -

內容介紹
輕鬆導航
簡單的介面
響應
一致的使用者介面元素
反饋機制
預設設定
針對性布局
戰略運用色彩和質感
提供幫助資訊
使用者為中心的方法
集團基於檢視設定

軟體系統分析員

系統分析師在IT組織是一個人，誰提出分析系統的需求，並確保要求構思和記錄正確與正確。分析師的角色，SDLC的軟體分析階段開始。這是分析師的責任，以確保所開發的軟體滿足客戶的要求.

系統分析員有以下職責:

分析和理解意軟體的要求
了解專案將如何在組織目標作出貢獻
識別需求來源
需求驗證
制定和實施需求管理計劃
業務，技術，工藝和產品的需求文件
協調與客戶需求的優先順序，並刪除和模糊性
定型驗收標準與客戶和其他利益相關者

軟體度量與對策

軟體的措施，可以理解為量化和象徵各種屬性和軟體方面的處理.

軟體度量提供措施，軟體過程和軟體產品的各個方面.

軟體措施是軟體工程的基本要求。他們不僅有助於控制軟體開發過程中，也有助於保持最終產品的優良品質.

據湯姆•德馬科，A(軟體工程師)，“你無法控制你無法衡量的東西。”通過他的說法，這是非常清楚的軟體措施是多麼的重要.

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

尺寸度量 - LOC(程式碼行)，主要是計算在數千交付原始碼行數，記為KLOC的.

功能點計數是衡量由軟體提供的功能。功能點計數定義的軟體功能性方面的大小.
複雜性度量 - McCabe的圈複雜度量化上限的計劃，這被認為是程式或模組，它的複雜性，獨立路徑數。它是通過使用控制流圖表示在圖論中的概念術語。.
品質指標 - 缺陷，它們的型別和原因，後果，嚴重程度的強度及其影響界定產品的品質.

在發展的過程和報告的用戶端產品安裝，或在用戶端交付後的缺陷數量發現的缺陷數，定義產品的品質.
流程指標 - 在SDLC的各個階段，方法和工具使用，公司的標準和發展的表現是軟體過程的度量.
資源指標 - 精力，時間和使用的各種資源，代表度量資源的測量.