业务需求转为IT要求之“Outside-in”设计

 作者介绍：Donald Ferguson 软公司SOA首席架构师

 需求文档和建模工作应定义开发工作输出的测试用例。如果团队无法将需求转换为测试用例，团队就没有理解这些需求。

　　–Don Ferguson

这是个很好的问题，我希望给出而且也能给出一个很好的回答。我想，解决此问题的最重要方法就是在开发流程和开发规则的过程中保持耐心。

很多项目并不能在需要的时候获得前端需求文档与分析以及业务建模。有时候，似乎会存在不利于提高编码效率的未说明的假设。正式的一流需求处理、流程建模和构件建模可能非常费时，但同时也能确保开发过程的结果能完美地满足业务需求。需求文档和建模工作应定义开发工作输出的测试用例。如果团队无法将需求转换为测试用例，团队就没有理解这些需求。

开发也需要进行迭代。我们从 Eclipse 开发和其他项目了解到，我们的开发工作每四到六周就需要生产出可以使用的过渡性版本。该版本应该提供给业务干系人使用，并验证项目是否满足了业务需求。每个过渡性版本阶段均应以一组得到一致认可的并且该版本将满足的需求和用例/场景作为出发点。

最后，我们已经开始在尝试用一个称为"Outside-in-in design"的概念。在此方法中，我们依赖于以下原则：

　　●　进行正式的用户建模，包括角色和用户概念对象

　　●　为与概念对象交互的角色定义一组用例

　　●　提供用例/场景的低精度和高精度可视模拟（有时简单得像纸上的铅笔画一样。通过这种方式，解决方案的用户可以提供早期评估和反馈。）

　　●　构建过渡性版本

　　●　此过程不是瀑布型的，而是迭代过程。（此方法可帮助提供项目的持续细化，以确保其向提高业务需求和要求的满足程度方向发展。）

未经允许不得转载：DOIT » 业务需求转为IT要求之“Outside-in”设计