非功能性需求，不要成为项目的坑

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

原文地址：非功能性需求，不要成为项目的坑
博客地址：http://blog.720ui.com/

易用性需求

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

页面交互

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

案例一 有效性校验

有效性校验，有什么特别之处么，我们正常都会考虑到的 ? 我想说“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降级攻击等。

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

（完）

关键字：需求, 产品经理

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！