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