由项目的需求说开去
项目需求可以说是贯穿整个研发流程的核心。没有界定规范的需求自然也没有执行严格的研发过程。可惜我领悟的太晚，直到最近才意识到它对业务流程理解的重要性。
从android2.3的时代走到如今的4.0，通话业务的需求也随之有所变更。但单就通话业务以及其补充业务（supplementary service）的流程而言，本质上并无太多区别。
以单卡项目为例，在2.3时代里我关注的与通话相关的项目需求是：
通话基本功能
视频电话
联系人
呼叫保持、切换、密谈，多方通话等
拨号盘设置（联系人匹配，拨号前编辑，显示/隐藏等等）
通话录音
可发送拒绝短信
快速拨号
呼叫转移
固定拨号
语音信箱设置
呼叫等待
本机号码
主叫号码识别显示和主叫号码识别限制功能选项
自动重拨
IP拨号
等等。
到了4.0时代，项目需求文档罗列更加详细，但实际上有所区别的大多是运营商或新的项目需要提出的需求，比如说：
去电、来电归属地查询
电话黑名单/白名单
可见CS业务发展至今无论是需求还是实现都已经相当成熟，即使改动也只是小打小闹，很少伤筋动骨。
虽然项目罗列的很清楚，说明文档上也写得很明了，但实际操作起来就不是那么一回事了。举个简单的例子，当前的android智能机上都有快速拨号的功能，将虚拟键盘某个按键映射到对应的联系人上，则可以直接播出他的联系电话。
这个本来是非常清楚的项目需求。但是问题在于，如果我将某项业务写入联系人菜单，比如说*#06#，这个MMI码是获取手机IMEI号的功能。然后我将它保存为联系人并绑定到快捷键上，然后长按拨出……结果出错了，显示“出现连接问题或MMI码无效”。且慢，这个功能是不是有问题？然后客官你换了另外一个##002#，这个MMI码是用来消除当前的所有呼叫转移设置的SS业务的功能。绑定，拨出，同样的流程下来，你发现这个功能又好用了。
很奇怪吗？至少我当时面对测试报上来的bug是非常迷惑，项目需求中对于拨号盘快捷键拨号的需求写道：支持单键拨号，在拨号盘长按某数字键盘后拨出设置好的某个号码，长按1呼出语音信箱。那么为什么有的情况下好用有的却又不好用？
事实上，这个要从MMI码的分类来说了。MMI码全称ManMachine Interface，简单讲就是人机匹配接口，它可以接收人为发出的消息，并在显示屏上有一个对应的显示区域，当然也可以是别的什么东西。
对于手机而言，则可以把获取MMI的方式分成需要通过远端服务器设置完成的，以及本地即可以获取相关状态的两种情况。两者最明显的区别在于，前者是需要通过“拨号”动作完成MMI的发送，之后由网络侧回传的消息判定是否MMI消息成功。而后者只要在拨号盘上输入最后一个字符就能弹出对应的消息框来。
对于前者，大家可以在PhoneUtils.java中的placeCall()方法里看到对应的处理流程，当拨号过程建立后，Connection获取为空的情况下，android系统就认为是一个MMI码的拨出动作（稍显有点不负责任了），至于是不是有效的MMI码，则交给Service去处理。之前我们举得##002#就是这么一个有效的MMI码，用来做清空当前呼叫转移的设置。
而对于后者，在SpecialCharSequenceMgr.java中，有个叫handleChars()的方法，这个方法里把四类有效地本地获取MMI消息的动作都罗列了出来，分别是：
handleIMEIDisplay()—— 这个就是我们举的*#06#动作，获取系统IMEI号。
handlePinEntry()—— 这个是pin码的输入
handleAdnEntry()—— 这个是adn的输入
handleSecretCode()—— 这个有些复杂，并不单指某个特定码，一般来说一些查询系统状态的，以*#*# 或者 #### 开头的MMI码都属此列。
说到这，估计各位也都明白为什么快捷拨号拨不出去前一种MMI码的缘故了，因为这个压根就不需要拨号动作……。
但是对于需求文档和测试用例而言，需求条目并没有详细描述到这个层次。但也许也是我入行时间太短，这些对本领域的技术人员而言应该是约定俗成的知识点对我来说还是空白一片，毫无概念。然而在实际操作过程中，还是经常会看到因为需求不明晰，概念不明确，产生的这样或者那样的问题。
其实对于普通的研发人员来说，如果有一份详实的项目需求文档和操作规程，无论是对项目进程还是自我学习而言，都是一件不可多得的好资料。但大多数时候，文档并不会细致到自己所需要的程度，那么剩下的，就要靠个人的努力修行了。