需求获取

属于软件工程中的一部分

需求获取，属于软件工程中的一部分，包括需求来源和获取需求的技术。它是软件设计的第一阶段，其本质主要是人的活动，涉及软件设计人员如何与客户建立有效的沟通。

简述

当软件项目以招标方式确定开发单位时，“标书”往往可以作为初步的需求陈述。用户需求陈述可能由用户单方面写出。也可能由系统分析员配合用户共同写出。需求陈述的内容包括问题范围、功能需求、应用环境及假设条件等。此外。对采用的软件工程标准、模块构造准则、将来可能做的扩充及可维护性要求等方面的内容，也都要做适当描述。总之，需求陈述应该阐明“做什么”而不是“怎样做”。它应该描述用户需求而不是提出解决问题的方法；应该指出哪些是系统必要的属性，哪些是可选的属性；应该避免对设计策略施加过多的约束；也不要描述系统的内部结构，否则会限制系统实现的灵活性。

需求获取是开发者、用户之间为了定义新系统而进行的交流。需求获取是需求分析的前提，需求获取是获得系统必要的特征，或者是获得用户能接受的、系统必须满足的约束。由于用户是其各自领域的专家，对开发的系统应该如何做，已经有了总体考虑，但这些用户通常不具备软件开发方面的技术和经验。而与此相对，开发者在软件开发方面具有丰富的经验，但了解用户和用户的领域相关知识较少。如果双方所理解的领域内容在系统分析、设计过程出现问题，通常在开发过程的后期才会被发现，将会使整个系统交付延迟，或上线的系统无法或难以使用，最终所开发的系统以失败告终，导致出现严重的软件危机。例如，遗漏的需求(丢失了系统必须支持的功能)或错误的需求(不正确的功能描述或不可用的用户界面)。需求获取的目标，就是为了提高开发者与用户之间沟通的能力，进而构造应用系统的领域模型。

在面向对象的方法中，开发者选择用户易于理解的表达方式，通常使用用例来获取软件的需求。用例通过描述“参与者”和“系统”之间的交互来描述系统的行为。用例方法最主要的优点在于它是用户导向的，用户可根据自己所对应的用例来不断细化自己的需求。此外，使用用例还可方便地得到系统功能的测试用例。

步骤

对于不同规模及不同类型的项目，需求获取的过程不会完全一样。下面给出需求获取过程的参考步骤。

1．开发高层的业务模型

所谓应用领域，即目标系统的应用环境，如银行、电信公司等。如果系统分析员对该领域有了充分了解，就可以建立一个业务模型，描述用户的业务过程，确定用户的初始需求。然后通过迭代，更深入地了解应用领域，之后再对业模型进行改进。

2．定义项目范围和高层需求

在项目开始之前，应当在所有利益相关方面建立一个共同的愿景，即定义项目范围和高层需求。项目范同描述系统的边界以眨与外部事物(包括组织、人、硬件设备、其他软件等)的关系。高层需求不涉及过多的细节，主要表示系统需求的概貌。

3．识别用户类和用户代表

需求获取的主要目标是理解用户需求，因而客户的参与是生产出优质软件的关键因素。因此，首先确定目标系统的不同用户类型；然后挑选出每一类用户和其他利益相关方的代表，并与他们一起工作；最后确定谁是项目需求的决策者。

用户类可以是人，也可以是与系统打交道的其他应用程序或硬件部件。如果是其他应用程序或硬件部件，则需要以熟悉这此系统或硬件的人员作为用户代表。

4．获取具体的需求

确定了项目范围和高层需求，并确定了用户类及用户代表后，就需要获取更具体、完整和详细的需求。

5．确定目标系统的业务工作流

具体到当前待开发的应用系统，确定系统的业务工作流和主要的业务规则。采取需求调研的方法获取所需的信息。例如，针对信息系统的需求调研方法如下。

(1)调研用户的组织结构、岗位设置、职责定义，从功能上区分有多少个子系统，划分系统的大致范围，明确系统的目标。

(2)调研每个子系统的工作流程、功能与处理规则，收集原始信息资料。用数据流来表示物流、资金流、信息流三者的关系。

(3)时凋研内容事先准备，针对不同管理层次的用户询问不同的问题，列出问题清单。将操作层、管理层、决策层的需求既联系又区分开来，形成一个需求的层次。

6．需求整理与总结

