软件需求
在进行需求获取之前，首先要明确需要获取什么，也就是需求包含哪些内容。软件需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。通常，这些需求包括功能需求、性能需求、用户或人的因素、环境需求、界面需求、文档需求、数据需求、资源使用需求、安全保密需求、可靠性需求、软件成本消耗与开发进度需求等，并预先估计以后系统可能达到的目标。此外，还需要注意其他非功能性的需求。具体内容如下。
（1）功能需求。
（2） 性能需求。
（3）用户或人的因素。
（4）环境需求。
（5） 界面需求。
（6） 文档需求。
（7） 数据需求。
（8） 资源使用需求。
（9）安全保密要求。
（10）可靠性要求。
（11）软件成本消耗与开发进度需求。
（12）其他非功能性要求。
1. 需求分析的任务
需求分析主要是确定待开发软件的功能、性能、数据、界面等要求。具体来说有下面几点。
（1）确定软件系统的综合要求，包括系统界面、功能、性能、安全性、保密性、可靠性、运行等方面的要求。
（2）分析软件系统的数据要求，包括基本数据元素、数据元素之间的逻辑关系、数据量、峰值等。
（3） 导出系统的逻辑模型，在结构化方法中可用数据流图来描述；在面向对象分析方法中可以用类模型来描述。
（4）修正项目开发计划。
（5）如有必要，可开发一个原型系统以验证用户的需求。
2.软件需求的分类
下面介绍软件需求的分类。
（1）功能需求。所开发的软件必须具备什么样的功能。
（2）非功能需求。它是指产品必须具备的属性或品质，如可靠性、性能响应时间、容错性和可扩展性等。
（3）设计约束。其也称为限制条件、补充规约，这通常是对解决方案的一些约束说明。
3.软件需求分析方法
需求分析方法由对软件的数据域和功能域的系统分析过程及其表示方法组成。它定义了表示系统逻辑视图和物理视图的方式。大多数的需求分析方法是由数据驱动的，数据域具有数据流、数据内容和数据结构 3 种属性。通常一种需求分析方法总要利用其中一种或几种属性。
需求分析原则
需求分析过程的具体实现有不同的分析方法，这些方法有自己独特的特点。然而，这些分析方法都遵循一组操作原则。
（1）必须能够表示和理解问题的信息域。
（2）必须能够定义软件将完成的任务。
（3）必须能够表示软件的行为（作为外部事件的结束）。
（4）必须划分描述数据、功能和行为的模型，从而可以分层次地揭示细节。
（5）分析过程应该从要素信息移向细节信息。
通过应用这些原则，分析人员将能系统地处理问题。检查信息域可以更完整地理解功能，通过模型可以更简洁地交流功能和行为的特征，应用抽象与分解可减少问题的复杂度。
需求工程
需求工程是一个不断反复的需求定义、文档记录、需求演进的过程，并最终在验证的基础上冻结需求。需求工程可以细分为需求获取、需求分析与协商、系统建模、需求规约、需求验证以及需求管理6个阶段。
1.需求获取
在需求获取阶段，系统分析人员通过与用户的交流、对现有系统的观察以及对任务进行分析确定系统或产品范围的限制性描述、与系统或产品有关的人员及特征列表、系统的技术环境的描述、系统功能的列表及应用于每个需求的领域限制、一组描述不同运行条件下系统或产品使用状况的应用场景以及为更好地定义需求而开发的原型。需求获取的工作产品为进行需求分析提供了基础。
2.需求分析与协商
需求获取结束后，分析活动对需求进行分类组织，分析每个需求与其他需求的关系，以检查需求的一致性、重叠和遗漏的情况，并根据用户的需要对需求进行排序。在需求获取阶段，经常出现以下问题∶用户提出的要求超出软件系统可以实现的范围或实现能力；不同的用户提出了相互冲突的需求；每个用户在提出自己的需求时都会说“这是至关重要的”，所以系统分析人员需要通过一个谈判过程来调解这些冲突。
3. 系统建模
建模技术可以通过合适的工具和符号系统地描述需求。建模工具的使用在用户和系统分析人员之间建立了统一的语言和理解的“桥梁”，同时系统分析人员借助建模技术对获取的需求信息进行分析，排除错误和弥补不足，确保需求文档正确地反映用户的真实意图。常用的分析和建模方法有面向数据流方法、面向数据结构方法和面向对象方法。
4.需求规约
软件需求规约是分析任务的最终产物，通过建立完整的信息描述、详细的功能和行为描述、性能需求和设计约束的说明、合适的验收标准，给出对目标软件的各种需求。需求规约作为用户和开发者之间的一个协议，在之后的软件工程各阶段发挥重要的作用。软件需求规约中通常包含以下内容。
（1）引言。
（2）信息描述。
（3）功能描述。
（4）行为描述。
（5）检验标准。
（6）参考书目。
（7）附录。
5.需求验证
需求验证作为需求开发阶段工作的复查手段，其目的是要检验需求功能的正确性、完整性和清晰性，是否能够反映用户的意愿。
需求验证需要对需求文档中定义的需求执行多种检查。开发团队要对用户需求进行“遍访”，逐条解释需求含义；评审团队应该检查需求的有效性、一致性和作为一个整体的完备性。评审人员评审时往往需要检查以下内容∶
（1）系统定义的目标是否与用户的要求一致。
（2）系统需求分析阶段提供的文档资料是否齐全；文档中的描述是否完整、清晰、准确地反映了用户要求。
（3）被开发项目的数据流与数据结构是否确定且充足。
（4）主要功能是否已包括在规定的软件范围之内，是否都已充分说明。
（5）设计的约束条件或限制条件是否符合实际。
（6）开发的技术风险是什么。
（7）是否详细地制定了检验标准，它们能否对系统定义进行确认。
6.需求管理
在实际的开发过程中，获取、分析、建模、编写规约和验证这些需求开发活动通常是交叉、递增和反复地进行。而且，软件系统的需求会变更，这些变更不仅会存在于项目开发过程，而且会出现在项目已经付诸应用之后。软件需求管理是一组用于帮助项目组在项目进展中的任何时候去标识、控制和跟踪需求的活动，对需求工程所有相关活动的规划和控制。换句话说，需求管理就是一种获取、组织并记录系统需求的系统化方案，以及一个使用户与项目团队对不断变更的系统需求达成并保持一致的过程。
未完待续。。。
更多知识传送：
计算机操作系统–基础知识
计算机操作系统–进程管理
计算机操作系统–存储管理
计算机操作系统–设备管理
计算机操作系统–文件管理
计算机操作系统–作业管理
计算机操作系统–网络操作系统和嵌入式操作系统
计算机操作系统–UNIX操作系统
软件工程基础知识–认识软件工程
软件工程基础知识–软件过程模型
～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～
以上内容整理参考《软件设计师教程（第5版）》和《软件设计师考试同步辅导（第四版）》（忘记是哪个老师的了，侵删）。本文章内容旨在帮助更多想要进军软考，给自己镀金的小伙伴。有兴趣的小伙伴可以共勉。
