面向对象需求分析方法实践

软件行业需求工作主要由需求分析师负责，需要完成对用户需求的调研、分析、整理，从而将用户需求转换为可供开发的功能需求。但随着互联网思维的普及，软件行业也越来越强调产品经理的作用，或许并不是互联网思维的关系，而是随着公司的发展，必须寻求由项目盈利模式向产品盈利模式转变，从而催生出产品经理的角色，以及对其的重视。
对于软件行业的产品经理来说，最核心的职责还是跟需求分析师一样，是从需求到产出原型的过程。在这个过程中主要使用的需求分析方法是面向对象需求分析方法。

1 面向对象需求分析方法
面向对象需求分析方法是通过统一建模语言 UML对用户需求进行调研和分析，并整理出功能需求的分析方法。

2 需求分析过程
前面已经讲到需求分析过程就是要将用户需求转换为可供开发的功能需求，为了达到这目的需要开展一系列需求活动。
2.1 收集并分析问题
在开展一项需求工作之前，都会从任务提出人哪里得到客户的想法（任务提出人不一定是客户，可能是销售同事、项目经理或维护经理）。但任务描述可能会比较粗糙，也较为含糊，还不足以指导后续的需求工作。
因此当你收到一项任务时，如果不了解情况，那么必须向任务提出人咨询清楚，客户为什么提出这项任务，需要达到什么目的，也就是尽量了解任务提出的背景。如果你不了解客户所提要求涉及的业务背景，或不了解前因后果，将对后续的梳理疑问和用户访谈造成很大的影响。
接下来就要有针对性的补充相关的知识背景，例如户政客户需要建设一项重户人员注销的功能，那就需要了解一下是不是最近有新的政策出来，或是不是最近公安部有检查，查出本省的重户人员较多而被通报了。这对后续功能实现可能起作用，也可能不起作用，但一定会对后续用户访谈的交流带来极大的好处。
在搞懂用户要求的过程中，你会产生很多疑问，这时需要将疑问分类整理好，为下一步用户访谈提供基础。梳理疑问需要以用户场景为指导，可沿着“谁要什么功能，达到什么目的”这一思路进行整理。
虽然在需求调研阶段不应该过多地思考功能实现，不过绝大部分情况都是在原有功能的基础上提出新的需求，全新的系统建设反而较少。这种情况下很难不基于现有功能思考新需求的实现。我认为无需太严格区分需求的每个阶段，在现有的功能基础上先构思解决方案是没有问题的，只要能基于用户场景，最终能满足用户需要即可。因此这时可以基于大概地功能实现的解决方案为出发来梳理细节问题，例如考虑到实现某个功能或操作时会有什么问题，就把问题记下来。但需要跟客户核实的问题应该还是以业务问题为主，如果只是些交互或操作层面上的问题，大可等到原型设计时，再进一步细化，或内部讨论解决。

2.2 用户访谈
用户访谈不是简单的将问题清单拿出来一个个问，问题清单只是辅助，主要是你自己要明白自己想要搞懂的是什么。可以将问题进行分类，整理每类问题的核心，然后基于核心向外发散。
最先要明确的是从大的范围来看，整个需求需要实现的功能是给谁用的，达到什么目的。再对细分的小需求进行确认，还是给谁用，达到什么目的。最终理出每个用户场景的角色和目的，方便后续需求分析及功能验证。
用户访谈时，很重要的一项技能是挖掘客户原话背后的真实需求，以及通过一定的提问技巧来帮助你完成访谈。下面是关于用户访谈时的一些提问技巧，以某项目客户提出报表需要导出为PDF为例。
1、用各种角色的身份进行提问
例：谁需要这个PDF文档？高层领导、档案管理员、部门经理？
2、进行反向提问（逆向提问）
例：不做这个功能会有什么影响？（体现该功能的重要性）
3、进行外延（发散、深入）提问
例：PDF文档有什么格式要求？
例：为什么需要做这个功能？
4、对原话的每一部分进行提问
例：什么报表需要导出为PDF？
根据用户访谈的结果，形成一个个的用户场景，最后将用户场景组装成一个完整的故事，这个故事就是整个业务过程。

2.3 结构建模
每个系统或功能都会涉及到不同角色、业务概念和物品等，这些事物之间会有很多关系，发生很多事情。特别是当我们刚接触新的业务时，最急迫需要解决的问题就是理清楚这些业务概念以及他们之间的关系。
类图能帮助我们识别出这些角色、业务概念、物品等，并理清他们的关系，这个过程就是机构建模。类图除了分析业务需求作用外，还起来指导原型设计的作用。一方面是在设计时能理清每个实体有哪些项目；另一方面是功能与功能之间的关系，一对一和一对多的设计方式是完全不一样的。
下面给出一个类图的例子，具体类图的知识和绘制不在此介绍，请查阅相关资料。

