软件需求分析

一、需求分析概述

需求分析就是分析软件用户的需求，它具有决策性、方向性和策略性，需求分析的任务就是解决“做什么”的问题，全面理解用户各项需求，准确表达所接收的用户需求

可行性研究不可替代需求分析，可行性研究阶段粗略的了解了用户的需求甚至提出了一些可行的方案，但是可行性研究的基本目的是用较小的成本在较短的时间内确定是否存在可行的解法，很多细节被忽略，所以并不能代替需求分析

在分析软件需求和书写软甲需求规格说明书的过程中，分析员和用户都起着关键必不可少的重要作用，只有用户才知道自己需要什么，在需求分析阶段结束前，系统分析员要写出软件需求规格说明书，以书面形式准确描述软件需求

需求分析方法遵守以下准则：

1、必须理解并描述问题的信息域，根据这条准则应该建立数据模型

2、必须定义软件应完成的功能，这条准则要求建立功能模型

3、必须描述作为外部事件结果的软件行为，这条准则要求建立行为模型

4、必须对描述信息、功能和行为的模型进行分解，用层次的方式展示细节

确定系统的综合需求：功能需求、性能需求、可行性和可用性需求、出错处理需求、

接口需求、约束、逆向需求、将来可能提出的需求

需求分析高于客户业务流程：需求分析组要工作是提取出核心、主要以及急迫的业务，明晰业务流程，需求调研包括用户的各种业务项目、业务流程、再明细到业务过程的每一个单据，每一条记录，最终分析用户的这业务流程的提中哪些是系统能帮助管理的，哪些是要在系统外进行处理的

需求分析来源于客户已有的业务流程的需要，但不能仅限于此，一个优秀的需求应该在满足既有业务流程需要的基础上，能持续帮助客户优化业务流程，兼具先进性和前瞻性

二、用例和用例图

用例主要用于描述系统应该具备什么样的功能，用例模型基本组成部分有用例、角色（参与者）和系统，参与者是指那些与系统交互的外部实体，用例往往必须向参与者传递一些数值，这些数值是参与者在系统中获得的信息

使用用例的主要目的如下：

1、系统应具备什么功能，这些功能是否满足客户需求；

2、为系统的功能提供清晰一致的描述

3、为系统测试打下基础

4、通过从需求的功能用例出发跟踪进入到系统中具体实现的类和方法

UML是一种用文本、图形和符号的集合的一个建模语言，它在演变的过程中提出了一些新的概念职责、扩展机制、并发、模式、合作、活动图、线程、过程等新概念

用例图：显示一组用例、参与者与它们之间的关系的一种图，用例图从用户的角度描述软件产品的需求，并分析产品的功能和动态行为，由参与者、系统边界、用例、关联4个元素组成

用例图的主要作用如下：

1、用来描述将要开发系统的功能需求和系统的使用场景

2、作为设计和开发过程的基础，促进各阶段开发工作的进展

3、用于验证与确认系统需求

参与者：代表系统的用户（参与者不是指人或事物本身，而是表示人或事物在系统中所扮演的角色）

系统边界：确定系统的范围

用例：代表系统提供的服务

关联：表示参与者与用例间的关系

由于参与者实际上就是类，所以参与者之间是继承关系（子类继承父类），在分析设计阶段一般使用泛化表示继承。

三、用例之间的关系

1、泛化关系：子用例继承父用例所有结构、行为和关系，同理任何父用例的地方可以用子用例来代替

父用例抽象：

父用例非抽象：

2、包含关系（include）：两个或多个用例中共用一组相同的动作，可以将这组相同的动作抽出来作为一个独立的子用例，供多个用例共享，以为子用例被抽出，父用例并非一个完整的用例，所以父用例必须和子用例一起使用

3、扩展（extend）：基础用例中定义有多个已命名的扩展点，扩展用例的实质是在一定条件下，将扩展用例的业务过程按相应的扩展点插入到基础用例中,子用例中的业务过程是一定要插入到基础用例中，且插入点只有一个，扩展用例不一定必须执行，执行扩展用例需要满足一定条件

对于一个系统来说，不同的人进行用例分析后得到的用例数目有的多有的少如果用例粒度很大那么得到的用例数就很少，如果粒度很小，得到的用例数量就很多

四、用例规约

用例规约：用例名称、用例描述、执行者、前置条件、后置条件、正常事件流、异常事件流、业务规则、涉及实体