比如在为客户设计办公自动化系统的时候，也许就要为客户预留将来与他们的业务单位进行交互的通道;在设计邮件系统的时候要考虑可能会需要广告管理服务器;设计网络电子商店时需考虑今后增加库存产品进销存统计分析等等;限于时间和财力的考虑，客户通常能够接受分阶段实施的开发过程，在需求分析时，提早为客户设想到今后的需求变更除了使项目开发更加顺利以外，也为今后业务的进一步深入打下了更好的基础。
4.2 利用自然的语言和图表描述项目模型
在业务员与客户进行沟通和调查时撰写的需求分析，尽可能用自然语言或形式化语言来描述，还可以添加图形表述方式和模型表征方式。虽然客户的水平和资历有所不同，但是最自然的描述能够使项目开发的各个成员都能清楚地理解需求含义，不至于在理解上产生偏差。对客户而言，这样的模型描述最接近真实，容易参与修订，并能以此为测试和验收的依据。制作示意图可以有很多种方式，关键是利用示意图将客户的需求和即将开始设计的系统体现出来。在进行系统分析和程序开发之前，双方对今后要完成的产品就能够有直观的认识，换言之，就是在产品还没有真正进入开发阶段的时候，双方就对工作的结果达成统一的意见，这将大大地减轻需求变更所带来的困扰，同时客户更容易地参与到项目的开发过程中。
4.3 需求分析要共同参与各施其职
项目经理、系统分析员、开发经理、交互设计师、测试人员、文档人员包括客户代表都应该看需求分析，并进行共同讨论，达成一致意见。参与项目开发的人员都应该对这份需求有统一清晰的认识，并根据自己的工作对需求提出意见，通过与客户的沟通修订，最终确定项目实现的目标。这样可以尽量避免业务人员与开发人员、承建方和客户方之间发生不必要的纠纷。
例如：项目经理通过需求分析才能组建所需要的团队包括配置工作环境，制定开发周期;开发周期的限制和功能上的要求可能会影响到程序员采用什么样的语言和工具进行编写;操作用户的技能水平将影响到交互设计师进行前台设计时做到什么样的精度;界面设计人员根据项目的性质和定位确定表现方式;测试人员了解测试环境和条件后才能对项目质量进行跟踪和检测。
4.4 将需求变更置于可控状态
需求的变更几乎是不可避免的，也许是出自客户的遗漏，也可能是在开发过程中被激发出来的。如何以可控的方式管理网站项目需求的变更，对于项目的顺利进行有着重要的意义。如果匆匆忙忙地完成用户调研与分析，则往往意味着不稳定的需求。所以需求管理要保证需求分析各个活动都得到了充分的执行。
为了将变更及时反馈到项目的各个角色中，做好需求变更日志就显得非常重要。在需求分析后面附上变更日志，并将修改后的需求分析制作成新版本，保留每次更改过的版本，而不是覆盖，这样就比较容易地跟踪到需求变更过程中所带来的工作调整。在新版本的需求分析中，将变更部分用特殊方式表示出来，并在日志中记录变更明细。
4.5 评审需求文档
需求文档完成后，需要经过正式评审，以便作为下一阶段工作的基础。一般的评审分为用户评审和同行评审两类。用户和开发方对于软件项目内容的描述，是以需求规格说明书作为基础的;用户验收的标准则是依据需求规格说明书中的内容来制订，所以评审需求文档时用户的意见是第一位的。而同行评审的目的，是在软件项目初期发现那些潜在的缺陷或错误，避免这些错误和缺陷遗漏到项目的后续阶段。
5 总结
随着互联网的飞速发展，Web技术应用日益广泛，网站的规模和复杂性不断增加，网站项目的设计和开发进入了需要强调流程和分工的时代，软件工程方法将越来越多地介入到网站项目的设计和开发中。建立规范的、有效的、健壮的开发机制，特别是打好网站项目管理的基石，强化项目的需求分析，将有利于高效、高速、高质量地完成开发任务。
文章来源于领测软件测试网 https://www.ltesting.net/
