第4章理解需求资料精要.pptVIP

需求模型的元素 4.6 协商需求 协调过程的目的是保证所开发的项目计划，在满足利益相关者要求的同时反应软件团队所处真实世界的限制（如时间、人员、预算） 最好能利益相关者和软件团队“双赢” 4.7 确认需求 模型元素创建后，需要检查一致性、是否有遗漏以及歧义性。 每项需求都和系统或产品的整体目标一致吗？ 所有的需求都已经在相应的抽象层上说明了吗？ 需求是真正必需的，还是另外加上去的，有可能不是系统目标所必需的特性吗？ 每项需求都有界定且无歧义吗？ 每项需求都有归属吗？--一个明确的人 4.7 确认需求 有需求与其他需求冲突吗？ 在系统或产品所处的技术环境下每个需求都能够实现吗？ 一旦实现后，没想需求是可测试的吗？ 需求模型恰当地反映了将要构建系统的信息、功能和行为吗？ 需求模型是否已经使用合适的方式“分割”，能够逐步地揭示详细的信息系统吗？ 已经使用了需求模式简化需求模型吗？所有的模式都已经恰当地确认了吗？所有的模式都和客户的需求一致吗？ 作业 4.1 为什么大量的软件开发人员没有足够重视需求工程？以前有没有什么情况让你可以跳过需求工程？ 4.2 想出三个以上在需求起始阶段可以要问利益相关者的“与情景无关的问题” 业务需求（Business requirement）表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开发一个系统，即组织希望达到的目标。使用前景和范围（vision and scope）文档来记录业务需求，这份文档有时也被称作项目轮廓图或市场需求（project charter 或 market requirement）文档。　　用户需求（user requirement）描述的是用户的目标，或用户要求系统必须能完成的任务。用例、场景描述和事件――响应表都是表达用户需求的有效途径。也就是说用户需求描述了用户能使用系统来做些什么。　　功能需求（functional requirement）规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。功能需求有时也被称作行为需求（behavīoral requirement），因为习惯上总是用“应该”对其进行描述：“系统应该发送电子邮件来通知用户已接受其预定”。功能需求描述是开发人员需要实现什么。　　系统需求（system requirement）用于描述包含多个子系统的产品（即系统）的顶级需求。系统可以只包含软件系统，也可以既包含软件又包含硬件子系统。人也可以是系统的一部分，因此某些系统功能可能要由人来承担。　　业务规则包括企业方针、政府条例、工业标准、会计准则和计算方法等。业务规划本身并非软件需求，因为它们不属于任何特定软件系统的范围。然而，业务规则常常会限制谁能够执行某些特定用例，或者规定系统为符合相关规则必须实现某些特定功能。有时，功能中特定的质量属性（通过功能实现）也源于业务规则。所以，对某些功能需求进行追溯时，会发现其来源正是一条特定的业务规则。　　功能需求记录在软件需求规格说明（SRS）中。SRS完整地描述了软件系统的预期特性。SRS我们一般把它当作文档，其实，SRS还可以是包含需求信息的数据库或电子表格；或者是存储在商业需求管理工具中的信息；而对于小型项目，甚至可能是一叠索引卡片。开发、测试、质量保证、项目管理和其他相关的项目功能都要用到 SRS。　　除了功能需求外，SRS中还包含非功能需求，包括性能指标和对质量属性的描述。　　质量属性（quality attribute）对产品的功能描述作了补充，它从不同方面描述了产品的各种特性。这些特性包括可用性、可移植性、完整性、效率和健壮性，它们对用户或开发人员都很重要。其他的非功能需求包括系统与外部世界的外部界面，以及对设计与实现的约束。　　约束（constraint）限制了开发人员设计和构建系统时的选择范围。　　产品特性。所谓特性（feature），是指一组逻辑上相关的功能需求，它们为用户提供某项功能，使业务目标得以满足。对商业软件而言，特性则是一组能被客户识别，并帮助他决定是否购买的需求，也就是产品说明书中用着重号标明的部分。客户希望得到的产品特性和用户的任务相关的需求不完全是一回事。一项特性可以包括多个用例，每个用例又要求实现多项功能需求，以便用户能够执行某项任务。 * 当需要调查大量人员的意见时，向被调查人员分发调查表是一个十分有效的方法 情景分析技术的用处主要体现在下述两个方面： 1.能在某种程度上演示目标系统的行为，从而便于用户理解，而且还可能进一步揭示出一些分析员目前还不知道的需求 2.由于情景分析比较容易被用户理解，使用这种技术能够保证用户在需求分析过程中始终