下载文档原格式
1.1跟我学软件系统需求工程——如何获得软件系统的用户需求在本单元中希望重点了解和掌握什么是用户需求，需求的表达形式，如何获取用户需求，如何细分需求，同时在此阶段所应该形成的制品；另外也应该掌握如何采用用例图（Use Case）对用户的需求进行建模，以及Use Case方法最主要的优点。
1.1.1需求工程1、需求工程（1）需求工程结构图（2）需求开发和需求管理的流程其中，需求变更控制是指依据“变更申请－审批－更改－重新确认”的流程处理需求的变更，确保需求的变更不会失去控制而导致项目发生混乱。
1.1.2如何获得用户需求1、什么是用户需求（1）关于用户需求1)它主要是说明系统所必须符合的条件或者应该具备的的功能，也即它用来描述系统应该和不应该做什么也即决定本系统应该有什么功能，从而开发者和用户可以创建一个初始化的商业联系。
2)重点在是应该做什么，而不是应该如何做。
3)需求最根本的挑战在于：寻找、交流并记录什么是真正需要的，并能够向用户和开发团队讲解。
（2）一个关于影响项目进展的因素的研究如下图（Jim Johnson 1994 Chaos:Charting the Seas of Information Technology. Published Report .The Standish Group）可见37%的问题都与需求有关，这就需要“需求开发”和“需求管理”。
（3）“需求管理”的两种方法●瀑布式在项目的第一阶段，在任何设计和实现工作之前，尽可能的推敲，把需求完全定义清楚，并把它稳定下来，并且实际开发前冻结需求，但历史证明这种方式是失败的，在项目很大的时候，冻结需求几乎没有可能。
●迭代式用一种条理化的方法来寻找、记录、组织和跟踪不断变化的需求。
这里的关键是“不断变化”这个词，把需求变化作为项目进展的不断驱动力，另一个重要的词是“寻找”，可以通过写出用例和召开需求研讨会等手段巧妙的得出需求。
整个问题都来自于，用户往往对自己的愿望并不清晰，需求会不断的变化。
需求分析概述—需求获取及用例使用需求获取(requirement elicitation)是需求工程的主体。
对于所建议的软件产品，获取需求是一个确定和理解不同用户类的需要和限制的过程。
获取用户需求位于软件需求三个层次的中间一层。
业务需求决定用户需求，它描述了用户利用系统需要完成的任务。
从这些任务中，分析者能获得用于描述系统活动的特定的软件功能需求，这些系统活动有助于用户执行他们的任务。
需求获取是在问题及其最终解决方案之间架设桥梁的第一步。
获取需求的一个必不可少的结果是对项目中描述的客户需求的普遍理解。
一旦理解了需求，分析者、开发者和客户就能探索出描述这些需求的多种解决方案。
参与需求获取者只有在他们理解了问题之后才能开始设计系统，否则，对需求定义的任何改进，设计上都必须大量的返工。
把需求获取集中在用户任务上—而不是集中在用户接口上—有助于防止开发组由于草率处理设计问题而造成的失误。
需求获取、分析、编写需求规格说明和验证并不遵循线性的顺序，这些活动是相互隔开、增量和反复的。
当你和客户合作时，你就将会问一些问题，并且取得他们所提供的信息(需求获取)。
同时，你将处理这些信息以理解它们，并把它们分成不同的类别，还要把客户需求同可能的软件需求相联系(分析)。
然后，你可以使客户信息结构化，并编写成文档和示意图(说明)。
下一步，就可以让客户代表评审文档并纠正存在的错误(验证)。
这四个过程贯穿着需求分析的整个阶段。
需求获取可能是软件开发中最困难、最关键、最易出错及最需要交流的方面。
需求获取只有通过有效的客户—开发者的合作才能成功。
分析者必须建立一个对问题进行彻底探讨的环境，而这些问题与产品有关。
为了方便清晰地进行交流，就要列出重要的小组，而不是假想所有的参与者都持有相同的看法。
对需求问题的全面考察需要一种技术，利用这种技术不但考虑了问题的功能需求方面，还可讨论项目的非功能需求。
确定用户已经理解：对于某些功能的讨论并不意味着即将在产品中实现它。
一、需求工程的活动1.需求获取：需求获取是从人、文档或者环境中获取需求的过程。
2.需求分析：需求分析的主要工作是通过建模来整合各种信息，从而使人们更好地理解问题。
3.需求规格说明：获取的需求需要被编写成文档，其中项目前景和范围文档记录业务需求、用户需求文档记录用户需求、系统需求文档被写入需求规格说明记录系统需求。
4.需求验证：以需求规格说明为输入，通过符号执行、模拟或快速原型等途径，分析需求规格的正确性和可行性，包含有效性检查，一致性检查，可行性检查和确认可验证性；5.需求管理：支持系统的需求演进，如需求变化和可跟踪性问题。
二、业务需求、用户需求、功能需求、非功能性需求1.业务需求：是抽象层次最高的需求，是系统建立的战略出发点，表现为高层次的目标，它描述了组织为什么要开发系统。
2.用户需求：是执行实际工作的用户对系统所能完成的具体任务的期望，描述了系统能够帮助用户做些什么。
3.功能需求：和系统主要工作相关的需求，即在不考虑物理约束的情况下，用户希望系统所能够执行的活动，这些活动可以帮助用户完成任务。
功能需求主要表现为系统和环境之间的行为交互。
4.非功能性需求：除了功能需求之外的其他4种类别需求，包括性能需求，质量属性，对外接口，约束。
三、项目前景和范围的内容项目前景：1.前景概述：用一个简洁的声明概括系统的长期目标和意图。
2.主要特性：为新产品的每一项主要特性或用户功能进行固定的、唯一的命名或编号，突出其超越原有产品或竞争产品的特性。
3.假设与依赖：记录构思项目和编写前景与范围文档过程中涉众所提出的每一项假设，能够避免可能的混乱以及这种混乱会在将来造成的影响。
项目范围：1.第一版范围：概述计划在产品的第一个版本中实现的主要特性。
描述产品的质量特性，产品依靠这些特性为不同类别的用户提供预期利益。
2.后续版本范围：后续版本能够实现更多的需求和特性，并可完善最初的功能。
3.限制与排除：管理范围蔓延的方法之一是，定义项目包含的需求与不包括的需求之间的界限。
§4 Capturing the requirements第4章需求获取引言：前几章，讨论了系统开发的阶段。
成功的软件开发都有几个关键的步骤，每个软件开发过程模型都包括捕捉软件需求的活动：理解顾客和用户期望这个系统能做什么。
这是整个开发活动的基础，能不能获取用户真正的需求直接决定着项目的成败。
In this chapter, we look at(本章，我们来看一下):●Eliciting requirements from our customers(从顾客诱导需求)●Types of requirements(需求类型)●Notations and methods for capturing(需求获取的符号和方法)●Reviewing requirements to ensure(复查需求以保证质量)●Documenting requirements for use by the design and test teams(文档化需求以供设计和测试团队使用)首先，确切地检查一下需求是什么以及我们如何同用户、顾客一同定义并文档化需求。
4.1 the requirements process(需求过程)(1). what is the requirements?Requirement: a feature of the system or a description of something the system is capable of doing in order to fulfill the system’s purpose. (需求就是系统的特征或者说是系统为完成系统的目标所能做的某事的描述。
)(2). the process of determining the requirements(Shown by Figure 4.1)1) First, we work with our customers to elicit the requirements, by asking questions, demonstrating similar systems, or even developing prototypes (首先我们通过问问题、论证相似系统，甚至开发目标系统的全部或部分原型同顾客共同工作以引出需求。
需求获取的几种简单方法很多做需求的都会遇到这类需求“我想要的是这个。
，我想做的是这个。
，但是却没有具体内容和实际实务支撑只能是一个大致模糊的想法”。
这样就需要需求分析师自己在判断客户的想法以及客户想要的东西的专业上，具现化这些需求（简单的说无中生有）。
遇到这类问题好多人都不知道我该做什么，因为没人会告诉你做什么、怎么做。
在我以往的工作中也经常遇到这类模糊需求，曾经饱受折磨。
在痛苦中学到几个小技巧在此分享。
一弄清楚需求根源与目的弄清楚需求的根源与目的是需求分析工作的核心，所有工作都是围绕这两点展开的。
首先要弄清楚需求是如何产生的，（例如：1 客户提出的需求，这样就会有具体业务支撑。
2 领导想做出一份需求用来说服客户等）。
然后要弄清楚需求的最终目的是什么。
有了上述两项然后制定需求的获取方法。
二如何具现化需求这里我们要说的就是需求的获取方法，我个人有三种小方法学习、创造和实践，一个需求可以采用其中一种方法也可以两到三种方法叠加使用。
下面我们就具体的说一说每一种方法。
1 学习法学习是一种效率最高的方法，我的学习就是查需求相关的资料或直接找需求相关的产品来学习。
当理解了之后在针对自己这边的具体需要来整理和修改需求使其能够适应需求。
学习的重点就是如何理解已有产品的各项功能，并找到其为什么要这样做的目的，这样需求就明确了（即：怎么做，为什么这样做）。
有了模版需求就可以按自己的需求来整理和修改了（注意：一定要弄清楚整体的需求结构，在不是理解非常透彻的情况下不要去改变结构，切记勿断章取义）。
2 创造法创造是最好的一种方法，但是创造需要有基础没有基础是创造不出来的。
首先目的是什么一定要非常明确，就是说要非常明确需求的目标和客户想要的结果（不能有些微的误差、便宜和分歧）。
其次要对业务非常的了解，在目标确定之后要对产生目标的整个业务流程的理解都要达到专业级的，每一个分支每一个步骤都要有理有据，并且需要与需求目的贴切（例如：需求目的是简单便捷，就不能做功能复杂的需求）。
需求获取名词解释需求获取，这四个字听起来好像有点专业，有点高大上，是不是？但其实啊，它就像我们每天找东西吃一样常见和重要！你想想，当你肚子饿了，你得知道自己想吃啥，是热气腾腾的饺子，还是香甜可口的蛋糕？这就是在获取你肚子的“需求”嘛。
需求获取也是这个道理，只不过对象不是我们的肚子，而是各种各样的事情、项目、产品等等。
比如说，一家公司想要开发一款新的手机应用程序。
那首先得搞清楚用户到底想要什么样的功能，什么样的界面设计，什么样的使用体验。
这就需要去获取用户的需求啦。
要是不搞清楚这些，闷头就开始开发，那结果可能就像做了一道没人爱吃的菜，白忙活一场！再比如，学校要组织一场运动会。
那得先知道同学们喜欢哪些项目，是跑步、跳远，还是篮球比赛？还得了解大家希望运动会在什么时候举行，是周末还是工作日？这也是在获取需求呀。
如果不了解清楚，运动会可能就会冷冷清清，没人愿意参加。
需求获取可不是随便问问就行的。
就像医生给病人看病，得仔细询问症状，做各种检查，才能准确诊断病情。
获取需求也得有方法，有技巧。
不能像没头的苍蝇到处乱撞，也不能像个糊涂虫啥都不清楚。
要获取需求，就得学会倾听。
听别人怎么说，怎么想。
可别人家还没说完，你就打断，那能获取到啥准确的需求呀？就像听故事，得让人家把故事讲完，你才能明白到底是怎么回事。
还得学会观察。
有时候，人们说的和做的不一定一样。
比如有人说喜欢跑步，可每次跑步都偷懒，那说不定他不是真的喜欢跑步，只是嘴上说说。
所以得观察观察他们的实际行动，才能更准确地获取需求。
而且，需求是会变化的。
今天喜欢这个，明天可能就喜欢那个了。
就像你今天想吃冰淇淋，明天可能就想吃巧克力了。
所以获取需求不是一锤子买卖，得持续关注，不断更新。
总之，需求获取是个非常重要的工作。
做好了，事情就能顺顺利利，大家都满意；做不好，那可就麻烦啦，浪费时间、浪费精力，还可能一事无成。
所以，咱们可不能小看这需求获取，得用心去做，才能得到想要的结果！。
工程项目需求获取的几种方法及其适用环境摘要：我们知道，需求调研不充分、用户需求描述不完整不准确，轻则影响项目建设的顺利程度，重则影响应用系统的质量，甚至决定项目的成败。
俗话说，“良好的开端是成功的一半”。
需求获取作为项目伊始的活动，是非常重要的。
目前我们所开发的软件项目一般有两种类型：产品项目和工程项目。
产品项目一般都会有充足的时间进行非常仔细的需求调研和分析，而工程项目却并非如此（因为它往往受诸多因素的影响）。
本文拟讨论如何根据工程项目的实际特点，采用合适的方法低成本高效率地获取用户的需求。
关键词：工程项目需求获取方法产品项目一般是根据公司战略和市场需求研发的旨在进行批量出售或推广的项目，工程项目一般是根据与用户签定的合同研发的旨在满足特定用户需求的项目。
笔者所开发和管理的项目主要是工程项目，在项目的建设过程中，感觉到最头疼的是项目需求的获取；我们往往要花相当大的精力在需求获取和需求确认上，然而有时效果还很不理想。
经过几年时间的项目实践，我们逐步总结出针对不同项目情况所适合采用的需求获取方法，这些方法能大大提高需求获取的效率。
现总结之，愿与大家分享。
我们知道，一个工程项目，如果从开发方（即承建方）和用户方（即建设方）对需求的清楚程度来分，大致可以分为如下四种：开发方和用户方都清楚项目需求、开发方不清楚项目需求但用户方清楚、开发方和用户方都不清楚项目需求、开发方清楚项目需求但用户方不清楚。
针对这四种类型的项目，我总结出四种对应的需求获取方法：问卷调查法、会议讨论法、界面原型法和可运行原型系统法。
以下逐一解析之。
一、问卷调查法所谓“问卷调查法”，是指开发方就用户需求中的一些个性化的、需要进一步明确的需求（或问题），通过采用向用户发问卷调查表的方式，达到彻底弄清项目需求的一种需求获取方法。
这种方法适合于开发方和用户方都清楚项目需求的情况。
因为开发方和建设方都清楚项目的需求，则需要双方进一步沟通的需求（或问题）就比较少，通过采用这种简单的问卷调查方法就能使问题得到较好的解决。
