软件需求的层次

软件需求的层次软件需求包括3个不同的层次-业务需求、用户需求和功能需求。除此之外，每个系统 还有各种非功能需求。业务需求(Businessrequirement )表示组织或客户高层次的目标。业务需求通常来自项 目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描 述了组织为什么要开发一个系统，即组织希望达到的目标。使用前景和范围(vision and scope) 文档来记录业务需求，这份文档有时也被称作项目轮廓图或市场需求( projectcharter 或 marketrequirement )文档。用户需求( user requirement) 描述的是用户的目标，或用户要求系统必须能完成的任务。 用例、场景描述和事件-响应表都是表达用户需求的有效途径。也就是说用户需求描述了用户 能使用系统来做些什么。功能需求( functionalrequirement ) 规定开发人员必须在产品中实现的软件功能，用户 利用这些功能来完成任务，满足业务需求。功能需求有时也被称作行为需求(behavioral requirement) ，因为习惯上总是用“应该”对其进行描述：“系统应该发送电子邮件来通知用户已 接受其预定”。功能需求描述是开发人员需要实现什么。系统需求( system requirement) 用于描述包含多个子系统的产品(即系统)的顶级需求。 系统可以只包含软件系统，也可以既包含软件又包含硬件子系统。人也可以是系统的一部分， 因此某些系统功能可能要由人来承担。业务规则包括企业方针、政府条例、工业标准、会计准则和计算方法等。业务规划本身并 非软件需求，因为它们不属于任何特定软件系统的范围。然而，业务规则常常会限制谁能够执 行某些特定用例，或者规定系统为符合相关规则必须实现某些特定功能。有时，功能中特定的 质量属性(通过功能实现)也源于业务规则。所以，对某些功能需求进行追溯时，会发现其来 源正是一条特定的业务规则。功能需求记录在软件需求规格说明(SRS )中。SRS完整地描述了软件系统的预期特性。SRS我们一般把它当作文档，其实，SRS还可以是包含需求信息的数据库或电子表格；或者是 存储在商业需求管理工具中的信息；而对于小型项目，甚至可能是一叠索引卡片。开发、测试 质量保证、项目管理和其他相关的项目功能都要用至ISRS。除了功能需求外，SRS中还包含非功能需求，包括性能指标和对质量属性的描述。 质量属性( qualityattribute ) 对产品的功能描述作了补充，它从不同方面描述了产品的 各种特性。这些特性包括可用性、可移植性、完整性、效率和健壮性，它们对用户或开发人员 都很重要。其他的非功能需求包括系统与外部世界的外部界面，以及对设计与实现的约束。约束( constraint) 限制了开发人员设计和构建系统时的选择范围。产品特性。所谓特性( feature) ，是指一组逻辑上相关的功能需求，它们为用户提供某项 功能，使业务目标得以满足。对商业软件而言，特性则是一组能被客户识别，并帮助他决定是 否购买的需求，也就是产品说明书中用着重号标明的部分。客户希望得到的产品特性和用户的 任务相关的需求不完全是一回事。一项特性可以包括多个用例，每个用例又要求实现多项功能 需求，以便用户能够执行某项任务。还有一项称为可用性(usability )的质量属性，它规定了业务需求中“有效”(efficiently ) 一词的含义。管理人员或市场营销人员负责定义软件的业务需求，以提高公司的运营效率(对信息系统 而言)或产品的市场竞争力(对商业软件而言)。所有的用户需求都必须符合业务需求。需求 分析员从用户需求中推导出产品应具备哪些对用户有帮助的功能。开发人员则根据功能需求和 非功能需求设计解决方案，在约束条件的限制范围内实现必需的功能，并达到规定的质量和性 能指标。当一项新的特性、用例或功能需求被提出时，需求分析员必须思考一个问题： “它在范围内 吗？”。如果答案是肯定的，则该需求属于需求规格说明，反之则不属于。但答案也许是 “不在， 但应该在”，这时必须由业务需求的负责人或投资管理人来决定：是否扩大项目范围以容纳新的 需求。这是一个可能影响项目进度和预算的商业决策。不属于需求的内容需求规格说明中不包括(除已知约束外的)设计和实现的细节、项目的计划信息，以及测 试信息(Leffingwell和Widrig2000 )。把这些内容与需求分开，就可以把需求活动的注意力 集中到了解开发小组需要开发的产品特性上。项目中通常还包括其他类型的需求，如开发环境 需求，进度或预算限制，帮助新用户跟上进度的培训需求，或者发布产品使其转入支持环境的 需求。这些都属于项目需求而不是产品需求，因此不属于软件需求的讨论范围。