半年沒有接觸.net了，最近公司又讓我參與半年前就已經啟動的乙個.net web專案，這次我負責一部分編碼和所有的測試。為了快速的融入團隊的開發工作中，我就必須盡快熟悉整個專案的環境。
這個專案雖然提供了需求文件，但是長篇大幅的，內容也比較多，看著也容易犯睏。需求是必須要了解的，自己又是負責測試部分，那麼我必須要對整個**的整體和細節部分都要清楚。
我個人認為，在接觸需求的時候，不能夠死磕需求文件，死磕需求僅僅是去做功能，這是比較機械的。我們需要站在使用者的角度去分析和理解需求，把自己放在普通使用者的位置去感受和想象，而不是開發人員的角度。
我把文件看一遍，**也瀏覽了一遍，但是對**的功能和流程仍然比較模糊，心中也沒有乙個具體的概念。我在瀏覽整個專案的ui草圖時，突然間得到了靈感：整個**頁面元素比較多的頁面就二三十個，我何不把這些頁面做成截圖的形式，對照著需求文件，在上一一把需求給標註出來呢？
我以下面這張截圖裡面的頁面為例。
大體一看，這個頁面按鈕也不少，而且很多按鈕元素比較隱秘，很難一眼看出來。如果對照需求去看，或許這次自己了解了，但是下次可能因疏忽而忘記某些頁面元素和功能，通過在圖上進行簡略的標註，能夠得到很直觀的需求，而且條目也非常清晰。
對照文件中的需求在圖上標註需求得到的結果如下，在測試這些功能時我也不必對著word文件去一一驗證，看圖就能了解需求部分了。
有些批註裡面的文字比較長，我就擷取部分關鍵的字，加重顯示，以後也不必每條都看完所有文字。了解需求後，我還得提供乙個測試文件，以測試這些功能。
功能
測試頁面
測試用例\用例步驟
bug
測試結果
1.功能1
url1. 用例一
a)b)
c)2.用例二
a)b)
c)1.bug1
2.bug2
3.bug3
(並提交到bug管理工具裡面，顯示bug原因，級別，截圖)
1.失敗
原因：2.成功
2.功能1
url1. 用例一
a)b)
c)2.用例二
a)b)
c)1.bug1
2.bug2
3.bug3
(並提交到bug管理工具裡面，顯示bug原因，級別，截圖)
1.失敗
原因：2.成功
3.功能1
url1. 用例一
a)b)
c)2.用例二
a)b)
c)1.bug1
2.bug2
3.bug3
(並提交到bug管理工具裡面，顯示bug原因，級別，截圖)
1.失敗
原因：2.成功
4.功能1
url1. 用例一
a)b)
c)2.用例二
a)b)
c)1.bug1
2.bug2
3.bug3
(並提交到bug管理工具裡面，顯示bug原因，級別，截圖)
1.失敗
原因：2.成功
由於是第一次擔任測試工作，文件也是隨心所欲，希望能有前輩提供一些建議，我能夠通過改進也運用到專案中（ps:公司沒有測試人員）
我是如何去了解需求的
半年沒有接觸.net了，最近公司又讓我參與半年前就已經啟動的乙個.net web專案，這次我負責一部分編碼和所有的測試。為了快速的融入團隊的開發工作中，我就必須盡快熟悉整個專案的環境。這個專案雖然提供了需求文件，但是長篇大幅的，內容也比較多，看著也容易犯睏。需求是必須要了解的，自己又是負責測試部分，...
如何了解需求？
大家都知道，做好乙個軟體專案的關鍵，在於需求的把握。那麼我們怎麼把握好需求了，我想每乙個設計師都可能有一套自己的理論和方法。我也不例外，這裡我就說說說我自己的方法吧。首先，大家都知道，了解需求的手段主要是通過面對面的交流。當然，也可以可以用郵件 甚至簡訊的方式來交流。但是我們都知道，這些手段都只是在...
產品經理如何了解使用者的需求？
今天特別想跟大家聊聊需求這件 小事 人人都是產品經理這句話說得不無道理，無論你從事哪個行業，都會提到 使用者需求 這個詞 尤其是對網際網路產品經理來說，需求是一切之始，先有了需求，才有了產品經理的一切職責的發揮空間，如果沒有需求，一切都無從談起，產品經理這個職位也就沒有了存在的價值。作為產品經理的你...