Skip to content

Use Case (用例)步骤编号的规则

这篇Post主要介绍Use Case的基本流程、扩展流程的步骤编号规则：

  • 基本流程 的步骤以1、2、3、4数字编号。
  • 扩展流程 则参照基本流程的编号，加上a、b、c、d字母编号。例如，执行第3条基本流程时可能发生的第1条扩展流程就编为3a，第2条扩展流程编为3b。
  • 扩展流程 的次步骤则编为3a1、3a2、3a3、3a4。
  • 如果扩展流程随时可能发生，而不依附特定的步骤时，则以星号取代基本流程的数字，编为*a、*b、*c、*d，其次步骤编为*a1、*a2、*a3、*a4。
  • 如果扩展流程在M到N步骤之间（包括M、N两个步骤）随时可能发生，则编为M-Na、M-Nb、M-Nc、M-Nd，其次步骤编为M-Na1、M-Na2、M-Na3、M-Na4。

Posted in 需求分析/产品设计.

Tagged with .

2 comments

By TzingChu – 2010年04月11日

2 Responses

Stay in touch with the conversation, subscribe to the RSS feed for comments on this post.

  1. Carrie says

    正不知道怎么写，多谢，留言顺便测下我刚弄的头像

    2010年08月25日, 00:21 回复

Continuing the Discussion

  1. 新入职互联网产品从业人员的三个月 » Go！欧欧！ linked to this post on 2010年10月14日

    [...] 在入职后两周后就接到了第一项任务：对网站现有在线沟通系统进行优化设计。当时脑子对PRD没有太多的概念，手边仅有的参考文档是面试时给主管的一份关于注册登录流程的策划，而这份文档是用Axure直接生成的。当时还是用了这个办法在交付日期前三天生成了一份进行了交付。虽然在对页面描述方面已经完全够用，但自己还是觉得这样的文档可阅读性实在太差。所以试着按iamsujie提供的产品需求模板和用例模板和TzingChu在博客里说的需求文档和UC的撰写和编号问题重新“借鉴”了一份文档出来，重新交付了一遍。其实PRD的核心就是把事情说清楚，为什么做，做些什么，怎么做且图片胜于文字，可以总结为“码字”。根据后续的一些零散项目来看（包括一些抽象规则的制订），我很多文档因为没有经验没有说到细节上，在最开始的两三个项目中还会让协作同事有不清晰的地方。文字解释看似容易但如何简洁明了精确的描述做好很难且需要时间和经验的累积。而在一些迅速执行的小项目的进行过程中PRD的存档意义还略略超过操作意义。 [...]



Some HTML is OK

or, reply to this post via trackback.

« »