软件需求工程

软件需求工程第四章软件需求与需求工程1软件需求的定义软件需求可以定义为：业务知识+问题列表+其它因素。

业务知识：包括业务事件、业务实体和业务规则

问题列表：用户在工作中遇到的困难和障碍，即软件开发时要解决的问题。

其它因素：设计约束和非功能方面的需求2需求的层次与类型三个层次：业务需求、用户需求、软件需求

业务需求项目视图/范围文档用户需求用例文档功能需求软件需求质量属性其他非功能需求设计约束SRS非功能需求三种类型：功能需求、非功能需求、设计需求

3需求的三个层次—业务需求业务需求是反映企业/组织对软件系统的高层次目标要求，即软件系统的建设目标。这种目标体现在两个方面：

问题：解决企业/组织运作过程中遇到的问题。如物资供应脱节、用户投诉大等。

机会：抓住外部环境变化带来的机会，以便为企业带来新的发展。如电子商务、网上银行等。

业务需求的提出者通常是企业/组织的高层管理人员，导出的是软件开发的高层需求，代表着软件项目开发的方向。业务需求是需求定义的产物，是软件项目立项阶段必须明确的问题。4需求的三个层次—用户需求用户需求描述的是用户使用软件需要完成什么任务、怎样完成任务的需求。用户需求是在业务需求的基础上进行用户访谈、调查，对用户使用场景进行整理的结果。即用户需求是需求捕捉的产物。特点：

●零散：用户会提出不同角度、不同层面、不同粒度的需求，而且通常是以一句话的形式提出的。

●存在矛盾：用户处于企业/组织的不同层面，提出的需求往往具有片面性，甚至不同用户之间会持不同的观点。

用户需求也叫原始需求，需要进行分析和整理，从而得到更加精确的需求说明。5需求的三个层次—软件需求软件需求是需求分析和建模的产物，是对用户需求进行分析、提炼、整理的结果。即需求规格说明书描述的结果。

业务需求是需求定义的产物用户需求是需求捕捉的产物软件需求是需求分析和建模的产物6软件需求的三种类型—功能需求

功能需求最关键的问题是如何对其进行组织,即如何来表达功能需求（表达形式不一样，得到不一样的结果）。传统的方法以系统->子系统->模块->下层模块的层次结构来组织。这种组织基本上是按照程序的结构来梳理，难以体现用户的使用场景。

现代需求理论更加强调需求分析人员从用户的角度，将系统理解成一个黑盒子，从横向的使用视角来整理需求。采用用例的方法组织功能需求被认为目前是最佳方法。

7软件需求的三种类型—非功能需求

非功能需求的要点在于保证信息的有效传递和注意其局部性。

信息传递无效性：在很多需求规格说明书中都列出诸如高可靠性、高可用性、安全性、高扩展性的要求。但开发人员根本不去看，因为这样的定性描述是没有判断标准的，即这种信息传递是无效的。信息传递有效性指开发人员能够清楚地知道列出的非功能需求针对的问题和要达到的标准，如系统7×24小时不间断运行，指系统在用户看来任何时候不能中断运行。

非功能需求的局部性：绝大多数非功能需求都是针对具体的功能，而非整个系统。如“所有查询的响应时间不超过10秒”的描述，对于一般性的简单查询或许可能满足，但对于年度统计分析的查询可能很难满足。更科学的做法是抓住具体的场景来描述非功能需求。

8软件需求的三种类型—设计约束

设计约束指软件系统开发所必须遵守的限制条件。

非技术因素决定的技术选型：有些技术选型不是由技术团队决定，而是受到企业/组织实际情况的影响。如铁路行业规定铁路信息系统开发必须采用oracle数据库管理系统，必须采用三级数据库部署架构。有的要求系统开发采用J2EE等。

预期的硬软件环境：技术开发团队在决定架构、选择实现技术时会受到企业/组织实际的硬软件环境的影响。如企业/组织的网络环境、服务器性能、个人电脑配置、操作系统、工具软件等，应该将这些预期的硬软件环境描述出来。

预期的使用环境：除硬软件环境之外的其它环境，如地理环境、基于局域网的信息系统的在局域网范围之外的移动设备用户、野外现场应用等。9优秀需求的标准—完整性

1、完整性需求的完整性就是需求没有遗漏。要保障需求的完整性，就必须从业务角度来组织各种需求项。与需求相关的主题域、业务事件、业务活动、业务步骤、困难与障碍点等尽可能完整，更具操作性。业务导向的层次结构是保障完整性的关键。用户是验证需求完整性的合适人选。需求完整性存在不同层面。企业/组织中的高层管理人员、中层管理人员、业务操作人员所了解和掌握的信息是不一样的。要从不同层次的需求来验证需求的完整性，即不同层次人员只负责评审与自己相关的需求。10优秀需求的标准—不失真

