功能需求的三个层次

　　软件需求是(1)用户解决问题或达到目标所需条件或权能(Capability)。(2)系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。(3)一种反映上面(1)或(2)所述条件或权能的文档说明。它包括功能性需求及非功能性需求，非功能性需求对设计和实现提出了限制，比如性能要求，质量标准，或者设计限制。80年代中期，形成了软件工程子领域——需求工程(requirementengineering,RE)。从1993年起每两年举办一次需求工程国际研讨会(ISRE)，自1994年起每两年举办一次需求工程国际会议(ICRE)，一些关于需求工程的工作小组相继成立。需求工程是随着计算机的发展而发展的，在计算机发展的初期，软件规模不大，软件开发所关注的是代码编写，需求分析很少受到重视。后来软件开发引入了生命周期的概念，需求分析成为其第一阶段。随着软件系统规模的扩大，需求分析与定义在整个软件开发与维护过程中越来越重要，直接关系到软件的成功与否。人们逐渐认识到需求分析活动不再仅限于软件开发的最初阶段，它贯穿于系统开发的整个生命周期。

     软件需求包括3个不同的层次――业务需求、用户需求和功能需求。除此之外，每个系统还有各种非功能需求。

　　业务需求（Businessrequirement）表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开发一个系统，即组织希望达到的目标。使用前景和范围（visionandscope）文档来记录业务需求，这份文档有时也被称作项目轮廓图或市场需求（projectcharter或marketrequirement）文档。

　　用户需求（userrequirement）描述的是用户的目标，或用户要求系统必须能完成的任务。用例、场景描述和事件――响应表都是表达用户需求的有效途径。也就是说用户需求描述了用户能使用系统来做些什么。

　　功能需求（functionalrequirement）规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。功能需求有时也被称作行为需求（behavīoralrequirement），因为习惯上总是用“应该”对其进行描述：“系统应该发送电子邮件来通知用户已接受其预定”。功能需求描述是开发人员需要实现什么。

　　系统需求（systemrequirement）用于描述包含多个子系统的产品（即系统）的顶级需求。系统可以只包含软件系统，也可以既包含软件又包含硬件子系统。人也可以是系统的一部分，因此某些系统功能可能要由人来承担。

　　业务规则包括企业方针、政府条例、工业标准、会计准则和计算方法等。业务规划本身并非软件需求，因为它们不属于任何特定软件系统的范围。然而，业务规则常常会限制谁能够执行某些特定用例，或者规定系统为符合相关规则必须实现某些特定功能。有时，功能中特定的质量属性（通过功能实现）也源于业务规则。所以，对某些功能需求进行追溯时，会发现其来源正是一条特定的业务规则。

　　FrederickBrooks在他1987年的经典的文章“NoSilverBullet：EssenceandAccidentsofSoftwareEngineering”中充分说明了需求过程在软件项目中扮演的重要角色：

　　开发软件系统最为困难的部分就是准确说明开发什么。最为困难的概念性工作便是编写出详细技术需求，这包括所有面向用户、面向机器和其它软件系统的接口。如果前期需求分析不透彻，一旦做错，将最终会给系统带来极大损害的部分，并且以后再对它进行修改也极为困难，容易导致项目失败。

　　功能需求记录在软件需求规格说明（SRS）中。SRS完整地描述了软件系统的预期特性。SRS我们一般把它当作文档，其实，SRS还可以是包含需求信息的数据库或电子表格；或者是存储在商业需求管理工具中的信息；而对于小型项目，甚至可能是一叠索引卡片。开发、测试、质量保证、项目管理和其他相关的项目功能都要用到SRS。

　　除了功能需求外，SRS中还包含非功能需求，包括性能指标和对质量属性的描述。

　　质量属性（qualityattribute）对产品的功能描述作了补充，它从不同方面描述了产品的各种特性。这些特性包括可用性、可移植性、完整性、效率和健壮性，它们对用户或开发人员都很重要。其他的非功能需求包括系统与外部世界的外部界面，以及对设计与实现的约束。

