在論壇裡看到zandb提問到：「作為軟體產品的需求分析，我們是否應該注重具體的實現？對需求文件的撰寫、需求描述，是否應該涉及到具體的實現呢？還是應該在功能上給予說明即可？」
這是個很好的問題，關於需求分析粒度的問題。
zandb舉了乙個例子，例如office
word 裡 的「替換」功能。「對於這個功能的需求描述，是否應該寫成：選擇『編輯』，在下拉式選單中單擊『替換』，顯示替換視窗，在替換視窗中『查詢內容』中輸入想 要被替換的字串，在『替換為』編輯框中輸入希望替換的字串，單擊『全部替換』按鈕，軟體將會完成替換操作。」還是「僅僅描述功能，像這樣：軟體應實現 『替換』功能，允許使用者輸入被替換的內容和要替換的內容，進而完成單個替換和全部替換」就可以了呢？
從大家的回帖，對於需求分析，大部分人認為需求分析應該僅是功能的描述。比如，simonxln就說：「應該是功能說明吧。」 mengge認為：「前者像設計，後者像需求。」daniellu1231也覺得「應該僅僅只描述這個功能是幹嘛用的，因為是在尋找需求，具體實現沒必要 在這個階段考慮」。
事實上，需求是回答「需要什麼」的問題，而實現才是解決怎樣才能做到的問題。
針對不同的用途，需求文件可能表現為不同的形式，比如：
1．售前方案書：在專案簽約之前為使用者提供的重點功能描述。
2．需求分析報告：為專案雙方約定設計任務的基本內容，限定設計任務的邊界。
3．需求規格說明書：對系統的設計目標與功能體系進行相對完整的說明，在需求報告的基礎上，增加對設計過程的支援與約束。
前兩種方案對專案的實現過程影響不是很大，需求規格說明則經常是系統架構設計所要參照的重要檔案。因此，個人淺見，在不同的階段、不同的場合，需求文件的撰寫也有所不同，是簡單的描述還是完整的說明，要根據實際需要來決定。但不論哪種形式，都是需求文件的一種。
專業實訓題目需求分析
題目 小二跑腿 業務需求 業務主要想解決使用者可以不出宿舍能讓別人幫自己帶來自己需要的東西，業務主要抓住現在大學生惰性的特點，在宿舍不想出去買需要的東西這一特點開發了這款軟體，能讓客戶可以足不出戶付出較小的代價能拿到自己想要的東西。同時業務也抓住了人們喜歡利益的心裡讓為軟體服務的人為客戶自身，實現了...
java程式訪問http，或https最簡單的方法
首先要引入包http request 5.6.jar 關於jar包，我已經是上傳了哈。下面 其實就幾句就行了，其他業務 不必理會。this method is 授權 return createtime 2015年1月5日 下午4 26 09 author yangwd public string a...
簡析軟體需求的分析過程
itpub論壇2009 06 15 文字tag 需求分析 it168 技術文章 最近正在做新產品的需求分析，對需求分析階段的很多問題又有了重新的認識，在此結合以前的經驗，就軟體 需求分析階段的各個任務，做一下總結，與大家分享。眾所周知，軟體需求分析是軟體生命週期的第二階段，主要對前期軟體定義及計畫階...