谈需求和设计

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