欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页

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

程序员文章站 2022-07-03 14:20:33
...
两周的工作量。

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

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

发现问题后,两个解决思路:

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


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

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

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

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

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

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

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

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

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