软件需求3个层次――业务需求、用户需求和功能需求.docx

软件需求3个层次一一业务需求、用户需求和功能需求 软件需求包括3个不同的层次 一一业务需求、用户需求和功能需求。除此之外，每个系统还有 各种非功能需求。 业务需求(Business requirement )表示组织或客户高层次的目标 。业务需求通常来自项目投 资人、购买产品的客户、实际用户的管理者、 市场营销部门或产品策划部门。 业务需求描述了组 visi on and scopeproject charter visi on and scope project charter market requireme nt )文档。 用户需求(user requirement )描述的是用户的目标，或用户要求系统必须能完成的任务 例、场景描述和事件 响应表都是表达用户需求的有效途径。 也就是说用户需求描述了用户能 使用系统来做些什么。 )规定开发人员必须在产品中实现的软件功能，用户利用，功能需求有时也被称作行为需求( behav 1 oral应该”对其进行描述：系统应该发送电子邮件来通知用户 )规定开发人员必须在产品中实现的软件功能，用户利用 ，功能需求有时也被称作行为需求( behav 1 oral 应该”对其进行描述：系统应该发送电子邮件来通知用户 系统需求(system requirement )用于描述包含多个子系统的产品(即系统)的顶级需求 系统可以只包含软件系统， 也可以既包含软件又包含硬件子系统。 人也可以是系统的一部分， 此某些系统功能可能要由人来承担。 举例如下： 业务需求一般是我由我们软件开发人员来搜集的，是企业自身在顾问等引导下自己所作的工作。 我们只是去从他们那里直接的拿来就可以了。比如为了配合企业生产改造，为了加强库存管理， 为了建立企业电子化运行平台， 这些都是业务需求。这些东西的建模还是留给咨询顾问吧， 我们 没有拿那份企业流程重组的钱，也就不用费这个力气。 用户需求是用户为实现其业务需求而提岀的基于实际情况的具体目标。 比如我的系统要可以查看 库存中的零件数量，我需要可以由计算机给出投料方案，计算工资总额。 功能需求就是要去解决这些具体的用户需求所产生的解决方案。 这个就是我们平常说的需求说明。 要得到这个就需要对用户需求作具体的分析，提岀具体的实施方法。 业务规则包括企业方针、政府条例、工业标准、会计准则和计算方法等 。业务规划本身并非软 件需求，因为它们不属于任何特定软件系统的范围。 然而，业务规则常常会限制谁能够执行某些 特定用例，或者规定系统为符合相关规则必须实现某些特定功能。 有时，功能中特定的质量属性 (通过功能实现)也源于业务规则。所以，对某些功能需求进行追溯时，会发现其来源正是一条 特定的业务规则。 功能需求记录在软件需求规格说明( SRS )中。SRS完整地描述了软件系统的预期特性。 SRS 我们一般把它当作文档，其实， SRS还可以是包含需求信息的数据库或电子表格；或者是存储 在商业需求管理工具中的信息；而对于小型项目，甚至可能是一叠索引卡片。开发、测试、质量 保证、项目管理和其他相关的项目功能都要用到 SRS。 除了功能需求外，SRS中还包含非功能需求，包括性能指标和对质量属性的描述。 质量属性(quality attribute )对产品的功能描述作了补充，它从不同方面描述了产品的各种 特性。这些特性包括可用性、可移植性、完整性、效率和健壮性 ，它们对用户或开发人员都很 重要。其他的非功能需求包括系统与外部世界的外部界面，以及对设计与实现的约束。 约束(constraint )限制了开发人员设计和构建系统时的选择范围 。 产品特性。所谓特性(feature )，是指一组逻辑上相关的功能需求， 它们为用户提供某项功能， 使业务目标得以满足。 对商业软件而言， 特性则是一组能被客户识别， 并帮助他决定是否购买的 需求，也就是产品说明书中用着重号标明的部分。 客户希望得到的产品特性和用户的任务相关的 需求不完全是一回事。一项特性可以包括多个用例， 每个用例又要求实现多项功能需求， 以便用 户能够执行某项任务。 还有一项称为可用性(usability )的质量属性，它规定了业务需求中 有效”(efficiently ) —词 的含义。 管理人员或市场营销人员负责定义软件的业务需求，以提高公司的运营效率(对信息系统而言) 或产品的市场竞争力(对商业软件而言)。 所有的用户需求都必须符合业务需求。需求分析员从 用户需求中推导岀产品应具备哪些对用户有帮助的功能。 开发人员则根据功能需求和非功能需求 设计解决方案，在约束条件的限制范围内实现必需的功能，并达到规定的质量和性能指标。 当一项新的特性、用例或功能需求被提岀时， 需求分析员必须思考一个问题： 它在范围内吗？ ”。 如果答案是肯定的，