首先談下需求的兩個層面的問題，一個層面是從需求收集調(diào)研到用戶需求的開發(fā)；第二個層面是軟件需求和原型的開發(fā)。第一階段重點是真正搞清楚用戶的問題域和場景，從用戶的How和What轉(zhuǎn)移到用戶的Why的根源分析，只有這樣才能夠真正挖掘潛在的需求；第二階段重點則是系統(tǒng)分析，是從現(xiàn)實到抽象的轉(zhuǎn)化，重點是軟件需求，原型和用戶業(yè)務(wù)場景的交互實現(xiàn)考慮。兩個階段應(yīng)該有一定程度的分離，否則很容易造成需求挖掘不充分，出現(xiàn)針對問題而問題，針對功能而功能的非系統(tǒng)解決方案。
其次對于需求收集，分析和開發(fā)工作。我們?nèi)匀缓軓娬{(diào)業(yè)務(wù)場景這個詞，在UML 2.0專門有了業(yè)務(wù)建模的概念，包括業(yè)務(wù)用例，活動圖，狀態(tài)圖和業(yè)務(wù)組件和對象模型等幫助我們完成對業(yè)務(wù)場景的系統(tǒng)建模。然后我們往往很容易跳過這一塊而直接過渡到系統(tǒng)用例，而系統(tǒng)用例的重點已經(jīng)會轉(zhuǎn)移到功能的實現(xiàn)上面。一個功能的實現(xiàn)沒有站在用戶角度去考慮不同的業(yè)務(wù)場景下，系統(tǒng)如何去更好的支持，導(dǎo)致出現(xiàn)大量的需求遺漏和易用性的問題。這也是易用性的一個較高層次，即業(yè)務(wù)易用性，是否進(jìn)行了分角色和分場景的設(shè)計。
在談UCD和交互設(shè)計的時候，這個時候談到了易用性的動態(tài)模型，我們原來談界面規(guī)范和配色等更多的是考慮系統(tǒng)的靜態(tài)易用性問題。在談交互設(shè)計的時候，則是要結(jié)合業(yè)務(wù)場景和業(yè)務(wù)角色，考慮系統(tǒng)的動態(tài)易用性問題，界面規(guī)范容易總結(jié)，但是交互規(guī)范和模式卻往往很難進(jìn)行總結(jié)。簡單而言，交互模式需要去回答一個問題，即在不同的業(yè)務(wù)場景下，最佳的交互方案是如何的，這里面究竟有沒有規(guī)律可遵循？
軟件做出來的功能不是用戶想要的，則是我們在出功能性需求的時候出現(xiàn)明顯的偏差。但是如何功能是不好用，則是我們沒有重視需求開發(fā)中的非功能性需求方面的描述，而關(guān)于軟件的性能，UI和交互，安全性，可靠性和健壯性等都是軟件的非功能性需求。很多時候軟件產(chǎn)品的失敗往往就是在非功能性需求上面。
需求的描述上面需要盡量的結(jié)構(gòu)化和條目化，好的需求不僅僅是完整和正確，更加重要的是一定是可以驗證的，因此不能出現(xiàn)任何類似易用，較快等模棱兩可的詞語。另外對于業(yè)務(wù)場景和到了系統(tǒng)用例的軟件需求之間，可能一個場景會對應(yīng)多個用例，也可能一個用例要實現(xiàn)多個業(yè)務(wù)場景，如何將業(yè)務(wù)場景體現(xiàn)到用例中去是必須要分析和解決的一個問題。同時體現(xiàn)了場景后，需求可以更好的指導(dǎo)測試用例的編寫，因為我們對測試用例更加強調(diào)基于業(yè)務(wù)場景的測試。
項目經(jīng)理勝任力免費測評PMQ上線啦！快來測測你排多少名吧~
http://opto-elec.com.cn/pmqhd/index.html
