YGR一个人
软件开发项目需求调研怎么做
第一步：1：找全项目主要干系人，了解他们的想法.2：可用用多种方法进行调研，如问卷调查/头脑风暴/原型法/会议等.3：做好需求确认.第二步：做好调研表格，如下格式第三步：市场调查工作必须有计划、有步骤地进行，以防止调查的盲目性。
一般说来，市场 调查可分为四个阶段：调查前的准备阶段、正式调查阶段、综合分析资料阶段和提出调查报告阶段。
1：调查前的准备阶段。
2：正式调查阶段。
市场调查的内容和方法很多，因企业和情况而异。
3：综合分析整理资料阶段。
当统计分析研究和现场直接调查完成后，市场调查人员拥有 大量的一手资料。
对这些资料首先要编辑，选取一切有关的、重要的资料，剔除没有 参考价值的资料。
需求调研的几种错误观点
1）快速原型法，可以替代需求 软件工程项目中，经常会遇到这样一种尴尬的局面，我们调研完需求，做完设计，代码也编写的差不多了，这时请客户过来一看，客户却惊奇地发现这根本不是他们想要的东西。
为了让客户更早更快的对将要建成的软件系统，有直观和感性的认识，我们便建立一个系统原型，用于给客户做演示。
客户在我们演示和讲解的时候，马上就可以发现问题，而我们甚至可以现场修改原型，直到客户满意为止。
从理论上说，快速原型法确实几乎没有任何问题。
但实际情况并非如此。
第一点，也是最重要的一点，快速原型法无法解决需求主线的问题。
关于需求主线前文已经讲得很多，而调研需求主线的禁忌中，就特别提到不可以上来就做原型。
说直接点，你是做了某个模块或功能的原型，而且这部分原型也得到了客户的认可，但项目中真的需要这个模块或功能吗？另外更可怕的一点，当你宣告整个项目的原型已经制作完毕，并且全面得到了用户的认可，而那些必须有的需求主线，真的全部包括进来了吗？ 第二点，快速原型法背后还隐含了一个假设，客户就有极高的计算机素养，非常清楚自己需要什么样的系统，他的认可就标志着原型已经合理且完善。
但现实中，绝大多数情况下，这种假设是不成立的。
我们知道，客户方的角色实际至少可以分为两个部分：项目发起人与项目负责人。
发起人多数是职能部门，而负责人是IT部门。
你能指望职能部门的最终使用者，能有多大的概率说清楚自己到底想要什么。
第三点，再好的原型，它的层次感也要弱于建筑行业的沙盘或效果图，这使得原型演示不可能完美的表达软件系统建成后的效果。
以大楼建设为例。
我们可以用幻灯片或沙盘的方式，首先展示建筑的外部环境、外观设计。
然后再进入到某一层的楼层布局设计图，在进入到该楼层某个房间的布局设计图。
这些甚至可以用3D的方法演示出来。
再配合讲解，就能够使客户非常清晰全面的了解到整个设计。
我们知道，一个大型软件系统，可能包含几十个大模块、上百个小模块，成百上千的界面，而涉及到按钮、功能键、数据输入和显示等细节甚至多达数万个。
这样庞大的软件系统，要去演示它的软件原型，我们就只能在屏幕上，演示一个又一个的界面，根本无法遵行从整体到局部再到细节这样一个流程来展示。
这样的一种情况，相当于在建筑行业中，客户要求你盖一栋商业、办公综合性大楼，而你给客户演示的幻灯片，却只是一大堆的房间、厨房、卫生间、甚至于类似排气扇、开关之类非常细枝末节的东西。
又如何让客户提意见，客户又从何提起？只见树木，不见森林，说的就是这个意思。
在快速原型法相关知识普及率如此之高的情况下，软件项目失败率依然居高不下，其最根本原因，就在于此。
在笔者看来，只有当需求分析已经细化到具体某个界面的时候，快速原型法的好处才能真正体现出来。
而在此之前的仅仅只能用于确定界面布局，以及界面风格。
否则将不会对项目有多少帮助。
2）迭代次数越多，越能贴近用户需求 曾经有一次到一个朋友公司去谈事情，到朋友的办公室的时候，恰好有一个项目经理正在汇报项目进度。
朋友知道我也是做软件工程管理的，就让项目经理继续汇报。
当时项目经理说的有一件事情记忆特别深刻：“现在的原型和设计已经进行到第5次迭代……”。
似乎迭代次数越多，就代表项目越能取得成功。
完成一个软件项目，特别是大型的软件项目，总是需要很长的时间，为了避免在项目已经进行到尾声的时候，才发现原来和用户的要求有很大的差别，于是产生了迭代法。
迭代的方式如下，假如这个项目要求6个月交货，我在第一个月就会拿出一个产品来，当然，这样会很不完善，会有很多功能还没有添加进去，bug很多，还不稳定，但客户看了以后，会提出更详细的修改意见，这样就知道自己距离客户的需求有多远。
回家以后，再花一个月，在上个月所作的需求分析、框架设计、代码、测试等等的基础上，进一步改进，又拿出一个更完善的产品来，给客户看，让他们提意见。
就这样，我的产品在功能上、质量上都能够逐渐逼近客户的要求，不会出现我花了大量心血后，直到最后发布之时才发现根本不是客户要的东西的情况。
对比快速原型法和迭代法，就可以发现它们所需要解决的核心问题是一样的，那就是如何应对和适用客户需求在项目实施过程中的变化。
实际上快速原型法中就包含了迭代的意思。
它的目标是争取在设计、编码开始前，将客户的需求稳定下来。
而迭代法则走得更远，它发现在客户需求变化几乎贯穿了软件工程项目的整个过程，而不仅仅是在需求调研过程之中。
于是迭代法就包含设计迭代、代码迭代、测试迭代。
但迭代法的同快速原型法一样，它重点仍然是着眼于如何应付需求的变化上，只是把变化扩展为整个开发过程。
也因此，迭代法仍然无法摆脱上述快速原型法中，讲到的只见树木不见森林缺陷。
3）敏捷开发和极限编程，可以应付需求变动 敏捷开发这个词很好很形象。
它使我仿佛看见一幅场景：两个人正在做游戏，一个人不停的丢出鸡蛋，而另一个人则敏捷地接下所有的鸡蛋，避免它掉在地...
软件实施面试时需要知道什么
主要是熟悉软件实施的相关工作技能和流程。
相关技能包括：1、系统环境搭建的公共技能包括：A、安装操作系统，特别是掌握了linux,aix等更好；B、安装数据库，包括DB2 , ORACLE , SQL SERVER , MYSQL等；如果能对数据库进行性能优化更好。
C、安装中间件；现在的系统基本都是BS模式，因此需要依托中间件。
主流为TOMCAT,WEBSPHERE 和 WEBLOGIC等。
2、需求调研的方式方法；实施人员很重要的工作就是需要调研客户现场的需求，并形成对应的用户需求手册等稳定。
最好掌握相关的文档编写方法。
3、客户培训的方式方法；实施人员必须要培训客户使用软件。
通常会使用PPT的方式实现。
4、项目实施进度的推进和管理；实施人员还需要对项目的进度进行管理，并推进现场的工作开展。
特别是协调需要客户配合的工作。
5、较好的交流沟通能力；要能客户保持好关系，避免一些不必要的阻力。
软件行业 去现场交流需求和去现场实施更新部署程序分别有哪些需要注...
车间管理模式确立后，及时进行更新、完善，对软包装企业提高生产效率、降低生产成本、提升企业竞争力，无疑将大有裨益 对于一般中小型企业来说，现场的车间生产管理有着产品结构复杂，生产周期长，品种多，数量少等特点。
这些特点对企业的生产三个关键要素 “工期、成本、质量”提出了更高的管理要求。
是一个企业发展的心脏，也是管理者最头痛的问题。
然而，大多数企业仅仅停留在纸面文件和质量体系证书方面，ISO质量体系几乎90%以上的制造企业都难执行、难持久。
员工培训固然重要，但是，大多情况下都是培训时热情洋溢，培训后依然如故；不断高薪挖人、换人，来的人不是水土不服，就是孤掌难鸣，大多数最后的结果就是企业白白花了十几万、甚至几十万的工资，企业最终还是老样子，天天救火，天天开会，重复问题就是得不到根治，管理水平几乎永远原地踏步。
大家一直都在思考着以下几个问题：1：生产，使用了大量的调度统计人员为什么还是不能按时交货？ 2：组装，为什么总是缺件？为什么不能提前预知？3：采购，能不能保证实际生产需要？关键件能否按时到货？4：库存，为什么仓库里有那么多物料，到底哪些是真正能用到的？4：成本，我们挣钱吗？如何降低成本？有...车间管理模式确立后，及时进行更新、完善，对软包装企业提高生产效率、降低生产成本、提升企业竞争力，无疑将大有裨益 对于一般中小型企业来说，现场的车间生产管理有着产品结构复杂，生产周期长，品种多，数量少等特点。
这些特点对企业的生产三个关键要素 “工期、成本、质量”提出了更高的管理要求。
是一个企业发展的心脏，也是管理者最头痛的问题。
然而，大多数企业仅仅停留在纸面文件和质量体系证书方面，ISO质量体系几乎90%以上的制造企业都难执行、难持久。
员工培训固然重要，但是，大多情况下都是培训时热情洋溢，培训后依然如故；不断高薪挖人、换人，来的人不是水土不服，就是孤掌难鸣，大多数最后的结果就是企业白白花了十几万、甚至几十万的工资，企业最终还是老样子，天天救火，天天开会，重复问题就是得不到根治，管理水平几乎永远原地踏步。
大家一直都在思考着以下几个问题：1：生产，使用了大量的调度统计人员为什么还是不能按时交货？ 2：组装，为什么总是缺件？为什么不能提前预知？3：采购，能不能保证实际生产需要？关键件能否按时到货？4：库存，为什么仓库里有那么多物料，到底哪些是真正能用到的？4：成本，我们挣钱吗？如何降低成本？有多少呆料在占据着我们的资金周转？当前单纯依靠人力成本来管理企业的情况已失去了竞争优势，在没有高附加值和独特的技术优势越来越难以在当前残酷的经济环境中生存的大背景下，信息化管理模式正在被越来越多的自动化设备制造企业中采纳。
海宝软件的核心团队成员，经过十几年的摸索和实践，开发出了一套实用、易用的制造企业现场车间管理软件，并在国内上百家机械企业中已成功运用。
海宝软件现场车间管理系统，主要解决生产企业，各车间、各工序之间的工件转序，实际生产进度、完成数量和人员业绩统计、查询和控制管理方面的问题。
1 生产计划管理：下达生产计划或订单的产品数量、完成日期，并设置计划取消、暂停、完成等状态。
2 批次任务运算：系统自动算出所下达的生产计划各车间的“工序任务清单”。
3 生产实绩录入：可录入各工序实际生产的完成数、合格数、不良数等数据。
支持条码方式。
4 工序转序录入：录入各车间、各工序之间的半成品转序数据，可打印转序单。
支持条码方式。
5生产统计查询：系统可实时统计：生产计划和各工序及各人员的完成数量、合格品数量、不良品数量；6产品在制品工序结存数量；以各种查询条件实时查询生产日报表；7 工序数据报警：如果各工序提交的数据对不上，系统会对有异常的生产计划及工序列出报警清单。
8 员工业绩统计：自动计算员工在某一时间段内的生产业绩，是计件制企业发放员工工资，奖金的依据，也可作为员工晋升的参考。
9.设备负荷统计：可动态实时查询各设备类型的设备负荷率和嫁动率及对比柱状图和趋势图。
10加工工时统计：可查看实际加工工时和预估加工工时的对比表，以便分析差异，不断提高预估工时的准确度。
11零件加工跟踪：可实时动态查询某个任务号，所有加工零件、各工序任务的加工进度完成信息及检验信息。
查询后显示的方式有：表格方式、图形方式、列表方式三种。
也可查询所有设备类型及设备正在安排的加工任务甘特图计划，和查询所有任务号的所有零件的加工设备计划安排甘特图计划。
车间生产管理系统只是海宝软件制造型生产管理系统的一个子系统。
企业应用一段时间后，可以根据管理需求，无缝升级其它模块功能（如销售，采购，质量，外协，仓库，财务等）。
无锡海宝软件依靠领先的技术、丰富的产品线、强大的咨询实施队伍、优秀的近距离化服务及规模化交付能力，海宝软件的产品、解决方案在制造业得到了广泛的应用。
我们依托强大的咨询实施队伍、优秀的海宝品牌产品，致力于服务苏州地区的企业信息化系统，为企业提供从调研、...
应用软件是怎样设计的？
软件系统的开发是按阶段进行的，一般划分为以下阶段：可行性讨论；需求分析；系统设计（概要设计、详细设计）；程序开发；编码，单元测试；系统测试；系统维护。
软件开发过程中要明确各阶段的工作目标、实现该目标所必需的工作内容以及达到的标准。
只有在上一个阶段的工作完成后，才能开始下一阶段的工作。
1.可行性讨论 明确系统的目的、功能和要求，了解目前所具备的开发环境和条件，论证的内容有：① 在技术能力上是否可以支持；② 在经济上效益如何；③ 在法律上是否符合要求；④ 与部门、企业的经营和发展是否吻合；⑤ 系统投入运行后的维护有无保障。
可行性讨论的目的是判定软件系统的开发有无价值。
分析和讨论的内容形成“系统开发计划书”，主要内容有： （1） 开发的目的及所期待的效果； （2） 系统的基本设想，涉及的业务对象和范围； （3） 开发进度表，开发组织结构； （4） 开发、运行的费用； （5） 预期的系统效益； （6） 开发过程中可能遇到的问题及注意事项。
2、系统需求分析 系统需求分析是软件系统开发中最重要的一个阶段，直接决定着系统的开发质量和成败，必须明确用户的要求和应用现场环境的特点，了解系统应具有哪些功能、数据的流程和数据之间的联系。
需求分析应有用户参加，到使用现场进行调研学习，软件设计人员应虚心向技术人员和使用人员请教，共同讨论解决需求问题的方法，对调查结果进行分析，明确问题的所在。
需求分析的内容编写成“系统需求分析报告”。
3.系统设计 可根据系统的规模分成概要设计和详细设计两个阶段。
概要设计包括：① 划分系统模块；② 每个模块的功能确定；③ 用户使用界面概要设计；④ 输入输出数据的概要设计；⑤ 报表概要设计；⑥ 数据之间的联系、流程分析；⑦ 文件和数据库表的逻辑设计；⑧ 硬件、软件开发平台的确定；⑨ 有规律数据的规范化及数据惟一性要求。
系统的详细设计是对系统的概要设计进一步具体化，其主要工作有：① 文件和数据库的物理设计；② 输入输出记录的方案设计；③ 对各子系统的处理方式和处理内容进行细化设计；④ 编制程序设计任务书。
程序说明书通常包括程序规范、功能说明、程序结构图，通常用HPIPO(Hierarchy Plus Input Process Output)图描述。
4、程序开发 根据程序设计任务书的要求，用计算机算法语言实现解题的步骤，主要工作包括：① 模块的理解和进一步划分；② 以模块为单位的逻辑设计，也就是模块内的流程图的编制；③ 编写代码，用程序设计语言编制程序；④ 进行模块内功能的测试、单元测试。
程序质量的要求包括：① 满足要求的确切功能；② 处理效率高；③ 操作方便，用户界面友好；④ 程序代码的可读性好，函数、变量标识符合规范；⑤ 扩充性、维护性好。
降低程序的复杂性也是十分重要的。
系统的复杂性由模块间的接口数来衡量，一般地讲，n个模块的接口数的最大值为n(n-1)/2；若是层次结构，n个模块的接口数的最小值为n-1。
为使复杂性最小，对模块的划分设计常常采用层次结构。
要注意编制的程序或模块应容易理解、容易修改，模块应相互独立，对某一模块的修改应对其他模块的功能不产生影响，模块间的联系尽可能少。
5.系统测试 测试是为了发现程序中的错误，对于设计的软件，出现错误是难免的。
系统测试通常由经验丰富的设计人员设计测试方案和测试样品，并写出测试过程的详细报告。
系统测试是在单元测试的基础上进行的，包括：① 测试方案的设计；② 进行测试；③ 写出测试报告；④ 用户对测试结果进行评价。
6、文档资料 文档包括开发过程中的所有技术资料以及用户所需的文档，软件系统的文档一般可分为系统文档和用户文档两类。
用户文档主要描述系统功能和使用方法，并不考虑这些功能是怎样实现的；系统文档描述系统设计、实现和测试等方面的内容。
文档是影响软件可维护性、可用性的决定因素，有句话讲，系统编程人员的每一张纸片都要保留，所以文档的编制是软件开发过程中的一项重要工作。
系统文档包括：开发软件系统在计划、需求分析、设计、编制、调试、运行等阶段的有关文档。
在对软件系统进行修改时，系统文档应同步更新，并注明修改者和修改日期，如有必要应注明修改原因，应切记过时的文档是无用的文档。
用户文档包括：① 系统功能描述；② 安装文档，说明系统安装步骤以及系统的硬件配置方法；③ 用户使用手册，说明使用软件系统方法和要求，疑难问题解答；④ 参考手册，描述可以使用的所有系统设施，解释系统出错信息的含义及解决途径。
7、系统的运行与维护 系统只有投入运行后，才能进一步对系统检验，发现潜在的问题，为了适应环境的变化和用户要求的改变，可能会对系统的功能、使用界面进行修改。
要对每次发现的问题和修改内容建立系统维护文档，并使系统文档资料同步更新。
软件实施工程师的地位以及发展前景。
展开全部 软件实施工程师是软件产品服务主线的一个决定性工作，一款软件的成功离不开软件工程师的实施。
一个好的软件实施工程师，其地位是很高的，其发展前景更是无可限量的。
软件实施工程师负责工程实施主要项目包括： 常用操作系统、应用软件及公司所开发的软件安装、调试、维护，还有少部分硬件、网络的工作； 负责现场培训： 现场软件应用培训； 协助项目验收； 负责需求的初步确认； 负责项目维护。
1、软件实施工程师的地位：综上所述，即可得出软件实施工程师的地位的重要性，甚至可以说他是对一个项目起到决定性的作用的工作，软件产品不同于其他行业的产品，特别是行业解决方案软件产品，用户购买后多数是不能立即进行使用的，这时候就需要软件公司的技术人员在软件技术、软件功能、软件操作等方面进行系统调试后方可上线使用，这期间还包括后期的维护。
2、软件实施工程师的发展前景：从收入来说，软件实施工程师的收入都是同行中比较高的收入群体，收入高，自然职业发展前景就好。
从职业来说，软件是不断发展和完善的，而每一款软件的发展和完善，都离不开软件实施工程师的运作和实施，所以其工作前景是光明的。
...
华天动力的“协同OA”优势在哪？
在我们进行一系列需求调研工作的同时，我们的需求分析工作也开始启动了。
需求调研与需求分析工作应当是相辅相伴共同进行的。
每次参加完需求调研回到公司，我们就应当对需求调研的成果进行一次需求分析。
当下一次开始进行需求调研时，我们应当首先将上次需求分析的结果与客户进行确认，同时对需求分析中提出的疑问交给客户予以解答。
这就是一个需求捕获->需求整理->需求验证->再需求捕获的过程。
但是，当我们经过一番忙碌，将需求中的第一手资料从调研现场捕获回来以后，我们应当怎样进行分析呢？不少团队对此都比较迷茫，没有一个统一和有效的方法，往往采用想到哪里做到哪里的方式。
一些问题想到了就做了，没有想到则忽略掉了。
实际上，需求分析不应当是太公钓鱼，而应当是拉网排查。
任何一个疏忽都可能对项目研发带来风险。
因此，我们应当采用一套成熟而完整的分析方法，稳步而有序地完成这部分工作。
不同类型的软件项目其分析方法可能存在差异，但一般来说，信息化管理类软件项目通常从这几个方面着手分析：功能角色分析、业务流程分析与业务领域分析。
需求分析不是一项一蹴而就就可以完成的工作，它需要一个长期的过程，而这个过程是一个由粗到细的过程，它体现了人类认识事物的客观规律。
在需求分析的初期，我们对需求的认识往往是整体的、宏观的，随着分析工作的逐渐深入，一步步细化。
按照这个思路，我们对需求的分析，首先应当从功能角色分析开始。
所谓功能角色分析，就是从一个外部用户的视角分析整个软件系统能够提供的功能，以及这些功能到底是提供给哪些角色使用。
对一个系统进行功能和角色方面的梳理和分析，可以采用的比较主流的方法之一就是绘制用例图。
用例图是UML的4+1视图中的一种，准确地说就是那个“+1”。
用例图是贯穿整个面向对象分析/设计（OOA/D）的核心视图，它描述的是系统到底为用户提供了哪些功能，以及到底是哪些用户在使用这些功能，是沟通用户与技术人员的桥梁。
运用用例视图对业务需求进行分析、抽象、整理、提炼，进而形成抽象模型的过程称之为用例建模，而这个模型就是用例模型。
一般地，在一个用例图中通常有三种元素：参与者（Actor）、用例（Use Case）与系统边界（Boundary）。
用例描述的是系统为用户提供的功能，也就是系统能为用户做什么，通常被绘制成一个椭圆；参与者，我认为称为角色更加合适，也就是系统为哪些类型的用户提供服务，他们都各自承担哪些不同的职责，通常被绘制成一个小人儿；最后是系统边界，也就是系统是对现实世界哪个范围的内容进行的模拟，它涉及到软件设计的工作范围与工作量，通常被绘制成一个方框。
但是，通常情况下系统边界只是一个概念而不用真正绘制出来，因为被绘制成用例的必然是系统内部的功能，被绘制成参与者的必然是系统外部事物。
从这个意义上讲，用例图中的参与者不仅包括人，还包括那些外部系统和自动触发器。
根据这样一个思路，我以往常常将外部系统和自动触发器绘制成一个小人，这常常令客户感到困惑。
随后我改变了思路，将外部系统和自动触发器绘制成另一种表达形式——类元符号表示法，并在构造型上标注为Actor。
上图是一个考核系统中一个子模块的用例图。
图中的用例就是这个系统提供给用户的各项功能。
注意，这里仅仅是在罗列功能而不表示它们之间诸如流程调用等相互关系，这是一些初学者常常犯的毛病。
参与者与用例通过实线关联起来，代表的是一种使用关系。
箭头代表的是一种导航，即动作施与的方向。
在这个用例图中，普通用户执行查询操作，查询系统提供的“预警监控单项查询”、“预警监控汇总查询”等查询报表；每日自动触发器触发自动考核功能，自动考核功能从“税收征管系统”这样一个外部系统中采集数据。
图中考核管理员和执法人员代表的是两个完全不同的角色，但他们在这个图中体现的是一些共有的特性，即对这堆报表的查询，因此被绘制成继承自普通用户。
继承是参与者间唯一的关系，代表继承者拥有被继承者所有的功能与权限。
除了参与者以外，用例与用例直接也存在着一些类型的关系，这我们在后面详细讲述。
在绘制用例图时一个值得思考的细节是，用例是怎样通过分析获得的。
这个问题，在一些客户对信息化管理比较有经验的项目中不存在问题，因为在客户提供给我们的需求文档中就清晰地划分出了一项一项的功能。
这些功能可能会在日后的需求分析工作中有所调整，但它从整体上形成了一个雏形，成为我们进行用例分析进而形成用例的依据。
但当我们面对的是一些对信息化管理没有经验的客户，情况就有些不妙了。
在这种情况下，通常客户只能给我们一些管理目标、基本想法，其它的调研工作就需要我们自己去做了。
这时，我给大家的建议是，首先从组织机构上划分清楚系统涉及哪些部门、哪些科室，然后在这个基础上划分出来这些部门这各个科室的人员都扮演哪些不同职能的角色，以及完成哪些业务操作。
系统中的一个功能，在一般情况下是组织机构中某个（或多个）角色，为该机构某项业务流程完成的某个操作，并且这个...
