《售前职路的技术》片段.pdfVIP

第十三章 需求分析与需求过程 【学习要点】本章内容适用于“信息化应用指导类”、“信息系统应用服务类”岗 位。要求通过本章的学习，了解软件需求的重要意义、需求工程方法、需求过程框架以 及问题分析方法。掌握业务模型建立、需求收集方法、产品定义、用例及其细化描述、 功能需求定义方法、非功能需求定义方法、软件需求规格说明的撰写以及需求评审方法。 13.1 需求工程原理 产品为用户所做的事情，以及产品在这种上下文背景中必须满足的约束，就是产品 的需求。程序设计的有效性依赖于规格说明，规格说明的有效性依赖于对问题域的理解。 没有好的需求，就没有办法验证程序设计的正确性，也就没有办法把程序与客户的期望 用一种逻辑性的方法联系起来。特别是当项目比较大需要很多人共同工作的时候，需求 可以保证整个开发团队沿着规定的目标一起前进。其实在软件开发中遇到的许多问题， 都是由于收集、编写、协商、修改产品需求过程中的手续和作法（方法）失误带来的。 为此我们必须深入地研究和建立良好的需求过程。 13.1.1 需求的层次 下面我们定义在需求工程领域中常见术语。软件需求包括三个不同的层次—业务需 求、用户需求、功能需求以及非功能需求。 1．业务需求 （business requirement ）：反映了组织机构或客户对系统、产品高层次 的目标要求，它们在项目视图与范围文档中予以说明。 2 ．用户需求 （user requirement ）：文档描述了用户使用产品必须要完成的任务，这 在用例（ use case ）文档或方案脚本（scenario ）说明中予以说明。 3 ．功能需求 （functional requirement ）：定义了开发人员必须实现的软件功能，使 得用户能完成他们的任务，从而满足了业务需求。所谓特性( feature )是指逻辑上相关的 功能需求的集合，给用户提供处理能力并满足业务需求。 4 ．非功能需求 （Non-functional requirement ）：非功能需求描述了产品必须遵从的 标准、规范和合约；外部界面的具体细节；性能要求；设计或实现的约束条件及质量属 性。所谓约束是指对开发人员在软件产品设计和构造上的限制。质量属性是通过多种角 度对产品的特点进行描述，从而反映产品功能。 软件需求各组成部分之间的关系如图13-1 所示。 图13-1 软件需求各组成部分之间的关系 13.1.2 高质量的需求过程带来的好处 实行有效的需求工程管理的组织能获得多方面的好处。最大的好处是在开发后期和 整个维护阶段的重做的工作大大减少了。需求过程之难并不在于某些书写标准或规范， 也不是仅仅了解用户需要什么，而是需要深入地从各个角度研究用户需求，总结出用户 需求的本质和将来变化的规律，如果事情说不清楚，就没有办法做好。 正确的需求过程强调产品开发中的通力合作，包括在整个项目过程中多方风险承担 者的积极努力。让用户积极参与需求收集过程能使产品更富有吸引力，而且能拥有忠实 的客户关系。通过了解用户的任务需求而不仅仅局限于一些“华丽”的特性，你能避免 在无用功能上白耗精力，并且用户的参与能弥补用户期望和开发者实际开发之间的“期 望差异”。 13.1.3 优秀需求具有的特性 13.1.3.1 良好需求说明的特征 1．完整性：每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计 和实现这些功能所需的所有必要信息。 2．正确性：每一项需求都必须准确地陈述其要开发的功能。做出正确判断的参考是 需求的来源，如用户或高层的系统需求规格说明。 3．可行性：每一项需求都必须是在已知系统和环境的限制范围内可以实施的。为避 免不可行的需求，最好在获取需求过程中始终有一位软件工程小组的组员与需求分析人 员或考虑市场的人员在一起工作，由他负责检查技术可行性。 4．必要性：每一项需求都应把客户真正所需要的和最终系统所需遵从的标准记录 下来。“必要性”也可以理解为每项需求都是用来授权你编写文档的“根源”。 5．划分优先级：给每项需求、特性或用例分配一个实施优先级以指明它在特定产品 中所占的分量。如果把所有的需求都看作同样重要，那么项目管理者在开发或节省预算 或调度中就丧失控制自由度。 6．无二义性：对所有需求说明的读者都只能有一个明确统一的解释，避免二义性的 有效方法包括对需求文档的正规审查，编写测试用例，开发原型等。 7．可验证性：检查一