如何做需求用例分析-常见问题

4.1常见问题

Q1：术语理解不一致。

A1：术语理解不一致通常都是到了系统上线后才能发现，非常不容易发现，危害也是巨大的。通常我们可以要求对术语进行书面解释，或者请用户举例说明

Sample1：财务人员可以按照月份进行统计。

Ask1：财务人员是记账人员？还是会计人员？还是CFO？

Ask2：是自然月吗？还是财务月？

Sample2：连续三个月不违规，加10分。

Ask1：连续3个月，起始点包括当前月吗？

Ask2：如果不违规，是每个月都加10分吗？还是第4个月才加10分？

 

Q2：调用者不明。边界不清。

A2：用例需求分析是面向对象的技术来分析需求。Actor-Case要求站在用户的角度来观察系统。

Sample1：用户用手机短信发布内容->发布成功，回复短信通知，告知用户发布成功

Ask1：用户是谁？谁接收了内容？谁回复短信通知？如果不成功怎么办？

 

Q3：非功能性问题被忽略。（法律，安全，性能，扩展性，易用性）

 

Q4：多人发表意见，不知道以谁的意见为准

A4：以领导的意见为准。如果没有领导就以投资方意见为准，如果没有投资方就以使用者意见为准。如果你有不同的想法，可以通过你的需求接口人提出建议。

 

Q5：找不到完成功能的理由。

A5：我们的开发人员经常说的一句话是“产品组让我这么做的，我也不知道为什么？”。存在的就是合理的，产品组的设计一定会有其存在的必要性，他独立与我们是否能意识到他的存在。但通过理解存在的必要性，可以使我们更好的理解系统。

 

Q6：我们对产品组的设计有质疑权吗？

A6：有。但要通过合适的方法来沟通。不要对产品组的设计进行主观的评价例如：“变态，太诡异了，他什么都不懂，这个客户就是个白痴。。。”，要客观的了解需求提出的背景。开发人员进行分析时，不仅要提出问题，也要给出提出问题的思考视角，以及你所能给出的最佳解决方案，及方案的利弊，供产品组参考。

 

Q7：用例的抽象的粒度如何考虑？

A7：由于使用面向对象的特点封装，继承，多态的特性，来表现系统的复杂的交互关系进行需求分析。这种比较符合我们思维方式的分析过程给我们带来了方便，同时也给我们文档整理带来了困扰。我们推荐按照最小粒度来整理需求用例文档，因为我们的需求用例分析的是使用面向对象的技术，通过开发人员的视角来理解需求，所以抽象级别不能过高。力争将用户对系统的每一次有明确动机的交互进行描述。

Sample1：

a．用户发布Feed项（用户在一分钟里面不能发布超过15条的Feed项，可以通过短信，客户端，和WEB进行发布）

b．用户发布Feed项(短信)

Ask1：a和b是包含关系，也许他们还存在一个公共的基类。按照最小粒度来整理。

修改后：

用户通过WEB页发布Feed项

用户通过客户端发布Feed项

客户通过短信发布Feed项

 

Sample2：用户的Feed数量查阅后清零。

Ask1：清零描述太具体，实际上这个操作只是设置了一个已读标记，清零是具体的实现方式。另外用户调用操作也不突出（这句话的结构的关键词是：**数量**清零），没有主语

修改后：用户点击Feed数量，查阅Feed内容（关键词是：**查阅**内容），没有主语。

Ask2：用户点击Feed数量，过于具体，作为用例标题来说不合适。

 

Q8：我们系统中经常有用户设定的授权点，授权值。该如何书写这一部分的用例？

A8：该类操作通常会修改系统的状态。站在用例的角度通常我们将这类的操作也作为一个用例。但是与常规的用例的区别是他不能构成一个完整的交互过程，通常是对常规用例操作过程的一些限定。我们推荐的方式是将此类的授权点，授权值的限定集合归为一个用例进行体现（例如：授权管理），这个用例作为常规用例的前置条件（或者设计限定）来约束常规用例的行为。

 

Q9：下一个阶段需求发生了变更，文档更新怎么做？

A9：待讨论。

 

Q10：如果要做对已有功能的变更，需求用例分析该如何写？

A10：这是问题通常得Case byCase的进行分析。通常情况下，我们在“设计要求”中要将原有的设计进行描述。再写上新的期望要求实现要求内容。

 

Q11：是否使用这个模板，我就能够更好的分析需求，使我的效率提高N倍？

A12：由于研究理论的不成熟，个体差异的存在，以及项目自身的复杂性，目前还不存在这样的标准。在CMM5体系中过程改进也是个持续的过程，需要不断的调整完善。这个模板只是给出了在需求分析过程中需要关注的项目模板，帮助分析人员找到思考的方向。而高质量的需求分析很大程度上依赖于系统分析员的个人经验，这些经验需要长时间的积累，也可以说是思维的训练过程，而文档模板只是思想经验的文本形式的展现。

 

Q13：我如何能够验证我的需求分析足够充分了？

A13：非常好的问题。想直接证明是非常困难的，通常我们通过反正法来证明。可以回答几个问题：

a.是否全部的需求在用例分析文档中已经覆盖了？

b.是否用例分析文档中还会重复的内容？

c.是否有人经常说我这是“过度设计”，“你想的太细了”？