PRD-非功能性需求

我们常说要加一个功能,或者扩展已有功能。有没有考虑过,功能之外的东西呢?今天给大家分享,非功能性需求。

定义

我们总是关注功能上的需求,忽略非功能需求。

功能性需求

功能性需求,指的是产品必须执行的动作,不是质量要求。且此类需求需要避免歧义,注意用词。

大体上可以分为:

  • 产品需要哪些功能?

  • 这些功能是为解决哪些问题?

  • 功能与问题之间的追踪是什么样的?

  • 这些功能能够改变公司的业务问题吗?

  • 功能需求如何测试?如何验收?

以自行车为例。自行车又叫单车, 通常是二轮的小型陆上车辆 。那么对应的功能性需求,我认为至少包含:

  1. 传动系统,能让人的踩踏变成轮子向前的动力
  2. 导向系统,能控制行驶的方向
  3. 制动系统,能进行减速、停止驾驶等

非功能性需求

产品必须具备的属性,使产品可靠、易用,体验更好。注意不要写解决方案,消除技术成分。

一般包含:

  • 产品需要什么样的质量标准?

  • 易使用性、易扩展性、性能是什么样的要求?

  • 如何度量?如何验收?

  • 产品有什么约束条件?

还是以自行车为例,非功能性需求可以是:

  1. 使用时自减少颠簸。具体方案可以是用橡胶轮子取代木轮,也可以是增加避震缓冲器。
  2. 使用时候要省力。具体方案可以是减少传动系统动力损耗,也可以是增加变速器辅助爬坡,还可以是增加助力系统。

必要性

很多时候,项目成员都说没时间,这样就能用了,不关注非功能需求。但是又老遇到各种问题,系统很不稳定。

常见问题

问题 所属类型
给客户现场演示,老是出现问题 性能需求
对比竞品,不好看 观感需求
XX功能,方案很NB。但是销售都不会用,产品内部也没几个人知道怎么用 易用性需求
APP请求了好多权限,客户要求给出说法。请求对应权限,是哪个功能要 安全性需求
后台采集定位,iOS上架难度大 法律需求

当然,现场演示这种,基本都会出问题。但不能否认,必须确保性能。网络正常,5秒转不出来一个页面,肯定是存在问题的。

行动计划

描述

非功能性需求 描述
观感 预期的外观
易用性 基于预期用户的操作水平作出
操作 产品预期的操作环境
性能 多快、多大、多精确、多安全、多可靠等
可维护、可移植 产品的可改动性必须达到什么水平,例如增加一个功能
安全性 产品的安全性、保密性和完整性
文化与政策 人的因素
法律需求 满足适用的法律

以易用性为例子,讲一下怎么一步步消除技术成分:

  1. 产品将使用一个鼠标
  2. 产品将使用一种指点设备
  3. 产品将允许用户直接操作所有的界面元素

发现

是谁或是什么 它们或它是否有以下需求
用户 观感、易用性、安全性、文化/政策
操作环境 可操作性、性能、可维护性
顾客、客户 文化/政策
相邻系统 法律、可操作性、性能

以批量生成帐号为例,讲述下具体的发现过程:

  1. 制造商的IT部相关人员,为经销商生成帐号(功能诉求1,制造商管理经销商帐号)

  2. 该行业,全国类型大企业,一般以省为单位设置一级经销商,也就30多个一级经销商(目标行业大背景)

  3. 考虑到部分制造商是区域型企业,某企业经销商数量将近一千(特殊场景)

  4. 一般系统上线,采用分批上线策略(具体策略)

  5. 为了用户的便利性(相关需求,易用性需求),需要支持批量生成帐号,一次300条记录(性能需求)

最终的需求描述很简单:批量生成经销商帐号,需要支持一次300条记录

明确定位

非功能性需求也不是一概而论,需要结合产品的策略和所在行业,进行清晰的定位。

举个例子,企业级的SaaS产品,面向消费品行业的销售人员,对应的非功能性需求评分如下(满分10分):

非功能性需求 评分
观感 5
易用性 7
操作 6
性能 8
可维护、可移植 10
安全性 9
文化与政策 5
法律需求 8

假如是个金融相关的产品,法律需求肯定是10分的。以P2P为例,没有信用担保,始终就是存在法律风险的。即便有存管银行,银行只进行资金的监控,防止挪用,不进行信用担保。

解答迷津

现状 疑惑 方案
产品使用了APP,要做各系统版本的兼容 不知道市场上系统版本占有率 善用国内报告
APP端, 要做各机型的兼容 不清楚哪些机型受欢迎 BAT研究报告,国家互联网应急中心报告
产品有Web端,要做浏览器的兼容 大体知道有几款浏览器,但不清楚客户现有的浏览器主要是什么,也不知道各浏览器占比 BAT研究报告,国家互联网应急中心报告
销售使用笔记本演示系统,体验不好。要在大屏幕和小屏幕上,都保证基本的用户体验 l仅仅知道1080P,2K以及笔记本屏幕这种通用概念,不清楚有哪些分辨率,也不知道对应占比 BAT研究报告,国家互联网应急中心报告
目前没关注性能需求,补充起来挺麻烦 性能指标不清晰,每个都定义好麻烦 参照业内标准,设置统一规范。如Web端3秒响应,APP端1.5秒响应。数据较多的页面,可以通过进度条、懒加载等方式进行优化
要求产品简单易学,培训成本低 无法界定,什么是简单易学 一般是经过培训后,一定比例的用户,能在指定时间内,完成特定的任务
非功能性需求描述很困难 不知道这个非功能需求,是否可以实现,是否合理 和开发经理保持沟通,或询问有经验的产品同事

需求验证

方面 判断标准
功能性需求 确保功能被正确地执行
非功能性需求 量化度量,引入该产品的3个月之内,60%的用户将用它来完整规定的工作。在这些用户之中,将有75%对产品表示赞许。

举个例子:

描述:当未经培训的公众第一次尝试使用该产品的时候,它应该易于学习。

理由:潜在用户可能从未使用过这类产品。

验收标准:由业务人员组成的测试小组中,90%的人在第一次使用该产品的时候,能在45秒内成功地登录APP,进行考勤打卡。


  目录