分析及整理用例

分析及整理用例

这个步骤是更具体，也很重要的的一步，前面2个步骤确定了范围和流程，这一步针对流程上的某个节点来具体描述。以会员中心→内容管理这个模块为例，这个模块下面包含的用例有：

1. 1. 新增文章

2. 2. 修改文章

3. 3. 删除文章

4. 4. 查看文章列表

5. 5. 查看文章详情

现在，就可以按照上面这个列表，来一一的描述用例。一个完整的用例应该包含以下主要内容：

在描述需求时，有2种方式，一种是用例描述，另外一种是功能点描述。用例描述和功能点描述最大的区别在于，描述的角度不一样，用例是从人和系统的旁观者来描述，而功能点是从产品的角度来描述。通过用例描述需求，最好用文档，并且有统一的用例模板，而功能描述只需要在Axure里，以注释的方式描述即可。

其实，关于需求怎么描述，没有完全正确的方式，只有最合适的方式，具体因人而异。《启示录》一书作者就建议描述产品需求只需要高保真原型+注释就可以，完全不需要文档，以下是书中的一些观点：

产品说明（需求）文档的主体应该是高保真原型，由它体现产品的功能需求、信息架构、用户体验、交互设计、视觉设计。高保证原型最大的优势是可以用于测试。

与其花几个星期撰写冗长的Word文档，既没人读，也无法测试，还不如和设计师一起创建原型。

不管是用例描述还是功能描述，规则都是最重要的一部分，这里主要讲一下如何描述能完整无误的阐述需求并让阅读者看懂。规则的描述，主要是从3方面思考。

1. 1. 数据规则。主要指页面从数据库调取数据并展现的规则，比如查看文章列表这个用例，需要描述文章列表页面展示哪些字段、每个字段的类型及长度、列表的排序规则刷新频率等。

2. 2. 状态逻辑。文章不同状态之间切换的触发点是什么，比如状态为已发布的文章，要变为下架，可能的触发条件有：发布时间已过期、手动操作下架等。

3. 3. 交互规则。界面上存在交互的元素，一一列举并说明，比如链接、按钮、滑动、下拉的具体交互规则及异常处理。另外，整个场景由于网络问题、系统问题导致的异常也需要说明。