什么是软件需求,什么是功能需求?——论需求的三个层次和三个方面...
我们的软件产品或者项目,其需求都有三个层级和三个方面。
一、我们首先看需求的三个层次 软件需求包括3个不同的层次――业务需求、用户需求和功能需求。
业务需求(Business requirement)表示组织或客户高层次的目标。
业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。
业务需求描述了组织为什么要开发一个系统,即组织希望达到的目标。
使用前景和范围(vision and scope)文档来记录业务需求,这份文档有时也被称作项目轮廓图或市场需求(project charter 或 market requirement)文档。
功能需求(functional requirement)规定开发人员必须在产品中实现的软件功能,用户利用这些功能来完成任务,满足业务需求。
功能需求有时也被称作行为需求(behavīoral requirement),因为习惯上总是用“应该”对其进行描述:“系统应该发送电子邮件来通知用户已接受其预定”。
功能需求描述是开发人员需要实现什么。
注意:用户需求不总是被转变成功能需求。
产品特性,所谓特性(feature),是指一组逻辑上相关的功能需求,它们为用户提供某项功能,使业务目标得以满足。
对商业软件而言,特性则是一组能被客户识别,并帮助他决定是否购买的需求,也就是产品说明书中用着重号标明的部分。
客户希望得到的产品特性和用户的任务相关的需求不完全是一回事。
一项特性可以包括多个用例,每个用例又要求实现多项功能需求,以便用户能够执行某项任务。
系统需求(system requirement)用于描述包含有多个子系统的产品(即系统)的顶级需求。
系统可以只包含软件系统,也可以既包含软件又包含硬件子系统。
人也可以是系统的一部分,因此某些系统功能可能要由人来承担。
业务规则包括企业方针、政府条例、工业标准、会计准则和计算方法等。
业务规划本身并非软件需求,因为它们不属于任何特定软件系统的范围。
然而,业务规则常常会限制谁能够执行某些特定用例,或者规定系统为符合相关规则必须实现某些特定功能。
有时,功能中特定的质量属性(通过功能实现)也源于业务规则。
所以,对某些功能需求进行追溯时,会发现其来源正是一条特定的业务规则。
功能需求记录在软件需求规格说明(SRS)中。
SRS完整地描述了软件系统的预期特性。
SRS我们一般把它当作文档,其实,SRS还可以是包含需求信息的数据库或电子表格;或者是存储在商业需求管理工具中的信息;而对于小型项目,甚至可能是一叠索引卡片。
开发、测试、质量保证、项目管理和其他相关的项目功能都要用到 SRS。
除此之外,对于需求层次,我们还有其它的分法: 组织级需求->业务需求->用户需求->功能需求(有时也叫行为需求)。
组织级需求:一般代表着组织的愿景和目标。
对于大的公司,一般是通过资深的咨询顾问和咨询公司得出的,呈现的方式是咨询报告。
比如在ITSM或者企业信息化这方面。
典型的组织级的需求是:降低成本、减少库存成本、提升IT服务部门在企业中的价值、通过ISO20000、提高IT服务的效率、提高员工的满意度等。
业务需求:是要完组织的使命,达成组织的愿景的各个业务流程和业务单元具有的需求。
业务需求服从于组织需求。
用户需求:用户级的需求,是在业务级的需求下,各个岗位协作完成业务而具有的需求。
我们在软件需求规格说明书中表述的需求其实主要是这一部分需求。
功能需求:同样,它代表着产品或者软件需求具备的能力。
一般是管理人员或者产品的市场部门人员负责定义软件的业务需求,以提高公司的运营效率(对信息系统而言)或产品的市场竞争力(对商业软件而言)。
所有的用户需求都必须符合业务需求。
需求分析员从用户需求中推导出产品应具备哪些对用户有帮助的功能。
开发人员则根据功能需求和非功能需求设计解决方案,在约束条件的限制范围内实现必需的功能,并达到规定的质量和性能指标。
当一项新的特性、用例或功能需求被提出时,需求分析员必须思考一个问题:“它在范围内吗?”。
如果答案是肯定的,则该需求属于需求规格说明,反之则不属于。
但答案也许是“不在,但应该在”,这时必须由业务需求的负责人或投资管理人来决定:是否扩大项目范围以容纳新的需求。
这是一个可能影响项目进度和预算的商业决策。
二、需求的三个方面 除了功能需求外,SRS中还包含非功能需求,包括性能指标和对质量属性的描述。
质量属性(quality attribute)对产品的功能描述作了补充,它从不同方面描述了产品的各种特性。
这些特性包括可用性、可移植性、完整性、效率和健壮性,它们对用户或开发人员都很重要。
其他的非功能需求包括系统与外部世界的外部界面,以及对设计与实现的约束。
还有一项称为可用性(usability)的质量属性,它规定了业务需求中“有效”(efficiently)一词的含义。
约束(constraint)限制了开发人员设计和构建系统时的选择范围。
约束,在产品的架构设计中,是需要被首先考虑的问题。
如果说产品的功能代表了产品的能力,那么产品的质量属性代表了产品的品质,产品的约束代表了产品必须去满足的或者适应的条件!用人说“...
【需求分析有哪几个层次】需求分析与程序设计有什么不同
按照传统软件工程的软件过程,区别如下: 1.需求分析--产生 软件功能规格说明书,需要确定用户对软件的需求,要作到明确、无歧义。
不涉及具体实现方法。
用户能看得明白,开发人员也可据此进行下面的工作(概要设计) 2.概要设计--产生 软件概要设计说明书,说明系统模块划分、选择的技术路线等,整体说明软件的实现思路。
并且需要指出关键技术难点等。
3.详细设计--产生 软件详细设计说明书,对概要设计的进一步细化,一般由各部分的担当人员依据概要设计分别完成,然后在集成,是具体的实现细节。
理论上要求可以照此编码。
什么是软件需求,什么是功能需求?
我们的软件产品或者项目,其需求都有三个层级和三个方面。
一、我们首先看需求的三个层次软件需求包括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)限制了开发人员设计和构建系...
如何进行软件需求分析
1.概念需求的定义包括从用户角度(系统的外部行为),以及从开发者角度(一些内部特性)来阐述需求.关键的问题是一定要编写需求文档.我曾经目睹过一个项目中途更换了所有的开发者,客户被迫与新的需求分析者坐到一起.系统的分析人员说:"我们想与你谈谈你的需求."客户的第一反应便是:"我已经将我的要求都告诉你们前任了,现在我要的就是给我编一个系统".百事通而实际上,UGGs,需求并未编写成文档,因此新的分析人员不得不从头做起.所以如果只有一堆邮件、会谈记录或一些零碎的未整理的对话,你就确信你已明白用户的需求,那完全是自欺欺人.需求的另外一种定义认为需求是"用户所需要的并能触发一个程序或系统开发工作的说明".有些需求分析专家拓展了这个概念:"从系统外部能发现系统所具有的满足于用户的特点、功能及属性等".这些定义强调的是产品是什么样的,而并非产品是怎样设计、构造的.而下面的定义则从用户需要进一步转移到了系统特性:需求是指明必须实现什么的规格说明.它描述了系统的行为、特性或属性,是在开发过程中对系统的约束.从上面这些不同形式的定义不难发现:并没有一个清晰、毫无二义性的"需求"术语存在,真正的"需求"实际上在人们的脑海中,这个人们主要是指客户,但一般情况下,用户并不能描述自己的需要,只就需要系统分析人员根据用户的自己语言的描述整理出相关的需要再进一步和客户核对.系统分析员和客户需要确保所有项目风险承担者在描述需求的那些名词的理解上务必达成共识.任何文档形式的需求(例如如下将要描述的需求规格说明书)仅是一个模型,一种描述.2.需求分析的任务开发软件系统最为困难的部分就是准确说明开发什么.最为困难的概念性工作便是编写出详细技术需求,这包括所有面向用户、面向机器和其它软件系统的接口.同时这也是一旦做错,将最终会给系统带来极大损害的部分,并且以后再对它进行修改也极为困难.目前,国内产品的庞杂,一家企业可能有几个系统并立运行,它们之间接口是系统开发人员最头痛的问题.对于商业最终用户应用程序,企业信息系统和软件作为一个大系统的一部分的产品是显而易见的.但是对于我们开发人员来说,并没有编写出客户认可的需求文档,我们如何知道项目于何时结束?而如果我们不知道什么对客户来说是重要的,那我们又如何能使客户感到满意呢?然而,即便并非出于商业目的的软件需求也是必须的.例如库、组件和工具这些供开发小组内部使用的软件.当然你可能偶尔勿需文档说明就能与其他人意见较为一致,但更常见的是出现重复返工这种不可避免的后果,而重新编制代码的代价远远超过重写一份需求文档的代价,这些血的教训正在国内的软件开发者身上发生.近来,我遇到一个开发小组开发包括代码编辑器在内的一套内部使用的计算机辅助软件.不幸的是,当他们开发完这个工具后,发现这个工具不能打印出源代码文件,使用者当然希望有这个功能.结果这个小组只好手工抄写源代码文档以供代码检查.这说明那怕需求明确无误并构思准确,如果我们没有编写文档,软件达不到期望目标也只能是咎由自取了.相反的情况,我曾见一个要集成到"错误跟踪系统"中的简单界面写了一页需求说明.而操作系统系统管理员在为处理脚本时发现简单的一张需求清单竟是如此有用.他们依据需求对系统进行测试时,此系统不仅非常清晰地实现了所有必需功能,而且未发现任何错误.事实上,需求文档在开发过程中一直起指导作用.3.需求分析过程可把整个软件需求工程研究领域划分为需求开发和需求管理两部分更合适,如图4-1所示:图4-1 需求工程域的层次分解示意图需求开发可进一步分为:问题获取、分析、编写规格说明和验证四个阶段.这些子项包括软件类产品中需求收集、评价、编写文档等所有活动.需求开发活动包括以下几个方面:确定产品所期望的用户类别.获取每个用户类的需求.了解实际用户任务和目标以及这些任务所支持的业务需求.分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息.将系统级的需求分为几个子系统,并将需求中的一部份分配给软件组件.了解相关质量属性的重要性.商讨实施优先级的划分.将所收集的用户需求编写成文档和模型.评审需求规格说明,确保对用户需求达到共同的理解与认识,并在整个开发小组接受说明之前将问题都弄清楚.需求管理需要"建立并维护在软件工程中同客户达成的合同" .这种合同都包含在编写的需求文档与模型中.客户的接受仅是需求成功的一半,开发人员也必须能够接受他们,并真正把需求应用到产品中.通常的需求管理活动包括:定义需求基线(迅速制定需求文档的主体).评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它.以一种可控制的方式将需求变更融入到项目中.使当前的项目计划与需求一致.估计变更需求所产生影响并在此基础上协商新的承诺,这种承诺具体体现在项目解决方案上.让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪.在整个项目过程中跟踪需求状态及其变更情况.以上几点说...
在软件工程中什么是需求分析?
一。
确定对系统的综合要求1. 功能需求这方面的需求指定系统必须提供的服务。
通过需求分析应该划分出系统必须完成的所有功能。
2. 性能需求性能需求指定系统必须满足的定时约束或容量约束,通常包括速度(响应时间)、信息量速率、主存容量、磁盘容量、安全性等方面的需求。
3. 可靠性和可用性需求可靠性需求定量地指定系统的可靠性。
可用性与可靠性密切相关,它量化了用户可以使用系统的程度。
4. 出错处理需求这类需求说明系统对环境错误应该怎样响应。
例如,如果它接收到从另一个系统发来的违反协议格式的消息,应该做什么?注意,上述这类错误并不是由该应用系统本身造成的。
5. 接口需求接口需求描述应用系统与它的环境通信的格式。
常见的接口需求有:用户接口需求;硬件接口需求;软件接口需求;通信接口需求。
6. 约束设计约束或实现约束描述在设计或实现应用系统时应遵守的限制条件。
在需求分析阶段提出这类需求,并不是要取代设计(或实现)过程,只是说明用户或环境强加给项目的限制条件。
常见的约束有:精度;工具和语言约束;设计约束;应该使用的标准;应该使用的硬件平台。
7. 逆向需求逆向需求说明软件系统不应该做什么。
理论上有无限多个逆向需求,我们应该仅选取能澄清真实需求且可消除可能发生的误解的那些逆向需求。
8. 将来可能提出的要求应该明确地列出那些虽然不属于当前系统开发范畴,但是据分析将来很可能会提出来的要求。
注意:举例让学生理解:这样做的目的是,在设计过程中对系统将来可能的扩充和修改预做准备,以便一旦确实需要时能比较容易地进行这种扩充和修改。
二 。
分析系统的数据要求任何一个软件系统本质上都是信息处理系统,系统必须处理的信息和系统应该产生的信息在很大程度上决定了系统的面貌,对软件设计有深远影响,因此,必须分析系统的数据要求,这是软件需求分析的一个重要任务。
分析系统的数据要求通常采用建立数据模型的方法(举例)。
三。
导出系统的逻辑模型综合上述两项分析的结果可以导出系统的详细的逻辑模型,通常用数据流图、实体-联系图、状态转换图、数据字典和主要的处理算法描述这个逻辑模型。
四。
修正系统开发计划根据在分析过程中获得的对系统的更深入更具体的了解,可以比较准确地估计系统的成本和进度,修正以前制定的开发计划。
软件需求分析在软件工程中的作用,有哪些软件需求分析的方法。
软件工程中包含需求、设计、编码和测试四个阶段,其中需求工程是软件工程第一个也是很重要的一个阶段,需求分析是要决定“做什么,不做什么”。
在一个软件项目中,软件需求包括三个不同的层次-业务需求、用户需求和功能需求-也包括非功能需求:业务需说明了提供给客户和产品开发商的新系统的最初利益,反映了组织机构或客户对系统、产品高层次的目标要求。
软件开发,能否获得成功,最重要的是需求分析的工作。
因此,软件需求分析能力和水平,对软件项目至关重要。
一般的分析方法和步骤如下:⑴首先调查组织机构情况 包括了解该组织的部门组成情况,各部门的职能等,为分析信息流程作准备。
⑵然后调查各部门的业务活动情况 包括了解各个部门输入和使用什么数据,如何加工处理这些数据,输出什么信息,输出到什么部门,输出结果的格式是什么。
⑶协助用户明确对新系统的各种要求 包括信息要求、处理要求、完全性与完整性要求。
⑷确定新系统的边界 确定哪些功能由计算机完成或将来准备让计算机完成,哪些活动由人工完成。
由计算机完成的功能就是新系统应该实现的功能。
常用的调查方法有: ⑴跟班作业 通过亲身参加业务工作来了解业务活动的情况。
这种方法可以比较准确地理解用户的需求,但比较耗费时间。
⑵开调查会 通过与用户座谈来了解业务活动情况及用户需求。
座谈时,参加者之间可以相互启发。
⑶请专人介绍。
⑷询问 对某些调查中的问题,可以找专人询问。
⑸设计调查表请用户填写 如果调查表设计得合理,这种方法是很有效,也很易于为用户接受的。
⑹查阅记录 即查阅与原系统有关的数据记录,包括原始单据、账簿、报表等。
通过调查了解了用户需求后,还需要进一步分析和表达用户的需求。
分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。
如何系统的进行用户需求分析
1.概念需求的定义包括从用户角度(系统的外部行为),以及从开发者角度(一些内部特性)来阐述需求.关键的问题是一定要编写需求文档.我曾经目睹过一个项目中途更换了所有的开发者,客户被迫与新的需求分析者坐到一起.系统的分析人员说:"我们想与你谈谈你的需求."客户的第一反应便是:"我已经将我的要求都告诉你们前任了,现在我要的就是给我编一个系统".百事通而实际上,UGGs,需求并未编写成文档,因此新的分析人员不得不从头做起.所以如果只有一堆邮件、会谈记录或一些零碎的未整理的对话,你就确信你已明白用户的需求,那完全是自欺欺人.需求的另外一种定义认为需求是"用户所需要的并能触发一个程序或系统开发工作的说明".有些需求分析专家拓展了这个概念:"从系统外部能发现系统所具有的满足于用户的特点、功能及属性等".这些定义强调的是产品是什么样的,而并非产品是怎样设计、构造的.而下面的定义则从用户需要进一步转移到了系统特性:需求是指明必须实现什么的规格说明.它描述了系统的行为、特性或属性,是在开发过程中对系统的约束.从上面这些不同形式的定义不难发现:并没有一个清晰、毫无二义性的"需求"术语存在,真正的"需求"实际上在人们的脑海中,这个人们主要是指客户,但一般情况下,用户并不能描述自己的需要,只就需要系统分析人员根据用户的自己语言的描述整理出相关的需要再进一步和客户核对.系统分析员和客户需要确保所有项目风险承担者在描述需求的那些名词的理解上务必达成共识.任何文档形式的需求(例如如下将要描述的需求规格说明书)仅是一个模型,一种描述.2.需求分析的任务开发软件系统最为困难的部分就是准确说明开发什么.最为困难的概念性工作便是编写出详细技术需求,这包括所有面向用户、面向机器和其它软件系统的接口.同时这也是一旦做错,将最终会给系统带来极大损害的部分,并且以后再对它进行修改也极为困难.目前,国内产品的庞杂,一家企业可能有几个系统并立运行,它们之间接口是系统开发人员最头痛的问题.对于商业最终用户应用程序,企业信息系统和软件作为一个大系统的一部分的产品是显而易见的.但是对于我们开发人员来说,并没有编写出客户认可的需求文档,我们如何知道项目于何时结束?而如果我们不知道什么对客户来说是重要的,那我们又如何能使客户感到满意呢?然而,即便并非出于商业目的的软件需求也是必须的.例如库、组件和工具这些供开发小组内部使用的软件.当然你可能偶尔勿需文档说明就能与其他人意见较为一致,但更常见的是出现重复返工这种不可避免的后果,而重新编制代码的代价远远超过重写一份需求文档的代价,这些血的教训正在国内的软件开发者身上发生.近来,我遇到一个开发小组开发包括代码编辑器在内的一套内部使用的计算机辅助软件.不幸的是,当他们开发完这个工具后,发现这个工具不能打印出源代码文件,使用者当然希望有这个功能.结果这个小组只好手工抄写源代码文档以供代码检查.这说明那怕需求明确无误并构思准确,如果我们没有编写文档,软件达不到期望目标也只能是咎由自取了.相反的情况,我曾见一个要集成到"错误跟踪系统"中的简单界面写了一页需求说明.而操作系统系统管理员在为处理脚本时发现简单的一张需求清单竟是如此有用.他们依据需求对系统进行测试时,此系统不仅非常清晰地实现了所有必需功能,而且未发现任何错误.事实上,需求文档在开发过程中一直起指导作用.3.需求分析过程可把整个软件需求工程研究领域划分为需求开发和需求管理两部分更合适,如图4-1所示:图4-1 需求工程域的层次分解示意图需求开发可进一步分为:问题获取、分析、编写规格说明和验证四个阶段.这些子项包括软件类产品中需求收集、评价、编写文档等所有活动.需求开发活动包括以下几个方面:确定产品所期望的用户类别.获取每个用户类的需求.了解实际用户任务和目标以及这些任务所支持的业务需求.分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息.将系统级的需求分为几个子系统,并将需求中的一部份分配给软件组件.了解相关质量属性的重要性.商讨实施优先级的划分.将所收集的用户需求编写成文档和模型.评审需求规格说明,确保对用户需求达到共同的理解与认识,并在整个开发小组接受说明之前将问题都弄清楚.需求管理需要"建立并维护在软件工程中同客户达成的合同" .这种合同都包含在编写的需求文档与模型中.客户的接受仅是需求成功的一半,开发人员也必须能够接受他们,并真正把需求应用到产品中.通常的需求管理活动包括:定义需求基线(迅速制定需求文档的主体).评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它.以一种可控制的方式将需求变更融入到项目中.使当前的项目计划与需求一致.估计变更需求所产生影响并在此基础上协商新的承诺,这种承诺具体体现在项目解决方案上.让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪.在整个项目过程中跟踪需求状态及其变更情况.以上几点说...
顾客需求的5个层次
略论客户需求的五个层次 看看我的答案:客户需求的五个层次//1、产品需求/2、服务需求/3、体验需求/4、关系需求/5、成功需求/所有的企业都在都在高度关注和研究客户的需求并强调“以客户的需求为导向”。
然而,没有多少企业真正地识别、把握和跟踪到了不断变化的客户需求。
客户需求的多样性、多变性、隐蔽性、复杂性使得人们难以驾驭。
因此,从纷繁多样的客户需求中找出其中的共性或规律性就显得十分重要了。
借助于马斯洛关于“人的需求五个层次”的分析模型和方法,并参考其他专家关于客户需求层次的论述,笔者认为,客户的需求也存在着五个层次,它们从低到高依此是:产品需求、服务需求、体验需求、关系需求、成功需求。
见下图:略论客户需求的五个层次 时间: 2008-5-15 来源:软通动力 作者:王传友 (责任编辑: 湛蓝) 略论客户需求的五个层次//1、产品需求/2、服务需求/3、体验需求/4、关系需求/5、成功需求/所有的企业都在都在高度关注和研究客户的需求并强调“以客户的需求为导向”。
然而,没有多少企业真正地识别、把握和跟踪到了不断变化的客户需求。
客户需求的多样性、多变性、隐蔽性、复杂性使得人们难以驾驭。
因此,从纷繁多样的客户需求中找出其中的共性或规律性就显得十分重要了。
借助于马斯洛关于“人的需求五个层次”的分析模型和方法,并参考其他专家关于客户需求层次的论述,笔者认为,客户的需求也存在着五个层次,它们从低到高依此是:产品需求、服务需求、体验需求、关系需求、成功需求。
希望对你有用。
转载请注明出处51数据库 » 软件需求 三个不同层次