在软件系统的整个开发过程中，需求分析是非常重要的一个环节，这一点大家都知道，这句话估计很多人都能脱口而出；然而在实际应用中，却往往容易被人忽视。为什么会出现这种情况呢？我想这也是可以理解的。理论毕竟是理论，与实际应用会有所偏差。比如一些外包项目，由于时间的紧迫，团队必须在较短的时间里做出最快速的反应，如此一来，诸如需求分析、文档管理等过程就会出现混乱，甚至是“避而不谈”，等客户需要相关文档的时候再补。其实这样做也无可厚非，因为实际问题摆在眼前，客户希望在最短的时间内看到结果，至于如何实现，他们并不关心。
然而有的项目，在功能性需求的基础上，客户会对其它的非功能性需求作出要求，例如安全性和高效性，有时候甚至会对项目的实现技术进行干预。比如我有碰到有些客户希望采用.NET来实现整个系统，他们并不会在意，各种软件技术诸如C++和C#的差异有多少，更不会去了解各种技术的优缺点在哪里，当时他们给我的理由是：“现在.NET不是很流行么？就用.NET吧。”。好了，现在让我们从架构设计的角度来看整个系统的设计：我们的客户已经给我们划出了“边界线”：请在.NET的范围内考虑问题！当然你完全可以根据实际情况来决定.NET是否真的合适，如果你发现的确不合适，那么你就应该跟你的客户交涉，提出你的观点，然后双方达成一致。
对于效率要求很高的系统，在系统的其它特性上就会有所保留，比如扩展性。在做设计的时候，你或许会把数据访问机制单独划分到一个层中，通过使用工厂模式或者ORM框架来完成数据库操作，这样做的好处是显而易见的：领域逻辑完全不需要关心对象的持久化细节（怎么保存、保存到哪里等一类技术问题），但它所带来的负面影响就是效率不会很高，起码与ADO.NET的方式相比，效率会有所损耗。因此，此时你不得不在扩展性和高效性上做出抉择，抉择的依据是什么？是客户需求，是系统运行环境的资源分配，是系统在未来一段时间的可变性，同时还有你的设计经验。
回过头来再看功能性需求。其实并非所有的功能性需求都是刚性需求，现在我们把功能性需求简单的分为两种：“刚性需求（Must Have）”和“柔性需求（Nice To Have）”。对于刚性需求，没有办法，你不得不将其实现于你的应用系统中，因为如果不做，那软件系统就不具有解决基本领域问题的能力，也自然无法让客户或者用户接受；而对于柔性需求，我认为，应该在可行、稳定的范围内做选择，这时候也应该跟客户共同商讨。比如，假如客户需求的某个功能并非关键功能，但要实现这个功能却需要投入相当大的人力物力资源，或者在技术上没把握，不能确保它能稳定运行，那么我们可以商讨，要么将这个功能的时间延后（比如放入下个阶段或者下下个阶段再完成），要么直接取消这个功能。
事实上，需求中还有很多隐含的东西，就好比人说话会有隐喻一样。例如做数据传输，那数据的加密、校验也就成了一项不可缺少的功能，本文不深入谈论需求分析，所以在此也就不多说了。由此可见，并非所有需求都能决定软件系统的架构，也不是所有的功能性需求。架构选择是功能性需求与非功能性需求的综合考虑因素。还是引用温昱顾问的那句话：关键需求决定架构。
与现行的软件设计方法一样，领域驱动设计（简称DDD，下同）也应该从需求分析开始。需求分析往往需要客户、领域专家以及软件人员共同参与，领域专家和软件人员共同通过客户了解系统需求，在需求的探讨和分析过程中，两者又与客户进行沟通，尽量在领域模型与软件模型之间做到平衡，而软件人员还要从领域专家那得到相关的领域知识。在实际中，客户和领域专家往往不懂软件，而软件人员又往往不了解领域知识，为了解决这个矛盾，DDD引入了通用语言。所谓通用语言，是建立在领域基础上的一套表达工具，可以是图表，可以是文档，甚至可以是简单的几个文字，关键就是要能够缩小客户、领域专家和软件人员之间的交流沟壑。根据DDD经验，UML不适合用作通用语言，因为它太通用了，不足以表示特定领域。通用语言也不应该是需求分析阶段的专利，只要有交流需要，就可以考虑使用通用语言。
与本节开头所述一样，软件项目完全可以没有需求分析，毕竟很多项目需求实在是简单明了，或者这些项目时间太紧，资源上安排不过来，或者客户图价格便宜，对软件质量要求不高。本节介绍需求分析的目的在于阐明在做软件设计的时候，需要权衡各种因素，再选择合适的架构设计，而这些因素又主要来源于需求。本系列文章介绍DDD在.NET下的实践，但并非是DDD的完全照搬，现实系统中，我们将会遇到很多Anti-DDD的东西。