下载掌阅APP，畅读海量书库
立即打开
从2004年到2013年的系统分析师考试中，共有4道论文试题和系统分析有关。在解答这类试题的过程中，考生除了需要有丰富的实践经验外，还需要十分熟悉有关理论、方法和步骤。特别是近两年来，试题的命题范围越来越窄，所考查的知识点越来越细，试题难度也随之增大。
这是2004年上半年的考试试题，主要考查项目中获取用例的基本步骤和方法。
UP（Unified Process，统一开发过程）是一种软件开发过程，它的特点是：用例驱动；以体系结构为中心；迭代和增量开发。用例（use case）是对一组动作序列的描述，系统通过执行该动作序列，为参与者（actors）产生可观察的结果。用例不仅可以描述系统的需求，而且能驱动系统的设计、实现和测试。
请围绕“用例的获取方法”论题，依次从以下三个方面进行论述。
1．概要叙述你参与分析和开发的软件项目，以及你所担任的主要工作。
2．详细论述你在这个项目中获取系统的用例的基本步骤。
3．分析并讨论获取用例的效果（是否获取了系统的所有用例或全部重要的用例），并进行评价。
参与者也称为执行者，是直接与系统相互作用的系统、子系统或类的外部实体的抽象概念。每个参与者定义了一个角色集合，当系统的用户与系统相互作用时会采用它们。一个物理对象如果满足多个参与者的角色，那么它就可以扮演多个参与者。
用例是参与者与系统之间一系列可能的交互行为序列的集合，以实现用户的使用系统所要达到的特定目标。用例描述参与者使用系统所要实现的行为，但是它不涉及具体的实现细节，强调的是能做什么，而不是怎么去做。
用例分析技术是Ivar Jacobson于1967年在爱立信公司开发AXE交换机时开始研究，并于1986年总结、发布的一项源于实践的需求分析技术。用例分析技术为软件需求规格化提供了一个基本的元素，而且该元素是可验证和可度量的。用例可以作为项目计划、进度控制、测试等环节的基础。用例是开发团队与客户之间有效的沟通工具，它可以用来描述功能和非功能需求，有助于确保需求的可跟踪性，能够抑制过早的设计。
用例驱动技术抓住参与者、参与者的目标、用例三个要素，借助于场景分析、顺序图和协作图（通信图）等技术克服了以上的困难，最大限度地消除了期望差异，最终的用例模型就是客户与开发人员之间达成一致的系统开发合同。
在用户需求获取阶段，为了获取用户需求，首先要明确系统的用户。这里的用户是指要与待开发的系统相互作用的外部实体，而不是专指组织的人员。首先，通过提以下问题来获得初始的用户列表。
（1）谁直接使用系统？
（2）谁负责系统的维护工作？
（3）系统使用的外部硬件。
（4）要与本系统交换信息的其他系统。
得到用户列表后，需要根据各用户使用系统的不同动机和目的对他们进行分类，每一分类代表一种逻辑角色，而属于同一种角色的用户的集合就是用例的参与者。一般的做法是，对几个人的用户组（一般2～3人）查看已识别的参与者是否已经包括了他们的需要，如已经包括了他们的需要，则他们所属的参与者类型就确定了。在识别参与者的过程中，提以下的问题是很有用的。
（1）谁将提供、使用、删除信息？
（2）谁将使用这个功能？
（3）谁对某一特定需求感兴趣？
（4）谁负责系统某一方面的维护工作？
（5）系统的外部资源是什么？
（6）哪些外部系统需要与系统的这一部分交互？
确定了参与者也就基本上确定了系统的边界，这有助于理解系统的目标和范围。只有直接与系统交互的用户才可以被看做是参与者，如果赋予参与者多余的角色，则必然会超出系统的当前范围。此外，参与者的确定不是一次性的工作，而是与用例的识别协同进行的，通过多次的迭代最终确定。
因为系统是为它的用户而开发的，所以应该以用户的需求为基础。在得到了初步的参与者后，系统的用户转化成了扮演各种逻辑角色的系统外部的参与者，用户需求也转变成了参与者所要执行的用例。所以，用户需求的获取就变成了参与者用例的获取。
获取用例的最好办法是考虑每个参与者需要系统为他做些什么，即参与者的目标。对于每个参与者，考虑以下问题来识别用例。
（1）参与者需要系统执行的主要任务是什么？
（2）参与者需要在系统中创建、存储、修改、删除和读取数据吗？
（3）参与者需要告知系统突然发生的外部变动吗？
（4）系统的所有特性是否可被已经识别的用例实现？
（5）参与者是否要执行系统的启动和关闭？
这些问题的答案代表了候选用例的事件流。并不是所有的事件流都能构成独立的用例，有的事件流是同一用例事件流的变体。一般来说，用户总是趋向于首先确定业务领域中的最重要用例，因此，最先经过用户确定的用例往往具有最高的优先级。不要期望一次得到所有的用例，而是应先根据系统的主要参与者的需求，识别他们的重要用例，再与用户代表和领域专家进行验证和评审。确定了这些重要用例后，也就确立了系统的核心功能，初步的用例获取工作即告完成。接下来的用例获取工作应围绕系统的次要参与者的需求来进行。经过多次的迭代，当下面的一些情景出现时，用例的获取工作可以认为已初步完成。
（1）用户不能想出更多的用例。
（2）用户提出的新的用例可以通过与已获取的用例相关的功能需求来实现。
（3）用户新提出的需求涉及具体的实现细节，可由有限的简单操作完成，其相应的用例粒度太小。
（4）用户提出的需求涉及系统将来的特性，超出了当前的系统范围。
在这个层次的用例反映的是用户需求，即用户（体现为执行者）通过系统要完成的目标。因此，这些用例是抽象的、大粒度的，不涉及系统的实现细节，每个用例应有一段简洁的叙述性的文字来描述用例的目标和基本的交互序列。
当用例获取基本完成后，应对所有用例进行验证，详细检查所有用例以确保满足所有的用户需求。然后，从所有的用例中识别出表达抽象行为的抽象用例，在基用例与这些抽象用例之间运用用例的包含、扩展和泛化关系建立联系。同时，在具有公共特性的参与者之间建立参与者的泛化关系。最终得到的是一个结构化的用例模型。这个模型是个高层的反映用户需求的抽象的模型，它从系统外部用户的角度描绘了系统的功能、范围，但不涉及系统的具体实现细节，它使功能需求获取工作流的输入，系统的功能需求都是从这个模型导出的。
用户需求阶段获取的用例描述了系统外部的参与者要实现的目标，反映的是用户需求，但并没有涉及系统应提供的相关的具体功能细节。用户需求决定了系统的功能需求，为了获取这些功能需求，必须要对用户需求阶段获取的大粒度的抽象用例进行求精，通过细化用例的事件流，得到用例的所有场景的集合，而这些场景中的各个步骤就是功能需求的来源。具体步骤如下。
（1）从用户需求阶段获取的所有用例中选择一个具有最高优先级的用例。
（2）场景分析。根据参与者的目标确定顺利完成目标的基本的、最简单的交互序列，即先确定用例的主要场景。然后，根据主要场景中每个基本步骤考虑其异常情况和其他可选项确定次要场景。当得到用例的所有场景后，转入第（3）步。
（3）用例分解。用例是场景的集合，场景中的每一步都可看成是一个小的子用例，这是个递归关系。这些子用例是场景所属外部用例的下级用例，其参与者称为系统的内部参与者，包括系统、子系统和对象三类实体。这些内部参与者是下级用例中与外部用例参与者交互的实体对象。
（4）用例判定。根据场景中下级用例的粒度做出判定，对于像更新数据库这类的简单操作，因其粒度太小，将它继续看成用例只能造成用例数量的膨胀，毫无益处，故应该把它当做系统实现的简单行为，这个简单行为就是系统要实现的一个功能需求；对于较大粒度的下级用例，因其本身代表了一个复杂的子交互序列，因此其参与者有明确的目标，应将其当做新的待求精用例，重复（2）～（4）步获取其功能需求。
（5）对剩余的用例，重复第（2）～（4）步。
当再没有用例可以求精时，最终得到的所有用例中的简单行为的集合就是系统的功能需求。
非功能需求反映系统的质量属性的特性和业务规则、法规制度等各种约束。具体有以下一些方面：易操作性、可靠性、可维护性、业务规则、各种法规和制度等。非功能需求不能由用例分析得到。相反，其中一些非功能需求会对用例的实现具有制约作用。因此，必须在这些用例和非功能需求之间建立联系，或者把非功能需求写入用例文档，或者在两者间建立需求跟踪机制。其他的非功能需求须独立地获取。
上面介绍了如何通过用例来获取系统的需求。不过值得注意的是，关于用例有两个常见的误区。
（1）用例分析技术包括了整个需求过程。事实上，用例分析只是一个需求分析技术，是在传统的需求获取技术的基础上使用的，并无法替代这些技术。
（2）用例分析技术是分解技术。其实用例分析技术是一种合成技术，将在需求获取中收集而来的零散的特性合成为用例。
因此，要清楚地认识到用例源于项目干系人，不能自己杜撰出用例，但也不要企图直接问他们还有什么用例；另外用例描述的编写工作，应由开发人员和客户组成的团队完成。
总而言之，用例来源于传统的需求捕获方法所产生的结果。通常采用迭代的方式来创建需求：首先生成提纲和高层描述（也就是粗略的用例模型），然后对其进行拓展和深化（也就是对用例模型的描述进行完善），最后进行集中的整理与修剪。而用例模型的建立过程主要可以分为识别参与者、合并需求获得用例、细化用例描述、调整用例等四个步骤，其中前三个步骤是必需的。
这是2006年上半年的考试试题，主要考查需求获取的技术。
需求分析阶段的首要工作是确定用户需求，以用户为核心是本阶段应遵循的至关重要的原则，它决定着项目的有效实施。正确地定义用户需求是需求分析阶段的基础。需求获取技术有助于系统分析员准确、快捷地获取和提炼用户需求信息。
请围绕“需求获取技术”论题，依次对以下三个方面进行论述。
1．概要叙述你参与分析和开发的应用项目及你所担任的主要工作。
2．详细说明目前有哪些比较常用的需求获取技术？说明每种需求获取技术的基本方法。
3．详细论述在你参与分析和开发的应用项目中所采取的需求获取技术，以及对该技术的具体实施运用，说明选取该技术的原因，并分析应用该技术所获取的需求是否达到预期目标。
在需求获取的过程中，主要解决需求调查的问题。要想做好需求调查，必须清楚地了解以下三个问题。
（1）What：应该搜集什么信息。
（2）Where：从什么地方搜集这些信息。
（3）How：用什么机制或者技术来搜集这些信息。
一方面，系统分析师应该知道，从宏观的角度来看，要获取的信息包括三大类：一是与问题域相关的信息（如业务资料、组织结构图、业务处理流程等）；二是与要求解决的问题相关的信息；三是用户对系统的特别期望与施加的任何约束信息。
另外一方面，系统分析师在开展具体需求获取工作时，应该做到在此之前明确自己需要获得什么信息，这样才有可能获得，才知道工作进展是否顺利完成目标。
除了要明确地知道我们需要什么方面的信息，还要知道可以从哪里获得它们。而通常情况下，这些你需要的信息会藏在客户、原有系统、原有系统用户、新系统的潜在用户、原有产品、竞争对手的产品、领域专家、技术法规与标准里。
面对这么多种可能，在具体的实践中该从何下手呢？其实很简单，从人的角度来说，应该首先对项目干系人进行分类，然后从每一类干系人中找到1～2名代表；而对于文档、产品而言，则更容易有选择地查阅。
在制订需求获取计划的时候，可以列出一个表格，第1列是我们想了解的信息，第2列是信息可能的来源，这样就能够建立起一一对应的关系，使得需求获取工作更加有的放矢，也更加高效。
当知道需要去寻找什么信息，并且也找到了信息的来源地后，接下来就需要选择合适的技术进行需求获取了。作为一名系统分析师，掌握各种不同的需求获取技术，并且熟练地在实践中运用它，是十分必要的。常用的需求获取技术主要有用户访谈、用户调查（问卷调查）、现场观摩、阅读历史文档等。这里只介绍用户访谈、现场观摩和阅读历史文档，有关问卷调查与联合讨论会的介绍，请参考2.1.6节。
（1）用户访谈
用户访谈是最基本的一种需求获取手段，其形式包括结构化和非结构化两种，结构化是指事先准备好一系列问题，有针对地进行；而非结构化则是只列出一个粗略的想法，根据访谈的具体情况发挥。最有效的访谈是结合这两种方法进行，因为毕竟不可能把什么都一一计划清楚，应该保持良好的灵活性。
·准备问题：进行用户访谈之前，最好先对要询问的问题进行一些准备。准备的方法是围绕着想要获取的信息展开，设计一系列的问题，按顺序组织起来。而且还要预先准备好记录方式，主要包括本人记录、第三人记录或者是录音/录像的形式，不过采用录音/录像的方式应该征得被访谈者的同意，而且这种方法虽然看上去比较有效，不容易丢失信息，但会给后面的整理工作带来一定的工作量和难度。
·访谈时的技巧：在访谈时一定要注意措辞得当，在充分尊重被访谈者的基础上，要避免出现“我不知你在说什么”，“我是来帮助你更好地工作”这样的言语，否则将会破坏访谈的气氛，从而使访谈的效率大打折扣。在访谈时一定要注意保持轻松的气氛，选择客户有充裕时间的时段进行，在说话、问问题时应该尽量采用易于理解、通俗化的语言。另外，值得注意的是，分析人员应该在进行访谈之前进行一些领域相关的知识培训，充分阅读相关材料，以保证自己有较专业的理解与认识，让被访谈者能够信任你。
·应该询问的问题：在设计询问的问题时，应该问自己，我的问题看起来相关吗？回答是否正式？对方是回答这些问题的合适人选吗？是否问了过多的问题？是否还有更多的问题要问被访者？另外，还可以在过程中询问被访者还希望自己问他什么问题，还应该见谁？
总的来说，用户访谈具有良好的灵活性，有较宽广的应用范围，但是也存在着许多困难，诸如客户经常较忙，你难以安排时间；面谈时信息量大，记录较为困难；沟通需要很多技巧，同时需要分析员有足够的领域知识；另外，在访谈时会遇到一些对于组织来说比较机密和敏感的话题。因此，这看似简单的技术，也需要分析人员拥有足够多的经验和较强的沟通能力。
（2）现场观摩
俗话说得好，百闻不如一见。对于许多较为复杂的流程和操作而言，是很难用言语表达清楚的，而且这样做也会显得很低效。因此，针对这一现象，分析团队可以就一些较复杂、较难理解的流程、操作，采用现场观摩的方法来获取需求。
具体来说，就是走到客户的工作现场，一边观察，一边听客户的讲解，甚至可以安排人员跟随客户工作一小段时间。这样就可以使得分析人员更加直观地理解需求。
（3）阅读历史文档
对于一些数据流比较复杂的，工作表单较多的项目，有时是难以通过言谈或观察来了解需求细节的。这个时候就可以借助于阅读历史文档的方法，对历史存在的一些文档进行研究，从中获得所需的信息。
这个方法的主要风险是历史的文档可能与新系统的流程、数据有一些不吻合的地方，并且还可能承载原有系统的一些缺陷。要想有效地避免和发现这些问题，就需要分析人员能够运用自己的聪明才智，将其与其他需求获取技术结合、对照。还有一个负面因素就是，这些历史的文档中记载的信息有可能涉及客户的商业秘密，因此对数据信息的保密也要求分析人员具备基本的职业道德。
在整个需求开发过程中，需求获取、需求分析、需求定义、需求验证四个阶段不是瀑布式的发展，而应该采用迭代式的演化过程。也就是说，在进行需求获取时，不要期望着一次就将需求收集完，而应该在获取到一些信息后，进行相应的需求分析，并针对分析中发现的疑问和不足，带着问题再进行有针对性的需求获取工作。
这是2006年下半年的考试试题，主要考查统一过程的需求分析。
在软件工程中，所有的项目干系人都关心需求分析。这些项目干系人包括客户、用户、业务或需求分析员、开发人员、测试人员、用户文档编写者、项目管理者和客户管理者。完成好需求分析阶段的工作，将为后续开发出出色的产品打下基础，同时会使客户感到满意；否则，会导致误解、挫折、障碍，以及潜在质量和业务价值上的威胁。因此采用有效的需求分析过程至关重要。统一过程是业界流行的需求分析方法。
请围绕“有效的需求分析过程”论题，依次对以下三个方面进行论述。
1．概要叙述你参与分析和开发的项目及你在其中所担任的主要工作。
2．详细论述你在这个项目中采用统一过程进行有效需求分析的具体方法和步骤。
3．论述你参与的需求分析过程所取得的实际效果和存在的问题。
有关统一过程的阶段划分，请参考1.2.1节。就需求分析而言，主要集中在初始阶段和细化阶段。
在初始阶段中，关注的是整个项目进行过程中的业务和需求方面的主要风险。初始阶段的主要目标如下。
·明确软件系统的范围和边界条件，包括从功能角度的前景分析、产品验收标准和哪些做与哪些不做的相关决定。
·明确区分系统的关键用例和主要的功能场景。
·展现或者演示至少一种符合主要场景要求的候选软件体系结构。
·对整个项目做最初的项目成本和进度估计（更详细的估计将在随后的细化阶段中做出）。
·估计出潜在的风险。
·准备好项目的支持环境。
初始阶段的工作成果（工件）主要有如下。
·项目核心需求、关键特色、主要约束的总体蓝图。
·原始用例模型（完成10%～20%）。
·原始项目术语表（可能部分表达为业务模型）。
·原始业务案例，包括业务的上下文、验收规范、成本预计。
·原始的风险评估。
·一个或多个原型。
初始阶段的评审标准如下。
·项目干系人就范围定义、成本及进度估计达成共识。
·以客观的主要用例证实对需求的理解。
·成本/进度、优先级、风险和开发过程的可信度。
·被开发体系结构原型的深度和广度。
·实际开支与计划开支的比较。
·如果无法通过这些里程碑，则项目可能被取消或重新考虑。
细化阶段是四个阶段中最关键的阶段，在细化阶段，可执行的体系结构原型在一个或多个迭代过程中建立，依赖于项目的范围、规模、风险和先进程度。至少要处理初始阶段中识别的关键用例，因为关键用例揭示了项目主要技术的风险。通常，我们的目标是一个由产品质量级别构件组成的可演化的原型，但这并不排除开发一个或多个探索性、可抛弃的原型来减少风险。例如，设计/需求折中，构件可行性研究，或者给投资者、顾客及最终用户演示版本等特定的风险。
细化阶段的主要目标如下。
·确保软件体系结构、需求、计划足够稳定；确保项目风险已经降低到能够预计完成整个项目的成本和进度的程度。
·针对项目的软件体系结构上的主要风险已经解决或处理完成。
·通过完成软件体系结构上的主要场景建立软件体系结构的基线。
·建立一个包含高质量构件的可演化的产品原型。
·说明基线化的软件体系结构可以保障系统需求能够控制在合理的成本和时间范围内。
·建立好产品的支持环境。
细化阶段的主要工作成果如下。
·用例模型（完成至少80%）。所有用例均被识别，大多数用例描述得以开发。
·补充和捕获非功能性要求和非关联于特定用例要求的需求。
·软件体系结构描述、可执行的软件原型。
·经修订过的风险清单和业务用例。
·项目总体开发计划。
·指明被使用过程更新过的开发用例。
·用户手册的初始版本（可选）。
细化阶段结束时，需要检验详细的系统目标和范围、体系结构的选择，以及主要风险的解决方案。主要的审核标准包括回答以下的问题。
·产品的蓝图是否稳定？
·体系结构是否稳定？
·可执行的演示版是否显示风险要素已被处理和可靠地解决？
·构建阶段的计划是否足够详细和精确？是否被可靠的审核基础支持？
·如果当前计划在现有的体系结构环境中被执行而开发出完整系统，是否所有的项目干系人同意该蓝图是可实现的？
·实际的费用开支与计划开支是否可以接受？
这是2011年上半年的考试试题，主要考查联合需求计划的基本概念、参与者及其作用、应该把握的原则，以及联合需求计划方法的优点与缺点。
需求获取是系统分析师用来确定、分析和理解系统需求的过程，访谈是需求获取的主要方式。为了提高需求获取的效率，越来越多的企业倾向于使用小组工作会议来代替大量独立的访谈。联合需求计划（Joint Requirement Planning，JRP）是一个通过高度结构化组织的群体会议来分析企业内的问题并获取需求的过程。JRP会议包括一些不同的参与者和角色，期望每个参与者都能够参加并主动地参与整个JRP会议。
请围绕“联合需求计划在系统需求获取中的应用”论题，依次从以下三个方面进行论述。
1．概要叙述你使用JRP方法，参与分析和开发的信息系统项目以及你所担任的主要工作。
2．简要分析JRP的参与者，并说明每个参与者在会议讨论中所发挥的作用。
3．分析实施JRP时应该把握的原则，有效组织的JRP会议和其他需求获取方法相比有哪些优点。
有关JRP的基本概念和方法，请参考2.1.6节。
JRP的参与者及每个参与者在会议讨论中所发挥的作用如下。
（1）负责人：通常是位于管理层的人，并且他的职权跨越系统项目中涉及的不同部门和用户，负责人通过鼓励用户主动参与JRP会议对系统项目给予完全的支持，并负责做出需求是否入选的最后决策。负责人通过介绍与会者来启动会议，并在会议结束时做最后小结。
（2）会议主持人：通常负责领导一个系统项目的所有会议，这个人具有出色的沟通能力，拥有协商和解决小组矛盾的能力，拥有业务知识，具有出色的组织能力，对将做出的决策保持公平，并且不用向任何与会者汇报工作。主要工作包括策划JRP会议，主持会议直至会议结束。会议期间，负责引导讨论，鼓励出席者主动参与，解决可能产生的矛盾，确保实现会议的预期目标和目的，并建立会议期间将遵守的基本规则。
（3）用户和管理人员：通常由项目负责人选择，人数为十几人或者更多。用户主要用来有效地明确或确认业务规则和需求、评审设计原型并做出是否接受的策略。管理人员是用来批准项目目标、设置项目优先权，批准进度和费用以及批准确定的培训需求和实现计划。
（4）记录员：负责记录会议上讨论的每件事情，这些记录在会后立即发给与会者，以便维持JRP会议及其成员的动力。使用CASE工具来收集JRP会议期间沟通的众多事实。这个角色通常由系统分析人员扮演。
（5）IT职员：主要负责聆听和记录用户和管理人员说的有关问题和需求。除非被邀请，否则不会主动发言。他们的任何问题和关注都在JRP会议之后或之前不久直接提交给JRP主持人。IT职员通常由项目团队的成员组成，这些成员和记录员密切合作，以形成开发模型和会议期间沟通结果的其他相关文档。
实施JRP时应该把握的原则，请参考2.1.6节。
有效组织的JRP会议具有的优点如下。
·JRP积极地将用户和管理人员引入到开发项目中。
·JRP通过小组会议代替传统的、耗时的一对一地与每个用户和管理人员面谈，减少了开发系统所需的时间。
·小组会议有助于获得用户和管理人员的一致意见，解决互相矛盾的信息和需求。
·JRP把原型化技术包括进来作为一种证实需求和获得设计建议批准的手段，能够有效发挥原型化技术的优点。
JRP会议的成功取决于JRP主持人及其计划与主持JRP会议的能力。
这是2012年上半年的考试试题，主要考查需求管理的活动及其主要内容。
软件需求工程关注创建和维护软件需求文档需展开的一切活动。需求工程可分为需求开发和需求管理两项工作，其中需求管理的目标是为软件需求建立一个基线，供软件开发及其管理使用，确保软件计划、产品和活动与软件需求的一致性。从软件需求工程的角度来看，需求管理包括在软件开发过程中维持需求一致性和精确性的所有活动。
请围绕“软件需求管理及其应用”论题，依次从以下三个方面进行论述。
1．概要叙述你参与管理和开发的软件项目以及你在其中所担任的主要工作。
2．详细论述软件需求管理的主要活动及其所包含的主要内容。
3．结合你具体参与管理和开发的实际项目，说明是如何采用软件需求管理方法进行需求管理的，说明具体实施过程以及应用效果。
1．简要叙述所参与管理和开发的软件项目，并明确指出在其中承担的主要任务和开展的主要工作。
2．需求管理的主要活动有变更控制、版本控制、需求跟踪和需求状态跟踪。
（1）需求变更管理过程包括如下。
·问题分析和变更描述。需要识别和分析需求问题，形成明确的变更协议，以检查它的有效性，从而产生一个更明确的需求变更提议。
·变更分析和成本计算。使用可追溯性信息和系统需求的一般知识，对需求变更提议进行影响分析和评估。变更成本计算应该包括对需求文档的修改、系统修改的设计和实现的成本。一旦分析完成并且被确认，应该进行是否执行这一变更的决策。
·变更实现。这要求需求文档和系统设计，以及实现都要同时修改。
（2）版本控制：主要包括确定需求文档版本。
（3）需求跟踪：包括定义对其他需求的链接；定义对其他系统元素的链接；使用的工具即需求跟踪矩阵。
（4）需求状态跟踪：定义需求状态；跟踪需求的每一个状态。
2．考生需结合自身参与项目的实际状况，指出其参与管理和开发的项目中所进行的需求管理活动，说明该活动的具体实施过程、使用的方法和工具，并对实际应用效果进行分析。
这是2013年上半年的考试试题，主要考查面向对象建模方法。
随着软件技术的发展，面向对象方法日益成为信息系统软件开发的主流技术，而面向对象建模技术是其中的关键。模型是软件开发的根本，大型、复杂的软件系统的开发是一项工程，而建模是系统化认识所开发软件的一个初步途径。
面向对象建模技术流派众多，包括OMT方法、OOSE方法、OOA/OOD方法等。统一建模语言的出现极大地促进了面向对象建模方法的普及与应用，已经成为当前面向对象建模方法的标准。
请围绕“论面向对象建模方法的应用”论题，依次从以下三个方面进行论述。
1．概要叙述你参与管理和开发的信息系统项目以及你在其中所承担的主要工作。
2．论述常见的面向对象建模方法的主要内容，包括每种模型的核心思想。
3．具体阐述你参与管理和开发的项目中使用的是哪种面向对象建模方法以及选择该方法的原因，给出具体的实施过程和实施效果。
常见的面向对象建模方法的基本情况如下。
Coad/Yourdon方法特别强调OOA和OOD采用完全一致的概念和表示法，使分析和设计之间不需要表示法的转换。该方法的特点是表示简练、易学，对于对象、结构、服务的认定较系统、完整，可操作性强。
在Coad/Yourdon方法中，OOA的任务主要是建立问题域的分析模型。分析过程和构造OOA概念模型的顺序由五个层次组成，分别是类与对象层、属性层、操作层、结构层和主题层，它们分别表示分析的不同侧面。OOA需要经过五个步骤来完成整个分析工作，即标识对象类、标识结构与关联（包括继承、聚合、组合、实例化等）、划分主题、定义属性和定义操作。
OOD中将继续贯穿OOA中的五个层次和五个活动，它由四个部分组成，分别是人机交互组件、问题域组件、任务管理组件和数据管理组件，其主要的活动就是这四个组件的设计工作。
Booch最先描述了OO方法的基础问题，指出OO方法是一种根本不同于传统的功能分解的设计方法。OO的系统分解更接近人对客观事务的理解，而功能分解只通过问题空间的转换来获得。
Booch认为系统开发是一个螺旋上升的过程，每个周期包括四个步骤，分别是标识类和对象、确定类和对象的含义、标识关系、说明每个类的接口和实现。Booch方法的开发模型包括静态模型和动态模型两种。静态模型分为逻辑模型（类图、对象图）和物理模型（模块图、进程图），用来描述系统的构成和结构。动态模型包括状态图和顺序图，用来描述对象的状态变化和交互过程。有关这些图形的详细知识，将在11.5.1节中介绍。
OMT方法使用了建模的思想，讨论如何建立一个实际的应用模型，包括对象模型、动态模型和功能模型。对象模型描述系统中对象的静态结构、对象之间的关系、属性和操作，主要用对象图来实现；动态模型描述与时间和操作顺序有关的系统特征，例如，激发事件、事件序列、确定事件先后关系的状态等，主要用状态图来实现动态模型；功能模型描述一个计算如何从输入值得到输出值，它不考虑计算的次序，主要用DFD来实现功能模型。简单地说，功能模型指出发生了什么，动态模型确定什么时候发生，而对象模型确定发生的客体。
OMT方法通常包括四个活动，分别是系统分析、系统设计、对象设计和实现。其中，系统分析就是实现OOA的任务，系统设计确定整个系统的架构，对象设计建立基于分析模型的设计模型并考虑实现细节，实现是将所设计的对象类及其关系转换为程序设计语言、数据库或硬件的实现。
OOSE在OMT的基础上，对功能模型进行了补充，提出了用例（use case）的概念，最终取代了DFD来进行需求分析和建立功能模型。OOSE方法采用五类模型来建立目标系统，分别是需求模型、分析模型、设计模型、实现模型和测试模型。
OOSE的开发活动主要分为三类，分别是分析、构造和测试。其中分析过程分为需求分析和健壮性分析两个子过程，分析活动分别产生需求模型和分析模型；构造活动包括设计和实现两个子过程，分别产生设计模型和实现模型；测试过程包括单元测试、集成测试和系统测试三个过程，共同产生测试模型。
用例是OOSE中的重要概念，在开发各种模型时，它是贯穿OOSE活动的核心，描述了系统的需求及功能。用例实际上是描述系统参与者（既可以是用户，也可以是与系统交互的其他系统）对于系统的使用情况，是从参与者的角度来确定系统的功能。因此，首先必须分析、确定系统的参与者，然后进一步考虑参与者的主要任务和使用方式，再识别出所使用的事件，即用例。
UML是一种定义良好、易于表达、功能强大且普遍适用的建模语言，它融入了软件工程领域的新思想、新方法和新技术，它的作用域不限于支持OOA和OOD，还支持从需求分析开始的软件开发的全过程。
从总体上来看，UML的结构包括构造块、公共机制和规则三个部分。
（1）构造块。UML有三种基本的构造块，分别是事物（thing）、关系（relationship）和图（diagram）。事物是UML的重要组成部分，关系把事物紧密联系在一起，图是多个相互关联的事物的集合。
（2）公共机制。公共机制是指达到特定目标的公共UML方法，主要包括规格说明（详细说明）、修饰、公共分类（通用划分）和扩展机制四种。规格说明是事物语义的细节描述，它是模型真正的核心；UML为每个事物设置了一个简单的记号，还可以通过修饰来表达更多的信息；UML包括两组公共分类，分别是类与对象（类表示概念，而对象表示具体的实体）、接口与实现（接口用来定义契约，而实现就是具体的内容）；扩展机制包括约束（扩展了UML构造块的语义，允许增加新的规则或修改现有的规则）、构造型（扩展UML的词汇，用于定义新的构造块）和标记值（扩展了UML构造块的特性，允许创建新的特殊信息来扩展事物的规格说明）。
（3）规则。规则是构造块如何放在一起的规定，包括为构造块命名；给一个名字以特定含义的语境，即范围；怎样使用或看见名字，即可见性；事物如何正确、一致地相互联系，即完整性；运行或模拟动态模型的含义是什么，即执行。