上一期，我们介绍了需求分析五个步骤中的前两个步骤（获取用户需求、分析用户需求），本期将继续介绍后三个步骤（编写需求文档、评审需求文档、管理需求），并与大家讨论相关实践问题。
1、编写需求文档
需求文档可以使用自然语言或形式化语言来描述，还可以添加图形的表述方式和模型表征的方式。需求文档应该包括用户的所有需求（功能性需求和非功能性需求）。
2、评审需求文档
需求文档完成后，需要经过正式评审，以便作为下一阶段工作的基础。一般的评审分为用户评审和同行评审两类。用户和开发方对于软件项目内容的描述，是以需求规格说明书作为基础的；用户验收的标准则是依据需求规格说明书中的内容来制订，所以评审需求文档时用户的意见是第一位的。而同行评审的目的，是在软件项目初期发现那些潜在的缺陷或错误，避免这些错误和缺陷遗漏到项目的后续阶段。
3、管理需求
图1 需求变更流程
需求的变更是不可避免的，如何以可控的方式管理软件的需求，对于项目的顺利进行有着重要的意义。如果匆匆忙忙地完成用户调研与分析，则往往意味着不稳定的需求。所以需求管理要保证需求分析各个活动都得到了充分的执行。对于需求变更的管理，则主要使用需求变更流程和需求跟踪矩阵的管理方式。需求变更流程和需求跟踪矩阵分别如图1和图2所示。
图2 需求跟踪矩阵
常见问题及建议
Q、客户与最终用户的区别是什么？
A、可以借助图3来说明它们之间的区别。
图3 需求获取渠道示意图
软件需求来自系统工程与客户两个方面，其中客户是主要的需求提供者（系统工程需求也来自于客户）。客户需要搜集其最终用户的需求并考虑自身的需求，然后再提供给开发方。假如客户并未去认真搜集最终用户的需求，开发方便需要做到这一点，因为系统最终要满足最终用户的需求。
Q、如何进行用户访谈？
A、首先，一定要事先确定访谈的目的和提纲。其次，因为用户往往并不知道应该提供哪些方面的需求，所以需要开发人员引导。
Q、用户访谈内容是什么？
A、首先，请用户描述他们如何完成自己当前的工作，并与用户一起抽象出一个工作流程或工作模型。然后，在得到用户的认可后，向用户解释自己是怎样来实现这些功能的，并说明哪些环节可以用自动化方式实现等。
Q、采用哪一种方式做需求分析最好？
A、不同的需求分析有不同的特点。还没有哪一种方法可以完全替代别的方法，否则，现在就不会存在不同的需求建模方式了。一般来说，可以使用DFD＋ERD来描述那些功能层次比较清晰的需求；而USE CASE则适于描述功能结构复杂的需求。做需求分析的目的是为了建立需求的模型，不同的子系统有可能使用不同的建模方法。
Q、怎样做原型，原型的目的是什么？
A、通常使用原型分析方法来帮助开发方进一步获取用户需求或让用户确认需求。开发方往往先向用户提供一个可视界面作为原型，并在界面上布置必要的元素以演示用户所需要的功能。可以使用第四代语言（例如Visual Basic、Delphi等）来快速生成用户界面，也可以使用FrontPage等网页制作工具来生成用户可视的页面流。
原型的目的往往是获取需求。但有时也使用原型的方式来验证关键技术或技术难点。对于技术原型，界面则往往被忽略掉。