文章目录

  1. 1. 易用性需求
  2. 2. 页面交互
    1. 2.1. 案例一 有效性校验
    2. 2.2. 案例二 潜在默认值规则
    3. 2.3. 案例三 注册用户与游客用户的区分
  3. 3. 功能逻辑
    1. 3.1. 案例一 涉及自身
    2. 3.2. 案例二 敏感信息
  4. 4. 可靠性需求
  5. 5. 兼容性需求
  6. 6. 性能需求
  7. 7. 安全性需求

我们在审批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攻击等,详细内容可以参考我之前的文章《如何防范常见的Web攻击》。

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

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

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

(完)

微信公众号

文章目录

  1. 1. 易用性需求
  2. 2. 页面交互
    1. 2.1. 案例一 有效性校验
    2. 2.2. 案例二 潜在默认值规则
    3. 2.3. 案例三 注册用户与游客用户的区分
  3. 3. 功能逻辑
    1. 3.1. 案例一 涉及自身
    2. 3.2. 案例二 敏感信息
  4. 4. 可靠性需求
  5. 5. 兼容性需求
  6. 6. 性能需求
  7. 7. 安全性需求