看實習生需求文檔有感

最近我呆的公司來了一批實習生，在公司培訓了幾個禮拜以後公司決定對他們進行一些測試。就是給他們出了一些可選的題目，好比《xxx租房網》、《xxx檔案管理系統》、《xxx圖書館》...等一些公司缺乏的系統。公司主要有如下幾個目的：

 

　　1. 檢查實習生的培訓效果

　　2. 經過一個完整的應用來測試同窗們，同時從裏面帥選出比較優秀的學生

      3. 爲公司編寫一個目前缺乏的系統。

 

咱們以租房網那個題目爲例，公司只是提了一些必須有的功能，好比登錄，好比發帖等基本的一些功能，其餘的並無詳細的要求。需求文檔也是由這些幾個一組的實習生來編寫的，而後在本身實現本身的需求文檔，並本身擔任QA測試和發佈。也就是說整個過程都是本身來獨立完成的。

 

今天有一組的同窗們寫完了需求，我一看名字是xxx需求V4.doc，我當時內心還挺高興的，都知道先本身過幾遍需求，而且有版本意識。可是當我通讀完需求以後發現了很是多的問題。考慮到這些問題基本上剛出校園的同窗們大都會遇到，因此有感而發寫了這篇文章。但願對你們有所幫助。若是文章中的一些觀點不正確的話，歡迎評論你們一塊兒探討。

 

首先我打開他們的需求文檔，有20多頁的樣子，整個需求文檔沒有圖，僅有的一個圖仍是截的別的網站的圖。其他的全是文字，整個需求文檔沒有很明顯的段落層次感。慢慢的文字有一種讓人作語文閱讀理解的感受。而後我從頭閱讀完，一一在上面標出了本身的疑點和建議。如今總結以下：

１.　需求文檔的內容首先必需要明確，明確要作什麼，要解決什麼問題。固然最好也能有爲何要作這個需求。

 

２.　需求文檔須要明肯定義系統有哪些主要功能模塊，每一個模塊有哪些子模塊，有哪些主要頁面，頁面上有哪些按鈕，系統有哪些主要角色，大體的交互流程是什麼樣的。文檔中須要對細節的地方定義清楚。最好使用圖或者表格的方式來進行表現。先在需求的上方列出主要功能點，主要的交互流程，而後在詳細的描述每一個功能點。另外要定義清楚細節。好比我看的這個需求中有一段：「信息發佈後，系統馬上自動將該條房源信息推送給符合條件的求租者。」從這段話中，個人關注點落在了【符合條件的求租者】，個人疑問是什麼樣的求租者纔是符合條件的呢？如何判斷某個求租者是不是知足條件的？ 需求中沒有對這個點定義清楚，這個就是細節沒定義清楚。而開發實現的時候這個細節倒是必需要清楚的。因此 這個地方是一個問題

 

３.　新人寫需求文檔的時候最容易犯的錯誤就是脫離實際狀況，好比我看的這個需求中寫的【利用圖片識別技術過濾虛假信息】，說實話我真心覺的剛剛本科畢業在公司培訓了幾周的同窗能作出來這個東西，固然不是看不起你們的意思。我只是覺的這些有點脫離實際狀況。寫需求的時候必定要結合需求的工期，看看有多少天時間，團隊成員的水平如何，執行力如何？作到「量力而行」。要記住，即使你的需求寫的天花亂墜各類NB的技術好像都用到了可是基本的功能不可用，結果必定會遠遠不如那些需求很明確簡單，可是實現的很不錯，系統功能正常運轉的方案。另外也沒有定義清楚什麼是虛假信息，如何斷定是不是虛假信息。

 

４.　需求中必須對功能進行優先級排序，明確什麼功能是必需要作的，什麼功能是必需要在此次需求中作的。什麼能夠放到下次需求。哪些功能是可選的。建議在一開始的時候，能夠先簡化需求，作一個需求初版。可能就是實現一個登陸和權限的功能。而後完成運行以後在作發帖之類的功能。經過這種迭代的方式來保證質量和工期。最後若是基本必須的功能實現好了，若是還有時間的話，能夠在進行添磚加瓦，錦上添花。

 

５.　對於新人來講，尤爲是幾個組作同一個需求的時候，千萬別比較【誰的需求文檔寫的多ＮＢ，什麼時髦的技術都提到了，用到了】，即使要比，也要比誰的需求文檔寫的更切合實際狀況，誰的需求文檔更能描述和解決實際的問題。有些人的需求寫的內容看起來確實很nb，可是每每最後都實現不出來。因此我覺的即使功能簡單，可是正常可用就是很不錯的東西。 尤爲是互聯網的產品，最初都是一個原型，經過不斷試錯，快速迭代的方式來小步快跑的增長功能。

 

好了，就先寫到這邊吧。