功能性需求

功能性需求是面向用户且明确具体的需求，由产品经理根据市场需求提炼出来。它们是产品生命周期中最重要的一环，并且产品开发人员必须完全按照需求文档实现功能，不能轻易变更。例如，电子商务系统中的优惠券功能通常包含以下需求：优惠券分类、细分领取人群和核销优惠券。

非功能性需求

非功能性需求是保障系统持续健康运转的辅助需求。以电子商务系统的优惠券为例，在促销活动期间发放大量优惠券时，如何防止用户集中领取优惠券时系统崩溃呢？活动结束后，如何回收服务器以节省资源呢？非功能性需求通常面向运维人员，它们同样重要，但有时可能没有操作界面，由架构师提出解决方案并推动各个业务开发部门接入相应的组件。这些辅助系统对业务系统性能影响较小，并且长期处于优化状态。

常见的非功能性需求

可伸缩性

可伸缩性是指系统根据外部负载自动调节计算能力。常见的做法包括水平扩展（增加服务器节点数量）和垂直扩展（增强单机处理能力）。合理扩容服务器数量应根据压测结果确定。在日常运维中，系统应能够自动化扩容少量机器以处理突发流量，并超出负载时发出警报。

可用性

可用性是指系统在规定时间内正常运行的能力，是衡量系统质量和稳定性的重要指标。例如，一个系统的可用性为 99.9%，表示在一年中的时间里，系统正常运行的时间占据了 99.9%。要计算可用性，可以使用以下公式：

可用性 = (总时间 - 停机时间) /总时间 100%

降低可用性的主要原因包括硬件故障、软件错误和自然灾害等不可抗力因素。对于大型互联网公司，系统可用性至关重要，他们通常采取异地多活的技术措施，在不同城市建立独立的数据中心以保证服务可用。

可维护性

可维护性是指系统升级的能力。修改或增加需求时，开发周期越短越好。影响可维护性的主要因素包括代码质量、文档齐全度和模块化设计。领域驱动设计是一种提高可维护性的设计方法论，但其实施成本高且沟通成本高。对于小团队或小型项目，提高可维护性可以做好以下两件事：

• 编写高质量的代码
• 采用模块化设计

一致性

一致性是指数据不能丢失或出错。在分布式系统中，保持数据一致性是公认的难题。原因如下：

• 网络延迟
• 节点故障
• 并发写入

为了保持数据一致性，可以使用以下技术：

• 事务
• 两阶段提交
• 副本机制

总结

需求开发中的非功能需求包括哪些

非功能性需求

4-1、系统需求（system requirement）用于描述包含多个子系统的产品（即系统）的顶级需求。系统可以只包含软件系统，也可以既包含软件又包含硬件子系统。人也可以是系统的一部分，因此某些系统功能可能要由人来承担。

4-2、业务规则包括企业方针、政府条例、工业标准、会计准则和计算方法等。业务规划本身并非软件需求，因为它们不属于任何特定软件系统的范围。然而，业务规则常常会限制谁能够执行某些特定用例，或者规定系统为符合相关规则必须实现某些特定功能。有时，功能中特定的质量属性（通过功能实现）也源于业务规则。所以，对某些功能需求进行追溯时，会发现其来源正是一条特定的业务规则。

4-3、功能需求记录在软件需求规格说明（ SRS ）中。 SRS 完整地描述了软件系统的预期特性。 SRS 我们一般把它当作文档，其实， SRS 还可以是包含需求信息的数据库或电子表格；或者是存储在商业需求管理工具中的信息；而对于小型项目，甚至可能是一叠索引卡片。开发、测试、质量保证、项目管理和其他相关的项目功能都要用到 SRS 。除了功能需求外， SRS 中还包含非功能需求，包括性能指标和对质量属性的描述。

4-4、质量属性（quality attribute）对产品的功能描述作了补充，它从不同方面描述了产品的各种特性。这些特性包括可用性、可移植性、完整性、效率和健壮性，它们对用户或开发人员都很重要。其他的非功能需求包括系统与外部世界的外部界面，以及对设计与实现的约束。

4-5、约束（constraint）限制了开发人员设计和构建系统时的选择范围，如局限于软件工程学科。 注：分清楚那些是业务需求、哪些是用户需求、哪些是功能性需求和非功能性需求对软件的开发有着重大的指导意义，绝不可以以偏概全，错误地去揣摩用户的心思；对于开发者而言，所有软件功能的开发我们都应该一一征求用户的意见，对需求有了清晰的认识后再进行实质性的开发工作。

非功能性需求

“我是谁？我从哪里来？要到哪里去？”，被西方人称为哲学上的三个终极之问，根据这个套路，我门来分析下软件研发过程中的非功能性需求。 它是软件质量的一个重要衡量指标，用于在度量系统在实现完系统性功能以后，交付及运行过程中的系统技术面要求的达成度，比如典型的三“高”要求； 它也是项目管理过程中甲方对乙方系统研发过程中提出的“设计约束”，诸如：开发平台、技术流派、关键实现等等方面的要求； 目前业界关于软件的非功能需求，一般就包括：质量属性要求和约束性要求； 非功能性需求作为功能性需求的补充，如其定义的那样主要保障了系统功能的正常并且稳定运行，它具有普适性，来源于传统行业的工作模式沉淀和提升。 非功能性指标去往何方？一般系统架构人员需要特别关注，他将对系统架构阶段进行分析设计并落地到具体的方面指标。 1、响应时间：指功能完成的时间，和客观环境、数据量级、主观感受等都有关系，比如包括：平均响应时间参考值(秒)、峰值响应时间参考值（秒）。 2、吞吐量：给定时间内系统可处理的事务/请求的数量等，比如QPS、TPS； 3、并发用户数：用来衡量系统的同步协调能力，我们更关注多个用户同时操作同一功能或数据时，对系统性能的影响，有以下指标：总用户数、峰值在线用户数、峰值[并发用户数 、平均在线用户数、平均并发用户数。 4、数据存储增量：每年的数据存储容量（G）及未来几年该数量的预期（增长）值。 指标包括累计存储容量（G）、年增长（G） 1、工作时间 满足业务的工作时间，一周到周五还是7×24小时； 2、灾备恢复时间 当系统故障，相关系统基础设施（中间件、数据存储、网络设施等）的恢复时间，核心指标：RTO，RPO； RTO用于衡量业务从停顿到恢复的所需时间，RPO用于衡量业务恢复所允许丢失的数据量。 1、弹性 负载均衡支持弹性扩容或缩容机器，业务流量切换顺滑，无影响； 2、兼容性 对于不同终端类型、版本的系统兼容性； 1、可运维 日志查询、系统参数修改、配置文件运行时更新、服务器监控告警、通知发送、运行时数据统计分析等； 2、运维易用性 运维不单提供系统人员，对业务人员友好性也需要考虑，包括UI、交互流程等于功能性要求有重合； 1、系统安全规范 架构面引入相关安全基础设施，加密机、CA中心、U盾等； 框架面定义安全技术规范、使用的技术框架，比如加密策略、加密算法，用户权限管理框架选型等； 功能设计面剥离安全性设计，进行单独设计，应对后续的安全漏洞，如AOP或者设计新的安全组件包等； 2、补丁自动升级 对于独立的安全设计，支持运行时的安全策略、算法、开关的升级，支持降级服务等； 1、网络百科2、灾备系统的衡量指标有哪些？不止RPO、RPO