在这里再谈下需求和设计的边界问题，我们最终的业务系统实现出现的偏差，究竟是需求的问题还是设计的问题？如果边界不清楚则很难明确的区分。对于需求本身有原始需求，用户需求，产品需求和系统需求的各种阶段；而对于需求的过程也本身存在原始需求的收集，需求分析，需求挖掘，和需求相关的业务建模。而对于设计同样存在总体的企业架构设计，到单个应用的总体设计和架构设计，概要设计和详细设计。
需求的重点是描述清楚现实世界，而设计的重点则是将现实世界的需求转换为抽象的模型。这是我们说的需求和设计的大边界，但是需求里面也不是简单的需求定义和挖掘的问题，还涉及到业务建模，业务建模和架构总体可以说是衔接需求和设计的重要内容。
在面向对象的需求分析方法中，用例建模涉及到的内容包括了业务流程，业务活动和操作，异常和边界，业务规则，业务对象模型，模块和接口等各个方面的内容，也是我们常采用的系统需求定义和编写的方法。即需求重点还是定义清楚问题，而不是管具体的实现方式。在对用例建模的方法基础上，往往再加入了界面原型和通用的UI/UE规范约束等各方面的内容，以进一步的细化需求。即我们将需求更进一步，从最初的需求用例增加了界面原型建模，到基于界面原型的界面操作和业务交互操作建模。
对于传统的需求和设计边界，往往即只做到系统用例层面，而让设计和实现有更多的发挥空间。在这种场景下最容易发生的问题就是在出现偏差的时候很难真正去界定究竟是需求的问题还设计的问题。在定义需求的时候，我们强调每一个需求条目本身的完整性和可验证性，但是这本身并不代表需求本身的粒度就合适，如果说一个需求最终去追踪设计的时候，发现大量的1对多的映射关系，那么可以讲需求本身的粒度和细化程度出了大问题，对于这种粗粒度的需求最终业务系统实现为什么样子我们也很难把控。
需求本身也是渐进明细和迭代的过程，为了进一步界定需求和设计的关系，可以讲任何不设计到设计层面建模的内容的都纳入到需求范围，设计建模包括了数据库设计，核心的类设计和对象模块，模块间交互和接口设计，具体一个业务功能的更详细类交互设计等。这些很明细是抽象层面的内容，那么除掉这些内容都可以作为是需求需要去考虑的内容。一个界面上的布局，控件的选择和交互，操作的易用性全部纳入到需求范围，这些的定义不涉及到具体的实现层面的类和代码逻辑，也是一种合理的方式。需求可以渐进明细并逐步精化，但是要意识到需求必须要管到这个层面，做需求的人时刻要考虑到按你需求做完的东西真正是客户想要的东西，需求分析和开发人员必须要对最终的交付负责，而设计开发人员则更多的是为需求的实现负责而已。
需求和设计可以有边界，但是更加重要的是需求和设计之间的衔接问题，任何只懂业务或只懂技术的人往往都很难真正做好这块的内容，而这块内容往往正是传统的系统分析员的核心价值。