需求获取--论文素材
需求的三个层次：业务，用户和功能。在项目中它们在不同的时间来自不同的来源，也有着不同的目标和对象，并需以不同的方式编写成文档。业务需求（或产品视图和范围）不应包括用户需求（或使用实例），而所有的功能需求都应该源于用户需求。同时你也需
要获取非功能需求，如质量属性。我将在随后列出相关主题的详细内容：
------确定需求开发过程。
------编写项目视图和范围文档。
------将用户群分类并归纳其特点，为每个用户类选择产品代表（product champion）。
------让用户代表确定使用实例。
------确定质量属性和其它非功能需求。
1) 确定需求开发过程 确定如何组织需求的收集、分析、细化并核实的步骤，并将它编写成文档。对重要的步骤要给予一定指导，这将有助于分析人员的工作，而且也使收集
需求
活动的安排和进度计划更容易进行。
2) 编写项目视图和范围文档 项目视图和范围文档应该包括高层的产品业务目标，所有的使用实例和功能需求都必须遵从能达到的业务需求。项目视图说明使所有项目参与者
对项
目的目标能达成共识。而范围则是作为评估需求或潜在特性的参考。
3) 将用户群分类并归纳各自特点 为避免出现疏忽某一用户群需求的情况，要将可能使用产品的客户分成不同组别。他们可能在使用频率、使用特性、优先等级或熟练程度等
方面
都有所差异。详细描述出它们的个性特点及任务状况，将有助于产品设计。
4) 选择每类用户的产品代表 为每类用户至少选择一位能真正代表他们需求的人作为那一类用户的代表并能作出决策。这对于内部信息系统的开发是最易实现的，因为此时，
用户
就是身边的职员。而对于商业开发，就得在主要的客户或测试者中建立起良好的合作关系，并确定合适的产品代表。他们必须一直参与项目的开发而且有权作出决策。
5) 建立起典型用户的核心队伍 把同类产品或你的产品的先前版本用户代表召集起来，从他们那里收集目前产品的功能需求和非功能需求。这样的核心队伍对于商业开发尤为有用，因为你拥有一个庞大且多样的客户基础。与产品代表的区别在于，核心队伍成员
通常没有决定权。
6) 让用户代表确定使用实例 从用户代表处收集他们使用软件完成所需任务的描述—使用实例，讨论用户与系统间的交互方式和对话要求。在编写使用实例的文档时可采用标
准模
版，在使用实例基础上可得到功能需求。
7) 召开应用程序开发联系会议 应用程序开发联系（J A D）会议是范围广的、简便的专题讨论会（w o r k s h o p），也是分析人员与客户代表之间一种很好的合作办法，并能由此拟出需求文档的底稿。该会议通过紧密而集中的讨论得以将客户与开发人员间的合
作伙伴关系付诸于实践（ Wood and Silver 1995）。
8) 分析用户工作流程 观察用户执行业务任务的过程。画一张简单的示意图（最好用数据流图）来描绘出用户什么时候获得什么数据，并怎样使用这些数据。编制业务过程流
程文
档将有助于明确产品的使用实例和功能需求。你甚至可能发现客户并不真地需要一个
全新的软件系统就能达到他们的业务目标（ McGraw and Harbison 1997）。
9) 确定质量属性和其它非功能需求 在功能需求之外再考虑一下非功能的质量特点，这会使你的产品达到并超过客户的期望。这些特点包括性能、有效性、可靠性、可用性等，
而
在这些质量属性上客户提供的信息相对来说就非常重要了。
10) 通过检查当前系统的问题报告来进一步完善需求 客户的问题报告及补充需求为新产品或新版本提供了大量丰富的改进及增加特性的想法，负责提供用户支持及帮助的人
能为收集需求过程提供极有价值的信息。
11) 跨项目重用需求 如果客户要求的功能与已有的产品很相似，则可查看需求是否有
足够的灵活性以允许重用一些已有的软件组件。
需求获取--论文素材
需求的三个层次：业务，用户和功能。在项目中它们在不同的时间来自不同的来源，也有着不同的目标和对象，并需以不同的方式编写成文档。业务需求（或产品视图和范围）不应包括用户需求（或使用实例），而所有的功能需求都应该源于用户需求。同时你也需
要获取非功能需求，如质量属性。我将在随后列出相关主题的详细内容：
------确定需求开发过程。
------编写项目视图和范围文档。
------将用户群分类并归纳其特点，为每个用户类选择产品代表（product champion）。
------让用户代表确定使用实例。
------确定质量属性和其它非功能需求。
1) 确定需求开发过程 确定如何组织需求的收集、分析、细化并核实的步骤，并将它编写成文档。对重要的步骤要给予一定指导，这将有助于分析人员的工作，而且也使收集
需求
活动的安排和进度计划更容易进行。
2) 编写项目视图和范围文档 项目视图和范围文档应该包括高层的产品业务目标，所有的使用实例和功能需求都必须遵从能达到的业务需求。项目视图说明使所有项目参与者
对项
目的目标能达成共识。而范围则是作为评估需求或潜在特性的参考。
3) 将用户群分类并归纳各自特点 为避免出现疏忽某一用户群需求的情况，要将可能使用产品的客户分成不同组别。他们可能在使用频率、使用特性、优先等级或熟练程度等
方面
都有所差异。详细描述出它们的个性特点及任务状况，将有助于产品设计。
4) 选择每类用户的产品代表 为每类用户至少选择一位能真正代表他们需求的人作为那一类用户的代表并能作出决策。这对于内部信息系统的开发是最易实现的，因为此时，
用户
就是身边的职员。而对于商业开发，就得在主要的客户或测试者中建立起良好的合作关系，并确定合适的产品代表。他们必须一直参与项目的开发而且有权作出决策。
5) 建立起典型用户的核心队伍 把同类产品或你的产品的先前版本用户代表召集起来，从他们那里收集目前产品的功能需求和非功能需求。这样的核心队伍对于商业开发尤为有用，因为你拥有一个庞大且多样的客户基础。与产品代表的区别在于，核心队伍成员
通常没有决定权。
6) 让用户代表确定使用实例 从用户代表处收集他们使用软件完成所需任务的描述—使用实例，讨论用户与系统间的交互方式和对话要求。在编写使用实例的文档时可采用标
准模
版，在使用实例基础上可得到功能需求。
7) 召开应用程序开发联系会议 应用程序开发联系（J A D）会议是范围广的、简便的专题讨论会（w o r k s h o p），也是分析人员与客户代表之间一种很好的合作办法，并能由此拟出需求文档的底稿。该会议通过紧密而集中的讨论得以将客户与开发人员间的合
作伙伴关系付诸于实践（ Wood and Silver 1995）。
8) 分析用户工作流程 观察用户执行业务任务的过程。画一张简单的示意图（最好用数据流图）来描绘出用户什么时候获得什么数据，并怎样使用这些数据。编制业务过程流
程文
档将有助于明确产品的使用实例和功能需求。你甚至可能发现客户并不真地需要一个
全新的软件系统就能达到他们的业务目标（ McGraw and Harbison 1997）。
9) 确定质量属性和其它非功能需求 在功能需求之外再考虑一下非功能的质量特点，这会使你的产品达到并超过客户的期望。这些特点包括性能、有效性、可靠性、可用性等，
而
在这些质量属性上客户提供的信息相对来说就非常重要了。
10) 通过检查当前系统的问题报告来进一步完善需求 客户的问题报告及补充需求为新产品或新版本提供了大量丰富的改进及增加特性的想法，负责提供用户支持及帮助的人
能为收集需求过程提供极有价值的信息。
11) 跨项目重用需求 如果客户要求的功能与已有的产品很相似，则可查看需求是否有
足够的灵活性以允许重用一些已有的软件组件。