高级需求分析师培训要点，如何正确编写需求用例的5个提示！

用例文档的编写最困难的地方在于，这是一种单调的写作方式，又需要富有完美的表达能力，使读者愿意阅读。当用例书写完毕以后，需要分析和回顾已写完的用例，使思路不断地被完善和清晰起来。用例编写的注意力应该放在文字上而不是画图上，对于正确的写作风格，我们将给出一些有益的提示。

使用例易于阅读

要是需求文档短小简明，而且易于阅读。从文法上说：要在现在时态中使用主动词。不是使用被动语态，要使用主动语态。要明确句子的主语在哪里，只写真正是需求的东西，不要提及与需求无关的东西。下面的一些习惯可以使你达到这个目的。

• 让问题短小、切题。长用例当然可以满足大的需求，但很少有人喜欢阅读。
• 从头开始，用一条主线贯穿始终。顶部是一些对全局有重要意义的用例，再从这里分离出用户目标和最终的子功能用例。
• 用动词短语来给用例命名，这些动词表达了用例所要达到的目的。
• 从触发事件开始一直连续，直到目标实现或者被取消。
• 用完整的主动语态句子来描述所要完成的子目标。
• 确保每一步中参与者及其意图是可见的。
• 突出失败条件，并使恢复动作是可读的，最好是不必为每个步骤编号，人们就能清楚地知道下一步该做什么。
• 把可选行为放在扩展部分，而不是放在用例主事件流的条件语句中。
• 只在非常必要的情况下才生成扩展用例。

仅使用一种句型


在编写用例的每个执行步骤的时候，只采用一种句型。

• 现在时态的句子。
• 在主动语句中使用主动动词。
• 描述参与者成功到达的目标，这些目标推动了整个过程的前进。

在扩展的条件部分可以使用不同的语法形式，这样就不会使它和执行步骤产生混淆。


“包含”子用例

很重要的一条经验就是，大部分子用例的加入使用包含关系。
混合使用饱含、扩展与泛化往往使读者产生混淆。也就是只在必要的时候使用扩展，当然在框架（Framework）设计的时候使用泛化有一定的好处，但只是在需要的时候使用。


两个结局

每个用例都有两个可能的结局：成功和失败。

记住：当一个执行步骤调用一个子用例的时候，被调用的用例可能成功也可能失败。如果是在主事件流中调用，则把失败处理放在扩展中。如果调用来自扩展，则成功和失败的处理均放在同一个扩展中。

对于目标的成功与失败，编写者实际上有两个职责：一个是确定对每个被调用用例的失败都进行了处理；另一个是确定用力满足了每一个项目相关人员的利益，特别是目标失败的情况下。


项目相关人员需要保证

用例不仅仅记录了主参与者和系统之间公共的可见的交互操作。如果用例仅仅完成了这些操作，那么它不是一个可接受的行为需求，而仅仅是一个文档化了的用户界面。

系统是为了达到项目相关人员利益上的目的。其中一个相关人员便是主参与者，在一般的用例格式中，其它相关人员并没有被列出来。但是用例需要满足这些项目相关人员的利益，并提供满足这些利益的保证。

一般主事件流和它的扩展瞄准了项目相关人员的利益，所以从主事件流开始阅读，看看是不是考虑了所有相关人员的利益，你会发现遗漏是经常的事情。例如，没有想到失败，因而没有记录下恢复信息，检查一下全部的失败处理是否保护了所有相关人员的利益。

在编写主事件流之前先编写保证条件是一个好的策略，因为在第一遍编写的时候就会考虑必要的保证，而不是后来发现它们再返回来对文本进行修改。