之前的部落格已經說過我的是《軟體需求》，那麼什麼是軟體需求，軟體需求是幹什麼的，為什麼要有這門課，他的意義是什麼？
總所周知，乙個碼農的工作壽命不可能超過40歲，因為那時，他已經沒有精力去程式設計和思考一些演算法問題了，而且公司更想要那些剛剛畢業的大學生，精力旺盛，而且工資水平不高，還能熬夜，所以，乙個40歲之後的碼農如何可以拜託事業的名義呢？就是上公升成為產品經理，為什麼產品經理的工資待遇高而且不用寫**呢？因為他們能直接和客戶交流，懂得客戶需求什麼，客戶想要的是什麼，可以將使用者的抽象描述用專業的術語轉達給程式設計師，這樣才能有好多軟體。
所以，你需求了解使用者需要的什麼，使用者為什麼要這樣做。
客戶所定義的「需求」對開發者似乎是乙個較高層次的產品概念。而開發人員所說的「需求」對使用者來說又像是詳細設計了。實際上，軟體需求包含著多個層次，不同層次的需求從不同角度與不同程度反映著細節問題。需求是指明必須實現什麼的規格說明。它描述了系統的行為、特性或屬性，是在開發過程中對系統的約束。軟體需求包括三個不同的層次—業務需求、使用者需求和功能需求—也包括非功能需求。業務需求（business requirement）反映了組織機構或客戶對系統、產品高層次的目標要求，它
們在專案檢視與範圍文件中予以說明。使用者需求(user requirement) 文件描述了使用者使用產品
必須要完成的任務，這在使用例項（use case）文件或方案指令碼（
s c e n a r i o
）說明中予以說明。
功能需求(functional requirement)定義了開發人員必須實現的軟體功能，使得使用者能完成他們
的任務，從而滿足了業務需求。所謂特性( f e a t u r e )是指邏輯上相關的功能需求的集合，給使用者提供處理能力並滿足業務需求。
開發軟體系統最為困難的部分就是準確說明開發什麼。最為困難的概念性工作便是編寫出詳細技術需求，這包括所有面向使用者、面向機器和其它軟體系統的介面。同時這也是一旦做錯，將最終會給系統帶來極大損害的部分，並且以後再對它進行修改也極為困難。每個軟體產品都是為了使其使用者能以某種方式改善他們的生活，於是，花在了解他們需要上的時間便是使專案成功的一種高層次的投資。這對於商業終端使用者應用程式，企業資訊系統和軟體作為乙個大系統的一部分的產品是顯而易見的。但是對於我們開發人員來說，並沒有編寫出客戶認可的需求文件，我們如何知道專案於何時結束？而如果我們不知道什麼對客戶來說是重要的，那我們又如何能使客戶感到滿意呢？然而，即便並非出於商業目的的軟體需求也是必須的。例如軟體庫、元件和工具這些供開發小組內部使用的軟體。當然你可能偶爾勿需文件說明就能與其他人意見較為一致，但更常見的是出現重複返工這種不可避免的後果，而重新編制**的代價遠遠超過重寫乙份需求文件的代價。
上面的描述就是軟體需求需要解決的問題。
軟體需求分析閱讀筆記1
一 需求的基礎與過程 這一部分主要是對軟體需求有乙個大致的了解，例如需求的概念，不同群體的人們對需求有不同的理解，ieee對需求的定義 使用者為了解決問題或達到某些目標所需要的條件和能力 系統或系統部件為了滿足合同 標準 規範或其他正式文件所規定的需求而需要具備的條件或能力。軟體系統通過影響問題域，...
軟體需求閱讀筆記
案例 某大銀行的一位銀行卡辦公室的收賬經理liz遇到了乙個問題。她每週都收到乙份過期未付款的賬戶名單。這份報告已經從兩年前的250個賬戶增加到現在的1250個賬戶。為了確定那些嚴重拖欠債務的賬戶，liz需要通讀這份報告。嚴重拖欠債務的賬戶由幾個不同的規則確定，每個規則都要求liz檢查客戶的一項或幾項...
軟體需求閱讀筆記08
需求分析是需求工程中最為核心的工作，需求建模是需求分析的主要手段。分解分解有很多種，如下業務流程為主線索的分解結構 程式結構為主線索的分解結構 基於場景的分解結構 基於資料的分解結構 提煉抽取業務事件中的相同部分 消除矛盾 需求分析過程中不免會出現矛盾，再過程的最後要消除這些矛盾 建模通過簡化 強調...