一、 了解你的团队和其他风险承担者

　　系统需求工程师不单纯是一个技术工作者，也应该是个很好的交际者。老外的书籍我并没有看到过多关于“需求获取中人际交往”的论述，大多是轻描谈写，但是在中国却要把这个放在首位。我亲眼见过甲方和乙方因为纯个人性格问题导致需求会开得很紧张的场面。我们能对这种现象避而不谈吗?我曾经说过，在中国获取需求好的地方是在饭桌上，这种观点老外会觉得不可思议。因此，不管是在需求获取、分析还是管理整个过程中，系统需求工程师不能忽视与人打交道的过程，应该分析每个人的优点缺点，有的放矢，为了获取终的需求有时要讲究策略和战术。在这个看似简单的问题亦或是管理心理学的问题上恐怕我们这些习惯于搞技术的人需要学习一辈子。能让大部分人在整个系统需求获取和管理中都能和平相处也是系统需求工程师一项责任。

　　二、 学习即待开发系统的全部业务，了解得越深越好

　　通常情况下，系统需求工程师可能对待开发系统根本一点都不了解，隔行如隔山，熟悉目标单位的具体业务是较大的考验，这也要求系统需求工程师善于学习。不仅仅是学习具体业务，还要学习行业业务，因为客户代表提出的需求不一定是整个行业中科学的合理的需求，如果系统需求工程师能控制需求导向往正确合理的方向发展，其好处是多方面的，既有助于是客户得到好的业务需求又有利于软件复用。

　　三、 获得所有需求的模型和关联图

　　通过需求收集获得的大多是口头上或是文字表述的需求，这种需求映射到系统开发上是有偏差的，口头上表达很容易的一项需求让计算机实现有时会变得非常复杂。因此建立各种模型尤为重要，这种模型可能是由专业的需求分析员来做。同样一个设计项目，两个人做出来的可能完全不一样，因为需求分析员对需求的理解可能不一样。系统需求工程师应该有责任把好关，细微的差别是允许的，但决不能偏离初需求的含义。

　　四、 获得接口原型和数据字典

　　往往在获取需求是客户代表说这需要一个接口，需要使用其他系统的某些数据。但如何实施，有没有政策法规和技术的壁垒呢，所以系统需求工程师不能把问题想得过于简单。接口两头的系统经常是黑盒与黑盒的关系，事先必须设计接口原型，有条件的情况下需要进行测试，这些工作应该在设计之前做。数据字典是人类和计算机模型之间的桥梁和纽带，也是所有风险承担者理解这个系统的统一规约，系统需求工程师在深入学习这些表述的同时有义务让所有参与者明白一些重点词汇、字段的含义。

　　五、 时刻不忘需求的优先级和可行性分析论证

　　主次不分是大忌，开发任何一个项目都有重点和非重点，把力量向重点倾斜会取得令人满意的结果，如果不分主次地盲目开发，设计者费了九牛二虎之力做出来的东西后发现根本不是主要的。如果在需求分析阶段非常注意把需求分成等级，哪些是整个系统的核心，哪些是次要的或者不影响整个业务流程的，这对随后的开发有着重要的意义。

　　六、 发现错误和遗漏立刻改正

　　作为系统需求工程师不能过于乐观，要知道需求分析员和其他风险承担者不是每个人都认真仔细阅读和分析你的所有文档。事实上大多数情况下他们不会承担“没有宏观把握需求”这个责任，因此系统需求工程师有责任也有必要从大局着手来发现宏观架构和细枝末节的错误，可以召集出一个团队对设计好的全部“蓝图”召开几次纠错会，好此时把程序设计者和客户代表也请过来。大家一起发现错误和遗漏的同时，也在达成一个潜在的共识，同时还加深了所有参与者对该项目的认识理解程度。我见过因为一个小小的错误导致整个系统流转出现问题的实例，其实这些错误完全可以在设计之初解决。

　　七、 抓住亮点和突破口

　　不管你如何强调项目需求的主次，其他风险承担者可能与你的看法会有出入。你可能是站在宏观的角度看问题，而他可能站在具体业务的角度看问题。所以还有一个系统需求工程师需要掌握的信息，那是客户代表或者使用者关心的那些主题，我们可以称之为亮点和突破口，在他们看来，这个亮点和突破口做好了他们很满意，因为他们并不关心这个系统架构设计得如何严谨漂亮。如果我写项目需求说明书我会把这个单独写一个文档，当然这些在RUP中是找不到相应模板的。

　　总之，好的需求获取是好的需求分析的基石，而需求分析过程中，如何使风险承担者目标一致，论证、提炼已收集到的需求，查找错误、不足或遗漏是分析过程中的核心目标。整个过程系统需求工程师需要付出巨大心血，俯视这个系统时你会发现这种付出是值得的。