软件需求分析工作及方法.pptx

软件需求分析工作及方法,部门 ： 医技事业部 姓名：杨 博 版本日期 20141228,仅供卫宁软件内部使用,上节培训回顾,需求调研的概述 了解软件需求调研 如何开展需求调研 需求调研前的准备 需求调研的步骤 需求调研中的注意规则,需求分析也是需求过程中最为核心的工作，需求分析更是项目建设的基石。在以往建设失败的项目中，80是由于需求分析的不明确而造成的。因此一个项目成功的关键因素之一，就是对需求分析的把握程度。 那么到底什么是需求分析呢？,引言：,培训内容,需求分析相关知识 需求分析工作方法（重点） 需求产品 需求验证,需求分析相关知识： 1. 需求分析的核心,需求分为业务需求，用户需求和软件需求三个层面。而我们在平时的需求分析中往往很容易直接跳到了软件需求阶段，而忽视了业务需求和业务建模。 需求分析核心： 业务需求 = 目标 + 范围 目标的表达必须包括目标+优势+度量+合理+可行，或者说SMART原则。同时在目标表达上可以考虑场景法，即问题是什么-影响谁-后果是什么-解决方案优点是什么？ 范围表达的两个重要方面是人和物，人包括干系人和最终用户；物包括业务事件和管理控制点。,需求分析相关知识： 2. 需求分析的工作目标,需求分析到底要做什么呢？换句话说就是需求分析到底要达到什么样的工作目标呢？,需求分析的工作任务实际上就是：分解、提炼、消除这个过程中存在的矛盾。并最终把用户业务需求形成需要进行软件信息化的专业表述，以便更加准确合理的开展后续工作。 分解：分解就是人类控制复杂性、认知复杂事物的工作。简单的说就是把复杂的问题拆解为若干小问题进行分析。 提炼：我们必须对需求中存在的业务流程，业务对象等经过分析加工之后，提炼为计算机软件专业性的表述。这便是提炼。其实就是把用户需求软件化专业表述的过程。 消除矛盾：在需求分析过程中，必然存在一些需求是相互矛盾、相互冲突的。因此在分析过程中，需求人员就必须发现和消除这些矛盾的地方。,需求分析相关知识： 3. 需求分析相关人员,需求工程师、 系统分析师 受益者： 项目管理、设计、开发、测试 到 用户,需求分析相关知识： 4. 需求分析方式,1. UML的分析法。 借助UML（统一建模语言）来进行分析。为了更加清晰的表现需求，我们通常结合UML（统一建模语言）来负责需求分析。这个手段也是我们通常采用的一种重要分析手段，我们在需求分析中经常会用到的UML图例如下图所示：,2. 头脑风暴法 当需求收集回来之后，我们在进行需求分析时，可以借助头脑风暴法采取会议的形式进行分析。大家求同存异，最终达到需求目标。在此过程中必须指定专人进行详尽记录。 组织形式：需求分析人员可以发起。 参与者：项目经理，需求人员，设计人员。,需求分析相关知识： 5. 需求分析工具,可以利用建模工具来辅助需求分析工作。需要说明的是需求分析工具也可以是纸、黑板等。其实工具并不重要， 【重要的是更合理的理清需求。从而更加完整和真实的抓住需求】 常用工具： MS-Viso 、 PowerDesigner、 Exel、 ROSE,培训内容,需求分析相关知识 需求分析工作方法（重点） 需求产品 需求验证,需求分析工作方法,从需求不同的捕获物来进行分析：在需求分析阶段，我们主要对从如下几个不同方面来进行分析，具体包含： 1、业务流程分析、 2、业务实体分析、 3、报表业务分析、 4、角色及场景分析、 5、界面需求分析、 6、其他需求分析 7、需求分析注意细节。,需求分析工作方法： 1. 业务流程分析,业务流程分析是针对每个业务事件来进行的，每个业务事件都是一个业务流程的触发，沿着对业务事件的响应序列，找到所有相关的业务活动，表述出这些业务活动之间的关系就是该任务的关键目标。在业务流程分析中，信息的主要来源是负责该业务流程的中层管理人员，因此访谈对象也是这一类人员。 业务流程分析的任务：就是针对每一个业务事件，分析并识别现有业务活动，确定业务活动之间的关系；了解这些业务活动需要接受哪些信息，将产生哪些数据（表单），确定数据传送的路线；同时标识出业务活动是由哪些部门、岗位负责等信息。,业务流程分析是针对每个业务事件来进行的，每个业务事件都是一个业务流程的触发，沿着对业务事件的响应序列，找到所有相关的业务活动，表述出这些业务活动之间的关系就是该任务的关键目标。在业务流程分析中，信息的主要来源是负责该业务流程的中层管理人员，因此访谈对象也是这一类人员。 A明确业务流程分析的任务：就是针对每一个业务事件，分析并识别现有业务活动，确定业务活动之间的关系；了解这些业务活动需要接受哪些信息，将产生哪些数据（表单），确定数据传送的路线；同时标识出业务活动是由哪些部门、岗位负责等信息。,B、分清楚业务流程的类型： 在一个企业/组织中，根据业务流程的目标可以将其分成不同的类型，最主要的类型包含以下三类： （1）生产性流程：这是流程中最重要的部分，它是企业/组织价值体现的核心，通常也是最容易标示的一部分。 （2）管理性流程：这是对生产性流程的管控。它通常是由管理层发现的，对一些质量、效率进行监督的控制性流程，这是容易忽略的部分。 （3）支持性流程：这是对生产性流产的一种补充，通常是由协作部门、本部门员工执行的工作，这也是容易丢失的部分。 例如：如果那软件开发过程来说的话，需求分析、软件设计、编码、测试都是生产性流程；项目管理、质量保证就属于管理性流程； 而支持性流程包括配置管理、文档管理等。,C 抓住业务流程的六大特性 在分析过程中，要注意抓住核心业务和主要活动点、部门内以及部门之间的衔接，工作中的繁琐和反复的环节，成本高、效率低、时间长的环节以及任务转手次数较多的环节。具体我们可以抓住业务流程的六大特性： * 目标性：流程是针对要达到的一个目标进行设计的。 * 内在性：流程本身是一个高内聚的整体，它是一个很好的分离业务耦合点的线索。 * 整体性：流程是由多个业务活动组成，分析要点在于缺的业务活动之间关系。 * 动态性：流程是一个顺序行为过程。 * 层次性：组成流程的本身也可以是个流程。因而分析要点在于必须理清流程层次，通过逐层嵌套形式理清脉络。 * 结构性：流程之间的关系包括：串联、并联和反馈。,UML流程图：利用其可以清晰的描述流程中每个不同职能角色的实际工作过程。它的主要图示要素及说明如下，具体我们也可以参考一些UML的书籍。 1） 流程名称：就是位于图的最顶部的“流程名称”，在此应该填入整个流程的名称。 2）职责带区：图中每一条长方列，每一条表式一种不同的职能，它可以用来标示参与业务流程中的各个岗位、部门。例如上图中的部门一、部门二。 3）流程阶段：对于一个比较长或者繁大的业务流程，我们通常将其分解成不同的阶段，以便于清晰。它可以用虚线来分隔不同阶段。,需求分析工作方法： 2. 业务实体分析,在需求分析中，必定会涉及到许多的业务实体（又称业务数据、业务术语），需要正确构建出信息系统，就必须对这些业务实体进行合理有效的分析。 业务实体分析概述： * 步骤或者目标：对于信息系统中的业务实体的分析，其主要步骤无非三点：识别出系统涉及到的业务实体、确定实体之间的关系（关联、泛化、聚合与组合），定义实体的关键属性。 * 原则：业务实体分析的原则就是采用面向对象思想来进行分析。,业务实体分析UML类图表示,类图的表示方法： 名称：名称是一个有别于其他类的名称。是一个文本字符串。例如：Order 属性：它是已经被命名的类的特性，它描述该类实例中包含的信息。在面向对象编程中，它实际上是类的成员变量。 操作：操作是类所提供的方法或者称为服务。 类在类图上使用包含三个部分的矩形来描述，如下图所示。最上面的部分显示类的名称，中间部分包含类的属性，最下面的部分包含类的操作（或者说“方法“）。,E/R图：它与数据库联系紧密。它是类图的扩充，反映了类之间的各种关系（关联、泛化、聚合与组合）。 如下图所示：,需求分析工作方法： 3. 报表业务分析,在信息系统中，用户肯定会提出一些报表需求，对于这类报表需求的分析工作，我们可以利用Why（目标）、What（内容）、How(展现形式)三个层次加以分析。 1. Why（目标）:就是要解决部门/职位、目的（查询条件）、相关场景与查询频率等方面的内容。 2. What（内容）：对于一张具体报表，我们必须确定它所涉及的业务实体、主要数据项（输出数据项）、数据项计算方法。同时也要确定具体有多少报表。 3. How(展现形式)：展现形式包含图表、列表等。 其实软件中的报表分析通俗一点就是： （1）输入什么样的内容，可以理解为查询条件； （2）通过什么处理方式，可以理解为计算方法或者业务处理逻辑等； （3）最终把处理结果以何种形式进行展现的过程，这一点通常是用户提供的各种报表格式，需要用户提供详细的原格式（描述为相应附录编号，以便对应）。 （4）此外，还需要明确排序规则，分组规则，数据约束规则等相关条件。,为了更加清晰的表述报表分析，我们可以以如下的撤销申请为例加以说明： 1、撤销申请表的要素信息包括：,2、撤销信息汇总情况报表分析：,需求分析工作方法： 4. 角色及场景分析,角色场景分析方法： 1、捕捉等开发系统行为的方法 2、表达及分析系统行为的方法 3、识别谁（用户）与系统交互，以及交互的过程。 4、验证所有的需求的捕捉完整性。,Use Case的定义是：在不展现一个系统或子系统内部结构的情况下，对系统或子系统的某个连贯的功能单元的定义和描述。 其实Use Case就是对系统功能的描述而已，不过一个Use Case描述的是整个系统功能的一部分，这一部分一定要是在逻辑上相对完整的功能流程。 用例的特点： 1）外部可见：用户行为、系统响应 2）有价值的需求 3）详细表述：与主要用户达成共识 4）完整性与精确性。,用例的表达,用例的表达： 角色（Actor）：在系统之外与系统交互的用户或动作。 用例（Case）：系统执行的外部可见的，产生对角色有价值的响应结果。 用例名称（CaseName）：能够简明说明目标的动名词组。,用例说明模板,需求分析工作方法： 5. 界面需求分析,界面需求分析应该是清晰、准确、符合用户习惯、满足人机工程学要求的界面设计方案，能够形成清晰的结果，将模糊却又时时存在的用户需求转化为清晰、准确的界面需求。对此我们要遵从和注意以下几点：,界面设计原则 （1）用户原则。人机界面设计首先要确立用户类型。划分类型可以从不同的角度，视实际情况而定。确定类型后要针对其特点预测他们对不同界面的反应。这就要从多方面设计分析。 （2）信息最小量原则。人机界面设计要尽量减少用户记忆负担，采用有助于记忆的设计方案。 （3）帮助和提示原则。要对用户的操作命令作出反应，帮助用户处理问题。系统要设计有恢复出错现场的能力，在系统内部处理工作要有提示，尽量把主动权让给用户。 （4）媒体最佳组合原则。多媒体界面的成功并不在于仅向用户提供丰富的媒体，而应在相关理论指导下，注意处理好各种媒体间的关系,恰当选用。,2 抓住界面元素 通常一个软件界面的”元素“包括界面主颜色、字体颜色、字体大小、界面布局、界面交互方式、界面功能分布、界面输入输出模式等。其中，对用户工作效率有显著影响的元素则是：输入输出方式、交互方式、功能分布。 在使用“命令”式交互方式的系统中，命令的名称、参数也是界面元素的内容，如何设计命令及参数也很重要。 影响用户对系统友好性评价的元素则有：颜色、字体大小、界面布局等，这种划分不是绝对的，软件界面作为一个整体，其中任何一个元素不符合用户习惯、不满足用户要求都将降低用户对软件系统的认可度，甚至影响用户的工作效率，也可能使用户最终放弃使用该系统。 围绕界面元素所要达到的设计目的是让最终用户能够获得美感、提高工作效率、易于操作使用系统。,3、根据不同用户因人而宜 界面需求分析必须以用户为中心，不同于客观功能的需求分析具有很大的主观性。虽然，界面设计人员可以按照通行的原则来设计，但是用户个体的文化背景、知识水平、个人喜好等是千差百异的，其界面需求也是相差很大。 之所以要定义用户角色，是因为不同的用户角色在需求分析过程中的需求目标不同，侧重点也不同，甚至互相矛盾。在一个大型系统中,需求分析人员面对的用户只能是众多单一的用户个体，他们的需求千奇百怪。只有明确了用户角色，需求分析人员才能在纷乱复杂而又不甚明了的用户要求中理出脉络，依据用户角色不同的优先级别，平衡众多用户需求中的矛盾，抽象出完整的GUI界面模型。,需求分析工作方法： 6. 其他需求分析, 接口需求：指软件与硬件或其它外部系统接口。包括下述内容： * 人机接口：说明输入、输出的内容、屏幕安排、格式等要求； * 硬件接口：说明端口号，指令集，输入输出信号的内容与数据类型，初始化信号源，传输通道号和信号处理方式。 * 软件接口：说明软件的名称、助记符、规格说明、版本号和来源； * 通讯接口：指定通讯接口和通讯协议等描述。, 非功能性需求：软件非功能性需求是指软件性能指标，容限等功能以外的需求。一般指下述内容： * 时间需求：输入、输出频率，输入、输出响应时间，各种功能恢复时间等； * 处理容限、精度、采样参数的分辨率，误差处理等； * 可靠性的MTBF要求，可维护性、安全性要求等。（对可能的不正常的输入给以正常响应是可靠性的重要内容，这属于功能性需求。）, 约束需求 约束需求主要包含如下三点内容： * 非技术因素决定的技术选型 * 预期的软硬件环境 * 预期的使用环境,需求分析工作方法： 7. 需求分析注意细节,当需求分析完善之后，我们不要疏漏了需求的细节的填充，具体包括： * 字段属性信息：也就是每个业务对象所包含的成员属性，细化其结构。 * 字段格式与规则：每个字段详细的格式，包括字段类型和组成规则（字段大小）。 * 计算规则：通过数据表达式并加以说明的方式来表示。 * 结构规则：对于数据的组成、格式进行描述。 这一部分细节的完善，建议多参考用户实际业务过程中所涉及的一些图表、报表等相关信息，并做到存在不清楚的地方多于用户进行沟通的方式。,培训内容,需求分析相关知识 需求分析工作方法（重点） 需求产品 需求验证,需求产品：1、用户需求说明书,1. 用途：面向客户的“用户需求说明书”。 用户需求说明书是用户对需求的说明和介绍，它的特点是更加面向业务，存在零散、可能相互矛盾等问题。根据CMMI的描述：通常客户需求是通过采集项目相关人员的需要、期望、限制和接口，对其加以解释并转化而成的。 2. 内容：需求开发的最终成果是：客户和开发小组对将要开发的产品达成一致协议。协议综合了业务需求、用户需求和软件功能需求和非功能需求文档，包括质量属性和外部接口需求。只有以结构化和可读性方式编写这些文档，并由项目的风险承担者评审通过后，各方面人员才能确信他们所赞同的需求是可靠的。 3. 描述规则： 简洁、段落文字少。 列表、图表相结合的表示法，可以加入需求分析中所用到的UML图表以及用户实际业务中用到的图表。 注意措辞。 避免使用描述数据的词语。 尽量使用用户易懂语言来描述用户业务。 用户需求说明书值得注意的地方：用户需求说明书应该尽可能的真实的还原用户需求，一定要遵从真实性原则。,需求产品：2、需求规格说明书,1. 用途：面向设计人员和开发人员的“需求规格说明书”。 2. 内容：分析人员要把从你和其他客户那里获得的所有信息进行整理，以区分业务需求及规范、功能需求、质量目标、解决方法和其它信息。通过这些分析就能得到一份软件需求规格说明。而这份软件需求规格说明便在开发人员和客户之间针对要开发的产品内容达成了协议。软件需求规格说明书可以用一种你认为易于翻阅和理解的方式组织编写。要评审编写出的规格说明以确保它们准确而完整地表达了你的需求。一份高质量的软件需求规格说明能有助于开发人员开发出真正需要的产品。 3. 规则：做好需求规格说明书的核心在于“确保信息的有效传递”。为达到这一目的，我们必须做到： 可获得：随时可获得最新的版本，需要文档管理制度来解决。 有更新：应该有专人更新，需要制度保障。 易于获知：对于读、写的人都能够正确的从文档中获得所需的信息，需要通过良好的文档模板来解决。 易于更新：应该确保同类信息只在一处出现，这样更易于更新。,需求产品：3、界面原型,由于在软件开发前期，用户的界面需求很模糊，甚至没有自己的理想模型，用户提出的要求就很难量化，结果很容易被需求分析人员忽略。因此在用户角色定义完成后应用快速原型法来设计用户界面，可以帮助用户尽快完善自己的理想模型。 利用界面原型可以将界面需求调查的周期尽量缩短，并尽可能满足用户的要求。快速原型法是迅速地根据软件系统的需求产生出软件系统的一个原型的过程，其主要好处是可尽早获得更完整、更正确地需求和设计。 通常我们所做的界面原型有如下两种： 1. 功能性Demo。辅助开发和设计人员进行工作。并可以用来进行需求确认与分析的demo。通常由设计和需求人员完成该项工作。可以利用Demo制作工具完成。 2. 界面UI展示Demo。帮助开发人员完成页面编程，通常由美工完成该项工作。可以利用Dreamweaver等美工设计工具完成。,培训内容,需求分析相关知识 需求分析工作方法（重点） 需求产品 需求验证,