非功能性需求都包括哪些方面?
1?????? 非功能性需求:用户对软件质量属性、运行环境、资源约束、外部接口等方面的要求或期望,包括:(1) 性能需求:用户在软件响应速度、结果精度、运行时资源消耗量等方面的要求。
(2) 可靠性需求:用户在软件失效的频率、严重程度、易恢复性,以及故障可预测性等方面的要求。
(3) 易用性需求:用户在界面的易用性、美观性,以及对面向用户的文档和培训资料等方面的要求。
(4) 安全性需求:用户在身份认证、授权控制、私密性等方面的要求。
(4) 运行环境约束:用户对软件系统运行环境的要求。
(5) 外部接口:用户对待开发软件系统与其他软件系统或硬件设备之间的接口的要求。
软件工程中的功能需求和非功能需求的区别是什么
展开全部我们的软件产品或者项目,其需求都有三个层级和三个方面。
一、我们首先看需求的三个层次软件需求包括3个不同的层次――业务需求、用户需求和功能需求。
业务需求 (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服务的效率、提高员工的满意度等。
业务需求: 是要完组织的使命,达成组织的愿景的各个业务流程和业务单元具有的需求。
业务需求服从于组织需求。
用户需求: 用户级的需求,是在业务级的需求下,各个岗位协作完成业务而具有的需求。
我们在软件需求规格说明书中表述的需求其实主要是这一部分需求。
功能需求: 同样,它代表着产品或者软件需求具备的能力。
一般是管理人员或者产品的市场部门人员负责定义软件的业务需求,以提高公司的运营效率(对信息系统而言)或产品的市场竞争力(对商业软件而言)。
所有的用 户需求都必须符合业务需求。
需求分析员从用户需求中推导出产品应具备哪些对用户有帮助的功能。
开发人员则根据功能需求和非功能需求设计解决方案,在约束条 件的限制范围内实现必需的功能,并达到规定的质量和性能指标。
当一项新的特性、用例或功能需求被提出时,需求分析员必须思考一个问题:“它在范围内 吗?”。
如果答案是肯定的,则该需求属于需求规格说明,反之则不属于。
但答案也许是“不在,但应该在”,这时必须由业务需求的负责人或投资管理人来决定: 是否扩大项目范围以容纳新的需求。
这是一个可能影响项目进度和预算的商业决策。
二、需求的三个方面 除了功能需求外,SRS中还包含非功能需求,包括性能指标和对质量属性的描述。
质量属性 (quality attribute)对产品的功能描述作了补充,它从不同方面描述了产品的各种特性。
这些特性包括可用性、可移植性、完整性、效率和健壮性,它们对用户或 开发人员都很重要。
其他的非功能需求包括系统与外部世界的外部界面,以及对设计与实现的约束。
还有一项称为可用性(usability)的质量属性,它规 定了业务需求中“有效”(efficiently)一词的含义。
约束(constraint)限制了开发人员设计...
软件工程的软件需求
软件需求包括 3 个不同的层次――业务需求、用户需求和功能需求。
除此之外,每个系统还有各种非功能需求。
业务需求(Business requirement)表示组织或客户高层次的目标。
业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。
业务需求描述了组织为什么要开发一个系统,即组织希望达到的目标。
使用前景和范围( vision and scope )文档来记录业务需求,这份文档有时也被称作项目轮廓图或市场需求( project charter 或 market requirement )文档。
用户需求(user requirement)描述的是用户的目标,或用户要求系统必须能完成的任务。
用例、场景描述和事件――响应表都是表达用户需求的有效途径。
也就是说用户需求描述了用户能使用系统来做些什么。
功能需求(functional requirement)规定开发人员必须在产品中实现的软件功能,用户利用这些功能来完成任务,满足业务需求。
功能需求有时也被称作行为需求( behavioral requirement ),因为习惯上总是用“应该”对其进行描述:“系统应该发送电子邮件来通知用户已接受其预定”。
功能需求描述是开发人员需要实现什么。
系统需求(system requirement)用于描述包含多个子系统的产品(即系统)的顶级需求。
系统可以只包含软件系统,也可以既包含软件又包含硬件子系统。
人也可以是系统的一部分,因此某些系统功能可能要由人来承担。
业务规则包括企业方针、政府条例、工业标准、会计准则和计算方法等。
业务规划本身并非软件需求,因为它们不属于任何特定软件系统的范围。
然而,业务规则常常会限制谁能够执行某些特定用例,或者规定系统为符合相关规则必须实现某些特定功能。
有时,功能中特定的质量属性(通过功能实现)也源于业务规则。
所以,对某些功能需求进行追溯时,会发现其来源正是一条特定的业务规则。
功能需求记录在软件需求说明书( SRS )中。
SRS 完整地描述了软件系统的预期特性。
SRS 我们一般把它当作文档,其实, SRS 还可以是包含需求信息的数据库或电子表格;或者是存储在商业需求管理工具中的信息;而对于小型项目,甚至可能是一叠索引卡片。
开发、测试、质量保证、项目管理和其他相关的项目功能都要用到 SRS 。
除了功能需求外, SRS 中还包含非功能需求,包括性能指标和对质量属性的描述。
质量属性(quality attribute)对产品的功能描述作了补充,它从不同方面描述了产品的各种特性。
这些特性包括可用性、可移植性、完整性、效率和健壮性,它们对用户或开发人员都很重要。
其他的非功能需求包括系统与外部世界的外部界面,以及对设计与实现的约束。
约束(constraint)限制了开发人员设计和构建系统时的选择范围。
行业需求:企业在招聘软件测试人员时主要看中应聘者的项目经验、逻辑思维能力、一定的技术能力和综合素质,而对学历、年龄、性别、工作经验等的要求较低,相对于IT行业其他职位而言,软件测试的入行更加容易。
(计算机专业)要写软件的需求报告,性能需求 中的 适应性 是什么意...
展开全部 1. 功能性项目功能性指与一组功能及其指定的性质有关的一组属性,这里的功能是指满足明确或者隐含的需求的那些功能。
具体包括:? 适合性:与规定任务能否提供一组功能,以及这组功能的适合程度有关的软件属性,例如面向任务系统中由子功能构成的功能是否合适,表容量是否合适等等。
? 准确性:与能否得到正确或者相符的结果或者效果有关的软件属性。
? 互操作性:与其他指定系统进行交互的能力有关的软件属性。
? 依从性:使软件遵循有关的标准约定法规及类似规定的软件属性。
? 安全性:即与防止对程序技术局的非授权的故意或者意外访问的能力有关的软件属性。
如用户权限、动态口令、数据库字段加密等。
对于这组非功能需求来说,绝大部分是满足功能需求的情况,他并不需要采用额外的措施,而安全性是一个例外,它会涉及具体的技术性功能需求。
...
软件工程uml功能需求和非功能需求的区别
有效的需求分析过程可以从四个方面出发:用户问题识别、综合分析、确认需求规格、评审。
问题识别就是从系统角度来理解软件,确定所要开发系统的综合要求,并提出这些需求的实现条件,以及需求应该达到的标准。
这些需求包括:功能需求(需要实现什么);性能需求(什么指标);环境需求(如服务器机型、操作系统、数据库等);可靠性需求(发生故障的情况和概率);安全保密需求;用户界面需求;资源需求(所需的内存、CPU、带宽等);软件成本消耗与开发进度需求;预先估计以后可能增加扩展的内容;系统可能达到的目标等;其中除了功能需求外其他需求是很容易一次性识别和评估的,而功能需求需要我们通过多种方式方法来逐步识别和完善,后面的综合分析中就要针对功能需求进行逐步的确定和完善。
具体可以参考trufun.net网站“资料文档”栏目。
了解更多UML相关资料。
软件详细设计说明书
展开全部 面向对象软件设计说明书模板 1 概述 1.1 系统简述 对系统要完成什么,所面向的用户以及系统运行的环境的简短描述,这部分主要来源于需求说明书的开始部分。
1.2 软件设计目标 这部分论述整个系统的设计目标,明确地说明哪些功能是系统决定实现而哪些时不准备实现的。
同时,对于非功能性的需求例如性能、可用性等,亦需提及。
需求规格说明书对于这部分的内容来说是很重要的参考,看看其中明确了的功能性以及非功能性的需求。
这部分必须说清楚设计的全貌如何,务必使读者看后知道将实现的系统有什么特点和功能。
在随后的文档部分,将解释设计是怎么来实现这些的。
1.3 参考资料 列出本文档中所引用的参考资料。
(至少要引用需求规格说明书) 1.4 修订版本记录 列出本文档修改的历史纪录。
必须指明修改的内容、日期以及修改人。
2 术语表 对本文档中所使用的各种术语进行说明。
如果一些术语在需求规格说明书中已经说明过了,此处不用再重复,可以指引读者参考需求说明。
3 用例 此处要求系统用用例图表述(UML),对每个用例(正常处理的情况)要有中文叙述。
4 设计概述 4.1 简述 这部分要求突出整个设计所采用的方法(是面向对象设计还是结构化设计)、系统的体系结构(例如客户/服务器结构)以及使用到的相应技术和工具(例如OMT、Rose) 4.2 系统结构设计 这部分要求提供高层系统结构的描述,使用方框图来显示主要的组件及组件间的交互。
最好是把逻辑结构同物理结构分离,对前者进行描述。
别忘了说明图中用到的俗语和符号。
4.2.1 顶层系统结构 4.2.2 子系统1结构 4.2.3 子系统2结构 4.3 系统界面 各种提供给用户的界面以及外部系统在此处要予以说明。
如果在需求规格说明书中已经对用户界面有了叙述,此处不用再重复,可以指引读者参考需求说明。
如果系统提供了对其它系统的接口,比如说从其它软件系统导入/导出数据,必须在此说明。
4.4 约束和假定 描述系统设计中最主要的约束,这些是由客户强制要求并在需求说明书写明的。
说明系统是如何来适应这些约束的。
另外如果本系统跟其它外部系统交互或者依赖其它外部系统提供一些功能辅助,那么系统可能还受到其它的约束。
这种情况下,要求清楚地描述与本系统有交互的软件类型(比如某某某数据库软件,某某某EMail软件)以及这样导致的约束(比如只允许纯文本的Email)。
实现的语言和平台也会对系统有约束,同样在此予以说明。
对于因选择具体的设计实现而导致对系统的约束,简要地描述你的想法思路,经过怎么样的权衡,为什么要采取这样的设计等等。
5 对象模型 5.1 系统对象模型 提供整个系统的对象模型,如果模型过大,按照可行的标准把它划分成小块,例如可以把客户端和服务器端的对象模型分开成两个图表述。
对象图应该包含什么呢? 在其中应该包含所有的系统对象。
这些对象都是从理解需求后得到的。
要明确哪些应该、哪些不应该被放进图中。
所有对象之间的关联必须被确定并且必须指明联系的基数(一对一、一对多还是多对多,0..1,*,1..*)。
聚合和继承关系必须清楚地确定下来。
每个图必须附有简单的说明。
可能经过多次反复之后才能得到系统的正确的对象模型。
6 对象描述 在这个部分叙述每个对象的细节,它的属性、它的方法。
在这之前必须从逻辑上对对象进行组织。
你可能需要用结构图把对象按子系统划分好。
为每个对象做一个条目。
在系统对象模型中简要的描述它的用途、约束(如只能有一个实例),列出它的属性和方法。
如果对象是存储在持久的数据容器中,标明它是持久对象,否则说明它是个临时对象(transient object)。
对每个对象的每个属性详细说明:名字、类型,如果属性不是很直观或者有约束(例如,每个对象的该属性必须有一个唯一的值或者值域是有限正整数等)。
对每个对象的每个方法详细说明:方法名,返回类型,返回值,参数,用途以及使用的算法的简要说明(如果不是特别简单的话)。
如果对变量或者返回值由什么假定的话,Pre-conditions和Post-conditions必须在此说明。
列出它或者被它调用的方法需要访问或者修改的属性。
最后,提供可以验证实现方法的测试案例。
6.1 子系统1中的对象 6.1.1 对象:对象1 用途: 约束: 持久性: 6.1.1.1 属性描述: 1. 属性:属性1 类型: 描述: 约束: 2. 属性:属性2 6.1.1.2 方法描述: 1. 方法:方法1 返回类型: 参数: 返回值: Pre-Condition: Post-Condition: 读取/修改的属性: 调用的方法: 处理逻辑: 测试例:用什么参数调用该方法,期望的输出是什么…… 7 动态模型 这部分的作用是描述系统如何响应各种事件。
例如,可以建立系统的行为模型。
一般使用顺序图和状态图。
确定不同的场景(Scenario)是第一步,不需要确定所有可能的场景,但是必须至少要覆盖典型的系统用例。
不要自己去想当然地创造场景,通常的策略是描述那些客户可以感受得到的场景。
7.1 场景(Scenarios) 对每个场景做一则条目,包括以下内容: 场景名:给它一个可以望文生义的名字 场景描述:简要叙述场景是干什么的以及发生的动作的顺序。
顺序图:描述各种事件及事...
什么是功能性?
我们的软件产品或者项目,其需求都有三个层级和三个方面。
一、我们首先看需求的三个层次软件需求包括3个不同的层次――业务需求、用户需求和功能需求。
业务需求 (Business requirement)表示组织或客户高层次的目标。
业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。
业 务需求描述了组织为什么要开发一个系统,即组织希望达到的目标。
使用前景和范围(vision and scope)文档来记录业务需求,这份文档有时也被称作项目轮廓图或市场需求(project charter 或 market requirement)文档。
用户需求 (user requirement)描述的是用户的目标,或用户要求系统必须能完成的任务。
用例、场景描述和事件――响应表都是表达用户需求的有效途径。
也就是说用户需求描述了用户能使用系统来做些什么。
功能需求 (functional requirement)规定开发人员必须在产品中实现的软件功能,用户利用这些功能来完成任务,满足业务需求。
功能需求有时也被称作行为需求 (behavīoral requirement),因为习惯上总是用“应该”对其进行描述:“系统应该发送电子邮件来通知用户已接受其预定”。
功能需求描述是开发人员需要实现什 么。
注意:用户需求不总是...我们的软件产品或者项目,其需求都有三个层级和三个方面。
一、我们首先看需求的三个层次软件需求包括3个不同的层次――业务需求、用户需求和功能需求。
业务需求 (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服务的效率、提高员工的满意度等。
业务需求: 是要完组织的使命,达成组织的愿景的各个业务流程和业务单元具有的需求。
业务需求服从于组织需求。
用户需求: 用户级的需求,是在业务级的需求下,各个岗位协作完成业务而具有的需求。
我们在软件需求规格说明书中表述的需求其实主要是这一部分需求。
功能需求: 同样,它代表着产品或者软件需求具备的能力。
一般是管理人员或者产品的市场部门人员负责定义软件的业务需求,以提高公司的运营效率(对信息系统而言)或产品的市场竞争力(对商业...
如何进行软件需求分析
展开全部 1.概念需求的定义包括从用户角度(系统的外部行为),以及从开发者角度(一些内部特性)来阐述需求.关键的问题是一定要编写需求文档.我曾经目睹过一个项目中途更换了所有的开发者,客户被迫与新的需求分析者坐到一起.系统的分析人员说:"我们想与你谈谈你的需求."客户的第一反应便是:"我已经将我的要求都告诉你们前任了,现在我要的就是给我编一个系统".百事通而实际上,UGGs,需求并未编写成文档,因此新的分析人员不得不从头做起.所以如果只有一堆邮件、会谈记录或一些零碎的未整理的对话,你就确信你已明白用户的需求,那完全是自欺欺人.需求的另外一种定义认为需求是"用户所需要的并能触发一个程序或系统开发工作的说明".有些需求分析专家拓展了这个概念:"从系统外部能发现系统所具有的满足于用户的特点、功能及属性等".这些定义强调的是产品是什么样的,而并非产品是怎样设计、构造的.而下面的定义则从用户需要进一步转移到了系统特性:需求是指明必须实现什么的规格说明.它描述了系统的行为、特性或属性,是在开发过程中对系统的约束.从上面这些不同形式的定义不难发现:并没有一个清晰、毫无二义性的"需求"术语存在,真正的"需求"实际上在人们的脑海中,这个人们主要是指客户,但一般情况下,用户并不能描述自己的需要,只就需要系统分析人员根据用户的自己语言的描述整理出相关的需要再进一步和客户核对.系统分析员和客户需要确保所有项目风险承担者在描述需求的那些名词的理解上务必达成共识.任何文档形式的需求(例如如下将要描述的需求规格说明书)仅是一个模型,一种描述.2.需求分析的任务开发软件系统最为困难的部分就是准确说明开发什么.最为困难的概念性工作便是编写出详细技术需求,这包括所有面向用户、面向机器和其它软件系统的接口.同时这也是一旦做错,将最终会给系统带来极大损害的部分,并且以后再对它进行修改也极为困难.目前,国内产品的庞杂,一家企业可能有几个系统并立运行,它们之间接口是系统开发人员最头痛的问题.对于商业最终用户应用程序,企业信息系统和软件作为一个大系统的一部分的产品是显而易见的.但是对于我们开发人员来说,并没有编写出客户认可的需求文档,我们如何知道项目于何时结束?而如果我们不知道什么对客户来说是重要的,那我们又如何能使客户感到满意呢?然而,即便并非出于商业目的的软件需求也是必须的.例如库、组件和工具这些供开发小组内部使用的软件.当然你可能偶尔勿需文档说明就能与其他人意见较为一致,但更常见的是出现重复返工这种不可避免的后果,而重新编制代码的代价远远超过重写一份需求文档的代价,这些血的教训正在国内的软件开发者身上发生.近来,我遇到一个开发小组开发包括代码编辑器在内的一套内部使用的计算机辅助软件.不幸的是,当他们开发完这个工具后,发现这个工具不能打印出源代码文件,使用者当然希望有这个功能.结果这个小组只好手工抄写源代码文档以供代码检查.这说明那怕需求明确无误并构思准确,如果我们没有编写文档,软件达不到期望目标也只能是咎由自取了.相反的情况,我曾见一个要集成到"错误跟踪系统"中的简单界面写了一页需求说明.而操作系统系统管理员在为处理脚本时发现简单的一张需求清单竟是如此有用.他们依据需求对系统进行测试时,此系统不仅非常清晰地实现了所有必需功能,而且未发现任何错误.事实上,需求文档在开发过程中一直起指导作用.3.需求分析过程可把整个软件需求工程研究领域划分为需求开发和需求管理两部分更合适,如图4-1所示:图4-1 需求工程域的层次分解示意图需求开发可进一步分为:问题获取、分析、编写规格说明和验证四个阶段.这些子项包括软件类产品中需求收集、评价、编写文档等所有活动.需求开发活动包括以下几个方面:确定产品所期望的用户类别.获取每个用户类的需求.了解实际用户任务和目标以及这些任务所支持的业务需求.分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息.将系统级的需求分为几个子系统,并将需求中的一部份分配给软件组件.了解相关质量属性的重要性.商讨实施优先级的划分.将所收集的用户需求编写成文档和模型.评审需求规格说明,确保对用户需求达到共同的理解与认识,并在整个开发小组接受说明之前将问题都弄清楚.需求管理需要"建立并维护在软件工程中同客户达成的合同" .这种合同都包含在编写的需求文档与模型中.客户的接受仅是需求成功的一半,开发人员也必须能够接受他们,并真正把需求应用到产品中.通常的需求管理活动包括:定义需求基线(迅速制定需求文档的主体).评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它.以一种可控制的方式将需求变更融入到项目中.使当前的项目计划与需求一致.估计变更需求所产生影响并在此基础上协商新的承诺,这种承诺具体体现在项目解决方案上.让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪.在整个项目过程中跟踪需求状态及其变更情况.以...