软件项目需求分析的要点与项目管理要遵守的流程

（一）软件开发的一般流程是什么?

软件开发一般分为五个阶段：
1.问题的定义及规划
此阶段是软件开发与需求放共同讨论，主要确定软件的开发目标及其可行性。
2.需求分析
在确定软件开发可行性的情况下，对软件需要实现的各个功能进行详细需求分析。需求分析阶段是一个很重要的阶段，这一阶段做的好，将为整个软件项目的开发打下良好的基础。“唯一不变的是变化本身”，同样软件需求也是在软件爱你开发过程中不断变化和深入的，因此，我们必须定制需求变更计划来应付这种变化，以保护整个项目的正常进行。
3.软件设计
此阶段中偶要根据需求分析的结果，对整个软件系统进行设计，如系统框架设计、数据库设计等。软件设计一般分为总体设计和详细设计。还的软件设计将为软件程序编写打下良好的基础。

4.程序编码
此阶段是将软件设计的结果转化为计算机可运行的程序代码。在程序编码中必定要制定统一、符合标准的编写规范。以保证程序的可读性、易维护性。提高程序的运行效率。
5.软件测试
在软件设计完成之后要进行严密的测试，一发现软件在整个软件设计过程中存在的问题并加以纠正。整个测试阶段分为单元测试、组装测试、系统测试三个阶段进行。测试方法主要有白盒测试和黑盒测试。
以上就是软件开发过程的五个阶段，但是有的时候在软件爱你开发过程中并不是必须按照这个过程进行的。

（二）软件项目管理必须要遵循一定的规律

一般一个好的软件开发必须是要遵循一定的规律的：
1、首先制定项目计划，最初计划是里程碑性质的。可以先按瀑布模型设置，里程碑点主要为需求评审、设计评审、经过代码开发和单元测试后进行集成测试、部署上线是一个很重要的里程碑，一般用户会期望系统何时能使用，进入试运行期。
2、需求开发阶段：怎么样写好需求很关键，这个需要实践经验锻炼自己。如果有项目成员，可以一起做需求，这个阶段对于业务理解、分析、如何开展调研以及文字表述、业务流程图描述还有文档编辑能力都有不少要求。一般分为《用户需求说明书》和《需求规格说明书》，小项目可以写一个《需求分析报告》，《用户需求说明书》是用用户的语言进行描述，让用户和开发团队对于需求的达成一致的理解，《需求规格说明书》，则是对用户需求的分析，形成系统要具有的功能，这个是真正提供用户可交互操作的文档，也就是后期设计和代码开发的重要基线。
另外，作为了解需求，拿出用户UI和用户交流也是一项比较重要的需求获取手段，虽然这个属于设计的范畴
3、系统设计阶段：
系统总体架构，结合用户对系统环境、开发语言以及运行的网络硬件等要求，确定开发工具等，对应用系统关系进行架构性设计，通过需求阶段对用户的分析归类，用图的方式描述出用户和各子系统或模块的全局视图，以及和其他系统的关系。也就是搞清楚系统的边界问题。
概要设计中除了高层架构设计，还需要设计网络拓扑图，以及系统部署图。概要设计比较重要的还有就是子系统、模块进行合理的划分。模块的名称很大程度上会成为用户的主要菜单，如何用用户的角度去取比较清楚的子系统和模块是很重要的。
4、代码开发和单元测试阶段：这个阶段一般来说需要改进瀑布模型，类似跌代开发，把模块进行合理划分，把项目总体计划的代码开发测试阶段划分为多个时间段，每个时间段都包括代码开发、单元测试和集成测试，这个阶段还需要对需求变更进行跟踪控制，如果需求有变更，那么要把需求文档、设计文档都重新跟上。跌代开发的好处就是不让代码开发阶段拉的过程，没有进行及时的自我检查，不小心到了提交时间，却不是用户想要的，还有可能都不是自己想要的。
项目经理重要的责任是控制好进度，能及早发现风险，并能拿出好的预防和解决办法的措施。合理安排好开发团队的任务，合时的任务安排和衔接，你会觉得非常有艺术感，这个要自己体会了。另外，关注项目团队各人员的状况，保持高的战斗力，及时发现并能鼓励团队共同朝一个目标前进。
5、测试工作，测试是项目的很重要的环节，怎么测试，怎么准确测试，怎么有效测试，怎么覆盖测试，时间、人手、经验扽个方面都会有制约。高级测试人员能够分析系统各测试要点，在需求、设计阶段都要参与，提早了解如何去测试，能写出测试用例。
6、文档工作，文档在项目开发中也占有重要位置，除非你觉得代码是项目唯一的成果，那么你把文档抛掉吧，什么都在你的脑子里，团队中人员一走，项目的一部分也就带走了。代码开发其实也需要文档，代码是成果，代码注释是成果，模块开发卷宗也是重要的成果，因为程序员在开发时候的逻辑是怎么样的，对于今后查问题很有作用。除非你的系统设计程度到了方法、类，把代码逻辑也都设计好了，那么程序员就CODEING去吧。
7、QA是对项目过程的质量保障，有些公司吧QA和测试工作合成一个岗位叫做QA&测试人员，或者就叫QA人员。QA是对项目全过程的监管，独立于项目之外。监督项目经理在各项目里程碑提交相关成果，入库形成基线。

