项目需求分析怎么写？

一、项目需求分析怎么写？

如果是一个软件系统的项目，站在项目角度需求管理包括项目需求、用户需求、业务需求、功能需求、非功能需求等内容。

而项目管理文档中主要是项目需求，在项目实施文档中主要是用户需求分析报告、软件（或系统）需求规格说明书等。

项目需求主要包括：（不同的项目还会有适当增减，由于不清楚你的项目具体情况，所以把总体上项目需求包括的内容都罗列一下）

二、项目需求分析主要分析哪些方面？

项目需求分析主要分析的内容包括项目市场分析项目客户结构分析。

三、创业项目需求分析思路？

通过市场调查，先写出创业项目当前市场需求情况，再统计出边缘徘徊需求予以分析，最后列举具体提升需求措施。

四、erp项目需求分析前的准备？

对软件系统要求 此处所说的系统要求是企业的硬件的操作系统，数据库系统要求。现在企业的类型多元化，有国有企业、外资企业、合资企业等，各类企业的硬件的操作系统要求也不尽相同，有windows、IOS、Linux等软件操作系统，数据库系统方面的种类也有很多，像Oracle、MSSQL、Mysql、Sybase等，企业要根据自己的需要以及自己的财力来均衡一下选择合适的操作系统及数据库系统很重要，当然一个ERP软件如果能跨平台跨数据库系统是很好的，但实际操作过程中有很多问题也相当复杂，合适的才是最好的。

五、项目需求分析都包括哪些内容？

需求分析是指理解用户需求，就软件功能与客户达成一致，估计软件风险和评估项目代价，最终形成开发计划的一个复杂过程在这个过程中，用户的确是处在主导地位，需求分析工程师和项目经理要负责整理用户需求，为之后的软件设计打下基础。需求分析阶段包括：

业务需求——反映了组织机构或客户对系统、产品高层次的目标要求，通常在项目定义与范围文档中予以说明。

用户需求——描述了用户使用产品必须要完成的任务，这在使用实例或方案脚本中予以说明。

功能需求——定义了开发人员必须实现的软件功能，使用户利用系统能够完成他们的任务，从而满足了业务需求。

非功能性的需求——描述了系统展现给用户的行为和执行的操作等，它包括产品必须遵从的标准、规范和约束，操作界面的具体细节和构造上的限制。

需求分析报告——报告所说明的功能需求充分描述了软件系统所应具有的外部行为。“需求分析报告”在开发、测试、质量保证、项目管理以及相关项目功能中起着重要作用。

六、如何做项目需求分析？

发现网上关于商业分析师的各种回答都是产品经理的答案，产品经理(Product manager) 和项目经理(Project Manager)不同，虽然都叫PM. 但是区别还是蛮大的，另外国内很多人把商业分析师和产品经理当作一个工作职能也是有一定的误解。

我的理解产品经理是跟特定的产品的，对产品和用户负责，可能也会对这个产品的盈利模式和未来的发展作全程跟踪，有点像妈妈和孩子的关系，中心思想是关心产品的未来发展。

项目经理有点像班主任和孩子的关系，每个项目的产出都有不同，在项目上线以后就交给产品经理和运营团队了，对于产品未来或者否盈利不是特别的关心，就像是班主任保证学生都顺利升学，没有留级挂科就好，将来干什么一般不关心。中心思想是在规定时间内按照需求交付产品。

而商业分析师侧重在于整个的细致流程的，有点像学校的教务处，比如课程表的制定，由哪个老师教，学生在整个学期内中什么时候做什么样的事情进行细致规划。中心思想在于保证流程的通畅，不至于学生来了学校上了数学课之后下一堂课进行不下去不知道应该做什么，这是甲方的商业分析师。而乙方的商业分析师有点像具体的某个专业课的授课老师，区别下文会详细说明。

在这里简单的回答一下项目的需求分析，算是抛砖引玉吧，欢迎交流，未经许可禁止转载。================================================

首先商业分析师 （Business Analyst）所要涉及的知识面非常多。根据题主的问题简单的回答一下，然后再慢慢更新。

1. 什么是Business Analysis (BA)?

商业分析师这个工作最早产生于90年代，是组织机构为了对内部的线下各部门的运营流程衔接以及线上的计算机系统进行整合（因为最容易出现问题的地方往往是各个部门衔接的地方）使之对公司产生好的经济效益。

提主没有特别说明这个需求分析师是针对甲方还是乙方的，这两个地方侧重的方面均有不同，那么我就分开来说吧，两个位置我都做过。

