我要做的是一个基于SSH的门票售卖系统，在系统中常见的质量属性有：可用性、可修改性、性能、安全性、易用性。
可用性方面：
可用性是指系统正常运行时间的比例，是通过两次故障之间的时间长度或在系统崩溃情况下能够恢复正常运行的速度来衡量的。实现可用性的战术分为三类：错误检测（用来检测故障的健康监视）、错误恢复（检测到故障时的恢复）、错误预防（阻止错误演变为故障）。用于检测错误的3个战术是： 信号/响应、心跳、异常。用于错误恢复的战术有7种：表决、主动冗余、被动冗余、备件、shadow操作、状态再同步、检查点/回滚。用于错误预防的战术有3种：从服务中删除、事务、进程监视器。
修改用户密码方面，当用户创建完账号时，会创建初始密码，但之后可能认为密码不安全，从而想要修改密码，当修改密码时，需要确认密码，当密码和确认的密码不一样是时，则不能完成对密码的修改。所以当用户输入的密码和第二个确认密码不同时，则立刻返回修改密码界面进行重新修改，而不会直接把第一个密码保存起来；还有当买票时，剩余的票不足够了用户所买的情况；管理员删除用户时，如果用户有购票信息，则先删除所有该用户的购票信息，在删除用户信息。
实例一
|
刺激源 |
刺激 |
制品 |
环境 |
响应 |
响应度量 |
|
用户 |
输入的密码和确认密码不一样 |
系统 |
正常状态 |
重新返回修改密码界面。 |
1s之内 |
实例二
|
刺激源 |
刺激 |
制品 |
环境 |
响应 |
响应度量 |
|
用户 |
需要购买的票比剩余的票多 |
系统 |
正常状态 |
返回到票的数量显示界面，并且提示出票的数量不足 |
在1s之内 |
实例三
|
刺激源 |
刺激 |
制品 |
环境 |
响应 |
响应度量 |
|
管理员 |
删除用户信息时，该用户有购票记录。 |
系统 |
正常状态 |
先删除他的购票记录，之后再删除用户信息 |
在1s之内 |
可修改性方面：
关注的两个方面：两个关注点：可以修改什么？何时以及谁进行修改。可修改性的战术有：局部化修改(减少由某个变更直接影响的模块的数量)；防止连锁反应（限制对局部化的模块的修改) ；推迟绑定时间（控制部署时间和成本）。
用户或着管理员修改自己密码方面，在不影响别人密码的前提下，在5s左右完成；设计人员修改用户界面用户购买的票的详细信息的界面，在不影响其他功能的前提下修改代码，要求在4小时内完成代码修改和测试，不产生有副作用的变；最终用户想要增加票的属性，在不影响其他功能的前提下，修改代码并进行测试。
实例一
|
刺激源 |
刺激 |
制品 |
环境 |
响应 |
响应度量 |
|
管理员或用户 |
修改密码 |
系统 |
正常状态 |
查找改用户或管理员的密码，并且修改成新的密码 |
在5s之内 |
实例二
|
刺激源 |
刺激 |
制品 |
环境 |
响应 |
响应度量 |
|
开发人员 |
希望修改用户购票详情界面 |
系统 |
设计时 |
修改并验证后，没有副作用的影响 |
在4小时之内 |
实例三
|
刺激源 |
刺激 |
制品 |
环境 |
响应 |
响应度量 |
|
最终用户 |
增加票的种类 |
系统 |
设计时 |
修改并验证后，没有副作用的影响 |
在3小时之内 |
性能方面：
指系统的响应能力----即对外部刺激(事件)做出反应时所需要的时间或在某段时间内所处理的事件个数。
20人同时登陆进行买票等操作，查看系统是否响应正常。
实例一
|
刺激源 |
刺激 |
制品 |
环境 |
响应 |
响应度量 |
|
20人 |
试图同时登陆系统 |
系统 |
正常运行 |
用户的操作被处理 |
平均响应时间5秒 |
24小时每隔一个小时随机登陆一次，参看系统是否登陆成功。
实例二
|
刺激源 |
刺激 |
制品 |
环境 |
响应 |
响应度量 |
|
用户 |
没个一个小时随机登陆一次系统 |
系统 |
正常运行 |
用户的操作正常被处理 |
平均响应时间3秒 |
安全性方面：
安全性是衡量系统在向合法用户正常提供服务的情况下，阻止非授权使用的能力。
在售票管理系统中。管理员不能修改用户的基本信息以及用户的购票信息；用户不能查看别人的购票信息以及进行操作。
实例一：
|
刺激源 |
刺激 |
制品 |
环境 |
响应 |
响应度量 |
|
管理员 |
修改用户信息或者购票信息 |
系统 |
正常运行 |
操作被禁止 |
100%禁止操作 |
实例二：
|
刺激源 |
刺激 |
制品 |
环境 |
响应 |
响应度量 |
|
用户 |
查看其他用户信息 |
系统 |
正常运行 |
操作被禁止 |
100%禁止操作 |
易用性方面：
关注的是对用户来说完成某个期望任务的难易程度，分为：有效性、错误避免及错误处理、用户自信和满意度、可学习性。有用性和易用性很相似，可用性是指是否可以使用，而易用性是指是否方便使用。易用性运行时战术：一旦系统执行，就可以通过为用户提供关于系统正在做什么的反馈，以及为用户提供发出基于易用性命令的能力来增强易用性；易用性设计时战术：在测试过程中，通常会频繁修改用户接口。也就是说，易用性工程师将为开发人员提供对当前用户接口设计的修改。
用户注册后会直接进入系统，不需要再输入账号和密码。
实例一：
|
刺激源 |
刺激 |
制品 |
环境 |
响应 |
响应度量 |
|
用户 |
用户注册进入系统 |
系统 |
正常运行 |
注册成功后，进入系统 |
响应时间少于2s |
当用户登陆后，买票时，会自动显示用户的账号和姓名，当选完数量后，自动显示总价。
实例二：
|
刺激源 |
刺激 |
制品 |
环境 |
响应 |
响应度量 |
|
用户 |
用户买票 |
系统 |
正常运行 |
显示总价 |
响应时间少于2s |
以上是我的项目的质量属性以及质量属性场景，可能我的分析或许不是很完整，但是我会尽量把我的项目做得完整。一个项目的质量属性影响着项目的好坏，所以要想做好项目，必须先分析好自己的质量属性。