功能規格和內容需求

“為什么會有這功能？”

*??? 范圍層在做兩件事情：這是一個有價值的過程，同時能產生有價值的產品。

過程的價值在于， 在產品處在假設階段的時候，使你迫使去考慮潛在沖突和產品一些粗略的點

產品的價值在于，被定義的這個產品給整個團隊一個參考的點，明確了這個項目要完成的全部工作。定義好你的要求能保證在設計過程中不會出現不確定的點。

>日程安排與里程碑

>用文檔定義產品需求

用文檔來定義需求：

1.你可以知道同時也讓別人知道你正在建設什么，建設的目標，以及什么時候達到目標。

2.責任劃分更清楚

3.知道你不需要建設什么，把多余的想法收集起來。進行長期規劃

功能和需求

>定義需求

1、適用于整個系統的需求，如品牌需求

2、技術需求，并發數、瀏覽器兼容

3、特殊性的需求

去了解“人們在想什么”的最佳途徑就是直接詢問他們。

>三類需求：

1.人們講述的最顯而易見的想法、其中會有非常清晰的好想法，會最終通過各種途徑實現在產品上。

2、有時候人們口中所說的與期望的并不同，當人們在某個過程或產品中遇到困難，會想出某個解決辦法緩解，但往往是行不通的，你需要與用戶探討為什么遇到困難，用戶這個需求最終的目的是什么，往往會得到不同的需求。

3、第三種需求是人們不知道他是否需要的特性，比如在討論新需求或者產品戰略時，會突然冒出一個偉大的構思，多數情況在頭腦風暴中產生。匯集各個部門以及不同的代表用戶進行頭腦風暴，是一種打開設計者思路，讓他們從未想到的可能性非常有效的工具。

>你的產品在什么硬件上使用，是否用到定位、陀螺感應、照相、聲音等等

> 將用戶置身于“場景”之中，想像用戶將經歷怎么樣的過程，幫我找到 幫助他順利完成的潛在需求

>競爭對手與我們有相似的產品目標，他們是否找到一種有效特性來完成某個戰略目標，他們是如何調整和權衡我們所遇到的問題

>以及其他平臺機制的借鑒

文檔原則：文檔足夠清楚和準確

只需包括設計或者開發過程中可能混淆的功能定義，只需記錄在創建這個產品時已經確定下來的決議

>記錄下來

樂觀??? 描述這個系統將要做什么 去 防止 不好的事情發生

具體??? 盡可能詳細的解釋清楚狀況

避免主觀語氣??? 規格功能必須可以進行驗證

>內容需求

建立內容清單，必須同搞清楚具體需求一樣重要，這樣團隊每個人就會確切的知道為設計用戶體驗該做那些工作。

確定需求優先級

1.優先滿足戰略目標（產品目標與用戶需求）?? 考慮 實現需求的可行性?

2 如果時間有限 則 把這個特性放到下個版本去做、如果是資源有限則技術或者企業的變化有事能減少資源的負擔

解決高層之爭 是 “制定戰略”，關注戰略目標 而不是 實現戰略的手段。