以《淘宝网》为例，描绘质量属性的六个常见属性场景

可用性分析:

场景设想:由于同时登陆淘宝网的人数过多造成登陆响应超时。

刺激源:淘宝网用户。

刺激:淘宝网服务器崩溃。

制品:淘宝网的服务器

环境:正常的操作

响应:无法登陆

响应度量:没有停机

 

可修改性分析:

场景设想：页面变动

刺激源:开发人员、活动项目组、淘宝用户。

刺激:希望修改界面。

制品:代码

环境:正常运行时

响应:修改不产生副作用

响应度量:在3小时内

 

性能分析:

场景设想:200万人希望登陆上淘宝网来选购想要的商品。

刺激源:200万淘宝网用户。

刺激:试图同时登陆淘宝网站进行选购商品。

制品:淘宝网站。

环境:正常模式(超载模式)。

响应:处理登陆请求。

响应度量:登陆等待时间不超过2秒。

 

安全性分析:

场景设想:某用户选中某件商品进行修改自己的收货地址并付款购买。

刺激源:淘宝网用户。

刺激:希望购买商品，修改数据，访问淘宝网用户服务。

制品:淘宝网用户信息系统、付款系统。

环境:用户和商家在线(离线)，达成交易。

响应:进行安全检测，保护资金支付环境安全以及动态显示商品购买后的状态。

响应度量:进行两次或以上的确认验证，商品属性验证，收货地址验证，付款密码验证等。

 

可测试性分析:

场景设想:单元测试人员想要测试搜索功能的性能。

刺激源:单元测试人员。

刺激:对淘宝网的搜索引擎代码加上模糊查询功能。

制品:具有模糊查询功能的查询模块。

环境:设计时、开发时、编译时。

响应:提供对搜索内容的访问，提供所查的值。

响应度量:在2~3秒内查找出与搜索内容相关的200条商品。

 

易用性分析:

刺激源:淘宝网用户。

刺激:淘宝网用户希望了解如何有效的使用系统，使错误降低，希望能了解系统特性以便可以快速上手购买商品。

制品:淘宝网站。

环境:在运行时。

响应:系统提供新手导航、帮助、小贴士、撤销、显示商品状态、找相似等等功能来响应用户对系统进行了解。

响应度量:按照步骤简练概括怎么做。