转：需求分析的过程及需求类型

时　间:2010-09-20 00:00:00
作　者:匿名   ID：10768  城市：成都
摘　要: 从以上定义可以发现，需求并未包括设计细节、实现细节、项目计划信息或测试信息。需求与这些没有关系，它关注的是充分说明你究竟想开发什么。项目也有其它方面的需求，如开发环境需求或发布产品及移植到支撑环境的需求。尽管这些需求对项目成功也至关重要，但它们并非本书所要讨论的。
正　文:

需求开发可进一步分为：问题获取、分析、编写规格说明和验证四个阶段。这些子项包括软件类产品中需求收集、评价、编写文档等所有活动。需求开发活动包括以下几个方面：
    1. 确定产品所期望的用户类别。
    2. 获取每个用户类的需求。
    3. 了解实际用户任务和目标以及这些任务所支持的业务需求。
    4. 分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息。
    5. 将系统级的需求分为几个子系统，并将需求中的一部份分配给软件组件。
    6. 了解相关质量属性的重要性。
    7. 商讨实施优先级的划分。
    8. 将所收集的用户需求编写成文档和模型。
    9. 评审需求规格说明，确保对用户需求达到共同的理解与认识，并在整个开发小组接受说明之前将问题都弄清楚。
    10. 需求管理需要“建立并维护在软件工程中同客户达成的合同” 。这种合同都包含在编写的需求文档与模型中。客户的接受仅是需求成功的一半，开发人员也必须能够接受他们，并真正把需求应用到产品中。通常的需求管理活动包括：
    11. 定义需求基线（迅速制定需求文档的主体）。
    12. 评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它。
    13. 以一种可控制的方式将需求变更融入到项目中。
    14. 使当前的项目计划与需求一致。
    15. 估计变更需求所产生影响并在此基础上协商新的承诺，这种承诺具体体现在项目解决方案上。
    16. 让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪。
    17. 在整个项目过程中跟踪需求状态及其变更情况。
    以上几点说明是我总结了成功实施项目后系统分析人员的经验，同时也根据国内外的其他系统实施的相关成功经验，进行了总结。

    软件需求包括三个不同的层次：业务需求、用户需求和功能需求（也包括非功能需求）。
   1．业务需求（business requirement）反映了组织机构或客户对系统、产品高层次的目标要求，们在项目视图与范围文档中予以说明。
    2．用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务，这在使用实例（use case）文档或方案脚本说明中予以说明。
    3．功能需求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他的任务，从而满足了业务需求。

    在软件需求规格说明书 （SRS）中说明的功能需求充分描述了软件系统所应具有的外部行为。软件需求规格说明在开发、测试、质量保证、项目管理以及相关项目功能中都起了重要的作用。对一个大型系统来说，软件功能需求也许只是系统需求的一个子集，因为另外一些可能属于子系统（或软件部件）。

    作为功能需求的补充，软件需求规格说明还应包括非功能需求，它描述了系统展现给用户的行为和执行的操作等。它包括产品必须遵从的标准、规范和合约；外部界面的具体细节；性能要求；设计或实现的约束条件及质量属性。所谓约束是指对开发人员在软件产品设计和构造上的限制。质量属性是通过多种角度对产品的特点进行描述，从而反映产品功能。多角度描述产品对用户和开发人员都极为重要。

    下面以一个字处理程序为例来说明需求的不同种类。业务需求可能是：“用户能有效地纠正文档中的拼写错误”，该产品的包装盒封面上可能会标明这是个满足业务需求的拼写检查器。而对应的用户需求可能是“找出文档中的拼写错误并通过一个提供的替换项列表来供选择替换拼错的词”。同时，该拼写检查器还有许多功能需求，如找到并高亮度提示错词的操作；显示提供替换词的对话框以及实现整个文档范围的替换。

    从以上定义可以发现，需求并未包括设计细节、实现细节、项目计划信息或测试信息。需求与这些没有关系，它关注的是充分说明你究竟想开发什么。项目也有其它方面的需求，如开发环境需求或发布产品及移植到支撑环境的需求。尽管这些需求对项目成功也至关重要，但它们并非本书所要讨论的。

Access软件网QQ交流群 (群号:54525238) 　　　　　　Access源码网店