分析的任务与用户沟通获取需求的方法需求工程分析建模软.docVIP

分析的任务与用户沟通获取需求的方法需求工程分析建模软 需 求 分 析需 求 分 析 的 几 个 问 题需 求 分 析 的 任 务与 用 户 沟 通 获 取 需 求 的 方 法需 求 工 程 分 析 建 模 软 件 原 型需 求 管 理 什 么 是 软 件 需 求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 )人员、程序员、测试 人员、部署人员、技术文档编写人员、培训人员 等。需 求 分 析 的 场 所调研时,在客户现场编纂软件需求规约文档时,可以在开发单位复审相关的需求文档时,根据需要来安排如 何 进 行 需 求 分 析需 求 分 析 的 目 的 与 准 则目 的准确地回答“ 系统必须做什么?” 这个问题。对目标系统提出完整、准确、清晰、具体的要求。准 则必须理解并描述问题的信息域,根据这条准则应该建 立 数据模型。必须定义软件应完成的功能,这条准则要求建立功能 模型。必须描述作为外部事件结果的软件行为,这条准则要 求建立行