1譬巫、需求文檔應(yīng)該包含什么內(nèi)容组哩？
需求文檔到底要寫什么內(nèi)容等龙，這個不可一概而論，應(yīng)該根據(jù)具體的項目情況酌情考慮伶贰，選擇最適合當前情況的文檔格式而咆。常規(guī)情況下漫蛔，需求文檔應(yīng)該包含前面提到的產(chǎn)品定位宁炫、需求內(nèi)容、需求優(yōu)先級等锨阿，以及關(guān)于需求的詳細描述說明们豌。下面是關(guān)于標準需求文檔的內(nèi)容示例涯捻。
1.文檔修改與審核記錄
需求文檔如有修改，需要簡要記錄望迎。
2.目錄
如內(nèi)容過多最好提供目錄障癌。
3.背景描述
為什么要做這個產(chǎn)品、市場行情辩尊、業(yè)務(wù)目標涛浙、產(chǎn)品定位。
4.用戶類型和特征
簡單描述目標用戶情況或現(xiàn)有使用人群的情況摄欲。
5.項目時間安排
何時啟動轿亮，何時完成等。
6.信息結(jié)構(gòu)
內(nèi)容或頁面的層級胸墙。
7.整體業(yè)務(wù)流程說明
對于涉及操作較多的產(chǎn)品/功能我注，需要業(yè)務(wù)流程圖，幫助設(shè)計師和項目成員理解具體的業(yè)務(wù)邏輯迟隅。比如一個廣告投放系統(tǒng)但骨，當廣告排期被占用時励七，用戶是否可接受相關(guān)位置；如不接受奔缠，系統(tǒng)如何處理賬戶金額等等掠抬。
8.需求詳細說明
每一條需求的詳細說明。一個文檔里會有若干條這樣的說明校哎。
9.需求文檔的后續(xù)迭代
需求文檔不可能一次到位两波。誰也不能保證一次把所有的問題想清楚。一般來說贬蛙，在完成需求文檔后，需要進行需求評審谚攒。評審時主要看需求有沒有明顯的漏洞阳准、不合理的地方，在技術(shù)上有沒有實現(xiàn)難度馏臭，能不能按期完成等野蝇。評審過后，產(chǎn)品經(jīng)理會根據(jù)大家的意見重新修改括儒。文檔迭代3次以上是很正常的現(xiàn)象绕沈。
另外，有一些較細節(jié)的東西在需求階段不容易考慮清楚帮寻，要到具體的設(shè)計階段才會有更深入的思考乍狐。但一些產(chǎn)品經(jīng)理為了方便大家理解，會在需求文檔中增加一些UI示意圖固逗。
最后一點要注意的是浅蚪，設(shè)計師不要嚴格按照需求文檔來做設(shè)計。產(chǎn)品經(jīng)理的考慮角度和設(shè)計師不可能完全一樣烫罩，需求文檔更多的是體現(xiàn)業(yè)務(wù)惜傲、產(chǎn)品要求、功能等內(nèi)容贝攒，而設(shè)計師還需要更多地去考慮目標用戶的特征盗誊、使用場景、痛點等隘弊。這些信息綜合起來哈踱，才是設(shè)計的主要依據(jù)。如果設(shè)計師參與了之前的產(chǎn)品定位梨熙、需求采集與分析過程嚣鄙，就會對用戶的情況比較了解。
因此串结，專業(yè)的交互設(shè)計師產(chǎn)出的設(shè)計結(jié)果一般都會和需求文檔提供的內(nèi)容不太一樣哑子，如信息結(jié)構(gòu)舅列、任務(wù)流程、內(nèi)容卧蜓、界面形式等帐要。只要經(jīng)過有效的溝通，產(chǎn)品經(jīng)理一般都是可以接受的弥奸。這相當于是在交互設(shè)計階段對文檔進行了迭代榨惠。產(chǎn)品經(jīng)理可以在設(shè)計完成后再修正需求文檔，也可以讓設(shè)計師把相應(yīng)的修改部分注釋在原型稿上盛霎，這樣開發(fā)人員只看原型稿就可以了赠橙。
