软件需求分析--三步走

软件项目如何进行需求分析,要解决这个问题，我们要分三步走

 

第一步：通过什么方式去了解需求

了解需求的方式有好几种：

（1）直接与客户交谈。如果分析人员生有足球评论员的那张“大嘴”，就非常容易侃出需求。

（2）有些需求客户讲不清楚，分析人员又猜不透，这时就要请教行家。有些高手真的很厉害，你还没有开始问，他就能讲出前因后果。让你感到“听君一席言，胜读十年书。”

（3）有很多需求可能客户与分析人员想都没有想过，或者想得太幼稚。要经常分析优秀的和蹩脚的同类软件，看到了优点就尽量吸取，看到了缺点就引以为戒。前人既然付了学费，后人就不要拒绝坐享其成。

 

第二步：应该了解什么

那怕是天下最无能的市长或书记，都知道在作报告时要先从宏观上讲一、二、三、四、五，再从细节上讲A、B、C、D、E。需求分析不象侦探推理那样从蛛丝马迹着手。应该先了解宏观的问题，再了解细节的问题

 

一个软件系统（记为 S）的涉及面可能很广，可以按不同的问题域（记为D）分类，每个问题域对应于一个软件子系统。

S = { D1，D2，D3，… Dn }

问题域Di 由若干个问题（记为P）组成，每个问题对应于子系统中的一个软构件。

Di = { P1，P2，P3，… Pm }

问题Pj有若干个行为（或功能，记为F），每个行为对应于软构件中的接口。

Pj = { F1，F2，F3，… Fk }

按这结构写成的需求说明书，对于那些只想了解宏观需求的领导，和需要了解细节的技术员都合适。在写需求说明书时还应该注意两个问题：

（1）最好为每个需求注释“为什么”，这样可让程序员了解需求的本质，以便选用最合适的技术来实现此需求。

（2）需求说明不可有二义性，更不能前后相矛盾。如果有二义性或前后相矛盾，则要重新分析此需求。

 

第三步：如何写需求说明书

主要是利用UML的用例图（领导一般只看这个）和活动图

1.1 为什么要用UML进行需求分析

一:什么是UML
Unified Modeling Language (UML)又称统一建模语言或标准建模语言,是始于1997年一个OMG标准，它是一个支持模型化和软件系统开发的图形化语言,为软件开发的所有阶段提供模型化和可视化支持，包括由需求分析到规格，到构造和配置。

我这里就不讲需求分析在软件产品开发中的地位了,我从项目开发的实际情况讲一下为什么要用UML进行需求分析

1:需求分析是一项重要且贯穿整个项目开发的过程,这样就需要一份很好文档提供给每一个阶段的开发人员,包括:测试人员,维护人员
2:需求分析文档是要给需求管理人员,项目经理,用户,测试人员,项目开发人员看的,如何把需求分析人员所知道的需求很好描述出来也是一件很重要的工作,因为需求分析出来的主要是给别人看;这是仅仅用文字描述是不够的,还需要用图表等多种情形展现需求

1.2 如何用UML进行需求分析

UML的展现形式有多种,如:类图,用例图,顺序图,活动图,状态图等,要跟具实际情况进行选用,我一般在做需求分析时选用"用例图"和"活动图"

1:用例图中清楚的、简要的用例描述每个角色能够使用的功能,方便在用户确认需求时很清楚有哪些功能及每个角色的权限.

2:活动图反应的是一个业务的工作流程,使用活动图有以下好处:
(1):方便用户确认需求,因为用户最了解工作流程,在确认需求时,用户通过我们的活动图,就很容易发现是否满足需求.
(2):有利于于开发人员对整个业务的了解,知道自己在做些什么及如何做.提出不同的解决方案

1.2.1 用例图

用例图的作用及描述

用例图说明的是谁要使用系统以及他们使用该系统可以做些什么?(用例图说明的是业务需求)

它描述了系统提供的一个功能单元。

====主要目的

用例图的主要目的是帮助开发团队以一种可视化的方式理解系统的功能需求，以及系统内用例之间的关系。用例图一般表示出用例的组织关系.
反应每个角色的权限,清楚的、简要的描述每个角色能够使用的功能,方便在用户确认需求时很清楚每个角色的权限.

用例图的画法

