软件需求-第4课-软件需求获取概述(一)(第1版)

第 4 章 软件需求获取概述,主要讨论问题,2 需求获取的策略,3 需求获取的主要方法,4 需求获取的记录工具,1 需求定义,1 需求定义,主要讨论问题,需求定义任务概述,问题分析的方法,需求定义的产物和要素,定义需求范围,1 需求定义,主要讨论问题,需求定义任务概述,问题分析的方法,需求定义的产物和要素,定义需求范围,1 需求定义,需求定义任务概述,软件的生存周期,问题定义,可行性研究,需求分析,软件设计,编码,测试,维护,计划时期,开发时期,运行时期,1 需求定义,需求定义任务概述,严格说来，需求定义活动不属于需求工程范畴。它实际上是立项管理阶段的产物，在一些软件工程的书籍中需求定义也称为总体问题陈述或者总体目标或者战略规划（第3课实例中），通常也可以称为业务需求（第2课） 但需求定义阶段的制品对于需求获取、分析和建模活动具有重要的指导意义，产生直接的影响。如果该阶段的工作做得不好，将会对系统开发带来严重的后果。目标和范围有问题，开发必然会出现重大的修改。,需求定义任务的地位,1 需求定义,需求定义任务概述,需求定义任务的地位,需求定义：就是确定项目的宏观需求，确切地说是定义项目的 业务需求，也就是明确项目的目标和范围。,1 需求定义,需求定义任务概述,需求定义的重要性,前景和范围,业务需求定义前景和范围,在前景和范围的指导下定,义用户需求,业务需求,用户需求,转化用户需求为软件需求,软件需求,所有不符合业,务需求目标的,用户需求和软,件需求都不应,该包含在,SRS,之,中,用户需求和软件需求必须满足业务需求（需求定义）。,1 需求定义,需求定义任务概述,需求定义的时机和问题,从以上对需求定义的理解可以看出，它的确应该在项目启动时需要解决的问题，也就是说要在项目启动前，项目立项时完成的工作。 实例，黑龙江省地方税务局全省大集中项目在项目启动会召开时，需求定义已经形成文档。启动会主要内容之一就是明确需求定义（业务需求、项目目标）。 多数项目在立项时没有很好地完成项目需求定义工作。主要原因是多数项目（100万以上）目前都采用招标形式，在招标开始时，项目需求定义已经完成，但项目团队并未参加。,1 需求定义,需求定义任务概述,需求定义的参与人员,企业/组织领导、相关负责人,企业业务主管,企业信息技术主管,咨询公司或相关公司,系统分析员形成文档,1 需求定义,需求定义任务概述,需求定义的策略,需求定义要从业务（和技术）发展趋势出发，根据企业/组织的现状，结合国家对行业的政策和策略制定。,实例 黑龙江省地方税务局战略规划制定策略,1 需求定义,需求定义任务概述,需求定义的实际经验,需求定义阶段产生的项目目标一般都比较抽象（参见第2课）通俗来说经常目标提的比较“空”。比如“依法治税”，“全面提高信息化应用水平”等。光看这些目标，很难落实。 对混沌不清的目标，对具体做需求的人员来说，一定不要简单放过。因为这些地方往往就是以后出现问题的地方。 解决的方法是采用内外结合的方法分析抽象目标的具体含义。,1 需求定义,需求定义任务概述,需求定义的实际经验,内外结合的方法分析抽象目标的具体含义。 所谓内外结合就是在企业内，一个项目提出后经常会逐层上报、审批，在此过程中项目的目标通常都会逐层被“抽象提高”，使其更具有高度。最终会产生模糊不清的、深奥抽象的目标。由此，可以尝试寻找正真的项目提出者，与其探讨目标的含义和需求。 企业/组织中的项目有时不是内部发起的，而是收到一些外部形势的影响，需要从外部寻找答案。,1 需求定义,需求定义任务概述,需求定义的理念,如果要对需求定义工作的着手点进行概括的话，就是6个字：问题、机会、约束。对于信息系统而言，其构建要么是解决问题的，要么是把握机会、创造机会的，但必须满足一定的约束条件。由此首先应该明确要解决的问题是什么，或者要把握什么机会，同时要明确解决问题或者把握机会都有什么约束。,1 需求定义,需求定义任务概述,需求定义的理念,在需求定义、制作项目提案时经常可以采用的方法之一是：目标-问题-可选方案-建议方案。 目标：通过内部寻根和外部朔源的方法，将整个项目要解决的 问题罗列出来，例如“提高为用户服务意识”。 问题：针对目标层面的问题进行分析，找到导致该问题产生的 根源，然后将其全部罗列出来。 可选方案：针对每个问题罗列出可能的解决方案。 建议方案：从各种可选的方案中挑选出比较合理的，并且满足 相关约束的方案。,1 需求定义,需求定义任务概述,需求定义的理念,1 需求定义,主要讨论问题,需求定义任务概述,问题分析的方法,需求定义的产物和要素,定义需求范围,1 需求定义,问题分析的方法,问题分析要点： 1 问题分析就是理解现实世界中的问题和用户的需求，并对如何满足这些需要提出解决方案的过程； 2 问题分析的目的是在开始开发前更好地理解所面对的问题； 3 要确定根本原因或者问题背后的问题，最好的方法就是咨询相关的人员； 4 问题分析的一个关键步骤就是确定系统的主角。,参考 ,1 需求定义,问题分析的方法,一般来说，问题分析可以通过以下步骤完成: (1) 在问题定义上达成共识； (2) 理解根本原因，分析问题背后的问题； (3) 确定相关人员和用户； (4) 定义解决方案的界限； (5) 确定加在解决方案上的约束。,1 需求定义,问题分析的方法,(1) 在问题定义上达成共识,问题分析是理解现实世界中的问题和用户需求并提出满足问题和需求的解决方案的过程。 所以问题分析的关键是明确问题并与相关人员就各个问题达成共识。 要与相关人员就问题达成共识，首先需要按照一定的方式描述问题，使参与者能够理解问题。 达成共识是目标，对问题的清楚的描述是必要的手段。,1 需求定义,问题分析的方法,要让大家达成共识，采用统一的格式写出来是很有效的手段。格式千差万别，但一般描述问题的方法是采用问题定义模板。,(1) 在问题定义上达成共识,1 需求定义,问题分析的方法,问题定义示例-银行信用卡部问题,(1) 在问题定义上达成共识,1 需求定义,问题分析的方法,(1) 在问题定义上达成共识,问题定义的经验一：需求定义阶段要善于将未知问题转换为 已知问题 将解决方案转换到已经掌握的方法或者手段上。在和用户沟通时，应该注意将用户的需求转换成自己已有的产品或者已有的解决方案上，而不是简单地重新开发。,1 需求定义,问题分析的方法,(1) 在问题定义上达成共识,问题定义的经验二：在确定某解决方案时，一定要考虑是否会引发 新的问题。 问题经常会被表象所掩盖，如果不能在问题定义时揭开此表象，则会对解决方案带来新的问题。关于从表象揭示问题的技巧可参考温伯格的著作你的灯亮着吗？-发现问题的真正所在。,1 需求定义,问题分析的方法,(1) 在问题定义上达成共识,关于温伯格：软件管理和软件工程的权威和代表人物。作为软件工程学生需要像上专业课一样学习其重要书籍主要书籍 探索需求 系统设计的一般原理 系统化思维导论 成为技术领导者（解决问题的有机方法） 程序开发心理学 质量软件管理（I,II,III卷） 理解专业程序员 你的灯亮着吗？,1 需求定义,问题分析的方法,(1) 在问题定义上达成共识,问题定义要明确。问题的明确性具有以下特点：易于理解；P1. 图书管理员：图书总是无法上架。P2. 图书管理员：图书的内容分类不合适，无法分类上架 图书上架的工作太繁杂，导致来不及上架。 图书的借阅不遵守章程，不能保证上架。能指明解决的方向P3. 决策者：生产的废品过多。,1 需求定义,问题分析的方法,(2) 发现问题背后的问题，理解根本原因,发现问题背后的问题就是要寻找问题的本源。在实际工作中，一般有两种工具可以帮助我们更好地完成该工作：鱼骨图和帕累托分析。 鱼骨图（也称鱼翅图）：用于定性分析。可以以一种直观的图形找出问题或现象的所有潜在原因的方法，它可以用于追踪问题的根源。 使用它的好处是：使分析人员能将问题的原因而不是症状放在首位；提供了一种运用集体智慧解决问题的方法；直观、简单、易于操作。,1 需求定义,问题分析的方法,(2) 发现问题背后的问题，理解根本原因,通常鱼骨图分析的过程都会结合头脑风暴。具体说就是绘制一个鱼骨图通常是一个团队在一起，通过以下几个步骤来实现制作： A 选择问题 首先选择一个具体的问题或者结果。在选择问题时，要保证问题是专门的、定义严谨的、范围相对较小的（对于大范围的问题往往需要考虑将其分解成相对较小的问题），并且保证参与人员切实理解要分析的内容。对问题定义产生出来的问题一般都应该进行一次独立的鱼骨图分析。 可以先将问题定义写出来，形成第1层鱼骨图。,鱼骨图的制作,1 需求定义,问题分析的方法,(2) 发现问题背后的问题，理解根本原因,鱼骨图的制作,1 需求定义,问题分析的方法,(2) 发现问题背后的问题，理解根本原因,B 头脑风暴 就导致问题的可能原因进行头脑风暴。将大家提出的意见记录下来，确认后贴到鱼骨图上。 需要注意的是不要将原因和解决方案混为一谈。在确定原因的分类前先进行头脑风暴（一个人提，大家批），不然思考问题的范围就会受到限制。支持者需要引导和鼓励参与者参与其中。,鱼骨图的制作,1 需求定义,问题分析的方法,(2) 发现问题背后的问题，理解根本原因,鱼骨图的制作,C 确定问题类型 对头脑风暴的结果进行整理，确定出主要的原因类型。一般来说，划分出来的问题不要少于2类，不要超过6类（经验数值，仅供参考）。经常使用的类型有：人、设备、材料、环境、方法、过程等。将这些类型补充到鱼骨图上。,1 需求定义,问题分析的方法,(2) 发现问题背后的问题，理解根本原因,鱼骨图的制作,废品率居高不下,生产,销售,运输,其它,第2层鱼骨图,1 需求定义,问题分析的方法,(2) 发现问题背后的问题，理解根本原因,鱼骨图的制作,D 分配原因 将头脑风暴中得出的潜在原因放在鱼骨图上，并且确保每一项原因都归于适当的类别中。如果原因看起来可以放在多个类别中，就表示是多重原因造成的问题。但如果多次出现多重原因，可能就以为着分类存在问题。该阶段将形成最终的鱼骨图,1 需求定义,问题分析的方法,(2) 发现问题背后的问题，理解根本原因,鱼骨图的制作,1 需求定义,问题分析的方法,(2) 发现问题背后的问题，理解根本原因,鱼骨图的制作,E 分析根本原因 对鱼骨图中罗列出来的所有潜在原因进行分析。分析出造成某一结果的最根本原因是什么？找出核心所在。 方法如下： 通过参与者之间的公开讨论来分享看法和经验； 寻找重复的原因，或者与特定类有关的原因的数量； 使用检查表收集资料、制造流程图或者进行用户调查， 通过帕累托分析法测试各种原因的相对强度； 投票（真理多数情况下掌握在多数人手里）,1 需求定义,问题分析的方法,(2) 发现问题背后的问题，理解根本原因,鱼骨图的制作,小结：鱼骨图是一种因果分析工具，它在需求定义、项目管理、过程改进等方面都有应用价值。其主要作用是： 关注原因而非表面的症状； 获取群体知识和经验； 提供了展现导致问题发生的所有原因的全景图； 为进一步收集资料和行动提供了坚实的基础。,1 需求定义,问题分析的方法,(2) 发现问题背后的问题，理解根本原因,关于帕累托分析在通过使用鱼骨图完成问题原因的定性描述后。仍然存在一个问题，就是根本原因的辨识需要有经验的决策者确定，或者根据人类固有经验（少数服从多数）确定。更好地方法是能够开展定量分析。帕累托分析可以帮助我们做出这样的定量分析。帕累托分析应用就是根据鱼骨图分析的结果，通过收集相关统计资料，通过直方图的方式显示问题的相对频度或者大小高低等定量结果。,1 需求定义,问题分析的方法,(2) 发现问题背后的问题，理解根本原因,帕累托分析步骤,A 确定问题和相关原因 利用鱼骨图的结果。 B 收集数据 有针对性第收集数据。例如上例中，我们可以抽取一些废品，分析这些废品产生的原因。,1 需求定义,问题分析的方法,(2) 发现问题背后的问题，理解根本原因,帕累托分析步骤,1 需求定义,问题分析的方法,(2) 发现问题背后的问题，理解根本原因,帕累托分析步骤,C 绘制直方图,1 需求定义,问题分析的方法,(2) 发现问题背后的问题，理解根本原因,帕累托分析步骤,从直方图可以看出导致上述问题的主要原因可以归结为两个因素。订单不准确和运输损耗。 帕累托分析可以： 确定并集中于主要的问题领域； 从许多有用的事物中分离出至关重要的几件事情； 确定主要的因与果。,1 需求定义,问题分析的方法,(3) 确定相关人员和用户,解释一下“Stakeholder”Stakeholder 的词典解释赌金保管者,（某组织、工程、体系等的）参与人，参与方；有权益关系者。 政治上 前美国国务卿助理左克利“利益攸关方 ”。在软件工程领域一般将其翻译为“涉众”。此解释来源于管理学领域。意思是能够影响组织的目标实现和被组织的目标实现所影响的所有个人或者团体。 一般米国人解读为“筹码持有人”。,1 需求定义,问题分析的方法,(3) 确定相关人员和用户,Stakeholder的含义理解：项目是一个博弈的游戏，有很多人拥有相应的筹码，项目经理的目标就是尽可能多地获取筹码，获取的筹码越多，项目成功的概率越高。有效地解决实际复杂问题的方法是满足不同涉众的不同的需求。不同的涉众通常对问题有不同的看法和需求，在解决问题时需要加以理解和分析。,1 需求定义,问题分析的方法,(3) 确定相关人员和用户,实践经验：既然Stakeholder的主要性体现为其拥有的“筹码”的多少。由此，在需求定义时应该分层次，分主次理解用户。需求获取团队应该更关注那些层次人员： 如果关注的是操作层，显然项目成功的机会不大，出现差错 的可能最大，显然，操作层手里的筹码相对最少。 如果关注的是管理层，如果项目管理适当，应该有成功的可 能，项目出现反复的可能小得多。 如果关注的是决策层，恭喜你 ，答对了。项目出现反复的可 能最小，成功的概率最大。高层人员拥有的筹码最多。,客户: 为达到其公司的业务目标而投资项目或购买产品。用户：直接或间接与产品打交道，是客户的一部分。需求分析员：负责编写需求并传达给开发团队。开发人员：设计、实现和维护产品。测试人员：确定产品的行为是否与预计的相一致。文档编制人员：负责编写用户手册、培训资料和系统帮助。项目经理：制定项目计划并带领开发人员获得成功。法律人员：确保产品符合所有相关法规。生产人员：制造包含该软件的产品。市场营销: 技术支持及其他与产品和客户打交道的人员。,1 需求定义,问题分析的方法,(3) 确定相关人员和用户,1 需求定义,问题分析的方法,(3) 确定相关人员和用户,寻找软件系统的涉众类别，辨别关键的涉众类别；描述不同涉众类别的特征，包括个人特征、工作特征；分析不同涉众类别的输赢条件和受影响程度； 描述不同涉众类别的关注点和兴趣取向；分析不同涉众类别的重要性和影响力；为每种涉众类别选择合适的代表参与项目开发。,涉众分析的过程,1 需求定义,问题分析的方法,(4) 定义解决方案的界限,解决方案的实际能力总是有约束的，系统的范围总是有限的。在需求定义阶段，对系统的范围进行界定是十分重要的。多数的书籍都建议用上下文图来确定系统范围。 上下文图实际就是数据流图中的顶层视图。其基本思路就是将整个待开发的系统理解为一个黑盒子。然后标识出外部的参与者，并标识出其与系统交互的关系。,1 需求定义,问题分析的方法,(4) 定义解决方案的界限,上下文图示例,1 需求定义,问题分析的方法,(4) 定义解决方案的界限,解决方案的界限非常重要，但在实际操作中确比较难做。原因在于：如果系统比较庞大，则相关的参与者和系统（功能）都比较多，画出来比较麻烦；另外参与者与系统的关系比较复杂，画出来也很麻烦。,1 需求定义,问题分析的方法,(4) 定义解决方案的界限,示例：产品销售界限的确定,接受订单,信用检查,记录订单,顾客,供应商促销数据,库存量,订单处理,订单,顾客记录,信用卡处理,核查后订单,结算记录,送货处理,1,2,3,1 需求定义,问题分析的方法,环境描述：,顾客需要买东西时会打电话（或其他方式）给公司销售人员，公司销售人员根据供应商的促销数据向顾客报价，并根据当前库存情况确定能否响应用户订单；如果顾客接受该价格，并且有足够的库存，销售人员会认为用户的订单是有效订单；信用人员将顾客的历史交易数据以及信用卡的情况决定接受该订单是否是安全的，然后就结果返回给销售人员；如果审核结果表明订单是安全的，销售人员将会记录订单；进行下一步工作。,(4) 定义解决方案的界限,1 需求定义,问题分析的方法,系统界限选择：如果采用3号边界，系统仅实现订单记录，意味着用户必须手动完成接受订单的工作，信用检查的功能也不在本系统中实现，系统只起到一种电子化的工作。相当容易实现。问题是：我要是用户，不会给你超过10，000块钱。,(4) 定义解决方案的界限,1 需求定义,问题分析的方法,系统界限选择：如果采用2号边界，系统不仅实现订单记录，还会将该顾客的历史交易记录、提供信用卡检查。系统有一定的复杂性，除信用卡核查外都比较容易实现。,(4) 定义解决方案的界限,1 需求定义,问题分析的方法,系统界限选择：如果采用1号边界，系统还将实现订单接受的自动化，可能的解决方案是建立一个呼叫中心，或者通过WEB服务网站。,(4) 定义解决方案的界限,1 需求定义,问题分析的方法,到底选择那个边界呢？和用户的投入（资金），进度，需求有关。经验：选择那个边界开发商往往不能起决定性的作用。由用户来确定比较好。但作为开发商重要的是能够将不同的边界说清楚。,实际操作中，无论是大型项目，还是中小型项目，选择那个边界不重要，重要的是边界都在那里。不同的边界要做什么事情需要清楚。,(4) 定义解决方案的界限,1 需求定义,问题分析的方法,(5) 确定解决方案上的约束,约束一般可以分为技术开发的约束和项目实施的约束。,1 需求定义,主要讨论问题,需求定义任务概述,问题分析的方法,需求定义的产物和要素,定义需求范围,1 需求定义,需求定义的产物和要素,软件的生存周期,问题定义,可行性研究,需求分析,软件设计,编码,测试,维护,计划时期,开发时期,运行时期,1 需求定义,需求定义的产物和要素,需求定义的产物：战略规划报告或者称为“前景及范围”文档；有时也称为“项目综述与愿景”文档,1 需求定义,需求定义的产物和要素,RUP 推荐的愿景文档主要包括：,业务需求解决方案范围及局限性业务环境产品成功因素,1 需求定义,需求定义的产物和要素,RUP 推荐的愿景文档主要包括：,业务需求解决方案范围及局限性业务环境产品成功因素,1 需求定义,需求定义的产物和要素,RUP 推荐的愿景文档主要包括：,业务需求解决方案范围及局限性业务环境产品成功因素,1 需求定义,RUP 推荐的愿景文档主要包括：,业务需求解决方案范围及局限性业务环境产品成功因素,需求定义的产物和要素,1 需求定义,RUP 推荐的愿景文档主要包括：,业务需求解决方案范围及局限性业务环境产品成功因素,需求定义的产物和要素,1 需求定义,RUP 推荐的愿景文档主要包括：,业务需求解决方案范围及局限性业务环境产品成功因素,需求定义的产物和要素,1 需求定义,主要讨论问题,需求定义任务概述,问题分析的方法,需求定义的产物和要素,定义需求范围,1 需求定义,定义需求范围,上下文图画法,在绘制上下文关系图时应该采用以下步骤：1、首先用一个矩形表示系统，写上系统的名称，将整个系统看做一个黑盒子；2、然后找到该系统的所有Customer(客户)，考虑这些Customer会发起什么事件，这些事件会引发Worker(内部工作人员)的什么工作，将这些序列逐一表示出来；3、最后在看看系统的每个Worker还有没有一些主动发起的事件。Customer：也就是该主题域的客户，它处于该主题域的外部。如，对于体检业务子系统而言，体检者显然就是一类客户，除此之外，客服中心、物资部门、财务部门的工作人员也是这个主题域的Customer。Worker：也就是该主题域的工作人员，它处于该主题域的内部。如，服务中心，体检科室，综合科的工作人员都是其Worker。关键要点在于“针对本主题域”而言。,1 需求定义,定义需求范围,上下文图