需求是存在的，要麽是因為這種類型的產品需要某些功能和質量，要麽是因為客戶希望這種需求被稱為已交付產品的壹部分。
1.功能需求是產品必須完成的事情。
2.非功能性需求是產品的屬性和質量。如果產品要被所有者和經營者接受，它們必須具有這些屬性或品質。非功能性需求描述了諸如外觀和感覺、可用性、安全性和法律限制等需求。
3.限制
約束是全局要求。它們可以是對項目本身或產品最終設計的限制。約束只是另壹種需求。
第二，Volere需求過程
該流程的目的是成功收集、驗證和記錄需求。
Volere是意大利語，意為“希望”和“想要”。
您通過這個過程所做的工作是由相關的提交產品驅動的，而不是過程。(不同的產品需求對這個過程中的每組任務有不同的詳細程度)。
三、需求過程的基本框架
無論是構建用戶定制系統、構建組件集成系統、使用商業可用軟件包、采用開源軟件、外包開發，還是修改現有軟件，都需要發現、捕獲和溝通需求。
采用Volere需求過程的客戶在開發產品時采用RUP、增量、叠代、螺旋、Scrum或其他類型的叠代開發過程，有些客戶采用更正式的瀑布過程或自己定制的開發過程。要構建正確的產品，我們必須找到正確的需求。為了找到正確完整的需求，需要壹個有序的過程。
項目開始——收集需求——快速且不完美地建模——場景——編寫需求——質量控制——重用需求——評審需求——叠代和增量過程——需求反射——需求演化——模板——Snow Card——定制需求過程
①啟動會議確定了業務問題的範圍，努力使利益相關者達成壹致。其中，利益相關者都是對它有需求的人。
②項目的啟動也確立了項目的目標。
③在這個階段，可以初步估算出項目需求部分所涉及的成本，這是壹個很好的項目管理實踐。這可以通過工作範圍模型中包含的信息來完成；
④在早期評估項目可能面臨的風險也是壹種良好的項目管理實踐。
⑤最後，團隊成員就項目是否值得和可行達成壹致。這是壹個“去或停”的決定。或者，如果此時還有很多未知的東西，創業團隊可以決定開始需求調查，然後很快對需求進行審核，重新評估項目的價值。
吸引需求
在動員會之後，需求分析師開始學習並理解他們工作中的功能。將工作環境圖分成壹些業務用例。每個業務用例都是功能的壹部分。每個業務事件都被分配了壹個需求分析師。
分析師可以使用壹些技能，比如學徒，場景分析和用例研討會，來發現工作的真實性質。
問題的本質是擁有這個產品底層業務的原因，或者我們可以把它當成壹種工作策略，或者想象壹下，沒有技術工作會是什麽樣子。
3.快速且不完美的建模
壹些正式的模型是由UML或BPMN制作的，但是很多時候業務分析師可以有效地使用快速草圖來建模研究工作。
4.該場景展示了業務流程的功能。場景是需求的基礎。
5.寫作要求
分析師編寫需求，以確保參與開發的所有各方就需要做什麽達成共識。這是確保需求的本質被記錄和交流，以及交付的產品可以被測試的最有效的方法。
分析師使用兩種機制來簡化需求規範的編寫。第壹個機制是需求規格模板，它是需求規格的概要。
第二個機制是需求項框架，也稱為“雪卡”，以確保每個需求都有正確的組件。
6.質量管理
需求是後面所有工作的基礎，必須保證正確性。質量控制檢查需求。
通常由1-2人組成，他們可能是首席需求分析師，也可能是測試人員。只有他們有權利允許需求通過質量關。在允許需求被添加到需求規格之前，他們壹起檢查每個需求的完整性、相關性、可測試性、壹致性、可追溯性和其他質量屬性。
7.重用要求
在開始任何新的需求項目之前，瀏覽以前項目的規範，找到壹些潛在的可重用的東西。有時候發現很多需求是可以復用的。
8.審查要求
審查確保了規範是完整和適當的，這樣我們就可以進入下壹個開發階段。這個過程可以評估風險和計算成本，以便對需求進行合理的評審。
9.叠代和增量過程
需求行業有壹個普遍的誤解，認為做需求就是采用傳統的瀑布流程，這在某些情況下是對的，但現在並不總是這樣。
產品可以小增量開發。這樣做的好處是可以盡快實現壹些用例，並獲得涉眾的反饋。
10.需求反映
需求反思的過程就是發現過程中的優點和缺點。這個過程包括壹系列與利益相關者的面談和與開發人員的小組會談。
反思可能采取非正式的方式:在喝咖啡的時間與項目團隊交談，或者項目負責人通過電子郵件從項目參與者那裏收集信息。
11.需求演變
需求隨著產品開發過程而發展。起初，它們是相當模糊的想法。隨著時間的推移，產品想法出現，需求變得準確和可測試。進化是可前可後的。(功能需求、非功能需求、約束)
12 .模板
Volere需求規格模板，它是產品功能和能力的完整藍圖。
模板目錄:
項目驅動-描述項目的原因和動機。
1.項目的目標——投資構建產品的原因以及我們希望通過這樣做獲得的商業利益。
2.顧客、客戶和其他利益相關者——產品涉及他們的利益或對他們的影響。
3.產品的用戶——預期的最終用戶，以及他們對產品可用性的影響。
項目約束——對項目和產品的約束。
4.需求約束——項目的限制和產品的約束。
5.命名標準和定義.項目詞匯
6.相關事實和假設——對產品有壹定影響的外部因素，或者開發者做出的假設。
功能需求-產品的功能
7.工作範圍-目標業務領域
8.產品範圍-定義預期產品的邊界及其與鄰近系統的聯系。
9.功能和數據需求——產品必須做什麽，功能操作的數據。
非功能需求-產品質量
10.感知要求-預期外觀
11.易用性和人性化要求——如果要讓預期用戶成功使用，產品必須是什麽樣子？
12.實施要求-速度、尺寸、準確性、人身安全、可靠性、堅固性、可擴展性、耐用性和容量。
13.操作和環境要求-產品的預期操作環境
14.可維護性和支持需求-產品可修改性必須達到什麽水平，需要什麽樣的支持？
15.安全要求-產品的信息安全、保密性和完整性。
16.文化和政策需求-人文和社會因素
17.法律需求-符合適用法律？
項目問題——這些是應用於建築產品的項目。
18.開放式問題——那些未解決的問題可能會對項目的成功產生影響。
19.現成的解決方案——使用現有的組件，而不是從頭開始開發
20.新問題——引入新產品引起的問題。
21.任務-將產品投入使用必須完成的壹些事情。
22.遷移到新產品——從現有系統轉型的任務
23.風險——項目最有可能面臨的風險。
24.成本——對構建產品的成本或工作量的早期估計。
25.用戶文檔-創建用戶指南和文檔的計劃。
26.後續版本的需求——產品未來發布版本中可能包含的需求。
27.解決方案創意——我們不想錯過的設計創意。
13.雪卡
模板是寫什麽的指南，雪卡是怎麽寫的指南。
有壹些自動化工具可以用來記錄、分析和跟蹤需求。
14.定制需求過程
15.正式指南