瀑布模型需求分析.pptxVIP

瀑布模型 需求分析 提纲 需求过程 需求诱导 需求的特性 需求建模 需求和规格说明书 原型化需求 需求文档 确认和验证 举例 从客户引发需求 对需求进行建模 评审需求以确保其质量 文档化需求 如何做需求 需求诱导 需求分析和谈判 需求规约 系统建模 需求确认 需求管理 需求分析 需求(Requirement) 对期望行为的表达，处理 对象或实体 他们的状态 用于改变状态或对象特性的功能 需求仅理解客户的问题和需要，不考虑如何解决或实现 需求分析 基本任务是准确回答“系统必须做什么” 需求分析不是确定系统怎样完成它的工作，而仅仅是对目标系统提出完整、准确、清晰、具体的要求 需求有自己的过程 结果关系到工程的成败和软件的质量 构建软件系统最艰难的是准确决定要做什么。没有其他的概念性工作像建立详细的技术需求这样困难，包括所有对人的界面、对机器的接口、对其他系统的接口。如果它做错了，系统基本失败 需求分析很重要 31%的项目在完成前取消，9%项目按时在预算内交付（而小公司为16%） 失败原因 不完整的需求 13.1% 缺少用户的参与 12.4% 缺乏资源 10.6% 不切实际的期望 9.9% 缺乏行政支持 9.3% 改变需求和规格说明 8.7% 缺乏计划 8.1% 不再需要该系统 7.5% 修复错误的代价 需求过程 1 设计 5 编码 10 单元测试 20 交付后 200 获取需求的过程 系统分析员 需求分析员 如何做需求 需求诱导 需求分析和谈判 需求规约 系统建模 需求确认 需求管理 需求诱导 询问客户、用户和其他人：什么是系统或产品的目标？需要完成什么？系统或产品如何满足业务的需要？最终系统或产品如何使用？ 困难： 范围问题，边界未定义好或刻画了可能混淆的、不必要的技术细节，非简明、整体的系统目标 理解问题，用户不能完全理解问题领域，与系统工程师沟通不好，省略一些他们认为是“明显”信息，提出与其他客户的需要冲突或有歧义的需求 易变问题，需求随时间变化 影响需求的人 人员 作用 委托人 支付费用。最终的风险承担者，有最终决定权 客户 购买软件的人 用户 熟悉当前系统，并最终使用系统；特殊人群 领域专家 对软件必须自动化的问题很熟悉 市场研究人员 调研以确定未来趋势及潜在客户的需要的人 律师或审计人员 对政府、安全性和法律熟悉的人 系统工程师或其他专家 确保产品在技术和经济上可行 观点会冲突；需求分析员可理解每种观点并以反映每个参与者关注的方式获取需求 开发人员怎样看待用户 用户怎样看待开发人员 不知道他们想要什么 不理解操作需求 不能清楚地表明他们想要什么 不能将清晰陈述的需求转变为成功的系统 不能提供可用的需求陈述 对需求定义设置不现实的标准 提出太多的含有政治动因的需求 对于强调技术 立刻想要一切 总是迟到 不能保持进度 不能对合法变化的需要做出及时响应 不能对需求划分优先级 总是超出预算 不愿意妥协 总是说“不” 拒绝为系统负责任 试图告诉我们如何做我们的本职工作 未对开发项目全力以赴 要求用户付出时间和工作量，甚至损害到用户的主要职责 需求诱导 针对提议的系统评估业务和技术可行性 确定能帮助刻画需求和了解他们的组织偏爱的人员 定义系统或产品将放置的技术环境 确定“领域约束”(特定应用领域的业务环境约束) 定义一种或多种需求诱导方法 多人参加，从不同视角对需求进行定义，并确定每个要记录的需求的理由 确定有歧义的需求作为原型实现的候选 创建使用场景 需求类型 功能需求 功能 系统什么时候做什么 有多种操作模式么 必须执行什么计算或数据转换 对可能刺激的合适反应是什么 数据 输入、输出的格式应该是什么 在任何时间都必须保留任何数据么 设计约束 过程约束 需求类型 设计约束 物理环境 设备安置，一个地点还是多个 对环境有何限制，温湿度、电磁干扰 对系统规模可有限制 电源、供热、制冷上限制 对现有软件的结构导致编程语言有限制 接口 输入来自一个或多个系统 输出是否传送到一个或多个其他系统 输入/输出数据的格式是否预先制定 数据使用必须使用规定的介质 用户 谁使用 有几种类型用户 每类用户技术怎样 需求类型 过程约束 资源 构造系统需要哪些材料、人员或其他资源 开发人员应具有怎样的技能 文档 需要多少文档 文档是联机的、印刷的还是都要 每种文档针对哪些读者 标准 需要遵循什么标准 需求类型 质量需求 性能 有无执行效率、响应时间或吞吐量的约束 用什么方法测量上述约束 有多少数据需经系统处理 数据收发的时间间隔等 可用性和人的因素 每类用户需要什么样的培训 用户理解并使用系统的难易程度 系统需要在多大程度上防止用户误用系统 安全性 必须控制对系统或信息的访问么 每个用