名词解释

1:参与者
参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。因此参与者可以是人，可以是事物，也可以是时间或其他系统等等。还有一点要注意的是，参与者不是指人或事物本身，而是表示人或事物当时所扮演的角色。比如小明是图书馆的管理员，他参与图书馆管理系统的交互，这时他既可以作为管理员这个角色参与管理，也可以作为借书者向图书馆借书，在这里小明扮演了两个角色，是两个不同的参与者。参与者在画图中用简笔人物画来表示，人物下面附上参与者的名称。

2:用例
用例是用户期望系统具备的动作.创立一个用例名时,要尽量使用主动语态动词和可以描述系统上执行的功能的名词.

3:箭头
箭头用来表示参与者和系统通过相互发送信号或消息进行交互的关联关系。箭头尾部用来表示启动交互的一方，箭头头部用来表示被启动的一方，其中用例总是要由参与者来启动。

角色之间的关系：

由于角色实质上也是类，所以它拥有与类相同的关系描述，即角色之间存在泛化关系，泛化关系的含义是把某些角色的共同行为提取出来表示为通用的行为。

1:泛化
是一种用于表示UML中项目的继承的技术.泛化可以应用于参与者和用例来表示其子项从父项继承功能,而且泛化还表示父亲的每个孩子都有着略微不同的功能或目的以确保自己的惟一性.
泛化关系的含义是把某些角色的共同行为提取出来表示为通用的行为。

*只要能说出"A项是B项的一种",你就找到了一个泛化.

用例与用例之间的关系

1:泛化

2:包含关系：
基本用例的行为包含了另一个用例的行为。基本用例描述在多个用例中都有的公共行为。包含关系本质上是比较特殊的依赖关系。它比一般的依赖关系多了一些语义。在包含关系中箭头的方向是从基本用例到包含用例。在UML1.1中用例之间是使用和扩展这两种关系，这两种关系都是泛化关系的版型。在UML1.3以后的版本中用例之间是包含和扩展这两种关系。

*当一个用例要一直使用另一个用例时就确定为包含关系.

3:扩展关系

扩展关系的基本含义和泛化关系类似，但在扩展关系中，对于扩展用例有更多的规则限制，基本用例必须声明扩展点，而扩展用例只能在扩展点上增加新的行为和含义。与包含关系一样，扩展关系也是依赖关系的版型。在扩展关系中，箭头的方向是从扩展用例到基本用例，这与包含关系是不同的。

*当一个用例可能使用另一个用例时就确定为扩展关系.

==用例的泛化、包含、扩展关系的比较。
一般来说可以使用“is a”和“has a”来判断使用那种关系。范化和扩展关系表示用例之间是“is a”关系，包含关系表示用例之间是“has a”关系。扩展与范化相比多了扩展点，扩展用例只能在基本用例的扩展点上进行扩展。在扩展关系中基本用例是独立存在。在包含关系中在执行基本用例的时候一定会执行包含用例。如果需要重复处理两个或多个用例时可以考虑使用包含关系，实现一个基本用例对另一个的引用。当处理正常行为的变形是偶尔描述时可以考虑只用泛化关系。当描述正常行为的变形希望采用更多的控制方式时，可以在基本用例中设置扩展点，使用扩展关系。扩展关系比较难理解，如果把扩展关系看作是带有更多规则限制的泛化关系，可以帮助理解。通常先获得基本用例，针对这个用例中的每一个行为提问：该步骤会出什么差错？该步骤有不同的情况吗？该步骤的工作怎样以不同的方式进行等，把所有的变化情况都标识为扩展。通常基本用例很容易构造，而扩展用例需要反复分析、验证。当我们发现已经存在的两个用例间具有某种相似性时，可以把相似的部分从两个用例中抽象出来单独作为一个用例，该用例被这两个用例同时使用，这个抽象出的用例和另外两个用例形成包含关系。

建模步骤

1:创建用例图有5项任务:

(1)找出系统中的参与者和用例.

(2)区分用例的优先次序.

(3)细化每个用例.

(4)建立用例模型结构.

(5)建立用户界面的原型.

2:构建一个用例图的步骤:

(1)确定出系统的参与者.

(2)确定出系统的用例.

(3)区分用例的优先次序.

(4)按照优先次序细化每个用例.

