需求获取与需求建模
一．需求获取
需求获取，属于软件工程中的一部分，包括需求来源和获取需求的技术。它是软件设计的第一阶段，其本质主要是人的活动，涉及软件设计人员如何与客户建立有效的沟通。也称为“需求发现”、“需求获得”。
需求获取(requirement elicitation)是需求工程的主体。对于所建议的软件产品，获取需求是一个确定和理解不同用户类的需要和限制的过程。获取用户需求位于软件需求三个层次的中间一层。业务需求决定用户需求，它描述了用户利用系统需要完成的任务。从这些任务中，分析者能获得用于描述系统活动的特定的软件功能需求，这些系统活动有助于用户执行他们的任务。需求获取和分析包括对原始需求变更控制，版本控制，从需求到产品和模块的可追溯性，成品交付和产品的状态跟踪。
需求获取是在问题及其最终解决方案之间架设桥梁的第一步。获取需求的一个必不可少的结果是对项目中描述的客户需求的普遍理解。一旦理解了需求，分析者、开发者和客户就能探索出描述这些需求的多种解决方案。参与需求获取者只有在他们理解了问题之后才能开始设计系统，否则，对需求定义的任何改进，设计上都必须大量的返工。把需求获取集中在用户任务上—而不是集中在用户接口上—有助于防止开发组由于草率处理设计问题而造成的失误。
需求获取、分析、编写需求规格说明和验证并不遵循线性的顺序，这些活动是相互隔开、增量和反复的。当你和客户合作时，你就将会问一些问题，并且取得他们所提供的信息（需求获取）。同时，你将处理这些信息以理解它们，并把它们分成不同的类别，还要把客户需求同可能的软件需求相联系（分析）。然后，你可以使客户信息结构化，并编写成文档和示意图（说明）。下一步，就可以让客户代表评审文档并纠正存在的错误（验证）。这四个过程贯穿着需求分析的整个阶段。需求获取可能是软件开发中最困难、最关键、最易出错及最需要交流的方面。需求获取只有通过有效的客户—开发者的合作才能成功。分析者必须建立一个对问题进行彻底探讨的环境，而这些问题与产品有关。为了方便清晰地进行交流，就要列出重要的小组，而不是假想所有的参与者都持有相同的看法。对需求问题的全面考察需要一种技术，利用这种技术不但考虑了问题的功能需求方面，还可讨论项目的非功能需求。确定用户已经理解：对于某些功能的讨论并不意味着即将在产品中实现它。对于想到的需求必须集中处理并设定优先级，以避免一个不能带来任何益处的无限大的项目。
需求获取是一个需要高度合作的活动，而并不是客户所说的需求的简单誊本。作为一个分析者，你必须透过客户所提出的表面需求理解他们的真正需求。询问一个可扩充（open-ended）的问题有助于你更好地理解用户目前的业务过程并且知道新系统如何帮助或改进他们的工作。调查用户任务可能遇到的变更，或者用户需要使用系统其它可能的方式。想像你自己在学习用户的工作，你需要完成什么任务？你有什么问题？从这一角度来指导需求的开发和利用。
还有，探讨例外的情况：什么会妨碍用户顺利完成任务？对系统错误情况的反映，用户是如何想的？询问问题时，以“还有什么能”,”当?时，将会发生什么”“你有没有曾经想过”,“有没有人曾经”为开头。记下每一个需求的来源，这样向下跟踪直到发现特定的客
户。
有些时候，尝试着问一些“愚蠢”的问题也有助于客户打开话匣子。如果你直接要求客户写出业务是如何实现的，客户十有八九无法完成。但是如果你尝试着问一些实际的问题，例如：“以我的理解，你们收到订单后，会...”。客户立刻就会指出你的错误，并滔滔不绝的开始谈论业务，而你，就在一边仔细的聆听吧。这一招就叫做“抛砖引玉”。
需求讨论会上必须要使用笔记本电脑，还要指定一个打字熟练的人把所有的讨论记录下来，记录的同时还要做一定的整理。如果不这样做，那么你结束会议的时候就会发现，所有的讨论只剩下一个模糊的印象，需求对你来说仍然是一件遥远的事情。在座谈讨论之后，记下所讨论的条目(item)，并请参与讨论的用户评论并更正。及早并经常进行座谈讨论是需求获取成功的一个关键途径，因为只有提供需求的人才能确定是否真正获取需求。进行深入收集和分析以消除任何冲突或不一致性。
尽量把客户所持的假设解释清楚，特别是那些发生冲突的部分。从字里行间去理解以明确客户没有表达清楚但又想加入的特性或特征。Gause 和Weinberg（1989）提出使用“上下文无关问题”—这是一个高层次的问题，它可以获取业务问题和可能的解决方案的全部信息。客户对这些问题的回答诸如“产品要求怎样的精确度”或“你能帮我解释一下你为什么不同意某人的回答吗？”这些回答可以更直接地认识问题，而这是封闭（close-end）问题所不能做到的。
需求获取利用了所有可用的信息来源，这些信息描述了问题域或在软件解决方案中合理的特性。一个研究表明：比起不成功的项目，一个成功的项目在开发者和客户之间采用了更多的交流方式（Kiel and Carmel 1995）。与单个客户或潜在的用户组一起座谈，对于业务软件包或信息管理系统（MIS）的应用来说是一种传统的需求来源。直接聘请用户进行获取需求的过程是为项目获得支持和买入（buy-in）的一种方式。
尽量理解用户用于表述他们需求的思维过程。充分研究用户执行任务时作出决策的过程，并提取出潜在的逻辑关系。流程图和决策树是描述这些逻辑决策途径的好方法。
在需求获取的过程中，你可能会发现对项目范围的定义存在误差，不是太大就是太小。如果范围太大，你将要收集比真正需要更多的需求，以传递足够的业务和客户的值，此时获取过程将会拖延。如果项目范围太小，那么客户将会提出很重要的但又在当前产品范围之外的需求。当前的范围太小，以致不能提供一个令人满意的产品。需求的获取将导致修改项目的范围和任务，但作出这样具有深远影响的改变，一定要小心谨慎。
正如经常所说的，需求主要是关于系统做什么，而解决方案如何实现是属于设计的范围。这样说虽然很简洁，但似乎过于简单化。需求的获取应该把重点放在“做什么”上，但在分析和设计之间还是存在一定的距离。你可以使用假设“怎么做”来分类并改善你对用户需求的理解。在需求的获取过程中，分析模型、屏幕图形和原型可以使概念表达得更加清楚，然后提供一个寻找错误和遗漏的办法。把你在需求开发阶段所形成的模型和屏幕效果看成是方便高效交流的概念性建议，而不应该看成是对设计者选择的一种限制。
需求获取讨论会中如果参与者过多，就会减慢进度。人数大致控制在5到7人是最好的。这些人包括客户、系统设计者、开发者和可视化设计者等主要工程角色。相反地，从极少的
代表那里收集信息或者只听到呼声最高、最有舆论影响的用户的声音，也会造成问题。这将导致忽视特定用户类的重要的需求，或者其需求不能代表绝大多数用户的需要。最好的权衡在于选择一些授权为他们的用户类发言的产品代表者，他们也被同组用户类的其它代表所支持。
没有一个简单、清楚的信号暗示你什么时候已完成需求获取。当客户和开发者与他们的同事聊天、阅读工业和商业上的文献及在早上沐浴时思考时，他们都将对潜在产品产生新的构思。你不可能全面收集需求，但是下列的提示将会暗示你在需求获取的过程中的返回点。
1. 如果用户不能想出更多的使用实例，也许你就完成了收集需求的工作。用户总是按其重要性的顺序来确定使用实例的。
2. 如果用户提出新的使用实例，但你可以从其它使用实例的相关功能需求中获得这些新的使用实例，这时也许你就完成了收集需求的工作。这些新的使用实例可能是你已获取的其它使用实例的可选过程。
3. 如果用户开始重复原先讨论过的问题，此时，也许你就完成了收集需求的工作。
4. 如果所提出的新需求比你已确定的需求的优先级都低时，也许你就完成了收集需求的工作。
5. 如果用户提出对将来产品的要求，而不是现在我们讨论的特定产品，也许你就完成了收集需求的工作。
以上知识大致上讨论需求分析应该如何做，实际上对于需求分析的方法有很多很多，已经形成了一定的理论，当然这种理论比较偏向与方法学，而方法学的应用主要还是要靠个人。所以，大家在实际应用的时候，不妨结合自己的实际，有选择性的采用一些方法，那你就是成功的。
多年来，分析者总是利用情节或经历来描述用户和软件系统的交互方式，从而获取需求（McGraw and Harbison 1997）。Ivar Jacobson（1992）把这种看法系统地阐述成用例（用例）的方法进行需求获取和建模。虽然用例来源于面向对象的开发环境，但是它也能应用在具有许多开发方法的项目中，因为用户并不关心你是怎样开发你的软件。而最重要的，用例的观点和思维过程带给需求开发的改变比起是否画正式的用例图显得更为重要。注意用户要利用系统做什么远远强于询问用户希望系统为他们做什么这一传统方法。
用例的重要功能是用画用例图的功能来鉴别和划分系统功能。它把系统分成角色（actor）和用例（用例）。角色(actor)表示系统用户能扮演的角色（role）。这些用户可能是人，可能是其他的计算机一些硬件或者甚至是其它软件系统，唯一的标准是它们必须要在被划分进用例的系统部分以外。它们必须能刺激系统部分并接收返回。用例描述了当角色给系统特定的刺激时系统的活动。这些活动被文本描述。它描述了触发用例的刺激的本质，输入和输出到其他活动者，和转换输入到输出的活动。用例文本通常也描述每一个活动在特殊的活动线时可能的错误和系统应采取的补救措施。
这样说可能会非常复杂，其实一个用例描述了系统和一个角色（actor）的交互顺序。
用例被定义成系统执行的一系列动作，动作执行的结果能被指定角色察觉到。用例可以:
·用例捕获某些用户可见的需求，实现一个具体的用户目标。
·用例由角色激活，并提供确切的值给角色。
·用例可大可小，但它必须是对一个具体的用户目标实现的完整描述。在UML中，用例表示为一个椭圆。
角色是指用户在系统中所扮演的角色。其图形化的表示是一个小人。在某些组织中很可能有许多角色实例（例如有很多个销售员），但就该系统而言，他们均起着同一种作用，扮演着相同的角色，所以用一个角色表示。一个用户也可以扮演多种角色。例如，一个高级营销人员既可以是贸易经理，也可以是普通的营销人员；一个营销人员也可以是售货员。在处理角色时，应考虑其作用，而不是人或工作名称，这一点是很重要的。
我们使用不带箭头的线段将角色与用例连接到一起，表示两者之间交换信息，称之为通信联系。角色触发用例，并与用例进行信息交换。单个角色可与多个用例联系；反过来，一个用例可与多个角色联系。对同一个用例而言，不同角色有着不同的作用：他们可以从用例中取值，也可以参与到用例中。需要注意的是角色在用例图中是用类似人的图形来表示，尽管执行的，但角色未必是人。例如，角色也可以是一个外界系统，该外界系统可能需要从当前系统中获取信息，与当前系统有进行交互。
一个用例可能包括完成某项任务的许多逻辑相关任务和交互顺序。因此，一个用例是相关的用法说明的集合，并且一个说明（scenario）是用例的实例。这种关系就像是类和对象的关系。在用例中，一个说明被视为事件的普通过程(normal course)，也叫作主过程，基本过程，普通流，或“满意之路”(happy path)。在描述普通过程时列出执行者和系统之间相互交互或对话的顺序。当这种交互结束时，执行者也达到了预期的目的。
在用例中的其它说明可以描述为可选过程(alternative coruse)。可选过程也可促进成功地完成任务，但它们代表了任务的细节或用于完成任务的途径的变化部分。在交互序列中，普通过程可以在一些决策点上分解成可选过程，然后再重新汇成一个普通过程。
二．需求建模
要有效地收集需求，要做的第一步是建模，它包括创建体系结构的表示形式以捕获需求、就解决方案方法进行交流、以及分析所提出的系统设计。其目的是使用模型来表现系统中的关键方面。然后，可以在形式化的分析、模拟和原型设计中使用这些模型，以研究预期的系统行为，并且可以在编写文档或总结时使用这些模型，以便就系统的性能和外观进行交流。
域建模
域建模指的是，对问题域创建相应的模型并且把它划分为若干个内聚组的过程。然后，可以在抽象模型中捕获业务流程、规则和数据。
域模型是一种用于理解问题域的工具。需要从信息系统之外的角度来理解这个域，这一点是很重要的。
要构造域模型，必须完成下列工作：
?标识并确定参与者（实体）及其操作（活动）的特征。
?标识管理操作（规则）的策略。
?收集有关实现这些操作、来自这些操作或者记录这些操作（构件/数据）的信息。
?将相关的要素划分为子域。
?确定结果域（核心的/通用的/外部的）以及它们之间交互的特征。
在这个过程中，一个有见地的架构师将学习到很多东西。结果域模型和相关的知识是实现角色（作为问题空间和解决方案空间之间的桥梁）的第一步。
用例建模
用例模型描述了各种参与者（人和其他系统）和要分析的系统之间的主要交互。用例应该说明系统如何支持域和业务流程模型中的业务流程。
用例模型应该将系统放到上下文环境中，显示系统和外部参与者之间的边界，并描述系统和参与者之间的关键交互。用例建模可以描述利益相关者（例如，用户和维护人员）所看到的系统行为
组件和服务建模
组件模型为子系统、模块和组件的层次结构分配需求和职责。每个元素作为一个自包含的单元，以用于开发、部署和执行的目的。组件模型的元素由它们所提供和使用的接口来进行规定。在这里，没有考虑其中的内部细节。
服务模型将应用程序定义为一组位于外部边界（用例）、架构层之间的抽象服务接口，并且提供了通用的应用程序和基础结构（安全、日志记录、配置等等）。支持应用程序需求的这组服务可以与现有的内部和外部提供的接口规范相匹配。所得到的分析结果可以确定预置策略，并将项目活动划分为特定类型的部分，这取决于给定的服务是否已经存在（内部或者外部的，并且其中每个服务都具有适当的活动）、存在但需要进行修改（定义一个新的接口，并规划其实现）、或者必须构建新的服务。
。
第一章 1.需求分析与系统设计之间的界限是什么何时从分析阶段进入设计阶段需求分析关注系统“做什么”，系统设计关注“如何做”。 当分析阶段完成后才能进入到设计阶段 2.需求处理要注意哪些非技术因素为什么 要注意的非技术因素：组织机构文化、社会背景、商业目标、利益协商等。因为利用建模与分析技术构建的解决方案一定要和具体的应用环境相关，不存在不依赖具体应用环境的解决方案，因此，在利用建模分析技术进行要求处理是不能忽视具体应用环境的相关因素 3.需求分析与需求工程之间的关系 那就是需求工程含义更广，包括需求获取、需求分析、需求定义 第二章 1.解释名词:问题域，解系统和共享现象，并结合他们的含义说明软件系统如何与现实世界形成互动的 问题域：现实的状况与人们期望的状况产生差异就产生问题。 解系统:软件系统通过影响问题域，能够帮助人们解决问题称为解系统通过共存现象仅仅是问题域和姐系统的一个部分。而不是他们的全部。 软件系统仅仅是现实世界的一种抽象。所以问题除了共享现象之外。还有很多在进行模型抽象时忽略的其他现实因素。 2.解释下列名词，需求，规格说明，问题域特性和约束，并结合他们的含义说明需求工程的主要任务是什么 需求是用户对问题域中的实体状态或事件的期望描述
规格说明:规格说明是解系统为满足用户需求而提供的解决方案，规定了解系统的行为特征。 问题域的特性：在和解系统相互影响的同时，问题域是自治的，它有自己的运行规律，而且这些规律不会因解系统的引入而发生改变，这种自治的规律性称为问题域特性，当这些特性非常明确时称之为约束。 需求工程的主要任务：1.需求工程必须说明软件系统将应用的环境及目标，说明用来达成这些目标的软件功能，还要说明在设计和实现这些功能时上下文环境对软件完成任务所用的方式、方法所施加的限制和约束。2需求工程必须将目标、功能和约束反映到软件系统中，映射为可行的软件行为，并对软件行为进行准确的规格说明。3需求工程还要妥善处理目标、功能和约束随着时间的演化情况。 4.需求有哪些常见的类别功能需求和非功能需求有什么差异 严格意义上的软件需求的分类： 功能需求（Functional Requirement）：和系统主要工作相关的需求，即在不考虑物理约束的情况下，用户希望系统所能够执行的活动，这些活动可以帮助用户完成任务。功能需求主要表现为系统和环境之间的行为交互。 Performance Requirement）：系统整体或系统组成部分应该 CPU使用率、内存使用率等。 Quality Attribute）：系统完成工作的质量，即系统需要在“好的程度”上实现功能需求，例如可靠性程度、可维护性程度等。 External Interface）：系统和环境中其他系统之间需要建立的接口，包括硬件接口、软件接口、数据库接口等等。
第1章软件工程基础知识 1.1软件工程知识体系 ●软件需求（Software Requirements） ●软件设计（Software Design） ●软件构造（Software Construction） ●软件测试（Software Testing） ●软件维护（Software Maintenance） ●软件配置管理（Software Configuration Management） ●软件工程管理（Software Engineering Management） ●软件工程过程（Software Engineering Process） ●软件工程工具和方法（Software Engineering Tools and Methods） ●软件质量（Software Quality） 1.2软件生存周期与软件开发模型 ● 1.2.1 软件生存周期 ●Boehm定义的软件生存周期模型 ●GB 8566-1988定义的软件生存周期模型 ●GB/T 8566-1995定义的软件生存周期过程模型 ●GB/T 8566-2001定义的软件生存周期过程模型 ●UP定义的软件生存周期模型 ● 1.2.2 软件开发模型 ●瀑布模型（waterfall model） ●快速原型模型（rapid prototype model） ●演化模型（evolutionary model） ●增量模型（incremental model） ●螺旋模型（spiral model） ●喷泉模型（water fountain model） 1.3软件质量模型与软件质量管理 ● 1.3.1 软件质量模型 ●软件产品的内部质量、外部质量和使用质量 ●质量特性、质量子特性和度量 ●功能性：适宜性、准确性、互用性、依从性、安全性 ●可靠性：成熟性、容错性、可恢复性 ●可用性：可理解性、易学性、可操作性 ●效率：时间特性、资源特性 ●可维护性：可分析性、可修改性、稳定性、可测试性 ●可移植性：适应性、易安装性、一致性、可替换性 ● 1.3.2 软件质量管理 ●质量需求分析 ●质量计划 ●质量保证 ●质量控制 ●质量改进 ●软件质量管理体系
软件需求分析与设计复习题 一．判断 1、( × ) 程序设计语言种类很多，在进行软件开发时可以随便选择一种语言进行编码。 2. ( x ) 软件需求规格说明书在软件开发中具有重要的作用，是软件可行性分析的依据。 3、(× ) 在软件开发的各个阶段进行过程中，增加人员肯定会对整个项目提前完成有好处。 4．( x ) 好的测试用例应能证明软件是正确的。 5．( x ) 软件功能测试的测试用例主要是由需求阶段的功能说明部分转化而来。 6、( x ) CoCoMo模型可以用来估算系统的工作量和软件开发所需时间。 7．( x ) 有时为了测试的方便，而可以局部地修改软件系统。 8、( v ) OOA方法的核心思想是利用面向对象的概念和方法为软件需求建造模型，大致步骤是识别对象（属性和方法），识别类及其结构，定义对象之间的消息传递等。 9．( x ) 面向对象方法更适合于软件重用的根本原因在于它是软部件唯一的合成技术。 10、( v ) 系统需求分析员应该具有开发软、硬件系统的经验并且了解用户领域的知识。 11．( x ) 在软件的生命周期中，工作量最大的一个阶段就是编写程序。 12、( x )软件运行正确，可见软件中没有缺陷（fault）。 13．( x ) RUP（Rational Unified Process：统一软件过程）本质上是轻量级的软件过程规范。 14、( v )软件失败（failure）在系统交付之前和交付之后都可能被发现。 15．( x ) 基准测试（benchmark test）是非正式的用户确认和验收测试。 16、( x )开发人员和客户对软件质量因素的认可是完全一致的。 17．( x ) UML语言支持面向对象的主要概念，并与具体的开发过程相关。 18、( v )里程碑（milestone）就是开发过程中的某个活动(activity)。 19．( v ) 好的软件测试是用少量的测试用例运行程序，发现被测程序尽可能多的错误。 20、( x )在软件开发中一定要不惜代价避免风险。 21．( v ) 在需求分析中，分析员要从用户那里解决的最重要的问题是明确软件做什么。 对功能的具体实现。 22．( v )用例图定义了系统的功能需求，它是从系统的外部看系统功能，并不描述系统内部 23．( v ) 软件过载缺陷就是当运行程序时，软件内部定长的数据结构被溢出，系统任务无法 24．( v ) 结构化程序设计方法能改善程序结构，提高程序的运行效率。 二、选择从供选择的答案中，选出正确的答案填入（）内 1．白盒测试法常用的方法是A方法，黑盒法中常用的方法是B方法和C方法，C方法根据输入的关系设计测试用例。供选择的答案：（②③⑤） A、B、C：①综合测试②路径测试③等价分类④归纳测试 ⑤因果图⑥追踪⑦回溯⑧排错 2. 软件工程的出现是由于（ A ）。 A．软件危机的出现 B. 计算机硬件技术的发展 C．软件社会化的需求 D. 计算机软件技术的发展 3. 系统技术可行性研究涉及的技术应该是（D）技术。 A．现在已提出的 B. 现在在研究的C．不一定可以获得的 D. 一定可以获得的 4．模块综合测试的方法有A和B两种，A是从下层模块向上层模块依次结合进行测试，为测试需要C 以便调用被测模块，但从开发的初期就能并行进行测试作业，并且每个模块的D都很容易做，是这种方法的优点。其缺点是直到测试的最后阶段，程序的缺陷都难以发现。B是从上层模块向下层模块依次结合进行测试，为了测试需要设计E模块模拟被测模块所调用的下级模块。 供选择的答案：（A：⑦ B：⑥ C：⑥ D：① E：①） A、B、D：①功能测试②组合测试③综合测试④可靠性测试 ⑤结构测试⑥自顶向下测试⑦自底向上测试 C、E：①仿真②模拟③生成④转贮⑤跟踪 ⑥驱动模块⑦宏模块⑧支持模块
一、Goldstein三层次模型 二十世纪八十年代，I·L·Goldstein、E·P·Braverman、H·Goldstein三人经过长期的研究将培训需求评价方法系统化，构建了Goldstein三层次模型。 Goldstein三层次模型是培训需求分析的重要理论基础，它最大的特点就是将培训需求分析看成了一个系统，进行了层次上的分类，通过将组织、任务、人员的需求进行整合，使得培训需求更加全面化，分析结果更加科学化。该模型将培训需求分析分成了三个部分：组织分析、任务分析和人员分析。 Goldstein三层次模型图如图2-2所示： 图2-2 Goldstein三层次模型图 1、组织分析 组织层次的分析将组织的长期目标和短期目标作为一个整体来考察，同时考察那些可能对组织目标发生影响的因素。组织的需求分析由人力资源分析、效率指标分析和组织气氛分析三部分组成。 人力资源分析将组织目标表现为人力资源的需求、技术的需求以及为满足这些需求而制定的计划。培训将在实现需求与供给之间的匹配方面发挥重要的作用。 效率指标分析针对目前组织的效率状况。常用的效率指标包括工资成本、产出的数量和质量、、设备利用情况等。首先确定这些指标的标准，然后评估实际的组织效率状况，就可以得到相应的培训需求。 组织气氛分析用于描述组织气氛是否适宜，员工各方面的工作感受如何。如果通过分析发现差距很大并且影响到大部分员工时，就有必要引进培训来解决。 2、工作分析
组织分析旨在从全局上把握整个组织与工作群体的培训需求，属于较为全局性的层面，而针对每项具体工作的具体培训需求，必须通过工作层次的分析才能加以识别。 进行工作分析时，首先应掌握以下三方面的信息：每项工作所包含的任务；完成这些任务所需要的知识、技能、经验、个人特质等；衡量该工作的可接受的绩效标准。 这些信息可以从国家有关部门制定的一些规范、标准中得到，也可以通过观察、记录分析、跟踪等手段从企业内部获得一手资料，从中识别和收集。 接着对工作岗位上的人员工作现状进行评价。评价手段包括资料调查、行为观察、表现记录分析、舆论调查、访谈、典型事件分析、技能考核等。 通过现状与标准的比较，识别差距、分析原因，就可以确认相应的培训需求。 3、人员分析 个人层次的分析针对每一位员工个体进行，最终落实到“谁需要培训”以及“需要哪些培训”上。个人分析的内容包括：员工实际工作绩效与该工作可接受绩效标准的差距及其原因（当前培训需求）；员工对每项技术的熟练程度与该项技术所需熟练程度的差距及其原因（将来的培训需求）。 分析手段可采用观察、记录分析、资料调查、技能考核等。此外，员工的自我评价也是收集个人需求信息的重要来源。 Goldstein三层次模型在培训需求分析中的运用存在以下几方面的不足： 1、模型虽然考虑了企业战略、组织资源对培训需求的影响，但是忽略了行业政策、国家政策等外部环境的影响。 2、模型对人员进行分析主要集中在员工绩效现状与理想水平的差距上，关注的是员工“必须学什么”以缩小差距，而没有重视“员工想学什么”。 3、模型很难找到具体可操作的分析方法，缺乏简单有效的识别工具。 二、培训需求差距分析模型 美国学者汤姆·W·戈特将“现实状态”与“理想状态”之间的“差距”称为缺口，并依此确定员工知识、技能和态度等培训内容，这就是培训需求差距分析模型。
需求获取与需求建模 一．需求获取 需求获取，属于软件工程中的一部分，包括需求来源和获取需求的技术。它是软件设计的第一阶段，其本质主要是人的活动，涉及软件设计人员如何与客户建立有效的沟通。也称为“需求发现”、“需求获得”。 需求获取(requirement elicitation)是需求工程的主体。对于所建议的软件产品，获取需求是一个确定和理解不同用户类的需要和限制的过程。获取用户需求位于软件需求三个层次的中间一层。业务需求决定用户需求，它描述了用户利用系统需要完成的任务。从这些任务中，分析者能获得用于描述系统活动的特定的软件功能需求，这些系统活动有助于用户执行他们的任务。需求获取和分析包括对原始需求变更控制，版本控制，从需求到产品和模块的可追溯性，成品交付和产品的状态跟踪。 需求获取是在问题及其最终解决方案之间架设桥梁的第一步。获取需求的一个必不可少的结果是对项目中描述的客户需求的普遍理解。一旦理解了需求，分析者、开发者和客户就能探索出描述这些需求的多种解决方案。参与需求获取者只有在他们理解了问题之后才能开始设计系统，否则，对需求定义的任何改进，设计上都必须大量的返工。把需求获取集中在用户任务上—而不是集中在用户接口上—有助于防止开发组由于草率处理设计问题而造成的失误。 需求获取、分析、编写需求规格说明和验证并不遵循线性的顺序，这些活动是相互隔开、增量和反复的。当你和客户合作时，你就将会问一些问题，并且取得他们所提供的信息（需求获取）。同时，你将处理这些信息以理解它们，并把它们分成不同的类别，还要把客户需求同可能的软件需求相联系（分析）。然后，你可以使客户信息结构化，并编写成文档和示意图（说明）。下一步，就可以让客户代表评审文档并纠正存在的错误（验证）。这四个过程贯穿着需求分析的整个阶段。需求获取可能是软件开发中最困难、最关键、最易出错及最需要交流的方面。需求获取只有通过有效的客户—开发者的合作才能成功。分析者必须建立一个对问题进行彻底探讨的环境，而这些问题与产品有关。为了方便清晰地进行交流，就要列出重要的小组，而不是假想所有的参与者都持有相同的看法。对需求问题的全面考察需要一种技术，利用这种技术不但考虑了问题的功能需求方面，还可讨论项目的非功能需求。确定用户已经理解：对于某些功能的讨论并不意味着即将在产品中实现它。对于想到的需求必须集中处理并设定优先级，以避免一个不能带来任何益处的无限大的项目。 需求获取是一个需要高度合作的活动，而并不是客户所说的需求的简单誊本。作为一个分析者，你必须透过客户所提出的表面需求理解他们的真正需求。询问一个可扩充（open-ended）的问题有助于你更好地理解用户目前的业务过程并且知道新系统如何帮助或改进他们的工作。调查用户任务可能遇到的变更，或者用户需要使用系统其它可能的方式。想像你自己在学习用户的工作，你需要完成什么任务？你有什么问题？从这一角度来指导需求的开发和利用。 还有，探讨例外的情况：什么会妨碍用户顺利完成任务？对系统错误情况的反映，用户是如何想的？询问问题时，以“还有什么能”,”当?时，将会发生什么”“你有没有曾经想过”,“有没有人曾经”为开头。记下每一个需求的来源，这样向下跟踪直到发现特定的客
普通话考试报名及成绩查询系统 需求分析 项目名称：普通话考试报名及成绩查询系统撰写人： 专业： 指导老师： 2012年3月19日
摘要 网络技术的飞速发展正无时无刻影响着人们的工作、在教育体系中,网络的应用也成为现代教育发展的基础.网络教育逐渐发展起来,校园网建设逐步成熟,基于Web的也伴随着网络技术的发展应运而生.它即简化了传统的考试模式,节约人力物力,也可以有效利用校园网资源,辅助教学. 该系统采用了目前流行的B/S模式,即浏览器、应用服务器、数据库服务器三层体系结构，后台数据库采用SQL Server 2005,客户端采用IE浏览器和服务器连接,最终形成了基于 B/S模式的在线考试系统.该系统具备了以下功能:学生信息管理、成绩查询等功能. 论文以基于B/S模式的在线考试系统为研究对象,按照软件工程的开发思想,用UML来构建在线考试系统模,后台采用数据库相结合. 际需求出发,论述了开发普通话等级考试报名及成绩查询系统的背景、目的及意义,讨论了开发系统的关键技术,并通过UML分析对系统设计及实现。 设计思路和方法采用瀑布模型开发，用统一建模语言 UML进行描述，经历了文献检索，需求分析，分析模型设计，数据模型设计，构建级设计，系统部署，系统测试六个个环节。。实现了用户登录、注册功能，出题组卷功能，考试评卷功能以及用户信息查询功能。 关键词：普通话等级考试报名及成绩查询系统； SQL SERVER2005
目录 一．摘要 (2) 二．背景 (5) 三．简介 (5) 1.设计目的 (5) 2.开发环境 (5) 3.程序功能 (6) 4.系统实际需求特点 (6) 四．整体规划思路 (6) 五．整体性需求分析 (6) 六．功能需求 (9) 1.业务规则 (9) 2.普通话等级考试报名及成绩查询系统登录 (10) 七．数据库设计 (12) 1.概念模型设计 (12) 2.数据表结构 (12) 八．系统结构设计 (14) 九．对性能的规定 (15) 1.灵活性 (15)
XX系统 软件需求分析和设计说明书（使用面向对象的方法） 组号： 组长： 组员：
任务分配表 1请详细注明每位同学具体的工作内容。
目录 1 热身：练习使用Visio (1) 2 作业：面向对象的分析和设计 (2) 2.1 用例图 (2) 2.2 类图 (2) 2.3 序列图（顺序图） (2) 2.4 状态图（状态机图） (2) 2.5 活动图 (2)
XX系统软件需求分析和设计说明书 （面向对象方法）2 1热身：练习使用Visio 以Microsoft Office Visio 2003为例：启动Visio，点击“帮助—Microsoft Office Visio帮助”。在弹出的窗口中，点击“目录”—“创建绘图”—“软件”—“UML模型图”—“关于UML模型”。在“关于UML模型”窗口中，依次练习使用对各类图的绘制方法。其中，对类和对象的描述安排在“静态结构图”中。 在Microsoft Office Visio 2003中的“关于UML模型”窗口示意： 如安装Microsoft Office Visio 2007：则启动Visio，点击“帮助—Microsoft Office Visio 帮助”。在弹出的窗口中，点击“软件和数据库模型图”—“UML图”—“UML 系统模型和类型”。按提示，依次练习使用“系统模型”（关于UML 模型图模板中的系统模型、向现有UML 系统模型添加新模型、创建新的UML 系统模型）、“用例图”、“静态结构图”、“序列图”、“状态图”、“活动图”，等。其中，对类和对象的描述安排在“静态结构图”中。 热身要求：熟悉上述UML图的用途和表示方法，按照帮助说明使用Visio软件绘制“裁判员认证系统”的相关UML图。每人独立完成，不需要提交试验报告。 实验时数：3学时。 2在5月22日前，由组长把本实验报告发送至教师邮箱。组长在发送作业时，需要同时（如不同时转发，本次发送视同无效！）转发给所有组内的其他同学。教师邮箱：dodge2000@https://www.doczj.com/doc/1819223698.html,，相关作业文件应为Word格式，并以附件方式发送。请在邮件的主题中标出：软件工程课程作业；[学号]；[姓名]。例如：“软件工程课程作业；04052119；倪哉君”。文中“XX”字样必须由实际的选题替换。
数据分析和数据建模 大数据应用有几个方面，一个是效率提升，帮助企业提升数据处理效率，降低数据存储成本。另外一个是对业务作出指导，例如精准营销，反欺诈，风险管理以及业务提升。过去企业都是通过线下渠道接触客户，客户数据不全，只能利用财务数据进行业务运营分析，缺少围绕客户的个人数据，数据分析应用的领域集中在企业内部经营和财务分析。 大数据应用有几个方面，一个是效率提升，帮助企业提升数据处理效率，降低数据存储成本。另外一个是对业务作出指导，例如精准营销，反欺诈，风险管理以及业务提升。过去企业都是通过线下渠道接触客户，客户数据不全，只能利用财务数据进行业务运营分析，缺少围绕客户的个人数据，数据分析应用的领域集中在企业内部经营和财务分析。 数字时代到来之后，企业经营的各个阶段都可以被记录下来，产品销售的各个环节也被记录下来，客户的消费行为和网上行为都被采集下来。企业拥有了多维度的数据，包括产品销售数据、客户消费数据、客户行为数据、企业运营数据等。拥有数据之后，数据分析成为可能，企业成立了数据分析团队整理数据和建立模型，找到商品和客户之间的关联关系，商品之间关联关系，另外也找到了收入和客户之间的关联关系。典型的数据分析案例如沃尔玛啤酒和尿布、蛋挞和手电筒，Target的判断16岁少女怀孕都是这种关联关系的体现。
关联分析是统计学应用最早的领域，早在1846年伦敦第二次霍乱期间，约翰医生利用霍乱地图找到了霍乱的传播途径，平息了伦敦霍乱，打败了霍乱源于空气污染说的精英，拯救了几万人的生命。伦敦霍乱平息过程中，约翰医生利用了频数分布分析，建立了霍乱地图，从死亡案例分布的密集程度上归纳出病人分布同水井的关系，从而推断出污染的水源是霍乱的主要传播途径，建议移除水井手柄，降低了霍乱发生的概率。 另外一个典型案例是第二次世界大战期间，统计分析学家改造轰炸机。英美联盟从1943年开始对德国的工业城市进行轰炸，但在1943年年底，轰炸机的损失率达到了英美联盟不能承受的程度。轰炸军司令部请来了统计学家，希望利用数据分析来改造轰炸机的结构，降低阵亡率，提高士兵生还率。统计学家利用大尺寸的飞机模型，详细记录了返航轰炸机的损伤情况。统计学家在飞机模型上将轰炸机受到攻击的部位用黑笔标注出来，两个月后，这些标注布满了机身，有的地方标注明显多于其他地方，例如机身和侧翼。有的地方的标注明显少于其他地方，例如驾驶室和发动机。统计学家让军火商来看这个模型，军火商认为应该加固受到更多攻击的地方，但是统计学家建议对标注少的地方进行加固，标注少的原因不是这些地方不容易被击中，而是被击中的这些地方的飞机，很多都没有返航。这些标注少的地方被击中是飞机坠毁的一个主要原因。军火商按照统计学家的建议进行了飞机加固，大大提高了轰炸机返航的比率。以二战著名的B-17轰炸机为例，其阵亡率由26%降到了7%，帮助美军节约了几亿美金，大大提高了士兵的生还率。 一数据分析中的角色和职责 数据分析团队应该在科技部门内部还在业务部门内部一直存在争议。在业务部门内部，对数据场景比较了解，容易找到数据变现的场景，数据分析对业务提升帮助较大，容易出成绩。但是弊端是仅仅对自己部门的业务数据了解，分析只是局限独立的业务单元之内，在数据获取的效率上，数据维度和数据视角方面缺乏全局观，数据的商业视野不大，对公司整体业务的推动发展有限。业务部门的数据分析团队缺少数据技术能力，无法利用最新的大数据计算和分析技术，来实现数
软件需求分析方案设计 软件需求分析是研究用户需求得到的东西，完全理解用户对软件需求的完整功能，确认用户软件功能需求，建立可确认的、可验证的一个基本依据。今天小编为大家准备了软件需求分析方案设计，欢迎阅读! 软件需求分析方案设计如果我们用数学方法来描述软件需求分析，可以将一个应用软件定义为S，可能应用软件涉及功能性问题非常广，我们用抽象化理论分析，可以划分为各个功能域，可以用D1、D2、… Dn表示，那么，我们可以用一个表达式描述为 S={D1，D2，D3，…Dn} 但是，功能域Di依然存在着有若干个问题P1、P2、P3、…Pm组成，并且每个功能对应于子系统中的一个软构件，我们可以表示为 Di={P1，P2，P3，…Pm} 同样，功能Pj有若干个行为F1、F2、F3、… Fk，每个行为对应于软构件中的实现方法 Pj={F1，F2，F3，…Fk} 一个软件包含了所有功能的集合，同时包含了实现所有功能的所有方法和算法描述。需求分析是依据于用户需求，经过需求问题识别，进行分析、消化与综合，制订规格说明，评审，分为四个阶段，形成用户需求与设计同步，设计满足
用户需求目标。 需求分析方法始终贯穿着吸收、同化、贯彻方法和手段，用商业化行为解决需求与实现中存在的矛盾，解决用户需求与商业化产品融通，解决规范与个性化追求。 软件需求分析的主要实现目标： 1)对实现软件的功能做全面的描述，帮助用户判断实现功能的正确性、一致性和完整性，促使用户在软件设计启动之前周密地、全面地思考软件需求; 2)了解和描述软件实现所需的全部信息，为软件设计、确认和验证提供一个基准; 3)为软件管理人员进行软件成本计价和编制软件开发计划书提供依据; 需求分析的具体内容可以归纳为六个方面：软件的功能需求，软件与硬件或其他外部系统接口，软件的非功能性需求，软件的反向需求，软件设计和实现上的限制，阅读支持信息。 软件需求分析应尽量提供软件实现功能需求的全部信息，使得软件设计人员和软件测试人员不再需要需求方的接触。这就要求软件需求分析内容应正确、完整、一致和可验证。此外，为保证软件设计质量，便于软件功能的休整和验证，软件需求表达无岔意性，具有可追踪性和可修改性。 、软件功能需求
一、概述 近年来，随着现代化高新技术的发展，计算机的飞速发展，网络化时代的到来，Internet的普及，信息技术已经发展到社会的每一个角落，越来越多的企业建立了自己的WWW网站，企业通过网站可以展示产品，发布最新动态，与用户进行交流和沟通，与合作伙伴建立联系，以及开展电子商务等。其中新闻信息管理系统是构成企业网站的一个重要组成部分，它担负着双层作用，一方面可以用来动态发布有关新产品或新开发项目，另一方面又可以及时向顾客公告企业经营业绩、技术与研发进展、特别推荐或优惠的工程项目、产品和服务，从而吸引顾客，扩大顾客群。 所以我们根据当前实际情况，分析了当今乃至将来社会的信息技术的发展和走向，设计出了一套完整的、基于B/S架构的信息管理系统，本文将详细论述整个系统的各个功能。 就现在开发信息管理系统的技术来说，主要集中分为三大类：基于C/S架构的应用程序开发，结合C/S架构和Web技术的复合应用程序，基于B/S架构的Web技术。现行主流的信息管理主要是采用ASP和脚本语言技术，但是由于ASP 本身的局限性使得系统有一些不可克服的缺陷，而虽说采用JSP技术可以改善这些缺陷,但其成本费用太高,所以,本系统采取当今比较流行的https://www.doczj.com/doc/1819223698.html,+MS SQL 技术,其性价比也有了很大提高。 该系统适应了政府、企业、事业单位和个人等使用，即可以作为内部工作网，也可以作为外的网的信息发布与共享。经调研，本系统所设计的运行模式符合大众需求，同时还增加了一些辅助功能，因此，本系统的设计具有较强的条理性、适应性和实用性。 运行本系统要安装https://www.doczj.com/doc/1819223698.html,运行环境和MS SQL，若没有安装，请按顺序安装以下软件： IE6.0 sp1 中文版； MDAC2.8 中文版； .Net Framework 1.1 可再发行组件包 .Net SDK 1.1 中文正式版； .Net Framework 1.1 sp1 for win2000；
需求分析与功能建模方法 (总分：40.00，做题时间：90分钟) 一、{{B}}选择题{{/B}}(总题数：40，分数：40.00) 1.软件开发人员开发软件产品的依据应该是______。 （分数：1.00） A.软件需求规格说明书√ B.可行性分析报告 C.标准说明书 D.项目合同 解析：[解析] 软件开发人员应该依据软件需求规格说明书开发软件产品，所以本题的答案为A。 2.在DFD建模方法中用平行四边形表示的基本对象是______。 （分数：1.00） A.数据源及数据终点√ B.数据流 C.数据存储 D.处理 解析：[解析] 数据源及数据终点表示当前系统的数据来源或数据去向，可以是某个人员、组织或其他系统，它处于当前系统范围之外，所以又称它为外部项，其图形符号用平行四边形表示，所以本题的答案为A。选项B数据流用标有名字的箭头表示，选项C数据存储分用指向或离开的箭头表示对存储数据的存取。选项D处理用矩形框表示。 3.在DFD建模方法中用矩形框表示______。 （分数：1.00） A.数据源及数据终点 B.数据流 C.数据存储 D.处理√ 解析：[解析] 在DFD建模方法中用矩形框表示的是处理。所以本题的答案为D。选项A数据源及数据终点用平行四边形表示，选项B数据流用标有名字的箭头表示，选项C数据存储分用指向或离开的箭头表示对存储数据的存取。 4.在需求分析阶段，结构化分析和建模方法是一种较为有效的需求分析方法，下列不属于结构化分析和建模方法优点的是______。 （分数：1.00） A.用图形化的模型能直观地表示系统功能 B.可避免过早陷入具体细节 C.图形对象不涉及太多技术术语，便于用户理解模型 D.从局部或子系统开始分析问题，便于建模人员了解业务模型√ 解析：[解析] 结构化分析及建模方法的主要优点是：①不过早陷入具体的细节。②从整体或宏观入手分析问题，如业务系统的总体结构，系统及子系统的关系。③通过图形化的模型对象直观地表示系统要做什么，完成什么功能。④图形化建模方法方便系统分析员理解和描述系统。⑤模型对象不涉及太多技术术语，便于用户理解模型。 5.评审委员会评审的依据应该是系统功能模型和______。 （分数：1.00） A.软件需求说明书√ B.可行性分析报告 C.标准说明书 D.项目合同 解析：[解析] 评审的依据主要是系统的功能模型和需求说明书中描述的内容，所以本题的答案为A。
1 问题分析的主要步骤（五步）？ (1) 在问题定义上达成共识； (2) 理解根本原因，分析问题背后的问题； (3) 确定相关人员和用户； (4) 定义解决方案的界限； (5) 确定加在解决方案上的约束。 2 鱼骨图主要用于定性分析，帕累托图主要用于定量分析。 3 鱼骨图、帕累托图构建的主要步骤？ 鱼骨图 A 选择问题 首先选择一个具体的问题或者结果。在选择问题时，要保 证问题是专门的、定义严谨的、范围相对较小的（对于大范围 的问题往往需要考虑将其分解成相对较小的问题），并且保证 参与人员切实理解要分析的内容。对问题定义产生出来的问题 一般都应该进行一次独立的鱼骨图分析。 B 头脑风暴 就导致问题的可能原因进行头脑风暴。将大家提出的意 见记录下来，确认后贴到鱼骨图上。 需要注意的是不要将原因和解决方案混为一谈。在确定 原因的分类前先进行头脑风暴（一个人提，大家批），不然 思考问题的范围就会受到限制。支持者需要引导和鼓励参与 者参与其中。 C 确定问题类型 对头脑风暴的结果进行整理，确定出主要的原因类型。
一般来说，划分出来的问题不要少于2类，不要超过6类 （经验数值，仅供参考）。经常使用的类型有：人、设备、 材料、环境、方法、过程等。将这些类型补充到鱼骨图上。 D 分配原因 将头脑风暴中得出的潜在原因放在鱼骨图上，并且确保每一项原因都归于适当的类别中。如果原因看起来可以放在多个 类别中，就表示是多重原因造成的问题。但如果多次出现多重 原因，可能就以为着分类存在问题。该阶段将形成最终的鱼骨图E 分析根本原因 对鱼骨图中罗列出来的所有潜在原因进行分析。分析出造成某一结果的最根本原因是什么？找出核心所在。 方法如下： 通过参与者之间的公开讨论来分享看法和经验； 寻找重复的原因，或者与特定类有关的原因的数量； 使用检查表收集资料、制造流程图或者进行用户调查， 通过帕累托分析法测试各种原因的相对强度； 投票（真理多数情况下掌握在多数人手里） 帕累托图 在通过使用鱼骨图完成问题原因的定性描述后。仍然存在一个 问题，就是根本原因的辨识需要有经验的决策者确定，或者根 据人类固有经验（少数服从多数）确定。更好地方法是能够开 展定量分析。帕累托分析可以帮助我们做出这样的定量分析。 帕累托分析应用就是根据鱼骨图分析的结果，通过收集相关统计资料，通过直方图的方式显示问题的相对频度或者大小高低等定
软件需求分析（Software Reguirement Analysis）是研究用户需求得到的东西，完全理解用户对软件需求的完整功能，确认用户软件功能需求，建立可确认的、可验证的一个基本依据。 软件需求分析是一个项目的开端，也是项目实施最重要的关键点。据有关的机构分析结果表明，我们设计的软件产品存在不完整性、不正确性等问题80％以上是需求分析错误所导致的，而且由于需求分析错误造成根本性的功能问题尤为突出。因此，一个项目的成功软件需求分析是关键的一步。 一、软件需求分析理论 如果我们用数学方法来描述软件需求分析，可以将一个应用软件定义为S，可能应用软件涉及功能性问题非常广，我们用抽象化理论分析，可以划分为各个功能域，可以用D1、D2、… Dn表示，那么，我们可以用一个表达式描述为S={D1，D2，D3，…Dn} 但是，功能域Di依然存在着有若干个问题P1、P2、P3、… Pm组成，并且每个功能对应于子系统中的一个软构件，我们可以表示为 Di={P1，P2，P3，…Pm} 同样，功能Pj有若干个行为F1、F2、F3、… Fk，每个行为对应于软构件中的实现方法 Pj={F1，F2，F3，…Fk} 一个软件包含了所有功能的集合，同时包含了实现所有功能的所有方法和算法描述。需求分析是依据于用户需求，经过需求问题识别，进行分析、消化与综合，制订规格说明，评审，分为四个阶段，形成用户需求与设计同步，设计满足用户需求目标。 需求分析方法始终贯穿着吸收、同化、贯彻方法和手段，用商业化行为解决需求与实现中存在的矛盾，解决用户需求与商业化产品融通，解决规范与个性化追求。 二、软件需求分析目标 软件需求分析的主要实现目标： 1）对实现软件的功能做全面的描述，帮助用户判断实现功能的正确性、一致性和完整性，促使用户在软件设计启动之前周密地、全面地思考软件需
需求分析建模技术内部编号：（YUUT-TBBY-MMUT-URRUY-UOOY-DBUYI-0128）
项目需求分析 1.需求分析概述 1.1需求分析定义 需求分析是指理解用户需求，就软件功能和性能与客户达成一致，估计软件风险和评估项目代价，最终形成开发计划的一个复杂过程。在这个过程中，用户处在主导地位，需求分析工程师和项目经理要负责整理用户需求，为之后的软件设计打下基础。需求分析阶段结束后，要求得到《用户需求说明书》和《需求规格说明书》两份文档。广义上，需求分析包括需求的获取、分析、规格说明、变更、验证、管理的一系列需求工程。 狭义上的需求分析是指需求的获取、分析及定义的过程。需求分析的任务就是软件系统解决“做什么”的问题，就是要全面地理解用户的各项要求，并准确地表达所接受的用户需求的过程。 1.2需求分析的根本任务 从实践角度考虑，需求分析不是分析如何实现用户的需求。实际上，需求分析是以业务分析为导向，将用户零散的需求串联起来，形成一个体系完成、组织合理、内容清晰的框架，为今后的设计开发工作打下良好的基础。 1、建立分析模型 将复杂的系统分解成为简单的部分以及它们之间的联系，确定本质 特征。 和用户达成对信息内容的共同理解。
分析的活动主要包括识别、定义和结构化，它的目的是获取某个可 以转换为知识的事物的信息。 2、创建解决方案 将一个问题分解成独立的、更简单和易于管理的子问题来帮助寻找 解决方案。 创建解决方案的过程是创造性的。 帮助开发者建立问题的定义，并确定被定义的事物之间的逻辑关 系。 这些逻辑关系可以形成信息的推理，进而可以被用来验证解决方案 的正确性。 1.3需求的层次 1、业务需求 反映组织机构或客户对系统、产品高层次的目标要求。通常问题定义就是业务需求 2、用户需求 描述用户使用产品必须要完成什么任务，怎么完成，通常是在问题定义 的基础上进用户访谈、调查，对用户使用的场景进行整理，从而建立从 用户角度的需求 3、系统需求 从系统的角度来说明软件的需求，它就包括了用特性说明的功能需求， 质量属性以及其它非功能需求，还有设计约束
基于android的物流客户端的需求分析 1.引言 1.1目的 1.2背景 1.3参考资料 1.4术语 列出本报告中用到的专门术语的定义。 2.任务概述 2.1目标 叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。解释被开发软件与其他有关软件之间的关系。如果本软件产品是一项独立的软件，而且全部内容自含，则说明这一点。如果所定义的产品是一个更大的系统的一个组成部分，则应说明本产品与该系统中的其他各组成部分之间的关系，为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。 2.2系统（或用户）的特点 如果是产品开发，应列出本软件的特点，与老版本软件（如果有的话）的不同之处，与市场上同类软件（如果有的话）的比较。说明本软件预期使用频度； 如果是针对合同开发，则应列出本软件的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，以及本软件预期使用频度。这些是软件设计工作的重要约束。 3.假定和约束 列出进行本软件开发工作的假定和约束，例如经费限制、开发期限等。
4.需求规定 4.1软件功能说明 逐项定量和定性地叙述对系统所提出的功能要求，说明输入什么量、经怎样的处理、得到什么输出，说明产品的容量，包括系统应支持的终端数和应支持的并行操作的用户数等指标。 4.2对功能的一般性规定 本处仅列出对开发产品的所有功能（或一部分）的共同要求，如要求界面格式统一，统一的错误声音提示，要求有在线帮助等。 4.3对性能的一般性规定 4.3.1 精度 说明对该系统的输入、输出数据精度的要求，可能包括传输过程中的精度。 4.3.2 时间特性要求 说明对于该系统的时间特性要求。 4.3.3 灵活性 说明对该系统的灵活性的要求，即当需求发生某些变化时，该系统对这些变化的适应能力。 4.4输入输出要求 解释各输入输出数据类型，并逐项说明其媒体、格式、数值范围、精度等。 对系统的数据输出及必须标明的控制输出量进行解释并举例。 4.5数据管理能力要求（针对软件系统） 说明需要管理的文卷和记录的个数、表和文卷的大小规模，要按可预见的增长对数据及其分量的存储作出估算。 4.6 故障处理要求 列出可能的软件、硬件故障以啊对各项性而言所产生的后果和对故障处理的要求。 4.7其他专门要求 如用户对安全保密的要求，包括信息加密、信息认证（确定穿过系统或网络的信息没有被修改）方面的要求。 对使用方便的要求，对可维护性、可补充性、易读性、可靠性、运行环境可
《UML与设计模式》实验报告
角色之间的关系 （4）绘制用例之间的包含和扩展关系（给出UML用例图） 用例之间如果存在包含关系，则通过拖拽“UML用例”标签页中的“用” 图标来连接两个用例；用例之间如果存在扩展关系，则通过拖拽“UML 用例”标签页中的“扩展”图标来连接两个用例。 用例图作为一种UML模型元素，也必须用包来组织。本例中将两个用例图都放到了用例模型顶层包中，还可以用注释元素对用例图作简单说明。 结果：
用例之间的包含和扩展关系 （5）每个用例进行用例描述 用例增加课程 参与者管理员 操作流（1）管理员选择进入管理界面，用例开始 （2）系统提示输入管理员密码 （3）管理员输入密码 （4）系统检验密码 （5）进入管理界面，系统显示当前所建立全部课程信息 （6）管理选择添加课程，管理输入新课程信息 （7）系统验证是否与已有课程冲突 （8）系统添加新课程，并提示添加成功 （9）系统回到管理主界面，显示所有课程，用例结束。 用例修改课程 参与者管理员 操作流（1）管理员选择进入管理界面，用例开始 （2系统提示输入管理员密码 （3）管理员输入密码 （4）系统检验密码 （5）进入管理界面，系统显示当前所建立全部课程信息
思考题【思考问题】 1．绘制用例图的步骤是什么？ 创建新的UML用例图 1.在“体系结构”菜单上，单击“新建关系图”。 2.在“模板”下，单击“UML 用例图”。 3.命名该关系图。 4.在“添加到建模项目”中，从您的解决方案中选择一个现有建模项目，或者选择“创建新的建模项目”，然后单击“确定” 绘制UML用例图 1.将“子系统”边界从工具箱拖到关系图中，它可以表示整个系统或其中的主要组件。 如果不希望描述系统或其组件支持哪些用例，用例图中可以不绘制系统边界。 根据需要，拖动系统的四角将其扩大。 对其适当地重命名。 2.将“参与者”从工具箱拖到关系图中（将其放在所有系统边界之外）。 参与者表示与您的系统进行交互的各类用户、组织和外部系统。 重命名这些参与者。例如：“顾客”、“餐馆”、“信用卡机构”。 3.将“用例”从工具箱拖到适当的系统中。 用例表示参与者在系统的帮助下所执行的活动。 使用参与者自身能够理解的名称重命名这些用例。不要使用与代码有关的名称。例如：“订餐”、“付餐费”、“送餐”。 从主要的事务（如“订餐”）开始，直到后面较小的事务（如“点菜”）为止。 将每个用例放入支持它的系统或主要子系统（忽略任何只与用户有关的外观模式或组件模式）。 可以在系统边界外绘制用例，以表明系统（可能在特定版本中）不支持该用例。 4.单击工具箱上的“关联”，然后单击用例，再单击该用例的参与者。以此方式将每个参与者与其用例相链接。
需求分析和概要设计实验报告 一．实验目的 1. 理解结构化分析和设计的软件工程范型； 2. 能运用常用的工具建立简单系统的分析模型和设计模型。 二．实验内容 图书管理系统的分析和设计。主要完成借书、还书、图书预定、图书查阅和图书管理等功能。要求建立系统的需求模型：DFD(data flow diagram)。 功能需求描述： 1. 借阅者可以通过网络查询书籍信息和预定书籍。 2. 借阅者能够借阅书籍和还书。 3. 图书管理员能够处理借阅者的借阅和还书请求，以及处理预定图书。三．实验结果 1.图书管理员处理借书第一层 1.1图书管理员处理借书第二层 2.图书管理员处理还书第一层 3.图书管理员处理预定图书第一层 3.1图书管理员处理预定图书第二层 四．实验分析 在本次实验中，我主要画出了图书管理员处理借书、还书以及预定图书的数据流程图。这是一个我们都很熟悉的环境，因此我们分析起来相对的会容易些，思路也会更加的清晰，在这个系统中，通过稍加细致的分析，我们可以了解到： 1. 图书管理员处理借书的时候，其主要过程是，先扫描读者信息，确认读者的合法性。接着，处理读者欲借阅的书。再接着，处理借书过程，同时修改读者和图书的有关信息。最后，系统将有关的信息反馈给我们的读者。 2. 图书管理员处理还书的时候，其过程相对的简单一些，只需直接处理读者欲还的书。同时修改读者和图书的有关信息。最后，系统将有关的信息反馈给我们的读者。 3. 图书管理员处理图书预定的时候，其主要过程是，先扫描读者信息，确认读者的合法性。接着，处理读者欲预定的书。再接着，处理预定图书过程，同时修改读者和图书的有关信息。最后，系统将有关的信息反馈给我们的读者。 在对这样的过程进行了分析后，再画数据流程图也就显得容易很多了。 通过本次的实验，我对数据流程图的重要性有了更加深刻的认识，数据流程图在我们设计系统过程中所扮演的角色是多么的重要，试想，如果一个系统在设计的过程中，不使用图的方式，而是将其用文字语言进行描述，这会是一个怎么样的情景。图的作用就是使我们对知识的理解非常的形象，易懂。一个非常复杂的问题，若是通过图形的方式向我们展示的话，会收到意想不到的结果。