（三）软件项目中，需求究竟该怎么分析？

对于软件开发团队而言，软件开发的全过程是：做什么 -> 怎么做 -> 做 -> 成果检验 -> 交付部署；其中，“做什么”对应的是需求分析过程，“怎么做”对应于软件架构设计过程，“做”对应于开发过程，“成果检验”对应于测试，部署由运维团队执行后，如果达到用户的要求，则软件上线后进入软件的运行生命周期。
而在实际的软件项目开发中，“做什么”，“怎么做”和“做”是紧密结合在一起的，“做”，“成果检验”和“交付部署”通常也会是一个持续交付过程，“成果检验”的内容会受到“做什么”的影响，开展“做什么”阶段的时候，也要考虑到如何部署和交付。所以软件开发的全过程，都是紧密结合在一起的，如果刻意划分为独立的几个阶段，忽视其作为一个整理的综合影响，每个环节的实施过程必然会遇到因上一阶段考虑不周全带来的问题，从而影响整体开发效率。
今天，我们首先来谈一下软件项目中，需求究竟该怎么分析？

正确的需求分析决定了我们产品的方向，需求分析搞错了，做再多都是浪费。只有方向对了你才能走出迷途，方向错了，你只能迷失！基于此，我们的需求分析可分为两个阶段，第一个阶段是收集需求，第二个阶段是处理需求。 

收集需求
需求的来源有很多，需求的处理方式也不尽相同。有效的收集需求，将收集到的需求去伪存真，是产品设计环节中最重要的一环，如同大厦的地基，地基不坚实，大楼是盖不起来的。而且我们在收集到需求时，要第一时间与用户交流沟通，尽量走到用户中去了解他们的想法，深入了解目标用户在真实环境下的感受，尽可能地挖掘用户的原始需求，充分了解用户真实场景，才能真正更好地服务用户，打造出他所想要的产品。
1、还原场景
如果只是单独看用户提出的需求，你很难分析到用户的真实需求，就像有些英语单词一样，你必须放到那个语境下面去了解，才能找到用户背后真实目的。
我们可以从以下场景进行分析：
基于什么环境：地铁/办公室/室内/公共场合/走路/夜晚/户外......深入情景周围的细节中去。
基于什么用户：具备什么特征，比如身份、收入、区域.....
基于什么行为：行为或操作流程，比如购物流程、操作习惯、行为认知.......
场景分析也就是需要考虑具体什么环境（时间、地点、情境）什么类型用户的什么动机，想达到什么目标，以及人与人的关系。如实地分析记录下来，如果偏差或缺乏信息，之后的分析就会有所偏差。
2、多问几个为什么
用户需求的传递过程中总是存在着无法完全理解吸收的问题，导致所收集的需求不一定就是用户的真实需求，这时你需要做的是找到需求的提出人，多问几个为什么。这个需求提出人可能是用户，也可能是运营，也可能是技术，你多问几个为什么的时候，也就能发觉用户背后的需求。
3、数据分析
数据是客观反映产品的重要指数，也是收集需求的重要来源，前期收集的数据需要是可靠、客观的，而且数据是零散的，在进行数据分析前一定要有明确的中心，划定一个界限，收集同一个框架内的数，同时单独的数据是死的，有对比的数据才有意义。为了避免主观意识的影响，同一份数据可参考其他人员的分析结果。
4、多和别人沟通/头脑风暴
一个人的力量是有限的，当我们吃不准的这个用户需求的时候，可以把这个需求拿出来和用户讨论一下，进行头脑风暴一下，人多力量大么，当我们吃不准一个需求的时候，大家都认为的那个结果就是需求分析的结果。

处理需求
处理需求的阶段，也是产品经理将需求进行筛选，梳理业务流程，设计产品架构的阶段。
1.需求筛选、分类
尽管我们保持严谨的态度收集大量的需求，其中还是有很多需求是“伪需求”，甚至是不合理的，我们第一步就需要将这些需求进行“清洗”，择优去重、去伪存真。
2.设置优先级
一般来说，从需求类型来看，基本型需求>期望型需求>兴奋型需求；
从需求来源来看，战略性需求（用户提出）>功能性需求（核心功能）>业务性需求（拉活、存留）>体验性需求（提升用户体验）。需求优先级判断最常用的是用四象限法则去评定优先级，另外可以使用RICE评定方法，KANO模型等。
3.竞品分析
由于在这个阶段，产品经理不仅要定义目标用户、产品使用场景，还要确定核心功能，产品流程等等，因此通过竞品（如果有）来辅助处理需求是一种很有效的方法。
通过相似竞品的用户定位、功能反推竞品的需求，与自己的需求进行对比；将自己的需求代入竞品中，看流程是否符合逻辑；与竞品进行对比，分析需求的异同。
4.需求评审
在这个阶段之前，作为产品经理对于产品应该有了一个完整的模型，但仅仅是理论上的模型，确保UI、UE、前端开发、后台开发、测试参与，从产品开发流程的各个角度对需求进行拆解、分析。需求评审可以看作是产品开发的初始化或者预开发。
需求分析是基于用户沟通、背景认知、人性理解，层层还原一个需求本源的过程。我们对一个需求的还原程度越高越准，越有机会在后续产品设计给出合理的方案。

