Chinaunix首页 | 论坛 | 博客
  • 博客访问: 5005462
  • 博文数量: 1194
  • 博客积分: 12961
  • 博客等级: 上将
  • 技术积分: 14366
  • 用 户 组: 普通用户
  • 注册时间: 2009-01-09 11:25
  • 认证徽章:
个人简介

偷得浮生半桶水(半日闲), 好记性不如抄下来(烂笔头). 信息爆炸的时代, 学习是一项持续的工作.

文章分类

全部博文(1194)

文章存档

2019年(170)

2018年(81)

2017年(80)

2016年(70)

2015年(52)

2014年(41)

2013年(51)

2012年(85)

2011年(45)

2010年(231)

2009年(287)

分类: 其他平台

2019-08-16 15:31:03


为什么要关注非功能性需求?
?决定了要将产品做的多好
描述产品的特征,或完成功能的方式
?在有些情况下,非功能性需求是一个项目的主要目的,也是产品成败的主要因素
?如果用户发现系统难用,运行缓慢,可靠性差,此时非功能就成为了主要需求
?案例:仓管系统



观感
?对产品的外观所期望的精神实质、情绪或风格。
?让自己的产品观感具备一些特点:
?保守,权威,平易近人,温和,具备艺术水准,昂贵,精美…
?示例:
应统一使用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. 利用客户,非功能性需求本来就是吸引他们的主要原因


量化各个指标




需求规格化







阅读(48) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~
评论热议
请登录后评论。

登录 注册