(5)确定出每个用例中的泛化: 只要能说出"A项是B项的一种",你就找到了一个泛化.

(6)确定每个用例中的包含关系. 切记:当一个用例要一直使用另一个用例时就确定为包含关系.

(7)在每个用例中确定扩展关系. 切记:当一个用例可能使用另一个用例时就确定为扩展关系.

(8)使用你已经确定的参与者,用例,泛化,包含关系和扩展关系为每个用例创建一个用例图.

1.2.2 活动图

活动图的作用及描述

活动图（activity diagram，动态图）是阐明了业务用例实现的工作流程。

活动图的画法

名词解释

活动图主要包括:
1:起点
只有一个,只有离开的前迁移

2:终点
可以多个,只有进入的迁移

3:活动
活动状态表示在工作流程中执行某个活动或步骤
有进有出,命名:动宾结构

4:转移
转移表示各种活动状态的先后顺序。这种转移可称为完成转移。它不同于一般的转移，因为它不需要明显的触发器事件，而是通过完成活动（用活动状态表示）来触发。

5:判定
决定在活动完成后将执行一组备选转移中的哪一个转移
判定的内容在前面活动中或者由泳道直接产生(误把活动当判定)

6:并行(分支与合并)
并行示意条用于显示平行分支流。同步示意条使您能够显示业务用例的工作流程中的并行线程。
当两个活动间没有直接的联系，而且它们都必需在第三个活动开始前结束，那它们是可以并行运行的。
例如:建"发放标准",基础物资初始化,人员类别初始化

有分必有合
有分必有进
有分必有出
并行!=同时

7:泳道
活动的负责者,可能多维
以使用垂直实线将活动图划分为泳道。每条泳道代表整个工作流程的某个部分的职责，该职责由组织的某个部门来执行。泳道最终可以由组织单元或者业务对象模型中的一组类来实施。泳道之间的排序并不会影响语义。每个活动状态都指派了一条泳道，而转移则可能跨越数条泳道。

8:嵌套活动图
一个活动状态可能要引用另一个活动图，因为后者显示了前者的内部结构。换言之，您可以嵌套活动图。您可以显示活动状态中的子图或是让活动状态引用另一个图。

建模步骤

建模步骤:

第一步，定义活动图的范围
首先应该定义您要对什么建模。单个用户案例力？一个用户案例的一部分？一个包含多个用户案例的商务流程？一个类的单个方法？一旦您定义了您所作图的范围，您应该在其顶部，用一个标注添加标签，指明该图的标题和唯一的标示符。您有可能也想要包括该图的时间甚至作者名。

第二步，添加起始和结束点

每个活动图有一个起始点和结束点，因此您也要马上添加它们。在《UML精粹》(UML Distilled)(参见 参考资料)，Fowler 和Scott认为结束点是可选的。有时候一个活动只是一个简单的结束，如果是这种情况，指明其唯一的转变是到一个结束点也是无害的。这样，当其他人阅读您的图时，他或她知道您已经考虑了如何退出这些活动。

第三步，添加活动

如果您正对一个用户案例建模，对每个角色(actor)所发出的主要步骤引入一个活动(该活动可能包括起始步骤，加上对起始步骤系统响应的任何步骤)。如果您正对一个高层的商务流程建模，对每个主要流程引入一个活动，通常为一个用户案例或用户案例包。最后，如果您正对一个方法建模，那么对此引入一个活动是很常见的。

第四步，添加决策点

有时候，您所建模的逻辑需要做出一个决策。有可能是需要检查某些事务或比较某些事务。要注意的是，使用决策点是可选的。例如，在图1中，我可以只是简单地将“接受”和“拒绝”两个转变直接接到“在大学报名(Enrollin University)”活动。"

第五步，找出可并行活动之处

当两个活动间没有直接的联系，而且它们都必需在第三个活动开始前结束，那它们是可以并行运行的。在图1中，您看到是有可能“参加简要介绍(attendoverview)”和“报名研讨班(enroll in seminars)”可以按任意次序进行，但是它们都得在您结束整个流程前完成。

第六步，添加活动间的转变

我的风格总是应该退出一个活动，即使它是转变到一个结束点。一旦一个活动有多个转变时，您必需对每个转变加以相应标示。