【原创】需求分析之用例规模

需求分析，看似简单，拿到需求后却不知如何下手，如何编写用例 ？ 是否需要时序图？ 如何表示业务流程或者系统处理流程？ 太多的疑问在头上环绕 ，今天我们试着着手做需求分析的第一步--用例分析。

其实需求分析不能仅仅去了解客户对系统的要求，我们需要站在客户的角度，客户所处的环境整体把握需求内容。

客户的目的

 客户究竟想干什么。我们不要先考虑系统将来怎么做，我们首先要考虑客户要干什么？客户的目的是什么？有哪些必要需求，哪些紧急需求？ 按客户要求的重点分别讨论每一个场景。

呵呵，终于开始考虑编写用例了，不用急 ，用例到底应该编写到何种程度才能达到我们的目的，才能知道我们应该怎么做？ 我们可以从以下角度考虑问题。（用例的编写方法我们就不做讨论了，很多书上都有的）

1、老板的角度

 拿到原始需求后，我们怎么汇报才能让老板明白我们在做什么呢？ 其实这个汇报有一定难度，我们要充分了解客户的需求，并概括为IT、业务都听的懂的专用术语，简单，突出重点的完成汇报。这就是我们要做的第一个用例，比如接到CIF系统需求，我们首先就要明确，谁，要做什么，简单扼要的回答就是，客户管理部提出客户信息管理系统。over ！如果我们回答：客户管理部**处需要客户信息查询、检索、维护等功能，还需要有。。。。 老板估计没心思听这些 。至于客户管理部有哪些要求，我们需要提供哪些功能，我们客户一点点的完善。

 

2、业务的角度

  从业务角度编写用例就得充分了解需求的背景，比如：**国家监管部门要求**行业需要通过系统处理费用信息，不允许公司出纳接手任何现金。 这些背景我们也需要重点关注，避免出现由于客户理解偏差导致系统需求偏差，需要提醒的是，发现问题一定要与客户讨论、确认问题，万不可私自篡改需求内容 。

说了一大推废话，用例该怎么编写还没说呢，其实以上内容是让需求分析员充分了解客户在没有系统支持的情况下业务的处理流程，系统虽然会优化业务的处理流程，但是也是要给予原业务流程，可不能犯了唯心主义错误。

这时候我们就可以明细业务的用例场景，按业务流程划分，什么角色、什么时间、干什么时 ，为主场景分析 。遇到什么问题、应该如何处理 ，为替代场景 。但这里需要注意的是，一定要分清楚哪些是我们重点需要分析的，哪些是第三方可以提供的服务，切不可喧宾夺主。

用例的编写重点要放在通过语言描述，理清各种场景的业务流程、业务功能，设置清晰的前置条件，后置条件，UML图可作为协助解释---图形可以让人更容易理解你的想法，特别是在做问题、流程梳理过程中，图形会带来意想不到的效果 。以上内容出炉后，结果是让业务很清晰的告知你，业务需要的就是你所描述的，也让模块负责人清晰的告诉你，他明白需求的关键点了。

以上所指的uml图形，指用例图、职责流程图、业务序列图等，重点是业务描述

 

3、IT的角度

     从IT的角度，不光要理解业务的功能点，我们需要知道准备要怎么做，第二点我们只是对业务的流程和功能做了梳理，系统需要怎样解决我们还不清楚，所以我们要搞清楚这点 。

  对应业务的用例分析，我们要有系统功能用例描述、系统职责流程、类描述、类关系描述、类序列描述、数据结构。 以上内容只表达一个目的----系统如何处理？

 这里需要提醒的一点是，对于项目中的技术难点、技术风险都需要做好防范及预先处理准备。

 

以上只是常规的需求分析过程，对于面对不同的业务部门，不同性格的业务人员，我们需要灵活掌握，我们的目的就是做好分析，做好系统。

 

 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/7389553/viewspace-625020/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/7389553/viewspace-625020/