第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、完整性、正确性检验 完整性检验，主要是对照相关的资料，检查是否存在被遗漏的功能，为满足未来发展变化需要，考察是否需要增加应对未来发展变化的功能；检查功能描述所包含的内容是否完整和明确，是否存在歧义。,目前进行系统分析和设计大多采用面向对象方法，并用统一建模语言（Unified Modeling Language，UML）来描述，其中利用用例图构建的用例模型便是需求分析的工作产品，对业务流程中描述的功能进行分析产生系统的功能需求，用用例来描述，功能之间的关系也就是用例之间的关系则描绘成用例图。,2.3 用例模型,1、用例 用例（Use Case）是在不展现系统内部结构的情况下，对系统功能的定义和描述。它来自于用户对系统所期望的功能需求，描述系统在响应来自某个参与者（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、情景描述 无论是用例说明还是活动图、状态图，对系统如何实现功能的描述都不是很直观，一些用户在确认需求时会感到比较困难，为此，用一组图片说明系统会发生什么事情，这一组图片便构成情景描述板，用户看到这组图片，便能够感知到系统操作行为是否正确，因此基于一组与活动顺序一致的图片与用户进行沟通，能够有效而准确地对用例说明、活动图、状态图进行检验。,2.4.4 情景描述板及验证,“卡类型管理”用例 情景描述板,2、用例检验 包括以下方面内容 情景描述板的完整性 用例说明中是否存在歧义、不明确、不正确的描述 前置条件和后置条件是否与业务流程相吻合 用例说明中提示信息的检验 非功能性需求的检验 可用性评价,