早在1987年，《人月神话》的作者Frederick Brooks就在 NoSilver Bullet - Essence And Accidents Of Software Engineering 中说过：“开发软件系统最为困难的部分，就是准确说明开发什么”。需求之所以困难，是因为其展现出了两个方面的复杂性：

1. 范围辽阔

需求的范围，不仅包括我们常规理解的软件，还应包含硬件与人。在实际工作中，为了帮助客户解决他们的问题，便要“想客户之所想”——站在客户所处系统的整体环境中发觉问题。问题的发觉，就是对客户所处的现实世界的运行情况的深入挖掘。不仅要挖问题的表象，还要挖其背后的核心。弄清了客户的问题后，需求人员要将这些问题“翻译”给开发人员，让开发人员能够清晰理解现实环境对软件的要求，形成软件的需求规格说明；并且在客户与开发人员之间，建立起工作连接，产生合理的互动。

到这里就结束了吗？当然没有。变化总是发生得那么悄无声息，又出现得那么惊天动地。我们无法控制需求的变更，便只能对需求进行动态管理。这是一项贯穿项目始终的工作。因此需求工程，绝不是我们所认为的、只发生在软件需求阶段的工作。而是在立项之前就开始，并在项目的整个生命周期中一直持续存在。

软件需求工程的主要任务，包括明确系统目标和应用环境；将现实映射到软件；动态管理目标、功能、环境和约束。这三点，便是对需求范围辽阔而导致的复杂性的提炼。

2. 干系人纷扰

随着软件产品化趋势的显著，使得很多软件企业的组织架构逐渐向职能化发展——营销部、需求分析部、前端开发部、后端开发部、测试部、实施部、运维部、客服部……这样的组织架构，有助于深化产品，做精做细；同时也削弱了对产品的集成管理能力。职能型的组织架构，会导致缺乏真正意义上的项目经理，增加部门间的沟通壁垒。在项目进展的关键节点，缺失对关键工作依赖关系的协调管理能力。这是内部干系人的纷扰。

外部干系人就更为复杂了。庞大的用户数量的增长，在量级和复杂度上，都对需求的统一和协调提出了管理质变的要求。更为关键的是，干系人真正的复杂性并不在于种类、数量的多少，而在于他们的环境背景、所处的领域、知识架构、思维与表达逻辑等，都存在着极大的差异化。软件想要解决这些干系人在现实环境中的问题，就要全面分析、系统处理、整合统一这些差异所产生的不同需求及其之间的关系。这个过程，想想都是极其困难且风险重重的。

尽管需求工程如此复杂，也没有挡住工程师们解决它的步伐。经过多年的发展，对需求工程基本活动的研究已经日趋成熟，主要分为需求开发和需求管理两大方面：

需求开发，将“需求”通过技术手段显现出来，包括了对需求的获取、分析、规格说明，以及确认。

需求管理，在整个项目的生命周期中，保证需求与工作的协调一致性，包括了理解与承诺管理、需求变更管理，以及维护需求的双向可追溯性。

这些需求工程活动，对需求工程师有哪些具体的要求呢？

在第14届IEEE国际需求工程师大会上，Ban Al-Ani和Susan Elliott Sim给出了需求工程师的关键专业领域模型。

抽取指的是在“需求获取”活动中，需求工程师挖掘需求的能力。抽取这个词，更具形象色彩，它体现了需求之间的隐藏与缠绕关系。需求工程师想要在一团乱麻的需求中抽丝剥茧，需要洞察外部干系人的业务逻辑与场景、工作过程与依赖关系、存在与潜藏的问题及其之间的关系，并将这些关键信息整合起来，还原出全面而准确的现实环境。

抽取过程中，切忌被客户“牵着鼻子走”。客户能表达出来的需求，通常只是现实世界的表象问题。这部分在图一中，仅仅是“系统---目标与应用环境”范畴中的一部分。需求工程师如果将这样的需求作为整体需求，就一定会遇到需求错误、需求增加、需求冲突、需求不一致等各种问题。这些问题往轻里说，会导致返工、延期、客户满意度下降……往重了说，会导致项目失败、亏损、公司声誉受损等重大的风险问题。

因此，夯实现实环境的基础，才能在此之上进行靠谱的需求分析。

分析指的是“需求分析”并将其转化为“需求规格说明”的能力。经过抽取，我们获得了现实世界的“画像”（原始需求）。下一步，便要分析原始需求的缺陷——有没有遗漏？有没有错误？有没有不一致？将原始需求具体、细化到适当的颗粒度。利用建模技术，将现实世界映射成软件行为，形成清晰的用户需求描述，确定不同需求的优先级顺序，将用户需求传递给开发人员，形成软件的需求规格说明。

需求分析的核心，是要达成项目组与客户间对需求信息的共同理解，并在此基础上创建软件解决方案。为了形成共同理解，需要将复杂的系统性问题分解为简单、独立的子问题，确定本质特征，摒弃次要特征。因此，在需求分析的过程中，需要的核心能力是抽象与分解。我们常用的各类建模技术，就是对抽象与分解的应用。

需求规格说明，是需求在不同工作任务与角色间流转的实体。编写需求规格说明需要书面表达技巧，简洁、精确、一致且易于理解，就是最好的需求规格说明文件。

确认通常以评审的方式，发生在需求获取、需求分析、需求规格说明、需求管理的全过程，以及内外部所有干系人之间。确认过程中，所有干系人都将就需求的正确性与可执行性展开讨论，形成对需求的一致理解。理解一致的需求有助于“一次做对”后续工作，减少因需求引入缺陷而造成返工与成本浪费。

由于需求影响了设计、开发、测试、交付、运维等后续所有活动。因此，需要通过需求管理保障需求的持续、稳定与有效。需求管理包括理解和承诺管理、需求变更管理、维护双向可追溯性。集成管理可以有效支撑需求被正确的理解与实现；变更控制过程可以有效管理需求变更的发生，而需求跟踪矩阵可以实现对需求变更的跟踪与一致性管理，维护需求的双向可追溯性。

沟通几乎覆盖了整个需求工程乃至软件工程的过程，包括口头、书面和其他形式。关于沟通与协调的技巧，我们在《万年老大难，沟通与协调》以及《给你一首歌的时间》中都有过说明。在此我只想强调，沟通是为了协调，协调是为了一致理解关键信息，作出工作承诺，并完成工作。

通过上述分析，我们可以发现，仅做好需求开发工作，就需要同理心、观察技巧、认知能力、领域知识、语言表达能力、结构化分析能力、抽象与分解能力、书面表达能力、建模技术、评审技术等多种能力。而需求管理工作涉及到的集成管理能力（工作过程管理、干系人管理、集成计划管理等）、变更管理能力等，更是需要多角色的共同参与。

因此，一个人做好需求工程，是不可思议的。需求是一个复杂的事，一个持续的事，更是一个团队的事，一个值得深入探讨的事。要持续关注哦~