为什么需要需求分析和管理
开发进销存MES最为困难的部分就是准确说明开发什么。最为困难的概念性工作便 是编写出详细技术需求，这包括所有面向用户、面向机器和其它进销存MES的接口。同 时这也是一旦做错，将最终会给系统带来极大损害的部分，并且以后再对它进行修改 也极为困难。
不重视需求过程的项目队伍将自食其果。需求工程中的缺陷将给项目成功带来极大风险， 这里的“成功”是指推出的产品能以合理的价格、及时限在功能、质量上完全满足用户的期望。
不适当的需求过程所引起的一些风险
? 用户不多导致产品无法被接受。
? 用户需求的增加带来过度的耗费和降低产品的质量。
? 模棱两可的需求说明可能导致时间的浪费和返工。
? 用户增加一些不必要的特性和开发人员画蛇添足 ( g o l d - p l a t i n g )。
? 过分简略的需求说明以致遗漏某些关键需求。
? 忽略某类用户的需求将导致众多客户的不满。
? 不完善的需求说明使得项目计划和跟踪无法准确进行。
正确的需求带来的好处：
正确的需求过程强调产品开发中的通力合作，包括在整个项目过程中多方风险承担者的
积极努力。收集需求能使开发小组更好地了解市场，而市场因素是任何项目成功的一个关键
因素。在产品开发前了解这些比在遭到客户批评后才意识到要节约很多成本。让用户积极参
与需求收集过程能使产品更富有吸引力，而且能拥有忠实的客户关系。通过了解用户的任务
需求而不仅仅局限于一些“华丽”的特性，你能避免在无用功能上白耗精力，并且用户的参
与能弥补用户期望和开发者实际开发之间的“鸿沟（期望差异）”。
将选定系统的需求明确地分配到各软件子系统，强调采用产品工程的系统方法。这样能 简化硬软件的集成，也能确保软硬件系统功能匹配适当。有效的变更控制和影响分析过程也 能降低需求变更带来的负面影响。最后，将需求编写成清晰、无二义性的文档将会极大地有 利于系统测试，确保产品质量，以使所有风险承担者感到满意。
优秀的需求
1. 完整性 每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。
2. 正确性 每一项需求都必须准确地陈述其要开发的功能。做出正确判断的参考是需求的来源，如 用户或高层的系统需求规格说明。若软件需求与对应的系统需求相抵触则是不正确的。只有 用户代表才能确定用户需求的正确性，这就是一定要有用户的积极参与的原因。没有用户参 与的需求评审将导致此类说法：“那些毫无意义，这些才很可能是他们所要想的。”其实这完 全是评审者凭空猜测。
3. 可行性 每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。为避免不可行 的需求，最好在获取（ e l i c i t a t i o n）需求(收集需求)过程中始终有一位软件工程小组的组员与 需求分析人员或考虑市场的人员在一起工作，由他负责检查技术可行性。
4. 必要性 每一项需求都应把客户真正所需要的和最终系统所需遵从的标准记录下来。“必要性”也 可以理解为每项需求都是用来授权你编写文档的“根源”。要使每项需求都能回溯至某项客户 的输入，如使用实例或别的来源。
5. 划分优先级 给每项需求、特性或使用实例分配一个实施优先级以指明它在特定产品中所占的分量。 如果把所有的需求都看作同样重要，那么项目管理者在开发或节省预算或调度中就丧失控制 自由度。
6. 无二义性 对所有需求说明的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性， 所以尽量把每项需求用简洁明了的用户性的语言表达出来。避免二义性的有效方法包括对需 求文档的正规审查，编写测试用例，开发原型以及设计特定的方案脚本。
7. 可验证性 检查一下每项需求是否能通过设计测试用例或其它的验证方法，如用演示、检测等来确 定产品是否确实按需求实现了。如果需求不可验证，则确定其实施是否正确就成为主观臆断， 而非客观分析了。一份前后矛盾，不可行或有二义性的需求也是不可验证的。
需求开发
软件需求包括三个不同的层次—业务需求、用户需求和功能需求—也包括非功能需求。
业务需求（business requirement）反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。
用户需求 (user requirement) 文档描述了用户使用产品必须要完成的任务，这在使用实例（ use case）文档或方案脚本（ s c e n a r i o）说明中予以说明。
功能需求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。
所谓特性 ( f e a t u r e )是指逻辑上相关的功能需求的集合，给用户提供处理能力并满足业务需求。
敏捷研发中三层级需求系统任务分解体系
鉴于国内金融组织的业务特点，我们推荐采用需求-系统任务-个人任务的需求管理体系：
u 需求：提供完整业务价值，能够细化到一次发布完整上线的程度。
u 系统任务：需求被拆分到不同系统，每个任务必须对应到一个系统，可反馈，建议每个系统任务不超过10人天工作量。
u 个人任务：将系统任务分解到个人，如前端开发任务、后端开发任务、测试用例编写，建议每个个人任务不超过3人天工作量。
web框架需求开发可进一步分为：问题获取（ e l i c i t a t i o n）、分析 ( a n a l y s i s )、编写规格说明（s p e c i f i c a t i o n）和验证（v e r i f i c a t i o n）四个阶段（Thayer and Dorfman 1997）。
这些子项包括软件类产品中需求收集、评价、编写文档等所有活动。需求开发活动包括以下几个方面：
? 确定产品所期望的用户类。
? 获取每个用户类的需求。
? 了解实际用户任务和目标以及这些任务所支持的业务需求。
? 分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息。
? 将系统级的需求分为几个子系统，并将需求中的一部份分配给软件组件。
? 了解相关质量属性的重要性。
? 商讨实施优先级的划分。
? 将所收集的用户需求编写成规格说明和模型。
? 评审需求规格说明，确保对用户需求达到共同的理解与认识，并在整个开发小组接受说明之前将问题都弄清楚。
需求管理
需求管理需要“建立并维护在软件工程中同客户达成的契约”（CMU/SEI 1995）。这种契 约都包含在编写的需求规格说明与模型中。
客户的接受仅是需求成功的一半，开发人员也必 须能够接受他们，并真正把需求应用到产品中。
web框架通常的需求管理活动包括：
? 定义需求基线（迅速制定需求文档的主体）。
? 评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它。
? 以一种可控制的方式将需求变更融入到项目中。
? 使当前的项目计划与需求一致。
? 估计变更需求所产生影响并在此基础上协商新的承诺（约定）。
? 让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪。
? 在整个项目过程中跟踪需求状态及其变更情况。
由下图中可以从另一个角度来看需求开发和需求管理之间的区别：
