首先談下需求的兩個(gè)層面的問題，一個(gè)層面是從需求收集調(diào)研到用戶需求的開發(fā)；第二個(gè)層面是軟件需求和原型的開發(fā)。第一階段重點(diǎn)是真正搞清楚用戶的問題域和場景，從用戶的How和What轉(zhuǎn)移到用戶的Why的根源分析，只有這樣才能夠真正挖掘潛在的需求；第二階段重點(diǎn)則是系統(tǒng)分析，是從現(xiàn)實(shí)到抽象的轉(zhuǎn)化，重點(diǎn)是軟件需求，原型和用戶業(yè)務(wù)場景的交互實(shí)現(xiàn)考慮。兩個(gè)階段應(yīng)該有一定程度的分離，否則很容易造成需求挖掘不充分，出現(xiàn)針對(duì)問題而問題，針對(duì)功能而功能的非系統(tǒng)解決方案。 

　　其次對(duì)于需求收集，分析和開發(fā)工作。我們?nèi)匀缓軓?qiáng)調(diào)業(yè)務(wù)場景這個(gè)詞，在UML 2.0專門有了業(yè)務(wù)建模的概念，包括業(yè)務(wù)用例，活動(dòng)圖，狀態(tài)圖和業(yè)務(wù)組件和對(duì)象模型等幫助我們完成對(duì)業(yè)務(wù)場景的系統(tǒng)建模。然后我們往往很容易跳過這一塊而直接過渡到系統(tǒng)用例，而系統(tǒng)用例的重點(diǎn)已經(jīng)會(huì)轉(zhuǎn)移到功能的實(shí)現(xiàn)上面。一個(gè)功能的實(shí)現(xiàn)沒有站在用戶角度去考慮不同的業(yè)務(wù)場景下，系統(tǒng)如何去更好的支持，導(dǎo)致出現(xiàn)大量的需求遺漏和易用性的問題。這也是易用性的一個(gè)較高層次，即業(yè)務(wù)易用性，是否進(jìn)行了分角色和分場景的設(shè)計(jì)。 

　　在談UCD和交互設(shè)計(jì)的時(shí)候，這個(gè)時(shí)候談到了易用性的動(dòng)態(tài)模型，我們?cè)瓉碚劷缑嬉?guī)范和配色等更多的是考慮系統(tǒng)的靜態(tài)易用性問題。在談交互設(shè)計(jì)的時(shí)候，則是要結(jié)合業(yè)務(wù)場景和業(yè)務(wù)角色，考慮系統(tǒng)的動(dòng)態(tài)易用性問題，界面規(guī)范容易總結(jié)，但是交互規(guī)范和模式卻往往很難進(jìn)行總結(jié)。簡單而言，交互模式需要去回答一個(gè)問題，即在不同的業(yè)務(wù)場景下，最佳的交互方案是如何的，這里面究竟有沒有規(guī)律可遵循？

　　軟件做出來的功能不是用戶想要的，則是我們?cè)诔龉δ苄孕枨蟮臅r(shí)候出現(xiàn)明顯的偏差。但是如何功能是不好用，則是我們沒有重視需求開發(fā)中的非功能性需求方面的描述，而關(guān)于軟件的性能，UI和交互，安全性，可靠性和健壯性等都是軟件的非功能性需求。很多時(shí)候軟件產(chǎn)品的失敗往往就是在非功能性需求上面。 

　　需求的描述上面需要盡量的結(jié)構(gòu)化和條目化，好的需求不僅僅是完整和正確，更加重要的是一定是可以驗(yàn)證的，因此不能出現(xiàn)任何類似易用，較快等模棱兩可的詞語。另外對(duì)于業(yè)務(wù)場景和到了系統(tǒng)用例的軟件需求之間，可能一個(gè)場景會(huì)對(duì)應(yīng)多個(gè)用例，也可能一個(gè)用例要實(shí)現(xiàn)多個(gè)業(yè)務(wù)場景，如何將業(yè)務(wù)場景體現(xiàn)到用例中去是必須要分析和解決的一個(gè)問題。同時(shí)體現(xiàn)了場景后，需求可以更好的指導(dǎo)測試用例的編寫，因?yàn)槲覀儗?duì)測試用例更加強(qiáng)調(diào)基于業(yè)務(wù)場景的測試。