有效需求分析二: 非功能性需求&需求管理部分

为什么要关注非功能性需求？
?决定了要将产品做的多好

描述产品的特征，或完成功能的方式

?在有些情况下，非功能性需求是一个项目的主要目的，也是产品成败的主要因素

?如果用户发现系统难用，运行缓慢，可靠性差，此时非功能就成为了主要需求

?案例：仓管系统

观感
?对产品的外观所期望的精神实质、情绪或风格。
?让自己的产品观感具备一些特点:

?保守，权威，平易近人，温和，具备艺术水准，昂贵，精美…

?示例：

应统一使用logo。
应和其他后台系统的风格保持一致。

?职责的主要承担者: UI
?软件已经走进千家万户，功能差别不大，此时 观感就很重要了

易用性(Usability)
?易用性使产品符合用户的能力以及对使用体验的期望
?易用性三原则：易见，易学，易操作
?如果不能识别目标用户的特征，就不要谈易用性。

?举例 - B端用户，都是小学文化农村户口，虽然起着英文名，但跟他讲英文他会懵逼，界面上就不要出现英文单词或专业术语。

?示例：

易于使用的需求：产品应帮助用户避免犯错。
个性化和国际化需求：产品应同时支持汉语，英语，阿拉伯语，并允许切换。
学习的容易程度：对于11岁以上的儿童，应该在3分钟内学会操作该app。
可理解性和礼貌需求：产品应该使用用户可以理解的符号和词语.
人群需求：产品应该能够红绿色盲使用。

?职责的主要承担者：UE/UX  
常见易用性需求

 用户的接受率或采用率

?因为引入该产品而导致的生产效率的提高
?错误率的降低
?被不同语种的人采用
?对残障人士可用
?被没有计算机经验的人使用

易用性需求是两方面综合作用的结果：SP & user，不要只关注一个，以用户为中心，但是要考虑买方的要求

执行需求

?对产品执行过程及结果的需求。
?常见考虑要素
?完成任务的速度
?结果的精度
?操作的安全性
?产品的容量
?允许的值的范围
?吞吐量，例如tps
?资源使用的效率
?可靠性
?容错能力和健壮性
?伸缩性
?职责的主要承担者：架构师 & 主程

        性能/效率

?定义：通常是指软件的“时间-空间”效率，而不仅是指软件的运行速度。

?度量： 响应时间(平均/最大)，CPU使用率，内存占用等。

?示例：

系统应该在0.25秒内识别一架飞机是敌人还是友军

用户每次操作的最大响应时间不得高于2秒

响应应该足够快，以避免打断用户的思路

产品必须每10秒读取一次传感器的值

云端配置更新后，产品必须在5分钟内下载新的配置并根据配置进行改变

    可靠性  Reliability

定义:指的是产品在规定的时间内，在规定的条件下，完成预定功能的能力

?度量：

MTBF——全称是Mean Time Between Failure，即平均失效间隔。

MTTR——全称是Mean Time To Repair，即平均恢复时间。就是从出现故障到恢复中间

的这段时间。MTTR越短表示易恢复性越好。

MTTF——全称是Mean Time To Failure，即平均无故障时间。系统平均能够正常运行多

长时间，才发生一次故障。系统的可靠性越高，平均无故障时间越长。

MTBF = MTTF + MTTR

?示例：

服务无故障运行时间占比应该高于99.9%，5分钟内请求错误率高于1%即判定为故障

伸缩性

?定义：系统可扩容缩容的能力

?一般针对预期的规格增长

?示例：

系统应该在2018年内达到亿级用户的支持能力

使用安全：对可能造成人身伤害，财产损失或环境破坏等所考虑到的风险的量化描述.
        示例：充电器应该保证在8千伏瞬时电压下不漏电。
精度：对产品产生的结果的期望的精度的量化描述。
        示例：所有金额都必须精确到小数点后两位
容量需求：指定处理的吞吐量和产品存储数据的容量
        示例：cs要有存储10亿个文件的能力，并具备5PB的容量
