通过用例、用户故事、角色和场景来定义需求——保持项目节奏实践之六

要减少不必要的代码，有一个好方法：想想谁会使用系统，又该如何开发用户需要的系统。

有很多项目都试图通过定义功能性和非功能性需求来确定需求。可是这些需求没有说明一个人如何使用系统，以及一个功能在何种场景下必须运行。需求收集的方法应该为项目团队提供上下文，这样才能深入理解需求。

谁需要那个支票账户？

克拉丽莎，资深经理

我的项目团队陷入困境。他们实现了一堆只开发完一部分的功能，可是没有哪个能够真正运行。我召开了一个会议，以决定接下来该做什么。

在会议上，我想知道：为了完成项目，哪些用户是他们的首要服务对象。他们看着我，脸上毫无表情。“你们看，我们是一家银行。我们希望年满18岁、将要进入大学的人们首先使用我们的服务。还有住在郊外的妈妈们，她们还有其他资产，75岁的老奶奶，以及年方15已经靠做家务挣得零花钱的孩子们。我们可以为他们提供不同的理财服务。如果他们走进来，我们希望他们成为我们的客户。对于这些不同类型的客户，我们真地想过要给他们提供什么样的产品么？”

他们以前太过专注于系统的内部功能，忽视了系统真正要为之服务的用户。我们把期望捕获的用户重新进行了排序，项目团队因此得以完成需求定义，并完成系统的功能。

人，总是人的因素，不是么？

只要大家了解需求的上下文，开发人员、测试人员和文案人员就能知道如何开发、测试、编写文案。如果他们不能了解，要是需求以功能性和非功能性需求的方式罗列，他们也可以问一些更好的问题，从而深入了解需求。