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

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了高级需求分析师培训要点,如何正确编写需求用例的5个提示!相关的知识,希望对你有一定的参考价值。

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


使用例易于阅读


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

技术分享


  • 让问题短小、切题。长用例当然可以满足大的需求,但很少有人喜欢阅读。

  • 从头开始,用一条主线贯穿始终。顶部是一些对全局有重要意义的用例,再从这里分离出用户目标和最终的子功能用例。

  • 用动词短语来给用例命名,这些动词表达了用例所要达到的目的。

  • 从触发事件开始一直连续,直到目标实现或者被取消。

  • 用完整的主动语态句子来描述所要完成的子目标。

  • 确保每一步中参与者及其意图是可见的。

  • 突出失败条件,并使恢复动作是可读的,最好是不必为每个步骤编号,人们就能清楚地知道下一步该做什么。

  • 把可选行为放在扩展部分,而不是放在用例主事件流的条件语句中。

  • 只在非常必要的情况下才生成扩展用例。


仅使用一种句型


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

技术分享

  • 现在时态的句子。

  • 在主动语句中使用主动动词。

  • 描述参与者成功到达的目标,这些目标推动了整个过程的前进。

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


“包含”子用例

技术分享

很重要的一条经验就是,大部分子用例的加入使用包含关系。

混合使用饱含、扩展与泛化往往使读者产生混淆。也就是只在必要的时候使用扩展,当然在框架(Framework)设计的时候使用泛化有一定的好处,但只是在需要的时候使用。


两个结局

技术分享

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


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


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


项目相关人员需要保证

技术分享

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


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


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


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


本文出自 “中科院计算所培训” 博客,谢绝转载!

以上是关于高级需求分析师培训要点,如何正确编写需求用例的5个提示!的主要内容,如果未能解决你的问题,请参考以下文章

测试用例的编写原则

测试理论--如何编写一个好的测试用例

如何设计一个完整的测试用例

软件测试的分类&测试用例的设计&如何编写测试用例

测试用例的设计步骤

UML和模式应用4:初始阶段--需求制品之用例模型示例