【IT168 技術文章】

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

　　其次對于需求收集，分析和開發工作。我們仍然很強調業務場景這個詞，在UML 2.0專門有了業務建模的概念，包括業務用例，活動圖，狀態圖和業務組件和對象模型等幫助我們完成對業務場景的系統建模。然后我們往往很容易跳過這一塊而直接過渡到系統用例，而系統用例的重點已經會轉移到功能的實現上面。一個功能的實現沒有站在用戶角度去考慮不同的業務場景下，系統如何去更好的支持，導致出現大量的需求遺漏和易用性的問題。這也是易用性的一個較高層次，即業務易用性，是否進行了分角色和分場景的設計。 

　　在談UCD和交互設計的時候，這個時候談到了易用性的動態模型，我們原來談界面規范和配色等更多的是考慮系統的靜態易用性問題。在談交互設計的時候，則是要結合業務場景和業務角色，考慮系統的動態易用性問題，界面規范容易總結，但是交互規范和模式卻往往很難進行總結。簡單而言，交互模式需要去回答一個問題，即在不同的業務場景下，最佳的交互方案是如何的，這里面究竟有沒有規律可遵循？

　　軟件做出來的功能不是用戶想要的，則是我們在出功能性需求的時候出現明顯的偏差。但是如何功能是不好用，則是我們沒有重視需求開發中的非功能性需求方面的描述，而關于軟件的性能，UI和交互，安全性，可靠性和健壯性等都是軟件的非功能性需求。很多時候軟件產品的失敗往往就是在非功能性需求上面。 

　　需求的描述上面需要盡量的結構化和條目化，好的需求不僅僅是完整和正確，更加重要的是一定是可以驗證的，因此不能出現任何類似易用，較快等模棱兩可的詞語。另外對于業務場景和到了系統用例的軟件需求之間，可能一個場景會對應多個用例，也可能一個用例要實現多個業務場景，如何將業務場景體現到用例中去是必須要分析和解決的一個問題。同時體現了場景后，需求可以更好的指導測試用例的編寫，因為我們對測試用例更加強調基于業務場景的測試。