第5章 软件项目需求分析阶段的知识和管理

单击此处编辑母版标题样式,*,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,第,5,章,软件项目需求分析阶段的知识和管理,本章要点：,需求分析是软件项目的立足之本,需求分析的工作内容,需求分析阶段的团队组织,需求分析阶段的项目管理,需求获取的方法和特点,需求分析方法和建模工具,需求分析阶段性成果和考核依据,软件需求分析阶段工作的基本任务就是要准确回答“用户真正需要一个什么样的软件系统,?,该软件系统必须完成什么功能,?”,。,需求分析阶段将对软件系统提出完整、准确、清晰、具体的要求。,5.1,需求分析是软件项目的立足之本,需求分析是整个软件项目开展工作的基础，需求分析质量的好坏，直接关系到软件项目交付成果的客户满意度，甚至整个项目的成败。如果需求分析工作做的不扎实，无论设计阶段工作完成得如何出色、软件编码质量如何高，其结果将只会给用户带来失望，给开发者带来失败的苦恼。,5.2,需求分析的工作内容,5.2.1,需求分析的目标、内容和任务,目标,获取完整、准确的用户需求；,充分理解、认识和分析用户的需求；,采用需求建模方法编写需求规格说明，为开展整个软件项目的连续工作提供详细的任务要求，为开发者和用户提供软件项目成果质量评价的重要依据。,工作内容,刻画出软件的功能和性能、指明软件和其他系统元素的接口、并建立软件必须满足的约束条件；,分解软件系统模块，建造将被软件处理的数据、功能和行为模型，为软件设计者提供了可被翻译成数据、体系结构、界面和处理流程的设计模型；,提交需求规格说明书，形成软件项目管理过程的第一个里程碑成果。,任务,问题分析,(,即如何获取需求,),、需求描述,(,即如何定义需求,),和需求验证。,问题分析,需求分析人员通过对问题及其环境的理解、分析和综合，消除用户需求的模糊性、歧义性和不一致性。,系统分析人员应该将自己对客户需求及问题的理解与自己所拥有的软件开发经验结合起来，以便发现哪些要求是由于用户的片面理解和短期行为所提出的不合理的要求，哪些要求是尚未提出但具有真正价值的潜在需求。,由于用户群中每个用户的出发点不同，思考问题的角度也有所区别，从不同的应用层面阐述对原始问题的理解和对目标系统的要求，因此，有必要对原始问题及其软件求解建立模型。,这种模型一方面用于精确记录用户从不同的角度、在不同的抽象级别对原始问题和软件要求的描述；另一方面，它也将帮助分析人员发现用户需求中的不一致性，排除不合理的部分，挖掘潜在的用户需求。,这种模型是分析人员对于原始问题及其软件理解的一种知识结构。这种结构往往包含问题及其环境所涉及的信息流、处理功能、用户界面、行为模型及设计约束。它是需求规格说明书、软件设计和实现的主要基础。,(2),需求描述,以需求模型为基础，考虑问题的软件可解性，生成需求规格说明书,和初步的用户手册,。,需求规格说明书包含对目标系统外部行为的完整描述、需求验证标准以及用户对系统在性能、质量、可维护性等方面的要求。,用户手册则包括用户界面描述以及有关目标系统使用方法的初步构想。,(3),需求验证,分析人员在用户和软件设计人员的配合下对生成的需求规格说明进行复核，以确保软件需求的全面性、精确性、一致性、可行性。,并使用户和软件设计人员对需求规格说明及用户手册的理解达成共识，达成对目标系统理解的一致性。,问题分析、需求描述和需求验证并不遵循线性顺序，这些活动是相互渗透、增量并行和连续反复的。包括四个过程：,第一，系统分析员和用户开展面对面的交流，记录用户提供的信息，即开展获取活动；,第二，需求分析员处理从用户那里获取的信息并理解它们，把它们分成不同的类别，并将客户需求同可能的软件需求相联系，即开展需求分析活动；,第三，系统分析人员将客户需求信息结构化，编写成文档和示意图，形成需求规格说明书；,最后，组织用户代表评审文档，并纠正存在的错误，完成需求的验证工作。,这四个过程循环往复，渗透到客户业务系统的各个环节，贯穿于需求分析的整个工作过程中，直到项目组人员与客户在对目标系统的功能、流程、接口、数据、操作等多方面内容达成共识后，方可宣布需求分析任务的结束。,需求还有可能再发生变动，此时需求分析的结束，只是标志客户需求在一定时期内的“相对锁定”，这对整个项目未来工作的开展非常重要。,5.2.2,需求分析的工作模式,需求分析在通常情况下划分为三个阶段。,第一阶段：“访谈式”,(Visitation),这一阶段是和具体用户方的领导层、业务层人员进行访谈式沟通，主要目的是从,宏观,上把握用户的具体需求，了解现有的组织架构、业务流程、硬件环境、软件环境、现有系统等具体情况，建立起良好的沟通渠道和方式。,实现手段：访谈、发放调查表,成果：调查报告、业务流程报告,第二阶段：“诱导式”,(1nducement),在分析人员已经了解了具体用户方的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等信息的基础上，作出简单的用户流程和操作界面，同时结合以往的项目经验对用户采用诱导式、启发式的调研方法和手段，和用户一起探讨业务流程设计的合理性、准确性、方便性、习惯性和易操作性。,实现手段：拜访（诱导）、,DEMO,演示,输出成果：调研分析报告、原型反馈报告、业务流程报告。,第三阶段：“确认式”(Affirm),进行具体的流程细化、数据项的确认阶段。,分析人员需要完成明确的业务流程报告、数据项描述、修改后的,DEMO,系统及业务流设计目标。,用户方审查业务流程报告、数据项描述以及通过操作开发方提供的,DEMO,系统，提出反馈意见，并对已经完成并可接受的报告、文档签字确认。,实现手段：拜访,(,回顾、确认,),，提交业务流程报告、数据项描述；,DEMO,演示系统。,输出成果：需求分析报告,5.3,需求分析阶段的团队组织,5.3.1,团队组织与建设,需求分析作为软件开发生命周期的第一个里程碑，它的内容贯穿于整个软件生命周期全过程，是一个需要团队成员高度配合和密切协作的阶段。,需求分析阶段参与项目的人员及工作职责如下：,(1),项目经理：负责需求分析阶段项目进度的安排和控制；参与项目的各种资源调度；负责项目的总体协调工作。,(2),系统分析人员：与用户方的技术人员和业务人员进行良好的沟通，了解业务流程、功能需求、系统构想和项目目标，完成软件需求说明书的编制任务。,(3),程序员：在采用原型法的系统分析过程中，程序员参与用户的需求分析过程，根据用户的实际需求，完成原型系统的开发工作。,(4),质量管理人员：负责组织有关人员完成对需求分析工作的质量审核和需求说明书的评审工作。,(5),配置管理人员：把通过评审的需求说明书纳入软件的配置管理项。,(6),用户方的技术人员：用户方参与项目的技术人员,(,往往是计算中心的工作人员，未来工作是维护系统,),，通过与系统分析人员的沟通，确定系统的技术实现方案。要求该人员具有对需求说明书中系统技术方案的最终签字认可权。,(7),用户方的业务人员：用户方参与项目的业务人员，经过与系统分析人员的沟通，确定未来软件系统实现的具体功能和业务模型。要求该类人员对需求说明书中的业务需求具有最终签字认可的权利。,图,5-4,为需求分析阶段典型的团队组织模型。,需求分析涉及的单位、组织和人员主要包括两大类，一类是用户方，一类是开发方。,双方参与需求分析阶段工作的人员在各自项目经理的领导和协调下开展工作，并分别与对方项目人员进行充分的沟通和交流；双方项目人员之间协调不了的事情由双方项目经理进行协调，项目经理协调不了的事情交项目委员会协调。,整个软件需求分析阶段的团队组织是按照项目管理中典型的矩阵式结构来开展，能够有效地利用项目资源，增加了沟通的机会，充分发挥项目人员的积极性。,5.3.2,团队管理,本阶段的团队管理包含项目参与双方团队的管理工作。,团队管理的特点有：,(1),团队成员能力的要求,具有良好的沟通及协作能力是对项目所有参与人员的共同要求。,对开发方需求分析人员，需要具备丰富的需求分析经验、良好的业务知识。切忌承担分析任务的分析人员既是新手，又不熟悉业务知识,对用户方人员来说，技术人员要具备良好的技术背景，熟悉本单位的计算机系统及网络状况。业务人员需要具有丰富的业务知识，熟悉各种业务的处理流程及结果形式。,(2),明确划分双方的职责,在需求分析阶段开始时，要明确项目双方在合作中的权利和义务，形成正式的项目协作文件。,为了避免用户方工作人员不愿意积极参与需求调研过程，或对需求分析的工作不重视的现象，对需求分析结果，用户方必须签字确认。,(3),团队矛盾及问题的防范及解决办法,需求分析阶段容易发生的矛盾与问题主要是系统分析人员与用户的工作配合上。,例如：由于种种原因，用户借工作忙，使需求调研工作一拖再拖；或用户拒绝对各项需求分析结果进行签字确认等；或是双方工作方式上的不恰当，造成工作配合上的矛盾和摩擦等。,可采用以下办法加以防范和解决：,1),明确各自的责任和义务,2),树立共同的项目目标和成功意识,3),增加友谊,4),出现问题尽量在小范围内自行协调解决,5),组织项目协调会议,5.4,需求分析阶段的项目管理,5.4.1,需求分析阶段的进度管理与控制,做好需求分析阶段的进度管理工作，需要做好以下几个方面的工作：,(1),详细的工作计划和明确的责任分工,由于需求分析阶段项目双方工作协作较多，容易出现配合上的矛盾和问题。所以，在需求分析阶段开始时，双方的项目经理要进行沟通，制定本阶段详细的工作计划、参与人员的工作分工及职责。,计划主要包括：,本阶段详细的进度计划安排；,项目参与双方参与人员的工作分派及职责要求；,双方人员的工作时间约定、工作内容及工作时间的保证要求；,在项目协作过程中双方工作人员的工作流程约定、问题及其解决流程约定等。,计划完成后，要形成正式的书面文件。双方项目经理签字认可后下发执行。,(2),合理的需求调研和科学的工作安排,较为理想的需求调研步骤为：,首先与用户方的技术人员交流，确定系统实现的技术方面的需求，即技术实现的架构与要求。,接下来再与业务人员交流，获取详细的业务需求。在业务需求的调研过程中，应先确定系统的主要功能要求，再在此基础上逐步进行需求细化工作。,(3),有效遏制需求变更,需求分析阶段用户需求的变更主要表现为用户需求的反复，容易使需求分析工作原地转圈，无法按计划完成需求分析工作。,要遏制分析阶段的需求变更，通常采用的办法有以下几种：,1),充分到位的需求调研。,详细周密的需求分析，以及对用户需求的深层次挖掘等工作，是保证高质量需求分析工作的基础，也是防止需求变更的基本手段。,2),用户签字制度。,签字的办法可以使用户在需求调研中以积极负责的态度，认真对待每个需求分析项。这样做可有效遏制需求的反复。,3),定期的工作通报制度。,开发方项目经理要定期将需求分析阶段的工作进展情况、存在的问题进行汇总，向项目双方的高层领导、项目管理委员会进行工作通报。,4),对签字认可后的需求纳入需求管理，对发生的需求变更，执行需求变更处理流程。,(4),确保与用户沟通的深度和广度,所谓深度是指分析人员在需求调查的过程中，不但要与用户建立良好的工作关系，甚至要努力去建立比较深厚的私人关系，拉近距离，便于沟通。只有这样才能更清楚的了解用户的真实想法，获得用户的尊重和工作支持。,所谓广度就是在需求调研过程中要进行整体调研，需求调研要面向用户项目参与的全体人员。一方面是要了解用户的整体需求细节；另一方面也可从不同人员各自的角度了解用户方到底想要完成一个什么样的系统。,对于用户方的不同认识，分析人员可通过召开项目协调会议的方法，协调并统一用户方人员对相关需求的一致看法。,(5),采取有效的需求调研方法,分析人员要确保本阶段工作能够按计划执行，首先需要分析在项目需求分析中的困难和问题，并采用有针对性的需求调研方法。,(6),需求的复用,在软件项目实施的过程中，许多不同项目间的需求都有相似性，特别是对于同类型项目在不同用户间的实施，需求之间的相似性就更加普遍。所以，分析人员应该十分注意需求的复用。,通过复用，用户形成了一个需求的原型，进而只需要对原型进行修改和完善即可。,(7),需求分析的结束控制,要做好需求验收工作，需要踏踏实实做好需求分析的各阶段工作：,1),通过项目的合同条款，做好项目的范围规划，明确项目的工作内容。,2),做好分析阶段的工作计划，明确工作进度、人员分工及各自的工作职责。,3),做好各部分需求条款的签字验收工作及定期的工作总结与工作汇报。,4),做好目标系统的介绍或原型系统的演示。,在做好上述工作的基础上，才能确保需求分析工作按进度、高质量地完成，需求阶段的验收工作也就可以顺利地进行。,5.4.2,需求分析阶段的质量管理与控制,高质量的需求最能真实反映用户的实际要求，也将对整个项目的开展带来较少的变更处理及较高的软件开发效率。,要得到高质量的需求分析，应做到以下几点：,(1),积极认真进行调研准备,分析人员在进行每一次需求调研前，要认真做好调研前的准备工作：即要按照工作计划设定需求调研主题；设计采用的需求调研方式；可能的结果形式估计及每种结果的应对措施等。,(2),正确理解用户的需求描述及非二异性的需求文字记录,对于用户描述的软件需求，一方面分析人员要正确理解，使项目双方之间达成共识；另一方面，分析人员在进行记录或书写需求说明书的时候，要表达准确，避免二异性描述的出现。,(3),做好各需求项的用户签字认可工作,需求分析结果是项目验收的质量标准，具有用户评审及验收签字的需求文档是最终软件产品能否通过验收的关键。将需求分析阶段的所有需求调研及会议讨论的结果形成正式的书面文件，经用户审核签字后，纳入需求管理。,(4),做好需求的管理工作,完成需求文档的版本控制及需求变更的控制工作，一方面可使需求分析的结果可管理，防止频繁的修改及内容混乱；另一方面通过有效的管理也可提高软件需求文档的复用率。,(5),定期的会议交流和评审,通过定期召开项目交流会议，一方面可将已获得的结果通报全体用户人员；另一方面将需求分析中的问题拿出来，供全体人员讨论，最终形成一致的结果。同时对已完成的需求结果进行用户的确认，形成“相对锁定”的用户需求。,5.4.3,需求分析阶段的沟通管理,(1),沟通的主要目的,沟通的主要目的就是要准确、全面地了解用户的实际应用需求和理想目标。为最终实现和满足用户的实际需求奠定良好的基础。,(2),沟通的技巧,需求分析人员一方面不能有害怕用户的心理，应以一种积极、主动，将项目做好的心态与用户进行沟通；另一方面要将需求调研看作是为了给用户解决问题，而不是来指导工作的。,在协作工作中，只有对别人尊重和理解，才能换取别人的尊重和支持。同时在工作中要以平和的心态面对用户的需求变更，应当积极地与用户进行交流，实现对需求变更的最佳解决。,（不卑不亢、相互尊重、心平气和）,(3),沟通的形式,1),正式的形式。即按照本阶段工作计划的安排，对用户进行需求调研。或者是相关人员参与问题的讨论等。,2),非正式的形式。通过共同进餐、闲聊、体育活动等方式。,在实际工作中，采用非正式的用户沟通形式往往可以取得意想不到的工作效果。,(4),沟通结果,对于沟通取得的工作结果，都要形成正式的书面文件，经过用户的签字验收，纳入需求管理范围。,5.4.4,需求管理,软件项目的实现过程是由需求驱动的，因而人们希望在软件的开始阶段尽量提供一个精确的需求定义，然后严格的实现这些需求。,但是，每个大型软件的需求都是随着需求的发展和人们认识程度的提高发生不同程度的需求变更。,所有针对需求变更的工作在需求分析阶段要纳入需求管理的范围。,（,1,）需求工程,把所有与需求直接相关的活动通称为需求工程。,需求工程的活动可分为两大类：需求开发；需求管理。其结构如图,5-5,所示,需求开发,需,求,获,取,需,求,分,析,需,求,定,义,需,求,验,证,需求,跟踪,需求变更,控制,版本,管理,需求,复用,需,求,工,程,需求管理,图,5-5,需求工程结构图,需求开发的目的是通过调查与分析，获取用户需求并定义产品需求。需求开发的过程有四个主要活动,:,1),需求获取。与用户进行交流，捕捉、分析和修正用户目标系统的需求，并提炼出符合解决问题的用户需求，产生,用户需求说明书,。,2),需求分析。对各种需求信息进行分析并抽象描述，为目标系统建立一个概念模型。,3),需求定义。是根据需求调查和需求分析的结果，进一步定义准确无误的产品需求，产生,需求规格说明书,。,4),需求验证。指开发方和用户共同对需求文档进行评审，经双方对需求达成共识后作出书面承诺，使需求文档具有商业合同效果。,需求管理的目的是：在用户与开发方对需求有着共同理解的基础上，维护需求的完整性和一致性，并控制需求的变更。,需求管理过程也有四个主要活动：,1),需求跟踪。指通过比较需求文档与后续工作成果之间的对应关系，确保产品依据需求文档进行开发。,2),需求变更控制。指依据“变更申请一审批一更改一重新确认”的流程处理需求的变更，防止需求变更失去控制而导致项目发生混乱。,3),版本管理。详细记录发生需求变更的需求文档版本的日期，发生变更的原因，变更发生的控制记录，更新后文档的版本号等。,4),需求复用。实现为需求开发过程提供可复用的需求文档资料，提高需求开发的工作效率和质量。,需求开发与需求管理活动的业务流程如图,5-6,所示。,(2),需求跟踪,是为了建立与维护“需求一设计一编程一测试”之间的一致性，确保所有的工作成果符合用户需求。,需求跟踪有两种方式：,1),正向跟踪。通过检查,需求规格说明书,中的每个需求，看是否都能在后继工作成果中找到对应点。,2),逆向跟踪。通过检查设计文档、代码、测试用例等工作成果，看是否都能在,需求规格说明书,中找到出处。,在实际工作中，我们通常将正向跟踪和逆向跟踪合并使用。,(3),需求变更控制,对软件项目来说广需求的变更是不可避免的，并且许多需求的改进是必要的、合理的。,需求发生变更的原因主要有：,1),随着项目的进展，人们对需求的认识越来越深入。对于早些时候的在需求描述中的错误或不足有了清晰的认识，因此要对早先提出的需求进行必要的变更处理。,2),业务或市场发生了变化，原先的需求文档已经不能适应用户实际业务的发展要求、或跟不上当前市场的变化。因此，要进行需求的变更处理，否则，完成的软件产品就失去了其应有的应用价值。,提出需求变更的动机是好的，目的是希望产品更加符合用户的需求或市场的变化。但对软件项目开发小组而言，变更需求意味着要调整项目资源、调整工作计划和重新分配工作任务、修改前期的工作成果等，开发小组要为此付出较大的代价。因此，变更请求要有一定的范围，否则项目实施将会遥遥无期。,需求变更控制的基本出发点是：,1),如果需求变更带来的好处大于坏处，那么允许变更，但必须按照在计划阶段已定义好的变更处理流程执行，避免变更失去控制。,2),如果需求变更带来的坏处大于好处，那么拒绝变更。,需求变更控制是一个渠道和过滤器，通过它可以确保采纳最合适的变更，使变更可能产生的负面影响减少到最小。,需求变更控制的一般流程如下,1),提出变更申请,需求变更申请的提出者可以是任何一个项目的利益相关人员。目的是完善需求或修改原需求文档中不正确的内容。,2),审批,对于变更申请的审批流程要根据项目计划阶段确定的变更处理流程进行。一般要由开发方和用户方共同承担需求变更的审批工作。审 批工作的主要目的是评价需求变更是利大于弊、还是弊大于利，根据评价结果决定是否同意进行需求变更。,3),修改需求文档,对于通过审批的变更申请，变更申请人从配置管理员或需求管理 员处获得需要修改的当前使用的需求文档版本，完成相关内容的修改和完善工作。,4),重新进行需求确认,修改完成的需求文档，要重新组织对需求的评审和确认工作。对通过需求评审和确认的需求文档纳入配置管理和需求管理，形成最新的需求文档版本。,5),变更结束,需求变更处理结束后，需要根据变更处理过程的工作记录完成,需求变更控制报告,。根据需求变更情况进行工作量的估算，并进行工作计划的调整。,需求变更将造成费用增加、工期延长，所以，在审批阶段就要认真进行变更所带来的工作量及成本增加情况的评估。,若工作量或成本增加不是很大时，可由项目双方协商是否由用户方增加适当的开发费用完成。,若工作量或成本增加较大时，一个较为理想的解决办法是将变更部分作为本项目的二期项目来实施。,5.5,需求获取的方法和特点,5.5.1,需求获取的主要困难及对策,整个软件项目实施过程中，需求获取是软件开发中最困难、最关键、最易出错及最需要沟通和交流的重要方面。,造成需求获取困难的主要原因是：,(1),分析人员领域知识的缺乏,大多数承担需求分析任务的需求分析人多数是技术出身，而不是业务出身。其知识结构的重点是计算机技术，对在项目实施过程中的管理及用户的业务操作等一般都不太熟悉。而用户是个计算机的门外汉。,需求分析员应当抓紧补习和学习该领域的业务知识。可能的话，最好聘请既懂软件开发又懂领域知识的行家来帮忙。,(2),用户对需求描述不清,大多数的用户不知道应该提什么样的需求，或者说他们对目标系统到底要做成什么样子只有一个模糊的概念。这样的想法很可能只是出自于企业规划中提出的一个宏观描述,需求分析员要善于挖掘、善于诱导、甚至给用户演示一些实际应用系统来启发用户对目标系统的理解和认识。,(3),对需求理解上的偏差,在需求分析的过程中，对于用户表达的软件需求，不同的开发人员可能存在不同的理解。如果需求分析员误解了用户的真正意图，将会导致后续的开发工作在错误的方向指引下越走越远。,不论是复杂的项目还是简单的项目，需求分析员和用户都有可能误解需求。所以需求评审,(,需求验证,),工作必不可少，通过需求分析、用户交流、需求评审等手段可使项目所有人员对目标系统的认识 达成共识。,5.5.2,基于调查的需求获取方法,(1),需求调查工作流程,需求调查的一般工作流程如下：,1),需求调查准备。,2),进行需求调查并记录。,3),分析用户的需求信息并撰写,用户需求说明书,。,4),进行需求确认工作。,(2),需求调查准备,需求调查准备工作围绕以下三个中心进行：,1),要调查什么内容,?,2),通过什么方式进行调查,?,3),对“何人”在“何时”进行调查,?,确定需求调查的内容,需求分析调查前，分析人员应将所有的项目资料进行汇总和分析，并与本项目的相关人员进行简单沟通，以便对项目整体上有一个基本的了解。,然后，根据自己对项目的认识，确定进行需求分析工作的重点和目标，起草相关的需求调查问题表，将调查工作的重点锁定在该问题表内。,确定需求调查的方式,一般可以采取以下几种方式：,与用户交谈，向用户提问题。, 参观用户的工作流程，观察用户的操作。, 向用户群体发放调查问卷表。, 与同行专家交谈，听取他们的意见。, 分析已经存在的同类软件产品，提取需求。, 从行业标准、规则中提取需求。,从,Inlemet,上搜查相关资料。,对于一个具体的软件项目，分析人员可以根据具体项目和用户的情况选择,12,种方式作为本项目主要的需求调查方式，其他方式作为辅助的调查方式完成需求调查的任务。,最后，需要确定调查的时间、地点和人员等,对于调查的时间、地点、人员的确定，分析人员首先需要做好自己的需求调查计 划，由项目经理组织项目会议，通过项目会议讨论并产生“需求调查计划”，确定用户方需求调查的人员、时间和地点。,通过项目会议可确保需求调查计划的可性行，确保调查者和被调查者都能很好的履 行自己的工作职责。,要特别注意的是，在调查计划中确定的调查对象一定要全面、并具有广泛的代表性，不要漏掉典型的用户。,。,(3),进行调查并记录,需求调查过程中应注意以下问题：,1),对于按计划即将调查的用户，要尽量提前预约并进行时间确认，这样做一方面可防止用户遗忘；另一方面可提醒用户做好调研的准备工作，使调研取得较好的效果。,2),与用户约好的调查时间，分析人员切勿迟到或早退。同时要注意自己的礼节和谈话方式，尽可能多地获得用户的好感。,3),对于自己将要调查的用户，需求分析员应事先了解用户的身份、背景、甚至用户的性格、兴趣和爱好等，以便调查时能采用灵活的谈话形式，使交谈的氛围融洽。,4),在需求调研过程中，应避免使用,IT,行业术语，以便使用户能够很好的理解。,5),在交谈过程中，要迅速记录需求调研的核心问题。不要等交流结束后才去整理和记录，那样会造成信息丢失和错误信息的发生。,(4),撰写用户需求说明书,用户需求说明书,的参考模板见表,5-2,。,用户需求说明书,0,文档介绍,0,1,文档目的,0,2,文档范围,0,3,读者对象,0,4,参考文档,0,5,术语与缩写解释,1,产品介绍,2,产品面向的用户群体,3,产品应当遵循的标准或规范,4,产品的功能性需求,5,产品的非功能性需求,6,其他需求,附录：用户需求调查报告,表,5-2 ,用户需求说明书,模板,(5),进行需求确认,用户需求说明书,编写完成以后，项目经理应组织同行专家和用户对,用户需求说明书,的正确性进行验证，即进行,用户需求说明书,的评审工作，以使,用户需求说明书,能够准确无误地反映用户的真实意图。,对于通过需求验证后的,用户需求说明书,，用户进行签字确认。,5.5.3,基于用例的需求获取方法,利用传统的需求调查获取方法，当系统较复杂或较大时，有可能出现前后描述不一致的问题，而且，这些需求规格说明也很难转变为设计和实现的规格说明。,面向对象技术的发展为我们提供了解决问题的新思路，其中基于用例,(Use Case),的需求获取办法作为日益流行的一种技术，被越来越多的开发团队所使用。,(1),用例在需求分析中的使用,用例是指一个用户或其他系统与要设计的系统进行的一个交互，这个交互是为了描述某个目标。,用例是对一组动作序列的描述，系统执行该动作序列来为参与者产生一个可观察的结果值。（,UML,用户指南）,用例的重要功能是通过画用例图的办法来鉴别和划分系统功能。它把系统分成角色,(actor),和用例。其中角色可以是一个人、另一个软件、一个硬件或其他与系统交互的实体。一个单一的用例，可能包括完成某项任务的一系列逻辑相关的任务。,用例图在面向对象的软件开发中，为用户进行需求获取和建模提供了一种有效的办法，是面向对象分析建模的基础。,用例像一个黑盒，它没有包括任何和实现有关一些信息。它很容易就被用户所理解。,如果用例不足以表达足够的信息来支持系统的开发，就有必要把用例黑盒打开，审视其内部的结构，找出黑盒内部的,Actor,和用例。,就这样通过不断的打开黑盒，分析黑盒，再打开新的黑盒。直到整个系统可以被清晰的了解为止。,采用用例的需求获取是通过询问用户要利用系统做什么。而大部分程序员的工作习惯也是考虑计算机应该如何实现用户的要求。使用用例方法恰好能够调和双方的矛盾。,虽然用例来源于用户、服务于用户，但是它同样可以用做软件开发的流程。,当系统的开发过程全部基于用例的时候，如利用用例获取需求，采用用例进行设计，应用用例进行编码，使用用例开展测试的时候。这个开发过程就属于用例驱动型的。,(2),用例的获取方法,大部分用例将在项目的需求分析阶段产生，并且随着工作的深入会发现更多的用例，这些都应及时增添到已有的用例集合中。,用例集合中的每个用例都是一个潜在的需求。,用例的获取一般需要经过两个阶段,:,1),确定角色,获取用例从识别角色开始。,角色可以分主要角色、次要角色。,通过回答一些问题来发现角色。以下是可供参考的问题：,谁使用系统的主要功能,(,主要使用者,),。,谁需要系统支持他们的日常工作。,谁来维护和管理，使系统正常工作,(,辅助使用者,),。,系统需要操纵哪些硬件。,系统需要与哪些其他系统交互，包含其他计算机系统和其他应用程序。,对系统产生的结果感兴趣的人或事物。,系统需要何种输入输出,?,输入从何处来,?,输出到何处,?,2),获取用例,获取角色，就可以对每个角色提出问题以获取用例。以下是可供参考的问题：,角色要求系统提供哪些功能,(,执行者需要做什么,)?,角色需要读取、产生、删除、修改或存储的信息有哪些类型,?,必须提醒角色的系统事件有哪些,?,或者角色必须提醒系统的事件有哪些,?,这些事件能干什么,?,为了完整地描述用例，还需要知道角色的某些典型功能能否被系统自动实现,?,当前运行系统,(,也许是一些手工操作而不是计算机系统,),的主要问题是什么,?,用例为表达用户需求提供了一种方法，而这一方法必须与系统的业务需求相一致。分析者和用户必须检查每一个用例，在把它们纳入需求之前决定其是否在项目所定义的范围内。,基于“用例”方法进行需求获取的目的在于描述用户需要使用系统完成所有的任务。,理论上，用例的结果集将包括所有合理的系统功能。实际工作中，分析人员不可能完全获得需求，但是比起其他获取方法，基于用例的方法可以带来更好的效果。,5.5.4,原型法,原型法,(Rapid Prototyping),是一种以计算机程序设计为基础的系统开发方法，它可以快速通过迭代的方法完成最终系统工作模型的建立。,原型法通过先构造一个功能简单的原型系统，然后用户通过对原型系统的讨论和评价而不断完善与细化，最终得到符合用户需求的软件系统。,原型法开发一般经历以下几个阶段：,(1),确定用户基本需求,通过初步调查获取用户的基本需求，了解用户期望的功能、应用范围、约束条件等。,这个阶段用户和开发者对系统功能要求的认识是不完整的，这种不完整可在今后的迭代过程中加以弥补和纠正。,(2),开发原型系统模型,原型系统是根据基本需求建立的初始方案，只包括部分功能，目的是为了进一步和用户讨论实际的需求。,这个模型是在计算机上实现的，它包括了,数据库信息模型,、系统功能模型和简单的业务流程过程模型。,在构造系统原型时比较强调预期的评估，而不是为了正规的使用。所以，对于最终产品的一些要求，如安全性、可靠性等一般不考虑。,(3),征求用户对原型的改进意见,用户在试用原型系统以后，能够指出哪些是他们需要的，哪些是不能接受的，还需要做哪些改进工作，还需要增加哪些新的功能。,(4),修改原型,根据用户要求进行原型的改进工作。这个过程可以反复多次，直到用户真正认为原型系统已实现了他所希望的实际需求为止。,原型化方法比较适合于用户需求不清，业务不确定、需求经常变化的软件项目。原型法的优点是见效快，用户能够在很短的时间内认识目标系统的概貌，然后再不断去改进和完善。,5.6,需求分析方法和建模工具,需求建模就是指用图形符号来表示、刻画需求。,5.6.1,数据流图法,数据流程图法，即结构化分析方法，是面向数据流开展需求分析工作的一种有效方法。一般采用自顶向下，逐层分解的演义分析法来定义系统的需求，即先把分析对象抽象成一个系统，然后自顶向下的逐层分解，将复杂的系统分解成简单的、能够清楚地被理解和表达的若干个子系统。,这样就可以分别理解系统的每个细节、前后顺序和相互关系，找出各部分之间的数据接口。,结构化分析方法通常用数据流图,(DFD),表达需求，以数据字典,(DD),的形式记录数据的逻辑定义。,结构化分析方法的主要工作步骤包括：,1),画出反映当前系统的数据流程图，指明系统的输入输出数据流。,2),分析新系统的设定目标，按照设定目标的要求推导出等价逻辑模型的数据流程图。,3),构造新系统的逻辑模型，生成数据字典。,4),确定人机接口界面与操作方式。,5),确定各种方案的成本与效益，据此对各种方案进行分析比较。,6),选择一种方案，建立完整的需求规格说明书。,(1),数据流程图,数据流程图是以图形的方式表达在问题中信息的变换和传递过程。,它把系统看成是由数据流联系的各种概念的组合，用分解及抽象手段来控制需求分析的复杂性，采用分层的数据流程图来表示一个复杂的系统。,数据流程图中四种主要图形元素：,：数据流。箭头的始点和终点分别代表数据流的源和目标。,：数据源、终点。代表系统之外的实体。,：对数据的加工,(,处理,),。加工是对数据进行处理的单元，它接收一定的数据输入，对其进行处理，并产生输出。,：数据存储。表示信息的静态存储，可以代表文件、文件的一部分、数据库的元素等。,(2),数据字典,数据字典的作用是对数据流图中描述的所有元素作出完整定义与说明，是数据流图的补充工具。,数据流图和数据字典共同构成系统的逻辑模型。,数据字典中的所有定义是严格的、精确的，没有二义性。它的用途是改善分析员与用户之间的沟通，避免发生误解。,数据字典的条目可以分为以下几类：,1),数据流条目,主要说明数据流条目是由哪些数据项组成，以及数据在单位时间内的流量、来源、去向等。,内容包括：,数据流名及其编号,数据流来源,数据流去向,数据流组成,数据流流量与频度,2),数据项条目,说明数据项类型、长度、取值范围等。,内容包括：,数据项名称及编号,数据项类型,取值的范围和取值含义,数据项长度,3),数据存储,数据存储是数据停留和保存的场所。,内容包括：,数据存储的名称及编号,流入和流出的数据流,数据存储的组成,数据存储方式,频率及数据量,4),加工处理条目,说明加工处理的输人数据、输出数据及其加工逻辑等。,内容包括：,加工处理逻辑的名称及编号,输入和输出,主要处理功能,5),外部实体条目,是系统的数据流由外部实体流人或者向外流出。,内容包括：,外部实体的名称及编号,与外部实体有关的数据流,5.6.2,面向对象的分析方法,（,1,）面向对象的基本概念,（,2,）面向对象方法与结构化方法的比较,结构化方法强调过程的抽象和分解，将现实世界映射为数据流及加工，并且加工之间通过数据流进行通信。数据作为被动的实体被主动的操作所加工，是以过程,(,或操作,),为中心的分析方法。,面向对象方法以对象为中心。对象将数据和操作封装在一起，提供有限的外部接口。对象之间通过消息相互通信。,与结构化方法相比，面向对象方法具有以下特点：,1),它把问题域的概念直接映射到对象及对象之间接口，符合人们通常的思维方式，减少了结构化方法从问题域到分析阶段的映射误差。,2),面向对象方法从分析、设计到编码采用一致的模型表示，后一阶段可以直接复用前一阶段的工作成果，弥合了结构化方法从数据流图到模块结构图转换的鸿沟，减少了工作量和映射误差。,3),在客观世界以及作为它的映射的软件系统中，实体的结构是相对稳定的。面向对象方法通过把属性和服务封装在对象中，当外部功能发生变化时，保持了对象结构的相对稳定，使改动局限于一个对象的内部，减少了由于改动而引起的系统波动效应。,4),面向对象方法具有的继承性和封装性支持软件复用，并易于扩充，能较好地适应复杂大系统不断发展和变化的要求。,(3),面向对象分析的步骤,以,Coad-Yourdon,方法介绍面向对象的软件开发过程。,Coad-Yourdon,方法在分析阶段采用五个主要步骤确定一个多层的面向对象分析模型。,标识对象,标识结构,确定主题,定义属性,定义服务及消息连接,这五个步骤并不是必须顺序进行，经常是根据需要交叉进行。当五个层次的工作全部完成时，系统分析的任务也就完成了。,1),标识对象,应该从问题域和系统责任两个方面来确定对象。,问题域侧重于客观存在的事物与系统中对象的映射；系统责任侧重于系统责任范围内的每一项职责都应落实到某些对象来完成。,并不是见到的任何东西都需要在系统中设立对象，在分析中要正确地运用抽象原则，舍弃那些与系统责任无关的事物。,判断事物是否是与系统责任有关的关键问题，一是该事物是否为系统提供了一些有用的信息；二是它是否向系统提供了某些服务。,2),标识结构,结构是一种思维组织的方式，用来反映问题域空间事物之间的复杂关系。,Yourdon,的面向对象方法提出两类结构：一般特殊结构和整体部分结构。,一般特殊结构针对的是事物类之间的组织关系，体现事物的一般性与特殊性。,整体部分结构表示事物的整体与部分间的组合关系。,表示结构为分析者提供了一种分割需求模型的方法。,3),确定主题,主题只是一个参照符号或指针，指向分析模型中的细节。,4,）定义属性,属性是用来描述对象状态的数据。,5,）定义服务及消息连接,服务是指某个对象所具有的特定的行为，定义服务的中心问题是定义所要求的行为。,消息连接是指一个服务为了完成其处理功能，而向另一个对象发出的消息请求。消息连接是在属性的强制封装性和处理这些属性的服务之间建立必要而有限的接口。,5.7,需求分析阶段性成果和考核依据,5.7.1,需求分析的阶段性成果,(1),用户需求说明书。,(2),需求分析模型文档。,(3),需求规格说明书。,用户需求说明书,是经过用户需求验证的，并有用户的确认签字；,需求规格说明书,是经过质量评审的。在本阶段工作完成以后，这两个重要的阶段性成果将被纳入软件配置管理。其中,需求规格说明书,将作为软件设计的重要依据。,需求分析模型文档,可作为,需求规格说明书,的附件。,5.7.2,需求规格说明书,的编写流程,(1),细化并分析用户需求,需求分析员首先对,用户需求说明书,进行细化，对比较复杂的用户需求进行建模分析，以帮助软件开发人员更好地理解需求。,(2),撰写需求规格说明书,需求分析员按照指定的文档模板撰写,需求规格说明书,。如果待开发的产品分为软件和硬件两部分的话，则应当分别撰写,软件需求规格说明书,和,硬件需求规格说明书,。,(3),进行需求确认,邀请同行专家和用户一起评审,需求规格说明书,，尽最大努力使,需求规格说明书,能够正确 无误地反映用户的真实意愿。,5.7.3,需求规格说明书,的评审标准,(1),正确性,需求规格说明书应当正确地反映用户的真实意图。即需求规格说明书中的功能、行为、性能描述必须与用户对目标软件产品的期望相吻合。“正确”是需求规格说明书最重要的属性。,(2),无歧义性,是指每个需求只有惟一的含义。即对于用 户、分析人员、设计人员和测试人员而言，需求规格说明书中的任何语法单位只能有惟一的语义解释。,(3),完整性,是指需求规格说明书中没有遗漏一些必要的需求。具体地说，目标软件产品的所有功能、行为、性能约束以及它所有可能情况下的预期行为，均应完整地包含在需求规格说明书中。,(4),一致性,是指在需求规格说明书中各个需求之间不能相互矛盾。这些矛盾可能表现为术语使用方面的冲突，功能和行为特征方面的冲突，以及时序方面的前后不一致等。,(5),可验证性,需求规格说明书中的各项需求，对用户方而言应当都是可验证的。,(6),可实现性,需求规格说明书中的各项需求对开发方而言应当都是可实现的。“可实现”意味着在技术上是可行的，并且满足时间、费用、质量等约束条件。,(7),可修改性,需求规格说明书的格式和组织方式应保证能够比较容易地接纳后续需求的增加、删除和修改。,(8),可跟踪性,需求规格说明书必须将分析后获得的每项需求与用户的原始需求项清晰地联系起来。,作业：,1.,通常需求分析分为哪些阶段？,2.,需求分析阶段的团队成员，一般由哪些人员组成？,3.,需求分析阶段的沟通形式有哪些？沟通手段有哪些？,4.,需求开发过程有哪些活动？需求管理过程有哪些活动？,5.,对需求分析规格说明书，应该按哪些标准进行评审？,6.,为什么需求阶段的每次会议需要由专人写备忘录并让客户签字或用邮件送给与会人员周知？,提示：,1.,为什么需求阶段的每次会议需要由专人写备忘录并让客户签字或用邮件送给与会人员周知？,发生有关需求的纠纷时作为依据,避免对需求理解的歧义,协调软件项目高效推进,