软件项目的管理—需求的管理.pptVIP

* 关键技巧 3：定义系统 定义系统指的是解释涉众需求，并整理为对要构建系统的意义明确的说明。在系统定义初期，需要决定需求的构成、文档格式、语言规范、需求等级、请求优先级和预计工作量、技术和管理风险以及系统规模等。系统定义活动还可包括与最关键的涉众请求直接联系的初期原型和设计模型。 系统定义的结果是用自然语言和图解方式表达的系统说明。 * 关键技巧 4：管理系统规模 项目规模由分配给它的需求集定义。管理项目规模，使之适合可用资源（时间、人力和资金），是成功管理项目的关键。管理规模是一个持续的活动，需要迭代式和递增式开发，这就将项目细分为更易于管理的若干个小部分。 产品/项目推介人应能够代表组织拒绝那些超出可用资源的规模变更，也应有相应能力扩展资源以适应扩大的规模。 * 关键技巧 5：改进系统定义 对高层系统定义达成一致并充分理解了系统初始规模后，投入资源改进系统定义不仅有可能，而且也是经济的。 改进系统定义包括两个重要的考虑事项：制定更详细的高层系统说明和验证系统是否符合涉众需要，是否按说明运行。 * 关键技巧 6：管理变更的需求 不管多么认真地定义需求，需求终将改变。实际上，一些变更是非常值得的！ 这意味着、团队需要与涉众保持密切联系。能否适应变更需求是评测团队的涉众敏感度和运作灵活性的一个尺度 - 敏感度和灵活性都是对项目成功有贡献的团队特征。 变更不是敌人，而没有管理的变更才是真正的敌人。 管理需求变更包括这样一些活动：设立基线、追踪每个需求的历史、确定哪些依赖关系值得追踪、在相关项之间建立可追踪关系以及维护版本控制等。 * 产生不合格需求的原因 产生不合格的需求说明的原因 无足够的用户参与，原因 感到与用户合作不如编写代码有意思 因为开发人员觉得已经明白用户的需求了 用户需求的不断增加 模棱两可的需求 不必要的特性 过于精简的规格说明 忽略了用户分类 不准确的计划 * 结语：只有一个需求 实际需求 程序员如此编码 客户如此描述 安装程序 商业顾问如此诠释 技术支持 项目经理如此理解 项目文档如此编写 分析人员如此设计 客户投资 * 本 章 结 束 　数据流图是结构化分析方法中使用的工具,它以图形的方式描绘数据在系统中流动和处理的过程，由于它只反映系统必须完成的逻辑功能，所以它是一种功能模型。 * * 系统开发团队之所以管理需求，是因为他们想让项目获得成功。满足项目需求即为成功打下了基础。若无法管理需求，达到目标的几率就会降低。 * 功能性需求 该平台需要解决如下问题： 移动协同用户（成员）、任务和动作的知识框架表示 移动资源的发现机制 计算资源的调度和计算迁移机制 移动网络不稳定的处理机制(协作非正常中断的处理机制) 移动状态下监控远程无线或有线系统协作用户状态； 多个组（用户）实时协作机制； 大流量下移动网络的拥塞与协议优化处理 移动安全机制 移动协同业务共性问题（如图形标绘感知） 移动协同服务支撑平台的开放性、系统平台无关性和应用无关性 * 软件工程重视的是过程能力，如果不能严格地确保软件过程的每一个环节都被不折不扣的执行，软件过程通常很难成功。需求跟踪过程也要遵循这一原则 * 特别地，也可以产生从阶段项可以到Use Case需求项的回溯跟踪矩阵,带红线的箭头表示suspect(可疑)的跟踪 ，（原始需求，系统需求），（系统需求，SRS）、（需求，测试）。 * * * 如果您正在开发一个在您公司内部使用的信息系统，那么在开发团队中应包括具有最终用户经验和业务领域专业知识的人员。讨论一般从业务模型一级开始，而不从系统一级开始。如果正在开发一个要在市场上出售的产品，那么您可以充分调动营销人员，以便更好地了解该市场中用户的需要。 * 我们使用了“说明”这个词而没有用“文档”，是为了避免在后者常见的使用中发现的固有缺陷。说明可以是书面文档、电子文件、图像或用于表达除系统本身以外的系统需求的任何表示方式。 原则 55：在编写比较正式的模型前，先使用自然语言进行编写 在第一次编写正式模型时，往往要用自然语言描述模型，而不是直接得到解决方案系统。请考虑以下示例： 要打长途电话时，用户应该拿起电话。系统将回应拨号音。用户拨打号码“9”，系统回应一种特殊的拨号音... 系统有四种状态：空闲、拨号音、特殊拨号音和连接状态。要使系统从空闲状态转向拨号音状态，请拿起电话。要从拨号音状态转到特殊拨号音状态，请拨号码“9”。 注意在后一个例子中，文字未起任何帮助读者理解的作用。 * 使用需求属性（如优先级、工作量和风险）作为协商应包含需求的基础，对管理规模而言是相当有用的技巧。侧重于属性，而不是需求自身，将减少通常对敏感问题的争论。 这也有助于培养小组负责人的谈判技巧，还有助于在项目中为组织培养推介人