需求分析的步骤有哪些
2024-05-13 18:06
1. 需求分析的步骤有哪些
一、需求识别 需求人员在此步骤应该分析需求类别、需求复杂度和需求价值用来确定需求实施的优先级。 1.需求类别确认： 需求类别包含流程类需求、统计分析类需求、接口类需求，一个需求可能为某一类型需求，也可能包含多类需求。 确认需求类别后应对每类需求的数量进行初步分析（比如流程类需求包含几个流程、统计分析类需求包含几个报表、接口类需求包含几个接口）。 2.需求复杂度分析： 一般需求受理工作量在1-5人天的需求复杂度低，工作量在5-15人天的需求复杂度中，工作量在15人天以上需求复杂度高。（工作量表示需求受理全过程需求人员需要付出的工作量）。 3.价值分析： 需求人员收到需求后应根据收集需求内容初步分析需求痛点/目标、需求复杂度、业务重要程度确定需求价值，需求价值分析 二、业务流程/统计查询/接口分析 针对流程类需求必须进行业务流程分析，统计查询和接口类需求可不进行详细的流程分析。 1.业务流程分为部门级、组织级和岗位级 部门级流程关注脉络需要分析涉及哪些具体岗位、执行活动、每个活动之间的关联关系，它是需求分析的主线条，也是流程分析的主要产物。 组织级流程关注宏观一般不会直接绘制，是对部门级流程的概括和抽象。 岗位级流程关注每个业务活动的执行步骤属需求细节范畴，在流程分析阶段不要过度进入细节。 2.需求识别阶段确认的流程均为部门级流程 需求人员在进行流程分析应遵循如下方法： （1）业务流程确认： 一个流程为一个业务事件，一般是外部角色发起或系统内部主动发起（比如时间事件或状态事件），发起后会触发一系列业务活动。 （2）角色及业务活动确认： 流程图中的每个泳道都必须对应到角色，每个角色对应多个业务活动。需求人员在确认业务活动时一定要保证活动的粒度，一个业务活动一定是由一个角色完成且每个业务活动都是有价值的活动。 比如项目输入项目名称是一个执行步骤，这个动作没有价值，项目经理查询项目信息就是一个业务活动。 在需求描述时针对线下活动或新增活动应该应标识区分。 （3）业务活动间关系及数据确认： 确定所有业务活动的前后置关系，并明确流程间的传递的数据实体。 （4）流程整体瓶颈分析： 一般若某个角色业务活动工作量较大，或流程涉及高级领导，一般都会造成瓶颈，这种情况需求人员应想办法分散工作量提出流程优化建议。 3.针对统计查询类需求及接口类需求，按照上述业务活动确定原则分析、确定角色，并明确每个角色所执行的业务活动即可。 三、数据实体分析 针对流程类需求需要分析各业务活动传递的数据实体，统计分析类需求需要分析统计查询条件和查询展现两类数据实体、接口类需求需要分析接口传递数据实体，具体分析包含如下内容： 1.明确数据实体： 确认需要分析的所有数据实体，明确哪些为系统原有实体、哪些为新增实体、哪些为改造实体。 2.明确所有数据实体间关系： 实体间关系包含（1对1、1对多、多对多），另外需要分析数据实体变更是否需要保留版本，实体删除（逻辑删除、物理删除）是否影响其它数据实体。 3.明确数据实体字段： 针对新增数据或改造数据实体需要明确新增字段的名称、字段类型、是否必填、字段取值方式（人工输入、系统自动继承自其它数据实体、系统自动计算需要明确计算公式）。 4.数据权限分析： 需要分析不同角色在数据权限方面的差异，若涉及纵向多级用户，要说明对于集团/省/地市用户的数据隔离。 四、角色及使用场景分析 一般来说每个业务活动是对用户使用场景的抽象，每个业务活动可能包含多个场景，分析使用场景时应按照业务活动为主线逐个进行分析，每个业务活动分析时应包含如下内容： 1.明确活动执行角色。 2.明确活动执行的前置条件和后置条件。 3.明确不同场景： 一个业务活动可能包含正常的使用场景、备选使用场景和异常使用场景； 4.明确每个场景的执行步骤： 描述执行步骤时应使用简单的语法，主语明确语义易于理解，每个步骤不应该在任何一方（执行角色、系统）停留两部以上，重点描述如何交互。 5.业务规则和约束： 明确在每个业务活动下应遵循的业务规则和约束，这里一般是与业务流程相关的行为规则（比如项目周期时长超过90天必须提交二级领导审批），或与数据实体相关的数据规则（需求交接单拒收时候必须填写拒收原因，且拒收原因不能超过500字）。 五、系统功能分析
2. 需求分析的十个步骤
1、概念明确----2、需求分析目的------3、如何识别需求---4、判断需求真伪----5、分析[ 用户故事评估框架、马斯洛框架、营销框架定位]---6、评判价值----7、砍需求能力---8、分类----9、排优先级----10、提升需求分析能力
一、什么是产品需求?
1、想要 vs 需要 vs 需求
“想要”(Want)是用户外在表达出来的，而“诉求”(Need)是用户内在的心理预期。产品需求满足的是用户的内在诉求，这是根本。
想要(Want)是外在的、具体的、有指向性的解决方案。
需要(Need)，或者如我们前面说到的“诉求”，是内在的、原始的最终动机。
需求(Demand)是满足内在需要的同时，在可控成本内实现外在想要的解决方案。
二、需求分析的目的
需求分析，本质是动机的分析，目的在于预测用户未来的行为。需求分析阶段的产出 物，需要回答用户要什么、为什么要，还要回答以后什么情况下还可能要类似的东西、这种情
况有什么特点、如何人为的制造这种情况、
需求重要，是因为它是用户行为的动机;需求是分层的，说出来的一个样，实际是另一个样。
用户需求分析，是为了通过分析动机，准确预测用户的行为。不同的需求，代表 了不同的动机，注定会产生不同的行为，应当看做不同类型的用户。
在需求分析中考虑竞争性，是为了比竞争对手预测得更准确，这是我们在后面要说的。
【知识点】需求= 购买欲望 + 购买力 = 需要 + 目标产品 + 购买力
三、如何识别需求？
分析完需求，那我们如何去发掘新需求呢?这里就涉及如何识别需求。 识别需求可以从三个方面去考虑，分别是视角、效率、体验。
1、视角
先说视角。作为产品经理，我们要具备多样化的视角来审视需求和产品，分为用户视角和产品视角。
比如:开头我们提到的关于微信朋友圈可见范围的例子，相比于之前三天可见和半年可见，增加了一个月可见范围。
在这个设计里，用户往往会站在自我的角度说，“不想让别人看我的朋友圈”，这是用户视角。而产品视角是考虑群体和整体，是“让用户更小压力去发朋友”。这种视角差异，最终的方案也会有差别。
用户视角满足的是“想要”(Want)，产品视角实现的是“需要”(Need)。
2. 效率
另一个识别需求的维度就是效率。在最优效率的前提下，满足尽可能多的用户需求。
我们还是用一个例子来说明，用过微信公众号赞赏功能的人都知道，如果自己赞赏过作者，那自己的头 像就会始终排在最前面。
如果自己没有赞赏过，那每次进入文章，且赞赏人数超过 24 人后，底部的赞赏头像都不是固定顺序展示的。
3. 体验
最后一个识别需求的维度就是体验，关于体验，做产品的同学就比较熟悉了。体现在信息架构设计、流程设计、交互设计还有文案设计等方面。
体验也是一个很虚的指标，很难量化，每个人的认知和感受都会因为习惯、文化、个人倾向产生差别。任何细节的体验设计，都会给用户传递一个认知，而我们要明白的是，独立个体的认知差异是很大的。
比如:对于“快车”这个概念，刚出来的时候，大众是无认知的，只能找到对标，比如出租车和专车，而快车是介乎于两者之间的一种服务。
如何更好的设计快车体验呢，其实用价格比专车低、比出租车干净舒服、且车多三个认知来传递给用户，就能让用户快速接受并理解。
四、接收需求判断真伪
真需求要满足三个条件
1. 该用户属于目标用户
2. 需求必须符合产品定位
3. 需求能够实现
五、如何分析需求
1、采用用户故事的方式进行分析
需求是结合用户表达的外在欲望、内在的核心诉求以及可用成本的综合评估。
基于这个定论，我整理了一句话，可以作为需求分析的一个评估框架—— 我们为谁用什么方法解决了一个什么问题?
在这句话里，“谁”指的就是我们的目标用户，我们需要明确用户画像;“问题”对应的是前文提到的需求，而“方法”就是我们基于需求提供的产品方案。
我们为谁用什么方法解决了一个什么问题?其实就是在反问我们自己，作为产品经理，你在为哪类人服务，他们的核心诉求是什么，你设计了一个什么产品方案去满足他们的需求。
用户分析，我们可以从用户身份和用户特征两个角度出发，用户是什么人群，年龄、性别、地区等都是构建用户画像的基本素材。
目标用户有什么样的特征，比如职业特征、文化特征等，这些都能帮助我们进一步理解用户。
其次是需求场景，说白了，就是用户是在什么环境和状态下来使用我们的产品。
“场”是时间加空间，“景”是情景和互动。当用户停留在这个空间的时间里，情景互动触发并裹挟用户的意见就是场景。
可以用比较通用的马斯洛需求理论对用户需求进行分析，评估满足的是哪个层级的
需求，或者是通过用户体验五层模型来划分需求层级。
用户价值是从体验和效率两方面来衡量的，一个需求能改善现有体验，那就能提升用户价值，能提高使用效率，也能提升用户价值。
如何衡量体验是否有提升呢，可以用新体验减去旧体验的方式，例如针对某个体验改进，简单粗暴的做法就是新旧体验相减得到的用户投诉率，如果为正，说明用户价值有提升。
而效率则可以通过用户完成某一任务的平均时长来衡量，例如在电商产品中，用新旧总平均成交转化时长的差值来衡量提单效率是否有提升。
商业价值就比较直观了，关乎于成本和利润，互联网传统的商业化方式包括了广告、游戏、会员等。目前也有很多做增值服务和第三方能力输出服务的，这都是商业化手段，同时也会对应到一些产品需求上。
2、马斯洛框架和营销层方式结合起来
做需求调研和分析，最尴尬的结局就是:用户以为自己说清楚了，我们以为自己听清楚了，结果两边就这样整差了。
在产品上线之前，甚至在进入产品设计阶段之前，我又怎么能知道我做的需求分析已经足够深了呢?
行业给出的一般方法是MVP(MinimumViable Product)，利用MVP收集线上实际数据。 但MVP只能告诉你，你是错了还是对了，依然解决不了“为什么”以及“应该怎样”的问 题。况且MVP还有覆盖度的问题，怎么设计才能让MVP覆盖所有“应该”被测试的场景呢?
到了1959年以后，马斯洛认为“人本”的导向会产生“自由主义”倾向，从而产生自私、不负责任、不顾他人、自我放纵等自我中心倾向。于是，马斯洛于1969年发表了论文《Z理论 ——两种不同类型的自我实现者》，并依照“超人本心理学”(Trans-HumanisticPsychology)将需求层次理论拆解为三个次理论:X理论、Y理论和Z理论。
依次为:
Z理论
最高需求(超越性灵性需求)
Y理论
自我实现需求
尊重需求
社会需求
X理论
安全需求 生理需求
营销学中的需求分层
在科特勒老师的《营销管理》(15th Global Edition)中，给出了这样一个案例:
表明了的需求:顾客需要一个便宜的汽车;
真正的需求:顾客需要一个养车比较便宜的汽车，而不是价格便宜的汽车;
未表明的需求:顾客希望零售商提供较好的服务;
愉快的需要:顾客希望零售商给装配车载GPS系统;
秘密的需要:顾客希望朋友们将TA看作是懂行的消费者;
有了前面两套框架，我们就守住了需求的来源和表达过程。但是两套框架的用法正好截然相 反:马老师的框架是“5:1”——从五个层次里选一个当前所在的层次;但营销学的需求理论 是“1:5”——拿到一个需求从五个方面来分解。
我们用卖苹果的例子还原一下需求分析的过程:
用户说:“我要买一个苹果”。此时千万不要直接就套上马老师的需求层次了，因为这根本就不是一个“根本性”的需要，而是一个结合了具体产品——苹果的具体需要。
这时应当用的是营销中的五个分类:
表明了的需要:我要一个苹果;
真正的需要:可能是解决饿肚子，可能是解决馋，更有甚者是解决低血糖的症状等
等;
未表明的需要:如果为了填饱肚子，就需要个大的;如果为了解馋，就需要味道好
的;如果为了解决低血糖，就需要一个更甜的;
愉快的需要:吃饱了、解馋了、头不晕了(低血糖的症状之一)当然开心，如果买一
送一、免费加工成苹果汁、还能额外加点糖，有可能就更好了;
秘密的需要:可能是工作繁忙，接下来还要赶往别处，实在没时间吃别的了;又或者
是最近吃胖了，需要用水果当饭吃;
六、评判需求价值
1. 广度:受众人群以及受众面
2. 强度:用户对于需求的迫切程度
3. 频率:间隔时间及可持续性
七、砍需求能力
1. 对需求进行价值评估和量化
2. 关联性较强的需求进行整合
3. 排列优先级
所有对产品的价值判断，都基于对行业、市场的探知程度;对人性的认识和了解程度(发现没有，把握人性始终贯穿产品的各个层面)
八、对需求分类
九、对需求排优先级
能用是基本要求，能用的标准是产品功能完整、没有异常、逻辑闭环，如果功能或流程缺失，或者产品有bug，那是达不到能用的标准的。
易用对应一些锦上添花的需求，在满足能用的前提下，做流程优化和交互优化，使产品达到用户体验良好的状态。
爱用是让用户形成习惯和依赖，例如我们在朋友圈里发布了很多内容，随着内容增多，我们的离开成本就越高，并且每次都能收到朋友圈的正向反馈，这个闭环就能形 成习惯和依赖。
传播能力使产品具备价值可扩散的属性，满足用户需求并获得市场认可后，需要将价值外延以吸引更多的用户，这是建立在基础功能完备、体验优良，并且满足用户价值 的前提下。
十、如何提升需求分析能力？
1. 倾听
首先是倾听，面对需求方，不论是用户还是运营还是工程师，首先做到先听，这是放下自我做产品的前提。
什么是事实? 客观的原因和现象是事实，基于现象去分析背后的原因，基于原因再形成观点。
2. 观察
其次是观察，观察是最好的洞察用户需求的方式，到用户身边去，看他们做了什么，行动往往反映了用户的真实诉求。
3. 同理心
如何切身感受、设身处地呢?最简单的方式就是到用户的环境中去，感受用户不如变成用户。
只有切身感受，尤其是感受到了痛，你才真的理解了用户。
附记：
需求沟通:需求中的需求?
至于怎么讲，我们还可以套用前面的框架——老板跟你说:“你做个需求分析”。
那么:
表明了的需要:老板需要你做一个需求分析;
真正的需要:老板可能在策划下一款新产品，或者要把一个竞争对手打掉，或者是老板的老板要求下来的，或者......
未表明的需要:时间呢?质量呢?形式呢?汇报对象呢?怎么，你不知道?快问啊!
愉快的需要:老板可能希望你从不同的视角(员工视角、跨行业视角、年轻视角等 等)给出不一样的答案;可能希望你直接做成他能用来汇报的ppt格式，可能......
秘密的需要:老板背负着公司巨大的业绩压力需要寻找突破口、老板“可能”也有自己升职加薪的小算盘......
3. 需求分析四步骤
软件项目流程包括 需求分析，设计，开发，测试，运营，需求分析结果是否准确，对整个整个项目至关重要。
这张图是什么意思呢？也就是说，如果在需求阶段只需花费1个单位时间就能改正的错误，拖到设计阶段来改正就需要5倍的时间，到了编码阶段将是10倍，测试阶段可能达到20~50倍，而到了运行与维护阶段或许会达到200倍之多。
需求工程包括需求开发和需求管理两大范畴。需求开发是收集、分析、整理、编写、验证需求的全过程，重点在于开发出高质量的需求规格说明。需求管理则是对需求的实现、变化进行追踪的全过程，重点在于确保开发的软件满足这些需求。
图3-3
在图3-3中已经指出了需求开发包括需求获取、需求分析、编写规约和需求验证4个具体的活动，但这些活动是顺序进行的吗？现代软件工程的思想更偏向于多次循环的形式，每次循环的过程如图3-4所示。
图3-4
需求分析四步骤解析
1.需求获取
一般通过，用户访谈及用户调研来获取需求！
预先对访谈问题、时间、访谈人员进行计划，做好充分准备！
2. 需求分析
首先需求站在业务的视角进行分析，需求分析也是业务分析，需求分析的任务是对问题域进行研究，因此从业务线索入手是最好的。
明确需求分析目的，通过建模 进行分析、交流，解决问题。
3. 编写规格说明书
需求规格说明书 建议应做到 共享，更新
共享：软件需求规格说明书就是用来完成信息传递和沟通的，因此必须实现共享是显而易见的。
更新：软件需求规格说明书在整个开发过程中是不断演化的，如果没有有效的更新机制，很快就会成为一潭死水，从而造成与开发活动的脱节，所以做到及时有效的更新
4.需求验证
需求验证，通过开需求评审会，项目组成员讨论的方式对需求加以验证。
4. 需求分析有哪两种主要分析方法?
从系统分析出发，可将需求分析方法大致分为功能分解方法、结构化分析方法、信息建模法和面向对象的分析方法。 (1)功能分解方法。 将新系统作为多功能模块的组合。各功能义可分解为若干子功能及接口，子功能再继续分解。便可得到系统的雏形，即功能分解——功能、子功能、功能接口。 (2)结构化分析方法。 结构化分析方法是一种从问题空间到某种表示的映射方法，是结构化方法中重要且被普遍接受的表示系统，由数据流图和数据词典构成并表示。此分析法又称为数据流法。其基本策略是跟踪数据流，即研究问题域中数据流动方式及在各个环节上所进行的处理，从而发现数据流和加工。结构化分析可定义为数据流、数据处理或加工、数据存储、端点、处理说明和数据字典。 (3)信息建模方法。 它从数据角度对现实世界建立模型。大型软件较复杂；很难直接对其分析和设计，常借助模型。模型是开发中常用工具，系统包括数据处理、事务管理和决策支持。实质上，也可看成由一系列有序模型构成，其有序模型通常为功能模型、信息模型、数据模型、控制模型和决策模型。有序是指这些模型是分别在系统的不同开发阶段及开发层次一同建立的。建立系统常用的基本工具是E—R图。经过改进后称为信息建模法，后来又发展为语义数据建模方法，并引入了许多面向对象的特点。 信息建模可定义为实体或对象、属性、关系、父类型/子类型和关联对象。此方法的核心概念是实体和关系，基本工具是E-R图，其基本要素由实体、属性和联系构成。该方法的基本策略是从现实中找出实体，然后再用属性进行描述。
5. 需求分析方法有哪些?
问题一：需求分析有哪些方法 三种需求分析的方法：结构化分析方法、面向对象的分析方法、面向问题域的分析方法。 结构化的分析方法是传统的分析法，它的好处是在需求阶段可以不需要精确地定义系统，只需要根据业务框架确定系统的功能范围，以及每个功能的处理逻辑和业务规则，功能需求规格书等。因为不需要精确描述，因此描述系统的方式比较灵活多样，可以采用图表、示例图、文字等等方式来描述系统。在系统开发以前，一般还可以采用更为直观的原型系统方式和最终用户进行交流和确认，因此对业务需求的要求会低一些，业务需求阶段的周期相对容易控制；通过业务全景图，最终用户也能了解系统的功能；通过功能活动图和业务规则的描述，也可以相对精确地描述业务系统；因为没有严格的标记语言，可以采用适当的篇幅描述适当的系统。当然，这种方法的缺点也是明显的，分析人员和业务人员之间可能缺乏共同语言，机器不能识别业务需求书，在设计阶段还需要继续和用户确认一部分功能。 面向对象的分析方法的最大好处是在需求阶段，就能够非常精确地描述一个系统，采用程序语言的方式和最终用户交流（最终用户必须要熟悉这种语言），能够在项目一开始就发现很多问题，避免在开发的过程中出现需求的反复，而且在系统设计和开发阶段不需要最终用户参与。在实施上，一般可以采用场景、业务功能等方式来描述，比较适合于业务流程环节多的系统，或者软件产品的开发。但是，我们也要看到，在现实中，绝大多数的应用系统都很难在需求阶段就可以被精确地抽象化定义，所以这种方法的缺点和困难也是显而易见的：首先，用户要非常清楚地知道最终的业务系统应该是什么样，或者采用一种抽象的方式能够确定最终的应用系统；其次，因为最终用户不需要参与设计和开发阶段的工作，所以双方确定业务需求的过程也会比较长；同时，因为是精确描述，因此描述系统的语言是非常逻辑化的，一般通过某种方式可以使机器识别业务需求，采用这种方式写的业务需求是非常格式化的，一方面描述一个系统需要的信息非常多，可能使需求说明的篇幅非常长，不便于理解和阅读；另外由于通过抽象的方式来推演最终系统的运行方式，对业务人骸的要求非常高。 问题二：项目需求分析的分析方法 需求分析的方法有很多.这里只强调原型化方法,其它的方法如:结构化方法,动态分析法等(个人认为,对初学者不必深究这些方法,实际上我也从来没用过这些方法)在此不讨论.原型化方法是十分重要的(是软考等常考的知识点).原型就是软件的一个早期可运行的版本,它实现了目标系统的某些或全部功能.原型化方法就是尽可能快地建造一个粗糙的系统,这系统实现了目标系统的某些或全部功能,但是这个系统可能在可靠性,界面的友好性或其他方面上存在缺陷.建造这样一个系统的目的是为了考察某一方面的可行性,如算法的可行性,技术的可行性,或考察是否满足用户的需求等.如,为了考察是否满足用户的要求,可以用某些软件工具快速的建造一个原型系统,这个系统只是一个界面,然后听取用户的意见,改进这个原型.以后的目标系统就在原型系统的基础上开发.原型主要有三种类型(软考考过):探索型,实验型,进化型.探索型:目的是要弄清楚对目标系统的要求,确定所希望的特性,并探讨多种方案的可行性.实验型:用于大规模开发和实现前,考核方案是否合适,规格说明是否可靠.进化型:目的不在于改进规格说明,而是将系统建造得易于变化,在改进原型的过程中,逐步将原型进化成最终系统。在使用原型化方法是有两种不同的策略:废弃策略,追加策略.废弃策略:先建造一个功能简单而且质量要求不高的模型系统，针对这个系统反复进行修改,形成比较好的思想,据此设计出较完整,准确,一致,可靠的最终系统.系统构造完成后,原来的模型系统就被废弃不用.探索型和实验型属于这种策略。追加策略:先构造一个功能简单而且质量要求不高的模型系统，作为最终系统的核心,然后通过不断地扩充修改,逐步追加新要求，发展成为最终系统。进化型属于这种策略. 问题三：如何做好需求分析，需求调研 转载以下资料供参考 从广义上理解：需求分析包括需求的获取、分析、规格说明、变更、验证、管理的一系列需求工程。 狭义上理解需求分析指需求的分析、定义过程。 原因 需求分析就是分析软件用户的需求是什么。如果投入大量的人力，物力、财力、时间，开发出的软件却没人要，那所有的投入都是徒劳。如果费了很大的精力，开发一个软件，最后却不满足用户的要求，从而要重新开发过，这种返工是让人痛心疾首的(相信大家都有体会)。比如：用户需要一个for linux的软件，而你在软件开发前期忽略了软件的运行环境，忘了向用户询问这个问题，而想当然的认为是开发for windows的软件。当你千辛万苦地开发完成向用户提交时才发现出了问题，那时候你是欲哭无泪了，恨不得找块豆腐一头撞死。 需求分析之所以重要，就因为他具有决策性、方向性、策略性的作用，他在软件开发的过程中具有举足轻重的地位，大家一定要对需求分析具有足够的重视。在一个大型软件系统的开发中，他的作用要远远大于程序设计。 任务 简言之，需求分析的任务就是解决“做什么的问题，就是要全面地理解用户的各项要求，并准确地表达所接受的用户需求。 过程 需求分析阶段的工作,可以分为四个方面：问题识别、分析与综合、制订规格说明、评审。 问题识别：就是从系统角度来理解软件，确定对所开发系统的综合要求，并提出这些需求的实现条件，以及需求应该达到的标准。这些需求包括：功能需求(做什么)、性能需求(要达到什么指标)、环境需求(如机型、操作系统等)、可靠性需求(不发生故障的概率）、安全保密需求、用户界面需求、资源使用需求(软件运行是所需的内存、CPU等)、软件成本消耗与开发进度需求、预先估计以后系统可能达到的目标。 分析与综合： 逐步细化所有的软件功能，找出系统各元素间的联系，接口特性和设计上的限制，分析他们是否满足需求，剔除不合理部分，增加需要部分。最后综合成系统的解决方案，给出要开发的系统的详细逻辑模型(做什么的模型)。 制订规格说明书： 即编制文档，描述需求的文档称为软件需求规格说明书。请注意，需求分析阶段的成果是需求规格说明书，向下一阶段提交。 评审： 对功能的正确性，完整性和清晰性，以及其它需求给予评价。评审通过才可进行下一阶段的工作,否则重新进行需求分析。 方法 需求分析的方法有很多，这里只强调原型化方法，其它的方法如：结构化方法、动态分析法等，从来没用过这些方法在此不讨论。 原型化方法是十分重要的，原型就是软件的一个早期可运行的版本，它实现了目标系统的某些或全部功能。 原型化方法就是尽可能快地建造一个粗糙的系统，这系统实现了目标系统的某些或全部功能。但是这个系统可能在可靠性、界面的友好性或其他方面上存在缺陷。建造这样一个系统的目的是为了考察某一方面的可行性，如算法的可行性、技术的可行性或考察是否满足用户的需求等。如：为了考察是否满足用户的要求，可以用某些软件工具快速的建造一个原型系统，这个系统只是一个界面，然后听取用户的意见，改进这个原型。以后的目标系统就在原型系统的基础上开发。 原型主要有三种类型：探索型、实验型、进化型。 探索型：目的是要弄清楚对目标系统的要求，确定所希望的特性，并探讨多种方案的可行性。 实验型：用于大规模开发和实现前，考核方案是否合适，规格说明是否可靠。 进化型：目的不在于改进规格说明，而是将系统建造得易于变化，在改进原型的过程中，逐步将原型进化成最终系统。 在使用原型化方法时有两种不同的策略：废弃策略、追加策略。 废弃策略：先建造一个功能简单而且质量要求不高的模型系统，针对这个系统反复进行修改,形成......>> 问题四：请问常用的需求分析方法有哪些？ 结构分析方法和面向对象分析法 问题五：培训需求分析的方法有哪几种 组织资源分析 如果没有确定可被利用的人力、物力和财力资源，就难以确立培训目标。组织资源分析包括对组织的金钱、时间、人力等资源的描述。一般情况下，通过对下面问题的分析，就可了解一个组织资源的大致情况。 组织特质与环境分析 组织特质与环境对培训的成功与否也起重要的影响作用。因为，当培训规划和组织的价值不一致时，培训的效果则很难保证。组织特质与环境分析主要是对组织的系统结构、文化、资讯传播情况的了解。主要包括如下内容： 系统特质指组织的输入、运作、输出、次级系统互动以及与外界环境间的交流特质，使管理者能够系统地面对组织，避免组织分析中以偏概全的缺失。 文化特质。指组织的软硬体设施、规章、制度、组织经营运作的方式、组织成员待人处事的特殊风格，使管理者能够深入了解组织，而非仅仅停留在表面。 资讯传播特质。指组织部门和成员收集、分析和传递信息的分工与运作，促使管理者了解组织信息传递和沟通的特性。 问题六：在需求分析阶段常用的图形工具有哪三种 1. 需求分析是准确的理解用的需求将其转换成需求定义，然后由需求定义转换成形式化的功能规约。需求分析的困难表现在问题的复杂性、交流的障碍、不完备和不一致性、需求易变性。 2. 结构化分析方法是采用自顶向下逐层分解的分析策略把一个复杂的系统分解成若干小问题然后分别解决 3. 数据流即数据通过一个系统时的变化方式。输入数据首先转换成中间数据，然后转换成输出结果数据。在此期间可以从已有的数据存储（如磁盘文件或内存缓冲区）中引入附加数据。对数据进行转换是程序中应有的功能或子功能。两个转换功能之间的数据传递就确定了功能间的接口。 4. 把一个功能分解成几个子功能，并确定这些子功能与父功能的接口，就属于横向分解。 5. 把一个功能分解成几个子功能，并确定这些子功能与父功能的接口，就属于横向分解。但如果继续分解，把某些子功能又分解为小的子功能，某个小的子功能又分解为更小的子功能，这就属于纵向分解了。 6. 数据流图是用来表示系统的功能的工具它表示系统的逻辑模型描述了数据流在系统中流动的情况它是一种功能模型。 问题七：如何做需求分析 随着技术的不断发展和用户对网站功能性的需求不断提高，如今网站项目的设计已经不能再仅仅简单地利用静态Html文件来实现，与前几年网站设计由一两名网页设计师自由的创作相比，网站项目的设计和开发越来越像一个软件工程，也越来越复杂，网站项目的设计和开发进入了需要强调流程和分工的时代，建立规范的、有效的、健壮的开发机制，才能适应用户不断变化的需要，达到预期的计划目标。 网站项目管理（WPM）的含义为Web-based Project Management，即以Web 应用程序为主要表现方式的架构来进行的项目设计及管理，这样的架构中包含了浏览器、网络和Web 服务器等关键主体，主要体现在网站设计、以浏览器为客户端的Web应用程序开发（例如信息类网站、网上商店、虚拟邮局、客户关系管理。）等项目管理中。 按照笔者的经验，网站项目管理可以分为以下l六个阶段进行控制： 1. 需求分析及变更管理 2. 项目模型及业务流程分析 3. 系统分析及软件建模 4. 界面设计、交互设计及程序开发 5. 系统测试和文档编写 6. 客户培训、技术支持和售后服务 需要说明的是，这些阶段虽然具有一定的延续性，但是并非完全隔断的，例如需求变更管理和测试工作、文档编写都是贯穿整个项目过程的，许多工作时交叉进行或同时进行的。 （一）如何做好需求分析及变更管理？ 业务员与客户进行的沟通，撰写需求分析报告是项目展开的基础。项目是以客户的需求为中心，而不是为技术而迁就需求。 一：让客户畅所欲言，罗列出所有的需求 让用户将所有的想法尽可能的阐述清楚，并把所有的要求罗列出来，不要遗漏。这时候不应该害怕“勾引”起客户的潜在需求而增加设计开发的工作量，从而被今后客户无止境的变更拖入泥潭，直接明白地跟客户把问题和要求一条条地列出来，把条理、归纳、分析先都扔到一边去，将用户最原始、最完整的要求准确地记录下来就完成了第一步的工作。 很明显，假如客户的需求做的都不完整，随时可能会产生意想之外的变更，甚至这个变更会破坏已经做的模型及结构，那么这个项目从开始就注定了会失败；比如站点所有的功能都实现了，本地测试起来也没有什么问题了，但是你却不知道客户的系统是要承受每天100万独立IP的访问，而你原来想当然的以为了不起就是1万独立IP访问的访问流量，稍微有经验的开发人员都会明白这样的设计是个灾难，无论是应用服务器、数据库还是程序全部要重新开发！ 二：透过现象分析潜在的需求 很多情况下客户并非专业人士，在他们滔滔不绝的描述中不能指望他们帮助我们整理出重点和技术难关，这需要我们去为客户进行分析、归纳和整理，尤其是客户谈的不多却又是技术上实现难度和强度很高的地方特别值得注意。 客户往往对需求的概念是非常模糊的，大多时候给出的需求都是笼统而且尺度难以控制的，这就要求业务人员在倾听了客户的详细说明以后，帮助客户进行整理和分析，同时预测客户在开发过程中变更及今后应用中可能进行修改升级的潜在需求。 比如在为客户设计办公自动化系统的时候，也许就要为客户预留将来与他们的业务单位进行交互的通道；在设计邮件系统的时候要考虑可能会需要广告管理服务器；设计网络电子商店时今后增加库存产品进销存统计分析等等；限于时间财力的考虑，客户通常能够接受分阶段实施的开发过程，在需求分析时，提早为客户设想到今后的需求变更除了使项目开发更加顺利以外，也为今后业务的进一步深入打下......>> 问题八：软件需求分析的方法和工具有哪些内容 1. 问卷调查法， 开发方就用户需求中的一些个性化的、需要进一步明确的需求，通过采用向用户发问卷调查表的方式，达到彻底弄清项目需求的一种需求获取方法。这种方法适合于开发方和用户方都清楚项目需求的情况。因为开发方和建设方都清楚项目的需求，则需要双方进一步沟通的需求就比较少，通过采用这种简单的问卷调查方法就能使问题得到较好的解决 2. 会议讨论法 ，开发方和用户方召开若干次需求讨论会议，达到彻底弄清项目需求的一种需求获取方法，这种方法适合于开发方不清楚项目需求（一般开发方是刚开始做这种业务类型的工程项目）但用户方清楚项目需求的情况。因为用户清楚项目的需求，则用户能准确地表达出他们的需求，而开发方有专业的软件开发经验，对用户提供的需求一般都能准确地描述和把握 3. 界面原型法 ，开发方根据自己所了解的用户需求，描画出应用系统的功能界面后与用户进行交流和沟通，通过“界面原型”这一载体，达到双方逐步明确项目需求的一种需求获取的方法。这种方法比较适合于开发方和用户方都不清楚项目需求的情况。因为开发方和用户方都不清楚项目需求，因此此时就更需要借助于一定的“载体”来加快对需求的挖掘和双方对需求理解。这种情况下，采用“可视化”的界面原型法比较可取
6. 需求分析有什么用？
需求分析很有用啊，就是你可以通过需求分析很直观，很细节的了解到你用户的需求，然后根据你的需求分析在一一去进行。扩展对应的设计。就像是你做事情要先想好，你要做什么为什么应该怎么做？这就是需求。对于你之后的后果效果如何？是由指导性目的性的作用。
7. 需求分析有哪几部分？
需求分析包括这些内容 1 、写出系统的任务和特点 2 、要实现的功能模块和作用 3、 系统结构图 4 、采用的数据库 5 、开发运行环境 "需求分析"，是指对要解决的问题进行详细的分析，弄清楚问题的要求，包括需要输入什么数据，要得到什么结果，最后应输出什么。在软件工程当中的"需求分析"就是确定要计算机"做什么"，要达到什么样的效果。
8. 需求分析有哪几个步骤
需求分析就是对客户提出的“要求”或者“需求”进行深入细致地调研和分析，准确理解用户和项目的功能、性能、可靠性等具体要求，将用户非形式的需求表述转化为完整的需求定义，从而确定系统必须做什么，为系统设计、系统完善和系统维护提供依据。 需求分析是项目计划阶段非常重要的环节，该环节决定了需要“实现什么”，为下一步如何去“实现”提供了明确的方向。 进行需求分析需要做到以下几点： （一）需求获取：在准备阶段，我们首先要确定需求获取的目标及范围，根据你的目标来选择对应的方式获取需求。 （二）需求分类：一般情况下，我们会根据对象的不同，将需求分为业务需求、用户需求、功能需求等。 （三）需求筛选：有些需求是伪需求，有些需求则不具备实现价值，我们可以通过真实性、价值性、可行性三个维度来筛选需求，过滤掉虚假的、不可行的、没有价值、价值不大或投入产出比不理想的需求。 （四）需求提炼：对剩下的需求进行提炼，目的在于从获取的表面需求中提炼出客户的本质需求。找出“为什么要做”比“做什么”更重要。 （五）需求优先级排序：挖掘到客户的真实目的后，我们需要根据不同维度的需求归类方法，如KANO模型分析法、投入产出比ROI等，对其进行归纳整理并排出优先级，帮助产品有条理地安排开发秩序，避免盲目排序。 （六）产出需求文档：通过以上的分析，我们需要将收集到的需求进行分析、汇总、归类，输出产出需求文档，为接下来的工作做好铺垫。 以上是对需求分析的一些理解和思路，做好需求分析工作之后，就可以对可实现的需求进行落地方案的跟进。
最新文章
热门文章
推荐阅读