对“需求分析”的看法

一直认为一个产品或者项目做的好坏是看它是否真正的满足了用户的需求，但怎么做到符合用户的需求呢？

个人认为需求包括业务需求、用户需求、非功能性需求等，业务需求是来自于部门的高层或者组织者提出的一个比较大概念的需求，不会具体到细节，它代表改软件最终实现的一个目标。用户需求是来自于真正使用该软件的底层用户的要求，软件要帮助底层用户去高效的工作，具体的功能要求都是来自于底层用户的意见。非功能性需求是指软件必须遵循的标准、规范和约束，操作界面的具体细节、易用性等。一个产品经理写出一份完善的需求说明书就要基于这些需求，而很多的产品经理常常会替用户说话。

一个好的软件是建立在一个好的需求说明书上的，而需求说明书来源与产品经理对需求的分析，做一个好的需求分析要做到一下几点：

1.了解业务需求，产品经理要于业务人员沟通，明白改软件要达到的目标，而业务方表达出的意见都是比较大概的，那麽PD就要去抽象这些业务的需求，把业务方的表述转化为一种可以实现的业务流程

2.与底层用户沟通，PD最好是可以在实际的工作中体验下底层用户的整个工作流程，明确的知道旧系统的功能，然后分析新系统要达到的目的，到底比旧系统优秀在那里，并且收集底层用户对新系统的期望

3.有良好的沟通技巧，PD在收集需求的过程实际上是个沟通的过程，PD要想办法让业务方或者底层用户能够滔滔不绝的说出自己的想法和意见，包括具体的功能和易用性方面的要求。

4.与开发人员沟通，沟通关于技术实现的各个方面，PD应该尊重开发人员，也要考虑开发成本与实现功能的性价比问题。

5.需求变更及时通知开发人员和测试人员，保证问题都在项目前期被发现解决。