软件需求分析实例
Charles Moore 例如，在银行应用程序的上下文中，功能性需求是指当客户选择“查看余额”时，他们能够看到其最新的账户余额。
软件需求也可以是非功能性的，可以是性能需求。例如，非功能性需求是指系统中的每个页面都应在5秒内向用户显示。
因此，基本上软件需求是
- 功能性的或
- 非功能性的
需求，它必须在系统中实现。软件需求通常表述为陈述。
需求类型
- 业务需求：这是指从项目业务案例中提取的高级需求。例如，一个移动银行服务系统为东南亚提供银行服务。为印度确定的业务需求是账户摘要和资金转账，而为中国确定的业务需求是账户摘要和账单支付。
| 国家 | 提供银行功能或服务的公司 |
|---|---|
| 印度 | 账户摘要和资金转账 |
| 中国 | 账户摘要和账单支付 |
- 架构和设计需求：这些需求比业务需求更详细。它决定了实现业务需求所需的整体设计。对于我们的教育组织，架构和设计用例将是登录、课程详情等。需求如下所示。
| 银行用例 | 需求 |
|---|---|
| 账单支付 | 此用例描述了客户如何登录网上银行并使用账单支付功能。
客户将看到已注册账单的待付账单仪表板。他可以添加、修改和删除账单详情。客户可以为不同的账单操作配置短信、电子邮件警报。他可以看到过去已付账单的历史记录。 启动此用例的参与者是银行客户或支持人员。 |
- 系统和集成需求：在最低级别，我们有系统和集成需求。它是对每一项需求的详细描述。它可以是用户故事的形式，真正用日常业务语言描述。需求非常详细，以便开发人员可以开始编码。例如，在账单支付模块中，将提及添加账单者的需求。
| 账单支付 | 需求 |
|---|---|
| 添加账单者 |
|
有时对于某些项目，您可能收不到任何需求或文档来处理。但仍然有其他需求来源供您考虑，以便您可以基于这些需求来设计您的软件或测试。因此，您可以依赖的其他需求来源包括：
其他需求来源
- 来自正在从事该项目的同事或员工的知识转移
- 与业务分析师、产品经理、项目负责人和开发人员讨论项目
- 分析已在系统中实现的先前系统版本
- 分析项目的旧需求文档
- 查看过去的 Bug 报告，其中一些 Bug 报告已转化为可能在当前版本中实现的增强请求
- 查看安装指南（如果可用），以了解所需的安装
- 分析团队试图实现的领域或行业知识
无论您获得什么需求来源，请务必以某种形式记录下来，并由其他有经验和知识的团队成员进行审查。
如何分析需求
考虑一个教育软件系统的例子，其中学生可以注册不同的课程。
让我们研究一下如何分析需求。需求必须保持标准质量，不同的需求质量类型包括：
- 原子性
- 唯一标识
- 已完成
- 一致且无歧义
- 可追溯
- 已排序
- 可测试
让我们通过一个例子来理解这一点，这里显示的表格有三列：
- 第一列表示 – “需求质量”
- 第二列表示 – “存在问题的坏需求”
- 第三列与第二列相同，但 – “已转换为好的需求”。
| 需求质量 | 坏需求示例 | 好需求示例 |
|---|---|---|
| 原子性 |
|
|
| 唯一标识 | 1- 学生将能够注册本科课程1- 学生将能够注册研究生课程 |
|
| 已完成 | 教授用户将通过提供其用户名、密码和其他相关信息登录系统 | 教授用户将通过提供其用户名、密码和部门代码登录系统 |
| 一致且无歧义 | 学生将只能选择本科课程或研究生课程，但不能同时选择两者。有些课程将对本科生和研究生同时开放。 | 学生将只能选择本科课程或研究生课程，但不能同时选择两者。 |
| 可追溯 | 维护学生信息 – 映射到 BRD 需求 ID？ | 维护学生信息 – 映射到 BRD 需求 ID 4.1 |
| 已排序 | 注册学生-优先级 1 维护用户信息-优先级 1 注册课程-优先级 1 查看成绩单-优先级 1 | 注册学生-优先级 1 维护用户信息-优先级 2 注册课程-优先级 1 查看成绩单-优先级 3 |
| 可测试 | 系统中的每个页面都将在可接受的时间范围内加载。 | 系统中注册学生和注册课程的页面将在 5 秒内加载。 |
现在让我们详细了解这些需求，从原子性开始。
原子性
因此，您的每一项需求都应该是原子的，这意味着它应该是非常细节的低级别，不应能将其分离成组件。在这里，我们将看到关于原子性和唯一标识需求级别的两个示例。
因此，让我们继续以教育领域系统构建的例子。这里，坏需求是“学生将能够注册本科和研究生课程”。这是一个坏需求，因为它不是原子的，因为它提到了两个不同的实体——本科生和研究生课程。所以，这显然不是一个好的需求，而是坏需求，因此相应的好的需求应该是将其分成两个需求。一个关于注册本科课程，另一个关于注册研究生课程。
唯一标识
同样，下一个需求质量是检查唯一标识，这里我们有两个单独的需求，但它们都具有相同的 ID#1。因此，如果我们通过 ID# 引用我们的需求，但又不清楚我们具体引用的是文档还是系统的其他部分，因为它们都具有相同的 ID#1。因此，通过唯一 ID 分开，好的需求将被重写为第 1 部分 – 课程注册，其中有两个需求 1.1 ID 是注册本科课程，而 1.2 ID 是注册研究生课程。
已完成
此外，每一项需求都应该是完整的。例如，这里有一个坏需求说“教授用户将通过提供其用户名、密码和其他相关信息登录系统”。这里的“其他相关信息”不清楚，因此在好的需求中应该明确说明其他相关信息，以使需求完整。
一致且无歧义
接下来，每一项需求都应该是一致且无歧义的。例如，这里我们有需求“学生将只能选择本科课程或研究生课程，但不能同时选择两者”，这是一个需求，还有另一个需求说“有些课程将对本科生和研究生同时开放”。
这个需求的问题在于，从第一个需求来看，课程分为两类：本科课程和研究生课程，学生只能选择其中一类，但不能同时选择两者。但当你读到另一个需求时，它与第一个需求相冲突，并告诉一些课程将对研究生和本科生同时开放。
因此，很明显可以将这个坏需求转换为好的需求，即“学生将只能选择本科课程或研究生课程，但不能同时选择两者”。这意味着每门课程都将被标记为本科课程或研究生课程。
可追溯
每一项需求都应该是可追溯的，因为已经有不同层次的需求，我们已经看到在顶部有业务需求，然后我们有架构和设计需求，接着是系统集成需求。
现在，当我们把业务需求转换为架构和设计需求，或者把架构和设计需求转换为系统集成需求时，必须存在可追溯性。这意味着我们应该能够获取每一项业务需求，并将其映射到一个或多个相应的软件架构和设计需求。所以这里有一个坏需求示例，它说“维护学生信息 – 映射到 BRD 需求 ID？”这里没有给出需求 ID。
因此，将其转换为好的需求，它说了同样的话，但它映射到了需求 ID 4.1。所以，每一项需求都应该有映射。同样，我们也有高级别和低级别映射需求，系统集成需求与实现该需求的 कोड 之间也存在映射，并且系统集成需求与测试该特定需求的测试用例之间也存在映射。
因此，这种可追溯性贯穿整个项目。
已排序
| 已排序 | 注册学生-优先级 1 维护用户信息-优先级 1 注册课程-优先级 1 查看成绩单-优先级 1 |
注册学生-优先级 1 维护用户信息-优先级 2 注册课程-优先级 1 查看成绩单-优先级 3 |
然后每一项需求都必须被优先排序，这样团队就有了一个指导方针，知道先实现哪些需求，哪些可以稍后完成。您可以看到，坏的优先级是注册学生、维护用户信息，并且每一项需求都被赋予了优先级 1。不可能所有需求都具有相同的优先级，所以需求可以被优先排序。所以这里的好的需求示例是注册学生和注册课程被赋予了最高的优先级 1，而维护用户信息排在第二位，优先级为 2，然后查看成绩单的优先级为 3。
可测试
| 可测试 | 系统中的每个页面都将在可接受的时间范围内加载。 | 系统中注册学生和注册课程的页面将在 5 秒内加载。 |
每一项需求都应该是可测试的。这里有一个坏需求是“系统中的每个页面都将在可接受的时间范围内加载”。现在这个需求有两个问题，第一个是“每个页面”意味着可能有许多页面，这会增加测试工作量。另一个问题是它说页面将在“可接受的时间范围内”加载，那么什么是可接受的时间范围？可接受的程度因人而异。所以我们必须将不可测试的论点转换为可测试的论点，具体说明我们指的是哪个页面“注册学生和注册课程页面”，并且还给出了可接受的时间范围，即 5 秒。
结论
这就是我们应该在适当的级别上查看每一项需求的方式。例如，如果我们打算构建与系统和集成需求相关的软件。我们必须查看软件需求规范或用户故事中给出的系统和集成需求，并将其应用于每一项需求质量。然后检查每一项需求是否是原子的、唯一标识的、完整的等等。
