风险躲在需求的迷雾之后,经理：“我们要建立一套完整的商业管理软件系统，包括商品的进、销、调、存管理，是总部-门店的连锁经营模式。通过通信手段门店自动订货，供应商自动结算，卖场通过扫条码实现销售，管理人员能够随时查询门店商品销售和库存情况。另外，我们也得为政府部门提供关于商品营运的报告。”分析员：“我已经明白这个项目的大体结构框架，这非常重要，但在制定计划之前，我们必须收集一些需求。”经理觉得奇怪：“我不是刚告诉你我的需求了吗？”分析员：“实际上，您只说明了整个项目的概念和目标。这些高层次的业务需求不足以提供开发的内容和时间。我需要与实际将要使用系统的业务人员进行讨论，然后才能真正明白达到业务目标所需功能和用户要求，了解清楚后，才可以发现哪些是现有组件即可实现的，哪些是需要开发的，这样可节省很多时间。”经理：“业务人员都在招商。他们非常忙，没有时间与你们详细讨论各种细节。你能不能说明一下你们现有的系统？”分析员尽量解释从用户处收集需求的合理性：“如果我们只是凭空猜想用户的要求，结果不会令人满意。我们只是软件开发人员，而不是采购专家、营运专家或是财务专家，我们并不真正明白您这个企业内部运营需要做些什么。我曾经尝试过，未真正明白这些问题就开始编码，结果没有人对产品满意。”经理坚持道：“行了，行了，我们没有那么多的时间。让我来告诉您我们的需求。实际上我也很忙。请马上开始开发，并随时将你们的进展情况告诉我。”,优秀的团队遇到糟糕 的需求,需求问题导致的主要后果是返工重复做您认为早已做好的事情。 返工的成本占了总开发成本的30%50，而对于返工的情况，70%80%是因需求错误引起的。 从图可以看出，在项目末期才发现缺陷，对其进行改正的成本要比在缺陷刚产生不久时修改的成本高得多。,镀金问题,开发人员为产品添加了一项需求说明中没有提到的功能，他认为“用户肯定会喜欢的”。这就是所谓的“镀金问题(gold plating)”。 开发人员和需求分析员不应擅自添加特性，应该把创意和备选方案提交给客户，让他们做决定。 要避免镀金问题，就应该追溯每项功能的来源，弄清楚为什么添加该功能。,过于抽象的需求,营销人员或经理经常喜欢只给出一个粗略的说明，他们希望开发人员在开发过程中充实它。 这种方式对研究性项目或需求特别灵活的项目或许管用，但是需要紧密合作的团队，而且仅限于开发小型系统。 大多数情况下，这种做法的结果是使开发人员受挫，让客户失望。,忽略了某类用户,用户所使用的产品特性、产品的使用频率以及用户自身的经验水平不尽相同。 因此，多数产品都拥有不同的用户群。如果一开始没能找出产品的所有重要用户群，就会有某些用户需求得不到满足。确定所有用户群后，还要保证获得各类用户的需求 。,第二部分 需求工程过程,需求工程: 对问题域及需求做调查研究和描述,设计将满足那些需求的解系统的特性并用文档说明. 需求获取 需求分析 规格说明 人机接口 需求验证 需求获取、分析、编写需求规格说明和验证并不遵循线性的顺序，这些活动是相互隔开、增量和反复。,需求开发过程,需求开发是一个迭代的过程,需求工程的推荐方法,列出了近50种方法，分别属于7个类型，它们可以帮助大部分项目开发团队更好地完成他们的需求工作。,知 识 技 能,开发者也应该了解产品应用领域中的基本概念和术语。 培训需求分析员 所有将要成为分析员的团队成员都应该接受需求工程方面的基本培训。 熟练的需求分析员应具备以下特点： 耐心，思维条理性强，有良好的交际和沟通能力，理解产品应用领域，并且掌握丰富的需求工程技术。 对用户代表和管理者进行软件需求培训 参与软件开发的用户应该接受一到两天的需求工程方面的培训。 对开发人员进行应用领域的相关培训 为了帮助开发人员对应用领域有一个基本的理解，可以安排一个研讨课程，内容是客户的业务活动、术语和产品的目标。 创建项目术语表 定义应用领域专业名称的术语表可以减少误解。,需求获取,需求获取(requirement elicitation)是需求工程的主体。对于所建议的软件产品，获取需求是一个确定和理解不同用户类的需要和限制的过程。 需求获取可能是软件开发中最困难、最关键、最易出错及最需要交流的方面。需求获取只有通过有效的客户开发者的合作才能成功。 需求获取是在问题及其最终解决方案之间架设桥梁的第一步。获取需求的一个必不可少的结果是对项目中描述的客户需求的普遍理解。,需求获取,第1章讨论了需求的三个层次：业务，用户和功能。在项目中它们在不同的时间来自不同的来源，也有着不同的目标和对象，并需以不同的方式编写成文档。业务需求（或产品视图和范围）不应包括用户需求（或使用实例），而所有的功能需求都应该源于用户需求。同时你也需要获取非功能需求，如质量属性。 1) 确定需求开发过程 确定如何组织需求的收集、分析、细化并核实的步骤，并将它编写成文档。对重要的步骤要给予一定指导，这将有助于分析人员的工作，而且也使收集需求活动的安排和进度计划更容易进行。 2) 编写项目视图和范围文档 项目视图和范围文档应该包括高层的产品业务目标，所有的使用实例和功能需求都必须遵从能达到的业务需求。项目视图说明使所有项目参与者对项目的目标能达成共识。而范围则是作为评估需求或潜在特性的参考。 3) 将用户群分类并归纳各自特点 为避免出现疏忽某一用户群需求的情况，要将可能使用产品的客户分成不同组别。他们可能在使用频率、使用特性、优先等级或熟练程度等方面都有所差异。详细描述出它们的个性特点及任务状况，将有助于产品设计。,4) 选择每类用户的产品代表 5) 建立起典型用户的核心队伍 6) 让用户代表确定使用实例 从用户代表处收集他们使用软件完成所需任务的描述使用实例，讨论用户与系统间的交互方式和对话要求。在编写使用实例的文档时可采用标准模版，在使用实例基础上可得到功能需求。 7) 召开应用程序开发联系（ J A D）会议 应用程序开发联系（ J A D）会议是范围广的、简便的专题讨论会（ w o r k s h o p），也是分析人员与客户代表之间一种很好的合作办法，并能由此拟出需求文档的底稿。该会议通过紧密而集中的讨论得以将客户与开发人员间的合作伙伴关系付诸于实践,8) 分析用户工作流程观察用户执行业务任务的过程 9) 确定质量属性和其它非功能需求 10) 通过检查当前系统的问题报告来进一步完善需求 11) 跨项目重用需求。 调查用户任务可能遇到的变更，或者用户需要使用系统其它可能的方式。想像你自己在学习用户的工作，你需要完成什么任务？你有什么问题？从这一角度来指导需求的开发和利用。还有，探讨例外的情况：什么会妨碍用户顺利完成任务？对系统错误情况的反映，用户是如何想的？询问问题时，以“还有什么能” ,”当时，将会发生什么”“你有没有曾经想过” ,“有没有人曾经”为开头。记下每一个需求的来源，这样向下跟踪直到发现特定的客户。,需求分析,分析:通过对问题域的研究,获得对该领域特性及存在于其中(需要解决)的问题特性的透彻理解并用文档说明. 需求分析（ requirement analysis）包括提炼、分析和仔细审查已收集到的需求，以确保所有的风险承担者都明白其含义并找出其中的错误、遗漏或其它不足的地方。分析员通过评价来确定是否所有的需求和软件需求规格说明都达到了优秀需求说明的要求。分析的目的在于开发出高质量和具体的需求，这样你就能作出实用的项目估算并可以进行设计、构造和测试. 通常，把需求中的一部分用多种形式来描述，如同时用文本和图形来描述。分析这些不同的视图将揭示出一些更深的问题，这是单一视图无法提供的。分析还包括与客户的交流以澄清某些易混淆的问题，并明确哪些需求更为重要。其目的是确保所有风险承担者尽早地对项目达成共识并对将来的产品有个相同而清晰的认识。,1)绘制系统关联图 这种关联图是用于定义系统与系统外部实体间的界限和接口的简单模型。同时它也明确了通过接口的信息流和物质流。 2) 创建用户接口原型 当开发人员或用户不能确定需求时，开发一个用户接口原型一个可能的局部实现这样使得许多概念和可能发生的事更为直观明了。用户通过评价原型将使项目参与者能更好地相互理解所要解决的问题。注意要找出需求文档与原型之间所有的冲突之处。 3) 分析需求可行性 在允许的成本、性能要求下，分析每项需求实施的可行性，明确与每项需求实现相联系的风险，包括与其它需求的冲突，对外界因素的依赖和技术障碍。 4) 确定需求的优先级别 应用分析方法来确定使用实例、产品特性或单项需求实现的优先级别。以优先级为基础确定产品版本将包括哪些特性或哪类需求。当允许需求变更时，在特定的版本中加入每一项变更，并在那个版本计划中作出需要的变更。,5) 为需求建立模型 需求的图形分析模型是软件需求规格说明极好的补充说明。它们能提供不同的信息与关系以有助于找到不正确的、不一致的、遗漏的和冗余的需求。这样的模型包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图。 6) 创建数据字典 数据字典是对系统用到的所有数据项和结构的定义，以确保开发人员使用统一的数据定义。在需求阶段，数据字典至少应定义客户数据项以确保客户与开发小组是使用一致的定义和术语。分析和设计工具通常包括数据字典组件。 7) 使用质量功能调配 质量功能调配( Q F D）是一种高级系统技术，它将产品特性、属性与对客户的重要性联系起来。该技术提供了一种分析方法以明确那些是客户最为关注的特性。 期望需求；普通需求；兴奋需求.,规格说明,无论你的需求从何而来，也不管你是怎样得到的，你都必须用一种统一的方式来将它们编写成可视文档。业务需求要写成项目视图和范围文档。用户需求要用一种标准使用实例模板编写成文档。而软件需求规格说明（ requirement specification）则包含了软件的功能需求和非功能需求。你必须为每项需求明确建立标准的惯例，并确定在S R S中采用任何惯例，以确保S R S的统一风格，同时读者也会明白怎样解释它。,1)采用S R S模板 在你的组织中要为编写软件需求文档定义一种标准模板。该模板为记录功能需求和各种其它与需求相关的重要信息提供了统一的结构。 2) 指明需求的来源 为了让所有项目风险承担者明白S R S中为何提供这些功能需求，要都能追溯每项需求的来源，这可能是一种使用实例或其它客户要求，也可能是某项更高层系统需求、业务规范、政府法规、标准或别的外部来源。 3) 为每项需求注上标号 制定一种惯例来为S R S中的每项需求提供一个独立的可识别的标号或记号。这种惯例应当很健全，允许增加、删除和修改。作了标号的需求使得需求能被跟踪，记录需求变更并为需求状态和变更活动建立度量。 4) 记录业务规范 业务规范是指关于产品的操作原则，比如谁能在什么情况下采取什么动作。将这些编写成S R S中的一个独立部分，或一独立的业务规范文档。某些业务规范将引出相应的功能需求；当然这些需求也应能追溯相应业务规范。 5) 创建需求跟踪能力矩阵 建立一个矩阵把每项需求与实现、测试它的设计和代码部分联系起来。这样的需求跟踪能力矩阵同时也把功能需求和高层的需求及其它相关需求联系起来了。在开发过程中建立这个矩阵，而不要等到最后才去补建。,人机接口设计,人机接口HMI 面向人的或其他的系统,需求验证,验证是为了确保需求说明准确、完整地表达必要的质量特点。而且能够满足客户的需要。 审查需求文档 对需求文档进行正式审查是保证软件质量的有效手段之一。 测试需求 根据用户需求推导出功能测试用例，以便记录产品在特定条件下应有的行为。 定义合格标准 让用户描述决定产品是否满足他们的需求并适合使用的标准。,1) 审查需求文档 2) 以需求为依据编写测试用例 3) 编写用户手册 4) 确定合格的标准,需 求 管 理,有了项目的初步需求，就必须处理好开发过程中不可避免的来自客户、管理层、营销部门、开发团队以及其他群体的变更请求。 定义需求变更控制过程 建立一个用于提议、分析和解决需求变更的过程。 成立变更控制委员会 可授权