德信无线标准软件过程TSSP-08-软件需求管理过程培训.ppt

xsdsd UI. Group / SW Depart. 德信无线通讯科技有限公司 2006-4-21 * Confidential 需求管理流程 曾 新 宇 (Eric Zeng) UI. Group / SW Depart. 提纲: 需求的概念 需求工作流程 需求管理 需求的收集 需求的评估 需求的实现 需求的跟踪 需求变更 1.需求的概念 需求包括业务需求、用户需求和功能需求。 业务需求（Business Requirement ）反映了组织机构或客户对系统、产品高层次的目标要求， 用户需求（User Requirement ）描述了用户使用产品必须完成的任务， 功能需求（Functional Requirement ）定义了开发人员必须实现的软件功能。 1.需求的概念(1) 1.需求的概念(2) 1.需求的概念(3) 需求包括业务需求、用户需求和功能需求。业务需求（Business Requirement ）反映了组织机构或客户对系统、产品高层次的目标要求，用户需求（User Requirement ）描述了用户使用产品必须完成的任务，功能需求（Functional Requirement ）定义了开发人员必须实现的软件功能。 NASA的软件开发过程中的概念，软件需求过程的标准是： 清楚(Clear) 完整(Complete) 一致(Consistent) 可测试(Testable) 其他的概念，如可跟踪的、可修改的等等。 1.需求的概念(4)_清楚 目前大多数的需求分析采用的仍然是自然语言（如果采用形式化语言的话，意味着客户在开发软件之前必须先进行形式化语言培训，这是不现实的）。 自然语言对需求分析最大的弊病就是它的二义性。所以尽量采用主语＋动作的简单表达方式。 需求分析中的描述让人看上去像是小孩子刚学习写作。 不要采用疑问句、修饰这些华丽的表达方式。 除了语言的二义性之外，主意不要使用行业术语。以免和用户沟通时造成用户理解上的困难。 例如银行的信用卡系统，可以描述软件需求为：银行的卡部管理信用卡，每张信用卡只属于一个帐户。信用卡有卡号、余额。一张信用卡有多笔的交易记录。 1.需求的概念(5)_完整 需求的完整性是非常非常重要的，如果出现需求遗漏就不得不返工。这仅仅是你的问题，更多的问题发生在用户那里，因为他们不知道该做些什么。 要做到需求的完整性是很艰难的一件事情，它涉及到需求分析过程的各方各面，贯穿了整个过程，从最初的计划制定到最后的需求评审。 1.需求的概念(6)_一致 简单的来说，就是用户需求必须和业务需求一致，功能需求必须和用户需求一致。 严格的遵守不同层次间的一致性关系，就可以保证最后开发出来的软件系统不会偏离最初的实现目标。 在实现过程中，我们还必须把一致性关系细化。比如说用户需求不能超出先前指定的范围。 1.需求的概念(7)_可测试 真正的测试开始于需求分析过程。需求分析是测试计划的输入和依据。这就要求需求分析是可测试的。 什么是可测试？ “我们要用新的系统完成报表自动化处理”，例如该需求就是不可测试的。报表包括哪些？自动化处理的标准是什么？这些在需求中都没有说明。因此这项需求是无法测试的，就是不具有可测试性。 前面的需求标准都是为了保证需求的可测试性。只有系统的所有需求是可以被测试的，才能够保证软件始终围绕着用户的需要，保证软件系统是成功的。大家真正在应用一些科学的方法的时候也应该记住，任何的方法都是为了保证软件的成功，不能偏离这个目标。 1.需求的概念(8)_写作 写作软件需求时应记在心上的原则： 保持句子和段落简短； 从开发者的立场来看，检查需求陈述是否足够明确； 努力找到一个适当的层次来写作； 检查是否有一个陈述表达了多个需求，将它们分开； 整个需求文档的写作都保持在一个一致的细节层次上； 避免陈述冗余的需求。 1.需求的概念(9) 用户需求与系统需求的区别 : 在许多开发中常常混淆用户与系统需求。 分析人员过分重视定义系统功能以至于忽略用户的想法；系统需求定义抽象的解决方案，而用户需求定义问题或系统对用户产生的结果。用户应该拥有用户需求并且应该使用他们能够理解的语言来描述；分析人员生成系统需求，它是对用户需求的直接响应。定义问题与解决方案需要不同的组织，如果混在了一起就会混淆用户与开发人员的需求，无法区分相应的责任。 非功能需求(隐性需求)也具有同样的特点。用户有非功能需求，如他们所要使用的系统的交付时间。在软件需