第3章_软件项目需求管理.pptVIP

第 3 章 软件项目需求管理 内容提要 3.1 软件项目需求管理概述 IEEE软件工程标准词汇表(1997年)中将需求定义为： 用户解决问题或达到目标所需的条件或能力(Capability)； 系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力； 一种反映上面(1)或(2)所描述的条件或能力的文档说明。 通过定义以下五项内容来确定一组完整的软件需求：系统的输入、系统的输出、系统的功能、系统的属性、系统环境的属性 软件需求各组成部分关系 业务需求（business requirement） 用户需求（user requirement） 功能需求（functional requirement） 非功能需求、软件需求规格说明（software requirements specification，SRS）等。 用户需求 通过自然语言、图表、图形等工具描述系统的外部行为，尽量避免涉及系统内部的设计特性，以便没有专业技术背景的用户能看懂。 使用自然语言描述用户需求可能出现的问题：描述困难、需求混乱 编写用户需求应遵守的几个原则：标准的格式、使用一致的语言、使用特殊文本、尽量避免专业术语 系统需求——功能需求 功能需求描述系统所应该提供的功能和服务，包括系统应该提供的服务、对输入如何响应及特定条件下系统行为的描述。有时，功能需求还包括系统不应该做的事情。功能需求取决于软件的类型、软件的用户及系统的类型等。 系统做什么？ 系统何时做什么？ 系统何时及如何修改或升级？ 系统需求——非功能需求 几个值得重视的问题 文档需求 需哪些文档？ 文档针对哪些读者？ 注意不要使用行话，就是计算机术语。需求分析最重要的是和用户沟通，可是用户多半不是计算机的专业人士，如果在需求分析中使用了行话，就会造成用户理解上的困难。 用户或人的因素 用户类型？ 各种用户熟练程度？ 需受何种训练？ 用户理解、使用系统的难度？ 用户错误操作系统的可能性？ 资源需求 软件运行时所需的数据、软件、内存空间等资源。 软件开发、维护所需的人力、支撑软件、开发设备等。 软件需求类型 在UP（统一过程）中，软件需求是根据FURPS+模型来分类的，其中FURPS的含义如下： Functional（功能性） Usability（可用性） Reliability（可靠性） Performance（性能） Supportability（可支持性） “+”是指一些辅助性的和次要的因素： Implementation（实现） Interface（接口） Operations（操作） Packaging(包装) Legal（授权） 软件需求质量评价 正确性 无歧义 完备性 一致性 根据重要性和稳定性分级 可验证性 可修改性 可跟踪性 可理解性 需求陷阱与解决办法 需求陷阱：软件的功能的确越来越强大，虽然在开发前期制定了开发计划，但是开发过程中经常激发更多想象，从而试图不断增加新的功能，这种追求完美的心理可能导致的后果就是产品始终出不来，永远处于开发期。 解决办法：锁定需求，限制功能，利用版本升级的原理，把功能分阶段实现，既保障产品的及时完成，又使小组产生成就感。 内容提要 3.2 需求开发和管理过程 一、需求过程所涉及的工作 需求工程——也叫做需求过程或需求阶段，包括需求开发和需求管理。 二、需求开发 需求开发又称之为需求定义，主要包括：需求获取、需求分析、需求处理（编写规格说明书）和需求验证四个阶段。 主要责任人：项目技术经理、项目系统组负责人或系统设计师。 项目经理的责任是关注这个阶段的过程和结果。 （一）需求开发操作矩阵 （二）需求获取 需求获取的主要目的是从宏观上把握用户的具体需求方向和趋势，了解现有的组织架构、业务流程、系统环境等，对任务进行分析、从而开发、捕获和修订用户的需求，以建立良好的沟通渠道和方式。 建立系统模型——确定系统的用户需求 软件开发的第一步并不是跑到客户那儿做什么软件需求调查，而是先要确定客户的业务目标，再围绕业务目标分析业务的环境与内容，同时最好能查找相关业务领域的书籍资料，较为全面地认识整个业务领域。 如果原有的业务流程或组织架构等本身存在问题，这时需要先进行业务重组，重新设计与改造业务，之后才在确定业务内容的基础上展开软件需求调查，显然这样做需求获取将会顺利得多（业务流程再造）。 需求获取——如何运用管理思想，优化业务流程 一是采用网络计算机这些新的技术手段，较之原先手工、电话等方式在信息的传递、信息的共享、数据的处理等方面将会带来新的方式，必将改变原有的业务流程。 另一方面就是根据对用户业务的理解，考虑是否可以运用先进的管理思想，比如MRPII、ERP、SCM、CRM、EIA、E-Business等等管理模型，进行现有业