2.4 行为建模
行为建模是通过活动图描述业务活动流程的过程。在梳理用户场景时会得到具体的业务事件，也对业务事件的办理过程有了大概的了解。接下来需要通过活动图对业务事件的过程进行明确，尽量使用泳道图明确各个活动的使用角色，即使是单角色的流程也应该明确标出角色名称。
业务流程分为生产性流程、管理性流程和支持性流程。生产性流程是流程中最重要的部分，是企业/组织价值体现的核心；管理性流程是对生产性流程的管控，通常是有管理层发现的，对一些质量、效率进行监督的控制性流程；支持性流程是对生产性流程的一种补充，通常是由协作部门、本部门员工执行的工作。如果拿软件开发过程来比喻的话，需求分析、软件设计、软件编码、软件测试是生产性流程；项目管理、质量保证是管理性流程；而文档配置等属于支持性流程。通常生产性流程是最容易标识的，而管理性流程和支持性流程比较容易忽略，因此在需求分析时要特别注意。
活动图示例如下图所示：

2.5 功能建模
用例图的作用主要是将活动图中不在系统范围内的部分过滤掉，只保留可以通过系统实现的活动。对于每一个人机交互的活动，需要细化分析其事件流，也就是当前活动里人机交互的详细过程，这个过程也可以通过活动图绘制。
用例中的事件流是原型设计的重要输入来源，另一个输入来源是类图中的对象属性及对象间的关系。
用例图示例如下图所示：

在完成用例图后，需要进一步细化用例说明：

经过一系列建模分析后，基本的功能都已经明确，这时需要对功能进行有效地组合，聚合成有机的整体。一般会以业务和角色两个维度进行分析。

业务/角色	业务1	业务2
角色1	功能11	功能21
角色2	功能12	功能22

如果业务间相对独立，且业务内部连贯性较强，建议以业务维度划分功能模块。如果业务间关联性强，需要经常协同，建议以角色维度划分功能模块，这样对于使用者来说，在一个地方就可以处理所有需要办理的业务。一般来情况下，也建议以角色维度划分功能模块。
在对内明确功能模块后，还需要对外明确本系统/功能跟其他系统/功能的关系。这里考虑的是我输出什么给别人，以及我有什么需要别人提供的，也就是接口需求，建议使用构件图简单绘制。

2.6 需求验证
需求验证主要是对需求分析的成果与客户进行确认，确保业务分析无误和无遗漏。业务需求建议以PPT的形式进行整理，这样更便于交流讨论。
需求验证和需求分析可能会反复进行，不断调整，最终确认无误后，即可进行功能建模和原型设计。
具体来说，需求解决方案PPT分为用户需求、需求分析和功能实现3部分。用户需求是在梳理用户场景时整理出来的用户场景，也就是用户希望解决的问题；需求分析是需求分析行为建模和结构建模的相关产出；功能实现主要是列出功能模块以及各功能要实现的作用。当然对于系统级的需求来说可能还需要加入架构图和部署图等设计部分内容。
另外需要注意，在需求调研过程中，需求分析和需求验证尽量采用敏捷方式执行，尽快给客户进行确认。对于核心业务或影响较大的功能，最好先在内部把一道关，内部评审后再与客户确认。

2.7 原型设计及验证
软件行业较互联网行业产品设计而已，没有太多花俏的功能，更关注的是系统功能能否满足业务需要，交互上尽量简单好用即可。因为信息管理软件绝大部分都是CRUD，没有太多新颖的东西，因此在原型设计上首先要保障的是功能的可用，在此基础上尽量简化操作。
目前原型设计工具以Axure为主流，但原型工具归根结底还是工具，关键还是使用的人，因此根据个人习惯选取即可，不用太纠结。但是在开展原型设计之前更建议使用纸和笔先构思功能原型及交互，再通过工具实现，因为纸和笔是更能理清思路的永恒不变的最好工具。另外不建议对原型过分追求，毕竟原型的作用是更好的交流，只要达到这一目的即可，除非客户对原型美观有要求，否则还是以效率为优先。
原型验证是基于业务需求检验原型设计能否满足需要的过程，这一过程务必先在公司内部与开发经理及相关领导进行沟通确认，确保原型可实现，避免出现技术难点，影响进度和效果。
如果在功能确认之前已经开展了需求确认工作，那么功能确认将顺利成章，在讲解之前只要简单回顾需求即可。但如果之前没有进行需求确认，那么在这一阶段，需求确认还是不能少，为了让领导和客户明白功能要解决的问题，还是需要先对需求进行讲解，再对功能进行说明。但这样改动的风险将会很高，因此务必在原型设计之前需要对业务需求进行确认。