对于甲方的商业分析师来说，你的分析一般需要涵盖自始至终的流程，包含手动和自动任务， 产出是BRD (Business Requirement Doc) 而最终的目的是每部分都可以进行有效的测量，包含生产的产品或服务，方便项目结束以后对每一部分进行追踪，比如从客户登陆网页购买产品开始，order number传给公司后台，包装部门线下进行包装配送，更新配送信息到系统，会计部门准备发票，等等。一般来说系统上线项目交接给运营部门会对该项目进行营利率追踪，普遍为5-10年，然后在追踪过程中，会对线上线下的流程进行优化，也就是我们说的项目之后的phase 2， phase 3 等等。

而甲方的项目往往会拆分成很多的小项目，分配给不同的服务供应商（一般是IT公司）他们所要提供的一般是这个项目的一部分IT系统的研发，比如CRM系统交给乙方1来做，会计系统交给乙方2来做，等等，最后和线下的流程一起交付给甲方的运营部门，那么对于每个乙方项目也会有商业分析师(BA) 偏IT系统技能的，而产出是根据BRD 产出的FRD (Functional Requirement Doc)和TD (Technical Design Doc).

对于甲方的商业分析师，一般用来作商业分析都会会采用Business Process Diagram进说明，这样可以使各个部门以及所对应的工作内容清晰化，并且能够找到流程上的瓶颈，低效率的部门，链接不畅等问题，说明现有流程(As is)，以及将来流程(To be), 这里面涉及到 High level的Business Requirements, 和干系人需求（Stakeholder requirements）以及Low level的解决需求(Solution Requirements) 这个Topic 很大就不展开讲了。

2. 需求记录（注意这里面首先是要记录需求，而不是排序或是辨别伪需求）

根据我的经验一般项目开始作为一个商业分析师，第一阶段首先跟项目发起人沟通，首先项目发起人对自己所要的一定是非常清楚的，但是很可能他要的idea 的范围很大，大到即使他自己也不知道有多大。不要紧，这里需要弄清楚的是项目干系人都有谁，所涉及到的整个流程都有哪些部门，负责人都有谁。并且和项目发起人的沟通过程中我们会产生很多问题，将这些问题写下来，做一个需求Burn down chart, 第一列写上出现的问题，第二列写谁提出的问题，第三列写提出问题的日期，第四列写出期望谁来回答这个问题，第五列记录得到回答的时间，第六列记录答案。

第二阶段就是开很多的work shop和约谈这些项目干系人，这时候当我们约谈越来越多的人时候Burn down chart里面的问题也会增多，一些问题将会被解决，一些问题会出现，我们都将这些需求记录并更新最新的答案。

3.辨别伪需求

第二阶段约谈项目干系人的时候我们可同时进行需求的鉴别。主要有4个部分：

3.1 这个需求是否是真正的需求？很多时候项目干系人给出的问题或者需求其实已经给了我们解决问题的方法，比如Digital的经理说，我们需要一个网上博客，这就已经给了你解决方案，但是这并不足够，你的分析是为什么需要博客账号？解决了什么。分析之后会发现因为我们没有博客，而且没有频繁更新，导致我们在网络搜索排名下降，网络无法导流到我们公司的产品主页。Root Cause 是流量导入，那么我分析可以给出很多导流的方案，比如微信，微博，百度购买关键字等。

如果决定了使用博客，那么我们需要分析的是，是我们自主开发博客，还是购买现成的模板，或是直接找公关公司替我们维护等等，我就不展开说了。

3.2 干系人提出的问题是症状还是病根？比如一个人说他腰疼，那么如果我是医生给他去疼片，吃过之后他感觉不到腰疼了，那我们是在处理他的症状而不是病根，当药效停止之后他肯定还会腰疼的，那么我们需要提供的解决方案是多运动，或者提议作腰部手术，将病根解决，这才是真正的需求。

3.3 如果病根解决之后是否其他的需求也会一并解决？对照burn down chart 进行需求归类，总结 Root cause, 例如可以将如腰疼导致的腿脚酸软一并解决。

3.4很多情况下在解决root cause 的时候会产生新需求，我们需要再按照3.1到3.3的流程解决一遍。

4 项目范围的界定以及假定。经过上面的流程我们应该得到大部分的答案了，对于没有解答的问题我们需要进行进一步的分析。

