软件需求最佳实践(3)

用例是一种纪录新系统或软件更换时的需求的技术。每个用例包含一个系统在作业时与用户或与其它系统之间交换信息的场景。一般用例避免使用术语，而尽量使用顾客、用户或他们的专家的语言。一般用例由软件开发者和顾客一起写成。用例之道：

• 不是系统完成的动作行为，而应该是有价值的业务活动的分解。
• 用例是需求分析的新视角-》业务视角。用例也可以是需求管理的基本单元。
• 用例价值的测试包括两方面，一是业务活动的原子性，一是Boss测试。
• 用例的粒度可能会取决于企业内业务的分工。
• 对于用例的CRUD原则，更加重点的标准是是否是一系列随机操作，是否由一个Actor完成。
• 用例需要避免功能分解，而应该是用户业务场景驱动。

在用例中常用的关系是扩展(Extend)，包含(Include)和泛化。对于扩展和包含区别如下：

• 扩展：在某种条件是会被执行，也可能不执行。所以它有可能是一种可以划到下个迭代的。
• 包含：包含的是子事件流，必然会调用到，而且是调用完后还会会到基用例。

对于获取用例的方法主要有两种，一种是自顶向下的流程派生法，跨职能流程图和泳道就是参与者，其中的业务活动就是用例；另外一种就是自底向上的合并法，比如可以从条目化的用户需求进行合并。在第一种方法中派生用例的时候需要注意：

• 去除掉非EndUser的泳道。
• 对泳道进行角色化的抽象。
• 判断活动与系统是否有关系。

对于用例分析重点是事件和业务流程，而对于数据分析则重点是在业务数据上面。用例分析代替不了数据分析。数据分析常用的就是业务实体分析，通过数据分析可以建立系统的领域模型。数据分析的目标就是理解业务领域中的业务术语和实体，包括语义关系，数量关系和主要内容。数据分析的要点就是要识别出具体的业务实体，以及这些业务实体间的关系。在FDD中的领域建模是基于数据和行为的综合分析，包括Together之父PeterCoad发明的菜色建模法。他将数据类分为了行为，参与角色，人事物，通用描述四个方面的内容。

在用例模板中有几个关键点，包括前置条件应该是系统必须能够检测和验证的。在用例描述中应该拒绝太多的实现细节；用例本身无法展示很多界面交互，因此需求建模还应该包括界面和交互建模的内容。而对于报表等需求往往并不太适合用例的表达方式，可以根据企业情况来确定具体的报表类需求的描述方法。

在用例模板中还有干系人利益的内容，在这里特别说明的是分析干系人利益可以帮助我们挖掘潜在的需求。虽然关系人不是Action事件的之间操作者，但是干系人的利益往往会影响到用例本身的需求。

另外关于这次培训后的具体感悟后续还会继续写，徐锋老师提供了一个书单我会整理到豆瓣上。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/15027599/viewspace-563289/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/15027599/viewspace-563289/