启动用户组需求不准问题反思

两周的工作量。

管理性需求，涉及及的方方面面都不了解的情况下，所做的功能设计，能完全正确的可能性小。

1.领导很重视的功能，为什么不拉着领导催下属确认一下界面设计。
2.已经实现的功能，领导很重视。为什么不催促确认一下是否正确。

发现问题后，两个解决思路：

1.小修小改先对付用。
2.大改，有2/3的设计要推翻。


如果需求仍不能确定准确，应该采用小修小改方式，尽量投入使用。这样可以避免再次的拍脑门。最终获得准确的需求。

注意：迭代式开发，不是拍脑门定需求的借口。2人周的代价比较大，再加上之前按单用户进行的配置的一版开发投入（需求确定的太轻率），应该也有1周。
3周的时间太浪费了。

这种情况，应该编写业务用例（业务过程），去明确分支行的审批过程。可惜因为沟通的问题，配合的问题，这些事不好做。

可先编写需求分析文档,设计用户界面。然后制作界面原型和用户确认功能，然后再开发。这里不是让用户去发现界面是否好用，而是要主动的和用户一起走一下业务过程。一方面确认业务用例。另一方面，在业务用例中观察功能的正确性。

注意:代码质量是重要的，这是修改的基础。
     小修小补的办法，要考虑到如果功能可行，用户推广使用后，还可能需要扩展修改。 如果修改数据结构，这时已有的用户数据就是问题了。在数据结构上，不必追求完美精确的设计，但一定要把握住领域的本质，否则小修小补的办法将导致将来很难再扩展修改。

-----------------------------------------------------------------------------
    用例似乎处处有用，却不能普遍的形式化的使用的原因，就在于用例本身的灵活性。
用例是分层次的，有时需要的是用例的思想，有时需要的是用例的形式。

    开发软件最初应该确定的是业务及的用例，采用用例描述进行表达。这时的用例描述是最有价值的，它保证了软件所应用的业务过程是正确的。注意：太高层的用例描述不会有太大用，因为它揭示的软件功能有限；对应软件界面的用例描述也没太大用，因为这个描述和业务相关性小，大多内容是界面交互过程描述。这时应该按用例思想去思考，用界面设计去表达。这时的用例描述，既要体现正确的用户业务，又要明确软件的功能。这样的用例，和软件的功能可能是不能整齐对应的，也不能直接进行工作量估算。需要根据这样的用例，找出对应软件功能的子用例（功能点）去进行估算。

   如果无法明确业务用例，那只能拍脑门定一下，然后迭代逼近正确的业务过程。
 
   业务用例包含了软件要实现的功能性用例。
   功能性用例，需要用用例的思想去设计，研究什么用户用，怎么用，如何达成用户目标。但最终会表达为交互设计。使用用例描述是不恰当的。

   进行需求分析时，采用用例进行思考始终是该做的事，是否需要形式化的用例表达，是不一定的。对于软件具体的功能，用例只是分析的开始。由此可以推论，只有对业务过程的分析是可以靠用例完成的。