　　约束（constraint）限制了开发人员设计和构建系统时的选择范围。

　　产品特性。所谓特性（feature），是指一组逻辑上相关的功能需求，它们为用户提供某项功能，使业务目标得以满足。对商业软件而言，特性则是一组能被客户识别，并帮助他决定是否购买的需求，也就是产品说明书中用着重号标明的部分。客户希望得到的产品特性和用户的任务相关的需求不完全是一回事。一项特性可以包括多个用例，每个用例又要求实现多项功能需求，以便用户能够执行某项任务。

　　还有一项称为可用性（usability）的质量属性，它规定了业务需求中“有效”（efficiently）一词的含义。

　　管理人员或市场营销人员负责定义软件的业务需求，以提高公司的运营效率（对信息系统而言）或产品的市场竞争力（对商业软件而言）。所有的用户需求都必须符合业务需求。需求分析员从用户需求中推导出产品应具备哪些对用户有帮助的功能。开发人员则根据功能需求和非功能需求设计解决方案，在约束条件的限制范围内实现必需的功能，并达到规定的质量和性能指标。

　　当一项新的特性、用例或功能需求被提出时，需求分析员必须思考一个问题：“它在范围内吗？”。如果答案是肯定的，则该需求属于需求规格说明，反之则不属于。但答案也许是“不在，但应该在”，这时必须由业务需求的负责人或投资管理人来决定：是否扩大项目范围以容纳新的需求。这是一个可能影响项目进度和预算的商业决策。

　　不属于需求的内容

　　需求规格说明中不包括（除已知约束外的）设计和实现的细节、项目的计划信息，以及测试信息（Leffingwell和Widrig2000）。把这些内容与需求分开，就可以把需求活动的注意力集中到了解开发小组需要开发的产品特性上。项目中通常还包括其他类型的需求，如开发环境需求，进度或预算限制，帮助新用户跟上进度的培训需求，或者发布产品使其转入支持环境的需求。这些都属于项目需求而不是产品需求，因此不属于软件需求的讨论范围。

　　作为补充，软件需求规格说明还应包括非功能需求，它描述了系统展现给用户的行为和执行的操作等。它包括产品必须遵从的标准、规范和合约；外部界面的具体细节；性能要求；设计或实现的约束条件及质量属性。所谓约束是指对开发人员在软件产品设计和构造上的限制。质量属性是通过多种角度对产品的特点进行描述，从而反映产品功能。多角度描述产品对用户和开发人员都极为重要。值得注意的一点是，需求并未包括设计细节、实现细节、项目计划信息或测试信息。需求与这些没有关系，它关注的是充分说明你究竟想开发什么。

　　举例如下：

　　业务需求一般是我由我们软件开发人员来搜集的，是企业自身在顾问等引导下自己所作的工作。我们只是去从他们那里直接的拿来就可以了。比如为了配合企业生产改造，为了加强库存管理，为了建立企业电子化运行平台，这些都是业务需求。这些东西的建模还是留给咨询顾问吧，我们没有拿那份企业流程重组的钱，也就不用费这个力气。

　　用户需求是用户为实现其业务需求而提出的基于实际情况的具体目标。比如我的系统要可以查看库存中的零件数量，我需要可以由计算机给出投料方案，计算工资总额。

　　功能需求就是要去解决这些具体的用户需求所产生的解决方案。这个就是我们平常说的需求说明。要得到这个就需要对用户需求作具体的分析，提出具体的实施方法。

　　基于上述分析可知，结构化分析方法与面向对象分析方法的区别主要体现在两个方面：

　　*将系统分解成于系统的方式不同。前者将系统描述成一组交互作用的处理，后者则描述成一组交互作用的对象。

　　*子系统之间的交互关系的描述方式不一样。前者加工之间的交互是通过不太精确的数据流来表示的，而后者对象之间通过消息传递交互关系。

　　因此，面向对象软件需求分析的结果能更好地刻画现实世界，处理复杂问题，对象比过程更具有稳定性，便于维护与复用。

　　更多详细内容，尽在课课家教育，我们期待您的咨询！！