我們做軟體是需要有個較規範的流程的，即是是乙個小軟體（除非只是乙個小功能）也是需要的，如果沒有流程，隨便搞的話，就會出現很多預期不到的問題。
在軟體流程前期有個需求階段，在需求階段，很多朋友常常搞不清或者容易把功能和需求給混淆了。那麼接下來我們談談功能和需求的區別，以及關係吧。
下面這些定義是需求工程領域中常見術語的定義。
軟體需求包括三個不同的層次：業務需求、使用者需求和功能需求（也包括非功能需求）。
1．業務需求（business requirement）反映了組織機構或客戶對系統、產品高層次的目標要求，它們在專案檢視與範圍文件中予以說明。
2．使用者需求(user requirement) 文件描述了使用者使用產品必須要完成的任務，這在使用例項（use case）文件或方案指令碼說明中予以說明。
3．功能需求(functional requirement)定義了開發人員必須實現的軟體功能，使得使用者能完成他們的任務，從而滿足了業務需求。
下面以乙個單人臥室的布置為例來說明需求和功能的概念區別。乙個單人臥室的布置，它需要被完成的就是提供乙個可以舒適休息的環境，平時休息可能需要一張沙發，晚上睡覺還需要一張床，還有需要書桌和書架用來學習等。
接下來就平時休息而言，我們在做需求分析的時候，就會想到，沙發。
那麼我們從軟體需求定義的概念中看，業務需求可能是：「需要休息」，這是乙個大的，高層次的目標性需求。
而真正的需求就是，使用者需求：「我需要乙個舒適的可以滿足平時休息的乙個工具。」
功能需求，即功能：提供乙個沙發。
仔細分析我們就會發現，使用者需求就是我們在做需求工程中所理解的需求，它所要關注的是充分說明使用者究竟想做什麼，想得到什麼效果。
而功能不是，功能就是定義中的功能需求，它是用來描述具體功能的，它所關注的是提供沙發，將沙發看做乙個功能，然而，你可以想也許座椅也可以實現使用者需求。
從以上定義可以發現，需求並未包括設計細節、實現細節、專案計畫資訊或測試資訊。需求與這些沒有關係，它關注的是充分說明你究竟想開發什麼。
功能測試之拆解需求
將業務需求分解成功能需求 了解業務背景 做這個需求的目的是什麼 業務需求 需求的大致邏輯 功能需求 為了實現業務需求，軟體應有的功能。有的是需求文件明確寫出來的 有的是需求文件中未提及的，未提及到的則需要我們根據自身的軟體測試經驗來進行補充並想產品確認 這個過程，可以用寫思維導圖體現 測試需求 為了...
《需求工程》閱讀筆記之六
在完成功能分解之後，可以建立完整的資料流圖層次結構。在這個結構中，所有複雜過程都被解釋為乙個低層次的資料流子圖。但是層次結構當中最低層次的原始過程卻沒有得到更為細節化的展示。為了充分描述系統功能，需要描述這些原始過程的處理邏輯，這個任務就是通過微規格說明技術來實現的。微規格說明是一些用來描述過程處理...
《需求工程》閱讀筆記之四
簡單來說，需求工程是所有需求處理活動的總和，它收集資訊 分析問題 整合觀點 記錄需求並驗證其正確性，最終反映軟體被應用後與其環境互動形成的期望效應。從細節來看，需求工程是軟體工程的乙個分支，它關注軟體系統所應實現的現實世界目標 軟體系統的功能和軟體系統應當遵守的約束，同時，也關注以上因素和準確的軟體...