从市场业务、用户需求、产品功能、到技术特性，需求层级和类别的划分与管理
参考：如何进行需求管理https://www.zhihu.com/question/19844142/answer/2501446036
https://zhuanlan.zhihu.com/p/721870622
引用
IPD，Integrated Product Development，集成产品开发。是一套系统的、成熟的产品开发的管理思想、模式和方法。
IPD强调以市场需求作为产品开发的驱动力，将产品开发作为一项投资来管理。
IPD不是流程，流程反而是IPD体系的一部分。
IPD强调的是“第一次把事情做对”，而不是“没有时间第一次把事情做对，却有时间多次返工”。
IPD诞生于1996年，让IBM凤凰涅槃。
市场理解
IPD流程中，理解市场最重要。 理解市场：五看三定模型
市场管理(MM，Market Managem)流程
市场管理流程可分成以下六个主要步骤：市场评估、进行市场细分、进行组合分析、制定业务战略和计划、融合和优化业务计划、管理业务计划和评估绩效。
MM：从宏观角度分析市场、分析对手，得出战略规划SP、年度规划BP、产品开发路标Roadmap、具体版本的任务书（Charter），为IPD提供录入，见下图：
（1）SP(Strategic plan) / BP(Annual Business Plan)是公司各体系战略规划和年度商业规划的流程
（2）Roadmap路标是项目任务书开发流程(Charter Development Process，CDP)对产品进行规划的流程
（3）产品包需求(Offering Requirement, OR) 要分层描述，必须包括客户问题、系统特性、系统需求及其各层之间的跟踪。
OR(Offering Requirement) 即，供货要求, 或者产品包需求。产品包需求分层：客户问题＋系统特性＋系统需求，如下图：
产品包需求分层分类总模型，如下：
产品包需求应从客户的商业问题分析开始，然后确定解决这些问题需要的系统特性，最后对系统特性进一步细化形成若干个系统需求。
一、需求管理(OR，Offering Requirements)流程概述
需求本质：需求 = 问题+解决方案
需求的三要素
需求包含三个要素：用户，效用和业务场景。
原始需求（RR）、用户需求（UR）、产品需求（PR）、特性（Feature）和功能需求（FR）之间的关系可以概括为：原始需求是出发点，用户需求是核心，产品需求是实现方式，特性是功能的集合，功能需求是实现特定特性的具体要求。
- 原始需求（RR）是项目或产品开发的出发点，通常由组织或客户的高层次目标决定，例如业务需求BR。这些需求描述了组织为什么要开发一个系统，即组织希望达到的目标。
- 用户需求（UR）是用户的目标，或用户要求系统必须能完成的任务。用户需求描述了用户能使用系统来做些什么，它是需求分析的核心，确保产品满足最终用户的期望。
- 产品需求（PR）是实现用户需求的具体方式，包括如何设计和实现产品以满足用户需求。产品需求关注的是如何将用户需求转化为实际的产品功能。
- 特性（Feature）是一组逻辑上相关的功能需求的集合，为用户提供某项功能，使业务目标得以满足。特性是产品的功能集合，帮助实现用户的特定任务或目标。
- 功能需求（FR）是开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。功能需求描述了开发人员需要实现什么，是实现特性的具体要求。
这些需求层次共同构成全面的需求分析，确保项目满足各种技术、业务和用户方面的需求，以达到项目成功。
需求分层分类
需求的两种视角：
二、 角色与产品需求三个层次
2.1 新产品需求的完成需要哪些成员：
| 角色 | 成员 | 输出 | 需求层次 |
| 客户经理 | 销售总监和销售经理 | 《》 | B（Benefits） |
| 市场经理 | 产品市场经理和营销版块 | 《市场需求说明书》《产品设计规格说明书》 | A（Advantage） |
| 产品经理 | 全系产品经理 | 《产品包需求说明书》 | F（Function） |
| 系统工程师 | 底层设计、代码、UI， 能否确保系统稳定落地到客户端的人员 |
《特性树》 | F（Feature） |
产品相关需求文档：
市场需求说明书、产品包需求说明书、需求的分解分配、产品设计规格说明书
产品包需求说明书包含：功能需求、性能需求、属性需求、其他需求、资料需求
2.2 FFAB工具明确了产品功能和技术需求
使用FFAB工具，对新产品、新技术、新功能进行定位、评估。从用户的角度分析各要素之间的内在关系，由新产品功能分解出支撑关键技术以及功能给用户带来的利益，确定待开发的技术项目和产品卖点。
- B（Benefits）： 客户需要解决的问题。 使用这款产品或这项技术能带给使用者的好处。
- F（Function）： 解决这些问题需要什么的功能。研发的产品功能模块的卖点和优势；
- F（Feature）： 这些功能需要什么技术支持。 研发产品期待实现的各种功能模块的技术特性；
- A（Advantage）：功能优点、技术优点。 产品的优势（技术优势、材质优势、价格优势等等），即产品的独特性和竞争性；
FFAB模型能够起到“转换器”的作用，最好的做法是把产品经理、销售人员和技术开发人员聚在一起共同制作完成新需求、新产品、新功能。
三、 通用需求三个层次及三个方面
3.1 分法一（设备领域）
Refer：4-业务架构师眼中的需求是什么？ - 知乎 (zhihu.com)
业务需求BR、用户需求UR、产品需求PR
业务需求(Business requirement)、用户需求(user requirement)、系统需求(System requirement) { 功能需求(functional requirement)、非功能需求、设计约束 }。
业务需求BR：描述组织或客户的高层次目标，如”超越 xx 竞争对手的搜索引擎，解决用户查询信息的问题”。这类需求通常来自于企业内部的管理者、市场营销部门、产品解决方案部门或 B 端客户的决策者。
它描述了组织开发系统的初衷和期望达到的目标，描述于文档项目轮廓图或市场需求文档。
业务需求从总体上描述了为什么要开发系统（why），组织希望达到什么目标，有什么样的愿景。这些最高级别的需求数量很少（2－5 条）。
用户需求UR：用户需求是从用户视角描述。用户需求必须能够体现软件系统将给用户带来的价值 ，描述了用户能使用系统来做些什么（what），即用户的目标或期望系统能完成的任务，常用用例和场景描述表达。如搜索引擎可以描述“查找用户想看的内容”。
用户需求通常隐含了质量属性(性能)，包括响应速度、容量、可用性、可靠性、可恢复性、数据完整性等。例如用户输入关键词后可在 3 秒内响应。质量属性是非功能性需求的主要来源。
产品需求PR：产品需求实际上是开发人员对用户需求的响应，也就是解决方案。如上述用户需求可以通过“如通过关键词匹配输出查询结果”描述。
产品需求包括功能需求和非功能性需求（质量需求、系统需求、接口需求和约束)。
非功能性需求是产品需求包的重要组成部分，有时候甚至是影响产品成败的，例如用户等待网约车的时间通常不应超过 5 分钟，否则用户取消订单的概率会大幅增加。
下面两种是，质量要求 转化为 “软件需求”的分析方法：
（1）软件质量模型“ FURPS"，
- 【功能性需求】 1 功能性（Functionality）
- 【非功能性需求】2 可用性（Usability） 3 可靠性（Reliability） 4 性能（Performance） 5 可支持性（Supportability）
ISO/IEC 25010:2023 将软件质量划分为 9 个主要特性，每个特性进一步细化为子特性，形成多层次的评估体系。模型结构如下： 源引 https://www.cnblogs.com/suntroop/articles/19014602
| 质量特性 | 子属性 | 定义与示例 | |
| 1 | 功能适用性（Functional Suitability） | 功能完整性、正确性、适当性 | 确保功能覆盖用户需求（如金融软件精确计算利息）。 |
| 2 | 性能效率 （Performance Efficiency） | 时间特性、资源利用率、容量 | 高并发系统的响应速度（如电商秒杀活动支持百万级用户） |
| 3 | 兼容性（Compatibility） | 共存性、互操作性、跨平台（容器）技术 | 多系统共享资源互不干扰（如智能家居设备跨平台联动）。 |
| 4 | 交互能力（Interaction Capability）（取代旧版“可用性”） | 可辨识性、可学习性、可操作性、用户错误防护、包容性、用户粘性（原“用户界面美观性”） | 支持无障碍设计（如视障用户通过屏幕阅读器操作软件） |
| 5 | 可靠性（Reliability） | 成熟性、容错性、易恢复性、可用性 | 系统故障后快速恢复（如云服务的自动故障转移机制） |
| 6 | 安全性（Security） | 保密性、完整性、不可抵赖性、真实性、可核查性 | 数据加密与权限控制（如医疗系统采用区块链技术保护患者隐私） |
| 7 | 可维护性（Maintainability） | 模块化、易分析性、易测试性、可复用性 | 代码低耦合设计（如微服务架构支持独立模块升级） |
| 8 | 灵活性（Flexibility）（取代旧版“可移植性”） | 适应性、易安装性、易替换性、可扩展性 | 跨平台兼容（如容器化技术实现“一次构建，随处运行”） |
| 9 | 无害性（Safety）（新增特性） | 风险识别、故障安全、危险警告、安全集成 | 高风险系统自动停机保护（如核电站传感器触发紧急关闭） |
现在较新颖全面“质量模型”是, GB/T 25000.10（ISO/IEC 25010:2023） 隶属于《系统与软件工程系统与软件质量要求和评价(SQuaRE) （Systems and software Quality Requirements and Evaluation）系列标准。
GB/T 25000.51《系统与软件工程系统与软件质量要求和评价(SQuaRE) 第51部分:就绪可用软件产品(RUSP)的质量要求和测试细则》是软件测试的重要依据，也是软件测试实验室进行CNAS测试认证一定会用的一部标准。
（2）质量功能展开(Quality Function Deployment，QFD) 是一种将用户要求转化成软件需求的技术，旨在将客户的模糊需求转化为可量化的技术指标和工程特性。
为了达到这个目标，QFD将软件需求分为三类，分别是常规需求、期望需求和意外需求。
3.2 分法二（软件领域）
Refer:https://zhuanlan.zhihu.com/p/81261956
组织级需求 -> 业务需求(Business requirement) -> 用户需求(user requirement) -> 功能需求(functional requirement)（有时也叫行为需求）
组织级需求： 一 般代表着组织的愿景和目标。对于大的公司，一般是通过资深的咨询顾问和咨询公司得出的，呈现的方式是咨询报告。比如在ITSM或者企业信息化这方面。
典型 的组织级的需求是：降低成本、减少库存成本、提升IT服务部门在企业中的价值、通过ISO20000、提高IT服务的效率、提高员工的满意度等。这里不做展开。
3.2.1 业务需求（Business requirement）
是指项目运营方或客户高层次的目标。业务需求通常来自于项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。
业务需求描述了组织为什么要开发一个系统，即组织希望达到的目标。
用系统使用前景和范围（vision and scope）文档来记录业务需求，这份文档有时也被称作项目轮廓图或市场需求（project charter 或 market requirement）文档。
业务需求针对的是项目公司，描述的是项目公司想要如何解决用户的问题，如何满足用户的欲望，以及商业可行性，最后将利益最大化。
换句再白一点的话就是，项目公司要做的软件系统对应的是公司的哪项业务？这些业务的用途是什么。
3.2.2 用户需求（user requirement）
是指用户的目标，或者用户要求系统必须能完成的任务。用例、场景描述和事件——响应表都是表达用户需求的有效途径。
用户需求针对的是人，即业务使用者。也就是说用户能使用系统来做些什么，系统怎么来完成用户的想法或者达到用户的什么目的。
【 业务规则 】涵盖了企业方针、政府条例、工业标准、会计准则和计算方法等。业务规划本身并非软件需求，因为它们不属于任何特定软件系统的范围。
然而，业务规则常常会限制谁 能够执行某些特定用例，或者规定系统为符合相关规则必须实现某些特定功能。
有时，功能中特定的质量属性（通过功能实现）也源于业务规则。所以，对某些功能 需求进行追溯时，会发现其来源正是一条特定的业务规则。这是一个可能影响项目进度和预算的商业决策。
3.2.3 功能需求（functional requirement）
规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求，功能需求记录在软件需求规格说明（SRS）中。
功能需求有时也被称作行为需求 （behavīoral requirement），因为习惯上总是用“应该”对其进行描述：“系统应该发送电子邮件来通知用户已接受其预定”。
功能需求描述是开发人员需要实现什 么。
注意：用户需求不总是被转变成功能需求。
产品特性，所谓特性（feature），是指一组逻辑上相关的功能需求，它们为用户提供某项功能，使业务目标 得以满足。对商业软件而言，特性则是一组能被客户识别，并帮助他决定是否购买的需求，也就是产品说明书中用着重号标明的部分。客户希望得到的产品特性和用 户的任务相关的需求不完全是一回事。一项特性可以包括多个用例，每个用例又要求实现多项功能需求，以便用户能够执行某项任务。
【 系统需求与业务规则 】
【系统需求（system requirement）】是对包含多个子系统的产品，即系统的顶级需求进行描述的。这个系统可能仅包含软件，也可能同时包含软件和硬件子系统。值得注意的是，人也可以被视为系统的一部分，因此某些系统功能可能需要由人来执行/承担。
业务规则涵盖了企业方针、政府条例、工业标准、会计准则以及计算方法等。这些规则本身并不直接构成软件需求，因为它们不属于特定软件系统的范围。然而，业务规则经常会对谁能够执行特定用例或系统必须实现哪些特定功能做出限制。
有时，功能中的特定质量属性也源于业务规则。所以，对某些功能 需求进行追溯时，会发现其来源正是一条特定的业务规则。这是一个可能影响项目进度和预算的商业决策。
3.3 需求的全面性
软件需求分为三类：功能需求、非功能需求和设计约束。源引《信息系统项目管理师》
在软件需求规格说明书SRS，除了功能需求外，还包含非功能需求。
功能需求和非功能需求的核心区别在于：功能需求定义软件的行为（“做什么”），而非功能需求定义软件的品质（“怎么做”）。在2025年一个企业管理系统开发中，功能需求可能包括生成报表，而非功能需求则要求报表生成时间在5秒内。
【 非功能需求 】
非功能需求涵盖了性能指标以及对质量属性的详尽描述。质量属性是对产品功能描述的重要补充，它从多个角度刻画了产品的多元特性。
这些质量特性包括产品的可用性、可移植性、完整性、效率以及健壮性，它们对用户和开发人员都具有深远的影响。
此外，非功能需求还涵盖了系统与外部环境的交互界面，以及对设计和实现过程的约束条件。特别值得一提的是，可用性质量属性为业务需求中的“效率”一词提供了明确的定义。
【 质量属性与约束条件(Constraint) 】
约束条件在产品架构设计中占据着举足轻重的地位，它限制了开发人员在设计和构建系统时的选择范围。
因此，在考虑产品设计时，约束条件往往需要首先被纳入考量。质量属性与约束条件不仅描述了产品的特性和设计的约束，还确保了 产品功能设计成真。
反映软件产品某一方面【 质量特性或特征 】。如可靠性、安全性、易用性等。 [1]
（1）性能（Performance）效率指标，是指系统的响应能力，处理任务所需时间或单位时间内的处理量，例如响应时间、吞吐量等。
（2）可靠性（Reliability）是指软件系统在应用或错误面前，在意外或错误使用的情况下维持软件系统功能特性的基本能力。
- （2.1）容错（Fault-tolerant）出现错误后仍能保证系统系统继续运行，且自行修正错误。
- （2.2）健壮性（Robustness）是指在处理或环境中，系统能够承受压力或变更的能力，错误不对系统产生影响，按既定程序忽略错误。
（3）可用性（Availability）是系统能够正常运行的时间比例。
（4）安全性（Security）是指系统向合法用户提供服务的同时保护用户的隐私和数据安全，例如防止未经授权的访问、防止数据泄露等。
（5）可修改性（Modification）是指能够快速地以较高的性能价格比对系统进行变更的能力。
- （5.1）可维护性（Maintainability）局部修复使故障对架构的负面影响最小化。易于维护和升级，例如代码清晰、文档完整等。
- （5.2）可拓展性（Extendibility）因松散耦合更易实现新特征/功能，不影响架构。例如易于添加新的功能、易于扩展系统等。
- （5.3）可移植性（Portability）适用于多样的环境（硬件平台、语言、操作系统）。例如在不同的操作系统上、在不同的硬件上等。
- （5.4）结构重组（Reconstructability）不影响主体进行的灵活配置。具有良好的可重用性，例如模块化设计、设计模式等。
（6）可变性（Changeability）总体架构可变，体系结构经扩充或变更成为新体系结构的能力。
（7）功能性（Functionality）需求的满足程度，是系统所能完成所期望工作的能力。
（8）互操作性（Inter-operation）是指系统与外界或系统与系统之间的相互作用能力，通过可视化或接口方式提供更好的交互操作体验。
（9）易用性（Usability）是衡量用户使用一个软件产品完成指定任务的难易程度。易于使用，例如界面友好、操作简单等。
（10）可测试性（Testability）是指软件发现故障并隔离、定位其故障的能力特性，以及在一定的时间和成本前提下，进行测试设计、测试执行的能力。
|
也有一种说法叫做质量属性，主要分为开发期质量属性和运行期质量属性，二者分别关注软件开发阶段和软件运行阶段的质量特征。 |
需求编号命名格式参考：<BR/UR/SR/PR>-<F/P/Q-S/C>-<Module>-001-001
|
BR-Q- |
业务需求-质量 |
| UR-F-MGR | 用户需求-功能-管理模块 |
| PR-S- | 产品需求-安全 |
| SR-P- | 系统需求-性能- |
四、 IPD产品研发模式需求分层RR- IR-SR-AR
参考：一句话解释IPD的核心内容
https://vip.kingdee.com/knowledge/606166847435805184?specialId=605757666757139968&productLineId=40&isKnowledge=2&lang=zh-CN
需求管理模型，按层级划分为RR、IR、SR、AR。需求管理解决方案(实体产品) (kingdee.com)
原始需求（RR：Raw Requirement）
初始需求（IR：Initial Requirement）
客户问题（PB：Problem）
系统特性（SF：System Feature）
系统需求（SR：System Requirement）
分配需求（AR：Assigned Requirement）
流程变更需求（CR：Process Change Requirement）
附录 A: 需求相关模板
1. 需求澄清模板：需求采集卡/需求采集表
通过 Y模型分析法 摸清了用户的真实需求之后，需要通过一定的方式将需求收集起来反馈给产品研发团队，需求收集表 就是一种最常见的方法 。
产品需求分析的三要素是 用户、需求和场景，其中用户本质上就是有相关问题的人，结合场景分析是为了更全面准确地定义问题，简单来说就是带入用户角色，去思考在某个具体的场景下用户的真实需求是什么？
在产品需求收集表中，也要重点体现这3个要素，常见的需求收集表如下所示：
| 需求编号（可由需求人员填写） | 需求类型（可由需求人员填写): 功能、性能、接口、可维护性、可靠性、可用性、安全性、兼容性和法规性需求 |
| 功能需求 | |
| 来源(Who)（重要信息，方便追根溯源） | |
|---|---|
| 场景 (Where、When)（重要信息，用来理解需求发生的场景） | |
| 1.仪器开机，初始化完成，处于待机模式，用户已经移出试剂装载仓的所有试剂盒 2.仪器处于操作模式，有试剂用完需要卸载，且无测试要加样 |
|
| 描述 (What)（最重要的信息） | |
| 1.用户在待机模式下，可以卸载任意数量试剂，当试剂盒数量大于5时，自动分批卸载 2.仪器操作模式下，可以自动选择空闲时间卸载用完的试剂盒 |
|
| 原因(Why）（需求人员要保持怀疑的心，很多时候理由是假想出来的） | |
|
|
|
| 验收标准 (How) （见验收准则AC） | 需求重要性权重 (How much) |
|
|
|
| 需求生命特征 (When) | 需求关联 (Which) |
|
|
|
| 参考材料 | 竞争者对比 |
|
|
|
也可以使用如下简易版：
| 需求采集卡 | |
|---|---|
| 需求编号 | XXX |
| 提出时间 | xx年xx月xx日 |
| 需求类型 | 市场规划类、客户需求类、技术性能类、其他类 |
| 需求名称 | |
| 需求来源部门 | XXXxx研发一组 |
| 需求提出人 | 需求提出者的姓名和联系方式 |
| 需求优先级 | 紧急但不重要、不重要且不紧急、重要不紧急、紧急目重要 |
| 需求描述 | 详细描述业务需求或产品特性，包括功能、性能、可靠性、可用性等方面。 |
| 风险及影响 | XXXXX |
| 可行性分析 | |
2. 产品功能/特性待办清单PBL模板
| 编号 | 标题 | 描述 | 来源 | 优先级(重要/紧急) | $APPEALS | 卡诺KANO模型（BSA模型） | 优先级分类模型(MoSCoW模型) | 商业价值 | 工作量评估 | 实现难度 | 版本/迭代规划 | 负责人 | 状态 | 备注(DOD/问题/变更) |
| UR- | APP端用户登录模块，...... | 场景/分类 | 记录需求来源，包括：客户需求、内部需求、市场需求等 | 1~5级，5最高 | 价格（$ Price）、可获得性（Availability）、包装（Packaging）、性能（Performance）、易用性（Ease of use）、保证（Assurances）、生命周期成本（Life cycle costs）、社会接受程度（Social acceptance） | 需求分析维度；预置： B（basic）：基本需求（核心业务功能和特性） S（satisfied）：满意度需求（增值或附加业务） A（attractive）：兴奋型需求（少数特定场景的需求） |
需求分析维度；必须(must)、应有(should have)、可有(could have)、暂缓(won’t have this time,WHT)、不必(won’t have ever,WHE) | 1~5分 | 设计; 开发; 测试; |
1~5级，5最高 | 设计; 开发; 测试; |
设计 开发 功能、性能、可靠性验证 |
||
| PR- | ||||||||||||||
| SR- |
在需求池/清单中存放着收集到的大量的需求，那么这些需求都有什么样的属性：
| 需求属性 | 属性说明 |
| 编号 | 需求的顺序号，唯一表示 |
| 录入人 | 需求的录入人，负责解释需求 |
| 录入时间 | 需求的录入时间 |
| 模块 | 属于产品的哪一模块；比如登录或者注册 |
| 名称 | 用简洁的语言描述 |
| 描述 | 需求的描述：无歧义、完整性、可测试、一致性等 |
| 提出者 | 需求最早的提出人 |
| BUG编号 | 有一些BUG即为需求，统一管理 |
| 分类 | 新增功能、功能改进、体验提升、bug修复、内部需求 |
| 层次 | 基础、扩展（期望需求）、增值（可做、可不做，兴趣需求） |
| 重要性 | 重要程度，根据商业价值 |
| 紧急程度 | 高中低，根据商业价值 |
| 持续时间 | 符合市场多长时间，根据商业价值 |
| 商业价值 | 商业优先级，不考虑开发难度，群体决策 |
| 开发量 | 需求的开发工作量、表征实现难度 |
| 性价比 | 商业价值/开发量；用于决定先做哪个 |
| 状态 | 需求生命周期：待讨论、暂缓、拒绝、需求中、开发中、发布中 |
| 负责PD | 进入需求中后确定 |
| 开发工程师 | 进入开发中后确定 |
| 项目名称 | 需求的发布项目 |
| 发布时间 | 需求的发布时间 |
| 备注 | 其他任何信息：1、被拒绝的理由2、暂缓、重启的条件3、其他相关文档 |
| 编号 | 录入人 | 录入时间 | 模块 | 名称 | 描述 | 提出者 | BUG编号 | 分类 | 层次 | 重要性 | 紧急程度 | 持续时间 | 商业价值 | 开发量 | 性价比 | 状态 | 负责PD | 开发工程师 |
项目名称 |
发布时间 | 备注 |
| PR-F-001-001 | 功能 | ||||||||||||||||||||
| SR-P--001-001 | 性能 | ||||||||||||||||||||
| SR-Q--001-001 | 质量 | ||||||||||||||||||||
3. 需求用例模板
| 需求用例标识/编号 | HK001 | |
| 需求用例名称 | 订票系统 | 输入功能名称 |
| 描述： | 旅客使用订票用例完成旅客的订票活动，把航空公 司的机票预订给旅客 |
描述该功能点所能实现的业务功能 |
| 参与者/角色： | 旅客，航空公司 | 输入使用该功能点的角色、岗位。 |
| 用例的规格说明 | ||
| 功能点编号： | 输入功能编号 | |
| 优先级： | A(高） | 输入该功能的优先级 |
| 前置条件 PreConditions | 航空公司机票预订管理员已成功登录系统并具有售票的权限 | 完成该功能点的前提条件。 |
| 正常（主）事件流： Flow of events | 主事件流： 1.管理员选择“售票”选项，用例开始 2.打开售票窗体 3.旅客输入旅客身份证号，系统根据购票规则检查旅客身份证有效性 A1：旅客身份证无效 4.管理员输入待售票条码号，检查机票有效性 A2:机票无效 5.系统登记一条新的购票信息 6.系统检查旅客预定信息 A3:有预定 7.用例结束 |
此处描述系统处理的事件流步骤。 |
| 备选（异常和分支）事件流 Alternate flow | 异常和分支事件流： A1:旅客信息无效 (1).系统显示旅客信息无效的提示信息 (2).返回主事件流第3步 A2:机票无效 (1).系统显示机票无效提示信息 (2).返回主事件流第4步 A3：有预定 (1).系统提示预定信息，并取消预定 (2).返回主事件流第7步 |
此处描述异常及分支事件。 |
| 后置条件 PostConditions | 系统成功写入一条售票信息，旅客当前的购票数量加1 | 完成该功能点产生的结果。 |
| 特殊需求/约束 | 支持使用条码扫描仪输入旅客身份证号，购一张票时间不超过30秒 | 此处写对该功能点的一些特殊限定和要求。 |
| 业务规则 |
e.g.
| 用例编号 | UC003 |
|---|---|
| 用例名称 | 退货单管理 |
| 参与者（Actor) | 申请人/申核人 |
| 使用频率 | Always |
| 前置条件 | 已成功登录系统 |
| 触发条件 | 1、申请人要求添加/删除/修改退货单。 2、审核人要求审核退货单 |
| 成功后置条件 | 成功提交中请/审核单 |
| 失败后置条件 | 提交失败 |
| 涉众利益 | |
| 被扩展的用例 | |
| 被包含的用例 | 修改/删除退货单包含查看退货单 |
| 假设 | |
| 基本事件流 | 1、申请人填写退货单； 3、中请人提交退货单； 4、审核人审核； 5、审核人提交库房； |
| 护展事件流 （Altermative Flow) | 1a、申请人修改未审核的退货单。 4a、审核驳回，填写驳回意见 |
| 异常事件流 | |
| 字段列表 | 客户名称、订货时问、业务员、商品编号、商品名称、计量单位、单价、数量、金额 |
| 业务规则 | 1、中请人只能修改或删除属于自己的退货单。 2、审核人只能审核自己未审核的退货单 |
| 非功能性需求 | |
| 设计约束 | |
| 待解决问题 | |
| 修改历史记录 |
4 验收准则AC模板：
Given <在什么样条件下>
When <采取了什么行动>
Then <得到什么结果>
| 检查点序号 | Given | When | Then |
| 1 | 先选择综合功能，再选择维护， 在左边的表格中选择编号3 服务， 然后在右边的表格中选择校准 日期重置，点击选择按钮， 进入界面 |
免疫分析仪通道选择Channel2， 点击执行 |
弹出界面 V:CDRIAChannel:Channel2 |
附录 B: 测试相关模板
1.测试用例模板
Refer:https://www.cnblogs.com/suntroop/articles/18668197
| 用例编号 | |
| 用例名称 | |
| 模块/项目名称 | |
| 用例属性 | 功能测试 性能/负载测试、界面测试、兼容性测试、易用性测试、安全性测试 |
| 用例名称 | |
| 场景描述 | |
| 重要等级 | |
| 预置条件 | |
| 测试数据 | |
| 测试步骤 |
常用的测试用例设计方法: （1）黑盒测试方法： （2）经验测试方法： （3）白盒测试方法： |
| 预期结果 | 具体性能指标：响应时间、cpu/ram占用率、 |
| 实际结果/结论 | 通过 不通过 |
| 测试状态/备注 | |
| 测试人员、日期 |
e.g.
浙公网安备 33010602011771号