最近我呆的公司來了一批實習生，在公司培訓了幾個禮拜之后公司決定對他們進行一些測試。就是給他們出了一些可選的題目，比如《xxx租房網》、《xxx檔案管理系統》、《xxx圖書館》...等一些公司缺少的系統。公司主要有以下幾個目的：
1. 檢查實習生的培訓效果
2. 通過一個完整的應用來測試同學們，同時從里面帥選出比較優秀的學生
3. 為公司編寫一個目前缺少的系統。
我們以租房網那個題目為例，公司只是提了一些必須有的功能，比如登陸，比如發帖等基本的一些功能，其他的並沒有詳細的要求。需求文檔也是由這些幾個一組的實習生來編寫的，然后在自己實現自己的需求文檔，並自己擔任QA測試和發布。也就是說整個過程都是自己來獨立完成的。
今天有一組的同學們寫完了需求，我一看名字是xxx需求V4.doc，我當時心里還挺高興的，都知道先自己過幾遍需求，並且有版本意識。但是當我通讀完需求之后發現了非常多的問題。考慮到這些問題基本上剛出校園的同學們大都會遇到，所以有感而發寫了這篇文章。希望對大家有所幫助。如果文章中的一些觀點不正確的話，歡迎評論大家一起探討。
首先我打開他們的需求文檔，有20多頁的樣子，整個需求文檔沒有圖，僅有的一個圖還是截的別的網站的圖。其余的全是文字，整個需求文檔沒有很明顯的段落層次感。慢慢的文字有一種讓人做語文閱讀理解的感覺。然后我從頭閱讀完，一一在上面標出了自己的疑點和建議。現在總結如下：
１. 需求文檔的內容首先必須要明確，明確要做什么，要解決什么問題。當然最好也能有為什么要做這個需求。
２. 需求文檔需要明確定義系統有哪些主要功能模塊，每個模塊有哪些子模塊，有哪些主要頁面，頁面上有哪些按鈕，系統有哪些主要角色，大致的交互流程是什么樣的。文檔中需要對細節的地方定義清楚。最好使用圖或者表格的方式來進行表現。先在需求的上方列出主要功能點，主要的交互流程，然后在詳細的描述每個功能點。另外要定義清楚細節。比如我看的這個需求中有一段：“信息發布后，系統立刻自動將該條房源信息推送給符合條件的求租者。”從這段話中，我的關注點落在了【符合條件的求租者】，我的疑問是什么樣的求租者才是符合條件的呢？如何判斷某個求租者是否是滿足條件的？ 需求中沒有對這個點定義清楚，這個就是細節沒定義清楚。而開發實現的時候這個細節卻是必須要清楚的。所以 這個地方是一個問題
３. 新人寫需求文檔的時候最容易犯的錯誤就是脫離實際情況，比如我看的這個需求中寫的【利用圖片識別技術過濾虛假信息】，說實話我真心覺的剛剛本科畢業在公司培訓了幾周的同學能做出來這個東西，當然不是看不起大家的意思。我只是覺的這些有點脫離實際情況。寫需求的時候一定要結合需求的工期，看看有多少天時間，團隊成員的水平如何，執行力如何？做到“量力而行”。要記住，即便你的需求寫的天花亂墜各種NB的技術好像都用到了但是基本的功能不可用，結果一定會遠遠不如那些需求很明確簡單，但是實現的很不錯，系統功能正常運轉的方案。另外也沒有定義清楚什么是虛假信息，如何判定是否是虛假信息。
４. 需求中必須對功能進行優先級排序，明確什么功能是必須要做的，什么功能是必須要在這次需求中做的。什么可以放到下次需求。哪些功能是可選的。建議在一開始的時候，可以先簡化需求，做一個需求第一版。可能就是實現一個登錄和權限的功能。然后完成運行之后在做發帖之類的功能。通過這種迭代的方式來保證質量和工期。最后如果基本必須的功能實現好了，如果還有時間的話，可以在進行添磚加瓦，錦上添花。
５. 對於新人來說，尤其是幾個組做同一個需求的時候，千萬別比較【誰的需求文檔寫的多ＮＢ，什么時髦的技術都提到了，用到了】，即便要比，也要比誰的需求文檔寫的更切合實際情況，誰的需求文檔更能描述和解決實際的問題。有些人的需求寫的內容看起來確實很nb，但是往往最后都實現不出來。所以我覺的即便功能簡單，但是正常可用就是很不錯的東西。 尤其是互聯網的產品，最初都是一個原型，通過不斷試錯，快速迭代的方式來小步快跑的增加功能。
好了，就先寫到這邊吧。