385 lines
18 KiB
Plaintext
385 lines
18 KiB
Plaintext
Q/SY KLD
|
||
昆仑数智科技有限责任公司企业标准
|
||
Q/SY KLD
|
||
软件需求文档编写要求
|
||
RequirementsforWritingSoftwareRequirement
|
||
Documents
|
||
20XX-XX-XX发布
|
||
20XX-XX-XX实施
|
||
昆仑数智科技有限责任公司
|
||
发布
|
||
目
|
||
前
|
||
言
|
||
1范围.
|
||
2规范性引用文件.
|
||
3术语和定义.
|
||
4缩略语.
|
||
5需求文档编写基本原则.
|
||
6编写文档结构与内容规范
|
||
6.1文档头部信息..
|
||
6.2业务需求主体.
|
||
2
|
||
6.2.1需求背景/来源.
|
||
6.2.2业务价值.
|
||
6.2.3需求描述.
|
||
6.2.4影响分析...
|
||
6.2.5验收条件
|
||
6
|
||
6.2.6其它..
|
||
6.3研发需求主体.
|
||
6.3.1需求来源..
|
||
6.3.2优先级..
|
||
6.3.3功能架构..
|
||
6.3.4功能描述..
|
||
6.3.5非功能性需求描述.
|
||
8
|
||
6.3.6验收标准..
|
||
8
|
||
附录A
|
||
（规范性）
|
||
标题名称
|
||
10
|
||
A.1
|
||
10
|
||
附录
|
||
B
|
||
（资料性）
|
||
标题名称
|
||
11
|
||
B.1
|
||
11
|
||
参考文献.
|
||
12
|
||
前
|
||
言
|
||
本文件按照GB/T1.1—2020《标准化工作导则第1部分：标准化文件的结构和起草规则》的规定
|
||
起草。
|
||
本文件由××××（一层组织全称）提出。
|
||
本文件由昆仑数智科技有限责任公司科技与产品发展部归口。
|
||
本文件起草单位：（一层组织全称）
|
||
本文件主要起草人：
|
||
本文件审查人：
|
||
需求文档编写要求
|
||
1范围
|
||
本文件规定了软件开发过程中业务需求和研发需求文档编写的要求
|
||
本文件适用于昆仑数智企业软件开发过程中业务需求和研发需求文档的编写。
|
||
2规范性引用文件
|
||
下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文件，
|
||
仅该日期对应的版本适用于本文件；不注日期的引用文件，其最新版本（包括所有的修改单）适用于本
|
||
文件。
|
||
GB/T1.1-2020《标准化工作导则第1部分：标准化文件的结构和起草规则》
|
||
3术语和定义
|
||
下列术语和定义适用于本文件。
|
||
3.1
|
||
业务需求BusinessRequirements
|
||
客户/用户提出的核心目标
|
||
3.2
|
||
研发需求DevelopmentRequirements
|
||
系统需实现的具体功能
|
||
4缩略语
|
||
无。
|
||
5需求文档编写基本原则
|
||
清晰明确：使用简洁的技术术语，避免模翻描述；每条需求须独立成段，不可混杂多个功能点
|
||
可验证性：每条需求需附带验收条件（如"用户登陆响应时间<2秒”）。
|
||
唯一性标识：为每条需求分配唯一编号（格式：REQ-项目缩写-模块-序号，如REQ-ERP-AUTH-001)。
|
||
可追溯性：需求需关联到来源（如用户反馈、会议记录、竞品分析文档编号）。
|
||
6编写文档结构与内容规范
|
||
6.1文档头部信息
|
||
Q/SY KLD
|
||
文档头部固定包含以下信息：
|
||
·项目名称
|
||
●文档版本号（格式：v1.0.0，遵循语义化版本控制）
|
||
●编写/修订日期
|
||
·编写人/审核人
|
||
·适用范围（如核心系统、移动端模块）
|
||
6.2业务需求主体
|
||
6.2.1需求背景/来源
|
||
详细描述业务场景，包括当前的市场环境、竞争对手分析、用户需求变化等，以便更好地理解需求
|
||
的背景和重要性。为了更好的描述需求背景，可以考虑从业务驱动因素、问题场景描述等方面入手对需
|
||
求的背景进行描述。
|
||
·业务驱动因素
|
||
■核心问题：当前业务遇到的痛点或机会是什么
|
||
■示例：“现有订单系统无法支持秒级库存同步，导致超卖问题频发，近3个月用户投诉量增加
|
||
35%。”
|
||
■关键点：当前业务现状（数据化描述）；未满足的目标或问题后果（如效率损失、成本增加、
|
||
用户流失等）。
|
||
●问题场景描述
|
||
■具体场景：需求针对哪些用户或业务场景
|
||
■示例：“商家在促销活动期间需手动调整库存，操作繁琐且容易出错，平均耗时30分钟/次。”
|
||
■关键点：用户角色（如商家、运营人员）；具体操作流程或场景痛点。
|
||
●市场/行业背景
|
||
■外部因素：市场需求、竞争压力或行业趋势是否驱动了该需求？
|
||
■示例：“竞品已上线AI客服系统，用户满意度提升20%，我方需跟进以保持竞争力。”
|
||
■关键点：竞品分析、用户调研结果；行业标准或技术演进（如AI、自动化趋势）。
|
||
●利益相关者（Stakeholders）
|
||
■相关方诉求：哪些部门或角色需要该功能
|
||
■示例：“客服部门反馈现有工单系统无法自动分类问题，导致响应效率低下。”
|
||
■关键点：提出需求的部门或角色（如业务方、技术团队、管理层）；他们的核心诉求和目标。
|
||
●数据支持
|
||
■量化依据：用数据证明需求的必要性。
|
||
■示例：“调研显示，80%的用户因支付流程复杂放弃下单，导致转化率损失15%。”
|
||
■关键点：用户调研数据、业务指标（如转化率、错误率）；历史问题发生的频率或影响范围。
|
||
●政策/合规要求
|
||
■法规驱动：是否因法律法规、安全标准等必须实现
|
||
■示例：“根据《个人信息保护法》要求，用户数据导出功能需增加权限审批流程。”
|
||
■关键点：法规名称及具体要求；不合规的风险（如罚款、停业整改）。
|
||
·关联需求/系统
|
||
■土下文依赖：需求与其他功能或系统的关联性。
|
||
■示例：“本需求为供应链系统升级的一部分，需与ERP系统库存模块对接。”
|
||
■关键点：上游/下游依赖的系统或功能；整体项目规划中的定位。
|
||
完整示例：
|
||
当前会员系统的积分兑换功能仅支持实物商品，但用户调研显示：65%的用户希望积分可兑换视频平
|
||
台会员等虚拟权益；因无法满足需求，近6个月积分闲置率高达45%，导致用户活跃度下降。此外，
|
||
竞品（如A平台）已上线虚拟权益兑换功能，其会员续费率提升20%。为提升用户粘性并跟进市场趋
|
||
势，需扩展积分兑换场景，支持虚拟权益发放。
|
||
6.2.1.1千系人
|
||
列出业务相关千系人（客户、业务部门、用户代表等），针对每一类干系人的痛点进行分析。
|
||
6.2.1.2收集方法
|
||
描述如何收集业务需求（如访谈、问卷等）。
|
||
6.2.2业务价值
|
||
应明确需求的具体价值，包括对业务增长、用户体验提升、成本控制等方面的具体影响，帮助相关
|
||
方理解实施该需求的必要性。
|
||
需求价值的表达要避免模糊，尽量量化表达不要夸大，不要假设，区分短期和长期价值并且把用户
|
||
视角和业务视角结合。
|
||
可从以下几个角度入手：
|
||
●业务指标提升
|
||
■明确需求对关键业务指标（如收入、转化率、效率）的直接影响。
|
||
5万元。”
|
||
·用户体验优化
|
||
■描述功能对用户操作效率、满意度或留存率的提升。
|
||
存率提升10%。”
|
||
·成本降低或效率提升
|
||
■说明需求如何减少资源浪费、缩短流程耗时或降低运维复杂度
|
||
■示例：“引1入自动化部署工具后，版本发布耗时从2小时降至10分钟，团队产能提升30%。”
|
||
·风险控制或合规性
|
||
■说明需求如何规避法律风险或系统稳定性问题。
|
||
■示例：“实现数据加密存储后，可满足GDPR合规要求，避免潜在罚款（最高年营收4%）。
|
||
●战略或市场竞争优势
|
||
■关联企业长期战略目标或市场竞争需求。
|
||
■示例：“支持多语言功能后，可拓展东南亚市场，支撑公司年度海外营收增长20%的目标。”
|
||
·技术债缓解或可扩展性
|
||
■说明技术架构优化对未来需求的支撑作用。
|
||
■示例：“重构订单模块后，系统可支持未来3年日均百万级订单量的增长需求。”
|
||
6.2.2.1优先级
|
||
为每个需求分配优先级（高、中、低）。
|
||
6.2.2.2需求分类
|
||
需求属于功能需求、非功能需求还是接口需求。
|
||
6.2.3需求描述
|
||
6.2.3.1整体描述
|
||
整体描述聚焦于它所在的模块或者系统，从更高层级或者整体的角度描述需求的功能。根据需求的
|
||
特点可以描述他在业务架构中的坐标位置，或者明确业务上下游的交互关系，或者其它能够帮助开发人
|
||
员理解业务特点的方式。
|
||
6.2.3.2干系人业务流程
|
||
从干系人视角描述该需求的业务流程
|
||
6.2.3.3界面需求
|
||
该章节可选。
|
||
此处填入界面原型图
|
||
6.2.3.3.1界面字段说明
|
||
针对原型的界面展示字段和输入字段进行说明，格式如下：
|
||
字段名称
|
||
数据类型
|
||
长度
|
||
说明
|
||
6.2.3.3.2界面操作
|
||
针对界面原型的操作进行说明。格式如下：
|
||
序号
|
||
业务操作
|
||
说明
|
||
6.2.3.4处理逻辑详细说明
|
||
对于复杂的处理逻辑在此具体说明，比如涉及到后台处理逻辑，处理步骤。可以通过时序图辅助说
|
||
明。
|
||
6.2.3.5数据描述
|
||
数据项
|
||
数据类型
|
||
数据含义
|
||
触发条件
|
||
可选条件
|
||
姓名
|
||
字符型
|
||
必填
|
||
年龄
|
||
整型
|
||
必填
|
||
6.2.3.6非功能性需求
|
||
6.2.3.6.1性能需求
|
||
描述系统响应时间，最大并发访问等需求，
|
||
6.2.3.6.2隔离需求
|
||
描述项目采用的隔离策略，是逻辑隔离，还是物理隔离
|
||
6.2.3.6.3安全需求
|
||
描述用户认证、授权管理、链路传输、数据备份和归档等安全需求
|
||
6.2.3.6.4运行坏境需求
|
||
描述软件、硬件配套的要求，链路要求，以及系统可移植性的需求
|
||
6.2.3.6.5可靠性需求
|
||
描述系统运行的可靠性、可用性需求，是否需要HA、STANDBY、负载均衡等高可用余设计
|
||
6.2.3.7接口需求
|
||
与外部模块/系统的交互需求（如“与第三方支付平台对接”）。
|
||
6.2.4影响分析
|
||
该章节可选。
|
||
应对需求实施可能带来的风险和影响进行全面分析，包括对现有系统、业务、用户、技术风险与挑
|
||
战、资源投入和法律合规的影响。描述的时候可选择其中一个或者多个受到影响的因素进行描述。下面
|
||
对这些因素进行详细说明。
|
||
·系统影响
|
||
■模块/功能影响：需求涉及哪些现有模块或功能需要修改
|
||
支持角色分级。”
|
||
■接口影响：是否新增或修改接口
|
||
示例：“支付系统需提供新版退款API（v3），旧接口逐步废弃。”
|
||
■数据影响：数据结构、存储或流程是否变化
|
||
示例：“商品表新增预售开始时间字段，历史数据需批量初始化。”
|
||
●业务影响
|
||
■流程变更：业务流程是否需要调整
|
||
●示例：“财务结算流程需增加预售订单的结算周期（从T+1改为T+7）。”
|
||
■部门协作：哪些部门需要配合流程或规则变化
|
||
示例：“客服团队需培训预售订单的售后处理规则。”
|
||
■KPI关联：对业务指标（如转化率、客单价）的预期影响。
|
||
●示例：“预计预售功能上线后，客单价提升15%，但订单取消率可能增加5%。”
|
||
·用户影响
|
||
■用户体验变化：用户操作流程是否简化或复杂化
|
||
示例：“用户需在结算页手动选择“现货"或"预售"商品，操作步骤增加1步。”
|
||
■用户教育成本：是否需要引导用户适应新功能？
|
||
示例：“需在APP首页增加预售功能引导弹窗，持续推送3天。”
|
||
·技术风险与挑战
|
||
技术复杂度：是否存在技术难点或未知风险
|
||
·示例：“预售库存与现货库存的实时隔离需解决高并发下的数据一致性问题。”
|
||
依赖风险：是否依赖未经验证的技术或第三方服务
|
||
示例：“依赖第三方物流API的实时回调接口，需评估其稳定性（SLA99.9%）。”
|
||
·资源影响
|
||
■
|
||
人力投入：开发、测试、运维的预计工时。
|
||
示例：“后端开发：10人日，前端开发：5人日，联调测试：3人日。”
|
||
环境依赖：是否需要特殊测试环境或数据准备
|
||
示例：“需在测试环境模拟百万级预售订单压力测试。”
|
||
·法律与合规影响
|
||
政策合规性：是否涉及数据隐私、消费者权益等法规
|
||
示例：
|
||
“预售规则需明确标注发货时间，避免违反《电子商务法》第35条。”
|
||
完整示例：
|
||
影响维度
|
||
具体内容
|
||
风险/应对措施
|
||
系统性能
|
||
预售订单峰值预计达10万/分钟，需优化数据库
|
||
风险：数据库压力过大；
|
||
分库策略。
|
||
应对：分库+读写分离。
|
||
用户体验
|
||
部分用户可能因等待发货时间较长选择取消订
|
||
应对：提供预售订单取消补偿券
|
||
单。
|
||
（满100减10）
|
||
合规性
|
||
预售规则需在商品页显著位置展示发货时间。
|
||
风险：法律纠纷；
|
||
应对：法务团队审核文案。
|
||
6.2.5验收条件
|
||
该章节可选。
|
||
编写验收条件要明确输入与输出，避免模糊词汇，使用量化指标，采用“前置条件+触发动作+预期
|
||
结果"的框架进行描述，并且要对条件进行分类，比如：功能验收、性能验收、兼容性验收等，例如：
|
||
功能验收
|
||
描述系统在特定场景下的预期行为
|
||
■
|
||
例如：“当用户点击‘提交'按钮时，系统应保存表单数据并跳转到确认页面。”
|
||
性能验收
|
||
■
|
||
定义响应时间、吞吐量、资源占用等指标
|
||
例如：“系统在1000并发用户下，页面加载时间应小于2秒。”
|
||
兼容性验收
|
||
■
|
||
明确支持的平台、设备或者版本
|
||
例如：“功能需兼容Chrome100+、Safari15+及Firefox90+浏览器。”
|
||
安全性验收
|
||
■
|
||
涉及权限、数据保护等
|
||
例如：“用户密码加密存储，且连续3次登陆失败后锁定账户30分钟。”
|
||
用户界面（UI）要求
|
||
描述交互或视觉
|
||
例如：“错误提示应显示为红色文本框，并自动聚集到错误字段。”
|
||
?
|
||
用户验收测试场景
|
||
描述用户实际操作流程的验证
|
||
■例如：“用户从商品搜索到支付完成的端到端流程需成功执行。”
|
||
验收的分类不局限于这些情况，根据实际需求可自定义。
|
||
6.2.6其它
|
||
该章节可选。
|
||
可以增加其他相关信息，如实施的时间框架、预算、资源需求等。
|
||
6.3研发需求主体
|
||
6.3.1需求来源
|
||
指定研发需求是从哪个业务需要分解而来，要指定需求名称、需求编号和文档版本号。
|
||
6.3.2优先级
|
||
根据研发需求的重要性和紧迫性，按高中低三档分配优先级。
|
||
6.3.3功能架构
|
||
功能架构编写要求
|
||
●命名规范：
|
||
■一级模块：业务领域中心（如客户中心、订单中心）
|
||
■二级模块：[主体对象管理（如个人客户管理、集团客户管理）
|
||
■三级模块：[核心操作管理（如基础信息管理、权限配置）
|
||
●示例：
|
||
客户中心（一级）
|
||
一个人客户管理（二级）
|
||
一基础信息管理（三级）
|
||
一服务记录管理(三级)
|
||
一集团客户管理(二级)
|
||
一集团信息管理（三级）
|
||
一成员单位管理（三级）
|
||
6.3.4功能描述
|
||
6.3.4.1总体描述
|
||
功能性需求是一个总体的描述，遵循”作为<用户角色》我想要<结果>以便于<目的>”的书
|
||
写结构，是对功能的整体描述，细节放在子章节，每一个子章节是一个功能单元（功能点）。
|
||
6.3.4.2功能单元描述
|
||
功能单元的编写方法采用以下两种方式：
|
||
·建议以主状谓宾或主谓宾补的固定句式进行描述。
|
||
如：系统用户（主语）通过（介词）人员管理界面（名词）查询（谓语）用户信息（宾语），并且
|
||
可以修改（谓语）用户的基本信息（宾语）。
|
||
■主状谓宾：主语_状语+谓语_宾语或名词_名词+介词_动词_名词
|
||
■主谓宾补：主语_谓语_宾语_补语或名词_动词_名词_介词+名词
|
||
·应尽量避免将拆分表“子过程描述”内容堆叠于此。
|
||
配图：可使用UM红流程图描述关键功能流程，每个流程对应一张图。或通过图片来直观呈现页面
|
||
布局，展示清晰、准确即可。
|
||
6.3.5非功能性需求描述
|
||
该章节可选。
|
||
非功能性需求可以按如下类型进行描述：
|
||
·非功能性需求模板
|
||
■模板：系统应[性能描述]，以确保[业务目标或用户体验]。
|
||
■示例：系统应能够在5秒内响应用户请求，以确保用户不会感到等待时间过长。
|
||
业务规则需求模板
|
||
■模板：当触发条件]时，系统应[业务规则描述]，以便[业务目标]。
|
||
■示例：当订单金额超过1000元时，系统应自动应用10%的折扣，以便鼓励高价值订单。
|
||
安全性需求模板
|
||
■模板：为了[安全目标]，系统应[安全措施]，以便[保护措施描述]。
|
||
■
|
||
示例：为了保护用户数据，系统应要求用户在30分钟后未活动时自动注销，以便防止未授权
|
||
访问。
|
||
性能优化需求模板
|
||
■模板：为了[性能目标]，系统应[优化措施]，以便性能提升描述]。
|
||
■示例：为了提高页面加载速度，系统应优化数据库查询，以便将页面加载时间从10秒减少到
|
||
3秒。
|
||
月
|
||
用户界面需求模板
|
||
■模板：用户应能够[界面操作]，以便[用户目标]。
|
||
■示例：用户应能够通过点击“提交"按钮来提交表单，以便快速完成注册流程。
|
||
报告和监控需求模板
|
||
■模板：系统应提供报告类型]，以便[监控目标]。
|
||
■示例：系统应提供每日销售报告，以便管理层监控销售趋势。
|
||
集成需求模板
|
||
■模板：系统应与[外部系统集成，以便[集成目标]。
|
||
■
|
||
示例：系统应与财务系统集成，以便自动同步交易数据。
|
||
维护和升级需求模板
|
||
■模板：系统应[维护措施]，以便[维护目标]。
|
||
■示例：系统应定期进行安全更新，以便保持系统的安全性。
|
||
6.3.6验收标准
|
||
验收标准的编写原则是：可量化、可验证、完整覆盖（功能，性能，安全，文档四维度）
|
||
完整示例：
|
||
1.功能实现
|
||
（1）输入正确账号密码可跳转到首页（测试用例覆盖5种浏览器）
|
||
(2密码错误3次后锁定账户1小时（需模拟10次错误请求验证）
|
||
2.性能要求
|
||
（1）单接口响应时间≤200ms（压测500并发通过）
|
||
（2）登录成功率≥99.9%（持续24小时监控）
|
||
3.安全要求
|
||
(1）通过OWASPTop10漏洞扫描（报告无高危漏洞）
|
||
(2）密码传输加密（HTTPS+BCrypt算法验证）
|
||
4.交付文档
|
||
（1）提供API接口文档（含错误码说明）
|
||
（2）提交部署配置脚本（已通过Jenkins流水线验证）
|