获取信息是很重要的。
　　（二）、定义系统
　　解释涉众需求，并整理为对要构建系统的意义明确的说明。在定义初期，决定需求的构
成、文档格式、语言规范、需求等级、请求优先级和预计工作量、技术和管理风险以及系统规模
等。定义活动还包括与最关键的涉众请求直接联系的初期原型和设计模型。
　　（三）、管理系统规模
　　管理系统规模是一个持续不断的活动，需要迭代式和递增式开发，将项目细分为更易
于管理的若干个小部分。使用需求属性作为协商应包含需求的基础，项目推介人能代表组织
拒绝那些超出可用资源规模的变更，也应有相应能力扩展资源以适应扩大的规模。
　　（四）、改进系统定义
　　包括两个重要的考虑事项：制定更详细的高层系统说明和验证系统是否符合涉众需要
是否按说明运行。说明通常是项目团队的重要参考材料，在制定说明时一定要考虑受众。
　　（五）、管理变更的需求
　　能否适应变更需求是评测团队的涉众敏感度和运作灵活性的一个尺度。变更不是敌人，
而没有管理的变更才是真正的敌人。一个需求的变更对其他需求可能有影响，管理需求变更
包括这样一些活动：
　　设立基线、追踪每个需求的历史、确定哪些依赖关系值得追踪、在相关项之间建立可追踪
关系以及维护版本控制等，建立变更控制或批准流程也很重要。

七、

评审需求以保证需求的质量
要保证需求的质量必须确认需求的标准，并对其进行评审。需求的标准包括其正确性、

一致性、无二义性、完备性、相关性、可测试性、可跟踪性等几个方面。依据软件工程中使用的
定义技术，上面的其中一些检查可能能够自动化的进行。我们重点讨论确认需求的技术中最
常见的评审。在评审中，来自开发人员的代表和来自客户职员的代表各自检查需求文档，然
后开会讨论识别出的问题。客户代表包含那些将操作系统的人、准备输入系统的人、以及将使
用系统输出的人。我们则提供设计小组、测试小组和过程小组的相关人员。在评审过程中有以
下工作是比较重要的：

、评审系统规定的目的和目标。

、将需求和目标、目的相比较，已确定所有的需求都是必要的。

、评审系统将要运行的环境，检查我们提议的系统与其他系统之间的接口。

、客户代表评审信息流和提议的功能。以证实需求正确的反映了客户的需求的意图。

、如果在开发过程中或系统实际运行过程中存在任何风险，我们可以评价并在文档中

记录这些风险，讨论和比较各种可选方案，并就将要使用的方案达成某种一致。

、我们可以就测试系统进行讨论：随着需求的增长和变化，如何重新确认需求等问题

总之，软件需求分析方法和工具的使用，对我们软件开发过程影响是很深远的，选用高效
能的正确的方法与工具，可以使我们的软件更加正确地反映现实需求，更加具有可用性、可
扩展性和可维护性；降低了软件项目的风险。

　　软件需求分析中的关键就是展开分析、发现问题、征服问题。所有的一切都是为了能够将
软件中的错误和漏洞在需求分析和需求工程阶段发现并解决，这样才能使软件开发的成本
收益比达到最大，使得软件在其生命周期中的维护费用降到最低，这也是我进行软件需求