4.1不在项目范围内如果一个问题即使项目发起人都无法回答，那么大部分是因为这个需求不在项目范围内，这时候我们需要跟项目发起者和关系人声明这一点，并且明确写在商业需求分析文档内，4.2根据自己的分析理解写出假定的分析记住将你的假定分析以邮件文本形式发给所有人，告知因为在规定时间内我们无法得到答案，所以我们进行如下假定XYZ.

4.3 将总结好的需求文档给大家审阅，进行MOSCOW分析，哪些功能是Must have, Should have, Could have, Won't have, 并在会上通过。

最简单的需求文档的格式一般包含以下几部分。a. 交代背景/ 项目的发起原因/ 解决什么样的问题/ 达到什么样的 goalb. 交代项目大概涉及到什么功能/ 牵扯哪些部门c. 项目的假设/ 依附关系/ 项目风险/ 声明非本文档内所提及的需求之外的需求皆不在项目范围内。d. 具体的项目需求/ 流程 等*（主要部分）e. 非功能性需求f. 系统需求及权限配置g. 项目发起人，和关系人对该文档的批准邮件h. 附录

5.需求表总结。对于一个高级的商业分析师，可以根据burn down chart来做出很多数据透视表，比如根据问题提出的时间和得到答案的时间大概算出该问题在回答者心目中的重要性，以及在escalation的情况下以此做为你的依据；还有真实需求和伪需求的占比，得出大家对项目的理解程度；最后如果你离职了，也可以把这个表给新人，让他迅速投入到工作中去。

... 以上。

===============================

有对该业务或企业咨询感兴趣的朋友欢迎勾搭

微信号：红色共产

电邮：crossrnbw@163.com

本文欢迎有兴趣的朋友进行转载，转载时请务必添加本人简介于文末，若有商业用途，烦请尽量联系告知作者。

七、项目需求分析文档都包括哪些内容？

需求分析是指理解用户需求，就软件功能与客户达成一致，估计软件风险和评估项目代价，最终形成开发计划的一个复杂过程在这个过程中，用户的确是处在主导地位，需求分析工程师和项目经理要负责整理用户需求，为之后的软件设计打下基础。

需求分析阶段包括： 业务需求——反映了组织机构或客户对系统、产品高层次的目标要求，通常在项目定义与范围文档中予以说明。用户需求——描述了用户使用产品必须要完成的任务，这在使用实例或方案脚本中予以说明。功能需求——定义了开发人员必须实现的软件功能，使用户利用系统能够完成他们的任务，从而满足了业务需求。非功能性的需求——描述了系统展现给用户的行为和执行的操作等，它包括产品必须遵从的标准、规范和约束，操作界面的具体细节和构造上的限制。需求分析报告——报告所说明的功能需求充分描述了软件系统所应具有的外部行为。“需求分析报告”在开发、测试、质量保证、项目管理以及相关项目功能中起着重要作用。

八、怎样写好项目的需求分析？

项目需求分析汇总

分析项目要覆盖的业务场景，以及要实现自动化的功能点。

比如使用自动化测试的业务范围，即哪些功能适合自动化，确定好测试方法、测试策略等方式

制定项目计划

项目一定要有范围，把范围定义清楚很重要

其次是对项目设定目标，对于这一点需要综合评估项目本身，如范围，涉及业务类型、大目标，否则就没有意义

项目计划需要联系

项目执行需要遵循项目计划

8.1.2制定测试用例

自动化测试也是需要编写测试用例的，这是规范和追踪测试活动的一个必不可少的环节

8.2 业务场景覆盖和分拆

业务场景覆盖和分拆是项目进行的前提。

8.2.1 逐个页面元素分析

8.2.2 分层创建脚本

1、 Python 中导入模块语句

• Python标准库模块即Python自带库
• Python第三方模块
• 自定义模块

2、函数

函数有六大要点，分别是

• Def
• 函数名
• 函数体
• 参数
• 返回值
• 两个英文符号，小括号(),里面是参数的定义内容和冒号。

Python函数有五大要素 Def、函数名、函数体、参数、返回值。

注意事项：设置参数顺序是，必须是必选参数在前，默认参数在后，否则Python解释器报错；默认参数必须指向不可变对象。

九、需求分析是在项目中扮演什么角色？

需求分析是在项目中根本顾客需求什么样的产品，根据需求在项目中制定生产方案。

十、需求分析步骤？

1、概念明确----2、需求分析目的------3、如何识别需求---4、判断需求真伪----5、分析[ 用户故事评估框架、马斯洛框架、营销框架定位]---6、评判价值----7、砍需求能力---8、分类----9、排优先级----10、提升需求分析能力