软件项目的需求开发和管理.doc

1 14 摘摘 要要 需求开发与管理是软件项目中一项十分重要的工作 据调查显示在众多失 败的软件项目中 由于需求原因导致的约占到 45 因此 需求工作将对软件 项目能否最终实现产生至关重要的影响 如何从各种各样的应用专业领域中特 别是直接从最终用户处捕获需求 并完整 准确地予以描述与分析 需求工程 成为研究的热点之一 本文通过对需求工程的基本概念 需求开发和管理中的主要风险和对策进 行研究和总结 希望在实践中加以应用 真正做好需求的开发和管理工作 关键字 软件项目 需求工程 需求分析 需求开发 需求管理 范围管 理 范围变更控制 2 14 目目 录录 1软件需求和需求工程软件需求和需求工程 3 1 1软件需求的基本概念 3 1 2软件需求的重要性 3 1 3需求工程的基本概念 4 1 4需求开发过程域 4 1 5需求管理过程域 5 1 6需求工程的一些感悟 5 2需求开发和管理的主要风险需求开发和管理的主要风险 6 3需求开发和管理的主要对策需求开发和管理的主要对策 6 3 1建立需求开发和管理工作机制需考虑的几个因素 7 3 2需求开发和管理流程 7 3 2 1需求调查 7 3 2 2细化用户需求 8 3 2 3撰写需求说明书 8 3 2 4需求确认 9 3 2 5需求跟踪 10 3 2 6需求变更控制 10 4总结总结 13 3 14 软件项目的需求开发和管理软件项目的需求开发和管理 1软件需求和需求工程软件需求和需求工程 1 1 软件需求的基本概念软件需求的基本概念 在 IEEE 软件工程标准词汇表 1997 年 中定义软件需求为 1 用户解决问题或达到目标所需的条件或能力 2 系统或系统部件要满足合同 标准 规范或其它正式规定文档所需 具有的条件或能力 3 一种反映上面 1 或 2 所描述的条件或权能的文档说明 实通俗的 讲 需求 就是用户的需要 它包括用户要解决的问题 达到的目 标 以及实现这些目标所需要的条件 它是一个程序或系统开发工 作的说明 表现形式一般为文档形式 所以我们可以理解 软件需求来源于用户的一些 需要 这些 需要 被分 析 确认后形成完整的文档 该文档详细地说明了产品 必须或应当 做什么 1 2 软件需求的重要性软件需求的重要性 软件需求是整个产品链的源头 需求工作的优劣将直接影响到产品的设计 生产 销售和维护的全过程 就像一条河流 如果源头被污染了 那么整条河 流也就被污染了 Frederick Brooks 在他的经典文章 No Silver Bullet 是这样描 述需求的重要性的 开发软件系统最困难的部分就是准确说明开发什么 最困 难的概念性工作是编写出详细的需求 包括所有面向用户 面向机器和其它软 件系统的接口 此工作一旦做错 将会给系统带来极大的损害 并且以后对它 修改也极为困难 4 14 1 3 需求工程的基本概念需求工程的基本概念 1 把所有与需求直接相关的活动通称为需求工程 2 需求工程中的活动可分为两大类 一类属于需求开发 另一类属于需求 管理 3 需求工程的结构图 图 1 需求工程结构图 1 4 需求开发过程域需求开发过程域 1 需求开发的目的是通过调查与分析 获取用户需求并定义产品需求 2 需求调查的目的是通过各种途径获取用户的需求信息 原始材料 产 生 用户需求说明书 3 需求分析的目的是对各种需求信息进行分析 消除错误 刻画细节等 常见的需求分析方法有 问答分析法 和 建模分析法 两类 4 需求定义的目的是根据需求调查和需求分析的结果 进一步定义准确无 误的产品需求 产生 产品需求规格说明书 系统设计人员将依据 产品需求规格说明书 开展系统设计工作 5 14 1 5 需求管理过程域需求管理过程域 1 需求管理的目的是在客户与开发方之间建立对需求的共同理解 维护需 求与其它工作成果的一致性 并控制需求的变更 2 需求确认是指开发方和客户共同对需求文档进行评审 双方对需求达成 共识后作出书面承诺 使需求文档具有商业合同效果 3 需求跟踪是指通过比较需求文档与后续工作成果之间的对应关系 建立 与维护 需求跟踪矩阵 确保产品依据需求文档进行开发 4 需求变更控制是指依据 变更申请 审批 更改 重新确认 的流程处理 需求的变更 防止需求变更失去控制而导致项目发生混乱 1 6 需求工程的一些感悟需求工程的一些感悟 1 不论是合同项目还是自主研发的产品 都必须开展需求开发和需求管理 活动 2 开发者对待需求工程的态度可分 被动型 主动型 和 领先型 三种 只有后两种才有可能开发出成功的产品 a 被动型 是指开发者被动地对待需求工程中的各项活动 能少干则 少干 能偷懒则偷懒 他们认为需求是用户的事情而不是自己的事 情 开发过程中经常发生需求变更 导致产品迷失方向 不是半途 而废就是陷入半死不活的状态 b 主动型 是指开发者积极地开展需求工程中的各项活动 他们把获 取准确的需求当作自己的职责 会想尽一切办法克服需求开发和需 求管理过程中的困难 而不是找借口推卸责任 俗话说 良好的开 端是成功的一半 主动型 需求工程是开发成功产品的必备条件 c 领先型 是需求工程的最高境界 开发者发掘了连用户自己都没有 意识到的需求 导致用户跟着新产品跑而不是新产品围着用户转 这叫引导消费 需求工程做到这个份上 才能使产品立于不败之地 长盛不衰 6 14 2需求开发和管理的主要风险需求开发和管理的主要风险 由于需求分析的参与人员 业务模式 投资 时间等客观因素的影响和需 求本身具有主观性和可描述性差的特点 因此 需求分析工作往往面临着一些 潜在的风险 这些风险主要表现在 1 用户不能正确表达自身的需求 这种情况往往会增加需求分析工作难 度 分析人员需要花费更多的时间和精力与用户交流 帮助他们梳理 思路 搞清用户的真实需求 2 业务人员配合力度不够 有的用户日常工作繁忙 他们不愿意付出更 多的时间和精力向分析人员讲解业务 这样会加大分析人员的工作难 度和工作量 也可能导致因业务需求不足而使系统无法使用 3 用户需求的不断变更 由于需求识别不全 业务发生变化 需求本身 错误 需求不清楚或对应政策法规发生了变化等原因 需求在项目的 整个生命周期都可能发生变化 一旦发生了需求变化 就不得不修改 设计 重写代码 修改测试用例 调整项目计划等等 需求的变化就 像是万恶之源 为项目的正常的进展带来不尽的麻烦 4 忽略了用户的特点分析 分析人员往往容易忽略了系统用户的特点 系统是由不同的人使用其不同的特性 使用频繁程度有所差异 使用 者受教育程度和经验水平不尽相同 如果忽略这些的话 将会导致有 的用户对产品感到失望 3需求开发和管理的主要对策需求开发和管理的主要对策 首先需要建立一个有效的工作机制 只有建立了工作机制 才能保证需求 工作按照既定方案执行 需求开发和管理的参与者才会在一种有序的状态下工 作 其次才是充分运用工作机制和个人能力去获取问题 分析问题 编写需求 文档和进行需求管理 7 14 3 1 建立需求开发和管理工作机制需考虑的几个因素建立需求开发和管理工作机制需考虑的几个因素 1 抓住决策者最迫切和最关心的问题 引起重视 用户方决策者对项目的 关心重视程度是项目能否顺利开展的关键 决策者的真实意图也是用户 方的最终需求 因此 在开发过程中要利用一切机会了解决策者关心的 问题 同时也要引导他们了解和重视项目的开发 当决策者认识到项目 的重要性时 需求分析工作在人力 物力 时间上就有了保障 2 建立良好的沟通环境和氛围 分析人员与用户沟通的程度关系到需求分 析的质量 因此建立一个良好的沟通氛围 处理好分析人员与用户之间 的关系显得尤其重要 3 需求质量控制要制度化 需求的变化是软件项目不可避免的事实 因此 需求质量控制是一项艰苦的工作 要保证该项工作的顺利实施 就必须 有制度保证 这个制度可以在项目质量控制方案中制定 该方案主要是 具体化 定量化的描述用户要求 形成全面 一致 规范的软件需求分 析规格说明书 明确需求分析规格说明书的工作程序和要素 规范开发 活动 为后续软件设计 实现 测试 评审及验收提供依据 3 2 需求开发和管理流程需求开发和管理流程 3 2 1 需求调查需求调查 1 首先 需求分析员起草需求调查问题表 将调查重点锁定在该问题 表内 否则调查工作将变得漫无边际 问题表可以是层次化的 随 着调查的深入 问题表将不断地被细化 问题表应当以 选择题 和 是非题 为主 2 其次 需求分析员应当确定需求调查的方式 例如 与用户交谈 向用户提问题 向用户群体发调查问卷等 还可以从用户的工作流 程 相关文档以及行业标准 规则中提取需求 分析已经存在的同 类软件产品 提取需求 8 14 3 最后 需求分析员与被调查者建立联系 确定调查的时间 地点 人员等 进行需求调查 3 2 2 细化用户需求细化用户需求 根据用户需求调查 对用户的需求进行细化 对比较复杂的用户需求进 行建模分析 以帮助软件开发人员更好地理解需求 例如采用 Rational 的 Rose 工具进行需求的建模分析 3 2 3 撰写需求说明书撰写需求说明书 需求分析员按照指定的文档模板撰写 需求说明书 需求说明书 的 参考模板如下 9 14 图 2 需求说明书 参考模板 3 2 4 需求确认需求确认 需求确认是指开发方和客户方共同对 需求说明书 进行评审 双方对需 求达成共识后作出承诺 需求确认包括两方面的工作 需求评审 和 需求承诺 1 需求评审 对需求的必要性和可行性进行分析 确定需求文档 2 需求承诺 开发方和客户方的对通过了正式技术评审的 需求说明书 做出承诺 按照 变更控制规程 执行 明确指出需求的变更将导致双方 10 14 重新协商成本 资源和进度等 3 2 5 需求跟踪需求跟踪 需求跟踪的目的是建立与维护 需求 设计 编程 测试 之间的一致性 确保所有的工作成果符合用户需求 需求跟踪有两种方式 1 正向跟踪 检查 需求说明书 中的每个需求是否都能在后继工作成果 中找到对应点 2 逆向跟踪 检查设计文档 代码 测试用例等工作成果是否都能在 需 求说明书 中找到出处 正向跟踪和逆向跟踪合称为 双向跟踪 不论采用何种跟踪方式 都要建 立与维护需求跟踪矩阵 需求跟踪矩阵保存了需求与后继工作成果的对应关系 3 2 6 需求变更控制需求变更控制 3 2 6 1需求变更的原因需求变更的原因 在软件项目中 变更可能来自方案服务商 客户或产品供应商等 也可能 来源于项目组内部 虽然需求变更的表现形式千差万别 但究其根本不外乎以 下几种原因 1 范围没有圈定就开始细化 细化工作是由需求分析人员完成的 一般是 根据用户提出的描述性的 总结性的短短几句话去细化的 提取其中的 一个个功能 并给出描述 正常执行时的描述和意外发生时的描述 当细化到一定程度后并开始系统设计时 范围会发生变化 那细节用例 的描述可能就有很多要改动 2 没有指定需求的基线 3 没有良好的软件结构适应变化 11 14 3 2 6 2如何控制需求变更如何控制需求变更 为了将项目变更的影响降低到最小 就需要采用项目范围变更控制方法 进行项目范围变更控制的主要依据是范围管理计划 变更请求和提供了项目执 行状况信息的绩效报告 按照现代项目管理的概念 一个项目的生命周期分为 启动 计划 执行 监控 收尾五个过程组 范围变更的控制不应该只是项目 实施过程考虑的事情 而是要分布在整个项目生命周期的全过程 1 项目启动 计划阶段的变更预防 对于任何项目 变更都无可避免 也无从逃避 只能积极应对 这个应对应该是从项目启动的需求分析 阶段就开始了 如果需求做得好 文档清晰且又有客户签字 那么后 期客户提出的变更就超出了合同范围 需要另外收费 这个时候千万 不能手软 这并非要刻意赚取客户的钱财 而是不能让客户养成经常 变更的习惯 否则后患无穷 2 项目执行 监控阶段的需求变更 成功项目和失败项目的区别就在于 项目的整个过程是否是可控的 项目经理应该树立一个理念 需求 变更是必然的 可控的 有益的 项目执行 监控阶段的变更控制需 要做的是分析变更请求 评估变更可能带来的风险和修改基准文件 3 项目收尾阶段的总结 能力的提高往往不是从成功的经验中来 而是 从失败的教训中来 项目总结工作应作为现有项目或将来项目持续改 进工作的一项重要内容 同时也可以作为对项目合同 设计方案内容 与目标的确认和验证 项目总结工作包括项目中事先识别的风险和没 有预料到而发生的变更等风险的应对措施的分析和总结 也包括项目 中发生的变更和项目中发生问题的分析统计的总结 3 2 6 3需求变更的处理流程需求变更的处理流程 需求变更既然不可避免 那么就必须有一套规范的处理流程 范围变更控 制参考流程图如下 12 14 图 3 范围变更控制参考流程图 1 提交变更请求 项目的任何干系人均可提交变更请求 通过将变更请求状 态设置为已提交 变更请求被记录到变更请求追踪系统中并放置到变更控 制委员会 CCB 复审队列中 2 复审变更请求 此活动的作用是复审已提交的变更请求 在 CCB 复审会 议中对变更请求的内容进行初始复审 以确定它是否为有效请求 如果是 则基于小组所确定的优先级 时间表 资源 努力程度 风险 严重性以 及其他任何相关的标准 判定该变更是在当前发布版的范围之内还是范围 之外 确认重复或拒绝 如果怀疑某个变更请求为重复的请求或已拒绝的无效请 求 例如 由于操作符错误 无法重现 工作方式等 将指定一个 CCB 代表来确认重复或已拒绝的变更请求 如果需要的话 该代表还从提交者 处收集更多信息 3 更新变更请求 如果评估变更请求时需要更多的信息 或者如果变更请求 13 14