需求工程

1,第4章需求工程,软件需求软件需求文档需求描述需求工程过程需求导出和分析需求有效性验证,2,4.1软件需求,软件需求（requirements）描述了系统应该提供的服务以及实现和运行时所受到的约束。Lethbridge定义为需求是关于系统将要完成什么工作的一段描述，它们必须经过所有相关人员的认可，其目的是彻底的解决用户的问题。,3,由于使用不同的方法和抽象层次来表达需求，Sommerville根据需求的来源将需求分成用户需求和系统需求两个不同层次的概念：用户需求：给出高层概要需求的描述，只描述系统的外部行为。系统需求：详细描述系统要提供的服务以及所受到的约束。为了能更好的理解，系统需求可能包括许多不同的模型，因此在需求分析阶段需要建模。,4,系统需求的进一步分类,1、功能需求描述系统应该做什么，即必须为用户和其它系统完成的功能、提供的服务以及在特定的条件下系统的行为。2、非功能需求指那些不直接与系统具体功能相关的一类需求。两种需求互相有联系，也可能有冲突。,5,4.2软件需求文档,软件需求文档称为软件需求说明（SoftwareRequirementsSpecification，SRS），也称需求规约，是经过验证的正式文档。它是需求分析阶段重要的产品，是所有其他开发和管理活动的基础。,6,需求文档应满足如下要求：具有准确性和一致性无二义性直观、易读和易于修改,7,4.3需求描述,1、自然语言描述2、结构化描述以一种标准方式来书写（使用模板），可以用程序设计语言中的选择结构和重复结构（教材P60图4-10）。,8,3、表格和图形模型采用标准的工具将需求进行图形化描述，以减少理解偏差。描述业务需求、用户需求的图形主要使用例图（确定业务范围）、活动图（描述业务流程），功能需求常用的是时序图、协作图、数据流图等。几种描述方法结合起来。,9,4.4需求工程过程,需求工程是一个包括创建和维护系统需求文档所必需的一切活动的过程。它主要包含了如下活动：业务需求的描述可行性研究需求获取（导出）和分析需求描述和文档编写需求有效性验证需求管理（管理需求的变更）,10,可行性研究,需求导出和分析,需求描述,需求有效性验证,可行性研究报告,系统模型,用户需求和系统需求,需求规约,需求工程过程,活动,模型或文档,需求管理,11,4.5需求导出和分析,软件开发人员、客户、系统最终用户一起调查应用领域：系统应该提供什么服务，应具有什么性能以及约束。涉及到多方面的人。过程模型见下图：,12,需求分类和组织,需求导出,优先排序和冲突解决,需求文档编制,需求导出和分析过程,13,需求导出技术,1、建立由客户（用户）、管理者、系统分析员、业务专家等信息持有者建立的的联合小组。2、需求导出的方法：个别访谈、召集会议、已有文件的研究、问卷调查、观察用户工作流程、建立原型。3、获取的需求的表达方式（建模）：（1）需求列表（2）业务流程图（状态/活动图）（3）视点(viewpoint)/用例(usecase)/脚本(scenario)/用户故事（userstory)的描述（4）数据流图（5）实体关系图（6）类图、时序图、协作图等等。,14,视点(viewpoint)是一种收集和组织需求的方式，一般用来分类需求源头。如：交互者视点：间接视点：领域视点：下列经验帮助你识别视点：,15,脚本(scenario)也称为场景，是用例的具体描述。一个用例封装了一组场景。脚本可用文本来是写，可附带图（如时序图）。,16,用例(usecase)根据Jacobson的定义，用例规定了一个动作的序列，系统执行这些动作并产生出对于特定参与者可见的有价值的结果。用例的集合代表了所有将会在系统需求中出现的交互。因此容易从使用的角度理解系统应达到的功能。一个用例最简单的形式是：在一个交互中定义参与的角色并命名该交互类型。,17,4.6需求有效性验证,需求验证是检查需求的有效性、一致性、完备性、真实性和可检验性的过程。需求验证的重要性：如果在后续的开发或当系统投入使用时才发现需求规约中的错误，就会导致更大代价的返工。由需求问题而对系统做变更的成本比修改设计或代码错误的成本要大的多。,18,对需求规约需执行以下类型的检查：（1）有效性检查（2）一致性检查（3）完备性检查（4）真实性检查(5)可检验性检查,19,需求验证技术（1）需求评审：正式会议要有严格的评审程序，要有会议记录。评审团除了检查需求的有效性、一致性、完备性等特性外