软件需求分析举例
查尔斯·摩尔
例如，在银行应用程序中，功能要求是当客户选择“查看余额”时，他们必须能够查看其最新的帐户余额。
软件需求也可以是非功能性的，可以是性能需求。例如，非功能性需求是系统的每个页面都应该在 5 秒内对用户可见。
所以，基本上 软件需求是
- 功能性或
- 非功能性
需要 必须将其实施到系统中。 软件需求通常以陈述的形式表达。
需求类型
- 业务需求：它们是从项目业务案例中获取的高级需求。例如，移动银行服务系统为东南亚提供银行服务。针对印度确定的业务需求是账户汇总和资金转账，而针对中国确定的业务需求是账户汇总和账单支付
| 国家 | 提供银行功能或服务的公司 |
|---|---|
| 印度 | 账户摘要和资金转账 |
| 中国 | 帐户摘要和 Bill 付款 |
- Archi结构和设计要求：这些要求比业务要求更详细。它决定了实现业务要求所需的总体设计。对于我们的教育机构，架构和设计用例将是登录、课程详情等。要求如下所示。
| 银行用例 | 需求 |
|---|---|
| Bill 付款 | 此用例描述了客户如何登录网上银行并使用 Bill 付款方式。
客户将可以看到注册记账人的未清账单仪表板。他可以添加、修改和删除帐单详细信息。客户可以为不同的计费操作配置短信、电子邮件警报。他可以查看过去支付账单的历史记录。 启动此用例的参与者是银行客户或支持人员。 |
- 系统和集成要求：在最低级别，我们有系统和集成需求。这是对每个需求的详细描述。它可以是用户故事的形式，实际上是在描述日常业务语言。需求非常详细，以便开发人员可以开始编码。以下是示例 Bill 支付模块中将提到添加 Biller
| Bill 付款 | 操作系统需求 |
|---|---|
| 添加 BillERS |
|
有时，对于某些项目，您可能不会收到任何需求或文档。但您仍然可以考虑其他需求来源以获取需求或信息，以便您可以根据这些需求设计软件或测试。因此，您可以依赖的其他需求来源是
其他要求来源
- 来自已经从事该项目的同事或员工的知识转移
- 与业务分析师、产品经理、项目负责人和开发人员讨论项目
- 分析已实施到系统中的先前系统版本
- 分析项目的旧需求文档
- 查看过去的 Bug 报告，一些 Bug 报告会转化为增强请求，可能会在当前版本中实现
- 查看安装指南（如果有）以了解安装所需的内容
- 分析团队正在尝试实施的领域或行业知识
无论您收到什么要求，请务必以某种形式记录下来，并让其他经验丰富且知识渊博的团队成员对其进行审查。
如何分析需求
考虑一个教育软件系统的例子，学生可以在其中注册不同的课程。
让我们研究如何分析需求。需求必须保持其需求的标准质量，不同类型的需求质量包括
- Atomic
- 唯一标识
- 完成：
- 一致且明确
- 可追溯：
- 优先
- 可测试
让我们通过一个例子来理解这一点，这里显示的表中有三列，
- 第一列表示-“需求质量”
- 第二列表示-“有一些问题的不良需求”
- 第三列与第二列相同，但“转换为良好的需求”。
| 需求质量 | 不良需求示例 | 良好需求示例 |
|---|---|---|
| Atomic |
|
|
| 唯一标识 | 1- 学生将能够注册本科课程1- 学生将能够注册研究生课程 |
|
| 完成： | 教授用户将通过提供用户名、密码和其他相关信息登录系统 | 教授用户将通过提供用户名、密码和部门代码登录系统 |
| 一致且明确 | 学生将学习本科课程或研究生课程，但不能同时学习两者。一些课程将对本科生和研究生开放 | 学生将拥有本科学位或研究生学位，但不能同时拥有两者 |
| 可追溯： | 维护映射到 BRD req.ID 的学生信息？ | 维护学生信息 - 映射到 BRD 请求 ID 4.1 |
| 优先 | 注册学生-优先1维护用户信息-优先1报名课程-优先1查看成绩单-优先1 | 注册学生-优先1维护用户信息-优先2报名课程-优先1查看成绩单-优先3 |
| 可测试 | 系统的每个页面都会在可接受的时间范围内加载 | 系统的注册学生和注册课程页面将在 5 秒内加载 |
现在让我们详细了解每个要求，首先 Atom我知道了。
Atomic
因此，您的每项需求都应是原子的，这意味着它应该处于非常低的细节水平，不可能分离成组件。在这里我们将看到两个需求示例， Atomic 和唯一标识的需求级别。
让我们继续以教育领域的系统构建为例。这里，糟糕的需求是“学生将能够注册本科和研究生课程”。这是一个糟糕的需求，因为它不是原子的，因为它谈论的是两个不同的实体：本科生和研究生课程。所以很明显这不是一个好的要求，而是糟糕的要求，所以对应的好要求是将其分成两个要求。所以一个谈论本科课程的注册，而另一个谈论研究生课程的注册。
唯一标识
同样，下一个需求质量是检查唯一标识，这里我们有两个单独的需求，但它们都有相同的 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 秒。
结语
因此，我们必须以适当的水平来看待每一项要求。例如，如果我们要构建一个关于系统和集成要求的软件。我们必须查看软件需求规范或用户故事中给出的系统和集成需求，并将其应用于每一个需求质量。然后检查每个需求是否是原子的、唯一标识的、完整的等等。