（四）软件项目需求分析：非功能性六大点

1、功能性项目
功能性指与一组功能及其指定的性质有关的一组属性，这里的功能是指满足明确或者隐含的需求的那些功能。具体包括：
• 适合性：与规定任务能否提供一组功能，以及这组功能的适合程度有关的软件属性，例如面向任务系统中由子功能构成的功能是否合适，表容量是否合适等等。
• 准确性：与能否得到正确或者相符的结果或者效果有关的软件属性。
• 互操作性：与其他指定系统进行交互的能力有关的软件属性。
• 依从性：使软件遵循有关的标准约定法规及类似规定的软件属性。
• 安全性：即与防止对程序技术局的非授权的故意或者意外访问的能力有关的软件属性。如用户权限、动态口令、数据库字段加密等。
对于这组非功能需求来说，绝大部分是满足功能需求的情况，他并不需要采用额外的措施，而安全性是一个例外，它会涉及具体的技术性功能需求。

2、可靠性
可靠性之与在规定的一段时间和条件下软件维持其性能水平的能力有关的一组属性。具体包括：
• 成熟性：与有软件故障引起失效的频度有关的软件属性。
• 容错性：与在软件故障或违反指定接口的情况下维持规定的性能水平的能力有关的软件属性。如离线录入支持等。
• 易恢复性：与在是小发生后重建其性能水平并恢复直接受影响数据的能力，以及为达到此目的所需时间和努力有关的软件属性。如表单数据自动保存等。
这类非功能需求通常是全局的，他除了与系统运行环境、平台选择、代码质量相关之外，还会涉及部分技术性功能需求，他别是容错性、易恢复性的实现都需要一些具体的功能来支持。

3、易用性
易用性是与一组规定或者潜在的用户为使用其软件所需做的努力和对这样的使用所作的评价有关的一组属性。具体包括：
• 易理解性：与用户为人质逻辑概念即其应用范围所花的努力有关的软件属性。
• 易学习性：与用户为学习软件应用所花的努力有关的软件属性。
• 易操作性：与用户为操作和运行控制所花的努力有关的软件属性。如带首字母筛选功能的下拉列表等。
这类非功能需求是与UI设计、联机帮助系统有着直接关系的，易理解性和易学习性通常和界面导航、联机帮助有关，课归纳为界面友好性;易操作性则会和界面元素设计有关。也就是说这类属性会关联到具体的技术性功能需求。

4、效率
效率是指与在规定的条件下软件的性能水平与所使用资源量有关的一组属性。具体如下：
• 时间特性：与软件执行器功能时响应和处理时间及吞吐量有关的软件属性。如数据缓存等。
• 资源特性：与在软件执行其功能时所使用的资源数量及其使用时间有关的软件属性。如数据压缩等。
这部分实际上就是通常所说的性能需求，他有一大部分是局部性的，在每个用力的描述中应该指出;另外它又会引申出一些相关的技术性功能需求，例如数据缓存等。

5、维护性
维护性是指与进行指定的修改所需的努力有关的一组属性。具体包括：
• 易分析性：与为诊断缺陷或者失效原因及为判定待修改的部分所需努力有关的软件属性。如日志记录系统等。
• 易改变性：与进行修改排除错误或者适应环境变化所需努力有关的软件属性。
• 稳定性：与修改所造成的未预料结果的风险有关的软件属性。
• 易测试性：与确认已修改软件所需的努力有关的软件属性。
这部分通常是开发团队最容易投入时间和成本的地方，诸如动态属性支持、UI界面生成、流程引擎等都是为了提高系统的可维护性，因此它显然是会引申出相关的技术性功能需求的。

6、可移植性
可移植性是指与软件可从某一环境转移到另一环境的能力有关的一组属性。具体包括：
• 适应性：与软件无需采用有别于为该软件准备的活动和手段就可能适应不同的规定环境有关的软件属性。如全球技术支持等。
• 易安装性：与在指定的环境下安装软件所需努力有关的软件属性。如在线更新、安装包自动生成等。
• 遵循性：使软件遵循与可移植性有关的标准或约定的软件属性。项目管理论坛
• 可替换性：与软件在该环境中用来替代指定的其他软件的机会和努力有关的软件属性。
这部分除了需要通过选择正确的开发工具、平台来支持外，也会涉及一些技巧性的功能需求，如全球语言支持等。