再談軟體需求分析和開發

關於軟體需求的一些基本內容可以參考
需求問答集1: http://blog.sina.com.cn/s/blog_493a845501008pu0.html
需求問答集2: http://blog.sina.com.cn/s/blog_493a845501008pyp.html

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

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

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

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

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

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/15027599/viewspace-551937/，如需轉載，請註明出處，否則將追究法律責任。