软件工程中的功能需求和非功能需求的区别是什么
我们的软件产品或者项目,其需求都有三个层级和三个方面。
一、我们首先看需求的三个层次软件需求包括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。
响应时间:分日常交互类、日常查询类、批量交易分别考虑。
日常交易指传统的大厅交互业务,如纳税申报、发票销售等,以及一次完成多笔业务处理的交易,如批量扣款等,日常交互类业务具有较高的响应要求。
查询类业务如登记资料查询、申报数据查询等。
查询业务由于受到查询的复杂程度、查询的数据量大小等因素的影响,需要根据具体情况而定,给出一个参考范围。
批处理业务如会计核算等业务处理,该类业务处理复杂、操作数据量大、处理时间长。
响应时间指标包括:平均响应时间参考值(秒)、峰值响应时间参考值(秒)。
2。
用户数:用户数要考虑用户数的增长情况,有以下指标:总用户数、峰值在线用户数、峰值并发用户数、平均在线用户数、平均并发用户数。
3。
吞吐量:系统交易量的估算。
指标有年交易笔数(笔/年)、高峰期交易笔数(笔/天)。
4。
数据存储量:每年的数据存储容量(G)及未来几年该数量的预期(增长)值。
指标包括累计存储容量(G)、年增长(G)。
二、系统可靠性:一般是窗口业务应在从星期一到星期五的所有工作日的工作时间是可以使用的;其它业务应满足7*24小时可以使用; 三、可扩展性:可实现负载均衡;日后若信息量较大,则系统可相应增加服务器实现扩展。
所谓非功能性需求,是指软件产品为满足用户业务需求而必须具有且除功能需求以外的特性。
软件产品的非功能性需求包括系统的性能、可靠性、可维护性、可扩充性和对技术和对业务的适应性等。
下面对其中的某些指标加以说明。
在这里可以看到非功能性需求涉及的范围很广,软件产品本身不是孤立存在的,还涉及到诸多外在环境的影响。
非功能性需求必须考虑软件既要可用,又要易用。
对于非功能性需求描述的困难在于很难像功能性需求那样,可以通过结构化和量化的词语来描述清楚,在描述这类需求时候我们经常采用软件性能要好,查询要在多少时间内出结果,软件健壮性要好等较模糊的描述词语。
这类描述词语都是脱离了软件的执行环境,人和相关的场景的描述,因此信息很难体现到软件架构设计和具体的实现中。
我们在架构设计中关注的安全,系统开发框架,并发和性能,异常日志等不是凭空产生出来的,而是来源于我们对非功能性需求的分析。
一个软件系统必须完整,因此不仅仅包括了可执行的程序,还包括了在线帮助,数据和用户管理,日志异常查询,自动升级等相关功能特征。
这些需求不仅仅是为了满足用户的需要,也是为了我们后续维护和监控系统的需要。
系统的可靠性,可维护性和适应性是密不可分的。
当系统出现故障和用户出现错误的操作后是否支持恢复,当用户在使用过程中遇到错误的时候是否可以立即定位问题,但业务场景和逻辑发生变化的时候系统是否支持,当网络不稳定或使用中异常中断的情况下系统是否都有相应的容错措施,这些都是需要在非功能性需求中考虑到的问题。
易用性也是我们在开发非功能性需求中必须要考虑到的问题,易用性同时还涉及到美工和UI界面,人机工程,交互式设计,心理学,用户行为模式等多方面的知识。
易用性的三原则就是易见,易学和易用或者叫为发现,易懂,效率。
易见就是各种功能操作不要藏得太深,用户很容易找到他们期望进行的各种操作;易学需要软件系统通过在线帮助,导航,向导等各种方式保证软件是可自学习的;易用的重点则在软件在熟练使用后应该可以更快的进行各项操作。
这三者相互间也存在冲突,需要平衡,而平衡的一个重点就是真正的做到以用户为中心进行设计,需要去细分场景和用户。
对于非功能性需求的描述,在描述过程中必须要强调到人,业务场景,环境等各方面的内容。
强调的目的就是要说明非功能性需求不是无限度的,任何一项非功能性需求的实现往往会付出更大的研发人力成本和硬件网络成本。
比如我们在描述一个表单的模糊查询功能的时候,如果简单的描述为所有查询都要在多少秒内完成,那么这种需求将很难得到满足,以下是一些可选的描述方式。
1.估计用户数为1万人,每天登录用户数为3000左右,网络的带宽为100M带宽。
2.在非高峰时间根据编号和名称特定条件进行搜索,可以在3秒内得到搜索结果。
3.当通过互联网接入系统的时候,期望在编号和名称搜索时最长查询时间<15秒。
软件工程的软件需求
软件需求包括 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. 功能性项目功能性指与一组功能及其指定的性质有关的一组属性,这里的功能是指满足明确或者隐含的需求的那些功能。
具体包括:? 适合性:与规定任务能否提供一组功能,以及这组功能的适合程度有关的软件属性,例如面向任务系统中由子功能构成的功能是否合适,表容量是否合适等等。
? 准确性:与能否得到正确或者相符的结果或者效果有关的软件属性。
? 互操作性:与其他指定系统进行交互的能力有关的软件属性。
? 依从性:使软件遵循有关的标准约定法规及类似规定的软件属性。
? 安全性:即与防止对程序技术局的非授权的故意或者意外访问的能力有关的软件属性。
如用户权限、动态口令、数据库字段加密等。
对于这组非功能需求来说,绝大部分是满足功能需求的情况,他并不需要采用额外的措施,而安全性是一个例外,它会涉及具体的技术性功能需求。
...
转载请注明出处51数据库 » 利用()产生软件功能需求和非功能需求