中科院需求工程 需求工程（第二讲）需求工程过程_.ppt

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 使用辩论结构 gIBIS 由Conklin在1989年开发 将辩论过程表示为一个超文本图 基本过程 标识观点 标识每个人可以作为位置来考虑的位置 将辩论论点以支持或反驳某个位置的形式连接进来 gIBIS辩论结构 使用辩论结构 Synoptic 由Easterbrooks在1991年开发 支持合作的面向任务的协商的工具 基本过程 让每个参与者将他们的概念模型外观化 找出这些模型之间的对应点 将不匹配的地方进行分类 为归结每个不匹配的地方产生侯选方案 使用预先存在的领域模型 Oz 由Robinson在1992年开发 使用预先存在的领域模型来比较冲突的视点 基本过程 识别视点（信念的集合） 通过标注一个目标和目的的领域模型来记录视点 领域将产品属性连接到目标 选择产品属性的组合，来最大化参与者的满意度 使用预先存在的领域模型 WinWin 由Boehm和同事们在90年代中期开发 显式地为每个参与者标识出赢的条件 结合质量需求和产品属性链的领域知识库 基本过程 为每个参与者输入赢的条件 为赢条件标识属性策略 为每个赢条件的每个策略确定副效果 手工归结不一致性 需求验证 需求审查 需求验证中的原型法 模型验证 需求测试 需求验证过程 需求分析 需求抽取阶段的“粗”需求 通常非形式化非结构化的表示 不完整、存在不一致 解决“我们得到了正确的需求吗？” 需求验证 检查需求文档，完整的系统需求 明显的不完整和不一致已经去掉 文档的表述符合规范 解决“我们是否把需求搞对了？” 需求验证过程：输入和输出 需求审查 阅读文档,识别错误和其它问题 检查确定的需求相关行为是否进行,进行得如何 需求审查的行为 模糊的需求 进一步澄清 需求不完整 补充缺失的需求 需求冲突 协商和冲突归结 不现实的需求 咨询需求相关者 修改或去掉这个 需求 需求审查表 可理解性 冗余性 完整性 二义性 一致性 组织结构 与标准的符合性 可跟踪性 组织审查的注意事项 规模 “足够的人，使得相关的经验都有” 最少：3（4如果写的人在的话） 最多：7（如果领导没有经验的话，可以少一些） 期限 不要超过2个小时 如果太长了注意力会漂移 输出 所有的审查员必须同意这个结果 接受；重新工作；重新审查 所有的发现都应该写下来 总结报告（为了管理） 问题的详细列表 范围 关注于一小部分的设计，而不要是整个事情 时间表 一旦作者完成了一件产品就开始检查它 不要太早 产品还没有准备好——发现作者已经意识到的问题 不要太晚 产品已经在使用——错误要该就要花费很大代价 目的 记住最大的好处是来自于固定这个过程 采集数据以帮助你下次不要犯同样的错误 审查指南 在审查之前 将形式的审查安排进项目规划中 训练所有的审查人 保证所有的出席人都要提前准备 在审查期间 审查产品，而不是它的作者 使意见是构造性的、专业的、以及和任务相关的 严格按照日程进行 领导必须防止拖延 限制辩论和反驳 记录下问题留着以后讨论，只识别问题，当时不要去试图解决它 全要写下来 在审查之后 审查这个审查过程 选择审查人 可能的候选人 审查方面的专业人员（比如，QA人员） 来自与作者同一个开发小组的人 因为有专业经验而被邀请的人 对产品有兴趣的人 有什么东西可以贡献的访问人员 来自组织中其它部门的人 要排除的人 负责审查作者本人的任何人（比如，产品线经理、等） 任何已经知道与其他审阅者有个人冲突的人 任何没有资格来做这件事的人 所有的管理人员 任何其出现会带来兴趣上的矛盾的人 将审查结构化 能够将审查结构化为不同的形式 经验的 依赖于审查人的经验 检查表 使用一个关于问题/观点的检查表 检查表被裁剪为文档的形式 主动审查（基于观点的阅读） 每个审查者从一个特定的目的来阅读，使用专门的问卷 不同的审查