软件需求分析举例
查尔斯·摩尔
软件需求是指系统中必须实现的功能性或非功能性需求。功能性需求是指为用户提供特定服务。
例如，在银行应用程序中，功能要求是当客户选择“查看余额”时，他们应该能够查看其最新的账户余额。
软件需求也可以是非功能性的，例如性能需求。例如，一项非功能性需求可能规定系统的每个页面都应该在 5 秒内加载完毕。
所以，基本上 软件需求是
- 功能性或
- 非功能性
需要 必须将其实施到系统中。 软件需求通常以语句的形式表达。
需求类型
业务需求这些是从项目商业案例中提取的高级需求。例如，一个移动银行服务系统为东南亚地区提供银行服务。针对印度市场确定的业务需求是账户概览和资金转账，而针对中国市场的业务需求是账户概览和账单支付。
| 国家 | 提供银行功能或服务的公司 |
|---|---|
| 印度 | 账户摘要和资金转账 |
| 中国 | 帐户摘要和 Bill 付款方式 |
Archi结构和设计要求这些需求比业务需求更详细，并驱动解决方案架构。它们决定了实现业务需求所需的整体设计。对于教育机构而言，典型的架构和设计用例包括登录、课程详情和注册。需求如下所示。
| 银行用例 | 需求 |
|---|---|
| Bill 付款方式 | 此用例描述了客户如何登录网上银行并使用 Bill 支付功能。客户可以查看已注册收款方的未结账单概览。客户可以添加、修改和删除收款方信息。客户可以针对不同的账单操作设置短信和电子邮件提醒。客户可以查看已支付账单的历史记录。此用例的使用者是银行客户或支持人员。 |
系统和集成要求最底层是系统和集成需求。它详细描述了每一项需求，可以用日常业务语言编写的用户故事来表示。这些需求包含丰富的细节，以便开发人员能够立即开始编码。 Bill 下面这个支付模块示例展示了添加收款方的要求。
| Bill 付款方式 | 申请条件 |
|---|---|
| 添加 BillERS | 公用事业供应商名称、客户关系编号、自动付款（是/否）、一次性付清 Bill – 是/否，自动付款限额 – 如果满足以下条件则不付款 Bill 超过指定金额 |
有时，项目可能没有任何需求或文档可供参考。即便如此，您仍然可以依赖其他需求信息来源来制定软件或测试设计。以下列出了您可以依赖的其他需求信息来源。
其他要求来源
- 来自已经从事该项目的同事或员工的知识转移
- 与业务分析师、产品经理、项目负责人和开发人员讨论项目。
- 分析已实现的先前系统版本
- 分析项目中的旧需求文档
- Rev查看之前的错误报告；一些错误报告会被转化为功能增强请求，这些请求可能会在当前版本中实现。
- 如有安装指南，请查看以了解需要进行哪些安装。
- 分析团队试图实施的领域或行业知识。
无论你使用哪种需求来源，都要以共享格式记录下来，并由经验丰富的团队成员进行审核。
如何分析需求
以教育软件系统为例，学生可以在该系统中注册不同的课程。
让我们来学习如何分析需求。每项需求都必须满足一系列标准质量属性，其中包括：
- Atomic
- 唯一标识
- 完成：
- 一致且明确
- 可追溯：
- 优先
- 可测试
下表用三列分别展示了每个属性：
- 第一列表示-“需求质量”
- 第二列表示-“有一些问题的不良需求”
- 第三列显示的是“转化为良好需求”的相同需求。
| 需求质量 | 不良需求示例 | 良好需求示例 |
|---|---|---|
| Atomic | 学生将能够注册本科和研究生课程 | 学生可以注册本科课程。学生可以注册研究生课程。 |
| 唯一标识 | 1. 学生将能够注册本科课程。1. 学生将能够注册研究生课程。 | 课程注册。学生可以注册本科课程。学生可以注册研究生课程。 |
| 完成： | 教授用户将通过提供用户名、密码和其他相关信息登录系统 | 教授用户将通过提供用户名、密码和部门代码登录系统 |
| 一致且明确 | 学生将学习本科课程或研究生课程，但不能同时学习两者。一些课程将对本科生和研究生开放 | 学生将拥有本科学位或研究生学位，但不能同时拥有两者 |
| 可追溯： | 维护映射到 BRD req.ID 的学生信息？ | 维护学生信息 - 映射到 BRD 请求 ID 4.1 |
| 优先 | 注册学生 - 优先级 1。维护用户信息 - 优先级 1。选课 - 优先级 1。查看成绩单 - 优先级 1。 | 学生注册 - 优先级 1；维护用户信息 - 优先级 2；选课 - 优先级 1；查看成绩单 - 优先级 3 |
| 可测试 | 系统的每个页面都会在可接受的时间范围内加载 | 系统的注册学生和注册课程页面将在 5 秒内加载 |
让我们更详细地了解这些属性，首先是： Atom我知道了。
Atomic
每个需求都应该是原子性的，这意味着它必须处于最底层的细节，并且不能进一步分解成组件。以下示例比较了原子性需求和非原子性需求。
继续以教育领域系统为例：这里，不合理的需求是“学生可以注册本科和研究生课程”。这是不合理的需求，因为它不是原子性的——它混淆了本科和研究生课程这两个不同的实体。相应的合理需求将其拆分为两个需求。一个需求涵盖本科课程的注册，另一个需求涵盖研究生课程的注册。
唯一标识
下一个质量属性是唯一标识。在反例中，两个不同的需求共享同一个 ID#1。如果团队通过 ID 引用需求，就无法明确指的是哪个需求。正确的做法是将它们重新归类到“第一部分——课程注册”下，并包含子需求 1.1（本科课程注册）和 1.2（研究生课程注册）。
完成：
每项需求都应该完整。例如，这里不恰当的需求描述为“教授用户将通过提供用户名、密码和其他相关信息登录系统”。“其他相关信息”过于模糊。完整的需求应该列出教授必须提供的具体字段，例如院系代码。
一致且明确
每一项要求都应保持一致且明确。在反例中，一项要求规定“学生只能修读本科课程或研究生课程，不能两者兼修”，而另一项要求则规定“部分课程本科生和研究生均可选修”。
第一项要求意味着课程分为两个互斥的类别，但第二项要求与之矛盾，因为它允许一些课程同时向两个群体开放。
好的要求通过明确规定每门课程要么是本科课程要么是研究生课程来解决冲突，学生只能选修一类课程。
可追溯：
每一项要求都必须是 trac之所以可行，是因为需求存在于多个层面：业务层面、架构和设计层面，以及系统和集成层面。
当您将业务需求转化为架构和设计需求，或者将架构和设计需求转化为系统和集成需求时， trac必须保证可实现性。每个业务需求都应该对应一个或多个架构和设计需求。在反例“维护学生信息——是否对应业务需求文档（BRD）需求 ID？”中，需求 ID 缺失。
良好的需求记录了相同的语句，但明确映射到 BRD 需求 ID 4.1。每个需求都必须包含一个 trac能力图ping系统和集成需求也应该与实现这些需求的代码以及验证这些需求的测试用例相对应。
Trac因此，可操作性贯穿整个项目始终。
优先
每个需求都必须进行优先级排序，以便团队知道哪些功能需要优先实现，哪些可以稍后再做。在反例中，“注册学生”、“维护用户信息”、“选课”和“查看成绩单”都被设置为优先级 1。但并非所有功能都优先级为 1，因此必须根据实际情况对需求进行排序。在正例中，“注册学生”和“选课”的优先级最高，为 1，“维护用户信息”为 2，“查看成绩单”为 3。
可测试
每个需求都应该是可测试的。例如，“系统的每个页面都将在可接受的时间范围内加载”就是一个反例，它无法测试，原因有二。首先，“每个页面”可能意味着几十个页面，这将大大增加测试工作量。其次，“可接受的时间范围”没有明确定义——对谁而言是可接受的？又以什么标准来衡量？好的需求通过明确指出具体的页面（例如“学生注册页面”和“课程注册页面”）并设定一个可衡量的目标值（例如 5 秒）来解决这两个问题。
