所谓非功能性需求,是指软件产品为满足用户业务需求而必须具有且除功能需求以外的特性。软件产品的非功能性需求包括系统的性能、可靠性、可维护性、可扩充性和对技术和对业务的适应性等。下面对其中的某些指标加以说明。在这里可以看到非功能性需求涉及的范围很广,软件产品本身不是孤立存在的,还涉及到诸多外在环境的影响。非功能性需求必须考虑软件既要可用,又要易用。
对于非功能性需求描述的困难在于很难像功能性需求那样,可以通过结构化和量化的词语来描述清楚,在描述这类需求时候我们经常采用软件性能要好,查询要在多少时间内出结果,软件健壮性要好等较模糊的描述词语。这类描述词语都是脱离了软件的执行环境,人和相关的场景的描述,因此信息很难体现到软件架构设计和具体的实现中。我们在架构设计中关注的安全,系统开发框架,并发和性能,异常日志等不是凭空产生出来的,而是来源于我们对非功能性需求的分析。
一个软件系统必须完整,因此不仅仅包括了可执行的程序,还包括了在线帮助,数据和用户管理,日志异常查询,自动升级等相关功能特征。这些需求不仅仅是为了满足用户的需要,也是为了我们后续维护和监控系统的需要。
系统的可靠性,可维护性和适应性是密不可分的。当系统出现故障和用户出现错误的操作后是否支持恢复,当用户在使用过程中遇到错误的时候是否可以立即定位问题,但业务场景和逻辑发生变化的时候系统是否支持,当网络不稳定或使用中异常中断的情况下系统是否都有相应的容错措施,这些都是需要在非功能性需求中考虑到的问题。
易用性也是我们在开发非功能性需求中必须要考虑到的问题,易用性同时还涉及到美工和UI界面,人机工程,交互式设计,心理学,用户行为模式等多方面的知识。易用性的三原则就是易见,易学和易用或者叫为发现,易懂,效率。易见就是各种功能操作不要藏得太深,用户很容易找到他们期望进行的各种操作;易学需要软件系统通过在线帮助,导航,向导等各种方式保证软件是可自学习的;易用的重点则在软件在熟练使用后应该可以更快的进行各项操作。这三者相互间也存在冲突,需要平衡,而平衡的一个重点就是真正的做到以用户为中心进行设计,需要去细分场景和用户。
对于非功能性需求的描述,在描述过程中必须要强调到人,业务场景,环境等各方面的内容。强调的目的就是要说明非功能性需求不是无限度的,任何一项非功能性需求的实现往往会付出更大的研发人力成本和硬件网络成本。比如我们在描述一个表单的模糊查询功能的时候,如果简单的描述为所有查询都要在多少秒内完成,那么这种需求将很难得到满足,以下是一些可选的描述方式。
1.估计用户数为1万人,每天登录用户数为3000左右,网络的带宽为100M带宽。
2.在非高峰时间根据编号和名称特定条件进行搜索,可以在3秒内得到搜索结果。
3.当通过互联网接入系统的时候,期望在编号和名称搜索时最长查询时间<15秒。
有了这些场景和数据后,我们在进行架构设计的时候就可以有针对性的选择我们的开发框架和模式,数据库,软硬件环境配置已经复杂功能的具体实现方式等。同时这些需求还可以更好的指导我们对通过性能测试等工具对这些非功能性需求进行验证。
本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/sharptoolbox/archive/2008/03/21/2202279.aspx
分享到:
相关推荐
所谓非功能性需求,是指软件产品为满足用户业务需求而必须具有且除功能需求以外的特性。软件产品的非功能性需求包括系统的性能、可靠性、可维护性、可扩充性和对技术和对业务的适应性等。其大概包括:系统的完整性、...
目前能够找到的一份最详尽的信息系统肺功能性需求规范,这个东西在我们后期写非功能性需求的时候,帮助非常大,虽然是2014年的文件,但其中描述、内容完全可以复用。
系统的功能性需求与非功能性需求.doc
非运行时非功能性需求从系统的灵活性与可维护性、可扩展性与可伸缩性、运行环境、数据完整性、准确性与及时性、开放性与先进性、规范性与标准性、可行性与可实施性等方面给出了具体的要求。
这是一个需求分析中的肺功能需求分析的表格
应用软件 非功能需求 应用软件非功能性需求总体上包括质量属性需求和约束。质量属性需求包括运行期质量属性需求、 设计期质量属性需求,质量属性需求详细分类如下表所示:
这是北京国华软件培训中心高级需求分析师培训课程的课件
软件架构的非功能性需求指标和区域化支持.pdf
我们在审批case的时候,最容易忽略的部分就是非功能性需求。非功能性需求分析不透彻,或者被忽略,常常给项目埋下巨大无比的坑。这个坑,想必大家都或多或少遇到过吧。比如项目要交付的时候,交互或需求不明确或者有...
系统的功能性需求与非功能性需求
系统的功能性需求与非功能性需求.pdf
对非功能性需求从系统性能、可用性、安全性、可靠性以及可管理性五个方面进行描述。
2.4系统的非功能性需求 5 2.4.1用户界面需求 5 2.4.2软硬件环境需求 5 2.4.3软件质量需求 5 三、可行性分析报告 5 3.1技术可行性 5 3.2人员可能性 5 3.3时间、设备可能性 5 3.4系统工作量 5 3.5代码工作量 5 3.6文档...
功能性好理解,硬指标,开发过程中的里程碑,一定要啃下的山头,而非功能性需求更偏“软”,如App好不好用,速度快不快,设计是否反人类等。在我们的日常生活中,非核心、非会员,只要带了一个“非”字,往往都不是...
非功能性需求都包括哪些方面
时间如何安排的呢? 15:20 开始 15:35 写完摘要 16:00 写完第一页 16:40 写完第二页 17:15 写完第三页 17:20 交卷
功能性好理解,硬指标,开发过程中的里程碑,一定要啃下的山头,而非功能性需求更偏“软”,如App好不好用,速度快不快,设计是否反人类等。在我们的日常生活中,非核心、非会员,只要带了一个“非”字,往往都不是...
了解架构设计模式,以管理特定于平台即服务(PaaS)环境的非功能性需求(NFRs)。了解Codename:BlueMix(IBMPaaS云操作环境)的技术特征,看看Codename:BlueMix如何为可靠、高度可用且可扩展的应用程序的设计和创建提供...