DRP项目（一）----需求的重要性

         又开始 学习新的项目，首先来介绍一下，下面我们即将学习的DRP（distribution resource planning 分销资源计划）。     

         DRP：是分销需求计划的延伸部分, 涉及分销系统中的关键资源, 如仓储空间、劳动力、货币资金、运输工具等等的计划，我们将从软件的设计的角度来记录分析和实现这些问题。

        一个软件的开始是从软件的需求开始的，DRP也不例外。DRP的业务需求在王老师的视频中讲的很详细了，我这就不详细书写了。但是不写并不代表不重要。

       需求通俗地说，软件需求分析师解决做什么，怎样做的问题，告诉客户及开发人员需要什么功能，以何种方式，在什么平台去进行操作，开发结束后，应交付那些东西。

       需求分析就是分析软件用户的需求是什么，如果投入大量的人力，物力，财力，时间，开发出来的软件却没人要，那所有的投入都是徒劳的，如果费了很大的精力，开发一个软件，最后却不满足用户的要求，从而要重新开发，这种返工是让人痛心疾首的。

       需求分析之所以重要，就因为他具有决策性，方向性，策略性的作用，他在软件开发的过程中具有举足轻重的地位，大家一定要对需求分析具有足够的重视，在一个大型系统项目开发中，它的作用远远大于程序设计。

        一：需求分析

               1.了解客户的要求

               2.分析系统的数据要求

        二：需求分析过程

               1. 问题识别：从系统角度来理解软件，确定对所开发系统的综合要求，并提出实现条件，以及需求应该达到什么样的标准，需求包括：功能需求（做什么），性能需求（达到什么样的目标），环境需求（如机型，操作系统等），可靠性（不发生故障的概率），安全保密要求，用户界面需求，资源使用需求（软件运行时所需的内存、CPU等），软件成本消耗与开发进度需求，预先估计以后系统可能达到的目标

              2.分析与综合：逐步细化所有功能，找出系统各元素间的联系，接口特性和设计上的限制，分析他们是否满足要求，提出不合理请求部分，增加需求部分，综合成系统的解决方案，给出开发的系统的详细逻辑模型（做什么模型）。

             3.制定规格说明书：软件需求说明书

       评审

             对功能的正确性、完整性和清晰性，以及其他需求给予评价，通过与客户的再一次交谈来确认

      三：需求分析误区             

　 要想说什么是好的需求分析，不如说什么是不好的需求分析，知道什么是不好的，自然也就知道了什么是好的。以下就是一些不好的情况：

　　（１）创意和求实 毋庸质疑的，每个人都会为自己的一个新的Ｉｄｅａ而激动万分，特别是当这个Ｉｄｅａ受到一些根本不知道你原本要干嘛的人的惊赞时。但是请注意，当你激动得意的时候，你可能已经忘了你原本是在描述一个需求，而不是在策划一个创意、创造一个概念。很多刚开始做需求分析的人员都或多或少的会犯这样的错误，陶醉在自己的新想法和新思路中，却违背了需求的原始客观性和真实性原则。 永远别忘了：需求不是空中楼阁，是实实在在的一砖一瓦。

　　（２）解剖的快感 几乎所有搞软件的人，做需求分析的时候，一上来就会把用户告诉你的要求，完完整整的作个解剖，切开分成几个块，再细分成几个子块，然后再条分缕析。可是当用户迷惑的看着你辛辛苦苦做出来的分析结果问你：我想作一个数据备份的任务，怎么做？这时，你会发现，需要先后打开三个窗口才能完成这个任务。 永远别忘了：分解是必需的，但最终的目的是为了更好的组合，而不是为了分解。（３）角度和思维 经常听到这样的抱怨：“用户怎么可以提出这样苛刻的要求呢？”。细细一了解，你会发现，用户只不过是要求把一个需要两次点击的功能，改成只有一次点击。这样会导致需要改变需求、改变编码、甚至重新测试，增加工作量。可是，如果换个角度来想想，这个功能，开发的时候只用了几次、几十次，可是用户每天都要用几百次甚 至几千次几万次，改动一下就减少了一半的工作量，对他来说，这样的需求难道会苛刻吗？ 永远别忘了：没有任何需求是不对的，不对的只是你的需求分析。试着站在用户的思维角度想想，你的需求分析就会更加的贴近用户，更加的合理。软件应该是以人为本的。

　　（3）程序员逻辑 从程序员成长为系统分析员是一个普遍的轨迹，但并不是一个好的程序员就必然能成为一个好的系统分析员。一些程序员的固化逻辑，使得他们在做需求分析的时候往往钻进了一些牛角里面。比如说１／０逻辑（或者是说黑白逻辑），认为不是这样就是那样，没有第三种情况。可实际情况往往是，在一定的时候是这样，其它时候是那样。又比如穷举逻辑，喜欢上来就把所有一二三可能的情况列举出来，然后一个一个分别处理，每个占用三分之一的时间；可是实际的情况往往是，三分之一的情况占了９９％的比例，其它两种情况一年都不会遇到一次。实际中还有很多这样的例子，不一一列举了。 永远别忘了：需求分析和程序设计不尽相同，合理、可行是才是重要的。跳出程序设计的圈子，站在系统的角度上来看问题，你的结论会截然不同。