软件需求讲义-第五部分.ppt

实现需求管理自动化 为需求管理工具定义项目需求。 最重要的功能是什么； 是否要与其它使用的工具集成以及通过Web远程数据处理是否重要； 决定是使用数据库存储全部数据还是只存储一部分； 列出影响决策的10 ~ 15个因素。 既要有主观的也要有客观的因素（如定制能力、有效性及GUI的效率）； 对上述步骤中列出的因素打分（总计100分）。 对更重要的因素可以打更高的分； 实现需求管理自动化（Cont.） 获得有关可用的需求管理工具的必威体育精装版信息，根据影响决策的因素对候选工具排序。 对客观因素的评分只有在使用每个工具后才能进行。开发商的展示可能会增加一些感性认识。但展示往往不全面，所以最好还是亲自使用一下（几个小时）。 根据给每个因素的加权值来计算每个候选工具的得分，从而确定最合适的产品。 从候选工具的其他用户那里获得一些体会 。 从候选工具中前三名的开发商处得到评估拷贝 。 最好用一个实际的项目来评估工具 。 经过对排名、许可权费、开发商后续支持费、当前用户的输入、工作小组主观印象等的考虑之后做出决定。 Rational Rose、PowerDesign的区别 ROSE：现在的版本中已经加入数据库建模的功能。ROSE主要是在开发过程中的各种语义、模块、对象以及流程，状态等描述比较好，主要体现在能够从各个方面和角度来分析和设计对系统的代码框架生成有很好的支持。但对数据库的开发管理和数据库端的迭代不是很好。 PowerBuilder：数据库的建模。如果使用UML分析，它的优点是生成代码时对Sybase的产品PowerBuilder的支持很好（其它UML建模工具则没有或者需要一定的插件），其他面向对象语言如 C++，Java，VB,C#等支持也不错。 其他：Visio、Enterprise Architect、 RequisitePro。 作业 练习五 1,2,3 学习附录A 软件需求规格说明书 * 这里所指的涉众包括客户方面的项目负责人和用户，开发方面的需求分析人员和项目管理者。 * 基线管理 基线：已经通过正式评审和批准的某规约或产品，它可以作为进一步开发的基础，并且只能通过正式的变化控制过程的改变。[IEEE] 基线是一个软件配置管理的概念 。 在软件工程的范围内，基线是软件开发中的里程碑，其标志是有一个或多个软件配置项的交付，且已经经过正式技术评审而获得认可。 需求基线的核心：就是按基线进行控制。 基线管理中几个需要注意的问题： 基线一旦建立，变更虽然可以进行，但是必须应用特定的、正式的规程来评估和验证每个变化。 用户项目组达成共识、并按需求属性建立需求数据库，可认为是完成建立需求基线的基本条件。 配置管理组或委员会（CCB）按照需求基线，对整个项目的进程进行控制和把握 。 需求状态的变化 经过需求获取、分析、处理、验证阶段达成共识的需求。 需求状态变化需首要关注被拒绝和被丢弃的需求。 第22章 需求风险管理 与需求有关的风险。 用于降低风险发生的可能性或减轻风险发生给项目带来的影响的方法。 周期性的风险跟踪能使管理人员保持对风险危害变化的了解。 与需求有关的风险 无足够用户参与 （不重视用户参与） 用户需求的不断增加 （用户的贪婪） 模棱两可的需求 （往往导致返工） 不必要的特性 （画蛇添足） 过于精简的规格说明 忽略了用户分类 （用户的能力、背景等的差异） 不准确的计划 评估需求风险 （一） 从需求获取、分析、编写说明、验证和管理分析风险。 需求获取阶段 产品前景与范围 前景文档 需求开发所需时间 开发计划 需求规格说明的完整性和正确性 情景测试用例与原型 对革新产品的需求，有时容易忽略市场对产品的反馈信息 明确非功能需求 一定要使客户认可产品需求 关注未加说明的需求 把已有的产品作为需求基线 逆向工程的优缺 给出期望的解决办法 评估需求风险 （二） 需求分析阶段 划分需求优先级 带来技术困难的特性 （可行性分析） 不熟悉的技术、方法、语言、工具或硬件平台 需求规格说明 需求开发人员和客户对需求的不同理解会带来彼此间的期望差异，这将导致最终产品无法满足客户的要求。（模型和原型的方法从不同角度说明需求） 时间压力对待确定因素的影响 （deadline） 具有二义性的术语 glossary 需求说明中包括了设计 评估需求风险 （三） 需求验证 未经验证的需求评审 开发前确认避免返工。 评审的有效性 选择合适的评审，有经验的和无经验的。 需求管理 将项目前景与范围文档作为变更的参照，可以减少项目范围的不适当地延伸 需求变更过程 未实现的需求 扩充项目范围 风险管理的措施 明确你当前项目面临的一些与需求有关的风险，不要把当前的问题当作风险，一定要是那些