在十年前，我热衷于研究软件的开发方法论，尝试将各种模型和技术用于解决项目难题。然而，现在我更注重应用“最佳方法”。这种方法强调将软件工具包拆分成多个子包以分别应用于不同的问题，而并不是去设计或购买一整套的解决方案。即使你采用了一套商业上的方法，你也应当从中提取出好的技术，将它有效地应用于实践。
“最佳方法”这个词值得我们深入讨论：谁能确定什么是“最佳”的呢？而且，得到这个结论的依据又是什么？一种可能的方案是把这方面的专家召集起来分析众多不同组织中成功和失败的项目。专家们将那些成功项目中提供高效的方法以及失败项目中导致低效甚至无效的方法都归纳出来。这样，专家们就能找到公认的能收到实效的关键方法。这些方法即是“最佳方法”，其本质就是有助于项目成功的有效方法。
以下是关于需求工程的推荐方法：
需求开发 6和分析是软件开发过程中至关重要的步骤，它确保了产品满足用户的需求和期望。下面是对您提供的需求开发步骤的解释和建议：
这些步骤中，有些可能是您的项目所必需的，而有些可能不那么关键。建议您根据项目的实际情况和资源，优先实施那些对项目影响最大且相对容易实施的方法。随着项目的进展，您可以逐步引入更复杂或更深入的技术和方法。
在实施需求工程时，没有必要采用所有可能的方法。相反，应该根据项目的具体情况、团队的经验和资源来选择合适的方法。以下是一些建议，可以帮助你评估和选择适合自己项目的需求工程方法，并设计一个实施步骤图来改进需求过程：
在选择具体的需求工程方法时，可以考虑以下方面：
最后，记得需求工程是一个持续的过程，需要根据项目的发展和变化不断地进行调整和优化。
软件开发团队成员中，并非所有人都系统地学习过高效需求工程所需的专业技能。然而，在实际工作中，许多开发者在项目生命周期的不同时期会参与到需求分析的过程中，与客户紧密合作，共同进行需求的收集、分析和文档编制工作。尽管一些人可能具有良好的沟通“天分”，但依赖于个人天赋并不足以确保高质量的需求管理。因此，通过专门的培训来提升团队成员在需求工程方面的能力是至关重要的。
鉴于需求定义对项目成功起着决定性作用，所有关键项目干系人都应该认识到需求工程的重要性、合理性和实施方法的基础知识。组织为期一天的需求工程流程简介研讨会 13，邀请包括开发人员、市场营销人员、客户代表、测试人员和管理人员在内的所有利益相关者参与，可以有效促进团队间的协作理解。这样的活动能使每个参与者意识到各自面临的挑战以及为了团队整体成功需要承担的责任。
对于直接负责收集、记录和解析用户需求的开发人员来说，应接受更为深入的需求工程基础培训，甚至是一周或更长时间的专项训练。资深需求分析师则应当通过充分的信息交流和应用领域的深入了解，熟练掌握并运用成熟的需求工程技术。
同时，参与软件开发过程中的用户代表和管理层也应该参加一天左右的需求工程基础知识培训，这包括开发项目经理和客户方管理者。此类培训有助于他们认识到强化需求阶段工作的重要性以及忽视需求管理所带来的潜在风险。不少用户在参加了需求研讨后反馈说，这加深了他们对软件开发人员工作的理解和尊重。
为增强开发人员对业务应用领域的认识，可安排一系列简短的讨论会议，介绍客户的日常运营活动、专业术语和目标等内容。这样可以帮助开发人员建立起对应用领域的基本认知，减少因误解而造成的返工问题。考虑为每位开发人员指定一个用户伙伴，以便在整个项目过程中解释业务相关的术语和概念；产品负责人或业务分析师可以扮演这一角色 14。
最后，为了减少因行业术语和词汇使用导致的沟通歧义，建议编写一份详尽的项目术语汇编，其中明确界定项目应用领域内专用词汇的意义和用法。这份汇编不仅应涵盖有多重含义或多用途的术语，还应包含那些在特定领域和通用语境中有不同释义的词语。
在项目中，需求的三个层次包括：
为了有效管理这些需求，需要建立一套流程，涵盖收集、分析、细化和验证步骤，并文档化。项目视图和范围文档定义了业务目标，为功能和用户需求提供框架。将用户分类有助于精准获取需求。每类用户选出代表，确保他们的需求被理解和记录。核心队伍由典型用户组成，提供丰富的现场反馈。
使用实例由用户代表定义，展示如何与系统交互。开发联系会议促进沟通，帮助草拟需求文档。通过分析用户工作流程，可以更深入地了解实际的业务操作，这可能揭示现有流程的改进点。
除了功能性需求，非功能质量属性（如性能、可靠性）也至关重要。问题报告提供了改进的方向和特性增加的想法。考虑需求重用可以提高效率，降低成本。
为了有效地进行需求开发，应制定以下步骤：
综上所述，正确且全面地处理这三层需求，并遵循规范的需求开发过程，有助于确保最终开发出的产品既能满足客户业务目标，又能提供优质的用户体验，并达到预期的质量标准。
需求分析是软件开发生命周期中的关键阶段，它涉及对收集到的需求进行深入的审查、验证和细化。以下是需求分析中的一些核心活动：
提炼与审查：分析员要确保每个需求清晰无误，没有歧义或遗漏，并且所有利益相关者都能理解其含义。这包括对照优秀需求说明的标准检查需求规格说明书。
多视图描述与分析：采用文本、图形等多种形式来表达需求，例如系统上下文示意图（System Context Diagrams），有助于从不同角度揭示潜在问题，促进各方共识。
绘制系统上下文示意图：此步骤用于界定系统的边界，展示系统与外部实体之间的交互关系以及信息流和物质流的方向。
创建用户接口原型：在需求不明确时，通过构建初步的用户界面原型，可以让团队成员和用户直观地理解设计概念和操作流程，从而发现并解决需求文档与实际应用间可能存在的冲突。
需求可行性分析：评估每项需求在成本、性能等约束条件下的实现可能性，识别实施风险，如与其他需求间的冲突、对外部因素的依赖和技术挑战。
确定需求优先级 16：利用分析技术为各项需求设定优先级，以便决定哪些功能将被纳入当前版本开发计划，并根据变更管理策略调整产品迭代内容。
建立需求模型：使用各种图形工具构建需求模型，如数据流图（DFD）、实体关系图（ERD）、状态机图、对话框图、UML类图和序列图 17等，以可视化方式查找和修复错误、不一致性和冗余。
创建数据字典：数据字典是定义项目中所有数据元素和结构的标准文档，保证团队成员对数据的一致理解和使用，尤其是在需求阶段对客户数据项的定义。
运用质量功能展开（QFD）：这是一种量化客户需求的技术，通过对需求分类（期望需求、普通需求和兴奋需求），帮助团队关注那些对客户价值影响最大的特性，优化资源分配，满足用户的隐性需求和显性需求。
综上所述，需求分析阶段的目标是形成准确、全面且可度量的需求文档，以便于后续的项目估算 18、设计、编码和测试工作，最终交付符合甚至超越客户期待的产品。
在软件开发过程中，需求管理是一个严谨且系统化的过程，确保所有需求都能被清晰、一致地记录并保持可追溯性。以下是您所描述的几个关键步骤：
在软件开发流程中，需求验证 22是确保产品成功的关键环节，它旨在确认需求规格说明书（SRS）的准确性和完整性，并为后续的设计、实现和系统验证提供可靠的基础。以下是您所提到的需求验证过程中的几个核心步骤：
处理项目需求变更时，有效的变更管理至关重要。这包括评估变更的潜在影响和可能的成本，并通过变更控制委员会与关键风险承担者协商确定实施哪些变更。跟踪需求状态对于管理过程也是不可或缺的。
配置管理方法对于需求管理至关重要。版本控制等技术不仅适用于代码管理，也可用于需求文档的管理。引入新的管理配置方法可以提升组织的需求管理效率。
建立需求变更控制流程，确保所有变更都经过选择、分析和决策过程。商业化的问题跟踪工具能够支持这一流程。
创建由项目风险承担者组成的变更控制委员会，负责确定、评估和决策哪些需求变更将被实施，以及它们的优先级和计划安排。
进行需求变更影响分析以评估对项目计划和其他需求的影响，明确相关任务及所需工作量，帮助委员会做出更好的决策。
跟踪所有受需求变更影响的工作产品，包括其他需求、设计模板、源代码和测试用例，以确保一致性并减少疏忽。
建立和维护需求基线 24和控制版本文档，使用配置管理工具进行版本控制，保持文档的清晰和组织。
记录需求变更历史，包括变更日期、原因、负责人和新版本号，以便追踪和审计。
建立数据库跟踪每项需求的状态，包括其重要属性和进展状态，这有助于随时获取项目需求的最新情况。
衡量需求稳定性，通过记录基本需求数量和定期的变更数量来评估项目管理的有效性。
使用需求管理工具来存储不同类型的需求、确定属性、跟踪状态，并在需求与其他软件开发工作产品之间建立联系链。
总之，软件工程管理方法在本质上与项目的需求过程是紧密相关的。为了应对需求变更和项目范围 25扩展，项目计划应允许一定程度的灵活性。组织应根据不同类型的项目和需求说明的不同程度选择几种不同的软件开发方法。在项目开发过程中，随着需求细节的不断清晰和完善，项目开发计划的进度安排也会不断改变。当需求发生变更时，需要协商项目约定并更新风险管理计划。同时，要跟踪需求工程所耗的工作量，以便评估需求活动是否达到预期要求并为将来的项目提供更好的资源计划。
以下是一些可能的障碍和解决方案：
在表格中，请为每种方法标注项目团队对应的能力水平，按照以下分类进行评估： - 专家：团队成员对该方法有深厚理解和丰富实践经验 - 熟练者：团队中有人能熟练应用此方法，并取得过良好效果 - 生手：团队具备一定的基础但尚不熟练，需要更多实践提升 - 新手：团队对此方法接触较少或完全陌生
倘若发现团队在任何一种关键方法上未达到熟练程度，则应采取行动： - 安排团队内某一成员专门负责学习该方法的深入知识与技能； - 学成后，要求这位成员将所学内容以培训或其他形式分享给团队其他成员，以提升整个团队在这方面的应用能力。
本文同步发表在 软件需求探索的https://srs.pub/theory/xu-qiu-gong-cheng-de-tui-jian-fang-fa.html