這幾個要素都是和通信公司的商業利益直接相關的，沒有牽涉到任何系統實現方式。如果不考慮通信公司內部的業務規范，實現方案可以有幾十種，下面列舉兩種：
1：SIM卡發給營業員，用戶入網的時候，選擇一個號碼，然后付錢。營業員把SIM卡號碼和電話號碼輸入系統，在交換網絡上進行注冊，這個SIM卡就可以通話了。然后各種費用記入各人帳戶，合同歸檔。
2：SIM卡在下發給營業員之前，先在交換網絡上和注冊，并且已經預先設置了一定的話費。用戶選擇了這個號碼，付錢之后直接SIM卡拿走就可以打電話了。營業員事后再輸入用戶的合同資料，費用計入各人帳戶，合同歸檔。
這兩種方案在實現過程上是不同的，因此具有不同的功能點。比如第二種方案中的SIM卡在出售之前是可以進行通話的，所以必須對這樣的號碼的通話費用進行監控，這個功能在第一種方案中是根本不需要的。并且兩種方案在帳目的核對方式上區別也是比較大的。這兩種方案是不同的功能點的集合，他們完成的是同一個業務需求。
系統在開發階段如果沒有保留用戶的業務需求情況，而是只留下一個功能點的列表，會給維護人員帶來成很大的困難。維護人員無法從這樣一堆功能點中發現最初的需求是什么樣子。各位可以試試，假設我們忘記上面的四個需求要素，只看下面的某個實現方案，從這個復雜的實現過程中，我們很難知道用戶現在的需求到底是什么。一旦需求發生了變化，這些功能點就會出錯，或者是功能點的時序發生意料不到的錯誤，也許帳目核對不上了，也許是用戶拿走的SIM卡不能打電話了。
看不見需求在哪里，不知道手里這段代碼會觸動需求的哪根神經。維護人員的痛苦大部分來源于此。
“不要緊，客戶記得自己的需求�！钡强蛻敉ǔ２欢夹g，即使他們懂技術，他們也不知道系統是如何實現的。如果開發人員依靠客戶提出新需求的解決方案，結果就是讓 軟件工程變成“生物工程”。到最后是錢基本花光，人基本累死，甲乙雙方感情基本破裂。
軟件開發必須劃分成幾個過程，但是各個步驟應該有一個統一的核心——業務需求。
在需求調查階段要搞清楚用戶的業務需求，為了達到這個目的，可以提問回答，可以對用戶進行跟蹤采訪，或者做一個demo給用戶看看，最終的目的是為了搞清楚用戶在做什么事，遇到了什么問題，程序應該去解決什么問題，這就是這一階段的工作。
然后開始進行設計，設計系統的邏輯結構和物理結構，邏輯結構要符合需求的概念，各個對象互相調用要能夠實現需求中的業務過程，同時物理結構劃分合理，符合實際的分布狀況，可以達到要求的的性能，業務過程的物理運行方式合理高效。這一階段仍然是以業務需求為核心。
接下來是編碼。首先是編寫一些基礎設施，比如 網絡通信、數據庫、文件的讀寫、 分布式計算，這些基礎設施和業務需求沒有什么關系，有很多現成的框架，借助這些框架我們可以盡快度過這個黑暗的階段。然后編寫業務對象，這時候業務需求中的一些概念逐步出現在代碼中，比如上面說的那個例子，“用戶”、“號碼”、“合同”、“入網”、“SIM卡 資源”這樣的業務要素逐漸出現，這些對象所擁有的屬性、可以運行的行為也和現實的需求一樣。接著這些業務對象串接起來，實現業務過程，現在業務需求又回到了人們的視野當中。業務需求是什么，如何實現，在這里一目了然。最后將這些過程在UI或者接口中調用，將功能提供給用戶或者別的系統。
測試更是要圍繞著業務需求來進行，正常的業務流程應該產生正常的結果，如果缺少某個資源，或者輸入了不合適的數據，應該出現業務含義明確的異常。并且系統的業務對象是處在一個獨立的層次上，與UI和基礎設施沒有很大的關聯，這樣可以方便的采用自動化的測試方法。
這樣的系統維護起來一定少很多痛苦。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
