业务分析与需求指南-BABOK

业务分析与需求周金根zhoujingen@gmail.comhttp://zhoujg.cnblogs.com/2010-2-24目录业务分析与需求...............................................................................................................................1前言..................................................................................................................................................5BABOK-业务分析知识体系介绍...................................................................................................6什么是BusinessAnalysis..................................................................................................7谁是BA.............................................................................................................................7范围(Scope).......................................................................................................................8BABOK结构......................................................................................................................8各组成部分在项目不同阶段大致工作量比例.............................................................11CBAP认证发展阶段.......................................................................................................12BABOK-BA 计划 项目进度计划表范例计划下载计划下载计划下载课程教学计划下载 和监控概要.........................................................................................................13描述.................................................................................................................................13目的.................................................................................................................................13任务列表.........................................................................................................................14任务：涉众管理（ConductStakeholderAnalysis）.....................................................14任务：计划活动（PlanBusinessAnalysisActivities）.................................................14任务：计划沟通（PlanBusinessAnalysisCommunication）.......................................15任务：计划需求管理流程（PlanRequirementsManagementProcess）...................15任务：计划、监控和报表业务分析绩效（Plan,monitorandReportonBusinessAnalysisPerformance）................................................................................................................15BABOK－企业分析概要.............................................................................................................17描述.................................................................................................................................17目的.................................................................................................................................17任务列表.........................................................................................................................17任务：标识业务需要（IdentifyBusinessNeed）........................................................18任务：确定 方案 气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载 步骤（DetermineSolutionApproach）.............................................18任务：定义方案范围（DefineSolutionScope）.........................................................18任务：开发业务案例（DeveloptheBusinessCase）..................................................19BABOK-需求获取（Elicitation）.................................................................................................20描述.................................................................................................................................20目的.................................................................................................................................20任务列表.........................................................................................................................21任务：准备工作（PrepareforElicitation）..................................................................21任务：开展获取（ConductElicitation）......................................................................21任务：文档化获取结果（DocumentElicitationResults）...........................................21任务：确认获取结果（ConfirmElicitationResults）...................................................22BABOK－需求分析概述.............................................................................................................23描述.................................................................................................................................23目的.................................................................................................................................23任务列表.........................................................................................................................24任务：组织需求（OrganizeRequirements）...............................................................24任务：划分优先级（PrioritizeRequirements）...........................................................24任务：详述需求和建模（SpecifyandModelRequirements）...................................24任务：确定假定和约束（DetermineAssumptionsandConstraints）........................25任务：确认需求（VerifyRequirements）....................................................................25任务：验证需求（ValidateRequirements）................................................................25BABOK－方案评估和验证概述.................................................................................................26描述.................................................................................................................................26目的.................................................................................................................................26任务列表.........................................................................................................................27任务：评估需求覆盖率（AssessRequirementsCoverage）.......................................27任务：分配需求（AllocateRequirements）................................................................27任务：确定组织意愿（DetermineOrganizationalReadiness）..................................28任务：验证方案（ValidateSolution）.........................................................................28任务：评价方案（EvaluateSolution）.........................................................................28BABOK－需求管理和沟通概要.................................................................................................30描述.................................................................................................................................30目的.................................................................................................................................30任务列表.........................................................................................................................31任务：管理方案和需求的范围（ManageSolutionandRequirementsScope）........31任务：管理需求追溯（ManageRequirementsTraceability）.....................................32任务：管理需求重用（MaintainRequirementsforre-use）......................................32任务：准备需求包（PrepareRequirementsPackage）...............................................32任务：传递需求（Communicaterequirements）........................................................33BABOK－业务分析技术概要.....................................................................................................34软件需求的三个层次.....................................................................................................................36业务需求.................................................................................................................................36用户需求.................................................................................................................................38功能需求.................................................................................................................................38三个层次的开发关系.............................................................................................................39需求工程＝需求开发＋需求管理.................................................................................................42需求开发.................................................................................................................................42需求获取.........................................................................................................................44需求分析.........................................................................................................................44需求管理.................................................................................................................................46用Kano模型来确定需求优先级...................................................................................................48客户满意度模型Kano....................................................................................................48评估需求类型.................................................................................................................48Kano模型分析................................................................................................................49原型开发.........................................................................................................................................51为什么需要原型.............................................................................................................51水平和垂直的原型.........................................................................................................51抛弃型原型或进化型原型.............................................................................................51低保真原型和高保真原型.............................................................................................52原型工具.........................................................................................................................53原型不仅仅是界面.........................................................................................................54OpenExpressApp对原型的支持....................................................................................55获取需求方法：NineBoxes...........................................................................................................56三个方面.........................................................................................................................56三种提问方式.................................................................................................................57用户故事.........................................................................................................................57为客户着想.....................................................................................................................57确定优先级的四个因素.................................................................................................................58用户经验曲线.................................................................................................................................59用户经验曲线.................................................................................................................59大多数用户是大众（competent）的用户..................................................................60附一：业务流程梳理工具Sam.....................................................................................................62业务流程五个层次.................................................................................................................62流程梳理工作方法.................................................................................................................64附二：原型工具GUIDesignStudio...............................................................................................65前言业务分析和需求对产品来说起到决定性作用，本文将会讲解一下业务分析知识体系BABOK以及一些与需求相关的一些知识。欢迎大家来信zhoujingen@gmail.com提出你的建议BABOK-业务分析知识体系介绍当我们作项目时，下面这张图很多人都明白，从计划、构建、测试、部署实施后发现提供的方案并不能真正解决用户的问题，那么我们是不是少了什么步骤或者缺少对什么环节的重视呢？上图和下图对比就可以看出来，保证产品是客户想要的，那么必须有业务分析这个重要环节，必须很好的描述和定义用户的需求并提供解决方案。Scrum方法中对开发团队提供了很多支持，但是对PO如何得出ProductBacklog并未提及，因为这已经属于另一范畴了。那我们有没有什么方法可以支持PO进行业务分析呢？秉承一贯偷的作风，在年度总结和计划：去年4个1，今年5个1中提及到引入BABOK知识体系，本篇将作为这个系列的开篇，对BABOK进行总体的介绍。什么是BusinessAnalysisBABOK对"WhatisBusinessAnalysis"做了一个权威的定义：Businessanalysisisthesetoftasksandtechniquesusedtoworkasaliaisonamongstakeholdersinordertounderstandthestructure,policies,andoperationsofanorganization,andrecommendsolutionsthatenabletheorganizationtoachieveitsgoals.翻译一下为：BusinessAnalysis就是一组任务和技能的集合，它是不同的利益相关者之间的桥梁，目的是为了让这些利益相关者更好的理解组织的架构、政策和运作模式，并且为了使得组织能够达到它们的目标，提出相应的解决方案。谁是BABABOK认为BA是任何人都可以是BA，只要他做的是业务分析的工作，而不区分岗位角色，他可能是系统分析师、流程分析师、项目（产品）管理者、开发人员、质量分析员、业务架构师或者咨询师等等。在不同的公司，对于BA有不同的理解和职位描述，所以在BABOK中也没有定义明确的岗位职责。对于IT的BA而言，IT部门和业务部门会存在gap，IT不懂业务，而业务部门不懂技术，所以IT的BA最好是既懂技术又懂业务。范围(Scope)术语“scope”应用非常广泛，定义也非常之多，IT中有两个定义占主导：方案范围（Solutionscope）：是满足业务需求而 设计 领导形象设计圆作业设计ao工艺污水处理厂设计附属工程施工组织设计清扫机器人结构设计 的一套方案项目范围（Projectscope）：实现和构造特定方案（solution）时的工作在本系列介绍中，如果没有特别说明时，范围都指方案范围，而项目范围更多出现在项目管理范畴中。BABOK结构BABOK由以下几个部分组成：1.任务（TASK）：业务分析中的核心工作，每件任务都必须具有如下的特性：o每件任务都是有价值的，并且大家都是认同的o每件任务是完整的，它的输出可以作为其它不同人的输入o每件任务都是知识体系中必须的组成部分o输入/输出2.技能（TECHNIQUE）：技能描述在在某个特定的情况下如何执行任务。每个任务可以没有或者有1至多个相关的技能，但每个技能必须至少关联到一项任务中去。BABOK中包括了BA社区中大部分常用的技能。当我们在自己领域中实践时，可以添加自己的技能。3. 知识点 高中化学知识点免费下载体育概论知识点下载名人传知识点免费下载线性代数知识点汇总下载高中化学知识点免费下载 （KnowledgeArea）：知识点是相关任务和技能的集合，它由7大组成部分：各组成部分在项目不同阶段大致工作量比例为了便于描述知识点的7个部分使用的技能，这里先约定一下简称，BAP&M–业务流程计划和监控（BusinessAnalysisPlanningandMonitoring）EA–企业分析（EnterpriseAnalysis）E–需求获取（Elicitation）RA–需求分析（RequirementsAnalysis）SA&V–方案评估和验证（SolutionAssessmentandValidation）RM&C–需求管理和沟通（RequirementsManagementandCommunication）CBAP认证发展阶段参考：BABOKVersion2IIBA业务分析师在敏捷项目中的作用BABOK2publicDraft下载BABOK-BA计划和监控概要描述业务分析计划是项目计划的主要输入，项目管理包括组织和协调业务分析活动。BA计划和监控描述如何确定在完成业务分析过程中需要哪些活动，它包括涉众标识、业务分析技术的选择、管理需求的流程以及如何评估变更。目的计划业务分析任务需要的话更新或更改业务分析方法有效并持续改善业务分析实践任务列表涉众管理（ConductStakeholderAnalysis）计划业务分析活动（PlanBusinessAnalysisActivities）计划沟通（PlanBusinessAnalysisCommunication）计划需求管理流程（PlanRequirementsManagementProcess）计划、监控和报表业务分析绩效（Plan,monitorandReportonBusinessAnalysisPerformance）任务：涉众管理（ConductStakeholderAnalysis）目的标识涉众，这个任务包括明确项目或项目不同阶段的涉众，涉众影响力分析，参考：企业架构－涉众管理（StakeholderManagement）输入o组织规范（OrganizationalStandards）o定义业务问题/机会（Problem/Opportunity）输出o涉众列表o涉众角色以及职责任务：计划活动（PlanBusinessAnalysisActivities）目的确定在定义业务解决方案过程中需要哪有活动，这些活动如何被执行，有哪些工作需要做，以及如何评估任务需要执行的时间o标识业务分析交付物o确定业务分析工作范围o确定业务分析活动在知识域（EnterpriseAnalysis,Elicitation,RequirementsAnalysis,SolutionAssessmentandValidation）的任务o标识任务之间的依赖关系以及任务间的接口问题o开发BA工作评估指标（时间、技能要求级别、任务复杂性等）输入o涉众列表o涉众角色以及职责o组织规范输出包含以下计划：o业务分析和监控（BusinessAnalysisPlanningandMonitoring）o企业分析（EnterpriseAnalysis）o需求获取（Elicitation）o需求分析（RequirementsAnalysis）o方案评估和验证（SolutionAssessmentandValidation）o需求管理和沟通（RequirementsManagementandCommunication）任务：计划沟通（PlanBusinessAnalysisCommunication）目的给涉众分组，确定不同涉众各自需要什么信息以及我们如何交流（口头、文字等）输入o涉众列表o涉众角色以及职责o业务分析计划输出业务分析沟通计划任务：计划需求管理流程（PlanRequirementsManagementProcess）目的描述如何确定合适的需求流程，包括确定是否以及为什么需求变更，涉众是否同意变更，以及需求追溯的方法。需求管理定义可以参考需求入门：需求工程＝需求开发＋需求管理输入o组织规范o业务分析计划输出o需求管理计划任务：计划、监控和报表业务分析绩效（Plan,monitorandReportonBusinessAnalysisPerformance）目的确定在业务分析执行评估中使用哪些度量，包括我们如何跟踪、评估和报告业务分析工作的质量以便我们采取措施改正我们的问题。输入o组织绩效规范o实际的绩效度量o业务分析计划o需求管理计划输出oBA绩效评估方法o学习文档（LessonsLearned）o流程改进建议（Processimprovementrecommendations）BABOK－企业分析概要描述企业分析描述我们如何捕捉、提炼并明晰业务需要，并定义一个可能实现这些业务需要的一个方案范围，它包括问题定义和分析，业务案例开发，可行性研究和方案范围定义目的明确业务战略需要和目标，并建议方案范围任务列表标识业务需要（IdentifyBusinessNeed）确定方案步骤（DetermineSolutionApproach）定义方案范围（DefineSolutionScope）开发业务案例（DeveloptheBusinessCase）任务：标识业务需要（IdentifyBusinessNeed）目的o评估内部和外部环境：内部：定义和提炼当前和将来的业务架构评估当前的技术（基础设施和应用）状态外部：基准分析（Benchmarkanalysis）竞争力分析（Competitivestudies）o完整的定义业务问题和机会输入o业务架构（BusinessArchitecture）o业务目标输出o业务问题和机会（DefinedBusinessProblem/Opportunity）任务：确定方案步骤（DetermineSolutionApproach）目的o找出潜在的方案（Identifypotentialsolutions）o分析可行性（Analyzefeasibilityofoptions）o推荐可行的业务方案（Recommendviablebusinesssolution）o决策者验证（Validatewithdecisionmakers）输入o业务架构（BusinessArchitecture）o业务问题和机会（DefinedBusinessProblem/Opportunity）输出o方案步骤（SolutionApproach）任务：定义方案范围（DefineSolutionScope）目的o上下文图（Contextdiagram）oProductBreakdownStructure输入o业务架构（BusinessArchitecture）o业务问题和机会（DefinedBusinessProblem/Opportunity）o方案步骤（SolutionApproach）输出o方案范围（SolutionScope）任务：开发业务案例（DeveloptheBusinessCase）目的o定义项目目的和期望的业务利益o开发项目范围o评估时间、费用和资源o分析费用vs获利o风险评估输入o业务架构o业务目标o业务问题和机会（DefinedBusinessProblem/Opportunity）o方案范围（SolutionScope）输出o业务案例BABOK-需求获取（Elicitation）描述需求获取描述我们如何与涉众一起协作来发现他们真正的需要，并保证我们正确并完整的理解他们的需要目的探索、标识并文档化涉众需求任务列表准备工作（PrepareforElicitation）开展获取（ConductElicitation）文档化获取结果（DocumentElicitationResults）确认获取结果（ConfirmElicitationResults）任务：准备工作（PrepareforElicitation）目的为需求获取做好准备，确保所有可用的资源都已组织和计划好来进行需求获取活动输入o涉众列表o涉众角色和职责o业务问题/机会或业务案例和方案范围o获取机会输出o计划好的资源（Scheduledresources）o提供支持的材料（Supportingmaterials）任务：开展获取（ConductElicitation）目的涉众调研，获取相关信息输入o提供支持的材料（Supportingmaterials）o业务问题/机会或业务案例和方案范围o组织规范输出o获取活动结果（Elicitationactivityresults）o假设、约束、风险、问题（Assumptions,constraints,risks,issues）o文档，如调研记录、研讨结果、调查反馈等（Documentationbasedontechniquee.g.,interviewnotes,workshopresults,surveyresponses,etc.)任务：文档化获取结果（DocumentElicitationResults）目的记录涉众的需求输入o获取活动的结果（Elicitationactivityresults）输出o文档化的需求（Statedrequirements）任务：确认获取结果（ConfirmElicitationResults）目的o验证涉众要求被正确并完整的理解输入o陈述的需求（Statedrequirements）输出o经过验证的文档化需求（Validatedstatedrequirements）BABOK－需求分析概述描述需求分析描述我们如何逐步详细的定义方案，以便项目团队设计和构建出满足业务和涉众需要的解决方案。目的逐步细化获取后的需求，在特定范围内更清晰的定义需求验证需求是否满足业务需要测试需求，确认需求高质量任务列表组织需求（OrganizeRequirements）划分优先级（PrioritizeRequirements）详述需求和建模（SpecifyandModelRequirements）确定假定和约束（DetermineAssumptionsandConstraints）确认需求（VerifyRequirements）验证需求（ValidateRequirements）任务：组织需求（OrganizeRequirements）目的预计需求的级别，功能的分组等的功能，把需求组织成结构化的逻辑分组。输入o业务案例o方案范围o需求输出结构化的需求任务：划分优先级（PrioritizeRequirements）目的决定需求的优先级，标识需求之间的逻辑依赖性输入o需求o业务案例输出经过划分优先级的需求（Prioritizedrequirements）任务：详述需求和建模（SpecifyandModelRequirements）目的o捕获需求质量属性o使用文字描述需求和通过图形建模输入需求输出详细的或者建模后的需求任务：确定假定和约束（DetermineAssumptionsandConstraints）目的在分析涉众需求时，我们会发现他们的期望不是需求，例如经费限制、开发期限、相关行业法律法规等。假设和约束最大的区别就是一个是确定的，一个是不确定的，约束是项目必须遵循的依据。输入涉众声明（StakeholderStatements）输出假定和约束（AssumptionsandConstraints）任务：确认需求（VerifyRequirements）目的检查需求被正确的、完整的定义出来输入详述或模型化的需求输出确认后的需求任务：验证需求（ValidateRequirements）目的验证需求满足业务需要输入确认后的需求输出验证后的需求BABOK－方案评估和验证概述描述方案评估和验证描述如何评估被提议的方案，检查这个方法是否最合适满足业务需要，标识出不同方案间的区别和优先点，并且决定必须的工作区或者需要更改的地方。目的评估方案，确保满足策略目标，涉众对需求满意任务列表评估需求覆盖率（AssessRequirementsCoverage）分配需求（AllocateRequirements）确定组织意愿（DetermineOrganizationalReadiness）验证方案（ValidateSolution）评价方案（EvaluateSolution）任务：评估需求覆盖率（AssessRequirementsCoverage）目的检查可能的方案是否满足需求，评定结果应该包括推荐的方案、排除的方案或者折衷的方案输入可选的设计方案输出设计方案评估任务：分配需求（AllocateRequirements）目的把需求分派到发布或者方案组件中。这个任务确保可能的发布最大化的满足业务价值，并且可以由设计部门来处理。感觉有点类似与我们做需求优先级划分的工作。o把需求归类到硬件、软件或者人工处理流程等o推荐的产品发布策略o明白在不同实现方法间的折衷处理输入o方案设计o验证的需求输出分配的需求任务：确定组织意愿（DetermineOrganizationalReadiness）目的确定组织对新方案执行的意愿o执行组织意愿评估o优化组织部署的推荐方法输入o业务架构o方案设计输出o组织意愿评定（OrganizationalReadinessAssessment）o组织变更建议（OrganizationalChangeRecommendations）任务：验证方案（ValidateSolution）目的验证被确定和部署的方案是否满足业务需要：o定义验收准则o标识缺点o分析影响o定义校正动作o验证校正动作输入o确认的或部署的方案o验证的需求输出o验证的方案o缺点影响分析（DefectImpactAnalysis）o验证的校正动作（ValidatedCorrectiveActions）任务：评价方案（EvaluateSolution）目的评估方案对业务的价值，比较实际和希望的成本和收益输入部署的方案绩效度量输出成本收益分析BABOK－需求管理和沟通概要描述需求管理和沟通描述我们如何管理冲突、问题、变更，并确保涉众和项目团队在方案范围内保持一致。不同项目的复杂度和方法论支持都不一样，我们需要管理正式评审、基线并跟踪需求文档的版本，还需要跟踪需求到实现的步骤目的认识在所有知识域（knowledgeareas）中发生的沟通对于管理需求来说非常重要管理批准的方案和需求范围确保涉众可以获得业务分析工作交付物准备好和涉众沟通需求有效的重用需求，提高企业一致性任务列表管理方案和需求的范围（ManageSolutionandRequirementsScope）管理需求追溯（ManageRequirementsTraceability）管理需求重用（MaintainRequirementsforre-use）准备需求包（PrepareRequirementsPackage）传递需求（Communicaterequirements）任务：管理方案和需求的范围（ManageSolutionandRequirementsScope）目的业务案例、方案和需求的基线和变更管理o对需求达成一致o基线需求o正式和非正式的需求变更管理o控制需求工件的版本o管理需求冲突和问题输入o涉众角色和职责o需求o需求管理计划输出o认可的需求（ApprovedRequirements）o决策记录（DecisionRecord）任务：管理需求追溯（ManageRequirementsTraceability）目的o需求跟踪o影响分析o支持方案评估和验证中的需求分配输入需求输出可跟踪的需求任务：管理需求重用（MaintainRequirementsforre-use）目的o选择哪些需求在方案实现后还需要维护o确定谁负责维护需求o在影响分析和方案维护中更方便的使用需求o鼓励企业业务模型的一致性，在相关项目中更方便的重用需求输入可实现的需求输出被管理的可重用需求任务：准备需求包（PrepareRequirementsPackage）目的o确认适当的需求格式o生成一个需求包输入o需求o业务分析沟通计划输出需求包（如executivesummary,formaldocumentation,RFI,RFP,etc.)任务：传递需求（Communicaterequirements）目的o在项目初期、中期和后期全过程与涉众交互o每个领域与沟通有关的将都在这里说明o与方案团队沟通，以确保需求被正常的理解和实现输入o需求包o业务分析沟通计划输出沟通过的需求BABOK－业务分析技术概要在前面部分，针对业务分析知识领域的7个组成部分的任务进行了介绍,本篇列出了各组成部分使用到的技术。这里不会对各种技术进行讲解，后面我将会分别对每种技术进行介绍。BAP&M–业务流程计划和监控（BusinessAnalysisPlanningandMonitoring）EA–企业分析（EnterpriseAnalysis）E–需求获取（Elicitation）RA–需求分析（RequirementsAnalysis）SA&V–方案评估和验证（SolutionAssessmentandValidation）RM&C–需求管理和沟通（RequirementsManagementandCommunication）软件需求的三个层次作为技术人员，我们以往更多的关注的是技术，但是在做个多年后，发现做正确的事比正确的做事更重要，而软件中需求的好坏就很大程度决定了你这个软件是否正确，需求确定后不管你如何实现，功能给客户直接带来的价值远远比技术直接带来的价值要高。鉴于需求的重要性，所以后续我将陆续写一些需求相关的博文和大家一起学习探讨，扩充开发人员的需求知识，提高我们应用需求到开发的技能。本篇将从下图所示的软件需求的三个层次开始我们的需求之旅。上图为需求的层次关系图，软件需求包括三个不同的层次：业务需求描述组织或客户的高层次目标，通常问题定义本身就是业务需求。业务需求就是系统目标，它必须是业务导向、可度量、合理、可行的。这类需求通常来自与高层，例如项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求从总体上描述了为什么要开发系统（why），组织希望达到什么目标。一般使用前景和范围（visionandscope）文档来记录业务需求，这份文档有时也被称作项目轮廓图或市场需求（projectcharter或marketrequirement）文档。组织愿景是一个组织对将使用的软件系统所要达成的目标的预期期望。比如“希望实施CRM后公司的客户满意度达到80％以上”就是一条组织愿景。这些最高级别的需求数量很少（2－5条）。以下为前景和范围文档主要提纲：RUP的业务建模流程（BusinessModeling）就属于这个级别，有时我们也叫这些为事理。在这个流程中，业务流程分析员对企业目前的业务流程进行评估，根据要进行的项目得到一个业务前景（BusinessVision），描述项目成功后会的样子，并在涉众范围内达成一致。业务需求层次需要投入的精力视具体项目而定，而业务需求的确定对之后的用户需求和功能需求起了限定作用，任何用户和功能需求都必须符合业务需求。大家可以使用免费的Sam业务流程梳理建模工具软件来进行业务梳理，坦白说我也没有实际真正的使用过这个工具，推荐它是因为它里面提出了用企业价值增值链图(EVC)和企业事件过程链图(EPC)来进行梳理，可能有人说这个工具不如Visio好用，想怎么画就怎么画，其实业务建模重在内容，并且图标需要统一规定。用户需求用户需求是指描述用户使用产品必须要完成什么任务，怎么完成需求，通常是在问题定义的基础上进行用户访谈、调查，对用户使用的场景进行整理，从而建立从用户角度的需求。用户需求必须能够体现软件系统将给用户带来的业务价值，或用户要求系统必须能完成的任务，也就是说用户需求描述了用户能使用系统来做些什么（what），这个层次的需求是非常重要的。用例、用户故事、特性等都是表达用户需求的有效途径。用户需求层次上的重心转移到如何收集用户的需求上，即确定角色和角色的用例，需求分析是很难的，因为很多需求是隐性的，很难获取，更难保证需求完整，而需求又是易变的。功能需求系统分析员描述开发人员在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。功能需求是需求的主体，它描述的是开发人员如何设计具体的解决方案来实现这些需求（how），其数量往往比用户需求高一个数量级。这些需求记录在软件需求规格说明（SoftwareRequirmentsSpecification）中。SRS完整地描述了软件系统的预期特性。SRS我们一般把它当作文档，其实，SRS还可以是包含需求信息的数据库或电子表格；或者是存储在商业需求管理工具中的信息；而对于小型项目，甚至可能是一叠索引卡片。开发、测试、质量保证、项目管理和其他相关的项目功能都要用到SRS。产品特性（feature），是指一组逻辑上相关的功能需求，它们为用户提供某项功能，使业务目标得以满足。对商业软件而言，特性则是一组能被客户识别，并帮助他决定是否购买的需求，也就是产品说明书中用着重号标明的部分。客户希望得到的产品特性和用户的任务相关的需求不完全是一回事。一项特性可以包括多个用例，每个用例又要求实现多项功能需求，以便用户能够执行某项任务。《SoftwareRequirements》举了一个字处理程序的例子来说明需求的这三种不同种类。业务需求可能是：“用户能有效地纠正文档中的拼写错误”，该产品的包装盒封面上可能会标明这是个满足业务需求的拼写检查器。而对应的用户需求可能是“找出文档中的拼写错误并通过一个提供的替换项列表来供选择替换拼错的词”。同时，该拼写检查器还有许多功能需求，如找到并高亮度提示错词的操作；显示提供替换词的对话框以及实现整个文档范围的替换。功能需求除了来自于用户需求，还来自于其它几方面需求：1.系统需求（systemrequirement）用于描述包含多个子系统的产品(即系统)的顶级需求，它是从系统实现的角度描述的需求，有时还需要考虑相关的硬件、环境方面的需求。2.业务规则业务规划本身并非软件需求，因为它们不属于任何特定软件系统的范围。然而，业务规则常常会限制谁能够执行某些特定用例，或者规定系统为符合相关规则必须实现某些特定功能。它包括企业方针、政府条例、工业标准、会计准则和计算方法等。有时，功能中特定的质量属性（通过功能实现）也源于业务规则。所以，对某些功能需求进行追溯时，会发现其来源正是一条特定的业务规则。3.质量属性（qualityattribute）产品必须具备的属性或品质。系统的质量属性包括可用性、可修改、性能、安全性、可测试行、易用性和McCall体系等4.约束（constraint）约束也称为限制条件、补充规约，通常是对解决方案的一些约束说明。三个层次的开发关系这三个层次按照通俗一些的话来说，可以表示为下图：在软件开发过程中，最为重要的“用户需求”往往和数量巨大的”功能需求“混淆在一起，这会让太多没有直接提供业务价值的需求充斥在需求阶段，这会导致没有突出重点而忽视重要的业务特性,这对业务分析来说是非常有害的。所以在开发过程中，很有必要加强认识并区分开来，有的开发平台（如普元）对三个层次的需求就区分开来，如下图的构件种类对应关系：需求工程＝需求开发＋需求管理上图是需求工程的组成部分，从图中可以看出，需求工程划分为两个部分：需求开发和需求管理。需求开发又分为需求获取（Elicitation）、需求分析（Analysis）、编写规约（Specification）和需求验证（Validation）。需求管理又分为基线管理、变更管理、需求跟踪。下面我将分别介绍一下上面各个主要组成部分主要的工作内容，以便那些不熟悉需求的人员读后能够从总体上把握需求所涉及的工作内容。需求开发需求开发活动包括以下几个方面：1.确定产品所期望的用户分类。2.获取每类用户的需求。3.了解实际用户任务和目标以及这些任务所支持的业务需求。4.分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息。5.将系统级的需求分为几个子系统，并将需求中的一部份分配给软件组件。6.了解相关质量属性的重要性。7.商讨实施优先级的划分。8.将所收集的用户需求编写成规格说明和模型。9.评审需求规格说明，确保对用户需求达到共同的理解与认识，并在整个开发小组接受说明之前将问题都弄清楚。实际工作中很难一次性得到完全正确的需求，所以以上步骤并不是严格顺序执行到底的，它是一个不断反复的过程。这些步骤也不是完全顺序的，很可能需要迭代的进行。基于项目的产品需求开发过程可能如下图所示：在软件开发过程中，当你想了解具体需求时，有些客户会说没有时间，这时需要和客户建立一种合作关系，具体来说：客户权利：1.要求分析人员使用符合客户语言习惯的表达。2.要求分析人员了解客户系统的业务及目标。3.要求分析人员组织需求获取期间所介绍的信息，并编写软件需求规格说明。4.要求开发人员对需求过程中所产生的工作结果进行解释说明。5.要求开发人员在整个交流过程中保持和维护一种合作的职业态度。6.要求开发人员对产品的实现及需求都要提供建议，拿出主意。7.描述产品使其具有易用、好用的特性。8.可以调整需求，允许重用已有的软件组件。9.当需要对需求进行变更时，对成本、影响、得失有个真实可信的评估。10.获得满足客户功能和质量要求的系统，并且这些要求是开发人员同意的。客户义务：1.给分析人员讲解业务及说明业务方面的术语等专业问题。2.抽出时间清楚地说明需求并不断完善。3.当说明系统需求时，力求准确详细。4.需要时要及时对需求做出决策。5.要尊重开发人员的成本估算和对需求的可行性分析。6.对单项需求、系统特性或使用实例划分优先级。7.评审需求文档和原型。8.一旦知道要对项目需求进行变更，要马上与开发人员联系。9.在要求需求变更时，应遵照开发组织确定的工作过程来处理。10.尊重需求工程中开发人员采用的流程（过程）。下面就需求开发每个活动进行简单介绍：需求获取在《软件需求的三个层次》中介绍了三个层次的需求，在需求获取中，这些需求都是我们需要获取的，我们需要收集问题域的描述，要求解决的问题列表，以及了解系统的行为或约束。信息来源客户（实际的和潜在的）用户（实际的和潜在的）已有系统及其文档领域专家相关技术标准和法规获取技术阅读背景资料用户访谈、调研需求讨论会现场观摩需求分析需求分析是指通过对需求获取中获得的问题域的研究，获得对该领域特性及存在其中的问题特性的透彻理解并用文档说明。不需要等到需求完全捕获后开始，在“业务需求”充分理解下，并且收集了本质的“用户需求”之后就可以开始进行需求分析交替进行，先把握“用户需求”主要部分，然后在分析的基础上引入系统级的需求（系统的涉及与实现角度），并且分析模型，成为开发人员之间、开发人员与客户之间达成共识的一个平台分析的基础上，就会发现更多的不明确项，更多待捕获的信息，这时就可以生成第二次的需求调研计划、问题和素材编写规约规格说明书是对需求分析结果的文档化过程需求规约必须与实际开发紧密结合，否则很容易造成与开发脱离为需求规约定义统一的格式是一个很重要的工作规约内容必须严谨、正确、无歧义需求验证不重视需求验证工作会在系统交付时，客户发现不是这样的，导致不期望的需求变更提高需求质量的重要手段有：需求评审、需求确认和原型验证《需求方法之－原型开发》需求管理需求管理活动包括：1.定义需求基线（迅速制定需求文档的主体）。2.评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它。3.以一种可控制的方式将需求变更融入到项目中。4.使当前的项目计划与需求一致。5.估计变更需求所产生影响并在此基础上协商新的承诺（约定）。6.让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪。7.在整个项目过程中跟踪需求状态及其变更情况。用Kano模型来确定需求优先级在《敏捷估计和规划》一书中，在确定合意性优先级一章中专门介绍了这个模型，这个模型可以作为我们确定需求优先级的一个参考。KANO模型定义了三个层次的顾客需求：基本型需求、期望型需求和兴奋型需求。这三种需求根据绩效指标分类就是基本因素、绩效因素和激励因素。客户满意度模型Kano1.基本型需求：顾客认为产品“必须有”的属性或功能。当其特性不充足时，顾客很不满意；当其特性充足时，对客户满意度没有多少影响，顾客充其量是满意。例如只要酒店浴室满足了我的基本需要，我并不会关心洗漱台的台面是用什么材料制作的。2.期望型需求：要求提供的产品或服务比较优秀，但并不是“必须”的产品属性，有些期望型需求连顾客都不太清楚，但是是他们却希望得到的。顾客通常谈论的是期望型需求，期望型需求又叫做线性需求，这类需求越多越好。线性需求在产品中实现的越多，顾客就越满意，当没有满意这些需求时，顾客就不满意。因此，产品的价格通常和线性特性相关。如果酒店有健身器材，我会更加高兴，相比没有这类器材的酒店，我下次可能就会在此入住这里。3.兴奋型需求：提供给顾客一些完全出乎意料的产品属性，使顾客产生惊喜。兴奋点和惊喜点常常是一些未被用户了解的需求，客户在看到这些功能之前并不知道自己需要它们。当其特性不充足时，并且是无关紧要的特性，则顾客无所谓，当产品提供了这类需求中的服务时，顾客就会对产品非常满意，从而提高顾客的忠诚度。这类需求可以为产品增加额外价格。评估需求类型在应用这个模型时，需要注意随着时间的发展，功能会在模型中向下移动。例如手机彩屏以前是期望的，而已经是必须的。所以需求的正确归类非常重要。使用Kano模型最简单的方法就是考虑每个主题或故事，对它所属的类型进行讨论。我们可以设计一套问卷，对用户进行问卷调查。Kano建议通过对一个功能问两个问题来确定分类：一个问题是如果产品中有这个功能，用户会觉得如何；另一个问题就是如果功能不存在，用户又是觉得如何。对每个问题采用5点的度量方式进行回答：1.我希望这样2.我预期这样3.我没有 意见 文理分科指导河道管理范围浙江建筑工程概算定额教材专家评审意见党员教师互相批评意见 4.我可以忍受这样5.我不希望这样经过调查后根据下图的归类矩阵，将问题进行归类来确定需求的类型Kano模型分析这3种不同类型如下图所示：由图可以看出，右下方箭头：一旦实现了一定数量的必须功能，就无法再通过增加这类功能来提高客户的满意度了。无论增加多少必须功能，客户满意度都不会超过中点以上。左上方箭头：只是实现一部分兴奋点就可以明显的提升客户满意度，这也是为什么企业把追求卓越作为企业的价值观之一中间的箭头：期望型功能的增加和客户满意度呈线性增长，所以这类需求越多越好通过以上分析，我们会对这三类需求分别对待：1.对于必须完成的功能，在产品发布时需要完成，但并不是要求在第一次迭代时就开发完成。2.完成尽可能多的线性需求3.如果时间允许，至少应该确定少量的兴奋点优先级，把它们包含进发布计划原型开发为什么需要原型建立原型的主要原因是为了解决在产品开发的早期阶段不确定的问题，利用这些不确定性来判断系统中哪一部分需要建立原型和希望从用户对原型的评价中获得什么。原型可以使他们的想象更具体化，有助于说明和纠正这些不确定性，总的来说通过原型法可以很好的减少项目风险。水平和垂直的原型我们和业务人员经常谈到的是水平原型，水平原型也叫做“行为原型”(behavioralprototype)。探索预期系统的一些特定行为，并达到细化需求的目的。当用户在考虑原型中所提出的功能可否使他们完成各自的业务任务时，原型使用户所探讨的问题更加具体化。它更多从业务需求着手，应用在需求阶段。垂直原型（verticalprototype），也叫做结构化原型或概念的证明，实现了一部分应用功能。当预期实现阶段可能存在技术风险时，可以开发一个垂直原型。垂直原型通常用在生产运行环境中的生产工具构造，使其结果一目了然（更有意义）。比起在软件的需求开发阶段，垂直原型更常用于软件的设计阶段以减少风险。抛弃型原型或进化型原型从原型存在生命时机考虑分为抛弃型原型和进行型原型，抛弃型原型不作为最终产品的一部分，只是作为探索性的回答一些需求问题，细化需求并提高需求质量。由于在开发阶段最终将抛弃这些原型，因此不需要花太大力气去建立该原型。进化型原型是在已经清楚地定义了需求的情况下，为开发渐进式产品提供了坚实的开发基础，作为产品的部分实现。与抛弃型原型的快速、粗略的特点相比，进化式模型一开始就必须具有健壮性和产品质量级的代码。因此，对于描述相同的功能，建立进化型原型比建立抛弃型原型所花的时间要多。一个进化型原型必须设计为易于升级和优化的，因此，你必须重视软件系统性和完整性的设计原则。要达到进化型原型的质量要求并没有捷径。进化型原型一般在处理架构时会采用。低保真原型和高保真原型原型分低保真原型和高保真原型，低保真原型目标在于表达工作主要内容，体现静态的元素，不需要动态交互。高保真原型目标是作出一个和实际上线后的产品差不多的样子，不仅包括静态的界面，还包括交互，甚至有的还把数据保存、逻辑验证等都包含在内。如果客户要求开发之前必须看到和实际产品一样的原型时，这时就需要做高保真原型，如果对于小型项目，或者只是用来做交流主要需求用时，就可以做低保真原型。原型工具需求在产品开发中的重要性已经是不需争议的事实，现在需求方法有很多，业界最常用的一种办法就是通过原型展现需求，通过用例表达需求。业务人员掌握制作原型能够更快更清楚的表达业务，同客户和开发可以进行更直观的沟通，使得大家在理解上容易更一致。然而原型工具有非常多，比如大多数人用过的Excel、Access、Delphi、PowerPoint、Axure、BalsamiqMockups、ForeUI、iRise、LucidSpec、MockupScreens、Pencil、Serena等，甚至开发工具雅奇等也可以用来做原型。工欲善其事，必先利其器，对于刚刚使用原型方法的业务人员来说，如何选择适合自己的原型工具呢？这就需要首先根据原型的目的明确做原型的粒度。在限定时间内能够将需求表达更清晰需要一个合适的工具。业务人员一般都不会有什么编程经验，我们怎么能够做出表达静态元素界面，又能加入动态交互功能的原型呢？为了能在需求阶段都能够更好的采用原型开发方法，我搜集并使用过多种原型工具，希望找打一款比较使用简单，但又能实现一般的交互功能，最好是业务人员学个一个小时就可以完全自己动手使用了。我用过一个原型工具GUIDesignStudio，它的主要特点就是操作简单，不需要开发人员帮助，通过半个小时的学习后你将可以自己开始做原型了。《原型工具GUIDesignStudio》对这个工具的使用进行可简单介绍。原型不仅仅是界面我们可以通过原型来引导用户来使用系统解决问题，但原型不仅仅是需求，它还是设计、开发工具，所以作原型时不仅需要客户的参与，也需要技术人员的参与，但应该尽量由业务人员而非开发人员来实现原型的需求部分。下面是在UCD社区里面看到的一张图，原型最主要功能是表现界面，但要做好界面其实不容易，山下面还有很多东西需要考虑才能支撑界面，其实做原型的过程就是设计系统的过程。我们都希望尽量把开发工作前移，需求能做的工作就不留到开发环节做。如果软件模式一定，那么框架做得好的话就一定可以让业务人员来做一部分现在属于开发人员的工作（注：这部分工作其实本就该属于业务人员），那时大家就能体会到开发软件就如同做原型一样的乐趣了！OpenExpressApp对原型的支持细心的读者在《OpenExpressApp架构－信息系统开发平台》中的Roadmap图中能看到右边的OpenTool中包括对原型的支持。OEA关注点更多的是从软件工程向业务工程的转移，所以和业务相关的原型会作为一个重点工具来考虑。使用原型有三个主要目的：1.作为一种需求工具，明确并完善需求原型，它初步实现所理解的系统的一部分。2.作为一种设计工具，探索设计选择方案原型，探索不同的用户界面技术，使系统达到最佳的可用性，并且可以评价可能的技术方案。3.作为一种开发工具，发展为最终的产品原型，是产品最初子集的完整功能实现，通过一系列小规模的开发循环后可以完成整个产品的开发。OEA的原型工具将会考虑集成需求工具、设计工具和开发工具与一体，由业务需求人员、设计师和开发人员在OpenExpressApp平台下进行连贯的开发，它做的是水平、进化型、高保真原型。获取需求方法：NineBoxes在《需求入门：需求工程＝需求开发＋需求管理》中介绍过，需求开发中可以通过用户访谈进行问题获取，本篇介绍一个进行用户访谈的方法：NineBoxes9格方法通过三个方面（列）和三种提问方式（行）组合成9个格子，它要求我们按照上图的数字顺序来进行，对每个问题进行沟通，可以把以前没有系统化的访谈方式更好的组织起来，帮助我们整理和清晰谈到的内容。三个方面1.定义问题这可以帮助客户确定问题，一起讨论。可以从组织结构、岗位职责等了解总体的工作情况，对于具体问题，可以更有针对性的设计问题。2.标识涉众产品解决的价值一定是与人相关的，这可以很好的把涉众标识出来。3.描述愿景这可以初步确定产品成功的目标，注意，这里不会谈到具体的问题解决方案，而只是一旦问题得到解决后，会有什么样的场景。三种提问方式1.Open这类问题属于开放式问题，可以这样提出来，”告诉我...“，”请描述一下...“”这样发生什么了？“等故事情节问题2.Control这类问题属于封闭式问题，如多少（如一张入库单有多少条明细）、什么频度（如多久填写一个单子）、在哪里等一些事实问题3.Confirm这个步骤很重要，因为有可能会引起对方思考之前他没有提及的事情。如果发生这种情况，你应该返回之前的步骤重新开始。用户故事当我们使用9格访谈后，会发现这些内容可以直接应用在用户故事中。在《Scrum之roductBacklog》中我简单讲了一下在Scrum方法中如何描述用户故事的一般写法是：作为【用户的类型】，我希望可以【先这样做，然后那样做，就应该得到...的结果】以便【业务价值】。为客户着想在进行访谈过程时，我们需要做到的三个方面是：为客户着想，了解客户期望和积极倾听。下面一副漫画可以很好的表达这个意思：（鱼饵就应当符合鱼儿的胃口，而不是钓鱼者）确定优先级的四个因素敏捷估计与规划中对优先级进行了描述，优先级由以下四点因素来确定。1.获得这些功能带来的经济价值2.开发（可能包含支持）新功能所需的成本3.开发新功能所产生的学习和知识的量及重要性4.开发这些功能所减少的风险用户经验曲线在设计软件功能时，我们会针对涉众来分析该功能应该如何实现。需求中涉众分析的重要性大家都知道，但是在设计软件时，我们也需要知道同一个用户在使用软件不同阶段会有不同需求，本篇描述了存在三类软件用户：新手（Novice）、胜任者（Competent）、专家（Expert），在设计大多数软件时，我们应该把关注点更多的放在Competent阶段。用户经验曲线有一阵子我们组迷上了魔方，人手一个，我也会玩了，起初几天时间处于看着公式的初级阶段，然后到了一般人的阶段，可以不需要看着纸条就能拼出来，但是我在最快也就是2分多种，我想我是不会成为下图最右边那位魔方高手一样的。另：在最后我将附上我的魔方不传秘籍给大家。学开车过程也是一样，我也花了好几周去学车，处于初学者阶段，虽然现在还没有买车，但我想开熟练了肯定就和骑自行车一样了，作为一个普通司机我也是可以胜任的，但我肯定不会变成专业赛车手。新手：临时状态胜任者：一般状态，是初学者执行相同任务时间的一半专家：极少数，是初学者执行相同任务时间的10％大多数用户是大众（competent）的用户就像商业策划、市场细分时我们也会对不同用户群进行分析，开发软件过程中，我们还需要认识到同一个用户所处的不同阶段。在设计软件时，我们需要记住大部分用户既不是初学者，也不是高级用户，更多的还是能胜任工作的大众用户。一般初学者在经过重复工作的经验下会变为可以胜任的用户，但是只有很少一部分会成为专家，大部分用户只是为了真正的工作需要而学习。针对不同阶段的用户，我们设计重点也会不同。对于大部分产品来说，大多数用户都是胜任者用户，我们分析这类产品需求时需要把针对胜任者用户的需求优先级定得高点，简单地拿一个功能来说，经常听人说这个易用性不行，但是我们是否真的要想尽办法支持让初学者不学软件就会使用呢？还是着重考虑用户在熟练操作方式下呢？如果如果我们把更多的精力注意在初级者和专家级用户需求时，我们就会往往会不自然的以忽略大众用户为代价，这时对产品来说就偏离重点了。虽然大部分用户是胜任的用户，但是有些应用必须着重考虑初学者。比如不是频繁使用的软件，或者想吸引大量网民的网站，这类产品如果忽略初级用户，这将会给产品带来致命性的打击，因为不能快速学习使用的产品会让他们马上转移到其他产品中去。也有一些产品必须考虑专家用户，这类产品本身追求的就是差异化，比一般产品能做更多事情，做事方式也更具复杂性。参考：CompetentUsersandSoftwareRequirementsDefendingPerpetualIntermediacyModelingUserCompetency魔方不传秘籍：第二层：逆时针：R’U’R’U’R’URUR顺时针：RURURU’R’U’R’第三层：十字：FRUR’U’F’一面：逆时针：不转在右边L’U’LU’L’U2L（固定一个，作用3个相同方向）顺时针：不转在左边RUR’URU2R’四角：对换在左边R2F2R’B’RF2R’BR’U’对好十字：顺时针：中间在前面RUR’URU2R’U-L’U’LU’L’U2LU’逆时针：中间在前面L’U’LU’L’U2LU’-RUR’URU2R’U附一：业务流程梳理工具Sam以前看到过一个流程梳理工具，还没有细研究，但感觉还行，推荐给大家梳理流程用。安装文件链接，安装前需要安装JDK炎黄盈动是中国最早专业定位于BPM平台与解决方案领域的实践者。Sam是主要由炎黄盈动开发和维护的一款业务流程梳理建模工具软件，可以永久性的免费使用和不以盈利为目的的分发这个工具。Sam为梳理业务流程提供了一个建模框架体系，使用了企业价值增值链图(EVC)、企业事件过程链图(EPC)模型，把企业的业务流程梳理分为五个层次，让用户清晰、完整的通过不同视角勾勒现实的业务流程或优化后的业务流程。我们现在可以使用它来梳理客户的业务流程，统一存放在一个项目，而不用每个流程单独一个visio文件。这些模型可以导入到他们的开发平台进行产品开发。要画好这些图比较难，但如果我们能画好这些图，相信对理清需求和后续开发都很有好处。业务流程五个层次流程梳理工作方法附二：原型工具GUIDesignStudio制作原型是业务人员应该掌握的一项基本技能，这篇主要给大家介绍一个我认为比较好的一个工具：GUIDesignStudio，大家可以到官方网站下载试用，如果用于个人学习，也可以上网搜到破解：）软件帮助文档有个记事本的例子,如果参考做完就能大致了解如何做原型了.下面我主要示例一个管理软件常用的界面模式，登录后显示主界面，主界面上面一个公司图标，左边为一个功能列表，点击列表时在工作区页签显示相应的模块窗体。做了一个视频,方便大家更好的快速了解.主界面上面为菜单和工具条，工具条主要用的就是连接线，菜单主要用的是Design－Addbitmap添加图片（我也是刚找到的，应该在右边Elements上更好）右边为界面元素和文档目录管理：Project：管理文件目录层次，可以在根目录下放主界面，然后把功能模块分系统新建多个目录保存。对于界面窗体比较多时，尽量按照模块目录分类来保存，千万不要放在一个页面中设计，否则以后就不好维护了。Element：界面元素，比如按钮、工具条等界面展现的控件Icon：图标，可以软件的安装目录里加入自己的图标后应用在项目中Storyboard：增加动态控制界面元素的动作控件。用的最多的是windowsplaceholder，主要来做显示在Tab页的内容，可以查看软件的帮助文件的索引Workingwithtabbedinterfaces进一步了解Note：给控件加标题和注释，如果加了注释，在原型运行时鼠标放在＃上会显示提示原型工具blog链接：产品经理实用工具【7】-客户端原型GUIDesignStudio线框图-原型可视化用FlashCatalyst做交互原型RapidPrototypingToolsRevisited10款交互设计原型开发工具 目录 前言 BABOK-业务分析知识体系介绍 BABOK-BA计划和监控概要 BABOK－企业分析概要 BABOK-需求获取（Elicitation） BABOK－需求分析概述 BABOK－方案评估和验证概述 BABOK－需求管理和沟通概要 BABOK－业务分析技术概要 软件需求的三个层次 用Kano模型来确定需求优先级 原型开发 获取需求方法：NineBoxes在 确定优先级的四个因素 用户经验曲线 附一：业务流程梳理工具Sam 附二：原型工具GUIDesignStudio