怎样做需求分析之十三：分析之行动图和状态图
需求分析方法
表示与关系
[｜] 表示或关系
字 [,] ()
典 {}
表示可选项 表示重复
M{}n 表示规定次数的重复
“” 表示基本数据元素
..
连接符
** 表示注释
说明 用于对于=左边的条目进行确切的含义 X=a+b表示X由a和b共同构成 X=[a｜b]与X=[a,b]等价，表示X由a或b组成
X=(a)表示a可以在X中出现，也可以不出现 大括号中的内容重复0到多次 重复的次数最少m次，最多n次
OOA并不区分问题域描 述与解系统描述之间的差异， 而是直接交付出新的解系统的 高层设计。
两种方法的比较
结构化分析方法
面向对象分析方法
SA和OOA还有几点相同特性： （1）主要模型是结构模型； （2）通常焦点集中在对解系统的建模上； （3）两种方法都较少地应用于需求获取领域； （4）分析与内部设计之间没有明显差异。
3a）“用户名或密码错误”，系统出现用户名或密码错误的提 示信息，回到主要流程1，由用户重新输入 3b）“输入的用户名与类型不符”，系统出现提示信息，回到 主要流程1，由用户重新输入 3c）当用户点击取消按钮时，取消登录
2．类图Class Diagram
2．类图Class Diagram
关联
0..* 参加 1..*
示例： 银行 取款 系统
简单银行取款应用描述：
储户将填好的取款单、存折交银行，银行做如 下处理：
①审核并查对帐目，将不合格的存折、取款 单退回储户，合格的存折、取款单送取款处理。
②处理取款修改帐目，将存折、利息单、结 算清单及现金交储户，同时将取款单存档。
画出银行取款处理数据流图。
2．过程建模： 数据流图Data Flow Diagram
软件需求分析中的状态图技术
软件需求分析中的状态图技术在软件开发的过程中，需求分析是非常重要的一环节，对于大型项目来说，更是至关重要。
在需求分析的过程中，一些专业的技术和工具能够帮助我们更好地理解和描述需求，其中状态图技术就是一种非常实用的方法。
一、状态图的基本概念状态图是一种描述系统状态及状态转移的图形化表示方法。
在状态图中，每一个状态都可以看作是一个节点，节点之间用箭头连接，表示状态之间可以发生转移。
状态图包括三个重要的元素：状态、转移和事件。
状态对应系统的不同运行状态，转移表示状态之间的相互关系，事件则是触发系统状态转移的条件。
在软件系统的需求分析过程中，状态图通常用于描述系统的业务流程和功能模块之间的状态转换关系。
通过状态图，开发人员可以更准确地把握需求，从而确保开发出更符合用户需求的系统。
二、状态图的使用场景1. 描述业务流程状态图可以用于描述业务流程，以图形化的形式描述业务状态之间的关系和转移条件，帮助开发人员更直观地理解业务流程。
在实际应用中，状态图可以用于描述订单生命周期、用户注册流程等。
2. 描述系统的功能模块状态图可以用于描述系统的功能模块之间的状态转换关系，帮助开发人员更好地理解系统的功能模块。
在实际应用中，状态图可以用于描述用户登录模块、消息发送模块等。
3. 描述系统的异常流程除了描述正常的业务流程和功能模块，状态图还可以用于描述系统的异常流程，如输入错误的用户名，密码错误等。
通过描述系统的异常流程，开发人员可以更好地处理异常情况，提高系统的容错性。
三、状态图的优点1. 图形化表示，易于理解状态图以图形化的方式描述系统状态之间的转换关系，使得需求分析更加清晰而直观，易于理解，并且符合人类的视觉认知特点。
2. 面向对象，易于维护状态图可以看作是一种面向对象的描述方法，每一个状态都可以看作是一个对象，而状态之间的关系则由状态之间的转换条件来判断。
这种方式使得状态图易于维护和修改。
3. 提高分析能力，缩短开发周期通过使用状态图进行需求分析，开发人员可以更全面地理解用户需求，从而正确地设计系统架构和功能模块。
如何做好需求分析
如何做好需求分析需求分析是软件开发的关键步骤之一，它涉及到对用户需求进行理解和规划，同时也是设计和开发过程中的基础。
下面是一些关键的步骤和技巧，可以帮助您做好需求分析。
1.确定和理解用户需求：与用户进行深入的沟通和访谈，以了解他们的需求。
确保准确地获取用户的期望和目标。
这可以通过使用各种技术，例如访谈、问卷调查和原型创建来实现。
2.建立需求规范：根据从用户那里收集到的信息，制定一份完整的需求规范文档。
这份文档应该包括功能需求、非功能需求、优先级、约束条件以及与其他系统的交互等内容。
3.分析和拆解需求：将整体需求拆分成更小、更具体的单元。
这样可以更好地理解和处理需求。
可以使用工具和技术，如用例图、流程图和状态转换图，来帮助分析和拆解需求。
4.确认需求的可行性：验证和确保所提出的需求是可行的，并且能够在给定的限制条件下实现。
这可以通过技术评审、成本估算和风险分析等方法来实现。
5.管理变更和优先级：需求分析过程中，很有可能会出现需求变更。
因此，需要建立一个良好的变更管理机制，确保所有的变更都得到适当的审查和批准。
另外，还需要为不同的需求给出优先级，以便在设计和开发过程中能够有条不紊地进行。
6.与其他团队成员的合作：需求分析过程中需要与设计、开发和测试团队紧密合作。
确保他们充分理解需求，并在开发过程中的每一个阶段都能满足这些需求。
7.使用合适的工具和技术：使用适当的工具和技术来支持需求分析过程。
这些工具可以帮助您管理和维护需求规范，创建和查看需求文档，以及与其他团队成员进行需求的共享和讨论。
8.精确的描述和文档化：需求分析的结果需要进行准确的描述和文档化。
确保将需求规范文档清晰地记录下来，并与其他相关文档进行适当的链接，以便在需要时能够方便地查阅。
9.进行评审和验证：在需求分析过程的不同阶段进行评审和验证，以确保分析结果的准确性和合理性。
可以邀请用户和其他团队成员参与评审和验证过程，以获取更多的反馈和建议。
七步让你做好需求分析
七步让你做好需求分析确定项目目标第一步是与团队一起明确项目的目标和范围。
这些目标需要从多个利益相关者的角度进行审查，并且应该能够明确地解释给所有人。
一、了解业务需求首先，需要对项目的业务需求进行深入了解。
这包括对业务过程、业务规则、数据模型等方面的分析。
在这个阶段，可以与业务相关人员进行沟通，听取他们的意见和建议。
同时，可以借助各种工具和技术，如流程图、数据字典、用例图等来帮助理解业务需求。
二、分析用户需求除了业务需求，还需要对用户需求进行分析。
用户需求是指用户对系统或产品的期望和要求，包括功能需求、性能需求、可靠性需求、安全需求等。
在这个阶段，可以采用用户调研、问卷调查等方法，收集用户的反馈和建议。
同时，也可以通过竞品分析、市场研究等方式，了解用户的偏好和需求趋势。
三、制定需求规格说明书为了更好地明确项目目标，需要制定一份完整的需求规格说明书。
该文档应包括项目的业务需求、用户需求、功能列表、性能指标、安全要求等信息，以及各种约束条件和假设前提。
在制定需求规格说明书时，需要注意以下几点：1.明确需求的优先级。
不同的需求具有不同的重要性和紧急程度，需要按照一定的优先级进行排序。
2.确保需求可行性。
需求规格说明书中列举的需求应当是可行的，不要超出技术或资源的限制。
3.避免冲突和歧义。
需求规格说明书中应尽量避免冲突和歧义，以免后续开发过程中出现问题。
四、与利益相关者沟通在确定项目目标的过程中，需要与各方利益相关者进行充分沟通。
这包括业务代表、用户、开发团队、测试团队、运维团队等。
通过与他们的沟通，可以更好地理解各方的需求和期望，协调各方的利益关系，确保项目成功完成。
五、制定项目计划最后，确定项目目标之后，需要制定一个详细的项目计划。
该计划应包括项目的时间表、里程碑、资源分配、风险管理等方面的内容。
在制定项目计划时，需要充分考虑各方的需求和利益，确保项目目标得以实现。
总之，通过对业务需求和用户需求的分析，制定完整的需求规格说明书，并与各方利益相关者充分沟通，最终制定一个详细的项目计划，可以更好地确定项目目标。
需求分析工作流程示意图
客户(用户)
需求及范围确 认
确认
项目技术 难点与解 决方案说 明
输出
需求分析 说明书
需求优先 级
需求管理工作流程动态视图
了解客户愿景与制定需求 计划
验证变更
需求评审与验证 需求分析
拒绝变更
变更影响分析
需求规格
需求变更请求
需求分析工作流程示意图
确定项目业务范围,形成项目的产品需求
输入
系统建设限 制性条件
项目建设非 功能性需求
业务知识分 析表
客户愿景分 析表
收集项目建设 限制条件
撰写需求分析 说明书
需求人员
分析项目业务 用例与业务模 式
调研项目非功 能性需求
确定项目业务 边界范围
完善需求分析 说明书
需求分析结束
初步分析项目 建设难点
分析项目需求 优级
需求评审人员
需求优先级评 审 是 其它评审工作 否
设计人员
确认分析项目 建设难点
初步提供项目技 术难点解决建议
需求分析(流程图+数据字典)
3．提高数据流程图的可理解性
（1）尽量减少处理框间输入、输出数据流的数目，以简化 处理间的联系。在数据流程图中，处理框间的数据流越少， 各个处理就越独立，用户对每个部分可以单独理解。因此， 在对处理框进行分解时，应尽量使各处理框间的关系简化， 这样可以使一个复杂的问题转变成若干简单的问题来处理。
– 1 数据项 – 2 数据结构 – 3 数据流 – 4 处理逻辑 – 5 数据存储
7.4.1 数据项的定义
数据项又称数据元素，是数据的最小单位。 在数据字典中，数据项的描述包括：
a P1.1
P1.2 c c P2.1
P1.3
d P2.2
P2.3 e
b P3.1 P3.2 P3.3 d 2层
顶层数据流程图
• 封闭：顶层封闭，子层可不封闭
第一层数据流程图
第二层数据流程图——进货
第二层数据流程图——销售
第二层数据流程图——盘存与报损
2.4 绘制数据流程图的注意事项
1．数据流程图的分层
顾客 请求 顾客订单
递交
导购 代表
查询
库存帐
呈送
销售单
开出
客户资料退 货Fra bibliotek查询修
修改
改
请
求
顾客退单
递交
导购 同意退货 销售退单 代表
流水帐
登记
11
1 需求分析的方法
数据流程图DFD（date flow diagram）和数据 字典DD（date dictionary）是描述用户需求的 重要工具。
需求分析图
机票预订系统-规格说明书目录I．引言A．系统参考文献《软件工程（第3版）》《机票预订系统规格说明书》B．整体描述C．软件项目约束II．信息描述A．信息内容B．信息流1. 数据流2. 控制流III．功能描述A．功能分解1．客户端子系统客户端子系统负责将订票员在客户端输入的信息，订票或取票，进行有效性验证之后，将订票申请或取票申请数据打包，发送到服务器端，并接收从服务器返回的信息，根据订票或取票打印出账单或机票。
2．服务器端子系统服务端子系统负责接收客户端子系统发送的数据，解包后判断是订票还是取票操作，执行相应的数据库操作，并将操作的结果返回给客户端。
B．功能描述1. 处理说明2. 限制3. 性能需求为了保证系统能够长期、安全、稳定、可靠、高效的运行，机票预订系统应该满足以下的性能需求：1．系统处理的准确性和及时性系统处理的准确性和及时性是系统的必要性能。
在系统设计和开发过程中，要充分考虑系统当前和将来可能承受的工作量，使系统的处理能力和响应时间能够满足企业对信息处理的需求。
在系统开发过程中，必须采用一定的方法保证系统的准确性。
2．系统的开放性和系统的可扩充性机票预订系统在开发过程中，应该充分考虑以后的可扩充性。
例如企业中管理模块的加入（人事管理、工资管理、日常事务管理等）也会不断的更新和完善。
所有这些，都要求系统提供足够的手段进行功能的调整和扩充为ERP系统。
而要实现这一点，应通过系统的开放性来完成，即系统应是一个开放系统，只要符合一定的规范，可以简单的加入和减少系统的模块，配置系统的硬件。
通过软件的修补、替换完成系统的升级和更新换代。
3．系统的易用性和易维护性机票预订系统是直接面对使用人员的，而使用人员往往对计算机并不时非常熟悉。
这就要求系统能够提供良好的用户接口，易用的人机交互界面。
要实现这一点，就要求系统应该尽量使用用户熟悉的术语和中文信息的界面；针对用户可能出现的使用问题，要提供足够的在线帮助，缩短用户对系统熟悉的过程。
教学课件PPT状态图和活动图
3
UML理论与实践
状态
状态由状态名、状态变量和活动三部分组成。 状态变量是状态图所显示的类的属性，也可以是临时变量。 活动部分列出了处于该状态时要执行的事件和动作。有3 个标准事件： entry事件用于指明进入该状态时的特定动作。
exit事件用于指明退出该状态时的特定动作。
do事件用于指明在该状态中时执行的动作。
24
UML理论与实践
H和H*的区别：
H只记住最外层的组合状态的历史。 H*可记住任何深度的组合状态的历史。
例：历史状态的例子。
25
UML理论与实践
状态图的工具支持
正向工程：根据状态图生成代码。例：
所生成的代码示例：
26 UML理论与实践
class MessageParser { public boolean put(char c) { switch (state) { case Waiting: if (c == '<') { state = GettingToken; token = new StringBuffer(); body = new StringBuffer(); } break; case GettingToken : if (c == '>') state = GettingBody; else token.append(c); break; case GettingBody : if (c == ';') { state = Waiting; return true; }
[change = 0]
[change > 0]
自动售货机 状态图
9 UML理论与实践
Do:dispense item
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
怎样做需求分析之十三：分析之行动图和状态图
作者: fangang发布时间: 2012-04-11 10:23
前面，我们耗费了大量的篇幅来讨论用例分析及用例图。
用例图，无疑是功能分析、角色分析，以及流程分析的利器，它将我们要开发的系统，清晰而详尽地描述出来。
但是，正如任何事物都有两面性，用例图也不例外，也有自己不利的一面。
在我看来，这集中体现在两个方面：只见树木不见森林、不生动形象。
什么叫“只见树木不见森林”呢？就是说，用例说明中对业务流程的描述，过早地将系统的整体流程，分散到了各个用例中了，丢失了对业务流程的整体描述。
不生动形象，则是说用例说明中对流程的描述都是用枯燥无味的文字来表述的，缺乏生动形象的图形表示。
针对这些不足，UML的另外两种视图，可以有效地弥补用例图的缺陷。
它们就是行动图与状态图。
行动图（Active Diagram），比较类似于我们过去绘制的流程图，是UML中描述流程与分支的视图。
在行动图中，往往是从一个实心圆的起始节点开始的。
最频繁使用的则是活动节点了，它表示的是业务流程中的一项活动。
活动节点可以表述为一个活动短语（如下订单），可以表述为一个表达式（如len=a.length+x），还可以表述为一个消息（如send(msg)）。
同时，将各个活动节点连接起来的一个个实线箭头，表明了各种活动之间的流转顺序。
在各种业务流程中，毫无疑问会有许多的分支。
在行动图中，分支用一个菱形来表示。
一个指向菱形的箭头，表示流程进入分支，另外两个或多个从菱形伸出的箭头，则表示不同条件下的分支流。
而菱形本身，则表示为一个条件判断语句。
另外，业务中的各个流程还会分岔与汇合的情况。
分岔，表示在某个时间点上，同时开始两个业务流程，这两个业务流程是同步进行的。
分岔用一个入箭头，一根横杠，与两个出箭头表示。
汇合，则表示，只有在两个流程都完成的情况下，才会进入下一流程，否则只能等待。
汇合则用两个入箭头，一根横杠，与一个出箭头表示。
最后，用一个或多个带环的实心圆，表示的是活动图的终止节点，代表了业务流程的终结。
以上这些元素，就组成了一个基本的活动图。
然而，基本的活动图还不能完整的反映我们的业务流程，因此我们还需要在基本活动图的基础上增加元素。
现在我们来看看泳道与业务对象流。
如图就是一个带泳道的活动图，图中每个泳道代表一个参与者的业务操作，而整个图形表述了多个参与者间的协作过程。
起初我比较爱绘制这样的活动图，但后来常常感到绘制泳道是
一件比较繁琐的事情。
既然如此，我们就改改吧。
这张图才是我最爱使用的行动图。
图中，将参与者由繁琐的泳道改为了用例图中的小人。
同时，在这张图中还增加了对象流与对象。
图中，自动考核结果、申辩申请单、调整后考核结果，都是数据对象，是该流程中相关环节操作的结果。
从活动节点指向对象的虚线箭头，则表示了一个对象流，如“申辩申请”活动指向“申辩申请单”的虚线箭头，表示了申辩申请活动的最终结果是产生申辩申请单；从“调整后考核结果”指向“过错追究”的虚线箭头，表示过错追究活动读取了调整后考核结果。
当然，活动图还有其它的元素，但我个人认为其实并不实用，使用以上元素就足以表述我们的业务流程了。
活动图打破了子系统与子系统的壁垒、用例与用例的壁垒，使我们能够从整体上了解整个系统的流程，因此常常使用在对整个系统的概述、对整个子系统的概述，以及对整个功能模块的概述中。
同时，与其它视图一样，活动图也应当有它的文字说明，以便对图中的每个活动节点、分支进行描述。
但对于一些流程相对简单，甚至没有什么流程的查询报表类功能模块，绘制它们的活动图则显得有些牵强附会，因此我们要灵活掌握。
除了活动图，我们似乎对需求的描述还缺少点儿什么，那就是对关键对象中流程中状态变化的描述，在这种情况下，我们的状态图就上场了。
在使用状态图时，一个非常关键的概念就是，一定是对某个关键对象的状态变化的描述，而这些状态变化一定是在某个业务流程的大背景下进行的。
下图是一个疑点数据整个生命周期的状态变化图。
图中，与行动图一样，一个实心圆点代表的是流程的开始，圆边的方框代表的是对象生命周期中的各个状态，状态节点间的实线箭头代表的是状态的切换，箭头的文字描述是触发状态切换的事件。
与行动图一样，状态图可以有分支、分岔、汇合，并最后以一个或多个带环的实心圆结束，代表对象生命周期的终结。
在需求分析中，状态图并不是必须的，它仅仅出现在你认为需要对某个对象的状态进行说明的时候。