下载文档原格式
需求开发与管理标准化流程说明及表单书写说明1 目的定义需求开发与管理过程，为需求开发及跟踪提供有效的流程和方法。
2 适用范围2.1 机构研发中心技术部门及PMO、技术拓展部。
2.2 业务提供需求工程的过程标准。
3 名词术语3.1 RDM（Request Development and Management）：需求开发与管理。
3.2 SRS(Software Requirement Specification)：软件需求规格说明书。
3.3 客户(Customer)：开发产品订单的付费方3.4 最终用户(End User)：最终真正操作软件的用户3.5 用户需求：指直接来自于客户或者用户的原始需求3.6 产品需求：指对用户需求进行需求分析和开发之后生成的对于软件产品开发的需求3.7 CCB(Change Control Board)：变更控制委员会。
CCB的组长一般为适用机构的领导，成员一般为PMO及适用机构领导制定的某些特定人员，对于子部门级别的项目，CCB可直接由子部门的经理担任组长，由PMO担任组员。
4 概述项目在工程活动的开始，首先要进行需求开发。
后续所有的工程活动，包括设计、实现、测试均是根据需求展开的，所以需求开发的重要程度是最高的，而由于需求的抽象性，需求开发人员（系统分析员）既需要有过硬的专业知识，还要具备较强的交流、沟通能力，所以需求开发也是最难的。
任何项目，需求在整个工程开发过程中必定会发生变化，因此对需求变更的控制，即需求管理必不可少。
5 过程定义5.1 需求开发与管理5.1.1 角色与职责5.1.2 入口准则◆项目已经启动；◆对于合同项目，合同已经签订。
5.1.3 输入◆项目计划5.1.4 过程活动1)、需求调查获取用户（客户和最终用户）的需求信息。
调查需求的方式包括：◆与用户交谈，向用户提问题◆参观用户的工作流程，观察用户的操作◆向用户群体发调查问卷◆与同行。
专家交谈，听取他们的意见◆分析已经存在的同类软件产品，提取需求◆从行业标准、规则中提取需求◆从internet上搜查相关资料在需求调查完成之后，需要生成需求搜集的文档，文档形式可以自定义，但搜集的需求形成的文档需要由项目经理组织进行非正式的评审，要尽最大努力使搜集到的需求正确无误的反映用户的真实意愿。
用户需求说明书与需求规格说明书的区别1、用户需求说明书是用户的需求（期望），需要和用户确认的，重点是站在客户的角度讲产品功能。
需求规格说明书是系统设计需求，主要是对内的，是从开发、测试的角度去讲产品功能。
2、优点：用户的语言与设计人员的语言是不同的，所以需要有面向不同人员的文档。
缺点：层次越多，信息损失的越多，误解的概率就越大。
权衡的结果：基本上是依据项目的规模而定。
3、如果要省掉一个的话，更倾向于写用户需求，因为搞系统的时候要始终明白用户在想什么，要解决什么问题。
需求规格相对不是很重要，具体实现用户需求的时候，你可以有各种方案，这个是用户不关心的。
要是用户需求就已经理解错了，特别是理解不全面，软件规格说明书写得好让用户签字就没有任何意义了。
4、最新的做法➢使用UML语言，开发需求用例说明书，用例、场景描述和事件――响应表，既可面向客户，又可面向开发设计；➢使用敏捷开发方法，通过用户故事描述用户需求，即客户想要实现一个什么功能，以满足某个方面的需求。
【相关知识】●“需求管理”的文档大体上包含需求管理计划、需求检查表、需求跟踪表（包含矩阵图）、需求变更状态跟踪表，以及与其配套产出的指南型文件。
●“需求开发”的文档大体上包含需求规格说明书，需求规格说明书检查表，需求开发指南等。
●需求分析报告：一般是对某个市场或者是客户群来讲的，类似于调研报告，重点是体现出产品要满足哪些功能，哪些是重点、热点。
●需求说明书：是根据与现场实际客户进行沟通，把客户的需求进行整理，CMMI中有标准的模板，重点是站在客户的角度讲产品功能。
●需求规格说明书：是从业务规则讲起的，细一点偏向于软件的需求设计到概要设计。
是从开发、测试的角度去讲产品功能，里面要包含原型界面、业务接口、活动图等。
◆业务需求（Business requirement）表示组织或客户高层次的目标。
业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。
《实用软件工程》第3版习题参考答案习题 11.1 开发文档都有哪些？用图示表示它们之间的关系。
开发文档包括目标程序、源程序、详细设计说明书、概要设计说明书、需求规格说明书、用户需求报告、软件合同，它们之间的关系如下图所示。
1.2 简述软件工程研究的内容。
软件工程研究的内容包括软件开发方法、软件开发模型、软件支持过程和软件管理过程。
其中软件开发方法的内容又涵盖市场调研、正式立项、需求分析、项目策划、概要设计、详细设计、编程、测试、试运行、产品发布、用户培训、产品复制、销售、实施、系统维护、版本升级。
常用的软件开发模型有瀑布模型、迭代模型、增量模型和原型模型。
软件支持过程由所支持的CASE工具组成，常用的CASE工具有Power Designer和Rational Rose。
软件管理过程主要有CMMI、ISO9000、微软企业文化和敏捷文化现象。
1.3 详细解释软件的定义、程序的定义及软件工程的定义。
软件的定义：软件＝程序＋数据＋文档。
这里的程序是指程序系统。
这里的数据不仅包括初始化数据、测试数据，而且包括研发数据、运行数据、维护数据，也包括软件企业积累的项目工程数据和项目管理数据中的大量决策原始记录数据。
这里的文档指的是软件开发过程中的分析、设计、实现、测试、维护文档、管理文档。
现在有一种新提法正在引起关注，这种提法是：软件＝知识＋程序＋数据＋文档。
程序是计算机为完成特定任务而执行的指令的有序集合。
从应用的角度可理解为：面向过程的程序＝算法＋数据结构面向对象的程序＝对象＋信息面向构件的程序＝构件＋构架软件工程是研究软件开发和软件管理的一门工程学科。
1.4 软件工程的7+1条基本原理有什么现实意义？软件工程的7条基本原理是在面向过程的程序设计时代（结构化时代）提出来的，但在面向数据和面向对象的程序设计的今天，它仍然有效。
并且在军事上的实时跟踪监控系统中有很好的应用，而且随着软件的开发和管理的进步，它将不断完善和充实。
用户需求规格说明书1.引言用户需求规格说明书是为了明确和定义用户对于特定产品或服务的期望和需求而编写的文档。
它对于开发者和设计团队来说是至关重要的，因为它帮助他们理解用户的需求，从而可以在开发过程中满足这些需求。
本文档将详细描述用户需求规格，包括产品的核心功能、性能要求、界面设计、可靠性和可用性等方面。
2.产品描述本产品是一款面向广大用户的软件应用程序，旨在解决特定问题或提供特定的服务。
它将提供以下核心功能：- 功能一：简要说明和描述功能一的具体内容。
例如，如果产品是一款社交媒体应用程序，功能一可以是用户注册和创建个人资料。
- 功能二：简要说明和描述功能二的具体内容。
例如，如果产品是一款电子商务平台，功能二可以是用户浏览和购买商品。
3.用户需求本节将详细描述用户对于产品的具体需求。
用户需求可以分为功能性需求和非功能性需求。
3.1 功能性需求功能性需求涉及到产品的核心功能和特性。
以下是对于本产品所要求的功能性需求的详细描述：- 需求一：详细描述需求一的功能和特性。
- 需求二：详细描述需求二的功能和特性。
3.2 非功能性需求非功能性需求涉及到产品的性能、界面设计、可靠性和可用性等方面。
以下是对于本产品所要求的非功能性需求的详细描述：- 需求三：描述对于产品性能的需求，例如响应时间、处理能力等。
- 需求四：描述对于产品界面设计的需求，例如简洁、直观和易用性。
- 需求五：描述对于产品可靠性的需求，例如稳定性、安全性等。
- 需求六：描述对于产品可用性的需求，例如可访问性、跨平台兼容性等。
4.用户场景用户场景描述了用户如何使用产品以及产品在不同情境和场景中的表现。
以下是对于本产品的一些典型用户场景的描述：- 场景一：描述一个典型用户使用产品的情境，例如用户登录并浏览商品。
- 场景二：描述另一个典型用户使用产品的情境，例如用户选择商品并付款。
5.限制和假设条件本节将描述可能对于产品开发和设计的限制和假设条件。
用户需求说明书与需求规格说明书的区别1、用户需求说明书是用户的需求（期望），需要和用户确认的，重点是站在客户的角度讲产品功能。
需求规格说明书是系统设计需求，主要是对内的，是从开发、测试的角度去讲产品功能。
2、优点：用户的语言与设计人员的语言是不同的，所以需要有面向不同人员的文档。
缺点：层次越多，信息损失的越多，误解的概率就越大。
权衡的结果：基本上是依据项目的规模而定。
3、如果要省掉一个的话，更倾向于写用户需求，因为搞系统的时候要始终明白用户在想什么，要解决什么问题。
需求规格相对不是很重要，具体实现用户需求的时候，你可以有各种方案，这个是用户不关心的。
要是用户需求就已经理解错了，特别是理解不全面，软件规格说明书写得好让用户签字就没有任何意义了。
4、最新的做法使用UML语言，开发需求用例说明书，用例、场景描述和事件――响应表，既可面向客户，又可面向开发设计；使用敏捷开发方法，通过用户故事描述用户需求，即客户想要实现一个什么功能，以满足某个方面的需求。
【相关知识】●“需求管理”的文档大体上包含需求管理计划、需求检查表、需求跟踪表（包含矩阵图）、需求变更状态跟踪表，以及与其配套产出的指南型文件。
●“需求开发”的文档大体上包含需求规格说明书，需求规格说明书检查表，需求开发指南等。
●需求分析报告：一般是对某个市场或者是客户群来讲的，类似于调研报告，重点是体现出产品要满足哪些功能，哪些是重点、热点。
●需求说明书：是根据与现场实际客户进行沟通，把客户的需求进行整理，CMMI中有标准的模板，重点是站在客户的角度讲产品功能。
●需求规格说明书：是从业务规则讲起的，细一点偏向于软件的需求设计到概要设计。
是从开发、测试的角度去讲产品功能，里面要包含原型界面、业务接口、活动图等。
◆业务需求（Business requirement）表示组织或客户高层次的目标。
业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。
用户需求说明书与需求规格说明书的区别1、用户需求说明书是用户的需求（期望），需要和用户确认的，重点是站在客户的角度讲产品功能。
需求规格说明书是系统设计需求，主要是对内的，是从开发、测试的角度去讲产品功能。
2、优点：用户的语言与设计人员的语言是不同的，所以需要有面向不同人员的文档。
缺点：层次越多，信息损失的越多，误解的概率就越大。
权衡的结果：基本上是依据项目的规模而定。
3、如果要省掉一个的话，更倾向于写用户需求，因为搞系统的时候要始终明白用户在想什么，要解决什么问题。
需求规格相对不是很重要，具体实现用户需求的时候，你可以有各种方案，这个是用户不关心的。
要是用户需求就已经理解错了，特别是理解不全面，软件规格说明书写得好让用户签字就没有任何意义了。
4、最新的做法➢使用UML语言，开发需求用例说明书，用例、场景描述和事件――响应表，既可面向客户，又可面向开发设计；➢使用敏捷开发方法，通过用户故事描述用户需求，即客户想要实现一个什么功能，以满足某个方面的需求。
【相关知识】●“需求管理”的文档大体上包含需求管理计划、需求检查表、需求跟踪表（包含矩阵图）、需求变更状态跟踪表，以及与其配套产出的指南型文件。
●“需求开发”的文档大体上包含需求规格说明书，需求规格说明书检查表，需求开发指南等。
●需求分析报告：一般是对某个市场或者是客户群来讲的，类似于调研报告，重点是体现出产品要满足哪些功能，哪些是重点、热点。
●需求说明书：是根据与现场实际客户进行沟通，把客户的需求进行整理，CMMI中有标准的模板，重点是站在客户的角度讲产品功能。
●需求规格说明书：是从业务规则讲起的，细一点偏向于软件的需求设计到概要设计。
是从开发、测试的角度去讲产品功能，里面要包含原型界面、业务接口、活动图等。
◆业务需求（Business requirement）表示组织或客户高层次的目标。
业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。
《需求规格说明书》编写参考指南1．概述（Summary）本文档是进行项目策划、概要设计和详细设计的基础，也是软件企业测试部门进行内部验收测试的依据。
1.1 用户简介（User Synopsis）在本章节中要将用户的基本情况描述清楚，以便于分析人员划定系统范围，进行功能、进度、成本、性能等方面的平衡决策。
对于产品开发类项目，需要在此将该产品定义的用户群的特点描述清楚。
1.2 项目的目的与目标（Purpose and Aim of Project）项目的目的是对开发本系统的意图的总概括。
项目的目标是将目的细化后的具体描述。
项目目标应是明确的、可度量的、可以达到的, 项目的范围应能确保项目的目标可以达到。
对于项目的目标可以逐步细化，以便与系统的需求建立对应关系，检查系统的功能是否覆盖了系统的目标。
1.3 术语定义（Terms Glossary）将该需求规格说明书中的术语、缩写进行定义, 包括用户应用领域与计算机领域的术语与缩写等。
1.4 参考资料（References）说明该用户需求报告使用的参考资料，如：[1] 商务合同[2] 招标书[3] 用户领域的资料[4] 用户需求调查表[5] 用户需求报告[6] 参照的标准每一个文件、文献要有标题、或文件号，发布或发表日期以及出版单位。
1.5 相关文档（Related Documents）[1] 项目开发计划[2] 概要设计说明书[3] 详细设计说明书1.6 版本更新信息（V ersion Updated Record）版本更新记录格式，如表5-19所示。
表5-19 版本更新记录2．目标系统描述（System in Target）2.1 组织结构与职责（Organizing Framework and Function）将目标系统的组织结构逐层详细描述，建议采用树状的组织结构图进行表达，每个部门的职责也应进行简单的描述。
组织结构是用户企业业务流程与信息的载体，对分析人员理解企业的业务、确定系统范围很有帮助。
用户需求说明书与需求规格说明书的区别1、用户需求说明书是用户的需求（期望），需要和用户确认的，重点是站在客户的角度讲产品功能。
需求规格说明书是系统设计需求，主要是对内的，是从开发、测试的角度去讲产品功能。
2、优点：用户的语言与设计人员的语言是不同的，所以需要有面向不同人员的文档。
缺点：层次越多，信息损失的越多，误解的概率就越大。
权衡的结果：基本上是依据项目的规模而定。
3、如果要省掉一个的话，更倾向于写用户需求，因为搞系统的时候要始终明白用户在想什么，要解决什么问题。
需求规格相对不是很重要，具体实现用户需求的时候，你可以有各种方案，这个是用户不关心的。
要是用户需求就已经理解错了，特别是理解不全面，软件规格说明书写得好让用户签字就没有任何意义了。
4、最新的做法使用UML语言，开发需求用例说明书，用例、场景描述和事件一一响应表，既可面向客户，又可面向开发设计；使用敏捷开发方法，通过用户故事描述用户需求，即客户想要实现一个什么功能，以满足某个方面的需求。
【相关知识】“需求管理”的文档大体上包含需求管理计划、需求检查表、需求跟踪表（包含矩阵图）、需求变更状态跟踪表，以及与其配套产出的指南型文件。
“需求开发”的文档大体上包含需求规格说明书，需求规格说明书检查表，需求开发指南等。
需求分析报告：一般是对某个市场或者是客户群来讲的，类似于调研报告，重点是体现出产品要满足哪些功能，哪些是重点、热点。
需求说明书：是根据与现场实际客户进行沟通，把客户的需求进行整理，CMMI中有标准的模板，重点是站在客户的角度讲产品功能。
需求规格说明书：是从业务规则讲起的，细一点偏向于软件的需求设计到概要设计。
是从开发、测试的角度去讲产品功能，里面要包含原型界面、业务接口、活动图等。
业务需求 (Busi ness requireme nt )表示组织或客户高层次的目标。
业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。
项目用户需求规格说明书范本1.引言本文档旨在收集和识别项目的用户需求，以便明确项目的目标和范围，为后续的设计和开发阶段提供指导。
本文档适用于任何规模的项目，旨在帮助整个团队理解用户需求并共同努力实现项目目标。
2.目标该项目的目标是开发一个功能完善、易于使用、可靠稳定的XXX系统，满足用户的需求并提供良好的用户体验。
通过该系统，用户可以更高效、更方便地进行XXX操作，提高工作效率和准确性。
3.用户需求3.1用户需求一：系统登录功能用户要求能够通过有效的身份验证登录系统，并能够根据自己的角色和权限访问不同的功能模块和数据。
3.2用户需求二：XXX操作3.3用户需求三：XXX功能用户要求系统能够提供XXX功能，并能够根据用户的需求生成相应的报表和统计数据。
3.4用户需求四：界面友好用户需要系统界面友好、简洁明了，操作流程清晰，各个功能模块之间的逻辑关系清晰可见。
3.5用户需求五：数据安全性用户要求系统能够保护数据的安全性，包括数据的备份、恢复以及权限控制等。
4.功能需求4.1系统登录功能系统应该提供一个登录界面，用户可以输入用户名和密码进行身份验证。
登录成功后，根据用户角色和权限显示相应的功能菜单。
4.2XXX功能4.3XXX功能系统应该提供XXX功能，包括生成报表、统计数据等。
4.4界面设计系统界面设计应该简洁明了，操作流程清晰，各个功能模块之间的逻辑关系清晰可见。
4.5数据安全性系统应该保护数据的安全性，包括数据的备份、恢复以及权限控制等。
5.性能需求系统应该具备良好的性能，包括快速响应用户操作、高并发处理能力、稳定可靠的运行等。
6.项目范围本项目的范围涵盖XXX功能的设计、开发和测试阶段。
运维、培训等后续阶段不属于本项目的范畴。
总结本文档提供了一个项目用户需求规格说明书的范本，可以根据实际项目的情况进行相应修改和补充。
通过准确理解和明确用户需求，对项目进行规范和约束，有助于提高项目的成功率和用户满意度。
用户需求说明书与需求规格说明书的区别
1、用户需求说明书是用户的需求（期望），需要和用户确认的，重点是站在客
户的角度讲产品功能。
需求规格说明书是系统设计需求，主要是对内的，是
从开发、测试的角度去讲产品功能。
2、优点：用户的语言与设计人员的语言是不同的，所以需要有面向不同人员的
文档。
缺点：层次越多，信息损失的越多，误解的概率就越大。
权衡的结
果：基本上是依据项目的规模而定。
3、如果要省掉一个的话，更倾向于写用户需求，因为搞系统的时候要始终明白
用户在想什么，要解决什么问题。
需求规格相对不是很重要，具体实现用户
需求的时候，你可以有各种方案，这个是用户不关心的。
要是用户需求就已
经理解错了，特别是理解不全面，软件规格说明书写得好让用户签字就没有
任何意义了。
4、最新的做法
使用UML语言，开发需求用例说明书，用例、场景描述和事件――响
应表，既可面向客户，又可面向开发设计；
使用敏捷开发方法，通过用户故事描述用户需求，即客户想要实现
一个什么功能，以满足某个方面的需求。
【相关知识】
“需求管理”的文档大体上包含需求管理计划、需求检查表、需求跟踪表（包含矩阵图）、需求变更状态跟踪表，以及与其配套产出的指南型文件。
“需求开发”的文档大体上包含需求规格说明书，需求规格说明书检查表，
需求开发指南等。
需求分析报告：一般是对某个市场或者是客户群来讲的，类似于调研报告，
重点是体现出产品要满足哪些功能，哪些是重点、热点。
需求说明书：是根据与现场实际客户进行沟通，把客户的需求进行整理，CMMI 中有标准的模板，重点是站在客户的角度讲产品功能。
需求规格说明书：是从业务规则讲起的，细一点偏向于软件的需求设计到概
要设计。
是从开发、测试的角度去讲产品功能，里面要包含原型界面、业务
接口、活动图等。
业务需求（Business requirement）表示组织或客户高层次的目标。
业务
需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销
部门或产品策划部门。
业务需求描述了组织为什么要开发一个系统，即组织
希望达到的目标。
使用前景和范围（vision and scope）文档来记录业务需求，这份文档有时也被称作项目轮廓图或市场需求（project charter 或market requirement）文档。
用户需求（user requirement）描述的是用户的目标，或用户要求系统必
须能完成的任务。
用例、场景描述和事件――响应表都是表达用户需求的有效
途径。
也就是说用户需求描述了用户能使用系统来做些什么。
功能需求（functional requirement）规定开发人员必须在产品中实现的
软件功能，用户利用这些功能来完成任务，满足业务需求。
功能需求有时也
被称作行为需求（behavīoral requirement），因为习惯上总是用“应该”对其进行描述：“系统应该发送电子邮件来通知用户已接受其预定”。
功能需求描述是开发人员需要实现什么。
注意：用户需求不总是被转变成功能需
求。
产品特性，所谓特性（feature），是指一组逻辑上相关的功能需求，它们为
用户提供某项功能，使业务目标得以满足。
对商业软件而言，特性则是一组
能被客户识别，并帮助他决定是否购买的需求，也就是产品说明书中用着重
号标明的部分。
客户希望得到的产品特性和用户的任务相关的需求不完全是
一回事。
一项特性可以包括多个用例，每个用例又要求实现多项功能需求，
以便用户能够执行某项任务。
系统需求（system requirement）用于描述包含有多个子系统的产品（即系统）的顶级需求。
系统可以只包含软件系统，也可以既包含软件又包含硬件
子系统。
人也可以是系统的一部分，因此某些系统功能可能要由人来承担。
业务规则包括企业方针、政府条例、工业标准、会计准则和计算方法等。
业
务规划本身并非软件需求，因为它们不属于任何特定软件系统的范围。
然而，
业务规则常常会限制谁能够执行某些特定用例，或者规定系统为符合相关规则必须实现某些特定功能。
有时，功能中特定的质量属性（通过功能实现）
也源于业务规则。
所以，对某些功能需求进行追溯时，会发现其来源正是
一条特定的业务规则。
功能需求记录在软件需求规格说明（SRS）中。
SRS完整地描述了软件系统的预期特性。
SRS我们一般把它当作文档，其实，SRS还可以是包含需求信息的数据库或电子表格；或者是存储在商业需求管理工具中的信息；而对于小
型项目，甚至可能是一叠索引卡片。
开发、测试、质量保证、项目管理和其他相关的项目功能都要用到SRS。
需求层次：组织级需求->业务需求->用户需求->功能需求（有时也叫行为需求）。
组织级需求：一般代表着组织的愿景和目标。
对于大的公司，一般是通过资
深的咨询顾问和咨询公司得出的，呈现的方式是咨询报告。
比如在ITSM或者企业信息化这方面。
典型的组织级的需求是：降低成本、减少库存成本、
提升IT服务部门在企业中的价值、通过ISO20000、提高IT服务的效率、提高员工的满意度等。
业务需求：是要完组织的使命，达成组织的愿景的各个业务流程和业务单
元具有的需求。
业务需求服从于组织需求。
用户需求：用户级的需求，是在业务级的需求下，各个岗位协作完成业务
而具有的需求。
我们在软件需求规格说明书中表述的需求其实主要是这一部
分需求。
功能需求：同样，它代表着产品或者软件需求具备的能力。
一般是管理人员或者产品的市场部门人员负责定义软件的业务需求，以提高公司的运营效率（对信息系统而言）或产品的市场竞争力（对商业软件而言）。
所有的用户需求都必须符合业务需求。
需求分析员从用户需求中推导出产品应具备哪
些对用户有帮助的功能。
开发人员则根据功能需求和非功能需求设计解决方案，在约束条件的限制范围内实现必需的功能，并达到规定的质量和性能指标。
当一项新的特性、用例或功能需求被提出时，需求分析员必须思考一个
问题：“它在范围内吗？”。
如果答案是肯定的，则该需求属于需求规格说
明，反之则不属于。
但答案也许是“不在，但应该在”，这时必须由业务需
求的负责人或投资管理人来决定：是否扩大项目范围以容纳新的需求。
这
是一个可能影响项目进度和预算的商业决策。
非功能需求，包括性能指标和对质量属性的描述。
质量属性（quality attribute）对产品的功能描述作了补充，它从不同方面描述了产品的各种
特性。
这些特性包括可用性、可移植性、完整性、效率和健壮性，它们对用
户或开发人员都很重要。
其他的非功能需求包括系统与外部世界的外部界面，
以及对设计与实现的约束。
还有一项称为可用性（usability）的质量属性，
它规定了业务需求中“有效”（efficiently）一词的含义。
约束（constraint）限制了开发人员设计和构建系统时的选择范围。
约束，在产品的架构设计中，是需要被首先考虑的问题。
如果说产品的功能代表了产品的能力，那么产品
的质量属性代表了产品的品质，产品的约束代表了产品必须去满足的或者适
应的条件！“用户体验”是产品的灵魂，对于个人级的软件这么说或许很恰
当，当对于企业级甚至是行业级的产品，其灵魂有两个：一个是产品带给用
户的价值，另一个是产品的品质，简单的说，就是价值和品质。
但其成为一
个产品的前提应该是满足约束，否则就不应该设计、开发、进入市场而成为
一个垃圾。
用户需求、功能需求区别。
简单的就是：用户需求。
用户需要在应用系统
中实现什么东西，为实现这个目标，需要用户提供的全部的详细的业务说明，
业务流程，表格样式等。
功能需求。
将用户需求归类分解为计算机可以实
现的子系统和功能模块，用设计语言描述和解释用户的需求，以达到可以指
导程序设计的目的。
欢迎您的下载，
资料仅供参考！
致力为企业和个人提供合同协议，策划案计划书，学习资料等等
打造全网一站式需求。
