軟件要求
該軟件要求的特徵和目標系統的功能性描述。要求傳送用戶從軟件產品的期望。這些要求可以明顯或隱藏的，已知或未知的，預期的或意外但從客戶的角度.
需求工程
這個過程收集的軟件需求，從客戶端，分析和記錄他們被稱爲需求工程.
需求工程的目標是開發和維護複雜的和描述性的「系統需求規範」的文件.
需求工程過程
這是一個四步驟的過程，其中包括 –
- 可行性研究
- 理解客戶需求
- S軟件需求規格說明
- 軟件需求驗證
讓我們來看看這個過程 -
可行性研究
當客戶接近組織獲取開發所要的產物，它涉及了什麼所有功能的軟件必須執行與其中所有的功能由軟件預期粗略的概念.
參照該信息，則分析做詳盡的研究有關係統要求的和它的功能是有可能開發.
本可行性研究報告的重點是對本組織的目標。本研究分析是否該軟件產品可實際上物化在實施項目的組織，成本約束的貢獻方面，並按照價值觀和組織目標。它探討的項目和產品技術方面，如可用性，可維護性和生產效率和整合能力.
這一階段的輸出應該是一個可行性研究報告應包含充分的意見和建議，供管理有關項目是否應該進行.
需求收集
如果可行性報告是對正在進行的項目正，下一階段的開始，從用戶收集需求。分析師和工程師設有自己想要的軟件，包括與客戶和最終用戶溝通，瞭解他們的想法是什麼軟件應該提供和.
軟件需求規格
收集來自各利益相關方的要求後，系統分析員創建SRS文檔.
SRS定義如何預定軟件將與硬件，外部接口，操作的速度，系統的響應時間，在不同平臺上，可維護性，恢復的速度軟件之後崩潰，安全，質量，限制等的便攜性相互作用.
系統分析員準備根據客戶要求的技術文件。爲了軟件開發團隊該文件很理解和有用的.
SRS應該拿出以下特點:
- 用戶需求均以自然語言.
- 技術要求中表達的結構化語言，它用於在組織內部.
- 設計說明應寫在僞代碼.
- 格式 表格和 GUI 屏幕打印.
- 條件和數學符號進行的DFD等.
軟件需求驗證
經過規定的技術規格，本文檔中提及的要求進行驗證。用戶可能會問非法的，不切實際的解決方案或專家可以解釋的規定不正確。這將導致成本大幅增加，如果在萌芽狀態不是扼殺。要求可覈對以下條件 -
- 如果能切實執行
- 如果他們每個功能和軟件領域，並有效作爲
- 如果有任何含糊之處
- I如果它們是完整的
- 如果他們可以證明
需求獲取過程
需求獲取過程可以用下面的圖來描繪:
收集需求 - 開發人員與客戶和最終用戶的討論和認識，從軟件的期望.
組織要求 - 開發者優先考慮和安排順序的重要性，緊迫性和便利性的要求.
談判和討論 - 如果要求不明確或存在各種利益相關者的要求有衝突，如果是這樣，它是那麼談判和與利益相關方進行討論。要求然後可以優先和合理妥協.
需求來自各個利益相關者。消除不確定性和衝突，他們的清晰度和準確性進行討論。不切實際的要求是合理的妥協.
文檔 - 所有正式和非正式的，功能性和非功能性需求都記錄並供下一階段的處理.
需求獲取技術
需求獲取的過程中，找出一個預期軟件系統的要求與客戶，最終用戶，系統用戶和其他人誰在軟件系統開發的股權進行通信.
有多種方法來發現需求
面試
面試是強中收集的要求。組織可進行多種類型的面試，如:
- 結構化(關閉)的採訪，其中的每一個信息收集是事先決定，他們遵循的討論模式.
- 非結構(開放)的採訪，其中的信息收集是不是事先決定，更加靈活，更加客觀.
- 口述訪談.
- 書面採訪.
- 這是桌子對面的兩個人之間進行1對1面談.
- 集團這些參與者羣體之間進行面試。它們有助於發現任何缺失要求衆多的人蔘與.
調查
組織可通過查詢他們從即將到來的系統的期望和要求，進行各種利益相關者之間的調查.
問卷調查
與預先定義的一組客觀題，並選擇相應的文件移交給所有利益相關者的回答，這是收集和編譯.
這種技術的缺點是，如果沒有在問卷中提到的一些問題的選項，這個問題可能會被看管。.
任務分析
工程師和開發團隊可能分析的量，新的系統是必需的操作。如果客戶機已經有一些軟件來執行某些操作時，它進行了研究，並提出了系統的要求被收集.
域分析
每個軟件屬於某個領域的範疇。專家人在域可以是有很大的幫助，分析一般和具體的要求.
頭腦風暴
一個非正式辯論舉行各種利益相關者之間以及他們所有的投入都記錄作進一步的需求分析.
原型
原型是建立用戶界面，而無需添加細節功能，爲用戶詮釋意軟件產品的功能。它有助於提供更好的主意的要求。如果沒有在客戶端結束於開發人員的參考安裝的軟件和客戶端是不知道自己的要求，開發人員創建一個原型的基礎上開始提要求。原型被示出爲客戶端和反饋悉。客戶反饋作爲輸入的需求收集。.
觀察
專家團隊拜訪客戶的組織或工作場所。他們觀察了現有的已安裝系統的實際工作。他們觀察工作流程，在客戶端和如何執行的問題得到處理。團隊本身得出了一些結論，形成從軟件預期的要求的援助.
軟件需求特點
採集軟件需求是整個軟件開發項目的基礎。因此，他們必須清晰，正確和明確的.
一個完整的軟件需求規格必須是:
- 清除
- 正確
- 一致
- 相干
- 可理解
- 可修改
- 可驗證
- 優先
- 勿庸置疑
- 溯源
- 可靠的消息來源
軟件要求
我們應該試着去了解可能出現的需求獲取階段有什麼樣的要求，什麼樣的要求，從軟件系統的預期.
廣義的軟件需求應該被歸類於兩類:
功能需求
這是關係到軟件功能方面都屬於這一類.
它們定義內，並從軟件系統的功能和功能性.
例子 -
- 搜索選項提供給用戶各種發票進行查詢.
- 用戶應該可以郵寄任何報告給管理層.
- 用戶可以被分成組和組可以給出不同的權利.
- 應當遵守業務規則和行政職能.
- 軟件開發保持向下兼容性完好.
非功能性需求
要求，這是不相關的軟件功能性方面，都屬於這一類。他們的軟件隱含的或預期的特徵，這對用戶做出的假設。.
非功能性需求，包括 -
- 安全性
- 記錄
- 存儲
- 配置
- 性能
- 成本
- 互操作性
- 靈活性
- 災難恢復
- 可訪問性
要求在邏輯上劃分爲
必須具備 : 軟件不能說的操作沒有他們.
應具備 : 增強軟件的功能.
可以有 : 軟件仍然可以正常使用這些功能的要求.
我的收藏夾 : 這些要求不映射到軟件的任何目標.
在開發軟件，'必須擁有'必須執行，「應該有」的爭論與利益相關者和否定的問題，而「可能」和「願望清單」，可以保持軟件更新.
用戶界面的要求
用戶界面是任何軟件或硬件或混合動力系統的重要組成部分。軟件已被廣泛接受，如果它是 -
- 易於操作
- 響應快速
- 有效地處理運行錯誤
- 提供簡單而一致的用戶界面
用戶的認可，取決於用戶如何使用該軟件。用戶界面是用戶感知系統的唯一途徑。表現良好的軟件系統也必須具備有吸引力的，明確的，一貫的，反應靈敏的用戶界面。否則軟件系統的功能不能在方便的方式被使用。系統被認爲是好的，如果它提供的手段來有效地使用它。用戶界面要求下面簡要提及 -
- 內容介紹
- 輕鬆導航
- 簡單的界面
- 響應
- 一致的用戶界面元素
- 反饋機制
- 默認設置
- 針對性佈局
- 戰略運用色彩和質感
- 提供幫助信息
- 用戶爲中心的方法
- 集團基於視圖設置
軟件系統分析員
系統分析師在IT組織是一個人，誰提出分析系統的需求，並確保要求構思和記錄正確與正確。分析師的角色，SDLC的軟件分析階段開始。這是分析師的責任，以確保所開發的軟件滿足客戶的要求.
系統分析員有以下職責:
- 分析和理解意軟件的要求
- 瞭解項目將如何在組織目標作出貢獻
- 識別需求來源
- 需求驗證
- 制定和實施需求管理計劃
- 業務，技術，工藝和產品的需求文檔
- 協調與客戶需求的優先級，並刪除和模糊性
- 定型驗收標準與客戶和其他利益相關者
軟件度量與對策
軟件的措施，可以理解爲量化和象徵各種屬性和軟件方面的處理.
軟件度量提供措施，軟件過程和軟件產品的各個方面.
軟件措施是軟件工程的基本要求。他們不僅有助於控制軟件開發過程中，也有助於保持最終產品的優良品質.
據湯姆•德馬科，A(軟件工程師)，「你無法控制你無法衡量的東西。」通過他的說法，這是非常清楚的軟件措施是多麼的重要.
讓我們來看看一些軟件指標:
尺寸度量 - LOC(代碼行)，主要是計算在數千交付源代碼行數，記爲KLOC的.
功能點計數是衡量由軟件提供的功能。功能點計數定義的軟件功能性方面的大小.
複雜性度量 - McCabe的圈複雜度量化上限的計劃，這被認爲是程序或模塊，它的複雜性，獨立路徑數。它是通過使用控制流圖表示在圖論中的概念術語。.
質量指標 - 缺陷，它們的類型和原因，後果，嚴重程度的強度及其影響界定產品的質量.
在發展的過程和報告的客戶端產品安裝，或在客戶端交付後的缺陷數量發現的缺陷數，定義產品的質量.
流程指標 - 在SDLC的各個階段，方法和工具使用，公司的標準和發展的表現是軟件過程的度量.
資源指標 - 精力，時間和使用的各種資源，代表度量資源的測量.