需求评估培训

Day01需求评估培训Agenda需求的基本概念与原理需求工程需求定义最佳实践需求捕获最佳实践业务流程与规则分析数据需求分析与建模Agenda需求的基本概念与原理需求工程需求定义最佳实践需求捕获最佳实践业务流程与规则分析数据需求分析与建模1）理论是实践的基础2）解决概念性的误区讨论你认为“什么是需求”？日常工作中，遇到与“需求”相关的问题有哪些？关于“需求”最大的困惑是什么？以下问题中，对你影响最大的是哪个？不切实际的用户需求很多需求最终是不需要的用户介入太少需求不完整需求变更频繁软件需求的定义软件行业存在这样一个问题，用于描述需求工作的术语没有统一的定义。对同一项需求，不同的人会有不同的描述，称其为用户需求、软件需求、功能需求、系统需求、技术需求、业务需求或产品需求。客户对需求的定义，在开发人员看来可能只是高级别的产品概念；而开发人员的需求概念对用户来说也许就是详细的用户界面设计。需求必须被记录成文档，这一点很重要。5对需求的不同解释IEEE的软件工程标准术语表(1990)则将需求定义为:用户为解决某个问题或达到某个目标而需具备的条件或能力。系统或系统组件为符合合同、标准、规范或其他正式文档而必须满足的条件或必须具备的能力。上述第一项或第二项中定义的条件和能力的文档表达。6注意:不要一厢情愿地认为项目涉众对需求的理解是一致的。应该事先给出定义，才能保证大家谈论的是同一个问题。需求—导致项目失败的罪魁祸首根据StandishGroup对23000个项目进行的研究结果表明，28%的项目彻底失败，46%的项目超出经费预算或者超出工期，只有约26%的项目获得成功。而在于这些高达74%的不成功项目中，有约60%的失败是源于需求问题。也就是说，有近45%的项目最终因为需求的问题最终导致失败。对不知道航行目的地的人来说，没有顺风！我们在哪里重重摔了一跤在StandishGroup的报告中总结了导致项目失败的最重要的8大原因中，有5个与需求相关：不完整的需求(13.1%)；缺乏用户的介入(12.4%)；不实际的客户期望(9.9%)；需求和规范的变更(8.7%)；提供了不再需要的(7.5%)缺乏资源(10.6%),没有执行层支持(9.3%),缺少规划(8.1%)项目成功的因素用户的参与：15.9%管理层支持：13.9%清晰的需求描述(13.0%)；合适的规划(9.6%)；现实的客户期望(8.2%)；较小的里程碑(7.7%)；有才能的员工(7.2%)软件需求曾经让我们如此狼狈参与各方都以自已角度讲述问题分布式WebServices三层对话框菜单条DCOMB/S数据交换……财务计算管理报表工作流自动库存控制库存报警业务线索管理业务经线索跟踪销售月报生成交易流数据问题的根源是什么？用户说的不是他想的：客户提供（陈述的需求）的需求并不是真实的需求，还需要作进一步的分析，以确定客户的真正需求和期望，接下来需要澄清并重新描述。可以这么说客户在理解基础业务过程和描述自己的需求方面有很大的差异。需求分析方法有问题：系统开发人员使用低效的需求分析和项目管理方法。共同责任强调不足：对客户和提供商在项目成功的共同责任方面强调不够。优秀的团队遇到糟糕的需求用户参与不足用户需求扩展有歧义的需求镀金问题过于抽象的需求忽略某种用户不准确的计划……用户参与不足开发人员往往也不重视用户的参与，原因是他们认为与用户打交道不像写代码那么有趣，或者自以为已经知道了用户想要什么。用户参与不足将导致不能在项目早期及时发现需求中的缺陷，从而延误项目的完成。在整个项目开发过程中，开发团队必须始终与实际用户直接合作。14用户需求扩展由于开发过程中需求的不断发展与增加，项目往往会落后于计划的进度并超出预算。出现这种情况是因为没有依据对需求的规模和复杂度的实际评估来制订计划，而不断修改需求又使情况变得更糟。问题的责任部分在于用户不断提出修改需求的要求，部分在于开发人员处理这种要求的方式。要控制项目范围的改变：首先应明确项目的业务目标、全局规划、范围、限制、成功标准以及产品的预计用途。然后参考这一框架对所有新特性和需求变更进行评估。15有岐义的需求岐义表现为同一读者可以对一项需求声明作出多种解释，或者不同的读者对同一需求产生不同的理解。岐义会导致以下几点：涉众对产品怀有不同的期望。因此最终交付的产品会让部分人感到意外。有岐义的需求使开发人员的时间浪费在解决无需解决的问题上。有岐义的需求导致测试人员与开发人员对产品功能的理解不同，从而使测试人员也要浪费时间来解决这些差异。消除歧义的办法之一是让代表不同观点的人对需求作正式的检查。16镀金问题开发人员为产品添加了一项需求说明中没有提到的功能，他认为“用户肯定会喜欢的”。这就是所谓的“镀金问题(goldplating)”。开发人员和需求分析员不应擅自添加特性，应该把创意和备选方案提交给客户，让他们做决定。要避免镀金问题，就应该追溯每项功能的来源，弄清楚为什么添加该功能。17过于抽象的需求营销人员或经理经常喜欢只给出一个粗略的说明，他们希望开发人员在开发过程中充实它。这种方式对研究性项目或需求特别灵活的项目或许管用，但是需要紧密合作的团队，而且仅限于开发小型系统(McConnell1996)。大多数情况下，这种做法的结果是使开发人员受挫，让客户失望。18忽略了某类用户用户所使用的产品特性、产品的使用频率以及用户自身的经验水平不尽相同。因此，多数产品都拥有不同的用户群。如果一开始没能找出产品的所有重要用户群，就会有某些用户需求得不到满足。确定所有用户群后，还要保证获得各类用户的需求。19不准确的计划不能充分理解需求，就会作出过于乐观的估计，最终不可避免地陷入超支的泥潭。造成软件成本估算失败的最主要原因包括频繁变更需求、遗漏需求、未与用户充分沟通、需求的说明不精确，以及对需求的分析不透彻(Davis1995)等。20优质需求过程的好处实现有效的需求工程过程。减少开发后期以及整个维护过程中不必要的返工并可带来极大的回报。下面列出的好处并不能完全量化，但确实存在：减少需求缺陷减少开发过程中的返工减少不必要的特性降低改进成本加快开发进度提高沟通效率控制需求范围的改变项目更有序对系统测试的评估更准确提高客户和开发人员的满意度21优秀需求的特点如何才能将好的需求规格说明与那些有问题的区分开来？这一节首先对说明中的单条需求(即需求声明)特点进行讨论，然后将介绍SRS作为整体应具备的特点。如果想知道您的需求是否具备这些特点，最好的办法就是请几位项目相关人员仔细审阅您的SRS。不同的人会发现不同的问题。22需求陈述的特点每一项用户需求、业务需求和功能需求都应具备下列性质。完整性每一项需求都必须完整地描述即将交付使用的功能。正确性每一项需求都必须准确地描述将要开发的功能。可行性需求必须能够在系统及其运行环境的已知能力和约束条件内实现。必要性每一项需求记录的功能都必须是用户的真正需要，或者是为符合外部系统需求或某一标准而必须具备的功能。有优先次序为每一项功能需求、特性或用例指定一个实现优先级，以表明它在产品的某一版本中的重要程度。无歧义一项需求声明对所有读者应该只有一种一致的解释，然而自然语言却极易产生歧义。可验证性看看您能否设计一些测试方法或使用其他验证方法，如检查或演示来判断产品是否正确实现了需求。23权利和义务法案客户有权利1.要求需求分析员使用客户的语言2.要求需求分析员熟悉客户的业务，了解客户对系统的目标3.要求需求分析员把需求收集过程中客户提供的信息组织成书面的软件需求规格说明4.要求需求分析员解释需求过程生成的所有工作结果5.要求需求分析员和开发人员尊重客户，始终以合作和专业的态度与客户进行互动6.要求需求分析员和开发人员为需求和产品实现提供思路和备用方案7.要求开发人员实现能让产品使用起来更容易、更有趣的特性8.调整需求，便于重用已有的软件组件9.在提出需求变更时，获得对变更的成本、影响及二者权衡关系的真实评估10.获得满足功能和质量要求的系统，这些要求必须事先告知开发人员并征得其同意软件客户有义务1.为需求分析员和开发人员讲解业务并定义业务术语2.提供需求，阐明需求，通过与开发人员的交互将需求充实完善3.对系统需求的描述必须详细、准确4.需要时，及时对需求做出决断5.尊重开发人员对需求成本和可行性的评估6.与开发人员协作，为功能需求、系统特性和用例设置优先级7.审阅需求文档，评估原型8.发现需要变更需求时，及时与开发人员沟通9.按照开发组织的变更控制过程提出需求变更10.尊重需求分析员在需求工程中使用的过程我们应该怎么办？对“需求”建立正确的认识；客户和供应商—一根绳子上的两个蚂蚱；和客户一起建立起“共同的目标”；寻找并使用正确的、有效的需求捕获、描述（建模）、管理方法；动态、持续地适应需求的变化；需求是什么？非功能需求业务需求项目视图/范围文档用户需求系统需求质量属性用例文档功能需求其它非功能需求设计约束SRS业务需求业务需求是指反映组织机构或客户对系统、产品高层次的目标要求，通常问题定义本身就是业务需求。背景描述：XX保险公司希望充分利用日益完善的移动通信技术，在原有的办公系统的基础上进行扩展，使得在外的业务人员能够及时地获得客户、业务相关的动态信息，与此同时，实现企业内部的即时通信。业务需求/目标：通过该系统的实施，将人工保费续缴、投保手续办理两项业务运转周期缩短10％以上，使企业内部沟通效率大幅改善，以帮助企业运转效率得以提高。业务目标示例某船厂商业管理系统目标：A1.取代过时的系统A2.集成订单文档及数据库A3.使用经验数据进行报价A4.支持系统化的销售A5.快速捕获成本数据A6.加快发票的制作某医院管理系统目标：B1.降低IT成本人事部门：B2.实现一些任务的自动化B3.消除出错源B4.遵守最后期限B5.减少繁琐工作医院部门：B6.减少加班及工作量不足的情况B7.更快速的勤务规划B8.改进勤务表质量业务需求就是定义系统目标现状：功能分解盛行的今天，常常会犯“盲人摸象”的错误，这使得需求太过脆弱，难以经受考验。目标！目标！还是目标！--系统开发应目标驱动！目标是团队唯一的行动纲领。目标的定义不能够流于形式，应该具有以下特征：业务导向、可度量、合理、可行。要注意目标太夸大会浪费资源，目标太缩小会影响士气。（教堂与小屋）目标通常就是业务需求！业务需求就是定义系统目标目标在哪里？业务需求是构建在“项目发起人”的脑子里的，也就是谁提出项目，谁就拥有对“业务需求”的最清晰的理解。引出宏观的目标：思考企业运作中存在什么问题？这些问题主要是体现在哪些方面？这些问题对企业造成了什么影响？认为可以怎么解决？希望达到什么样的效果？将大任务分解成为小目标，并且引导客户良好地定义，这也是我们形成“项目子目标描述”的关键基础。衡量这些目标的合理性与可行性。业务需求就是定义系统目标形成一个不超过50字的项目目标，并且列出5-9个主要子目标，并且将其制作成一页文档，作为“项目的行动纲领”，还应该得到“项目发起人”的认可。在此基础上，可以编写“项目的目标和范围文档”(或称项目综述，即POS，内容包括问题/机会、项目目标、项目目的、成功标准、假设/风险/障碍)，对于产品而言，我们还可以构建一个从市场角度分析的“愿景”文档。该部分工作是处于“需求过程”的金字塔尖，多花费一些时间和精力是值得的，也是必要的。业务需求就是定义系统目标有了清晰的目标之后，还应该对系统划定范围，最常用的方法是工作上下文范围图（结构化分析方法）：用户需求用户需求是指描述用户使用产品必须要完成什么任务，怎么完成的需求，通常是在问题定义的基础上进用户访谈、调查，对用户使用的场景进行整理，从而建立从用户角度的需求。用户有不同类型：管理型、事务型信息系统、人决策