软件需求包括三个不同的层次:业务需求，解释新系统提供给客户和产品开发人员的好处，反映组织或客户对系统和产品的高层目标需求，将在项目视图和范围文档中解释；用户需求，描述用户在使用系统时必须完成的任务，在用例文档或场景脚本描述中解释；功能需求和非功能需求定义了开发人员必须实现的软件功能，使用户能够顺利完成任务，从而满足业务需求。

第一，需求获取

收集、分析、提炼、验证和组织需求，并将其写入文档的步骤。该活动包括10个具体任务:编译项目视图和范围文档、划分用户组、选择用户代表、构建核心团队、确定用例、召开联席会议、分析用户工作流、确定质量属性、检查问题报告和复用需求。文章后面会详细阐述。

二、需求分析

根据需求获取获得的需求文档，分析系统实现方案。本活动需要完成以下任务:

1.绘制关联图，定义系统与系统外部实体之间的边界和接口的简单模型；

2.创建开发原型。当开发者或者用户不能把某些需求说清楚的时候，开发一个系统原型，让很多概念和可能的事情变得更加直观清晰；

3.分析可行性。在允许的成本和性能要求下，分析实现每项要求的可行性，明确与实现每项要求相关的风险，包括与其他要求的冲突、各种用户的利益平衡、对外部因素的依赖和技术障碍；

4.确定需求的优先级:分析确定使用实例、系统特性或个别需求的优先级的方法，并根据优先级确定产品版本将包含哪些特性或类型的需求；

5.建立需求的模型和需求的图形化分析模型是对软件需求规格说明的极好补充，可以从多个角度对系统需求进行建模；

6.编写数据字典，并创建数据字典。数据字典是系统中使用的所有数据项和结构的定义，以确保开发者使用统一的数据定义；

7.应用质量功能展开，将系统特性和属性与它们对顾客的重要性联系起来，并提供一种分析方法来阐明顾客最关心的特性。

第三，写需求说明书。

开发的最终结果是客户和开发团队就要开发的产品达成一致，这是通过文档化的需求规格来体现的。规范包括项目视图和范围文档来说明系统的业务需求，而用例文档说明用户需求。本活动需要完成以下任务:

1.使用模板。在您的组织中，您应该为编写软件需求规格说明和其他文档定义一个标准模板。此模板为记录系统需求和其他与需求相关的重要信息提供了统一的结构；

2.指明需求的来源。为了让所有项目涉众理解为什么在需求规格中提供这些功能需求，有必要追踪每个需求的来源，这可能是用例或其他客户需求，或者更高级别的系统需求、业务规格、政府法规、标准或其他外部来源。这些来源应记录在需求的跟踪能力矩阵中；

3.给每个需求贴上标签。对于需求的可追溯性和可修改性的质量标准，每个软件需求必须被唯一地确定，并且应该建立一个约定，为需求规格书中的每个需求提供一个独立的、可识别的标签或标记；

4.记录业务规范是指系统的运行原理，比如谁在什么情况下可以采取什么行动，将这些写入需求规范的独立部分或者独立的业务规范文档；

5.创建一个需求跟踪能力矩阵，并建立一个矩阵来链接每个需求的来源、定义和实现，并测试其设计和代码，有利于需求管理和评估需求变更的影响范围。

四。需求验证

需求验证是为了保证需求描述准确完整，表达必要的质量特性。该需求将作为系统设计和最终验证的基础，因此必须保证其正确性。需求验证必须确保符合完整性、正确性、灵活性、必要性、模糊性、一致性、可追溯性和可验证性的良好特性。本活动需要完成以下任务:

1.评审需求文档和正式评审需求文档是保证软件质量的有效方法。组织一个由不同代表(如用户、分析师、设计师和测试人员)组成的小组，仔细检查需求规格说明书和相关模型；

2.根据需求编写测试用例，根据用户需求所要求的产品特性编写系统的功能测试用例，作为系统测试依据；

3.编写用户手册，可以在需求开发初期起草，作为需求规格说明的参考，作为需求分析的辅助；

4.确定合格标准。需求描述中描述的什么样的产品才能满足用户的要求，适合他们的使用？根据使用场景或使用示例的描述，建立合格的测试。

五、需求的监督和调节

需求管理是一种组织、控制和记录需求的系统方法，也是用户和开发组织之间改变系统功能的协议。在验证和批准开发结果之后，定义开发工作的需求基线，它在客户和开发人员之间构造一个需求协议。需求管理包括在项目过程中维护需求协议的一致性和准确性的活动。现在许多商业需求管理工具可以很好地支持需求管理活动。本活动需要完成以下任务:

1.确定变更控制过程，以及选择、分析和决定需求变更的过程。所有的需求变化都要遵循这个过程；

2.建立软件变更控制委员会，组织一组项目涉众作为变更控制委员会，他们将评估和确定需求变更；

3.进行变更影响分析，评估需求变更对项目进度、资源、工作量、项目范围和其他要求的影响；

4.跟踪受变更影响的产品。当某个需求发生变化时，参考需求跟踪能力矩阵，寻找其他相关的需求、设计文档、源代码和测试用例。这些相关部分可能也需要修改；

5.建立基准和控制版本，需求文档确定一个基线，基线是特定时刻一致性需求的快照，然后需求变更可以遵循变更控制流程；

6.维护变更历史，记录需求文件版本变更的日期、变更内容及原因、负责更新和更新新版本号的人员等。

7.跟踪每个需求的状态，包括“OK”、“Implemented”、“Suspended”、“New”和“Change”。建立一个数据库，其中每个记录记录一个需求；

8.测量需求的稳定性，并记录基线需求的数量和每周或每月的变化量。

需求获取是在问题及其最终解决方案之间搭建桥梁的第一步，是软件需求过程的主体。项目的目的是开发一个正确的系统。要做到这一点，需要足够详细地描述需求，即系统必须满足的条件或能力，这样用户和开发人员才能就系统应该做什么和不应该做什么达成共识。众所周知，开发一个软件系统最困难的部分是准确地解释要开发什么，最困难的概念性工作是编写详细的技术需求，包括用户、机器和其他软件系统的所有接口。

需求获取就是为了解决这些问题，其本质成果是对项目中描述的用户需求的大致理解。一旦理解了需求，分析人员、开发人员和用户就可以探索各种解决方案来描述这些需求。

这个阶段的工作一旦做错，最终会给系统带来巨大的破坏。任何由需求获取引起的需求定义的改变，都会导致设计、实现和测试的大量返工，此时所花费的资源和时间将大大超过仔细准确地获取需求的时间和资源