软件质量工程 04
软件需求规格说明书 (Software Requirements Specification,SRS)
定义与目的
- 目的 (Purpose):清晰定义正在开发的系统的文档(a document that clearly define the system under development)
- 预期受众 (Intended audience):系统的所有者、开发团队和最终用户
- 范围 (Scope):系统需求;系统功能的高层次描述;系统的目标
- 清晰的定义和缩写说明 (Clear documentation of definitions and acronyms)
- 参考 (References):用于定义现有系统、流程、需求等
- 概述 (Overview):SRS 文档的组织结构;支持增强可读性
- 一般描述 (General description):包括但不限于:
- 产品视角 (Product perspective):展示整个系统主要组件、相互连接以及外部接口的高层次图
- 产品功能 (Product functions):列出系统的主功能
- 用户特征 (User characteristics):预期将使用该产品的用户列表
- 运行环境 (Operating environment):主要包括硬件平台和操作系统
- 一般约束 (General constraints):主要包括硬件、软件和网络约束
- 假设与依赖 (Assumptions and Dependencies):所做的假设和考虑的因素
SRS 的模型
- 数据模型 (Data Model): 描述信息结构。
- 功能与信息流模型 (Functional and Information Flow Model): 描述数据处理方式。
- 行为模型 (Behavioral Model): 描述如何与系统交互。
SRS 的关键特征
SRS 应具备以下特性,以确保高质量:
- ||完整性 (Complete)||: 涵盖所有需求,无遗漏。
- ||可追溯性 (Traceable)||: 每个需求可追溯到其来源。
- ||精确性 (Precise)||: 需求描述清晰明确。
- ||可理解性 (Understandable)||: 易于目标受众理解。
- ||无歧义 (Unambiguous)||: 避免多重解释。
- ||组织性 (Organized)||: 结构清晰,便于阅读。
- ||可验证性 (Verifiable)||: 需求可被测试验证。
- ||正确性 (Correct)||: 需求准确反映用户需要。
- ||一致性 (Consistent)||: 需求之间无矛盾。
- ||简洁性 (Concise)||: 表述简明扼要。
- ||可修改性 (Modifiable)||: 便于更新和维护。
- ||可用性 (Usable)||: 便于开发和测试使用。
SRS 示例分析
示例 1: “系统应安全记录所有用户活动”
- 问题:
- 缺少可追溯性:未指明“安全”的具体标准或相关法规。
- 缺乏具体细节,如记录的内容或存储方式。
- 改进版本:
- “系统应根据 GDPR 法规 (参考文献 [GDPR-2016]),以加密形式记录所有用户活动(如登录、操作、退出),并存储在符合 ISO 27001 标准的数据库中 (参考文献 [ISO-27001-2022])。”
- 改进效果:
- 可追溯性: 明确引用法规和标准,便于验证。
- 清晰性: 具体描述记录内容和存储方式,减少歧义。
- 软件质量提升: 确保系统符合法律和安全标准,降低合规风险。
示例 2: 其他需求分析
- “系统应用户友好且快速”
- 问题: “用户友好”和“快速”过于模糊,缺乏量化标准。
- 改进: “系统应在 2 秒内响应 95% 的用户请求 (参考性能测试标准 [PERF-TEST-2023]),并通过用户体验测试 (参考 [UX-TEST-2022]) 确保界面符合直观性和易用性标准。”
- “用户应能重置密码”
- 问题: 未描述重置流程或安全要求。
- 改进: “用户应通过注册邮箱接收重置链接,在 5 分钟内完成密码重置,符合 OWASP 密码安全标准 (参考文献 [OWASP-2023])。”
- “软件必须符合法律要求”
- 问题: “法律要求”不具体,缺乏可追溯性。
- 改进: “软件应遵守 GDPR 和 CCPA 法规 (参考文献 [GDPR-2016, CCPA-2020]),包括用户数据隐私保护和数据删除请求处理。”
SRS 的优点
- ||理解并明确需求(To understand and specify requirements)||
- ||提供系统功能的精确说明(To provide precise statement about the functions of the system)||
- ||为成本和进度估算提供基础(To provide basis for costs and schedules estimations)||
- ||提供验证和确认的基准(To provide a baseline for validation and verification)||
- ||缓解语言障碍问题(To mitigate problem of language barrier)||
- ||减轻理解和阅读文档的困难(Mitigating difficulties in understanding and reading documents)||
- ||防止需求混淆(To prevent requirements confusion)||
- ||防止功能需求和非功能需求的混杂(Preventing mixing of functional and non-functional requirements)||
- ||防止需求组合(To prevent requirements combination)||
- ||减少开发工作量(To reduce the development efforts)||
- ||作为增强的基础(To serve as a basis for enhancement)||
IEEE 830-2009 标准
标准结构
IEEE 830-2009 提供了一个推荐的 SRS 文档结构,分为以下部分:
- 引言 (Introduction)
- 目的 (Purpose): 描述 SRS 的目标。
- 范围 (Scope): 说明系统功能和目标。
- 定义、缩写和缩略语 (Definitions, Acronyms, and Abbreviations): 定义术语。
- 参考文献 (References): 列出相关文档。
- 概述 (Overview): 描述 SRS 的组织结构。
- 总体描述 (Overall Description)
- 产品视角 (Product Perspective): 系统主要组件、连接和外部接口的高级图。
- 产品功能 (Product Functions): 列出系统主要功能。
- 用户特征 (User Characteristics): 描述预期用户群体。
- 约束条件 (Constraints): 硬件、软件、网络等限制。
- 假设和依赖 (Assumptions and Dependencies): 开发中的假设和依赖因素。
- 具体需求 (Specific Requirements)
- 外部接口 (External Interfaces): 系统与外部的交互(GUI screens, file formats)。
- 功能 (Functions): 系统的输入、输出和功能描述(detailed specifications of each use case)。
- 性能需求 (Performance Requirements): 系统的性能指标。
- 逻辑数据库需求 (Logical Database Requirements): 数据库结构和需求。
- 设计约束 (Design Constraints): 设计限制条件。
- 软件系统质量属性 (Software System Quality Attributes): 如可靠性、可维护性等。
- 面向对象模型 (Object-Oriented Models): 系统的对象模型。
- Architecture Specification
- Class Diagram
- State and Collaboration Diagrams
- Activity Diagram (concurrent/distributed)
- 支持信息 (Supporting Information)
- 目录 (Table of Contents)
- 索引 (Index)
- 附录 (Appendixes)
用例 (Use Cases)
定义
- 用例: 描述用户如何使用系统完成特定目标的文档,用户是系统外部的对象。
- 作用: 表示系统的特定功能,清晰描述用户与系统的交互。
用例模板
字段 | 描述 |
---|---|
用例名称 (Use Case) | 用例的名称 |
目标 (Goal) | 用例的主要目标 |
范围与级别 (Scope & Level) | 用例的范围和详细程度 |
前置条件 (Pre-condition) | 用例开始前的条件 |
成功结束条件 (Success End Condition) | 用例成功的状态 |
失败结束条件 (Failed End Condition) | 用例失败的状态 |
参与者 (Actors) | 发起用例的用户 |
触发器 (Trigger) | 启动用例的动作 |
描述 (Description) | 用例的步骤描述 |
- 其他字段:
- 扩展 (Extends)
- 包含 (Includes)
- 子变体 (Sub Variations)
- 利益相关者及利益 (Stakeholders and Interests)
- 使用频率 (Frequency of Use)
- 风险级别 (Level of Risk)
- 优先级 (Priority)
用例示例:物流系统
- 场景: 物流部门的应用支持客户请求和库存管理。客户提交请求,客服代表处理订单,订单准备好后通知客户付款。若库存低于某个水平,代表可选择重新订货。
- 用例描述 (以“处理客户订单”为例):
字段 (Field) | 内容 (Content) |
---|---|
用例名称 (Use Case) | 客户下订单(Place Customer Order) |
目标 (Goal) | 客户成功下订单并完成支付流程,同时系统检查库存是否需要补货。 |
范围与级别 (Scope & Level) | 物流管理系统,用户级别(User-goal level) |
前置条件 (Pre-condition) | 系统已启动,客户账户可用,库存信息同步完成。 |
成功结束条件 (Success End Condition) | 订单成功记录,客户完成支付,若库存不足则生成补货通知。 |
失败结束条件 (Failed End Condition) | 客户未完成支付或系统库存检查失败,订单未被确认。 |
参与者 (Actors) | 客户(Customer)、客户代表(Customer Representative) |
触发器 (Trigger) | 客户提交订单请求。 |
描述 (Description) | 1. 客户登录系统并浏览产品。 2. 客户选择商品并下订单。 3. 系统记录订单并通知客户代表。 4. 客户代表检查库存。 5. 若库存充足,系统准备发货并通知客户支付。 6. 客户完成支付。 7. 若库存不足,系统提示客户代表是否下补货单。 8. 系统更新库存信息。 |
扩展 (Extends) | 支付失败流程(用于描述支付失败时的处理)。 |
包含 (Includes) | 检查库存(Check Stock)、生成补货单(Create Re-stocking Order) |
子变体 (Sub Variations) | 客户批量下单、客户预约未来发货 |
利益相关者及利益 (Stakeholders and Interests) | 客户希望及时收到订单;公司希望避免缺货;仓库希望优化库存。 |
使用频率 (Frequency of Use) | 高频(每天多次) |
风险级别 (Level of Risk) | 中等,涉及支付和库存。 |
优先级 (Priority) | 高 |
用例的优点
- 明确交互: 清晰描述用户与系统的交互过程。
- 避免错误: 通过定义前置条件和结束条件,减少系统设计中的歧义。
- 支持测试: 提供测试用例的基础。
活动图 (Activity Diagram)
定义
- 活动图: 描述系统或流程的动态行为,展示活动之间的顺序和条件。
- 用途: 用于可视化用例或业务流程的步骤。
示例:创建 ZIP 档案
- 场景: 用户在文件管理应用中选择文件并创建 ZIP 档案。
- 活动图:
graph TD start((Start)) --> UserSelectFiles[User selects files] UserSelectFiles --> UserSelectArchive[User selects archive] UserSelectArchive --> CheckFileExists{File exists?} CheckFileExists -- New --> AddFileToArchive[Add file to archive] CheckFileExists -- Existing --> OverwritePrompt{Overwrite?} OverwritePrompt -- Yes --> AddFileToArchive OverwritePrompt -- No --> Finish[(End)] AddFileToArchive --> Finishgraph TD start((Start)) --> UserSelectFiles[User selects files] UserSelectFiles --> UserSelectArchive[User selects archive] UserSelectArchive --> CheckFileExists{File exists?} CheckFileExists -- New --> AddFileToArchive[Add file to archive] CheckFileExists -- Existing --> OverwritePrompt{Overwrite?} OverwritePrompt -- Yes --> AddFileToArchive OverwritePrompt -- No --> Finish[(End)] AddFileToArchive --> Finish
- 错误避免:
- 明确流程顺序,防止遗漏步骤。
- 定义条件分支,处理异常情况。
- 提高系统的可测试性。
可能考法与示例考题
考法
- 选择题: SRS 的关键特性、IEEE 830 标准结构。
- 简答题: 解释 SRS 或用例的作用,分析需求问题。
- 应用题: 编写 SRS 片段、用例描述或活动图。
示例考题
-
选择题: 以下哪项不是 SRS 的关键特性?
- A. 可追溯性 (Traceability)
- B. 复杂性 (Complexity)
- C. 完整性 (Completeness)
- D. 无歧义 (Unambiguity)
- 答案: B. 复杂性 (Complexity)
- 中文解释: SRS 应简洁、清晰,复杂性不是其关键特性。
- English Explanation: SRS should be concise and clear; complexity is not a key characteristic.
-
简答题: 为什么 SRS 需要可追溯性?举例说明。
- 答案:
- 中文: 可追溯性确保需求可链接到其来源,便于验证和维护。例如,“系统应符合 GDPR”可追溯到 [GDPR-2016],确保合规性。
- English: Traceability ensures requirements can be linked to their sources for verification and maintenance. For example, “The system shall comply with GDPR” can be traced to [GDPR-2016], ensuring compliance.
- 答案:
-
应用题: 为在线图书借阅系统编写一个用例描述。
-
答案:
字段 内容 用例名称 (Use Case) 借阅图书 (Borrow Book) 目标 (Goal) 允许用户成功借阅图书 范围与级别 (Scope & Level) 在线图书借阅系统 (Online Library System),核心功能 (Core Function) 前置条件 (Pre-condition) 用户已登录系统,图书在库存中,用户的借阅权限有效 成功结束条件 (Success End Condition) 图书借阅记录更新,用户收到借阅确认通知,图书库存减少 失败结束条件 (Failed End Condition) 图书不可用、用户权限不足或系统错误导致借阅失败,用户收到错误提示 参与者 (Actors) 注册用户 (Registered User) 触发器 (Trigger) 用户点击“借阅”按钮 描述 (Description) 1. 用户登录在线图书借阅系统
2. 用户通过搜索功能查找目标图书
3. 用户选择图书并点击“借阅”按钮
4. 系统检查图书库存和用户借阅权限
5. 系统确认借阅,更新借阅记录和库存
6. 系统向用户发送借阅确认通知
7. 若库存不足或权限无效,系统显示错误提示扩展 (Extends) 若图书不可用,系统可推荐类似图书 包含 (Includes) 用户身份验证 (User Authentication) 子变体 (Sub Variations) 用户可通过书名、作者或 ISBN 搜索图书 利益相关者及利益 (Stakeholders and Interests) 用户:借阅所需图书
图书馆管理员:确保库存和借阅记录准确使用频率 (Frequency of Use) 每日多次 风险级别 (Level of Risk) 中等(涉及库存管理和用户权限) 优先级 (Priority) 高(核心功能) - 中文解释: 此用例描述了用户通过在线图书借阅系统借阅图书的完整流程,涵盖前置条件、成功和失败场景,以及扩展功能(如推荐类似图书)。它确保需求清晰、可追溯,减少开发中的歧义。
- English Explanation: This use case describes the complete process of a user borrowing a book through the online library system, covering preconditions, success and failure scenarios, and extensions (e.g., recommending similar books). It ensures clear, traceable requirements, reducing ambiguity in development.
-