一、需求是什麼？
需求之所以存在，要麼因為該型別的產品要求某些功能和品質，要麼因為客戶希望該需求稱為交付的產品的一部分。
1.功能需求是產品必須完成的那些事。
2.非功能需求是產品的屬性和品質。產品要讓擁有者和操作者接受，就必須具備這些屬性或品質。非功能需求描述了諸如觀感、可用性、安全性和法律限制等需求。
3.限制條件
限制條件是全域性性的需求。它們可以是對專案本身的限制，或是對產品最終設計的限制。限制條件只是另一種型別的需求。
二、volere需求過程
這個過程目的是成功地收集、驗證需求，並編寫需求文件。
volere是義大利語，意思是「希望」、「想要」。
你通過該過程所做地工作是由相關的提交產物驅動的，並非流程。（不同的產品需求，該流程中的每一組任務細節程度不同）。
三、需求過程的基本框架
不論是構建使用者定製的系統，還是構建元件整合的系統，或者使用商業上架銷售的軟體包，或者採用開源軟體，或者將開發外包，或者對已有的軟體進行改動，都需要發現、捕獲和交流需求。
採用volere需求過程的客戶，開發產品時採用了rup、增量、迭代、螺旋、scrum，或其他型別的迭代式開發過程，也有的客戶採用了更正式的瀑布式過程，或自己定製的開發過程。要構建正確的產品，就必須發現正確的需求。為了發現正確、完整的需求，需要某種有序的過程。
專案啟動——網羅需求——快而不完美地建模——場景——編寫需求——質量關——復用需求——複查需求——迭代和增量過程——需求反思——需求演進——模板——白雪卡——定製需求過程
①啟動會議確定了業務問題的範圍，爭取讓利益相關者達成一致意見。其中，利益相關者是所有對它有要求的人。
②專案啟動也確立了專案的目標。
③在這個階段可以對專案的需求部分所涉及的成本進行初步預估，是不錯的專案管理實踐。可以通過工作範圍模型中包含的資訊來完成；
④對專案可能面臨的風險進行早期評估，也是不錯的專案管理實踐。
⑤最後，小組成員對專案是否值得進行和是否可行達成一致意見。這是「進行或終止」的決定。或者，此時如果還有許多未知的東西，啟動小組可以決定開始需求調研，不久後再來複查需求，重新評估專案的價值。
2.網羅需求
啟動會議結束後，需求分析師開始在工作中網羅，學習和理解它的功能性。將工作上下文圖劃分為一些業務用例。每個業務用例都是一部分功能。每個業務事件都指派一名需求分析師。
分析師可以採用一些技巧：如做學徒、場景分析和用例研討會等，來發現工作的真正本質。
問題的實質是擁有這個產品的底層業務的理由，或者可以將它看成是工作的策略，或者想象在沒有技術的情況下工作會是什麼樣子。
3.快而不完美的建模
一些正式的模型是用uml或bpmn做的，但許多時候業務分析師可以有效地利用快速地草圖，對調研工作進行建模。
4.場景展示了業務過程地功能性。場景是需求地基礎。
5.編寫需求
分析師編寫需求是為了確保參與開發地各方對需要做地事達成一致地理解。這是確保記錄和溝通需求實質地最有效方式，也確保交付地產品可測試。
分析師使用了兩種機制，使編寫需求規格說明地工作更容易。第一種機制是需求規格說明模板，它是需求規格說明的乙個提綱。
第二種機制是需求項框架，也稱為「白雪卡」，確保每項需求都有正確的組成要素。
6.質量關
需求是所有後面工作的基礎，必須保證正確性。質量關對需求進行檢查。
通常由1-2個人組成，可能是首席需求分析師和乙個測試人員。只有他們有權允許需求通過質量關。在允許需求加入需求規格說明之前，他們一起檢查每項需求的完整性、相關性、可測試性、一致性、可追蹤性和其他一些質量屬性。
7.復用需求
在開始任何新需求專案之前，瀏覽一下以前專案的規格說明書，尋找潛在可復用的東西。有時會發現很多需求都是可以復用的。
8.複查需求
複查工作確保規格說明書是完整的、恰當的，這樣可以轉向下乙個開發階段。這個過程可以評估風險和計算成本來對需求進行合理的複查。
9.迭代和增量過程
在需求業界有乙個常見誤解，認為做需求就意味著採用傳統的瀑布式過程，在某些情況下確實如此，在並不總是這樣。
產品可以以小的增量的方式進行開發。這樣做的優勢是可以盡早實現一部分用例，取得利益相關者的反饋。
10.需求反思
需求反思過程是發現過程中的優缺點。該過程包括一系列風險承擔者訪談，以及與開發者進行小組會談。
反思可能採取非正式的方式：利用喝咖啡的時間和專案小組會談，，或專案領導者通過e-mail向專案參與者收集資訊。
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.正式性指南
Bundle 究竟是什麼？
bundle用於場景 在我印象中比較深刻的是，一般用於activity之間傳遞數值，也用於handler傳送訊息，如下 intent intent new intent bundle bundle new bundle bundle.putstring key value intent.putext...
分析EOF究竟是什麼
eof僅僅是一種狀態或者說條件，需要觸發。read呼叫遇到檔案結尾，觸發該條件，結果將返回0。針對eof，對於標準輸入裝置，普通檔案，管道檔案，網路套接字檔案是read如何觸發呢？下面程式將說明 server.c 是socket套接字服務端，目的為了網路套接字檔案是read如何觸發測試用的。serv...
分析EOF究竟是什麼
eof僅僅是一種狀態或者說條件，需要觸發。read呼叫遇到檔案結尾，觸發該條件，結果將返回0。針對eof，對於標準輸入裝置，普通檔案，管道檔案，網路套接字檔案是read如何觸發呢？下面程式將說明 server.c 是socket套接字服務端，目的為了網路套接字檔案是read如何觸發測試用的。serv...