在論壇里看到zandb提問到：“作為軟件產(chǎn)品的需求分析，我們是否應(yīng)該注重具體的實現(xiàn)？對需求文檔的撰寫、需求描述，是否應(yīng)該涉及到具體的實現(xiàn)呢？還是應(yīng)該在功能上給予說明即可？”
這是個很好的問題，關(guān)于需求分析粒度的問題。
zandb舉了一個例子，例如Office Word里的“替換”功能?！皩τ谶@個功能的需求描述，是否應(yīng)該寫成：選擇‘編輯’，在下拉式菜單中單擊‘替換’，顯示替換窗口，在替換窗口中‘查找內(nèi)容’中輸入想要被替換的字符串，在‘替換為’編輯框中輸入希望替換的字符串，單擊‘全部替換’按鈕，軟件將會完成替換操作?！边€是“僅僅描述功能，像這樣：軟件應(yīng)實現(xiàn)‘替換’功能，允許用戶輸入被替換的內(nèi)容和要替換的內(nèi)容，進(jìn)而完成單個替換和全部替換”就可以了呢？
從大家的回帖，對于需求分析，大部分人認(rèn)為需求分析應(yīng)該僅是功能的描述。比如，simonxln就說：“應(yīng)該是功能說明吧?！?mengge認(rèn)為：“前者像設(shè)計，后者像需求。”daniellu1231也覺得“應(yīng)該僅僅只描述這個功能是干嘛用的，因為是在尋找需求，具體實現(xiàn)沒必要在這個階段考慮”。
事實上，需求是回答“需要什么”的問題，而實現(xiàn)才是解決怎樣才能做到的問題。
針對不同的用途，需求文檔可能表現(xiàn)為不同的形式，比如：
1．售前方案書：在項目簽約之前為用戶提供的重點功能描述。
2．需求分析報告：為項目雙方約定設(shè)計任務(wù)的基本內(nèi)容，限定設(shè)計任務(wù)的邊界。
3．需求規(guī)格說明書：對系統(tǒng)的設(shè)計目標(biāo)與功能體系進(jìn)行相對完整的說明，在需求報告的基礎(chǔ)上，增加對設(shè)計過程的支持與約束。
前兩種方案對項目的實現(xiàn)過程影響不是很大，需求規(guī)格說明則經(jīng)常是系統(tǒng)架構(gòu)設(shè)計所要參照的重要文件。因此，個人淺見，在不同的階段、不同的場合，需求文檔的撰寫也有所不同，是簡單的描述還是完整的說明，要根據(jù)實際需要來決定。但不論哪種形式，都是需求文檔的一種。