2.8 需求跟踪
需求跟踪包括从原型验证后到上线的一系列需求落地工作，主要包括编写需规、需求评审、开发答疑、需求符合性测试等。
1、需规编写及评审
需规将需求调研和分析的成果描述出来，是开发人员系统开发的依据，也是公司过程文档的一种记录，只需按公司要求编写即可。需要注意的是前面整个需求过程都是围绕着功能性需求开展的，对于非功能性需求并没有描述，需要另外讨论，这里不做细化。
需要注意的是在编写需规前建议先给开发人员和测试人员进行需求讲解，在一些功能细节上可能会做适当的调整，但大改不应该出现，因为之前关键人物都参与了需求确认的过程。在对细节达成一致后再开展需规编写工作，避免返工，并且后续需求评审将更高效。
2、开发答疑
在需求评审结束后，并不表示需求的工作就完成，可以等着开发后的检验。在这个过程中需要确保开发对需求理解到位，并持续关注开发疑问及时解答，一个好的办法是主动创建讨论组，关注讨论组上的情况。另外还需要参加开发的设计评审，通过设计评审确保需求得到落实。
3、需求符合性测试
当功能完成开发后，需要经过多轮的测试，在开发完成集成测试后，需求人员需要进行需求符合性测试，确保功能与需求一致。后续再提交系统测试和客户确认测试。

3 结束语
以上需求分析过程只是根据本人工作经验梳理的一套工作方法，但并不是说不能调整。多年工作经验让我明白，理论知识很重要，但怎么运用知识更重要。整个需求分析过程都是与人打交道的过程，每个人都是那么的独特，因此并没有一种方法放之四海而皆准，需要在实际工作中灵活运用所学知识和经验，也正是这样才更体现需求分析师的价值。

面向对象需求分析方法实践相关推荐

软件工程——面向对象需求分析方法——知识点总结
面向对象需求分析方法一.UML统一建模语言 1.主要特点 2.基本结构 3.UML的视图 4.9个基本图 5.视图和基本图的关系 6.UML类图的组成二.面向对象的需求分析建模 1.模型组成 2. ...
面向对象需求分析方法-知识点总结
面向对象需求分析方法 UML统一建模语言主要特点基本结构 UML视图基本图图和视图的关系 UML类图二.面向对象需求分析模型组成领域建模用例建模领域模型的建模用例模型的建模相关概 ...
Visio——软件工程实验壹——面向对象需求分析方法
所使用的工具软件及环境: 硬件环境:微机1台. 软件环境:操作系统:Windows:建模工具:Visio或Rose:数据库:MySQL(可选):开发工具包:JDK(可选):开发环境:MyEclipse ...
面向对象的需求分析方法
面向对象的需求分析方法面向对象的需求分析方法的核心是利用面向对象的概念和方法为软件需求建造模型.它包含面向对象风格的图形语言机制和用于指导需求分析的面向对象方法学. 面向对象的思想最初起源于 20世 ...
php面向对象之策略模式,php策略模式的学习--引自《深入php面向对象模式与实践》...
#策略(Strategy)模式 #定义抽象类 Lesson abstract class Lesson{ private $duration; private $coststrategy;#定义属性 ...
常见的需求分析方法（产品篇）
需求分析方法常见的需求分析方法有: 一.如何做结构化分析二.如何做系统建模三.需求加法四.需求减法总结常见的需求分析方法有: 1. 结构化分析 2. 系统建模 3. 需求加法 4. 需求减 ...
软件工程 chap-5 需求分析方法
需求分析方法 1 需求分析的原则对需求描述的要求 2 需求收集方法 3 传统需求分析建模方法功能建模(DFD) 行为建模(STD) Petri网数据字典判定表和判定树 4 面向对象的需求分析建 ...
深圳电子行业的mes系统的需求分析方法~先达智控
深圳电子行业mes系统的需求分析方法导读:如今,制造业的行业竞争越来越激烈,减少产品成本.提高产品质量,缩短开发周期,已成为当前企业生产与发展中的一个重点方向.而对电子行业而言,厂家着重考虑并解决了产 ...
面向对象开发方法，Coad方法、Booch方法和OMT方法及UML
目前,面向对象开发方法的研究已日趋成熟,国际上已有不少面向对象产品出现.面向对象开发方法有Coad方法.Booch方法和OMT方法等. (1).Booch方法 Booch最先描述了面向对象的软件开发方 ...
【系统分析师之路】面向对象开发方法，Coad方法、Booch方法和OMT方法及UML
[系统分析师之路]面向对象开发方法,Coad方法.Booch方法和OMT方法及UML 目前,面向对象开发方法的研究已日趋成熟,国际上已有不少面向对象产品出现.面向对象开发方法有Coad方法.Booch ...

面向对象需求分析方法实践

面向对象需求分析方法实践相关推荐

最新文章

热门文章