1.项目的范围：在需求分析中，首先必须明确项目的范围，去掉那些看似属于该项目其实不该在项目中的需求特性。特别是在一些MIS项目中，客户往往把一些属于他们的日常工作但不属于该项目的需求提交给项目组，这时必须分清项目的范围，不要在项目中加入太多不应该做的东西，否则往往会导致项目范围无限扩大，终只能是使项目失败。
2.需求的优先级：需求的优先级是非常重要的特性，只有在准确把握的需求优先级的基础上我们才可能规划外部里程碑(产品版本)和内部里程碑(开发的阶段性，后面会讲到)。通常是用户关心，使用频繁的功能应该属于高优先级，而那些不怎么重要或很少用到的功能应该属于低优先级。我们必须在产品的开始版本和项目的开始把重点放在高优先级的需求上，而对于低优先级的功能可以在项目后期根据需要进行裁减或纳入下一个版本规划。项目经理圈子
3.产品的易用性：产品的易用性反映在原型中，是原型法的一个非常重要的作用。很多产品的失败其一个重要原因是易用性比较差，虽然它在功能上满足了用户需求，甚至可以说功能很强大。通过原型法，能让用户看到并模拟使用终的产品界面，能在需求阶段通过修正软件界面来适应用户的偏好，从而在很大程度上提高了产品的易用性，使项目更容易成功。blog.mypm.net
4.其他需求特性：如性能要求、健壮性等。这些特性是产品的非功能性需求，也是项目成功的关键因素，特别是在一些大型的涉及重要领域的管理信息系统中。
需求分析是整个项目活动中的非常关键的部分，它的好坏往往决定了项目的成败。根据经验，需求分析所需的时间往往占整个项目时间的12%[1]。在需求分析中，需要防止的一个错误做法是太依靠一些所谓的分析方法，而使整个需求分析过程非常复杂，过多的图表往往使人眼花缭乱，而不能准确抓住问题的本质。一些分析人员往往对自己熟悉的简单的业务花大力气，而对不熟悉的则一笔带过，也是本末倒置的错误行为。在分析过程中，我们必须始终把握需求分析的目的是把模糊的流程搞清晰，把复杂的业务尽量简化，而不是相反。项目管理培训
需求的管理也是非常重要的方面。对需求分析完后的形成的规格说明需要进行专门的评审，并且需要客户和终用户的参与，在达成一致后形成初的需求基线。以后对需求的更改都必须在基线的基础上进行，并需要项目组各成员的一致确认，对需求进行严格规划评审的目的也在于在项目的后期能尽量减少对需求的更改，提高开发的效率。项目管理者联盟
需求分析完成后，项目组需要对项目的初步计划进行重新审定，一般都需要变更项目时间表和资源需求。需求分析的完成也意味着项目其他部分可以齐头并进，如概要设计、测试计划、用户说明书，这也在某个方面证明了需求分析的重要性-它是下面所有活动的基础和准绳。
3.2.3开发计划
软件开发中的计划性是非常重要的，一个没有良好计划的开发项目能够成功的机会非常小，除非有天才的程序员再加上好运气。开发计划的主要内容包括：项目进度安排、人力资源安排，风险管理策略等。
项目的进度安排和人力资源安排可能是开发计划中重要的部分，也是难以估计的部分。一般国内的中小软件公司对项目工作量和开发人员能力的量化程度不高，所以导致进度和资源安排不确切，有时候甚至是相差很远。目前一个实际的办法是根据以往项目的积累，但必须要求是同一领域的类似项目，这样才有较强的可比性。由于这些计划安排是预估粗略的，所以还必须在以后的项目各阶段完成后进行合理的变更，反应项目的实际需求。微软的办法是把进度估计的权限交给开发人员，由开发人员根据自己的经验进行估计，由于一般开发人员往往会高估自己的能力，估计的进度也会相应偏短，后再做适当的延长[2]。这种办法有它合理的地方，在中国还需进行实践摸索。
对于进度的估计，我们有个经验公式，即您初预估的时间再乘以2.5，可能是后的完成时间。因为许多人在估计进度的时候，往往忽略了很多非开发时间，如与客户沟通的时间、项目组沟通时间、公司培训时间、假期等，所以我们在估计进度的时候，一定要全方位周全考虑，在尽可能的情况下宁愿把进度估计的长一点，免得在项目后期导致非常被动的局面。后面我们将具体讲到我们采取的阶段性的开发方法，这种方法的运用反映在进度估计时必须在各阶段间预留缓冲时间，以解决那些我们事先没有预料到的活动。如果进度表和要求的出货时间有冲突，宁愿砍掉一些不重要的功能，也不要盲目增加人手，这种做法可能会导致产品质量下降，终得不偿失，详细说明请参考[4]。
风险管理是项目管理中非常重要的部分，并且要贯穿项目的始终。一些软件企业往往不是很重视风险管理，导致在项目的后期出现了很多预料之外的事情，使项目进度一拖再拖，往往质量也达不到预期要求。因此我们要特别重视风险的管理，具体方法留待后面专门详述。
3.2.4开发过程
在项目的开发过程中，我们采用了阶段式的开发过程，这也是微软公司所推荐的开发过程。在开发过程的初期，首要的活动是概要设计。概要设计的目标是简单、适用、能够覆盖所有的需求并能支持后面的阶段式开发。微软的应用方案解决模型是基于服务的三层(多层)架构，包括用户层，业务层和数据层，各层之间采用标准的接口进行通讯，至于该方法的具体使用，请参看相关书籍，在此不在赘述了。
阶段开发过程不是传统的根据模块划分来依次完成各模块，后再进行项目的整合，而是在每个阶段完成后，项目都可以推出产品，只不过该产品的功能比终产品的功能弱一些。
阶段性完成项目比传统的开发方法明显的优点是不必到项目的末期才开始整合产品，使产品模块之间协作产生的问题及早产生，也及早修正，从而项目的风险也大大减小。传统的开发总是在项目的后期才开始整合各模块，使产生的问题改正起来极为困难，成本也大大增加;前面累计的所有问题全部都拖到了后面来解决，也使后面剩下的工作量大大增加。项目往往看起来已完成了90%——大部分的功能模块都已完成，但剩下的10%总是完不成，项目进度一拖再拖，很可能还要再花90%的时间来完成剩下的10%。当然采用阶段性开发方法也有相应的代价，大的代价可能是反复的整合、测试已经完成的模块，但采用相应的一些自动化工具可以减小这个代价。
一般在开始的阶段进行的是系统架构和重要的功能，后面的阶段是相对不怎么重要的功能。这样的分配有利于终用户在早期能看到系统的大致模样，便于他们及早的对产品提出意见，并对相应的错误进行修改;也有利于项目组在项目后期时间很紧的情况下，去掉一些不重要的功能，把它们纳入下一个版本处理，确保产品的推出时间。迭代的顺利进行依赖于良好的架构设计，前面阶段的设计应该给后面要加入的功能预留出各种接口，并能使后面的工作在前面的基础上继续进行下去。
这种在开发阶段的迭代方式不同于整个项目的完全迭代开发，后者是项目的需求、概要设计、开发等全部是迭代进行，一次迭代要进行所有的项目活动。至于谁优谁劣可能在不同的情况下有不同的说法，需要根据项目和自身的情况合理采用。
还有是迭代的次数也要根据项目的具体情况而定。不能太多，导致重复的工作量过大;也不能太少，使得该方法退化到传统方法。我们的项目(项目小组在10人左右，开发时间在5个月左右)一般分了四个阶段：架构完成、主要功能完成、其他功能完成、整合发行。实践证明，这样的实施比传统方法确实在很大程度上减小了项目失败的风险，再没有产生那种“似乎永远也做不完的感觉”。项目管理者联盟文章
这里举一个具体例子来更形象的说明该方法的运用。一个一般的MIS程序，第一阶段可以构建数据库结构和基于特定领域的核心平台服务(包括一些基本服务类)，并进行初步整合;第二阶段可并行同时开发系统各大模块的基本功能，并进行第二次整合;第三阶段可开发其他增强功能，也需要相应的功能整合;第四阶段进行整个系统的后整合，并可进行相应的性能改进，使产品进入可发行状态。
