理解需求的重要性：“我知道你认为你理解我说的是什么，但是你并不理解的是：我所说的并不是我想要的”
需求工程 （Requirement Engineering，RE） 需求工程指致力于不断理解需求的大量任务和技术。需求工程通过执行7个不同的活动来实现：起始、导出、精化、协商、规格说明、确认和管理。 起始：项目起始阶段中，要建立基本的理解，包括对问题、谁需要解决方案、所期望解决方案的性质、与项目利益相关者和开发人员之间达成初步交流合作的效果。 导出：询问客户、用于和其他人，系统和产品的目标是什么、想要实现什么、系统和产品是如何满足业务要求、最终系统是如何用于日常工作； 精化：将起始和导出阶段的信息进行扩展和提炼，开发一个精确的需求模型，用以说明软件的功能、特征和信息的各个方面。 协商：解决客户过高需求与有限业务资源冲突的过程，让客户、用户和其他利益相关者对各自需求排序，按优先级讨论冲突； 规格说明：基于计算机的系统和软件的环境下，属于规格说明对不同的人有不同的含义。一个规格说明可能是一个说明文档、图形化的模型、形式化的数学模型、一组使用场景 、一个原型或上述任意组合。 确认：对需求工程的产品进行评估，检查规格说明，保证无歧义的说明的所有的系统需求、已检测出不一致性并得到纠正、工作产品符合过程、项目和产品建立的标准。 需求管理：用于帮助项目组在项目进展中标识、控制和跟踪需求以及需求变更的一组活动。
建立规格说明的大纲 目录 版本历史 1 导言 1.1 目的 1.2 文档约定 1.3 适用人群和阅读建议 1.4 项目范围 1.5 参考文献 2 总体描述 2.1 产品愿景 2.2 产品特性 2.3 用户类型和特征 2.4 操作环境 2.5 设计和实现约束 2.6 用户文档 2.7 假设和依赖 3 系统特性 3.1 系统特性1 3.2 系统特性2 …… 4 外部接口需求 4.1 用户接口 4.2 硬件接口 4.3 软件接口 4.4 通信接口 5 其他非功能性需求 5.1 性能需求 5.2 安全需求 5.3 保密需求 5.4 软件质量属性 6 其他需求 附录A：术语表 附录B：分析模型 附录C：问题列表 过程 2.2 建立根基 起始阶段，首先需要确认该项目的利益相关者（直接或间接从正在开发的系统中获益的人），如业务运行管理人员、产品管理人员、市场销售人员、内部和外部客户、最终用户、顾问等。需求工程师应创建一个人员列表。不同的利益相关者提出的需求可能是重复的、矛盾的或者有某种关联的，因此需求工程师的下一步工作是将利益相关者提出的需求进行分类整理。第三步是根据需求的分类和目标，确定在利益相关者之间要团结协作，并与软件工程人员紧密协作。这一步需求工程师需要划分利益相关者和开发人员的职责、标识公共区域（都同意的需求）和矛盾区域。 2.3 导出需求 利益相关者和开发团队应该共同完成：确认问题，提供建议，商讨解决方法。 协作收集需求：首先为明确问题并提出解决方案，需要由软件工程师和利益相关者共同参与讨论会议，明确项目的各方面需求、约束列表、性能标准等，尽可能收集需求，并将需求分类整理。 质量功能部署（Quality Function Deployment，QFD）：是一种将客户要求转化成软件技术需求的质量管理技术。在此过程中，QFD确认三类需求：正常需求（开会时客户确定的需求）、期望需求（隐含在产品或系统中，但客户没有显式说明，但缺少这些将导致用户不满，如人机交互的容易性、安装的简易性）和令人兴奋的需求（客户期望之外的特点，实现这些将使客户非常满意）。 用户场景：收集需求时，逐步具体化系统功能和特性的整体愿景。 导出工作产品：工作产品包括要求和可行性陈述、系统或产品范围的界限说明、系统技术环境的说明、需求列表、一些使用场景、任何能更好定义需求的原型等。 2.4 开发用例 用例讲述了能表达主体场景的故事：最终用户如何在一个特定环境下和系统交互。这个故事可以是叙述性的文本、任务或交互的概要、基于模板的说明或图形表示。用例是从最终用户角度描述了软件或系统。 撰写用例首先要确定参与者，然后再开发用例。参与者是任何与系统或产品通信的事务，且对系统本身而言参与者是外部的。参与者并不等于系统的最终用户。 2.5 构建需求模型 需求模型为基于计算机的系统提供必要的信息、功能和行为域的说明。 2.6 协商需求 在多数情况下，让利益相关者以成本和产品投放市场的时间为背景，平衡功能、性能和其他的产品或系统特性。协调的目的是保证所开发的项目计划，在满足利益相关者要求的同时反映软件团队所处真实世界的限制。 协商需求一般有以下活动： - 识别系统或子系统关键的利益相关者； - 确认利益相关者“赢”的条件； - 就利益相关者“赢”的条件进行协商，以便使其与所有涉及人的一些双赢条件一致。 2.7 确认需求 需求模型的每一个元素都已创建后，需要检查一致性、是否有遗漏以及是否有歧义。 每项需求都和系统或产品的整体目标一致吗？ 所有的需求都已经在相应的抽象层上说明了吗？ 需求是真正必须的，还是另外加上去的，有可能不是系统目标所必须的吗？ 每项需求都是有界定并且无歧义的吗？ 每项需求是标记了来源吗？ 需求之间有冲突的吗？ 现实资源环境基础上每项需求都能实现吗？ 一旦实现后，是否每项需求都可测试？ 需求模型是否恰当反映了将要构建系统的信息、功能和行为？ …… 总结 需求工程的任务是为设计和构建活动建立一个可靠坚固的基础。需求工程发生在于客户沟通活动和为一般的软件过程定义的建模活动过程中。软件团队成员要实施7个不同的需求工程职能：起始、导出、精化、协商、规格说明、确认和管理。 参考 http://www.tutorialspoint.com/software_engineering/pdf/software_requirements.pdf https://www.inflectra.com/Ideas/Whitepaper/Principles-of-Requirements-Engineering.aspx https://www.sciencedirect.com/topics/computer-science/requirement-engineering#:~:text=Requirements engineering is the process of eliciting stakeholder,as a basis for all subsequent development activities.