必须对上面步骤取得的需求资料进行整理和总结，确定对软件系统的综合要求，即软件的需求。并提出这些需求实现条件，以及需求应达到的标准。这些需求包括功能需求、性能需求、环境需求、可靠性需求、安全保密需求、用户界面需求、资源使用需求、软件成本消耗与开发进度需求等。

方法

1．用户面谈

这是一种理解商业功能和商业规则的最有效方法。面谈过程需要认真的计划和准备。其基本要点如下。

(1)面谈之前：确立面谈目的；确定要包括的相关用户；确定参加会议的项目小组成员；建立要讨论的问题和要点列表；复查有关文档和资料；确立时间和地点；通知所有参加者有关会议的目的、时间和地点。

(2)进行面谈时：衣着得体；准时到达、寻找异常和错误情况；深入调查细节；详细记录；指出和记录下未回答条目和未解决问题。

(3)面谈之后：复查笔记的准确性、完整性和可理解性；把所收集的信息转化为适当的模型和文档；确定需要进一步澄清的问题域；适当的时候向参加会议的每一个人发一封感谢信。

2．需求专题讨论会

需求专题讨论会也许是需求获取的一种最有力的技术。项目主要风险承担人在短暂而紧凑的时间段内集中在一起，一般为一或两天，与会者可以在应用需求上达成共识、对操作过程尽快取得统一意见。参加会议的人员包括主持人、用户、技术人员、项目组人员。

专题讨论会具有以下优点。

(1)协助建立一支高效的团队，围绕项目成功的目标；

(2)所有的风险承担人都畅所欲言；

(3)促进风险承担人和开发闭队之间达成共识；

(4)揭露和解决那些妨碍项同成功的行政问题；

(5)能够很快地产生初步的系统定义。

3．问卷调查

可用于确认假设和收集统计倾向数据，问卷需要快速叫答，允许匿名方式。存在问题的是：相关的问题不能事先决定；问题背后的假设对答案造成偏颇。如“这符合你的期望吗?”难以探索一些新领域：难以继续用户的模糊响应。在完成最初的面谈和分析后，问卷调查可作为一项协作技术收到良好的效果。

4．现场观察

掌握用户如何实际使用一个系统以及到底用户需要哪些信息，最好的办法是亲自观察用户是如何完成实际工作的。一般方法如下。

(1)对办公室进行快速浏览，了解布局、设备要求和使用、工作流总体情况；

(2)安排几个小时观察用户是如何。实际完成他们的工作的，理解用户实际使用计算机系统和处理事务的细节；

(3)像用户一样接受训练和做实际工作，发现关键问题和瓶颈。

5．原型化方法

一个软件原型是所提出的新产品的部分实现，帮助开发人员、用户以及客户更好地理解系统的需求，它比开发人员常用的技术术语更易于理解。建立原型可以解决在产品开发的早期阶段需求不确定的问题，用户、经理和其他非技术项目风险承担者发现在确定和开发产品时，原型可以使他们的想象更具体化，如建立基于Web的应用系统原理，使用HTML进行界而设计。

6．基于用例的方法

随着面向对象技术的发展，基于用例的方法任需求获取和建模方面应用越来越广泛。用例建模是以任务和用户为中心的，开发和描述用户需要系统做什么。另外，用例帮助于开发人员理解用户的、业务和应用领域，并可以运用面向对象分析和设计方法将用例转化为对象模型。

用例建模的基本步骤入下。

(1)确定系统的参与者：参与者是与系统交互的外部实体，它既可以是人员也可以是外部系统或硬件设备。

(2)确定场景：场景是对人们利用计算机系统过程做了什么和体验了什么的叙述性描述，它从单个参与者的角度观察系统特性的具体化和非正式的描述。

(3)确定系统用例：用例描述了一个完整的系统事件流程，其重点在于参与者与系统之间的交互而不是内在的系统活动，并对参与者产生存价值的可观测结果。

(4)确定用例之间的关系：在确定出每一个参与者的用例之后，需要将参与者和特定的用例联系起来，最终绘制出系统的用例图。

(5)编写用例描述文档：单纯使用用例图并不能提供用例所具有的全部信息，因此需要使用文字描述那些不能反映在网形上的信息。用例描述是关于角色与系统如何交互的规格说明，要求清晰明确，没有二义性。在描述用例时，应该只注重外部能力，不涉及内部细节。

全国各地天气预报查询

上海市

市辖区

云南省