系统具备同时处理5000条呼叫的容量
寿命：指定产品预计的生存期
        示例：产品应该在最大维护预算范围内至少运行5年
操作环境
        对产品所处环境的要求. windows / 手机/ 弱光 / 远距离等等
        示例

预期的物理环境：产品所处的物理环境

    示例：产品应该能在弱光下使用

            产品声音不应该比周围环境高20分贝以上

与相邻系统接口：与伙伴应用或设备接口的需求

    示例：系统应该支持IE8及以上的浏览器版本

        系统可以展示office2003及以上版本制作的ppt

产品化需求：为了使产品可以发布或销售所必需的需求

    示例：产品应该以zip格式发布

        产品应该可以在线安装

发布需求：指定计划的产品发布周期等

    示例：产品一月内不应该发布超过一次

        产品必须向下兼容。

    可维护性:  可修复(恢复)性和可改进性的难易程度
            示例：

可使用trace工具在10分钟内定位bug

新增流量控制功能时，对原有代码的修改量应该不高于5%

    可扩展性

?定义：新增业务产品时，实现对现有产品无影响，透明上线新产品的能力

?示例：

    上架到应用市场时，不用更新客户端。

    安全性（security）
                ?保密性：未经授权不可见

?完整性：未经允许不可改

?可得性：保障合法使用，不被拒绝服务攻击，也不能因为维护操作或bug导致数据不可得

?示例：

访问控制需求：只有直接经理可以看到他的职员的个人记录。

完整性需求：数据不允许物理删除

隐私需求：产品应该在收集用户信息前告知用户。

审计需求：所有的操作都应该记录操作日志，以备审查。

免疫力相关需求：防止恶意软件或恶意攻击

?完整性还包括：检查，以防止正确的用户不正确的使用数据

    再一些异常情况如断电等事件后保障数据完整性（数据静默丢失）

    文化和政策需求

?受用户其他风险承担者的文化或政策影响而不得不重点关注的需求。
?由于人的习惯，宗教，语言，禁忌或偏见，可能会导致产品不被接受。
?有时候文化需求并不明显。但公司有全球业务，应该要关注，比如阿拉伯地区从右往左写。
?最佳方式是寻找对应文化的代表者来提供帮助，譬如中东地区，或者特定职业的用户。
文化需求：针对社会因素的需求，如果要针对外国市场，要特别注意这些需求
示例：产品应该记录欧盟所有国家及美国的公共假日
产品应该显示佛历
政策需求：针对政策因素的需求：
示例：为保护国家信息安全，产品应该只使用国产软件。
产品应该依据不同国家的交规来针对性导航。
产品要做敏感词过滤

    法律需求
        如 （数据保护，隐私保护，担保，消费者保护，消费者信用，知情权等，未成年人保护法？防沉迷？版权保护？GPL这种强行开源的协议等）

质量模型
?软件质量的定义：

软件产品中能满足给定需要的性质和特性的总体
软件具有所期望的各种属性的组合程度
顾客和用户觉得软件满足其综合期望的程度
确定软件在使用中将满足顾客预期要求的程度

?质量模型：

Jim McCall软件质量模型
Barry W. Boehm软件质量模型
FURPS/+软件质量模型
R. Geoff Dromey软件质量模型
ISO/IEC 9126软件质量模型
ISO/IEC 25010 软件质量模型

FURPS/+

Functional（功能性）：特性、功能、安全性；
Usability（可用性）：人性化因素、帮助、文档；
Reliability（可靠性）：故障频率、可恢复性、可预测性；
Performance（性能）：响应时间、吞吐量、准确性、有效性、资源利用率；
Supportability（可支持性）：适应性、可维护性、国际化、可配置性。

如何发现非功能性需求
1. 随时Wiki记录. 分类共享.
2. 从用例分析得到
3. 利用客户，非功能性需求本来就是吸引他们的主要原因


量化各个指标




需求规格化