数据库设计贯通-需求工程.ppt

不做需求规格说明转化或缺乏较好的需求规格说明转化规范，将造成不同程度的需求说明丢失 * 恰当地使用图形符号： 现代建模工具如Rose有非常丰富的图形符号和文字标注，能很好地表达模型的细节。要注意的是：在建模时使用花样过多的图形符号或文字意味着模型表示的复杂化，将使开发人员更难掌握，而且使图形文档更加杂乱。 世上不存在一个包罗万象的图——它能完整地描述需求。需求建模不可能取代文字描述。在需求文档中，文字描述是第一重要的，建模主要是起分析、解释作用。建议将模型存放在需求文档的附录中，便于正文引用。 * 可测试性： 从测试的角度看，很多需求说明是不可测的，这就要求重写这些需求说明，直到可测性得到保证。测试组要求的往往是简洁且准确的说明，而这恰恰是开发人员做得不够好的几个方面之一；另一方面，目前无论是国内的市场还是企业，对测试人员都不够重视，软件企业很少招聘测试人员。实际上，优秀的软件测试人员对保证软件质量非常重要，一般来说，测试部门的经理应该由具有软件开发经验、做过软件开发管理且有相当测试经验的资深人员担任。处理好设计和测试人员的关系是众多国内软件企业应该进一步重视的问题 * * 稳定性和可扩展性之间存在辨证的关系 如果每次变化都导致体系结构发生大的变动，那简直就是“伤筋动骨”，这样的体系结构无疑是败笔之作。（例如房屋装修） * 评审：由项目经理邀请专家和客户（用户和客户）进行 * 需求评审的一个通病是“虎头蛇尾”。需求评审的确乏味，也比较费脑子。刚开始评审时，大家都比较认真，越到后头越马虎。 需求评审涉及的人员可能比较多，有些时候让这么多人聚在一起花费比较长的时间开会并不容易（例如有些人可能出差在外，有些人可能事务缠身）。没有必要把所有事情挤在一块做，需求开发是循序渐进的过程，需求评审也可以分段进行。这样每次评审的时间比较短，参加评审的人员也少一些，组织会议就比较容易。 开评审会议时经常会“跑题”，导致评审效率很低。有时话匣子一打开后关不上，大家越扯越远，结果评审会议变成了聊天会议。主持人应当控制话题，避免大家讨论与主题无关的东西。 开评审会议时经常会发生争议。适当的争议有利于澄清问题，比什么东西都一致赞成要好。然而当争议变为争吵时就坏事了，争吵不仅对评审工作没有好处，而且会无意中伤害同事们的感情。 人们在很多时候分不清楚自己究竟是“坚持真理”还是“固执己见”。毫不妥协或者轻易妥协都不是好办法。我们应当养成良好的习惯：不要一棍子打死异己的观点，尝试着让自己站在他人的立场思考问题，这样你会找到比较满意的答案 * 需求承诺的“八股文”如下： 本《产品需求规格说明书》建立在双方对需求的共同理解基础之上，我同意后续的开发工作根据该《产品需求规格说明书》开展。如果需求发生变化，我们将按照“变更控制规程”执行。我明白需求的变更将导致双方重新协商成本、资源和进度等。 甲方签字 乙方签字 人们在作出承诺之前务必要认真阅读文档，一定要明白签字意味着什么。 * 需求变更控制过程中最难办的事情是莫过于“拒绝客户提出的需求变更请求”。通常情况下开发方是不敢得罪客户的，但是无原则地退让将使开发小组陷入困境。解决这个问题最好的办法是事先建立“游戏规则”： 开发方与客户方达成“事不过三”的约定（符合中国人的习惯），即允许客户变更三次需求；如果客户第四此变更需求，开发方有权拒绝，除非客户愿意补偿开发方的损失。 如果事先没有“游戏规则”的话，开发方需要一些社交技巧来减缓矛盾。例如建议在开发该产品新版本时修改需求。 * 8. 什么是好的需求规格说明书 8.3 无二义性 8.4 一致 8.5 必要 跟踪每个需求回溯到出处，如用例，需求的最初描述，其他用户的意见。如果你不能标识出处，可能需求没有真正的必须 8. 什么是好的需求规格说明书 8.6 完备 不应该遗漏要求和必需的信息 8.7 可实现 看你是否能够做出测试计划，设计出测试用 在需求分析阶段应该有一个开发人员参与 8.8 可验证 8. 什么是好的需求规格说明书 8.9 确定优先级 如果所有的需求同等重要，那么在开发中的预算削减，计划超时或组员离开导致新的需求及变更时，项目经理将不能起到作用 例： 高优先权：必须体现在下一个产品版本中 中优先权：表明需求是必须的，但是如果需要可以推迟到晚一些的产品版本中 低优先权表明有它很好，但如果没有充足的时间或资源，它可以被放弃 8. 什么是好的需求规格说明书 8.10 阐述“做什么”而不是“怎么做” 避免在需求说明书中嵌入设计 把软件划分成若干模块 给每个模块分配功能 描述模块间的信息流程或者控制流程 选择数据结构 9 例 例1．“产品应在不少于每60秒的正常周期内提供状态信息” 不完备：状态信息是什么，如何显示给用户 不清楚：我