如何寫乙個好的需求文件

1、從使用者角度的編寫

2、使用screen shots

3、用簡單的語言編寫

a)保持簡短的語句，把長的語句分解成多個小的語句。

b)避免大篇幅的連續文字，把他們分解成多個小的章節。

c)把大塊文字內容分解成，screen shots，**、重點列表等等。

4、小心的使用模板

我發現mrd模板非常有用。他們的幾個好處包括：

a) 模板提供了乙個標準的格式，使那些不得不閱讀大量mrd的讀者更加容易閱讀。

b) 模板讓新的產品經理快速的寫mrd變得容易，因為公司與公司之間的mrd內容是不同的。

c) 模板確保你不會忘記所有需要在mrd中覆蓋描述的部分；

5、區分需求的優先順序

區分需求的優先順序是乙個最好的能幫助完成這個事情的辦法。我發現把需求分等級就像p1，p2，p3...這樣工作的剛剛好。在這個分類中-p1是最高優先順序，p2是第二高優先順序等等。

我們只要包括p1，p2，p3的需求在你的mrd中，在多數的專案中更低的優先順序可能未必會實現。還有這樣也讓mrd變得更加容易讀。

6、說明"是什麼"和"為什麼"，但不要"如何"

為理解客戶的需求負責，然後基於這些理解定義什麼和為什麼需要開發.

推薦-描述「是什麼」，不推薦-描述「怎麼樣」。

有技術背景的產品經理尤其喜歡描述「如何實現」。如果這些描述的就是你，應該從現在開始不要再做這樣的事了。工程師們將會感謝你。

7、覆蓋非功能性需求

儘管功能性需求描述產品的功能，非功能性需求描述系統特性，如：

a)效能

b)可伸縮性

c)可用性

d)國際化

e)等等...

我注意到因為許多產品經理和產品市場人員認為這些是「技術細節」，而在mrd中被忽略。我發現這些是我的mrd中非常重要的一部分，工程師們會非常感激在mrd中定義這些需求。

要點：當寫非功能性需求的時候，盡可能的是使他們可度量（可測試）。否則，qa不能測試它們，你將沒有辦法知道完成的產品是否已經實現了這些非功能性需求。

8、評審&修正

9、定義市場目標和定位

這些問題（誰將買和使使用者你的產品和與競爭對手的產品比你的產品定位怎麼樣的）的確有一些正面價值，我發現許多任務程師想知道為什麼乙個產品或特性要開發，誰將使用他們，什麼是他們可以另外選擇辦法。

這些資訊幫助他們和產品組的其他成員想象終端使用者並從而更好的為創造成功的產品工作。我的建議的盡可能的（在mrd中）包含這些資訊。- 它們不一定要很詳細，只要包含幾個段落就足夠了。

10、包含乙個術語表

如何寫乙個好的需求文件

1 從使用者角度的編寫 2 使用screen shots 3 用簡單的語言編寫 a 保持簡短的語句，把長的語句分解成多個小的語句。b 避免大篇幅的連續文字，把他們分解成多個小的章節。c 把大塊文字內容分解成，screen shots，重點列表等等。4 小心的使用模板 我發現mrd模板非常有用。他們的...

如何寫乙個好的缺陷（Defect）報告

編寫缺陷報告是測試人員的日常工作，好的缺陷報告能夠讓開發人員更容易理解，更快速的定位問題 不好的缺陷報告可能會誤導調查方向，增加溝通成本。那麼乙個好的缺陷報告應該包括哪些方面呢？請看我的mindmap 1.首先要做乙個 標題黨 此標題黨非彼標題黨 標題一定要清晰簡潔易理解，不應該臃長 2.盡量字首要...

如何寫乙個Stack？

1.棧是陣列 2.先進後出 3.出棧 4.入棧 手寫乙個雙向鍊錶 棧 public class stackpopandpush public stackpopandpush int lens 返回元素個數 public intsize 返回陣列長度，容量，棧資料長 private intcapaci...