第三章_需求工程的推荐方法.pptVIP

3.3 需 求 分 析 需求分析包括对需求进行推敲和润色以保证所有的涉众人都能够理解需求，以及仔细检查找其中的错误、疏漏和其他缺陷。 分析包括将高层的需求分解成具体细节、创建开发原型，以及评估可行性和协商需求优先级。 绘制关联图 关联图是显示新系统如何适应它的环境的一个简单的分析模型 。 创建用户界面和技术原型 当开发人员或用户对需求不能确定时，可构建一个开发原型。 分析需求的可行性 在允许的成本和性能要求下，分析在指定的运行环境下实现每项需求的可行性。 3.3 需 求 分 析 确定需求优先级 可采用分析方法确定产品功能、用例或单项需求的相对实现优先级。 为需求建模 模型包括数据流图、实体关系图、状态转换图或状态图、对话图、类图、序列图、交互作用图、决策表和决策树等。 创建数据字典 数据字典中包括系统用到的所有数据项和结构的定义。 将需求分解到子系统 将多个子系统的复杂产品的需求分配到各个软件、硬件以及人员子系统和部件中去(Nelsen 1990)。 应用质量功能调配 质量功能调配(QFD)是一种高级系统技术，它将产品功能、属性与客户的重要性联系起来(Zultner 1993;Pardee 1996)。 3.4 规 格 说 明 获得需求，将它们编成一致的、可访问、可检查的文档。 采用SRS模板 该模板为记录功能说明和其他与需求相关的信息提供了统一的结构。 确定需求来源 为保证所有涉众都明白SRS中为何包括这些需求，以及便于进一步阐明需求，应追溯每项需求的来源。 为需求分配惟一标号 可定义一种约定，用于为SRS中的每项需求提供一个惟一的识别标号。 记录业务规则 业务规则包括公司章程、政府法规和计算机算法。 定义质量属性 在功能需求之外还应考虑非功能的质量属性这些属性包括性能、效率、可靠性、可用性等。 3.5 需 求 验 证 需求验证可确保需求声明是正确的、具备了所需的质量属性，而且能够满足客户的需要。 审查需求文档 对需求文档进行正式审查是保证软件质量的有效手段之一。 测试需求 根据用户需求推导出功能测试用例，以便记录产品在特定条件下应有的行为。 定义合格标准 让用户描述决定产品是否满足他们的需求并适合使用的标准。 3.6 需 求 管 理 有了项目的初步需求，就必须处理好开发过程中不可避免的来自客户、管理层、营销部门、开发团队以及其他群体的变更请求。 定义需求变更控制过程 建立一个用于提议、分析和解决需求变更的过程。 成立变更控制委员会 可授权由涉众组成的小组作为变更控制委员会(CCB)来接收需求变更的请求。 分析需求变更的影响 对影响进行分析有助于CCB做出明智的业务决策。 建立基线和控制需求文档的版本 基线是由已经被提交到一个指定版本中的实现的需求组成的。 基线是软件文档或源码(或其它产出物)的一个稳定版本,它是进一步开发的基础.当基线形成后,项目负责人需要通知相关人员基线已经形成,并且哪儿可以找到这一基线的版本.这个过程可被认为内部的发布.  3.6 需 求 管 理 维护需求变更的历史记录 记录需求规格说明变更的日期、变更的内容、变更的实施者和原因。 跟踪每项需求的状态 建立一个数据库，为每一项功能需求保存一条记录。 衡量需求的稳定性 记录已设为基线的需求数，以及每周提议和批准的需求的变更(增加，修改，删除)数。 使用需求管理工具 商业需求管理工具可用于在数据库中存储各种类型的需求。 创建需求跟踪矩阵 建立一个表，把每项功能需求和实现它的设计和代码部分、验证它的测试部分联系起来。 3.7 项 目 管 理 软件项目管理方法和项目的需求过程密切相关。应根据需要实现的需求来规划项目资源、进度和承诺。 选择合适的软件开发生命周期 组织应该定义多种开发生命周期，以适应不同的项目类型和不同程度的需求不确定性(McConnell 1996)。 根据需求制订项目计划 当范围和详细的需求变得清楚时，应反复斟酌项目的计划和进度表。 3.7 项 目 管 理 需求变更时重新讨论项目承诺 将新的需求合并到项目中时，应估计一下你是否仍然可以利用可用资源兑现当前的进度和质量承诺。 管理与需求相关的风险以及编写风险文档 确定与需求相关的风险并将它们编写成文档是项目风险管理活动的一部分。 跟踪需求工程的投入 记录下你的团队在需求开发和管理活动上投入的工作量。 从其他项目的需求工程中积累经验 组建一个学术研究组织专门管理项目回顾(也称为项目的审阅)以收集有价值的信息。 3.8 开始新实践 表3.2将本章中描述的需求工程方法，按照对大多数项目的相对影响以及实现的相对难度进行分组。 3.9 需求开发过程 图3.1 需求开发是一个迭代的