需求分析

• 软件需求

在进行需求获取之前，首先要明确获取什么，也就是需求包含哪些内容。软件需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。

1. 功能需求。考虑系统要做什么，在何时做，在何时以及如何修改或升级。
2. 性能需求。考虑软件开发的技术性指标。例如，存储容量限制、执行速度、响应时间及吞吐量。
3. 用户或人的因素。考虑用户的类型。例如，各种用户对计算机的熟练程度，需要接受的训练，用户理解、使用系统难度，用户错误操作系统的可能性等。
4. 环境需求。考虑软件未来的应用环境，包括软件和硬件。对硬件设备的需求包括机型、外设、接口、地点、分布、湿度、磁场干扰等；对软件的需求包括操作系统、网络、数据库等。
5. 界面需求。考虑来自其他系统的输入，到其他系统的输出，对数据格式的特殊规定，对数据存储介质的规定。
6. 文档需求。考虑需要哪些文档，文档针对哪些读者。
7. 数据需求。考虑输入、输出数据的格式，接收、发送数据的频率，数据的精准性和精度，数据流量，数据需保持的时间。
8. 资源使用需求。考虑软件运行时所需要的数据、其他软件、内存空间等资源；软件开发，维护所需的人力、支撑软件、开发设备等。
9. 安全保密要求。考虑是否需要的对访问系统或系统信息加以控制，隔离用户数据的方法，用户程序如何与其他程序和操作系统隔离以及系统备份要求。
10. 可靠性要求。考虑系统的可靠性要求，系统是否必须检测和隔离错误；出错后，重启系统允许的时间等。
11. 软件成本消耗与开发进度需求。考虑开发是否有规定的时间表，软/硬件投资有无限制等。
12. 其他非功能性要求。如采用某种开发模式，确定质量控制标准、里程碑和评审、验收标准、各种质量要求的优先级等，以及可维护性方面的要求。

这些需求可以来自于用户、用户的规约、应用领域的专家、相关的技术标准和法规；也可以来自于原有的系统、原有系统的用户、新系统的潜在用户；甚至还可以来自竞争对手的产品。

• 需求分析原则

需求分析过程的具体实现有不同的分析方法，这些方法有自己独特的特点。然而，这些分析方法都遵循一组操作原则。

1. 必须能够表示和理解问题的信息域。
2. 必须能够定义软件将完成的任务。
3. 必须能够表示软件的行为（作为外部事件的结束）。
4. 必须规划描述数据、功能和行为的模型，总而可以分层次地揭示细节。
5. 分析过程应该从要素信息移向细节信息。

          通过这些原则，分析人员能够系统的处理问题。

• 需求工程
•  
• 需求获取

在需求获取阶段，系统分析人员通过与用户的交流、对现有系统的观察以及对任务进行分析确定系统或产品范围的限制性描述、与系统或产品有关的人员及特征列表、系统的技术环境的描述、系统功能的列表及应用于每个需求的领域限制、一组描述不同运行条件下系统或产品使用状况的应用场景以及为更好地定义需求而开发的原型。需求获取的工作产品为进行需求分析提供了基础。

需求分析于协商

需求获取结束后，分析活动对需求进行分类组织，分析每个需求与其他需求的关系，以检查需求的一致性、重叠和遗漏的情况、并根据用户的需要对需求进行排序。

系统建模

常见的分析和建模方法有面向数据流方法、面向数据结构方法和面向对象方法。

在软件需求分析阶段所创建的模型，要着重于系统要做什么，而不是如何去做，目标模型不应涉及软件的实现细节。

常见的分析方法有以下两种：

1. 面向数据流的结构分析方法（SA）。
2. 面向对象的分析方法（OOA）。

• 需求规约

软件需求规约是分析任务的最终产物，通过建立完整的信息描述详细的功能和行为描述、性能需求和设计约束的说明、合适的验收标准，给出对目标软件的各种需求。

需求规约作为用户和开发者之间的一个协议，在之后的软件工程各阶段发挥重要作用。软件需求规约中通常包含以下内容。

1. 引言。引言陈述软件目标，在基于计算机的系统语境内进行描述。
2. 信息描述。信息描述给出软件必须解决的问题的详细描述，记录信息内容、信息流和信息结构。
3. 功能描述。功能描述用来描述所需要的每个功能。
4. 行为描述。行为描述用于描述作为外部事件和内部产生的控制特征的软件操作。
5. 检验标准。检验标准描述检验系统成功的标志，即对系统进行什么样的测试，得到什么样的结果，就表示系统已经实现成功。检验标准是确认测试的基础。
6. 参考书目。参考书目包含了对所有和该软件相关的文档的引用，其中包括其他的软件工程文档、技术参考文献、厂商文献和标准。
7. 附录。附录包含了规约的补充信息，表格数据、算法的详细描述、图表和其他资料。

• 需求验证

需求验证作为需求开发阶段工作的复查手段，其目的是要检验需求功能的正确性、完善性、清晰性，能否反应用户的意愿。

需求验证需要对需求文档中定义的需求执行多种检查。评审人员检查时往往会检查以下内容：

1. 系统定义的目标是否与用户的要求一致。
2. 系统需求阶段提供的问答资料是否齐全；文档中断描述是否完整、清晰、准确地反映用户的需求。
3. 被开发的数据流与数据结构是否确且充足。
4. 主要功能是否已包括在规定的软件范围之内，是否都已充分说明。
5. 设计的约束条件或限制条件是否符合实际。
6. 开发的技术风险是什么。
7. 是否详细的制定了检验标准，他们是否对系统定义进行确认。

为了保证软件需求定义的质量，验证应该由专门的人员来负责，按照规定严格进行。参加的人员出分析人员之外，还要有用户，开发部门的管理者，软件设计、实现、测试的人员参加。

• 需求管理

在实际的开发过程中，获取、分析、建模、编写规约和验证这些需求开放活动通常是交叉、递增和反复地进行。而且，软件系统的需求会变更，这些变更不仅会存在于项目开发过程，而且会出现在项目已经付诸应用之后。软件需求管理是一组用于帮助项目组在项目进展中的任何时候去标识、控制和跟踪需求的活动，对需求工程所有工程所有相关活动的规划和控制。换句话说，需求管理就是一种获取、组织并记录系统需求的系统化方案，以及一个使用户与项目团队对不断变更的系统需求达成并保持一致的过程。

在需求管理中，每个需求被赋予唯一的标识符，一旦标识出需求，就可以为需求建立跟踪表，每个跟踪表标识需求与其他需求或设计文档、代码、测试用例的不同版本间的关系。例如，特征跟踪表，记录需求如何与产品或系统特征相关联；来源跟踪表，记录每个需求的来源；依赖跟踪表，描述需求间如何关联。

这些跟踪表可以用于需求跟踪。在整个开发过程中，进行需求跟踪的目的是为了建立和维护从用户需求开始到测试之间的一致性与完整性，确保所有实现都是以用户需求为基础，所有的输出符合用户需求并且全面覆盖了用户需求。需求跟着有两种方式正向跟踪和逆向跟踪。其中，正向跟踪以用户需求为切入点，检查《需求规约》中的每个需求是否都能在后续产品中找到对应点；逆向跟踪检查设计文档、代码、、测试用例等工作产品是否都能在《需求规约》中找到出处。