62681《软件需求分析（微课版）》第2章

第2章软件需求开发流程目录CONTENTS软件需求开发基本流程01战略分析02定义业务需求03识别用户类型04获取用户需求05分析整理需求06整理系统涉及的数据需求07识别其他非功能性需求08记录需求09需求确认10软件需求开发基本流程软件需求开发不太可能一蹴而就，他是一个循环迭代、持续更新的过程。需求获取需求分析需求定义需求验证澄清需求补缺需求重写需求重新评估确认及更正软件需求开发基本流程由于软件开发项目和团队文化的差异，需求开发过程迄今为止没有一个公式化的套路。需求开发中的重要步骤：（1）战略分析；（2）定义业务需求；（3）识别用户类型；（4）获取各类用户需求；（5）理解用户需求，得出功能需求；（6）为需求建模；（7）整理系统涉及的数据需求；（8）识别其他非功能性需求；（9）记录需求；（10）需求确认。战略分析（1）用一个“故事”来说清楚项目的来由，这就是项目背景。（2）该项目能帮助甲方实现哪些核心价值？（3）该项目对甲方的重要性如何？A、生存需求：该项目关系到甲方的生存问题。B、核心发展需求：该项目有利于甲方提高核心领域的生产力和竞争力。C、次要发展需求：该项目对甲方的生产力和发展不产生重要影响，但有利于甲方解决一些具体问题，或有助于改善核心领域的工作。D、面子需要：该项目有利于企业或领导的“政绩”。战略分析（4）要成功完成这个项目，甲方有哪些有利条件和不利条件？（5）要成功完成这个项目，乙方有哪些有利条件和不利条件？（6）乙方应以怎样的战略来应对这个项目？A、全力以赴，满足甲方需求，哪怕牺牲自身利益。B、花费合理的乙方成本，满足甲方的基本需求，超出乙方当前承受范围的，引导甲方做“下一期”。C、仅满足甲方非常紧迫的需求，为维持客户关系而勉强做这个项目，不得罪客户，但保证乙方不亏本或只稍微亏本。D、不做这个项目。定义业务需求业务需求反映了组织机构或客户对系统、产品高层次的目标需求。业务需求是软件系统建设的目标。用户需求和功能需求必须与业务需求建立的背景和目标保持一致。任何无助于项目达成业务目标的需求都不宜实现。业务需求一般会定义解决方案的愿景和实现该方案的项目范围。愿景需要简要描述最终产品要达成什么业务目标，后续需求分析，项目实施都得围绕这一目标展开。项目范围明确当前项目或迭代版本需要完成的各项具体工作的简明描述。恰当的范围界定对于项目成功是十分重要的。定义业务需求–定义愿景产品愿景是项目负责人对项目未来前景和方向的一个高度概括描述，它应符合公司或组织的战略目标。产品愿景是整个项目的目标，好的产品愿景要回答以下几个问题：（1）产品是什么？（2）产品的目标客户是谁？（3）产品满足了什么需求或达成了什么目标？（4）产品的类型是什么？（5）产品的主要功能或主要收益是什么？（6）竞争对手是谁？（7）如何满足用户需求并超越竞争对手？定义业务需求–愿景声明模板针对【目标客户】对象【陈述需求或机会】产品【产品名称】是【产品类型】具体的【主要功能、关键收益、吸引人使用的理由】不同于【主要当前系统、当前业务过程或竞争产品】【陈述新产品的主要不同点和优势】定义业务需求–愿景声明案例某留学交流中心因为业务扩展，每日咨询量增加迅猛，客服人员即便每天加班，也没法及时回复所有咨询人员的问题。为了能降低工作人员的压力，同时也能及时响应咨询人员，留学交流中心希望在官网上增加一个在线咨询的聊天机器人，从而减少人工咨询数量，并能及时响应咨询人员的问题。目标客户：留学交流中心产品名称：聊天机器人主要优势：减少人工咨询数量，降低留学交流中心工作人员的压力，并能及时响应留学咨询人员的问题。主要功能：管理人员通过预先输入大量问题及解答后，留学咨询人员可以通过点击在线咨询，输入自己的问题，与聊天机器人一对一的聊天。业务需求：及时响应留学咨询人员的问题定义业务需求–愿景声明案例针对留学交流中心咨询量较大，客服人员不能及时响应的问题，聊天机器人是一个用来模拟对话或聊天的程序。管理人员通过预先输入大量问题及解答后，留学咨询人员可以通过点击在线咨询，输入自己的问题，与聊天机器人一对一的聊天。不同于当前单一的人工咨询模式，聊天机器人可以减少人工咨询数量，降低留学交流中心工作人员的压力，并能及时响应留学咨询人员的问题。定义业务需求–产品愿景确认在确定产品愿景之后，检查愿景是否回答了前面提到的七个问题。检查后要与项目干系人确认，然后根据其反馈进行修改。修改之后，要把产品愿景发给项目团队中的每个人，保证团队都理解并认可产品愿景。在整个研发过程中，团队都需要产品愿景来指引方向，有时产品愿景甚至可以作为判断一个需求要不要做的有力依据。每隔一段时间根据业务需要和市场变化对愿景声明进行审核与修改。定义业务需求–项目范围和限制如果对项目的范围界定不够清晰，很可能掉入需求蔓延的陷阱。项目范围的定义为需求是否属于该项目划定了界限，它确定了项目需要实现的功能，以及实现这些功能会有些什么限制。也可以把项目范围的定义细分成范围和限制。范围为提议解决方案的概念和适用领域进行描述。限制则指出产品不包括的某些性能。范围最终是在计划某个具体的版本的一组功能需求定义的。在每个层面，范围必须限定在上一级的边界范围内。业务需求用户需求功能需求定义业务需求–首发版的范围在1.0版本中，应该关注在最快的时间允许的范围内、以最能接受的成本、向最广大的群体提供最多价值。首发版中也需要关注非功能性需求。一个快递APP的1.0版本并不要求快速、漂亮或易于使用，但必须可靠。定义业务需求–后续版本的范围项目范围中可以包含多个后续迭代版本的范围。后续版本会实现更多的用例和特性，不断的扩充和丰富首发版。定义业务需求–限制和排除限制和排除项目范围之外的内容需要列出干系人期望但不计划纳入在产品范围或特定版本中的产品功能和特性。对范围的任何更改都必须经过完整的更改控制程序，以确保团队只在他们需要做的事情上工作。定义业务需求–范围变更当客户提出新的需求时，需求分析师应该首先考虑：“这是在当前版本范围内吗？”客户需求分析师这是在当前版本范围内吗？（1）该需求明显超出范围。（2）该需求明显在项目定义的范围内。（3）新需求虽然超出了范围，但是它是一个很好，很适用的需求。当前版本后续版本?识别用户类型产品的用户可能在以下方面有差别，基于这些差别，可以将用户分成不同的用户群。他们的访问权限和安全级别。他们在业务操作中执行的任务。他们使用的特性。他们使用产品的频率。他们在应用领域和计算机专业技能方面的经验。他们使用的平台（台式机、笔记本、平板、智能手机和定制设备）。他们的母语。他们是直接还是间接与系统交互。识别用户类型在项目早期阶段识别并划分出用户类别，以便从各个重要的用户类别代表那里获取需求。这里推荐一种“发散后聚拢”的方法。第一个阶段，首先，问项目出资人谁会使用系统，然后，通过头脑风暴列出项目尽可能多的用户类别。在这个阶段，即使列出几十个也不要怕，重要的是不要遗漏用户类别。第二个阶段，识别有相同需求的用户，把他们归为一类，试着将这个列表缩减到15个不同的用户类别以下。识别用户类型在第二部分可视化需求建模中会介绍组织结构图，借助组织结构图我们可以更加从容的识别出用户类型。分析组织结构图可以降低遗漏组织内重要用户群的可能性。它可以指引你找到特定用户群的代表，还能帮你确定谁可能是核心的需求决策人。识别用户类型一种用户类别在系统中实际上对应了一种角色，记录这些角色的所有相关信息，如角色名，角色人数，角色承担的事情等，可以通过列表的方式进行展示。下表是聊天机器人项目的用户角色表。角色名角色人数角色描述信息技术部负责人1人负责所有中心系统的采购和运维。在线客服10人+负责在线回答留学人员咨询的问题。他们有相关的培训手册，里面记载了留学人员的常见问题。但是对于一些个例性的问题他们通常需要咨询项目主管或其他相关人员。项目主管30人+不同国家涉及多个不同的项目。每个项目主管一般负责1个国家或几个相邻国家的项目。针对美国、英国等留学项目较多的国家，可能涉及多个项目主管负责同一个国家的情况。每个项目主管负责收集整理各项目相关的法律法规、相关政策等。他们对自己负责的项目情况非常了解。他们会评审留学项目，给留学人员办理相关的留学资助、留学目的地变更、留学期限变更等事务。留学咨询人员5000+人咨询留学项目，留学申请流程等。获取用户需求--用户访谈用户访谈是获取用户需求常用的一种方法。用户访谈是一种研究型的交谈，它运用有目的、有计划、有方法的口头交谈方式，对有意识要获得的资料进行收集和梳理。无计划、无目的、无主题有计划、有目的、有主题无时间规划有明确的时间安排及进程可以无需互动、无需真实必须有良好的互动且力求真实可随意符合不随意赞同或评价无记录、无总结有记录、有总结普通谈话用户访谈获取用户需求--用户访谈前明确研究目标1招募访谈对象23准备访谈内容4建立融洽关系获取用户需求--用户访谈中取得用户信任1聚焦访谈主题23探究用户想法4避免诱导性问题说他们的语言5鼓励现场演示67记录访谈过程获取用户需求--用户访谈后梳理访谈过程1问题确认，持续迭代2获取用户需求--焦点小组焦点小组又称小组座谈法，是由一个经过训练的主持人与一组用户代表进行交谈，从而获得对有关问题的深入了解。当时间比较短，同时资源又很有限的时候，如果想尽快获取到用户的问题，可以采用“焦点小组”法。焦点小组的主要目的是倾听被调查者对研究问题的看法。被调查者选自研究的总体人群。焦点小组的优点在于，研究者常常可以从自由讨论中得到意想不到的发现。之所以强调焦点，是因为焦点小组集中在一个或一类主题，用结构化方式揭示目标用户的经验、感受、态度，并努力呈现其背后的理由。获取用户需求--焦点小组焦点小组的实施过程一般包括以下几步：（1）征选用户代表。（2）征选主持人。（3）编制讨论指南。（4）访谈。（5）访谈总结。获取用户需求–现场观察如果让用户描述他们的工作，他们可能会遗漏一些细节或者表达得不够准确。照成这个问题的原因一般可能有多方面：（1）用户的专业背景和需求分析者不一致。（2）任务太过复杂，用户很难记住每一项细节。（3）用户对任务太熟悉了，反而无法将其所有的步骤清晰的表达出来。获取用户需求–现场观察去现场观察用户，能够获取到更多需求。但是现场观察通常比较耗时，因此不适合所有用户或所有任务。可以选择重要或高风险任务以及多个用户类别来观察。现场观察时需要注意以下几点：（1）为了不干扰用户日常的工作安排，尽量将每次观察的时间限制在2小时以内。（2）做好记录，尝试理解用户实际使用计算机系统和处理事务的细节。（3）像用户一样使用系统和参与实际工作，发现关键问题和瓶颈。观察结束后，需要对观察到的用户活动进行提炼总结，保证捕获到的需求能够从整体上应用于该类用户，而不是只针对个体。获取用户需求–问卷调查用户访谈的数量一般有限，如果希望针对更大群体的用户收集需求，可以进行问卷调查。根据载体的不同，问卷调查可分为纸质问卷调查和网络问卷调查。纸质问卷调查就是传统的问卷调查，调查者通过雇佣工人来分发这些纸质问卷，以回收答卷。这种形式的问卷存在一些缺点，分析与统计结果比较麻烦，成本比较高。而另一种网络问卷调查，就是用户依靠一些在线调查问卷网站，这些网站提供设计问卷，发放问卷，分析结果等一系列服务。这种方式的优点是无地域限制，成本相对低廉，缺点是答卷质量无法保证。目前国内的问卷网、问卷星、调查派等公司提供了这种方式。获取用户需求–问卷调查问卷调查的关键在于问题的设计。设计问卷之前也需要明确两点，一是问卷调查的目的，二是问卷调查的人群，不要指望一次调查搞定所有用户。针对不同类型的用户，可以设计不同的问卷调查。问卷设计中我们需要注意以下几个问题：（1）问卷调查最好以多选题开始。（2）问卷调查的时间最好不要超过15分钟。（3）在问题中不要有所暗示。（4）问题的答案应该尽量穷举，且答案之间应该互斥。（5）设计的答案应该是用户愿意回答，尽量不要涉及用户隐私。获取用户需求–竞品分析竞品是竞争对手的产品，竞品分析顾名思义，是对竞争对手的产品进行比较分析。竞品分析也是一种常用的需求挖掘方法。进行竞品分析有利于我们及时对自有产品进行查缺补漏，也有利于取其精华去其槽粕。那么我们如何去做竞品分析呢？一般情况下，并不需要花几个小时去写上一篇详细的竞品分析报告，重点关注以下几点就行：（1）竞品是否有新上线的业务，上线背后逻辑是什么？（2）竞品的上线产品的评论及用户反馈。（3）竞品的前端对应后台的管理需求、操作需求、配置需求。获取用户需求–用户反馈用户反馈，是产品与用户沟通的渠道，是需求从收集，到实现，到反馈的闭环过程。只有不断收集用户反馈，持续改进，才能让用户更好的接受产品。在这个过程中，不仅解决了用户的问题、收集了产品需求，更重要的是建立了用户与产品之间的情感关联。用户反馈可以通过多种渠道获取：（1）社交平台，比如微信，微博，知乎，贴吧，论坛等。（2）应用商店，比如APPStore、豌豆荚等应用商店。（3）内部渠道，比如客服咨询、反馈投诉等。分析整理需求获取需求时不要指望客户会给你一份清晰、完整的需求清单。客户在描述需求时常常会将很多信息混杂在一起，需求分析师必须对听到的各类信息进行归类整理，层层分解，最终转化为可以进行工程实践的功能需求。分析整理需求1.业务需求如果客户描述其希望从产品中获得资金、市场或者其他有业务利益，则可以归入业务需求。注意倾听体现软件购买方或者用户预期价值的陈述。示例如下：“在n个月内将x区域内的市场份额提升m个百分点。”“通过去除无效的浪费，每年可以节省x万元开销。”分析整理需求2.用户需求对用户目标或者用户需要完成的业务任务的总体陈述。例如“我需要<做什么>”可能就是在描述一个用户需求。示例如下：“我需要为每一台设备制作一个二维码。”“作为实验室管理人员，我需要为每一门实验课程分配实验教室。”分析整理需求3.业务规则当客户说只有特定的用户在特定的环境下才能去做某项活动时，他可能是在表述一个业务规则。例如，“必须要符合……,”“必须要依据……,”“如果<某些条件属实>，那么<就会发生某些事情>”。业务规则虽然并不代表软件需求，但可以从中引出一些功能需求的前置条件。示例如下：“用户必须登录以后才能查看个人信息。”“补假审批必须符合公司人事部门制定的休假制度。”分析整理需求功能需求功能需求描述的是系统在特定条件下展示出来的可观察到的行为及系统允许用户采取的行动。示例如下：“如果温度超过37°，需要语音报警。”“用户必须要能够对实验列表按实验名称和提交时间进行排序。”分析整理需求质量属性质量属性属于系统的非功能性需求，通常是对系统如何很好完成某些任务的陈述。注意倾听描述系统特征的词：迅速、简单、用户友好、可靠、安全。示例如下：“移动软件必须对触摸指令做出快速响应。”“购物车必须好用，使新客户不至于放弃购买。”分析整理需求6.外部接口此类需求描述系统与外部世界的联系。例如：“必须从……读取信号”、“必须要向……发送信息”、“必须要以<某种格式>来读取文件”、“用户界面元素必须符合<某个标准>”。示例如下：“实验系统中的课程名单必须从教务系统中导入。”“用户除了可以使用用户名、密码登录，还支持通过微信、QQ等第三方平台验证登录。”分析整理需求7.约束设计和实现约束是对开发人员可用选项的合理限制。例如：“必须要用<某个编程语言>来写”、“不能超过<某些限制>”、“必须要用<一种具体的用户界面控制>”。示例如下：“提交的电子文档必须使用pdf格式，大小不能超过10M。”“为保证所有安全交易，浏览器必须要用256位密匙。”分析整理需求8.数据需求如果客户描述的内容是：格式、数据类型、允许值或者数据元素的默认值；复杂的业务数据结构的组成；或者是待生成的报告。那他们就是在表达数据需求，示例如下：“邮政编码由6个数字组成。”“订单信息包含：客户身份、发货信息、一件或多件产品，每个都要包含产品编号、数量、单价和总价。”分析整理需求9.解决思路有些来自用户的“需求”其实是解决思路。如果有人在描述与系统交互使其执行某个动作的一种特定方法，说明他就是在提供解决思路。示例如下：“从下拉选项列表中选择一个包裹发送目的地。”“手机必须允许用户用一个手指在屏幕上滑动导航。”分析整理需求对客户输入进行归类以后，还需要将信息组合成为表述清晰，组织良好的需求集合。需求分析师在描述、记录需求时，可以借助一些可视化需求模型来表达。下表是用户需求中的描述词语到可视化需求模型的映射。词语类型示例可视化需求模型名词人员、组织机构、软件系统、数据元素或已存在对象的描述组织结构图用例图实体关系图数据流图动词行为、用户或者系统所发生的事情及流程用例图顺序图活动图数据流图条件条件逻辑的陈述角色权限矩阵活动图状态机图整理系统涉及的数据需求哪里有功能，哪里就有数据。不管数据代表的是视频游戏中的像素、手机通话中的数据、公司季度销售报表还是其他任何事情，软件的功能就是创建、修改、显示、删除、处理和使用数据。在需求获取过程中，一旦有数据，需求分析师就应该开始收集并定义它们。在需求获取阶段，用户提到的名词常常暗示着重要的数据实体：留学人员、项目主管、关键词、问题列表等。实体关系图、业务数据图和类图可以帮助我们理解业务中或系统中的数据组件及相互之间的关系。第三篇将重点讨论软件需求分析中常见的数据分析方法和各种数据需求模型。识别其他非功能性需求在需求分析时，功能性需求是人们普遍关注的，但也不能忽视非功能性需求的分析。非功能性需求主要包括质量属性和约束条件。软件产品要想取