我们应当怎么做需求分析

     无体现出论是从东软开发软件还是作者自己开发软件的经历中都体现出提前做好全面彻底的需求分析的重要性。而且就像上课时提到的不能完全任由客户提出需求，也就是不能说用户提出什么需求就完成什么，应该就能力还有开发实际情况，还有社会情况综合提出。这样给出自己的建设性的意见，不仅能够使开发过程更加得心应手，而且能够在客户心里树立权威。做需求调研不是形式主义而是要深入细节的调查，具体功能方面应该详细询问相关底层工作人员。另外强调的一个重点就是需求分析不是一蹴而就的，它应当贯穿整个开发周期，不断的分析确认的过程。

     首先，从第一印象开始，要适时表达出自己的意见从而让客户觉得自己比较有见地。中国是一个注重感情的国度，感情培养起来才好慢慢做事。在会议之前重要的是确定一个负责人，这样能够有助于在场面比较复杂的时候让其控制局面最终拍板决定。最后，与客户方领导制订出软件目标，是相当重要但常常被我们忽视的一个步骤。软件信息化管理不是包治百病的神药。很多项目的失败都归因与项目目标不明确造成的项目范围的失控。因此，这时讨论项目目标，既重要又适时。总结为三点1）树立良好的职业威信；2）进行详细角色分析，将与会各方代表对号入座；3）从宏观上制订目标与方案。在开发过程中努力去结识一些有助于我们顺利完成工作的人，和领域专家搞好关系，对那些对我们怀有敌意的人也不要抱着针尖对麦芒的心理，应当尽量化干戈为玉帛。研讨会也是一样，不能够指望一次性解决所有问题，应该多开小会，有针对的开小会。

     其次，在接下来的需求调研上，我们经历了，需求研讨、迭代、需求捕获、功能功能角色分析以及绘制用例图。这时候我们的系统整体结构已经大概清晰，然后我们进行业务流程分析，将系统划分为几个模块，然后针对每个模块进一步绘制用例图。在这个过程中，我们应该尝试缩减低效模块，促成更高效的系统，方便操作的同时，能够降低我们的工作量。简单说就是清除低效环节、简化业务瓶颈、整合可用资源，以及将繁琐任务自动化。

     然后，接下来在绘制用例图之后要对用例进行说明，那些查询、汇总与报表功能，需要我们描述的不是什么操作流程，而更重要的是那些数据项、数据来源、报表格式、数据链接，以及使用者、使用频率的说明。就是到了我们的查询报表分析。之后要对子用例和拓展用例进行分析，只有不断的分析细节才能防止一些必不可少的细节的疏漏。用例图能够清晰的展示系统的边界还有实现的功能，但是不能够动态的去描述系统所要实现的功能。行动图还有状态图能够有效的弥补这一弊端，但是在需求分析中，状态图并不是必须的，它仅仅出现在你认为需要对某个对象的状态进行说明的时候。

     再者，接下来就是业务领域分析，业务领域分析，就是对需求分析中涉及到的业务实体，以及它们相互之间关联关系的分析。系统中涉及的表单、报表，都是存在于系统的静态实体，它们中的大多数也最终以数据结构的形式持久化保存于系统的数据库中。因此，系统中应当有哪些实体，这些实体都有哪些属性，被赋予了哪些行为，它们之间的相互关系是怎样的，就成为了业务领域分析的重要内容，而业务领域分析也就成为了对系统进行的一种静态分析。原文分析是在进行了用例分析还有流程分析以后对结果进行进一步的分析。在伊大师的这个思想中，我们应当与客户代表形成一种统一的语言，一种混合语言。这种语言，既有软件技术中的元素，又有业务领域中的术语，这样才能有效消除隔阂，让业务人员和技术人员更有效的交流。在设计软件过程中往往忽略非功能方面的设计，所以应该早日让构架师加入讨论以实现系统性能，还有可靠性等构架层次问题的解决。

     最终，在编写需求规格说明书时注意不能脱离需求。在写好需求列表，编写出了需求规格说明书后，不代表需求分析就此结束了，它将延续到设计、开发，甚至测试阶段。整个过程虽然辛苦，但是会为以后的开发工作避免很多误区。

转载于:https://www.cnblogs.com/sisi-job/p/5906392.html