需求变更控制.ppt

需求分析的几个问题 需求分析的任务 与用户沟通获取需求的方法 需求工程 分析建模 软件原型 需求管理 什么是软件需求 IEEE软件工程标准词汇表(1997)将需求定义为： (1)用户解决问题或达到目标所需的条件或能力。 (2)系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。 (3)一种反映上面（1）或（2）所描述的条件或能力的文档说明。 其他几种关于“需求”的定义： 需求是用户所需要的并能触发一个程序或系统开发工作的说明； 需求是从系统外部能发现系统所具有的满足于用户的特点、功能及属性等； 需求是指明必须实现什么的规格说明。它描述了系统的行为、特性或属性，是在开发过程中对系统的约束。 有哪些层次的软件需求 业务需求（business requirement）：反映了组织机构或客户对系统或产品高层次的目标要求，它们在项目视图与范围文档中予以说明。 用户需求（user requirement）：描述了用户使用产品必须要完成的任务，可在用例模型或方案脚本中予以说明。 功能需求（functional requirement）定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。 非功能需求（non-functional requirement）：是从各个角度对系统的约束和限制，反映了应用对软件系统质量和特性的额外要求。 过程需求：有交付、实现方法和标准等需求； 产品需求：包含性能、可用性、实用性、可靠性、可移植性、安全必威体育官网网址性、容错性等方面的需求； 外部需求：有法规、成本、操作性等需求。 软件需求各组成部分之间的关系 什么时候进行需求分析 项目的早期阶段？ 贯穿于整个软件开发过程的需求活动 导致需求错误的原因有哪些1 缺乏足够的用户参与： 客户经常不明白为什么收集需求和确保需求质量需花费那么多功夫，开发人员可能也不重视用户的参与。 可能原因：与用户合作不如编写代码有意思；开发人员觉得已经明白用户的需求了。 用户需求不断增加： 在开发过程中，用户需求经常发生变化，不断的变更会使其整体结构越来越乱，整个程序也难以理解和维护。 在项目的开始对项目视图、范围、目标、约束限制和成功标准给予明确说明，并将此说明作为评价需求变更和新特性的参照框架。 需求模棱两可： 不同的人对需求说明产生了不同的理解，或者同一个人能用不止一个方式来解释某项需求说明。 返工耗费开发总费用的40%，而70%～85%的重做是由于需求方面的错误引起的，它是需求规格说明中最严重的问题。 组织不同的人员从不同的角度审查需求。 导致需求错误的原因有哪些2 添加不必要的特性： 开发人员力图增加一些“用户欣赏”但需求规格说明中并未涉及的新功能，然而常常是用户并不认为这些功能性很有用。 开发人员应当为客户构思方案，并为他们提供一些具有创新意识的思路，具体提供哪些功能要在客户的需要和允许时限内的技术可行性之间求得平衡。 规格说明过于简单： 客户往往不明白需求分析的重要性，只是提供一份十分简略的规格说明，仅涉及产品概念上的内容，然后让开发人员在项目进展中去完善，从而导致开发人员先建立产品结构再完成需求说明。 忽略了用户分类： 大多数产品是由不同的人使用其不同的特性，使用频繁程度也有所差异，使用者受教育程度和经验水平也不尽相同。 在项目早期就针对所有这些主要用户进行分类。 参与需求分析的人 系统分析师、需求阐释者、客户代表、用户代表、开发方领导、项目经理、架构设计师、领域专家、财务人员、市场人员、软件质量保证（SQA，Software Quality Assure）人员、程序员、测试人员、部署人员、技术文档编写人员、培训人员等。 需求分析的场所 调研时，在客户现场 编纂软件需求规约文档时，可以在开发单位 复审相关的需求文档时，根据需要来安排 如何进行需求分析 需求分析的目的与准则 目的 准确地回答“系统必须做什么?”这个问题。 对目标系统提出完整、准确、清晰、具体的要求。 准则 必须理解并描述问题的信息域，根据这条准则应该建立数据模型。 必须定义软件应完成的功能，这条准则要求建立功能模型。 必须描述作为外部事件结果的软件行为，这条准则要求建立行为模型。 必须对描述信息、功能和行为的模型进行分解，用层次的方式展示细节。 需求分析的任务1 确定对系统的综合要求 功能需求：划分出系统必须完成的所有功能。 性能需求：指定系统必须满足的定时约束或容量约束，通常包括速度(响应时间)、信息量速率、主存容量、磁盘容量、安全性等方面的需求。 可靠性和可用性需求：定量地指定系统的可靠性，它量化了用户可以使用系统的程度。 出错处理需求：说明系统对环境错误应该怎样响应，这类错误并不是由该应用系统本身造成的。 接口需求：接口需求描