第2章 需求调查

第2章需求调查2.1.1良好需求的特征1、无歧义2、可检验3、确定性强4、完整性5、可跟踪性6、正确性2.1需求调查概述2.1.2需求调查的步骤及工作产品1、阅读资料2、构建术语表3、制定调查计划2.1.3需求调查前的准备1、问卷2、实地观察3、面谈4、查阅资料2.1.4需求调查的基本方法业务流程的调查和分析采用自顶向下调查、自底向上补充完善的方法进行。2.2业务流程调查1、业务流程图基本符号2.2.1业务流程规范2、业务流程图示例从系统的观点出发，系统具有可分解性、层次性和相关性，因此在需求调查时，首先将系统分解为若干个业务领域，即大粒度功能范围，确定待开发系统的边界，研究大粒度功能范围之间的关系，从而获得待开发系统的概况。2.2.2概要调查例如，商场提出要针对会员卡的管理构建一个会员卡系统.会员卡管理总体工作流程是：商场计划部首先设计并制作会员卡，交给商场服务台，顾客填写后交还给服务员，由服务员为其建立会员档案，再由服务员进行卡作业处理，将办好的会员卡交给顾客，顾客便可持卡消费。商场统计部定期根据顾客消费情况进行统计分析，分析结果提交给计划部，为制订销售计划提供依据。在获得概要需求后，开发人员与用户讨论协商，共同确定系统业务功能包括会员卡管理、会员档案管理、卡作业处理和统计分析等四个部分总体业务流程图绘制总体业务流程图时，值得注意的问题：①流程图中所描绘的人员并非都是某个具体的角色②在流程图的绘制中除了按照规范要求使用规定符号、按照自顶向下原则绘制流程图外，还应该按照流程走向从左到右地制图，在制图中要尽量避免线条交叉③每一张图都要标注图名、设计人、制图人、校对人、检验人、确认人，以便对文档实施有效的跟踪管理④概要调查中还应该获取用户对系统的整体期望目标，以及非功能性的宏观需求，这类需求可以使用自然语言描述，并形成文档1、会员卡管理的详细需求调查2.2.3详细调查2、会员档案管理的详细需求调查3、卡作业处理详细需求调查4、统计分析详细需求调查1、业务流程图的内部检验检查所有功能、文档、存储数据、人员的命名是否规范和正确。存在问题的业务流程图2.2.4流程检验2、业务流程图之间相关性检验检查所有业务流程图中的存储数据符号，观察是否存在所有功能都需要使用某个存储数据，而没有一个功能产生这个存储数据,如果存在这种现象，则说明遗漏了产生存储数据的功能。3、完整性、正确性检验完整性检验，主要是对照相关的资料，检查是否存在被遗漏的功能，为满足未来发展变化需要，考察是否需要增加应对未来发展变化的功能；检查功能描述所包含的内容是否完整和明确，是否存在歧义。目前进行系统分析和设计大多采用面向对象方法，并用统一建模语言（UnifiedModelingLanguage，UML）来描述，其中利用用例图构建的用例模型便是需求分析的工作产品，对业务流程中描述的功能进行分析产生系统的功能需求，用用例来描述，功能之间的关系也就是用例之间的关系则描绘成用例图。2.3用例模型1、用例用例（UseCase）是在不展现系统内部结构的情况下，对系统功能的定义和描述。它来自于用户对系统所期望的功能需求，描述系统在响应来自某个参与者（Actor）的请求时在各种情况下的操作行为，而参与者则是与系统交互的人或者是物。用例的命名可以是一个简单的祈使句，其中包含有动词和该动词的宾语，说明系统将要做什么。2.3.1用例模型规范2、用例模型用例模型由用例和参与者组成，其中值得注意的是用户和参与者的概念有所不同，参与者的名字表明了角色，一个用户可以在系统中扮演多个角色，角色是与系统交互的外部实体。用例模型通过用例图来描述。3、用例图基本符号用例图示例4、用例之间的扩展关系和包含关系1、高层用例模型高层用例模型的形成来自与高层的业务流程图，转换方法是：把高层业务流程图中的功能转换为用例，把参与某项功能的人转换为参与者。总体用例模型2.3.3用例模型的建立2、会员卡管理用例模型3、会员档案管理用例模型4、卡作业处理用例模型5、统计分析用例模型6、用例模型间的层次关系泛化处理还可继续向上进行，泛化出一个“系统角色”参与者1、检验用例模型与业务流程图之间的关系最高层用例图中的用例应该与最高层业务流程图中描述的功能对应，并且名称也要尽量一致，每个用例实际上是一个相对独立的业务领域，是完整系统中的一个子系统。其余用例模型中的用例应该与对应的业务流程图中描述的功能有对应关系，用例集合是功能集合的一个子集，也就是说，业务流程图中的所有功能并不一定都能实现，但用例一定与某个功能有全部或部分对应关系，不能凭开发人员的想象而增加用例。2.3.4用例模型的检验2、用例模型的检验用例模型检验主要考虑以下几个方面的问题：①用例模型中，除扩展用例或包含用例可以没有参与者外，每个用例都应该有参与者，并且由参与者启动用例。②两个参与者之间不应该有“单向关联”线，即某个参与者不能启动另一个参与者。③例间的包含关系和扩展关系出现循环回路，在逻辑上是不合理的，应该重新考虑扩展用例或包含用例的设置问题。④如果发现有两个参与者共同启动一个用例，那么说明用例也还可以进一步分解。⑤每个用例应该是一个相对独立的功能，如果包含多个功能，那么可以考虑对用例的分解。3、用例模型的完整性检验与用户一起彻底检查每一个用例，确认其功能需求是否完整，用例的命名是否存在歧义，用例所表达的功能需求是否与用户的想法一致。2.4.1活动图1、活动图要素活动图由开始、活动、状态、同步条、判断、结束、迁移和泳道等图例组成2.4用例模型描述及检验2、用例间关系的描述以“会员卡管理”用例模型为例3、用例内部的活动描述以“申请制卡”为例“生成提交凭证”活动图“会员信息建档”活动图“会员信息变更处理”活动图“卡作业处理”活动图状态图反映的是某个对象在其生存期间，响应事件后状态的变化情况会员持卡信息状态图2.4.2状态图1、用例说明的基本内容◆简要说明：概要描述用例的作用。一般认为，用例名称是对用例功能的高度概括。◆前提条件：说明执行该功能之前必须满足的条件。◆事件流：描述具体细节，说明具体操作步骤。指出用例如何开始、进行哪些操作、正常的流程、出错后如何处理、用例如何结束等等。◆事后条件：用例执行后必须为真的条件，即说明该用例执行完后在什么条件下才可以运行另一个用例等等。◆非功能性需求：对用例的运行在可靠性、可用性、可支持性方面的要求，以及性能上和设计约束方面的要求。2.4.3用例说明2、自然语言存在的问题①界限不明确②逻辑次序不明确③含义模糊的形容词或副词3、结构式语言形式结构式语言是介于自然语言和程序设计语言之间的语言形式，在结构式语言中，只允许使用四种句型：◆祈使句；◆判断句◆循环句◆上述三种语句的混合句①祈使句用祈使句说明要做的事情，以动宾结构为主，语句中至少应该包含有一个动词和名词，说明要做什么事情。②判断句在描述功能需求时，常常需要对某个条件做出判断，并根据判断的结果执行不同的操作。采用结构式语言中的判断句进行描述，它的基本语句格式是：如果

条件（成立）

则执行动作序列A否则（条件不成立）

执行动作序列B③循环句循环句的语句结构是：按条件（成立）循环执行

动作序列循环操作结束④混合句用例说明中需要将祈使句、判断句、循环句混合使用，注意到在判断句和循环句的语句格式中使用“动作序列”词汇，说明此时已将祈使句应用到这两个语句格式中，另外，判断句和循环句之间可以是判断句中嵌套循环句、循环句嵌套判断句、判断句中嵌套判断句、循环句中嵌套循环句等多种形式，所以在使用时注意格式中的缩格处理，使书写格式清晰、可读。1、情景描述无论是用例说明还是活动图、状态图，对系统如何实现功能的描述都不是很直观，一些用户在确认需求时会感到比较困难，为此，用一组图片说明系统会发生什么事情，这一组图片便构成情景描述板，用户看到这组图片，便能够感知到系统操作行为是否正确，因此基于