您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   Code  
会员   
   
 
     
   
 订阅
  捐助
非功能性需求,不要成为项目的坑
 
   次浏览      
 2018-11-01 
 
编辑推荐:

本文来自于720ui,文章介绍了易用性需求、可靠性需求、兼容性需求以及性能需求等,并配以实例进行讲解。

我们在审批case的时候,最容易忽略的部分就是非功能性需求。非功能性需求分析不透彻,或者被忽略,常常给项目埋下巨大无比的坑。这个坑,想必大家都或多或少遇到过吧。比如项目要交付的时候,交互或需求不明确或者有歧义导致项目返工或延期,安全问题考虑不周导致生产环节被攻击者恶意攻击,没有考虑性能导致遇到高流量的时候就悲剧了等场景。今天的话题,我们就来聊聊《非功能性需求,不要成为项目的坑》。

易用性需求

顾名思义,用户在使用过程中易理解,易操作等。页面描述要清晰,最高境界就是“零手册”,不能让用户理解有歧义,此外,一致性也是很重要的,比如输入内容校验规则,页面展示风格,类似模块的交互等等。比如,一个系统,有的地方是用瀑布式风格,有的地方使用正常的分页,在页面展示上就会有点奇怪,不是么?

页面交互

换句话说,就是页面交互中我们需要确认的一些常常容易忽略的问题。这里面的坑太多了,我举几个案例作为引子,希望引起大家的注意。

案例一 有效性校验

有效性校验,有什么特别之处么,我们正常都会考虑到的 ? 我想说“Are you sure?”,我们来看看下面两个场景。

首先,看看新浪微博的发布文章功能,并不是我们理解的所有中文,字母,数字,符合分别都算1个字哟,这里的2个数字才算1个字。所以,我们的产品中有存在这种场景,就需要和策划/需求人员确认清楚规则,而不是想当然咯。

然后,我们再看看微信公众号发布文章功能,正文内容限制是2万字,超过2万字就不让提交了。这也是一个非功能性需求,需要和策划/需求人员确认清楚文章字数限制,如果他们说希望无穷大,然后你答应了,请挖好坑把自己埋了吧。

案例二 潜在默认值规则

很多情况下,存在如果不填写会设置默认值的场景,此时你要确认清楚具体的默认值规则。比如,发布一个应用,默认是下架还是上架状态?设置权重,是否有默认值场景?再比如,文章摘要的场景也是一个很好的例子。微信公众号,摘要的规则就是如果不填写会默认抓取正文前54个字。

案例三 注册用户与游客用户的区分

如果是游客用户,下面的收藏、评论、点赞,交互场景如何呢?是屏蔽让游客用户无法看到,还是置灰禁止操作,还是弹出登录页面,让用户注册或者登陆。

功能逻辑

功能逻辑,也是一个很经常考虑的问题。这里面的坑也很多,我举几个案例,看看是否引起大家的共鸣。

案例一 涉及自身

比如,生日祝福功能,是否可以给自己祝福呢? 关注用户功能,可以不可以关注自己哈?这些都是需要考虑的,虽然从产品的角度而言没太大问题,但是从使用的角度,就存在一定的业务问题。

案例二 敏感信息

比如,服务端发送消息给客户端,如果单单从客户端的角度进行敏感信息的过滤,安全性上面就存在很大的风险。之前,我抓包分析过一些产品的接口数据,有的产品接口层面没有做屏蔽,只是简单的在页面加”*“符号替换,当然这些信息,被一览无余。

可靠性需求

例如,是否考虑容错性,是否考虑灰度环境,是否服务降级,是否考虑故障转移等。

兼容性需求

Web端是否考虑兼容市面上主流浏览器,比如是否需要兼容IE8、IE9,这也是比较头大的问题,需要一开始就要确认清楚,而不是开发过程中再去考虑。因为,IE8、IE9涉及技术选型上的问题,比如是否要用HTML5,跨域问题要如何处理,需要采用什么框架,是使用原生的方式,还是使用单页面框架React/Vue?

Android端,需要兼容哪些主流版本,4.x? 5.x? 6.x? 需要考虑哪些设备等。

性能需求

性能需求,也是一个非常重要的非功能性需求。简单的理解,性能就是在空间和时间资源有限的条件下,软件系统工作的如何?系统性能需求,有几个典型的指标:响应时间,并发用户数,TPS,资源利用率等。

试想,如果是电商系统,我们不去考虑性能,那么生产环境遇到稍微高一些的并发场景,服务器可能就奔溃了。

此外,业务方对性能指标有要求的场景,也需要去确认这个指标是否合理。现在,回头想想,我很早之前参与的网考系统,那时候要求并发用户要达到1万,实际上它的指标更像是在线用户数,而并发用户数不会达到这个峰值。

性能需求,还涉及是否需要负载均衡和集群,session的处理方案,对于这个有状态的session,是单独部署服务器,还是去session化,是考虑单应用模式,还是使用微服务模式等。

安全性需求

安全问题,一直是我们重视的问题。例如,是否存在SQL注入攻击,如何防范XSS攻击等。

最容易忽略的部分就是水平权限管理,水平权限问题在同一个角色上,系统只验证了访问数据的角色,没有对角色内的用户做细分,由于水平权限管理是系统缺乏一个数据级的访问控制所造成的,因此水平权限管理又可以称之为“基于数据的访问控制”。举个例子,比如我们之前的一个助手产品,客户端用户删除评论功能,如果没有做水平权限管理,即设置只有本人才可以删除自己的评论,那么用户通过修改评论id就可以删除别人的评论这个就存在危险的越权操作。这个层面,基本需要我们业务层面去处理,但是这个也是最为经常遗落的安全点。

此外,一些产品对安全问题还有其他要求。例如,我刚参与完成的某导航系统,要求进行漏洞扫描,安全生命周期的梳理,威胁建模,防止TLS降级攻击等。

所以,在产品开发之处,建议把产品需要考虑的安全问题列一个清单,而不是再开发完成之后,再去梳理应该要去考虑什么安全问题。

   
次浏览       
 
相关文章

需求分析师的能力模型
基于模型的需求管理方法与工具
需求管理工具DOORS 的接口
使用Web+EA实现基于模型的需求管理
需求经过大脑的过程:需求分析评估方法
 
相关文档

需求分析与需求管理
需求分析具体要求全解
需求分析与验证
需求分析的核心线索
基于UML的需求分析方法
 
相关课程

需求分析与管理
从需求过渡到设计
业务建模与业务分析
产品需求分析与管理
需求分析最佳实践与沙盘演练