这几个要素都是和通信公司的商业利益直接相关的，没有牵涉到任何系统实现方式。如果不考虑通信公司内部的业务规范，实现方案可以有几十种，下面列举两种：
1：SIM卡发给营业员，用户入网的时候，选择一个号码，然后付钱。营业员把SIM卡号码和电话号码输入系统，在交换网络上进行注册，这个SIM卡就可以通话了。然后各种费用记入各人帐户，合同归档。
2：SIM卡在下发给营业员之前，先在交换网络上和注册，并且已经预先设置了一定的话费。用户选择了这个号码，付钱之后直接SIM卡拿走就可以打电话了。营业员事后再输入用户的合同资料，费用计入各人帐户，合同归档。
这两种方案在实现过程上是不同的，因此具有不同的功能点。比如第二种方案中的SIM卡在出售之前是可以进行通话的，所以必须对这样的号码的通话费用进行监控，这个功能在第一种方案中是根本不需要的。并且两种方案在帐目的核对方式上区别也是比较大的。这两种方案是不同的功能点的集合，他们完成的是同一个业务需求。
系统在开发阶段如果没有保留用户的业务需求情况，而是只留下一个功能点的列表，会给维护人员带来成很大的困难。维护人员无法从这样一堆功能点中发现最初的需求是什么样子。各位可以试试，假设我们忘记上面的四个需求要素，只看下面的某个实现方案，从这个复杂的实现过程中，我们很难知道用户现在的需求到底是什么。一旦需求发生了变化，这些功能点就会出错，或者是功能点的时序发生意料不到的错误，也许帐目核对不上了，也许是用户拿走的SIM卡不能打电话了。
看不见需求在哪里，不知道手里这段代码会触动需求的哪根神经。维护人员的痛苦大部分来源于此。
“不要紧，客户记得自己的需求。”但是客户通常不懂技术，即使他们懂技术，他们也不知道系统是如何实现的。如果开发人员依靠客户提出新需求的解决方案，结果就是让 软件工程变成“生物工程”。到最后是钱基本花光，人基本累死，甲乙双方感情基本破裂。
软件开发必须划分成几个过程，但是各个步骤应该有一个统一的核心——业务需求。
在需求调查阶段要搞清楚用户的业务需求，为了达到这个目的，可以提问回答，可以对用户进行跟踪采访，或者做一个demo给用户看看，最终的目的是为了搞清楚用户在做什么事，遇到了什么问题，程序应该去解决什么问题，这就是这一阶段的工作。
然后开始进行设计，设计系统的逻辑结构和物理结构，逻辑结构要符合需求的概念，各个对象互相调用要能够实现需求中的业务过程，同时物理结构划分合理，符合实际的分布状况，可以达到要求的的性能，业务过程的物理运行方式合理高效。这一阶段仍然是以业务需求为核心。
接下来是编码。首先是编写一些基础设施，比如 网络通信、数据库、文件的读写、 分布式计算，这些基础设施和业务需求没有什么关系，有很多现成的框架，借助这些框架我们可以尽快度过这个黑暗的阶段。然后编写业务对象，这时候业务需求中的一些概念逐步出现在代码中，比如上面说的那个例子，“用户”、“号码”、“合同”、“入网”、“SIM卡 资源”这样的业务要素逐渐出现，这些对象所拥有的属性、可以运行的行为也和现实的需求一样。接着这些业务对象串接起来，实现业务过程，现在业务需求又回到了人们的视野当中。业务需求是什么，如何实现，在这里一目了然。最后将这些过程在UI或者接口中调用，将功能提供给用户或者别的系统。
测试更是要围绕着业务需求来进行，正常的业务流程应该产生正常的结果，如果缺少某个资源，或者输入了不合适的数据，应该出现业务含义明确的异常。并且系统的业务对象是处在一个独立的层次上，与UI和基础设施没有很大的关联，这样可以方便的采用自动化的测试方法。
这样的系统维护起来一定少很多痛苦。
文章来源于领测软件测试网 https://www.ltesting.net/
