（一）需求–开发–测试关系
现公司很多需求在产品提出后，是否完善是个问题，在实际工作中，发现测试测试功能要从开发处问得需求，开发在开发的过程当中要承担很大的需求任务，当然开发确实要思考需求，但这不妨碍产品提出更完善的需求。建议如下：
软件工程中对需求的是否合格的标准是是否可测试
***需求完成后，测试使用需求文档生成测试用例用于测试，需求文档告诉测试测什么，开发告诉测试怎么测。
***测试不仅仅是测试程序是否正确，同时也对对需求的完备性进行测试。
注：敏捷开发中开发兼职需求，但需求依然是完备的。
（二）需求调研经验
1. 大领导，弄清系统的价值。以及协调相关调研工作。
成果：系统目标，用例图。
2. 系统用户的调研。弄清它们平时怎么做相关业务，以及一些表单。
成果：业务流程，领域模型模型。开始做页面原型
3. 结出页面原型，用户提出问题，进行修改，直至用户满意，进行需求迭代。
成果：不断变更的原型，更加丰富的领域模型和更加完善的业务流程。
4. 形成正式需求文档，进行需求评审。
周期一：理清框架和脉络,用例图，活动图，实体关系图。
周期二：确定需求细节 以原型为主
调研过程 听–问 –确认 索取相关资料
原型讲解，语言和材料为一体。
注：需求要可实现、可测试
（三）需求变更调研经验
调研前准备：客户要变更相关功能的业务，不能在调研时还不了解业务，听不懂客户在说什么。如果知道用户大概要变的方面，要在了解业务的基础上思考客户可能的变更及变更的风险。
调研过程：
1. 倾听客户变更的原因，变更内容，变更目的。
2. 对倾听中的问题进行询问，直到达到真正了解了以上三点。
3.询问客户有没有相关的电子或纸质资料。也可以放在2中来进行，但2中会比较零散。完了2要自己再问一下，还有没有其它的资料。
4. 对客户的想法进行总结，确认，如果问题会涉及计算机的解决方案会和客户提的有不匹配或会改变用户业务习惯或流程的，要用客户能听懂的语言给出解决方案，和客户一起探讨这个方案可不可以满足客户的要求。
5. 回来后要对变更做一个变更调研的文件，发与相关人员进行确认（包括开发方及客户的相关人）
（四）项目管理
不能只对事，还是要考虑对方的想法，人和事还是不一样的。回想自己当项目经理时，现在又站在程序页的角度，确实好多事会有不同的看法。事和人确实是分不开的。
上对下：任何任务都要有一个唯一的负责人
唯一负责人的第一要务就是要让参与人员达到共识
下去上：要让领导放心。有规划做好事情，汇 应该汇 的（处理过后的结果）。
（五）文档及表述
模糊词汇及歧义:
如果是技术性的描述，不能出现系统，对象，它等泛指词，要说清楚是什么系统，什么对象，如果要描述的涉及几个系统，那么就很有必要在描述前说明几个系统的名称代指和系统边界，这样在以后的描述中才不会和听者或者读者产生歧义。
如老婆描述：系统延迟两秒进行录制 /span>系统中哪个系统行录制是调用其它系统还是自己系统做迟两秒是延迟两秒调用录制还是录制的时候延迟。….很多疑问，如果现在往后说，怎么可能听懂，说的都是未知或疑惑的。
正确的表达方式：
本程序做为录制系统的一个jar包发布，是录制系统的一部分，下面用本程序和录制系统来定义自己开发的功能和录制系统的其它功能接口。本程序延迟两秒进行调用录制系统的接口进行录制。
表述中用到的专业术语要有解释，文档不可以跳跃，不可以出现模糊词汇（如系统，对象，这个，它，他等）和未经解释的术语，除非可以通过上下文可以明确知晓（就算可明确知晓用精确的词会比泛指的好）。要涵盖所有的可能脉络，不能有的脉络不说或说一半，脉络描述可以总分，也可以分总，但不能一会总一会分，让阅读的人很难理解。
相关资源：RoomArranger(房间布置软件)v7.2中文版.rar-其它代码类资源-CSDN…
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！