一.需求分析入手：
(一）明确项目背景：
本项目解决了客户的什么样的问题。
本项目涉及到的哪些人，哪些单位。
本项目的目标是什么。
本项目的范围是怎样的。
本项目的成功标准是怎样的。
背景、需要、需求规格
二、分析业务模型-类图
什么是类图
只有一个类的类图
类之间的关系，有直线，包含，继承，依赖。
直线关系有：一对一，一对多
直线关系
包含关系（弱包含）
继承关系
依赖关系
关联类
类图的基本用法
说明：A继承B，A依赖B
三、流程分析利器-活动图
基础语法：初始状态，结束状态，活动，判断，合并
怎样开始画每一个流程：
1.明确该流程要达到怎样的业务目的。
2.该流程有什么角色参与？哪些是主要角色？
3.排除异常情况，画出正常情况下的流程，这就是流程的主干，通常是线性的流程。线性的流程是指一条线从头走到尾的流程，中间没有分支。
4.明确流程主干中的活动涉及到的角色。
5.逐步增加分支流程，关键的分支流程都应该表达出来，但要注意并不需要画出所有异常情况，必要时通过注释或者文字说明。
6.适当控制活动的粒度。
7.先画出反映当前情况的流程，再画出优化后的流程。
8.对照前后的差异，整理出业务需要调整的地方，与客户确认。
活动图-审批工时
活动图（泳道图）-审批工时
以下补充知识（来源于网络），出处为http://yunzhu.iteye.com/blog/1914288：
活动图最适合用来描述企业的本质工作流。活动图所要捕捉的是整体业务流程的“大方向”。有关细节的相关描述应该是在讨论“用例”时才需要捕捉。
活动图的使用场景：
项目起始阶段，需求分析人员可以使用活动图，针对与项目相关的企业活动，与领域专家一起设计流程
项目上线阶段，可以用利用起始阶段的活动图作为集成测试的重要参考依据
项目维护阶段，企业管理人员可以通过活动图了解企业现行的流程以及未来可以改善的方向。
转载网络日志
四、描述系统行为-用例图
用例图是用来描述什么角色通过某系统能做什么事情。关注的是系统的外在表现、系统与人的交互，系统与其他系统的交互。
基本语法：
小人：执行者，可以是人，也可以是系统。
圆圈：用例（动宾结构）
大框框：系统边界
线条：关联，有三种，无箭头，指向执行者的，指向用例的。箭头的指向表明是数据的流向。
做一个系统的时候，首先应该考虑什么角色会用这个系统，不同的角色对系统有什么要求。
例如：考勤系统
一般用例图
角色继承
角色继承用例图
<<include>>说明包含的子用例
<<extend>>扩展，在。。。基础上做。。。事情
用例表模板
每一个用例都会涉及到一个或多个业务信息。
使用类图来描述所有业务及业务所涉及到的概念，以及概念所涉及到的关系，在每个用例表中只需要说明特别关注的内容。
在用例图的基础上，再重点说清楚每个用例：
1.用例所涉及到的业务概念，业务规则。
2.用例的目标，通过该用例用户能做什么事情，达到怎样的效果。
3.该用例的前置条件。
4.必须考虑的特殊情况。
设计系统时，首先要保证各个角色的基本功能。
当设计中出现n多个用例图时，比较好的组织是：
1. 画一个表示宏观需求的用例图，该用例图我会使用系统边界，每个用例圈用比较高度概括的语言。
2.将宏观用例图分解为多个具体的用例图。
3.用例比较多，层次比较复杂时，分层次展开用例图。
4.用户角色比较多的时候，先单独画出角色以及他们的关系，并用表格说明每个角色在本系统期望解决的问题，关注点等。
模板使用事例
模板使用事例
五、描述系统框架-部署图，构件图
功能性需求：描述系统的功能，即能做什么事情。
非功能性需求：对系统安全性，性能方面的要求。
需求阶段需要确定技术框架层次上的一些要求：
1.系统的技术选型：开发语言，数据库平台。
2.系统部署在怎样的服务器上，是原有的服务器上还是新采购的服务器，服务器需要怎样的软件，硬件配置。
3.系统需要与原有的哪些系统进行对接，将来要与哪些系统进行对接。
4.系统需要导入哪些数据，需要和哪些系统同步数据。
5.客户原有的IT平台需要怎样的改造，怎样才能让新系统运行的更好，同时保障客户原有系统的正常运行。
6.系统在安全性，性能方面需要达到怎样的要求。
网络拓扑图
部署图
部署图
部署图可以做的工作：
1.用部署图描述客户当前的IT环境架构
2.用部署图设计客户改造后的IT环境架构
需要说明的是，设计系统时，还应该考虑用例的状态。记住三点：
1.流程不合理，可以考虑增加、删减，修改状态来改善。
2.增加一个合适的新状态，可能会解决很多问题。
3.但新增状态的副作用就是增加流程的复杂度，可能会因此带来其他问题。
六、考勤系统的设计
（一）整理系统的详细需求，可以按照以下步骤完成：
1.制定本项目的战略方针
2.分析系统的需要：目标、涉众，待解决的问题、范围、项目成功标准等。
3.系统的业务概念，可以用类图描述。
4.画出关键流程的流程图。
5.分析有什么角色会使用系统，用用例图描绘系统功能，并挑几个进行用例表设计
6.部署图和构架图描述系统在架构上的要求
7.其他非功能性要求
8.以上，组织成需求文档
（二）需求分析全过程：
战略分析，需要分析，业务分析，需求细化
需求分析全过程的活动图
1.战略分析：通过招投标书，了解项目背景。需要搞清楚：为什么会有这样一个项目？客户为什么想要做这样一个项目？公司为什么会接这样一个项目？公司在这个项目上的战略是怎样的？是为了赚钱，还是积累客户关系，还是积累业务，积累技术？
2.需要分析：
目标：从招投标书，合同，方案书等，整理出项目的目标。
涉众及待解决问题：
涉众分类：①系统用户；②对该系统有商业决策权的人，如领导；③系统会影响到的第三方，可能是为其他系统提供接口，或者是需要采购某硬件
(就是梳理系统涉及的各部门的职能，各岗位的工作职责）
（注意：需求调研对象往往提出的是解决方案，或者是需求规格级别的。）
--如何找出关键涉众：
1.尽可能多的列出涉众
2.列出每种涉众待解决的问题
3.对于每一类的涉众，都应清除的说明系统是如何影响他的，他是如何影响本系统的
范围：从三个维度：①功能 ②与其他系统的关系 ③系统的地域使用范围
项目成功标准（略）
3.业务分析：
可以从两个角度来进行业务分析，结构建模和行为建模。
3.需求细化（需求规格）：设计有价值的需求方案。软件要做什么样的功能，要实现怎样的效果，是根据客户的需要，理解和优化客户的业务设计出来的。
通常一个流程中的多个步骤均可提炼为用例，多个用例组合起来能支撑某个流程。
（三）按照以上的需求分析方法，进行该系统的分析：
⑴战略分析
怎样做战略分析：
①项目背景：
甲方是怎样一个公司。
没有该系统之前，甲方是这样工作的。
当前的工作方式，出现了这样的问题。
出现了。。的导火索，以致于萌生了做这个系统的的想法，期望达到什么效果。
②该项目能帮甲方实现哪些核心价值。
生存需要，该项目关系到甲方生存问题。
核心发展需要，有利于甲方提高生产力和核心竞争力。
次要发展需要
锦上添花的需要
面子工程需要，有助企业或领导的政绩
③该项目对甲方的重要性如何。
④要成功完成项目，甲方有哪些有利或不利的条件。
⑤要成功完成项目，乙方有哪些有利或不利的条件。
⑵.需要分析
目标：
涉众：
涉众分析表
一般来说，涉众就是某一类角色。领导级别的通常会有：审批，（通过不通过），审核（审批是否合适）
范围：
项目成功标准：（需求，成本，进度，质量）
⑶.业务概念分析
分两步走：结构建模和行为建模，即业务概念和业务流程。
利用类图进行业务概念分析，先识别出类，再画出类的属性，描绘出类之间的关系，再进行抽象。
将事情抽象成类。通常管理一个事情，除了管理流程，还要管理一条或者多条数据。
考勤系统管理的事情有打卡、请假、外出。（管理记录就是管理事情）
分析业务时，要抓住与系统目标相关的业务概念。
包括业务术语、名词解释
考勤系统业务概念图
在分析业务时，脑袋中会产生不同的方案，请记录下来。
注意：客户日常工作中用到的各种纸质文件、表格、图表等。都是我们提炼业务概念的重要素材。日常工作的纸质表格，特别是报表类的表格，含有统计信息。要识别出哪些内容是统计出来的，哪些内容是原生的，要发现这些内容的真正来源。
但凡做管理系统，相关的制度文件是重要的需求来源。研究这些制度文件时，可能会发现一些不合理的地方，你需要和客户商量优化这些制度。
对于重要的类别，可以用一个类表示，如请假类别。
当我们分析某某申请单之类的东西时，该申请单在提出之后需要经历处理，该申请单往往隐含了“状态变化”的信息，需要识别出来。
处理突发状况的理有效方法，往往不是修改系统让系统更强的，而是思考一些管理办法，设计一些紧急状况应对预案。
⑷.业务流程分析
活动图
处理突发状况，往往不是修改系统让系统更强大，而是思考一些管理办法。
对于多变的业务，需要设计通过配置可以适应大多数情况的软件。
⑸.需求细化
①执行者分析
角色分析图
上图表明了继承关系，表明了儿子可以做父亲做的事情。孙子可以做儿子，父亲做的事情。
系统一般至少有一种管理员的角色，进行用户管理和权限管理。高层领导往往具备管理员的权限，中层领导具备管理员的部分权限。通常可以是一个角色对应多个用户。
绘制用例图的时候，每种角色只需要画出他独特的可执行的用例。
一般来说，角色是直接的上下级关系，上级角色可直接继承下级角色。
管理员功能：
1.系统用户管理：
a.查看，新增，删除，修改用户
b.设置公司组织架构(如：设置事业部及事业部以下的部门）
c.设置公司的职位（如总经理，副总经理，部门经理，HR经理等）
d.设置用户属于某个组织架构或职位
2.管理系统权限：
a.设置系统的功能点，一般会按照“树”的方式进行组织。
b.设置系统角色，并为每个角色分派功能点，表示该角色具备这些功能点的权限。
c.为每一个用户设置一个或者多个角色，这样该用户就具备一个或者多个权限
d.直接为每个用户分派功能点。
”单点登录“即一个系统登录了，其他系统不需要再登录。
②非功能性需求：
包括：软件技术架构方面的要求；安全性，易用性，性能，接口等方面的要求。
善用客户当前的IT资源，减少客户的负担，是我们规划软件技术架构时需要考虑的。
MIS系统，即信息管理系统。
七、如何编写需求规格说明书
需求文档框架
说明：需求文档一般是和客户确认的文档，
八、需求分析的团队作战
（一）如何在项目时间紧的情况下完成需求调研工作：
1.根据项目的合同，方案书的内容，整理出项目的目标、涉众及关注点。
2.制定具体的需求调研计划，并每天持续细化和更新。每天上午在客户处获取原始需求，下午项目组全体一起整理需求，并列出需要第二天确认的问题。
3.分头调研。可以将项目组（一个需求三个研发，一个测试）分成亮嗓调研小组，每个小组成员负责不同的涉众。每个小组通过需求调研问卷，UML图等方式获取需求，并且获取了大量的客户提供的原始纸张和电子版资料。
4.聚头分析。各个小组通过类图整理业务概念，通过活动图等整理业务流程，然后向其他小组通报。各个小组相互印证各种获取的需求，整合交叉部分内容，找出矛盾点。
5.项目组共同编写和维护一份需求文档，每天添加新内容，修改不合适的旧内容。
最后的需求规格说明书需要去客户方确认签字。
注意：软件架构设计需要把握高层次需求。
（二） 需求分析师的工作重点：1.全面准确获取和提炼需求。2.将需求传递给项目组成员，让大家准备无误的理解需求。（提不出问题是最大的问题）
关于开会：可以是在项目初期，项目特别紧张的时期，或者是感到问题特别多的时候，会议时间一般不超过15分钟，会议主要内容是让大家说出工作中存在的问题，需要得到什么支援。
（三）快速分享需求建议：
1.要求开发人员根据需求准备设计方案，开展技术研究工作等。
2.测试人员根据需求准备测试方案，测试数据和环境等。
3.要求实施人员根据需求准备实施方案，模拟实施环境等。
（四）让客户持续参与：
1.需求文档应该一边写一边和客户确认，最后来一个整体确认。
2.让客户全方位全程参与，从客户的高层领导，中层干部，基层员工中获取和整理需求，并将这些需求系统的整理在一起，再分别与之确认，持续确认。
不同级别不同需求列表
（五）关于需求的确认：
(1)按照以下的顺序来分批次确认
1.背景
2.需要
3.业务概念，如果业务概念复杂，应该分多次确认
4.业务流程，如果业务流程很多，应该逐一确认
5.执行者分析以及用力分析，用例可能会有几十甚至上百个，也应该分多次确认
6.非功能性需求
7.全部需求
(2)最佳实践建议：
1.与客户的需求分析确认过程是可持续的，各种确认方式有如下：
a.需求调研表，客户签字
b.会议记录，与会者签字
c.邮件确认
d.中间文件的确认
2.项目组要主动与客户确认，可用各种非正式确认方式。
a.某次口头沟通后，对达成一致的问题，整理出文档Email与客户确认
b.确认某业务概念或者流程后，将图打印出来与客户确认，让客户签字。
3.从谁那里获取需求，就向谁确认
4.向客户说明：项目组也需要签字，签字不代表不可以变化，而是表示到签字这刻为止，双方达成一致理解。
5.最后的确认是由客户某人作为代表，他的确认是在他人确认的基础上进行的，最后的确认应该是正式的确认。
总结：需求分析工作可分解为三方面的工作
1.全部准确的获取需求
2.将获取到的需求准确的分享给项目组其他成员，并根据他们的反馈进一步完善需求
3.和客户确认项目组对需求的理解
验证需求是否真正理解需求，可以自问几个问题
http://www.woshipm.com/pmd/979525.html
1.业务对象清楚了没有？系统的用户以及各功能模块的用户是谁是否清楚。
2.业务流程清楚了没有？各环节的处理人以及处理动作是否清楚。
3.业务场景清楚了没有？每个需求的业务场景是否弄清楚，所有需求的业务场景是否能连接在一起，在脑海中完整的形成一个故事。
4.业务事项数量清楚了没有？一共有多少个需求，一共有多少种角色，一共有多少张报表，一共有多少个前置条件……
5.跨部门的业务关系清楚了没有？这个部门与那个部门的关系以及产生的哪些业务往来是否清楚。
网友评论