需求工程师需要什么样的素质呢?
《软件需求》一书的作者 Karl E. Wiegers 在文章 “So You Want To Be a Requirements Analyst?” [1] 中列出了需求工程师的任务和素质要求,简要摘录如下。
Karl E. Wiegers 认为,需求工程师需要和系统的各种涉众沟通,成为他们之间的纽带。所以,需求工程师需要具备以下素质:

需求分析师负责沟通各种人
关于需求工程师的素质要求,Karl E. Wiegers列出了以下几点:
1. 倾听的能力。积极倾听包括排除干扰,保持专心的姿态和眼神接触,并重复要点来确认你己经理解。你需要抓住要点并从字里行间推断出对方犹犹豫豫没有说出来的东西。了解对方喜欢什么样的沟通方式,尽量避免把你的个人理解强加到客户身上。
2. 访问能力。大多数需求输入来自讨论,因此一名分析员必须能够询问正确的问题。例如,用户一般会把精力集中在正常的、符合期望的行为上,而每个程序员都知道需要大量代码来处理错误,可以问类似这样的问题“如果这样,会发生什么事情”或“会出现这样的问题吗?”Donald Gause和Gerald Weinberg在书中[2]描述了“context-free questions”的技术。
3. 分析能力。有在不同层次进行抽象的能力。有时你需要从高层往下钻到细节,有时需要从某个用户的特定需要泛化到适用于整个用户类别的需求集合。评价各种从不同来源收集到的素材,调和冲突,从用户的需要中分离出真正想要的,并把解决方案从需求分离。
4. 协调能力。涉众需要需求工程师作为中立的协调员,协调员需要强的提问和观察技巧,以帮助团体建立信任、改善业务人员和技术人员之间有时会出现的紧张关系。Ellen Gottesdiener的书[3]中提供了协调员的建议宝库。
5. 观察能力。在持续观察用户做工作或使用一个应用系统的时候,你可以推断到一些微妙的东西,这些东西可能在讨论的时候没有涉及。这样就揭示了新的需求领域。
6. 书写能力。你为顾客、营销人员、经理的主要交付物是书写好的规格说明。为了完成这个任务,你需要有坚实的(自然)语言能力。力争做到清楚,避免含糊词语和语法错误。
7. 组织能力。你会面对一大堆在启发和分析中得到的混乱信息,快速地把它们组织起来,把碎片拼成相关的整体。这需要高超的组织技巧,还有耐心和韧性。
8. 建模能力。从流程图到结构化分析模型(数据流图、实体关系图等)到UML标记,需求分析师的工具箱里应该有这些画图工具。在和用户交流的时候,一些这样的技巧是非常有用的,和开发人员的交流也一样。你会经常需要教育其他涉众这些技能的价值以及如何阅读它们。
9. 交际能力。你必须能够使有不同兴趣的人一起工作。你应能自如地和组织中不同级别的个体交谈不同的工作,你可能还需要和分布的团队交流,它的成员分布在不同的地点,时区、文化、语言都有区别。
10. 创新能力。分析师不只是一名抄写员,顾客说什么他就记什么。James Robertson[4]建议最好的分析师应提议需求,分析师可以构思创新的产品功能,设想新的市场和业务机会,想出能够使顾客震惊和高兴的好方法。一名真正有价值的分析师能发现创新方法来满足用户一直不知道自己已有的需要。
11. 领域知识。事先拥有一定的领域知识,才能使以上的能力 发挥出来。对于需求工程师,并没有标准的教育程序和工作叙述,他们大多数来自不同的背景。如果你从类似于系统用户这样的角色进入到需求分析角色,你需要在你丰富的业务知识和软件工程工作环境之间作出平衡,并学会和你的技术同事们沟通。如果你是从开发人员转换而来,你需要增强对业务的理解,随时提防滑进自己的技术陷阱中。
需求获取技术
Karl E. Wiegers还列出了一些搜集需求数据的方法:
• 访谈
• 需求工作组
• 文档分析
• 问卷调查
• 现场观察
• 业务流程分析
• 工作流和任务分析
• 列出外部事件以及相应的系统响应
• 竞争对手产品分析
• 逆向工程现有系统
• 回溯以前的项目
参考文献
[1] So You Want To Be a Requirements Analyst?, Software Development, July 2003
[2] Exploring Requirements: Quality Before Design, Dorset House, 1989
[3] Requirements by Collaboration: Workshops for Defining Needs, Addison-Wesley, 2002
[4] Eureka! Why Analysts Should Invent Requirements, IEEE Software, July/Aug. 2002

实事要做,blog也要多写!哈哈
时间精力有限啊。也需要不断学习提高。尽量把握个平衡吧 呵呵
为什么没有开发经验?
– ”11. 领域知识“ 也许可以部分解答你的疑问。我也是查了很多资料综合考虑后决定不做开发,直接做需求。
– LinkedIn上也是有这方面的讨论,有人认为分偏业务型和偏技术型,或者两者兼有。
– 有人主张确定需求时最好同时有业务专家和技术专家。
– 我的感触是,不管哪种类型,首先必须是业务专家。有技术背景更好了(只要不陷入技术陷阱),或者至少了解实现原理,逻辑清晰严谨,这样不容易提出不切实际或者不合逻辑的需求。