在收到国外汇款时,业务人员需要记录汇款的相关信息,如果汇款指定的收款人帐户为本行帐户,进行入帐处理,如果收款人帐户属于同城同业(本地的其他银行),则通过同城同业转汇给收款人(后续如何处理?),如果收款人帐户属于异地同业(异地的其他银行),则通过银行的帐户行将汇款转汇至异地,并支付帐户行转汇的费用(后续如何处理?)。
以上是一个银行的国际结算业务中款业务的例子。简短的叙述和非正式的形式体现了XP强调的简单原则。故事帮助开发人员和用户理顺流程的关系。在上述例子中,我们看到开发双方对流程仍然存在一定的疑虑(即括号中有问号的部分),但是这并不影响到用户故事的创作,因为这个版本的用户故事还会变化多次。但从这个简单的例子上来看,我们发现故事的形式仍然存在着一些不足: 故事的形式更容易被人接受,但是也有不规则的缺点。任意描述需求虽然节约了培训的成本,但是却造成了不一致性。不同的人对故事有着不同的理解,对需求也就有了不同的理解。需求故事虽然看起来很简单,但是要讲好一个需求故事绝对不是一件容易的事情。需求规约过于形式化和正式化,导致了需求规约难以使用,但是完全不要形式也不是一个好的做法。在形式和可用性之间保持平衡,是讲好需求故事的关键。 需求故事虽然容易阅读,但是却很难写得好。如何控制需求的描写精度,如何分解需求,如何组织,如何确定边界。但是XP并不关心这个问题,只要能够起到沟通的效果,怎么做都行。这种态度是否正确我们暂不去评价。但在实践中,由于缺乏系统的指导,一个新手往往需要花费很长的时间才能够学会故事的写法。
对于XP来说,需求的开发只有先后次序之分。而先后次序的制定由客户来负责。但是在实践中,识别出先后次序并不仅仅是客户的责任,开发人员同样需要提供需求优先级和风险的建议。这里有几点需求优先级的建议:
需求中包含了主要的设计,或是包含了大量的业务实体和典型的业务规则。对于这样具有系统代表性的需求,应该赋予较高的优先级。
需求中存在重大的技术风险,例如需求中包括了OCR开发包,而开发团队原先并没有相关的经验。
需求中包含了重要的业务流程,代表了本软件的主要设计思路。
需求具有代表性,并且难以估算,急需对需求进行试验性的评估,以获得较为精确的速度值。
需求的时间紧迫。
采用用例技术
文章来源于领测软件测试网 https://www.ltesting.net/