软件需求分析师

软件需求分析师：

1、根据概要需求（客户及内部需求）编写详细需求规格说明书；

2、系统规划，与产品人员进行前期调研和产品设计工作，编写调研报告和项目解决方案；

3、参与系统功能验收工作及用户手册、新增产品功能培训资料的编写；

4、负责客户(及内部)需求调研及需求反馈的分析；

5、配合测试人员编写测试计划、测试用例、测试报告的编写、问题缺陷的发现及跟踪、产品用户手册编写等；

任职要求：

1、年龄：26—35，本科以上学历，3年以上工作经验，其中2年以上软件需求分析经验，成功参与过大型产品项目的需求分析工作；有2年以上大型互联网网站需求分析经验者优先；有开发经验者优先；

2、熟悉需求调研方法，较强的业务流程及业务模型分析设计能力；善于控制需求，进行版本范围及项目范围管理；丰富的客户（及内部）沟通经验，能快速把握需求的核心要点；

3、熟悉软件工程理论，掌握软件需求获取与分析方法，至少熟悉一种开发语言和一种数据库。

4、有较强的文档编写能力；熟悉CMM文档规范者优先；

5、良好的英语读写水平，有独立查阅英文专业资料的能力；

6、需有较强的团队协作精神。有效的沟通技巧，在团队协作中具有精炼思维和解决复杂问题的能力，具备良好的学习能力，责任心强，能够承受较大的工作压力；

岗位描述1. 与客户沟通，确定需求边界。能根据客户的表述进行需求文档的编写和需求的拆分。

2. 配合公司市场人员获取需求。

3. 进行需求可行性研究。

4. 参与需求调研和产品定义评估，业务需求讨论与设计

5. 根据产品定义实现详细需求分析文档、用户手册编写并协助解决测试问题

6. 参与整个产品开发流程，与开发测试团队一起保证最终产品发版。

岗位要求1）计算机，软件工程等相关专业，本科以上学历；

2）具有2年以上软件项目分析经验；参与过项目（或产品）的规划设计、需求分析工作；3）较强的用户需求判断、引导、控制能力；优秀的文字表达、业务理解、交流能力；

4）团队合作精神。

第1章前言

目的

需求调研是为需要说明书做前期工作，可以说需要说明书说是从需求调研表中得到或抽取而出。

需求调研是要了解现实世界中做实际工作的人们真正需要什么样的程序的过程，再把这些需求开进细节整理由设计部开发，再由销售部销售给用户。

用户：系统分析人员

回页首

第2章前期准备

2.1. 确定工具

?没有什么工具是好还是坏的问题，问题是关键是如何使用它们，无论是什么工具也只是一个辅助工具，也不是生成工具。

?工具的选取要求是自己（本组）熟悉的工具，不能是一件最新时髦工具而自己对它了解很少，结果大部分时间化在学习工具上，而不是使用它为你工作。

?工具最好也是要求是普通流行的，因为要考虑交流的问题。

2.2. 要做什么就要先了解什么

?如果做的项目是你所不了解的一个行业（专业）同组有要最好有要专家----最终用户做为这个专家是最好的，最少你有了解这个专业，不是要你成为专家，但最少要了解一定的专业知识（最少专来词汇你要知道），不然您甚至不知道去问什么问题或者如何去问他们，甚至于人家在说什么你也不知道。

?相应的专业资料是必须的，最少要有专业入门书籍和对应的资料，也需要求更深入的一些资料。

当然有专家的参入就另当别论。

?如果行业的难度不是很大，可以通入分析人员的自我学习在短时间内了解行业，也许可以不用专家，否则专家是必须的。

2.3. 建立设计环境

一定建立一个专门的设计环境来为本项目服务，进行一定的资源分配，进行必要的文件管理。

2.4. 真正了解自己和用户

?那些是用户可能明确要达到的目地

?要知道那些是自己能做到的，那些是自己不能做的。

?对于不能做的处理方法，如拒绝，转包等

?那些是用户想要做到的

2.5. 列出人员分配表和所有工具列表

?明确项目人员分工

?统一项目所用的工具

?统一项目文件模版

?其它资源列表（资料，相关网站，资询电话。。。）

回页首

第3章调研过程

3.1. 搜集需求得到需求说明书

注意：

1.虽然最终必须要编成基于计算机解决方案的描述，但到目前为止，我们关注的焦点的文档在相应

领域方面的部分。

2.记住这里没有计算机方面的行话，如果是编写一个会计软件，那么一位会计师都应该清楚地理解

程序员写的会计方面的问题说明书

3.需求说明书问题中，不要太正式。只要描述能表达您想要做的事情就行了，就和另外一个人在说

话一样就可以。

4.对于客户或相应人员了解问题时，一定要有记笔记的习惯，谈上几个小时，很多细节是记不住的。

3.2. 整理，检查和细化需求说明书

1.对于客户的需要进行必要的整理和分类有进从用户那里会得到很多信息，不行进必要的整理就不

能从中进行合理的分析

2.分清有用功能、可选功能用、无用功能及不可实现功能对于用户来讲他可以说出他想要的很多功

能，但这些功能间的关系有时是清晰的，但对于很多用户来讲想通过计算机或新系统实现他以前

没有的功能，在这时他所提出的新需求的可行性和与其它模块之间的关系就已经不清，所以对于

分析员来讲，要从用户的需求中分清有用功能和无用功能和可选功能，进行分别区分处理，比如

不可实现功能请用户放弃。

3.不要忽略明显的错误用户倒是不经常提及他需要的东西，而这些东西对问题来说都是很基本的，

要细化检查一定有注意这个问题。

4.你认为的也许不是对的对于系统分析员对需求分析的自认为的情况要加以注意，对于一个行业来

说，有些规则可以不是最合理，但它就是那样存在和使用，所以对于每一个非明确确定的需求，

要由专业人员来审定。除非你就是专家。

3.3. 改进

最初的第一次需求在分析，细化一定有不明及不确定之处，那么就把整理出一份问题细化问询表，对发现的问题进行整理，列出不明之处，可根椐以下格式

问询人：

问题：

业务不清问题列表（业务描述不清）：

1 ….是什么含义？

2 …..与XX是什么关系？

多种选择可以列表（请用户进行选择）：

1 ……有多个可能，那么现在我们使用

A …… B……. C…….. D ……

3.4. 审核需求

1.自我审枋

把自己从用户的角度来考虑

是否合理，是否可以提高效率，是否可以达到目的，是否有完整

2.由用户来评价

由最终用户来评价你所列的需求是否达到了用户要求（用户人数1-3人，再多也没有什么益处）。

3.重复过程，最终通过审核完成需求说明书

参考资料

标准版API 规范，JAVA 2 核心技术和其他方面的信息。