2、不失真确保需求在信息传递的过程中不失真（不同人对其理解的一致性），即确保需求的正确性和无歧义性。正确性：要找到正确的人来验证需求，即不同层次的用户验证对应层次的需求和直接相关的人员来验证需求。

无歧义性：歧义主要是不同背景的人在传递时加入不同理解而导致的。可能要通过协商或上一层次的人来解决。要确保需求不失真，加强需求的验证是关键手段。11优秀需求的标准—有优先级

3、需求有优先级

“事有轻重缓急”，需求也有不同的优先级，用户最希望系统能解决他希望解决的问题，在软件验收时，总是抓住他希望实现的功能反复使用，看是否满足他的要求。同时，在设计时关键需求决定软件架构。优先级的三种角度角度参与人员说明要点业务用户代表需求人员根据业务的价值和频度进行评价优先级是相对的技术开发架构师开发人员根据技术依赖性对优先级进行评价在业务优先级后进行只提级不降级项目管理项目经理架构师根据项目风险对优先级进行评价在业务优先级后进行只提级不降级12优秀需求的标准—技术团队早介入

4、开发团队早介入

需求规格说明书的内容来自用户，需求规格说明书的读者是技术团队，即开发团队和测试团队。需求的可行性需要开发团队早介入。某些需求项在实现方面的可行性需要开发团队给予评价。需求分析的可验证性指需求规格说明书应能指导测试活动。需求规格说明书的组织应考虑测试的需要，应该便于推导出测试用例。13需求工程软件工程活动包括需求、系统分析与设计、编码、测试、配置管理等活动，但唯独只有需求被称为工程。需求错误的代价阶段代价（时间单元）需求1设计5编码10测试20--50运行与维护200在需求阶段花1个时间单元改正的错误，推迟到设计阶段改正需要花5倍的时间，编码阶段是10倍，测试阶段是20至50倍，维护阶段是200倍之多。14需求工程—范畴需求工程包括需求开发和需求管理两大范畴需求获取需求分析编写规约需求验证需求工程基线管理变更管理需求跟踪需求开发需求管理15需求工程—需求开发需求开发包括需求获取、需求分析、编写规约和需求验证。需求获取需求分析编写规约需求验证证实重写评估重新更正16需求工程—需求开发

需求获取：也称需求捕获，即获取用户需求。

需求分析：需求分析是需求开发中的核心任务。需求分析是业务分析，因此将从业务线索入手，对用户需求进行分析、提炼和整合，建立模型。必须强调的是：需求分析是目标，需求建模是手段，建模的过程就是分析的过程。

编写规约：将需求分析结果文档化的过程—需求规格说明书。

需求验证：通过评审发现尽可能多的错误，减少因需求错误而带来的工作量浪费。需求验证的关键手段是评审。17需求工程—需求开发需求开发的4个具体活动不是一个顺序过程，而是要通过多次循环才能完成。一般至少要经过3次循化才能完成。循环工作任务对应的RUP阶段初始循环明确项目的目标和范围，完成子系统划分；明确每个子系统的内容（业务事件和报表）和相互之间的接口。初始阶段脉络阶段通过对每个业务事件进行流程分析、业务实体分析，并标识出所有用例。细化阶段的第一次迭代细节循环对每个用例的细节进行分析，包括事件流、用户界面原型等细化阶段的第二次迭代18需求工程—需求管理

1、基线管理需求基线的内容是一次迭代开发的工作内容。基线中的需求是明确的，所以每次迭代都是一个小型的瀑布型生命周期。通过这样的划分，整个开发工作被划分成了多个小项目。这样更容易使开发人员保持良好的工作节奏。

2、变更管理

需求变更管理的核心是控制变更对技术开发工作所带来的影响，以减少返工、重做的工作量。

3、需求跟踪

需求跟踪是将单个需求与其它系统元素之间的依赖关系和逻辑关系建立跟踪。包括用户需求向前跟踪到软件需求，从软件需求到向前跟踪到下游工作产品；从下游工作产品后向跟踪到软件需求，从软件需求后向跟踪到用户需求。19需求分析人员的技能需求分析人员是对项目相关人员的需求进行收集、分析、记录和验证等职责的主要承担者，是用户群体与软件开发团队间进行需求沟通的主要渠道。主要完成的活动包括：定义业务需求、确定项目涉众和用户类别、获取需求、分析需求、为需求建模、编写需求规格说明、主持对需求的验证、引导需求的优先级的划分、管理需求。需求分析人员必须掌握的技能包括：倾听、交谈和提问的技巧，分析、协调、观察、写作、组织、建模、人际交往和建模能力。这些能力可以概括为业务知识、技术知识和沟通能力三个方面20课程任务本课程主要讲解与需求开发的相关内容。具体将按照Subject->Event/Report->UseCase的层次过程进行