non functional requirement constraint

非功能特性的约定和要求

这是一篇关于系统非功能性特性的顶层约束文档，可以视为文档顶层约束在系统特性的扩充更广泛和全面的说明

范围

非功能特性，另一个名字即叫做质量或者质量目标，因此本文定制内容的目标是涵盖以下且不仅限于以下特征的规定：

• 可维护性
  • 缩短故障或非预期行为时花费的时间
• 可扩展性
  • 可以在增加新功能时候对原有系统避免做出改动或仅做出最小化的改动
• 可伸缩性
  • 可以通过增强节点硬件配置（垂直伸缩）或增加运算节点（水平伸缩）来改进系统的吞吐量和响应时间
• 可测试性
  • 可以不改变或少改变系统定义的情况下，执行测试，最小化测试工作量
• 可靠性和可访问性
  • 尽可能的减少系统不可用或低性能运行时间
• 安全及隐私性
• 易用性（效率及满意度）
• 性能（吞吐量及响应时间）
• ...

内容

会从不同的形式侧面来规定如何来达成对支撑系统行为规定的各个特性要素的描述，包含以下且不限于以下方面：

• coding规范
• 接口形式
• 数据库设计
• 文档格式
• ...

即，这里更多的是从经验角度做出的一般性规定，而不是在探索一种新的关于分析方法

---

下面是素材积累

---

对需求的管理和控制

• 所有的功能性和非功能性定义都要做到有文案可查
• 功能性定义的文案要落实在需求管理工具系统（禅道 or 其他）中，并可以通过URL在其他位置予以引用
  • 如果无法约束外部输入的信息源共同使用一致的需求管理工具，那么接收需求的工程师有责任将该输入信息通过上传、附录、copy等形式来通过需求管理工具来持续进行维护
• 需求描述除了原始信息来源的文字记录，应当按以下格式从第一人称来进行提炼总结，以便进一步的识别功能特性和非功能特性的细节规定
  • 我作为XXX角色，期望系统具备YYY能力，从而可以实现ZZZ的价值
  • 举例，我作为一个管理员，希望系统可以提供重置用户密码功能，以便能让管理员可以帮助忘记密码的用户设定新的密码；
  • 【我作为一个管理员，在帮助用户重置密码的过程中，不应当让我接触到用户实际使用的密码，从而让有安全意识的用户觉得隐私并没有被侵犯，等等；我作为一个医生，我希望能随时看到目前某一工作日预约患者的预约时间列表，以便我能够为我的一个老客户选择一个我和他都能接受的时间来进行会面】
• 要识别原始需求信息（无论是来源于最终用户，还是需求收集者，如产品经理），工程师有责任识别需求背后的更多规定，让原始需求信息转换成一个可以进行开发的有明确目的和价值的规定