全面提高之需求分析2

1.分析一个系统采用面向对象的分析方法；（1）一定要弄清楚组织结构图；
（2）然后给对应的部门或者分支添加上对应的功能的详细描述，（个人建议分析的时候想全面一些尽可能的多分析多想到一些内容，至于怎样才可以多想到一些内容，其实就是看个人的项目经验或者说是分析遇到的案例有多少了，一般遇到多了自然就分析得够详细了，但是也可以通过阅读别人的分析案例来达到这样效果。说到这里就回想到几年前刚进入大学那会什么都不懂，以完成作业为目的，导致自己的需求调研从来都是一忽儿过，做得一点都不规范，一点都不够好。那会也没有现在的感觉，也没有认真学习需求分析。从来不去看案例，现在看来个中型项目，看到了个大型项目的需求，特么的就需求规格说明书都是95M，我特么遇得到哦。拿这个项目来作为进入公司的考核，让我去。。。）一般包含（部门编号，部门名称，直接上级，部门性质，部门级别，编制人数，下属部门，部门的职能，具体的实现条件，现在拥有哪些设备可供使用，是否异地啊，是否文件传输需要加密啊，验证之类的信息）。
（3）现在就是给每个部门的职工或者说是对应的岗位加上对应的信息了，至于信息有哪些，肯定首先有这个岗位本身的信息，性质，加上公司的一些要求和岗位的要求，最后就是岗位的目前提供的设备，提供的那些东西，这个也是积累，借用某个人的一句话“见多识广，孰能生巧”。
2.目标的流程设计
顶层流程设计：泳道模式，加十分详细的节点描述
底层流程设计：泳道模式，加十分详细的节点描述
3.表单资料整理：资料进行划分，对应的资料加上标识符，名称，长度，数据项编号。
4.后面的东西就是非业务中的，但是也是系统中重要的东西，这个东西就需要实际的去了解。至此需求调研完成了。接下来就是需求分析了。

5.需求的第一步，就是根据需求调研报告，进行用例规划。画出用例图。
（1）用例规划一般情况下从需求调研报告的业务流程图抽取，一般情况下运行节点作为用例的候选者。
（2）用例抽取时候需要注意用例必须由一个参与者进行触发而产生的活动，即每个用例必须至少一个参与者来启动。
6.用例图的画法。
（1）运行节点分析表：从替代性、复杂度、共享性、优先级、可行性来分析。
（2）用例拆分表：
（3）用例补充分析表
（4）系统用例汇总表
（5）用例参与者关系分析表
（6）用例确认表（这个表可能会删除一些用户提到的部分用例，按照优先级来进行的筛选，因为用户的投资规模，商业目标，企业的管理模式等最后就确认了该需求未必需要全部实现）
（7）特别期许用例规划（从非业务需求来进行的，有些非业务需求会有一定的影响。）
7编写数据字典（需求分析的数据字典与数据框架阶段的数据字典有不同的意义，需求分析的数据字典具有 全局指导性的广泛意义，规范了整个开发过程中的各类数据的解释和组织，包含了对数据架构师和所有开发人员的指导，数据库字典是数据结构师为指导数据库实现而设计的，但是数据库字典在不同的数据库中实现是不一样的，必须遵循相应数据库的设计原则和规范。）（实际上很少有公司将数据字典当作需求分析的重要内容来书写的，一般都不将数据字典写在需求分析阶段，但是为什么这个老师就将数据字典写在了这里呢。大部分没有使用数据字典都是使用的领域类图来进行代替的，）（编写数据字典一定不能脱离业务调研报告，不能随意瞎想，自己进行定义）（设计原则：这里就不写了）
（1） 数据字典原始表单整理：：其实该表单只要具备了应有的基本信息之后，可以添加一些其他东西。

（2） 数据集确认表
（3） 数据集数据项模板
（4） 数据项字典模板
（5） 整理后创建数据字典的数据库，便于团队成员查询。
8用例描述：用例描述其实需要让人架构师和程序员能够懂得这个讲述的是什么内容，图形其实是文字描写的一种表达方式，可以加上文字描写用户/管理员交互过程等。对于相对复杂的用例而言，可以使用用例运行流程图来补充描述。前置条件（执行该用例需要先满足的条件），后置条件（执行该用例结束后必须成立的条件，若达不到效果，则这个用例就是执行有误），事件流程（用例通过前置条件后就会进入事件流程中来，执行时间流程。当然了用例不一定需要有潜质太哦键和后置条件，但是必须需要有事件流程）。
（1）基本事件流描述：在分析事件流的时候 除了要有正常的事件流，还必须添加自己已经想到的出现异常的事件流，主要是系统软件运行出现的异常事件流（系统异常），还有就是开发系统时候对应用例填写错误从而导致的异常（业务异常），
在这里直接引用书上所画的图，
因本人时间关系后面9.10.11就先不写了。留待后面时间充足时后看。
9用例及参与者关系分析
10领域类图
11非功能需求分析