下载文档原格式
软件需求分析中的状态图技术在软件开发的过程中，需求分析是非常重要的一环节，对于大型项目来说，更是至关重要。
在需求分析的过程中，一些专业的技术和工具能够帮助我们更好地理解和描述需求，其中状态图技术就是一种非常实用的方法。
一、状态图的基本概念状态图是一种描述系统状态及状态转移的图形化表示方法。
在状态图中，每一个状态都可以看作是一个节点，节点之间用箭头连接，表示状态之间可以发生转移。
状态图包括三个重要的元素：状态、转移和事件。
状态对应系统的不同运行状态，转移表示状态之间的相互关系，事件则是触发系统状态转移的条件。
在软件系统的需求分析过程中，状态图通常用于描述系统的业务流程和功能模块之间的状态转换关系。
通过状态图，开发人员可以更准确地把握需求，从而确保开发出更符合用户需求的系统。
二、状态图的使用场景1. 描述业务流程状态图可以用于描述业务流程，以图形化的形式描述业务状态之间的关系和转移条件，帮助开发人员更直观地理解业务流程。
在实际应用中，状态图可以用于描述订单生命周期、用户注册流程等。
2. 描述系统的功能模块状态图可以用于描述系统的功能模块之间的状态转换关系，帮助开发人员更好地理解系统的功能模块。
在实际应用中，状态图可以用于描述用户登录模块、消息发送模块等。
3. 描述系统的异常流程除了描述正常的业务流程和功能模块，状态图还可以用于描述系统的异常流程，如输入错误的用户名，密码错误等。
通过描述系统的异常流程，开发人员可以更好地处理异常情况，提高系统的容错性。
三、状态图的优点1. 图形化表示，易于理解状态图以图形化的方式描述系统状态之间的转换关系，使得需求分析更加清晰而直观，易于理解，并且符合人类的视觉认知特点。
2. 面向对象，易于维护状态图可以看作是一种面向对象的描述方法，每一个状态都可以看作是一个对象，而状态之间的关系则由状态之间的转换条件来判断。
这种方式使得状态图易于维护和修改。
3. 提高分析能力，缩短开发周期通过使用状态图进行需求分析，开发人员可以更全面地理解用户需求，从而正确地设计系统架构和功能模块。
如何做好需求分析需求分析是软件开发的关键步骤之一，它涉及到对用户需求进行理解和规划，同时也是设计和开发过程中的基础。
下面是一些关键的步骤和技巧，可以帮助您做好需求分析。
1.确定和理解用户需求：与用户进行深入的沟通和访谈，以了解他们的需求。
确保准确地获取用户的期望和目标。
这可以通过使用各种技术，例如访谈、问卷调查和原型创建来实现。
2.建立需求规范：根据从用户那里收集到的信息，制定一份完整的需求规范文档。
这份文档应该包括功能需求、非功能需求、优先级、约束条件以及与其他系统的交互等内容。
3.分析和拆解需求：将整体需求拆分成更小、更具体的单元。
这样可以更好地理解和处理需求。
可以使用工具和技术，如用例图、流程图和状态转换图，来帮助分析和拆解需求。
4.确认需求的可行性：验证和确保所提出的需求是可行的，并且能够在给定的限制条件下实现。
这可以通过技术评审、成本估算和风险分析等方法来实现。
5.管理变更和优先级：需求分析过程中，很有可能会出现需求变更。
因此，需要建立一个良好的变更管理机制，确保所有的变更都得到适当的审查和批准。
另外，还需要为不同的需求给出优先级，以便在设计和开发过程中能够有条不紊地进行。
6.与其他团队成员的合作：需求分析过程中需要与设计、开发和测试团队紧密合作。
确保他们充分理解需求，并在开发过程中的每一个阶段都能满足这些需求。
7.使用合适的工具和技术：使用适当的工具和技术来支持需求分析过程。
这些工具可以帮助您管理和维护需求规范，创建和查看需求文档，以及与其他团队成员进行需求的共享和讨论。
8.精确的描述和文档化：需求分析的结果需要进行准确的描述和文档化。
确保将需求规范文档清晰地记录下来，并与其他相关文档进行适当的链接，以便在需要时能够方便地查阅。
9.进行评审和验证：在需求分析过程的不同阶段进行评审和验证，以确保分析结果的准确性和合理性。
可以邀请用户和其他团队成员参与评审和验证过程，以获取更多的反馈和建议。
七步让你做好需求分析确定项目目标第一步是与团队一起明确项目的目标和范围。
这些目标需要从多个利益相关者的角度进行审查，并且应该能够明确地解释给所有人。
一、了解业务需求首先，需要对项目的业务需求进行深入了解。
这包括对业务过程、业务规则、数据模型等方面的分析。
在这个阶段，可以与业务相关人员进行沟通，听取他们的意见和建议。
同时，可以借助各种工具和技术，如流程图、数据字典、用例图等来帮助理解业务需求。
二、分析用户需求除了业务需求，还需要对用户需求进行分析。
用户需求是指用户对系统或产品的期望和要求，包括功能需求、性能需求、可靠性需求、安全需求等。
在这个阶段，可以采用用户调研、问卷调查等方法，收集用户的反馈和建议。
同时，也可以通过竞品分析、市场研究等方式，了解用户的偏好和需求趋势。
三、制定需求规格说明书为了更好地明确项目目标，需要制定一份完整的需求规格说明书。
该文档应包括项目的业务需求、用户需求、功能列表、性能指标、安全要求等信息，以及各种约束条件和假设前提。
在制定需求规格说明书时，需要注意以下几点：1.明确需求的优先级。
不同的需求具有不同的重要性和紧急程度，需要按照一定的优先级进行排序。
2.确保需求可行性。
需求规格说明书中列举的需求应当是可行的，不要超出技术或资源的限制。
3.避免冲突和歧义。
需求规格说明书中应尽量避免冲突和歧义，以免后续开发过程中出现问题。
四、与利益相关者沟通在确定项目目标的过程中，需要与各方利益相关者进行充分沟通。
这包括业务代表、用户、开发团队、测试团队、运维团队等。
通过与他们的沟通，可以更好地理解各方的需求和期望，协调各方的利益关系，确保项目成功完成。
五、制定项目计划最后，确定项目目标之后，需要制定一个详细的项目计划。
该计划应包括项目的时间表、里程碑、资源分配、风险管理等方面的内容。
在制定项目计划时，需要充分考虑各方的需求和利益，确保项目目标得以实现。
总之，通过对业务需求和用户需求的分析，制定完整的需求规格说明书，并与各方利益相关者充分沟通，最终制定一个详细的项目计划，可以更好地确定项目目标。
机票预订系统-规格说明书目录I．引言A．系统参考文献《软件工程（第3版）》《机票预订系统规格说明书》B．整体描述C．软件项目约束II．信息描述A．信息内容B．信息流1. 数据流2. 控制流III．功能描述A．功能分解1．客户端子系统客户端子系统负责将订票员在客户端输入的信息，订票或取票，进行有效性验证之后，将订票申请或取票申请数据打包，发送到服务器端，并接收从服务器返回的信息，根据订票或取票打印出账单或机票。
2．服务器端子系统服务端子系统负责接收客户端子系统发送的数据，解包后判断是订票还是取票操作，执行相应的数据库操作，并将操作的结果返回给客户端。
B．功能描述1. 处理说明2. 限制3. 性能需求为了保证系统能够长期、安全、稳定、可靠、高效的运行，机票预订系统应该满足以下的性能需求：1．系统处理的准确性和及时性系统处理的准确性和及时性是系统的必要性能。
在系统设计和开发过程中，要充分考虑系统当前和将来可能承受的工作量，使系统的处理能力和响应时间能够满足企业对信息处理的需求。
在系统开发过程中，必须采用一定的方法保证系统的准确性。
2．系统的开放性和系统的可扩充性机票预订系统在开发过程中，应该充分考虑以后的可扩充性。
例如企业中管理模块的加入（人事管理、工资管理、日常事务管理等）也会不断的更新和完善。
所有这些，都要求系统提供足够的手段进行功能的调整和扩充为ERP系统。
而要实现这一点，应通过系统的开放性来完成，即系统应是一个开放系统，只要符合一定的规范，可以简单的加入和减少系统的模块，配置系统的硬件。
通过软件的修补、替换完成系统的升级和更新换代。
3．系统的易用性和易维护性机票预订系统是直接面对使用人员的，而使用人员往往对计算机并不时非常熟悉。
这就要求系统能够提供良好的用户接口，易用的人机交互界面。
要实现这一点，就要求系统应该尽量使用用户熟悉的术语和中文信息的界面；针对用户可能出现的使用问题，要提供足够的在线帮助，缩短用户对系统熟悉的过程。
需求分析怎么做？（上）在具体的研究需求分析之前，我们先了解一下软件工程这个概念。
软件工程分为三个层次，过程层、方法层、工具层。
在最基础的过程层，最重要的就是一组被称为关键过程区域（KPAs）的框架（KPA的概念在讨论CMM的书中有详细的概念说明）。
关键过程区域构成了软件项目的管理控制的基础，并且确立了上下文各区域的关系，其中规定了技术方法的采用、工程产品的，模型、文档、数据、报告、表格等，等的产生、里程碑的建立、质量的保证及变化的适当管理。
方法层主要是过程在技术上的实现。
它解决的问题是如何做。
软件工程方法涵盖了一系列的任务：需求分析、设计、编程、测试、维护。
同时他还包括了一组基本原则，控制了每一个的关键过程区域。
工具层就很好理解了，他对过程层和方法层提供了自动和半自动的支持。
这些辅助工具就称为CASE。
可以看到需求分析的位置，但是事实上需求分析是跨越了软件工程的三个层次的。
这一点是和其他的过程是一样的。
当然我们这里比较重点强调的是在软件工程的方法层，同时也涉及到一些过程层的思想，至于工具层则不再我们的讨论之列，但是会提到一些很适合在需求分析时应用的工具，诸如Word、Excel、Visio等。
方法需求分析都包括了哪些方法呢？这里列举出在《需求分析》一书中推荐的一些方法，1. 绘制系统关联图，这种关联图是用于定义系统与系统外部实体间的界限和接口的简单模型。
同时它也明确了通过接口的信息流和物质流。
2. 创建用户接口原型，当开发人员或用户不能确定需求时，开发一个用户接口原型—一个可能的局部实现—这样使得许多概念和可能发生的事更为直观明了。
用户通过评价原型将使项目参与者能更好地相互理解所要解决的问题。
注意要找出需求文档与原型之间所有的冲突之处。
3. 分析需求可行性，在允许的成本、性能要求下，分析每项需求实施的可行性，明确与每项需求实现相联系的风险，包括与其它需求的冲突，对外界因素的依赖和技术障碍。
4. 确定需求的优先级别，应用分析方法来确定使用实例、产品特性或单项需求实现的优先级别。
产品需求分析图图表的制作产品是否畅销，除了受到推广、渠道等因素影响之外，其中一个很重要的原因就是它是否符合消费者的需求，所以在做产品的相关报告时，需求分析往往会是其中的重点所在。
我们可以使用图表直观地把调查分析的结果呈现出来，如图2-43所示。
呈现这类数据时，常用的图表类型有饼图和条形图，通常更多人会选择饼图，因为饼图能更直观地表现各种需求所占的比重。
但在以下情况下，建议优先使用条形图。
一是项目的数量较多的时候，这时饼图会被分割成很多扇区而变得难以阅读，而使用条形图就不会有这样的问题。
二是调查问卷的内容，一些调查问卷被设计成多项选择，这样的结果使各个项目的总和大于100%，这时使用饼图可能引起误解。
下面就以这个图表为例，演示其制作的详细过程。
首先选择数据，并插入默认的簇状条形图，然后开始下面的操作。
步骤一、输入标题、脚注等信息插入图表后，通过拖曳调整图表及绘图区的形状和尺寸，然后分别在图表顶端和底端绘制文本框，输入主副标题、脚注、数据来源等信息，如图2-44所示。
步骤二、删除横坐标轴这个图表使用数据标签来标示数值，因此横坐标轴没有存在的必要，将其删除。
步骤三、删除垂直网格线删除图表中的垂直网格线，在后面美化图表的步骤中，我们会为其添加水平网格线。
步骤四、设置纵坐标轴取消纵坐标轴的刻度线，并且设置其线条颜色为无线条，仅保留坐标轴标签，如图2-45所示。
步骤五、设置数据系列在【设置数据系列格式】对话框中设置分类间距为80%，填充颜色为绿色（RGB:0,173,79）。
步骤六、添加水平网格线因为图表使用数据标签来标示数值，因此网格线并没有实质的作用，只是起到美化图表的效果。
从美观的角度而言，在这个图表中水平网格线的效果要优于垂直网格线。
添加水平网格线后，设置其样式为虚线。
步骤七、添加数据标签通过右键菜单为图表添加数据标签，并设置数据标签的字体样式为微软雅黑、10号字、加粗，如图2-46所示。
愿陛下亲之、信之，则汉室之隆，可计日而待也。
信息系统需求分析流程图信息系统需求分析是信息系统开发过程中非常重要的一步，它的目标是明确用户需求，为开发团队提供明确的方向和目标。
本文将介绍信息系统需求分析的流程图，并详细解析每个步骤。
流程图一：用户需求获取用户需求获取是信息系统需求分析的第一步，它的目标是与用户进行有效的沟通，准确地了解用户的需求。
具体步骤如下：1. 确定需求获取的方式：可以通过面对面的访谈、问卷调查、观察等方式获取用户需求。
根据具体情况选择适合的方式。
2. 进行需求访谈：与用户面对面进行访谈，主要目的是获取用户的工作流程、业务需求等信息。
3. 设计问卷调查：设计合适的问卷，并向用户发放，收集用户对信息系统的期望和需求。
4. 观察用户操作：通过观察用户的工作过程和操作习惯，获取对信息系统的需求。
流程图二：需求分析与整理需求分析与整理是在获取用户需求后，对所有的需求进行梳理和整理，确保所有的需求都被记录下来并准确地理解。
具体步骤如下：1. 收集需求：将上一步中获取到的用户需求记录下来，包括文字描述、功能需求、性能需求等。
2. 需求分类：对收集到的需求进行分类，分为基本需求、附加需求、优先需求等。
3. 需求整理：整理需求，去除冗余和重复的需求，确保需求的准确性和完整性。
4. 验证需求：和用户进行反馈，确认整理后的需求是否准确地反映了用户的期望和需求。
流程图三：需求分析与建模需求分析与建模是在需求整理后，将需求进一步具体化、明确化，为系统设计提供依据。
具体步骤如下：1. 需求细化：将整理后的需求进行细化，明确每个需求的具体内容和表达方式，以便于后续的系统设计。
2. 数据建模：根据需求，进行数据建模，包括实体-关系模型、数据流图等，明确系统中的数据流动和关系。
3. 功能建模：根据需求，进行功能建模，明确系统的各个功能模块和功能之间的关系。
4. 接口建模：根据需求，进行接口建模，明确系统与外部系统之间的接口需求和交互方式。
流程图四：需求确认与评审需求确认与评审是在需求建模后，与用户进行沟通和确认，确保需求的准确性和完整性。
怎样做需求分析之十三：分析之行动图和状态图作者: fangang发布时间: 2012-04-11 10:23前面，我们耗费了大量的篇幅来讨论用例分析及用例图。
用例图，无疑是功能分析、角色分析，以及流程分析的利器，它将我们要开发的系统，清晰而详尽地描述出来。
但是，正如任何事物都有两面性，用例图也不例外，也有自己不利的一面。
在我看来，这集中体现在两个方面：只见树木不见森林、不生动形象。
什么叫“只见树木不见森林”呢？就是说，用例说明中对业务流程的描述，过早地将系统的整体流程，分散到了各个用例中了，丢失了对业务流程的整体描述。
不生动形象，则是说用例说明中对流程的描述都是用枯燥无味的文字来表述的，缺乏生动形象的图形表示。
针对这些不足，UML的另外两种视图，可以有效地弥补用例图的缺陷。
它们就是行动图与状态图。
行动图（Active Diagram），比较类似于我们过去绘制的流程图，是UML中描述流程与分支的视图。
在行动图中，往往是从一个实心圆的起始节点开始的。
最频繁使用的则是活动节点了，它表示的是业务流程中的一项活动。
活动节点可以表述为一个活动短语（如下订单），可以表述为一个表达式（如len=a.length+x），还可以表述为一个消息（如send(msg)）。
同时，将各个活动节点连接起来的一个个实线箭头，表明了各种活动之间的流转顺序。
在各种业务流程中，毫无疑问会有许多的分支。
在行动图中，分支用一个菱形来表示。
一个指向菱形的箭头，表示流程进入分支，另外两个或多个从菱形伸出的箭头，则表示不同条件下的分支流。
而菱形本身，则表示为一个条件判断语句。
另外，业务中的各个流程还会分岔与汇合的情况。
分岔，表示在某个时间点上，同时开始两个业务流程，这两个业务流程是同步进行的。
分岔用一个入箭头，一根横杠，与两个出箭头表示。
汇合，则表示，只有在两个流程都完成的情况下，才会进入下一流程，否则只能等待。
汇合则用两个入箭头，一根横杠，与一个出箭头表示。
怎样做需求分析之十：分析之用例说明作者: fangang发布时间: 2012-04-10 22:30当我们进行业务流程分析时，只空对空而不落到纸面上是不可以的。
过去，在面向过程的时代，我们绘制DFD图、流程图，以及编写流程说明来描绘这一部分分析；而现在，在面向对象的时代，我们则是绘制行动图、状态图，以及编写用例说明来完成这部分工作。
在这部分工作中，编写用例说明应当是最主要的工作，之后在一些关键部分辅之以行动图、状态图。
现在我们来看看用例说明应当怎样编写。
毫不疑问，做用例分析首先是要绘制出用例图（前面已经说过了）。
图形的最大优势是能够形象生动地描述我们的分析，但它最大的缺点是会遗失许多的细节信息，因此我们必须要对它进行进一步的文字描述。
由于不同的人对用例的理解不同，格式也不尽相同，但一些基本的元素是一样的。
以上表格是我采用的用例说明格式，其中用例名称、用例描述、参与者、前置条件、事件流、后置条件是公认的、用例说明的基本元素。
用例标识：就是用例的编号，一般采用“项目编号-子系统编号-模块编号-序号”来编号。
用例名称：没啥可说的，就是用例图中该用例的名称。
注意用例的命名规则：用例名称通常是一个动词短语或短句，而不是一个名词短语。
它可以是一个动词（如：自动考核），一个动宾短语（如：提取存款），一个被动句（如：发票填报），或者一个主谓句（如：用户提款，这个不推荐，因为主语就是参与者，显得有些多余）。
用例类型：在我看来，不同类型的用例，其用例说明的格式是不一样的。
以上给出的是“业务操作”类用例的格式，它更加着重地在描述业务操作的流程。
而“查询报表”类用例则没有什么流程，它更加着重地在描述报表格式及显示内容（后面再给出）。
还有用例类型还包括“子用例”、“扩展用例”。
用例描述：对该用例的功能定义、要实现的业务需求，以及谁（参与者）应该如何使用进行描述。
同时，这部分还可以整体概述实现业务需求的主要流程，以及与其它用例、其它外部系统的关系。
如何使用UML状态图进行系统建模与分析UML（Unified Modeling Language）状态图是一种用于系统建模与分析的工具。
它能够帮助软件工程师和系统分析师更好地理解和描述系统的行为和状态转换。
本文将介绍如何使用UML状态图进行系统建模与分析，以及它的重要性和应用场景。
一、UML状态图的基本概念UML状态图是一种描述对象在其生命周期中各种状态和状态转换的图形化表示方法。
它由状态、转换、事件和动作等元素组成。
1. 状态（State）：表示对象在某一时刻的特定情况或属性。
状态可以是离散的，如“打开”、“关闭”等，也可以是连续的，如“运行中”、“停止”等。
2. 转换（Transition）：表示对象从一个状态转变到另一个状态的过程。
转换可以由事件触发，也可以由条件控制。
3. 事件（Event）：触发状态转换的外部或内部事件。
事件可以是用户的操作、系统的响应或者时间的变化等。
4. 动作（Action）：在状态转换过程中执行的操作。
动作可以是改变对象属性、调用方法或发送消息等。
二、使用UML状态图进行系统建模与分析的步骤使用UML状态图进行系统建模与分析可以帮助我们更好地理解系统的行为和状态转换，从而更好地设计和实现系统。
下面是一些使用UML状态图进行系统建模与分析的步骤：1. 确定系统的关键对象和其状态：首先要确定系统中的关键对象，然后确定每个对象可能的状态。
例如，一个电梯系统中的关键对象可以是电梯，它的状态可以是“开门”、“关门”、“上行”、“下行”等。
2. 绘制状态图：在状态图中，使用矩形表示状态，使用箭头表示状态之间的转换。
在状态之间的转换上标注事件和条件。
在状态图中可以添加动作，表示状态转换过程中执行的操作。
3. 分析状态转换：分析每个状态之间的转换条件和事件，确定状态转换的触发条件和动作。
例如，在电梯系统中，当电梯处于“开门”状态时，如果检测到有人进入电梯，则触发状态转换到“关门”状态。
怎样做需求分析之十三：分析之行动图和状态图
作者: fangang发布时间: 2012-04-11 10:23
前面，我们耗费了大量的篇幅来讨论用例分析及用例图。
用例图，无疑是功能分析、角色分析，以及流程分析的利器，它将我们要开发的系统，清晰而详尽地描述出来。
但是，正如任何事物都有两面性，用例图也不例外，也有自己不利的一面。
在我看来，这集中体现在两个方面：只见树木不见森林、不生动形象。
什么叫“只见树木不见森林”呢？就是说，用例说明中对业务流程的描述，过早地将系统的整体流程，分散到了各个用例中了，丢失了对业务流程的整体描述。
不生动形象，则是说用例说明中对流程的描述都是用枯燥无味的文字来表述的，缺乏生动形象的图形表示。
针对这些不足，UML的另外两种视图，可以有效地弥补用例图的缺陷。
它们就是行动图与状态图。
行动图（Active Diagram），比较类似于我们过去绘制的流程图，是UML中描述流程与分支的视图。
在行动图中，往往是从一个实心圆的起始节点开始的。
最频繁使用的则是活动节点了，它表示的是业务流程中的一项活动。
活动节点可以表述为一个活动短语（如下订单），可以表述为一个表达式（如len=a.length+x），还可以表述为一个消息（如send(msg)）。
同时，将各个活动节点连接起来的一个个实线箭头，表明了各种活动之间的流转顺序。
在各种业务流程中，毫无疑问会有许多的分支。
在行动图中，分支用一个菱形来表示。
一个指向菱形的箭头，表示流程进入分支，另外两个或多个从菱形伸出的箭头，则表示不同条件下的分支流。
而菱形本身，则表示为一个条件判断语句。
另外，业务中的各个流程还会分岔与汇合的情况。
分岔，表示在某个时间点上，同时开始两个业务流程，这两个业务流程是同步进行的。
分岔用一个入箭头，一根横杠，与两个出箭头表示。
汇合，则表示，只有在两个流程都完成的情况下，才会进入下一流程，否则只能等待。
汇合则用两个入箭头，一根横杠，与一个出箭头表示。
最后，用一个或多个带环的实心圆，表示的是活动图的终止节点，代表了业务流程的终结。
以上这些元素，就组成了一个基本的活动图。
然而，基本的活动图还不能完整的反映我们的业务流程，因此我们还需要在基本活动图的基础上增加元素。
现在我们来看看泳道与业务对象流。
如图就是一个带泳道的活动图，图中每个泳道代表一个参与者的业务操作，而整个图形表述了多个参与者间的协作过程。
起初我比较爱绘制这样的活动图，但后来常常感到绘制泳道是
一件比较繁琐的事情。
既然如此，我们就改改吧。
这张图才是我最爱使用的行动图。
图中，将参与者由繁琐的泳道改为了用例图中的小人。
同时，在这张图中还增加了对象流与对象。
图中，自动考核结果、申辩申请单、调整后考核结果，都是数据对象，是该流程中相关环节操作的结果。
从活动节点指向对象的虚线箭头，则表示了一个对象流，如“申辩申请”活动指向“申辩申请单”的虚线箭头，表示了申辩申请活动的最终结果是产生申辩申请单；从“调整后考核结果”指向“过错追究”的虚线箭头，表示过错追究活动读取了调整后考核结果。
当然，活动图还有其它的元素，但我个人认为其实并不实用，使用以上元素就足以表述我们的业务流程了。
活动图打破了子系统与子系统的壁垒、用例与用例的壁垒，使我们能够从整体上了解整个系统的流程，因此常常使用在对整个系统的概述、对整个子系统的概述，以及对整个功能模块的概述中。
同时，与其它视图一样，活动图也应当有它的文字说明，以便对图中的每个活动节点、分支进行描述。
但对于一些流程相对简单，甚至没有什么流程的查询报表类功能模块，绘制它们的活动图则显得有些牵强附会，因此我们要灵活掌握。
除了活动图，我们似乎对需求的描述还缺少点儿什么，那就是对关键对象中流程中状态变化的描述，在这种情况下，我们的状态图就上场了。
在使用状态图时，一个非常关键的概念就是，一定是对某个关键对象的状态变化的描述，而这些状态变化一定是在某个业务流程的大背景下进行的。
下图是一个疑点数据整个生命周期的状态变化图。
图中，与行动图一样，一个实心圆点代表的是流程的开始，圆边的方框代表的是对象生命周期中的各个状态，状态节点间的实线箭头代表的是状态的切换，箭头的文字描述是触发状态切换的事件。
与行动图一样，状态图可以有分支、分岔、汇合，并最后以一个或多个带环的实心圆结束，代表对象生命周期的终结。
在需求分析中，状态图并不是必须的，它仅仅出现在你认为需要对某个对象的状态进行说明的时候。
